Posts from ‘WAN’



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?

Thanks, Paul.


Here was my reply:

Hi Paul,

When using PPP CHAP keep in mind four fundamental things:

  1. 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.
  2. 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.
  3. Both routers need a CHAP password, and you have a couple of options on how to do this.
  4. 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!





Tags: , ,


This blog post is taken from the INE Resources area Understanding Frame-Relay Traffic Shaping presentation by Brian Dennis.


Frame-Relay traffic shaping is designed to control the amount of traffic the router sends out of an interface or out of a particular DLCI. Common reasons for Frame-Relay traffic shaping are:

  • It allows the router to conform to the rate subscribed with the service provider
  • It allows for the throttling of a higher speed site (768K) so that it does not overrun a lower speed site (64K)

Traffic shaping is designed to delay excess traffic, whereas policing is designed to drop excess traffic.


  • Available Rate (AR) – the actual physical speed of the interface; on a DCE serial interface this is determined by the configured clock rate. On a DTE serial interface, it is determined by the received clock rate. A router will always (by default) try to send out at the AR regardless of the interface bandwidth. AR is also commonly referred to as port speed, line rate, or access rate.

Continue Reading

Tags: , , ,


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.

Continue Reading

Tags: , , , , ,


CCIE Bloggers