Was hoping someone could check my thought process on how PPP works.
The below is from a cisco article.
“Active Discovery Phase—In this phase, the PPPoE client locates a PPPoE server, called an access concentrator. During this phase, a Session ID is assigned and the PPPoE layer is established.”
To me this sound like the active discover phase relies on LCP to do all the work
“PPP Session Phase—In this phase, PPP options are negotiated and authentication is performed. Once the link setup is completed, PPPoE functions as a Layer 2 encapsulation method, allowing data to be transferred over the PPP link within PPPoE headers.”
To me this sounds like the session phase uses a combination of LCP and NCP. LCP being used for option negotiation and authentication and NCP being used for the rest.
Am I on the right track or am I missing anything? Thanks for any help anyone can provide.
To provide a point-to-point connection over Ethernet, each PPP session must learn the Ethernet address of the remote peer, as well as establish a unique session identifier. PPPoE includes a discovery protocol that provides this.
PPPoE has two distinct stages. There is a Discovery stage and a PPP Session stage. When a Host wishes to initiate a PPPoE session, it must first perform Discovery to identify the Ethernet MAC address of the peer and establish a PPPoE SESSION_ID. While PPP defines a peer-to-peer relationship, Discovery is inherently a client-server relationship. In the Discovery process, a Host (the client) discovers an Access Concentrator (the server). Based on the network topology, there may be more than one Access Concentrator that the Host can communicate with. The Discovery stage allows the Host to discover all Access Concentrators and then select one. When Discovery completes successfully, both the Host and the selected Access Concentrator have the information they will use to build their point-to-point connection over Ethernet.
Forgive me. Ive never really dealt with serial links before. So why do we care about authentication when it comes to serial links? Why is it important? What exactly is being authenticated? One router is authenticating another router? Is this to prevent rogue routers? Does a Gigabit or Fast Ether router interface not deal with PPP or CHAP authentication?
@jmwalker24 The reason you would care is if you are an ISP. If you are serving customers a DSL connection you want to making sure only paying customers can use your network. Since PPPoE (which uses PPP )is used for DSL connections you can use PAP and CHAP authentication to keep unwanted users off your network. I hope this helps!
Hello Rene and Laz,
I hate to admit this but I am not 100% clear with what happens in PPP chap authentication.
From the lesson Introduction to PPP on Cisco IOS, it says
-On the left side we have a router with hostname R1.
-On the right side we have arouter without a hostname but is has the username R1 password CCNA configured in a local db
--------Challenge----------> 1st question: What is happening here? Is the challenge also sent as
In order for the above to happen does R1 have to be set up with
ppp authentication chap? Meaning, R1 will be doing the authenticating and R2 is the one that is sending the username and password? Does this mean that when R1 is configured with the ppp authentication chap, it will keep sending a challenge out its Serial port until it receives a response from R2?
In the PAP case that was described in the lesson, does now R2 have to have the ppp authentication chap and R1 use the ppp pap sent-username R1 password CCNA?
In this case does R1, who is potentially doing the authentication WAIT for R2 to sent the username and password as opposed to sending a challenge in order to trigger a response from R2? Is this the way it works?
I am attaching the images from the Ciscos ICND2 200-101 book for pap and chap respectively. Notice the WAIT ON THE OTHER ROUTER and ASK THE OTHER ROUTER on the illustrations
I am trying to understand how it works and what triggers these two processes. It seems to me that in chap the authenticating router is the one that begins the process and in pap, the router wanting to be authenticated is the one that triggers the process.
In short, no – its not a hash. Challenge contains pseudo randomly generated number. Cisco routers are randomly generating 128 bit number, so it may be missleading because MD5 hash also has 128bits, but this value in challenge frame is just a random number.
This is correct, when you configure “ppp authentication chap” on interface, router starts to send challenge frames out of this interface every 2 seconds. Each challenge frame has increased sequence number and new generated random number (128 bit random number in case of Cisco). The command “ppp authentication chap” tells the router to authenticate the other end of link with CHAP.
On the other hand with PAP and command “ppp authentication pap” we are telling the router to authenticate device on the other end of line with PAP, thus we are requiring PAP from him. In case of PAP, the device, that wants to be authenticated has to generage ppp pap frame and include its credentials in it.
You should edit your pencil notes in the book for CHAP:
(2) Response! Contains [code = 0x02; sequence ID; hash; responder name], hash value here is based on [sequence ID; password; random# from Challenge!], the order matters here.
(3) Success or Failure! Contains [code; sequence ID]. Code for Success is 0x03, for Failure 0x04, sequence ID is copied from response frame.
Whole 3-way CHAP handshake has same sequence ID in all 3 frames.
You should erase “undoes hash” pencil note. The whole hashing mechanisms are based on the fact that hashing is NOT reversible process. Once we are able to reverse hashing process then the hashing algorithm is no more considered secure. MD5 is not considered secure since 2012.
What router that receives chap response does is that he generates his own MD5 hash based on data from received response [sequence ID; password for reponder name in local database; random# generated for this sequence ID], compares generated MD5 hash with hash received in chap Response, if it is same = Success, if it is different = Failure.
It may be confusing to understand it just from text so for better imagination there is a small lab.
Lets say we want Router1 to authenticate Router2 using CHAP and Router2 wants to authenticate Router1 using PAP.
We start with CHAP. Router1 requires CHAP authentication from Router2.
Router1(config)# interface s1/0
Router1(config-if)# ppp authentication chap
CHAP verifies the identity of the peer using a three-way handshake (means there are 3 frames between peers in total for authentication). Right after PPP LCP is Open and CHAP+MD5 is negotiated for authentication between endpoint devices, following 3 messages happens:
Challenge (message 1, generated by Router1)
Device that requires authenticaion on interface generates challenge message and sends it to the peer.
This challenge message is generated every 2 seconds and contains:
01: challenge frame type identifier code. Challenge has always code 1.
ID: sequentially increasing number that identifies the challenge.
random: 16 byte pseudo random number generated by the challenger (CHAP requiring device).
device name = name of the challenger (CHAP requiring device, in our case Router1).
Response (message 2, generated by Router2)
Device that receives challenge (its the device that has to authenticate). First it has to figure what password to use for authentication.
It can identify required password in two ways.
Use specific, manually configured password (by using ppp chap password).
Username lookup. If specific username and password, that have to be send are not configured, then device is going to look for “device name” (value received in challenge frame, in our case “Router1”) in its local username database and use password that is associated with that username. As you have this example in Networklessons article Im going to use specific username/password configuration.
Configure specific username and password for CHAP reponse.
Router2(config)# int s1/1
Router2(config-if)# ppp chap hostname CHAPclient
Router2(config-if)# ppp chap password CHAPpassword
Now responding device is going to start building string from [ID, configured password, received random#], this string is used as input for MD5 hashing algorithm and final output of hashing algorithm is hash, that is send in response frame.
Response frame has this format.
02: reponse frame type identifier. Response has always code 02.
ID: this value is copied from ID field of challenge frame, thus its same to identify each other.
hash: contains MD5 hashed value of generated string
device name = name of the responding device (in our case CHAPclient, because it was configured to send).
Result (message 3, generated by Router1)
In case authentication fails, a CHAP failure frame is generated and contains:
04: failure identifier. Always code 04.
ID: copied from the response frame.
In case we configure username and password for our client.
Glad it helped.
Autocommand logout has nothing to do with authentication messages, but when we are creating username and password in local database for chap/pap clients, as side effect, this username and password can be used for telnet/ssh connection into our router.
As countermeasure “autocommand logout” is used. For example if someone telnets into router and uses CHAPclient as username, router automatically "logout"s him, before he has a chance to type any commands.
It like, when user logs in, system automatically runs command “logout” in his command line.
The reason why a /32 IP address is assigned to the client is because that is what we configured as the local pool on the server like so:
ip local pool CLIENT 192.168.12.1
As a result, whenever the client connects it will receive IP address 192.168.12.1. This command doesn’t include any subnet information, so it is assumed to be a host address, thus the /32. Now this doesn’t really matter because remember, PPP is a point to point technology. This means that L3 addressing isn’t actually used for the communication between the equipment on each end of the link, but it is used in order to route to and from the hosts from beyond the link itself.
Hello team, just for my clarification …
I visualized that after the ppp link is formed, it is exchanging “keepalive” with echo / request frames, reading this frame I see that the only useful identification would be MagicNumber. would this be the parameter he checks for both Loop / error identification, but also to validate if the peer is this UP?
if he does not receive the neighbor and is seen as down or if it is not even equal to the magic number negotiated in the initial session?
The process of configuring, maintaining and terminating the point to point link using PPP goes through specific stages. These are described in detail in RFC 1331. I include the diagram here for convenience:
The RFC explains each stage in detail.
The magic number is a parameter that is initially used in the Establishing phase, where CONFREQ and CONFACK messages are sent. The magic number is used as a way to detect looped-back links and other data link layer errors. Magic numbers are arbitrarily chosen by each PPP router and the only check that each router performs is if the received magic number is not equal to the sent magic number. If they are equal, the two routers will randomly change their magic numbers and try to reconnect.
Magic numbers are also part of the Link Maintenance packets which are used to manage and debug a successfully connected link. They are contained within echo requests and echo replies which are used to ensure that the link is up. However, the only function of the magic numbers is to ensure that no physical loopback has occurred. Routers are obligated to accept any value for the magic number as long as it is not equal to its own.
I have seen below lines in some DSL (PPPoE/PPPoA) configurations:
controller VDSL Slot/Subslot/Port
interface ATM Slot/Subslot/Port
no ip address
no atm ilmi-keepalive
interface ATM Slot/Subslot/Port.Subinterface point-to-point
pppoe-client dial-pool-number 1
ip address negotiated
dialer pool 1
ppp authentication pap callin
ppp pap sent-username qwerty password qwerty
ppp chap refuse
Q1. Can you please explain what is the use of controller VDSL command? What is its requirement when we are already configuring the physical interface (ATM).
Q2. If I wish to apply QoS settings on this DSL link, where should the service-policy be attached, Dialer or ATM subinterface?
Q3. The username password for pap in this configuration is not the local username password configured for VTY etc. right?
The configuration of the controller and the ATM interface are two different things with very different purposes.
The controller vdsl command allows you to enter the VDSL configuration mode. Within this mode you are able to configure various parameters such as the operating mode. The operating mode enables the device to choose what type of VDSL will be used including parameters such as VDSL or VDSL2, or even older ADSL profiles, and what annex will be used. In the above output, it looks like the router is set to automatically negotiate the best possible DSL parameters based on what it detects on the other end.
The ATM interface configuration configures parameters pertaining to the interface itself. Parameters include IP address, and PVC information among others.
Some additional information on these parameters for both VDSL controller and ATM interface configuration can be found here:
There are several ways to achieve this. These include:
Thanks a lot Laz for your answer. It helped me to understand the concept. I have another query regarding the controller VDSL command. If I wish to remove itsconfiguration and wish to bring to its default state (like ‘default interface ATM 0’ command), the ‘no controller VDSL’ command doesn’t work. Why is that? Is it not necessary? Any work-around?