Posts Tagged ‘ppp’
The following question was recently sent to me regarding PPP and CHAP:
At the moment I only have packet tracer to practice on, and have been trying to setup CHAP over PPP.
It seems that the “PPP CHAP username xxxx” and “PPP CHAP password xxxx” commands are missing in packet tracer.
I have it set similar to this video… (you can skip the first 1 min 50 secs)
As he doesn’t use the missing commands, if that were to be done on live kit would it just use the hostname and magic number to create the hash?
Also, in bi-directional authentication, do both routers have to use the same password or can they be different as long as they match what they expect from the other router?
Here was my reply:
When using PPP CHAP keep in mind four fundamental things:
- The “magic number” that you see in PPP LCP messages has nothing to do with Authentication or CHAP. It is simply PPPs way of trying to verify that it has a bi-directional link with a peer. When sending a PPP LCP message a random Magic Number is generated. The idea is that you should NOT see your own Magic Number in LCP messages received from your PPP Peer. If you DO see the same magic number that you transmited, that means you are talking to yourself (your outgoing LCP CONFREQ message has been looped back to you). This might happen if the Telco that is providing your circuit is doing some testing or something and has temporarily looped-back your circuit.
- At least one of the devices will be initiating the CHAP challenge. In IOS this is enabled with the interface command, “ppp authentication chap”. Technically it only has to be configured on one device (usually the ISP router that wishes to “challenge” the incoming caller) but with CHAP you can configure it on both sides if you wish to have bi-directional CHAP challenges.
- Both routers need a CHAP password, and you have a couple of options on how to do this.
- The “hash” that is generated in an outgoing PPP CHAP Response is created as a combination of three variables, and without knowing all three values the Hash Response cannot be generated:
- A router’s Hostname
- The configured PPP CHAP password
- The PPP CHAP Challenge value
I do all of my lab testing on real hardware so I can’t speak to any “gotchas” that might be present in simulators like Packet Tracer. But what I can tell you, is that on real routers the side that is receiving the CHAP challenge must be configured with an interface-level CHAP password.
The relevant configurations are below as an example.
ISP router that is initiating the CHAP Challenge for incoming callers:
username Customer password cisco ! interface Serial1/3 encapsulation ppp ppp authentication chap ip address x.x.x.x y.y.y.y !
Customer router placing the outgoing PPP call to ISP:
hostname Customer ! interface Serial1/3 encapsulation ppp ppp chap password cisco ip address x.x.x.x y.y.y.y !
If you have a situation where you expect that the Customer Router might be using this same interface to “call” multiple remote destinations, and use a different CHAP password for each remote location, then you could add the following:
Customer router placing the outgoing PPP call to ISP-1 (CHAP password = Bob) and ISP-2 (CHAP password = Sally):
hostname Customer ! username ISP-1 password Bob
username ISP-2 password Sally
interface Serial1/3 encapsulation ppp ppp chap password cisco ip address x.x.x.x y.y.y.y !
Notice in the example above, the “username x password y” commands supercede the interface-level command, “ppp chap password x”. But please note that the customer (calling) router always needs the “ppp chap password” command configured at the interface level. A global “username x password y” in the customer router does not replace this command. In this situation, if the Customer router placed a call to ISP-3 (for which there IS no “username/password” statement) it would fallback to using the password configured at the interface-level.
Lastly, the “username x password y” command needs to be viewed differently depending on whether or not it is configured on the router that is RESPONDING to a Challenge…or is on the router that is GENERATING the Challenge:
- When the command “username X password Y” is configured on the router that is responding to the CHAP Challenge (Customer router), the router’s local “hostname” and password in this command (along with the received Challenge) will be used in the Hash algorithm to generate the CHAP RESPONSE.
- When the command “username X password Y” is configured on the router that is generating the CHAP Challenge (ISP Router), once the ISP router receives the CHAP Authentication Response (which includes the hostname of the Customer/calling router) it will match that received Hostname to a corresponding “username X password Y” statement. If one is found that matches, then the ISP router will perform its own CHAP hash of the username, password, and Challenge that it previously created to see if its own, locally-generated result matches the result that was received in the CHAP Response.
Lastly, you asked, “ Also, in bi-directional authentication, do both routers have to use the same password or can they be different as long as they match what they expect from the other router?”
Hopefully from my explanations above it is now clear that in the case of bi-directional authentication, the passwords do indeed have to be the same on both sides.
Hope that helps!
In this post, we will examine PAP and CHAP forms of PPP authentication. The emphasis here will be on the fact that these technologies are one-way in nature. So many of my CCIE-level students believe that they must be configured in a bidirectional configuration. I guess this is because it is what traditional Cisco classes always demonstrate at the CCNA and CCNP levels.
OK – I have pre-configured two routers, R1 and R2, they are connected by their Serial 0/0 interfaces. Let us begin with R1 as a PPP PAP server, and the R2 device as the PPP PAP client. If you ALWAYS think of these technologies (PAP and CHAP) in terms of CLIENT and SERVER commands, you will be in excellent shape.
If you ever used IPCP for address allocation with PPP (“ip address negotiated” on client side and “peer default ip address” on server side) you may have noticed that the mask assigned to a client is always /32. It does not matter what mask a server uses on it’s side of the connection, just PPP is designed to operate this way.
However, many have noticed two strange commands “ppp ipcp mask request” and “ppp ipcp mask X.X.X.X” under PPP interface configuration mode. If IPCP assigned address never uses a custom mask, what would the purpose of those commands be? The answer is simple – to configure on-demand address pools in a client. That is, a client may request a DHCP pool parameters from server using IPCP – for example request a subnet and a mask. The client may then further use this information and allocate IP addresses to it’s subordinates. Here is a configuration to verify this feature. Consider that R1 connects to R3 over a point-to-point link:
R1: ip dhcp pool LOCAL import all origin ipcp ! ! Link to R3 ! interface Serial0/1 ip address pool LOCAL encapsulation ppp ppp ipcp mask request R3: ! ! Link to R1 ! interface Serial1/2 ip address 172.16.13.3 255.255.255.0 encapsulation ppp peer default ip address pool POOL clock rate 128000 ppp ipcp mask 255.255.255.0 ! ip local pool POOL 172.16.100.1 172.16.100.254
Using the “debug ppp negotiation” command on R1 (the client) and R3 (the server) you may see the mask being requested and passed down to the client. Debug output from R1:
Se0/1 IPCP: I CONFREQ [REQsent] id 1 len 10 Se0/1 IPCP: Address 172.16.13.3 (0x0306AC100D03) Se0/1 IPCP: O CONFACK [REQsent] id 1 len 10 Se0/1 IPCP: Address 172.16.13.3 (0x0306AC100D03) Se0/1 CDPCP: Redirect packet to Se0/1 Se0/1 CDPCP: I CONFREQ [REQsent] id 1 len 4 Se0/1 CDPCP: O CONFACK [REQsent] id 1 len 4 Se0/1 IPCP: I CONFNAK [ACKsent] id 1 len 20 Se0/1 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se0/1 IPCP: Address 172.16.100.3 (0x0306AC106403) Se0/1 IPCP: O CONFREQ [ACKsent] id 2 len 20 Se0/1 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se0/1 IPCP: Address 172.16.100.3 (0x0306AC106403) Se0/1 CDPCP: I CONFACK [ACKsent] id 1 len 4 Se0/1 CDPCP: State is Open Se0/1 IPCP: I CONFACK [ACKsent] id 2 len 20 Se0/1 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se0/1 IPCP: Address 172.16.100.3 (0x0306AC106403) Se0/1 IPCP: State is Open Se0/1 IPCP: Subnet: address 172.16.100.3 mask 255.255.255.0
Debug output from R3:
Se1/2 IPCP: O CONFREQ [Closed] id 1 len 10 Se1/2 IPCP: Address 172.16.13.3 (0x0306AC100D03) Se1/2 CDPCP: O CONFREQ [Closed] id 1 len 4 Se1/2 PPP: Process pending ncp packets Se1/2 IPCP: I CONFREQ [REQsent] id 1 len 20 Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C0100000000) Se1/2 IPCP: Address 172.16.100.3 (0x0306AC106403) Se1/2 IPCP: Use our explicit subbnet mask 255.255.255.0 Se1/2 IPCP: O CONFNAK [REQsent] id 1 len 14 Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se1/2 CDPCP: I CONFREQ [REQsent] id 1 len 4 Se1/2 CDPCP: O CONFACK [REQsent] id 1 len 4 Se1/2 CDPCP: I CONFACK [ACKsent] id 1 len 4 Se1/2 CDPCP: State is Open Se1/2 IPCP: I CONFACK [REQsent] id 1 len 10 Se1/2 IPCP: Address 172.16.13.3 (0x0306AC100D03) Se1/2 IPCP: I CONFREQ [ACKrcvd] id 2 len 20 Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se1/2 IPCP: Address 172.16.100.3 (0x0306AC106403) Se1/2 IPCP: Use our explicit subbnet mask 255.255.255.0 Se1/2 IPCP: O CONFACK [ACKrcvd] id 2 len 20 Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00) Se1/2 IPCP: Address 172.16.100.3 (0x0306AC106403)
Now this is what you get when you configure “ip address negotiated” on R1:
R1#sh ip interface serial 0/1 Serial0/1 is up, line protocol is up Internet address is 172.16.100.5/32 Broadcast address is 255.255.255.255 Address determined by IPCP Peer address is 172.16.13.3
And this is what shows up when you use local DHCP address pool for autoconfiguration (note the subnet mask):
R1#sh ip interface serial 0/1 Serial0/1 is up, line protocol is up Internet address is 172.16.100.4/24 Broadcast address is 255.255.255.255 Address determined by setup command Peer address is 172.16.13.3
However, the funniest part is that R1 serial interface IP address is actually not allocated from the local (on-demand) DHCP pool! Observing the debug output you can see that R1 uses the IP address sent from R3, not allocated from the local DHCP pool. Then again, the local pool DHCP still has the requested subnet:
R1#sh ip dhcp pool Pool LOCAL : Utilization mark (high/low) : 100 / 0 Subnet size (first/next) : 0 / 0 Total addresses : 254 Leased addresses : 0 Pending event : none 1 subnet is currently in the pool : Current index IP address range Leased addresses 172.16.100.1 172.16.100.1 - 172.16.100.254 0 R1#sh ip dhcp binding Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name R1#
You can see the following on R3:
R3#sh ip local pool POOL Pool Begin End Free In use POOL 172.16.100.1 172.16.100.254 253 1 ... 172.16.100.1 Se1/2 172.16.100.2 Se1/2 172.16.100.3 Se1/2 172.16.100.4 Se1/2 Inuse addresses: 172.16.100.4 Se1/2
This is what so funny about Cisco IOS – you can never be sure the feature works in a most logical way you may suppose it to work. You can play with this example further, for example changing IP address allocation on R3 to local DHCP Pools or a static IP – there is always something you can experiment with!
A common question that I get from students in class is what are the options to resolve spoke to spoke reachability in a Frame-Relay network. Below are your “standard” choices in order of preference:
1) Use point-to-point subinterfaces on the spokes. This option is preferred as all IP addresses on the subnet will automatically be mapped to the DLCI that is bound to the subinterface.
2) Multipoint interfaces (physical or multipoint subinterfaces) on the spokes with Frame-Relay mappings pointing to the hub’s DLCI to reach the other spokes.
3) Multipoint interfaces on the spokes along with using the OSPF point-to-multipoint network type on all routers on the subnet. Each end point will advertise out a /32 and this advertisement will be relayed to the other spokes by the hub. This is exactly what the OSPF point-to-multipoint network type was designed for (full layer 3 reachability in a network that doesn’t have full layer 2 connectivity.
4) Use PPP over Frame-Relay (PPPoFR). By using PPPoFR IP will now be running over PPP and not directly over Frame-Relay. This means that IP sees everything as point-to-point links and no layer 3 to layer 2 mappings are needed.
5) Static /32 routes on the spokes point to the hub to reach the other spokes. Not a pretty solution but it will resolve the reachability issue.
Below are a couple example configurations for PPPoE. Note that you can run into MTU issues when trying to use OSPF over PPPoE. This can easily be resolved by using the “ip ospf mtu-ignore” command as the dialer interface’s MTU is 1492 while the virtual-template’s (virtual-access) MTU is 1500.
*** Client *** interface Ethernet0/0 pppoe enable pppoe-client dial-pool-number 1 ! interface Dialer1 ip address 22.214.171.124 255.255.255.0 encapsulation ppp dialer-pool 1 dialer persistent *** Server *** vpdn enable ! vpdn-group CISCO accept-dialin protocol pppoe virtual-template 1 ! interface Ethernet0/0 pppoe enable ! interface Virtual-Template1 ip address 126.96.36.199 255.255.255.0
The next example is using DHCP to assign the client their IP address:
*** Client *** interface Ethernet0/1 pppoe enable pppoe-client dial-pool-number 1 ! interface Dialer1 ip address dhcp encapsulation ppp dialer pool 1 dialer persistent *** Server *** ip dhcp excluded-address 188.8.131.52 184.108.40.206 ! ip dhcp pool MYPOOL network 220.127.116.11 255.255.255.0 ! vpdn enable ! vpdn-group CISCO accept-dialin protocol pppoe virtual-template 1 ! interface Ethernet0/0 pppoe enable ! interface Virtual-Template1 ip address 18.104.22.168 255.255.255.0 peer default ip address dhcp-pool MYPOOL
Hello Brian,Can you explain how PPP over Frame Relay works? Also what are the advantages and disadvantages of using it over normal Frame Relay configuration?Thanks and regards,
Frame Relay does not natively support features such as authentication, link quality monitoring, and reliable transmission. Based on this it is sometimes advantageous to encapsulate an additional PPP header between the normal layer 2 Frame Relay encapsulation and the layer 3 protocol. By running PPP over Frame Relay (PPPoFR) we can then implement authentication of Frame Relay PVCs, or even bind multiple PVCs together using PPP Multilink.
PPPoFR is configure in Cisco IOS through the usage of a Virtual-Template interface. A Virtual-Template is a PPP encapsulated interface that is designed to spawn a “template” of configuration down to multiple member interfaces. The traditional usage of this interface has been on dial-in access servers, such as the AS5200, to support multiple PPP dialin clients terminating their connection on a single interface running IP.
The first step in configuring PPPoFR is to create the Virtual-Template interface. This interface is where all logical options, such as IP address and PPP authentication will be configured. The syntax is as follows:
interface Virtual-Template1 ip address 22.214.171.124 255.255.255.0 ppp chap hostname ROUTER6 ppp chap password 0 CISCO
Note the lack of the “encapsulation ppp” command on the Virtual-Template. This command is not needed as a Virtual-Template is always running PPP. This can be seen by looking at the “show interface virtual-template1” output in the IOS. Additionally in this particular case the remote end of this connection will be challenging the router to authenticate via PPP CHAP. The “ppp chap” subcommands have instructed the router to reply with the username ROUTER6 and an MD5 hash value of the PPP magic number and the password CISCO.
Our next step is to configure the physical Frame Relay interface, and to bind the Virtual-Template to the Frame Relay PVC. This is accomplished as follows:
interface Serial0/0 encapsulation frame-relay frame-relay interface-dlci 201 ppp Virtual-Template1
Note that the “no frame-relay inverse-arp” command is not used on this interface. Since our IP address is located on the Virtual-Template interface the Frame Relay process doesn’t actually see IP running over the link. Instead it simply sees a PPP header being encapsulated on the link, while the IPCP protocol of PPP takes care of all the IP negotiation for us. Note that the order that these steps are performed in is significant. If a Virtual-Template interface is applied to a Frame Relay PVC before it is actually created you may see difficulties with getting the link to become active.
Also when using a Virtual-Template interface it’s important to understand that a Virtual-Access “member” interface is cloned from the Virtual-Template interface when the PPP connection comes up. Therefore the Virtual-Template interface itself will always be in the down/down state. This can affect certain network designs such as using the backup interface command on a Virtual-Template. In our particular case we can see from the below output this effect:
R6#show ip interface brief | include 126.96.36.199 Virtual-Access1 188.8.131.52 YES TFTP up up Virtual-Template1 184.108.40.206 YES manual down down
Aside from this there is no other configuration that directly relates to Frame Relay for PPP. Other options such as authentication, reliability, and multilink would be configured under the Virtual-Template interface.