My journey to CCIE RS —PPP
Hello folks. In this article, I continue the series of texts with my notes, accumulated during years of study until passing the CCIE RS lab years ago. As I wrote in the last articles, there are almost 400 pages of notebooks with information and observations that I consider important when working with Routing and Switching for 15 years. Some technologies are no longer used, but I’ll post them anyway (eg Frame Relay :).
I believe this information can help not only with certification exams, but the day-to-day life of others (like me) when dealing with Cisco infrastructure.
For those who have not read the first articles, follow the links for “Switching-1”, “Switching-2”. Below is the part about “PPP”.
Feel free to comment and contact me on LinkedIn. If you liked the content, I encourage you to share it with others in yours groups. Don’t forget to follow TechRebels and me by clicking “follow” :)
PPP
Main advantage is being “media independent”, besides being considered a very light encapsulation.
Adds important features that other L2 media do not natively support:
- Authentication
- Fragmentation
- Multilink
- Reliability
LCP PHASE — PPP uses Link Control Protocol (LCP) to negotiate basic options and upper layer protocols.
UPPER LAYER NEGOTIATION — Each trade has its own control protocol with its own negotiation parameters:
- IPCP
- IPv6CP
- CDPCP
- etc
Such parameters can be used to negotiate addressing and routing.
This comes from ISP dial-up times, when the client accessed the same Access Server (AS) that served more than one DHCP pool. The AS needs to know the client IP (which it gained via DHCP) because it was usually on another network. Then IPCP negotiates and installs an exact match /32 route with the client address, allowing them to be in different subnets.
By default, IPCP learns about the remote host and installs the exact match on the RIB on P2P links. This allows the hosts to be on different networks and still able to communicate.
- “No peer neighbor-route” disables this function.
NOTE: Everything can be checked through <debug ppp negotiation>. Always throw this debug to the log because it may overload the console buffer and crash. If it happens, only reloading will restore the service 😞
- <logging con 6> — don’t send debug to console
- <logging buffer 7> — send debug to buffer
- <logging buffer XXXXXX> — set a large buffer
- <clear log> — clears log
Password Authentication Protocol (PAP)
Uses clear text for “username” and “password”.
Authentication happens in 3 phases:
- Authentication Request
- Authentication Response
- Validation — Accept or Deny
Validation always checks with a local or remote database (TACACS, AAA, etc).
Authentication is always “one way”. It means that authentication on one peer is independent of authentication on another peer, allowing to mix parameters and options.
- Authenticator sends REQUEST
- AUTH-NACK means authentication has been denied.
CHAP
- The authenticator sends the request stating “hostname”.
- Host searches the base for the received hostname and returns an MD5 hash created from the password (set to hostname) and magic-number.
- Authenticator recreates the MD5 hash based on the password set for the host and magic-number and then compares it with the received hash.
NOTE: No matter what the authentication direction, the password must be the same (shared) and cannot use parameter “secret” (because it will not have the same hash on both sides) as CHAP would encrypt again.
- <ppp chap password> — uses default password to hash the response. Not used to validate authentication. Specific username and password override the default password.
NOTE: A simple solution when we have many Serial interfaces on the same router is to set them to “unnumbered” pointing them to a loopback and let PPP install / 32 routes to ensure communication.
PPPoFR
The biggest caution when using PPPoX is to create the virtual template before docking an interface, otherwise the interface may not work even with a correct config.
Virtual-template is always a link with PPP encapsulation and it is a PPP specific interface.
Virtual-access is the instance of virtual-template. In this case, access it to be UP, while the template always remains DOWN / DOWN.
NOTE: If you enable technology debug (eg debug frelay packets) the upper protocol will point to PPP and no longer to IP.
Even configured on a multipoint main interface, the virtual-access logical instance is P2P because, by definition, Point-to-Point Protocol can only be configured between 2 neighbors at a time.
PPP adds 8 bytes header to payload and obviously can generate problem with MTU.
Multilink interfaces are similar to etherchannel interfaces. The logical interface is where the config is applied and PPP takes care of fragmentation and balancing between all interfaces in the group.
Being independent, it is possible to unite interfaces of different technologies that have PPP support (frelay, eth, atm, etc).
PPPoE
- DOC — Server: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/15-mt/bba-15-mt-book/bba-pppoe-baa.html
- DOC — Client: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/15-mt/bba-15-mt-book/bba-ppoe-client.html
PPPoE is basically XDSL.
DSLAM (DSL Aggregation Multiplexer) — Basically throws multiple ATM links into higher speed links, basically doing just L1. This higher speed link goes to a PPPoE Server.
The PPPoE header is 8 bytes, so if you do not configure 1492 MTU to fragment it… 1493–1500 byte packets are actually 1501–1508 and will not be fragmented by PPP and therefore discarded by eth.
Server Steps:
- Set PPP Interface
- <virtual-template X>
2. Apply logical options
- authentication, multilink, ip address, etc
3. Define BBA group (broadband and access aggregation)
- <bba-group pppoe [NAME | global]>
- <virtual-template X>
4. Attach to link
- <pppoe enable group [NAME | global]>
Client Steps:
- Set PPP Interface
- < interface dialer X>
- <encap ppp> (by default PPP uses HDLC encapsulation) (virtual-template only supports PPP)
- <dialer pool Y>
2. Apply logical options
- authentication, multilink, ip address, etc
3. Attach to link
- <pppoe-client dial-pool-number Y>
PPPoE changes the Maximum Receivable Unit (MRU) to 1492 with 8 bytes of overhead. In this case you need to change the Dialer MTU to 1492 because it may affect the Path MTU discovery or force the router to fragment it. It can break upper application layers larger than 1492 bytes.
- Requests IP through IPCP (PPP):
- — <ip address negotiated>
- Responds through local pool (negotiated <-> pool):
- — <peer default ip address pool POOL>
- Requests IP through BOOTP:
- — <ip address dhcp>
- Responds via DHCP:
- a) Uses local pool:
- — — <peer default ip address dhcp-pool>
- b) Forward to DHCP server:
- — — <peer default ip address dhcp>
- — — <ip helper-address>
On interfaces, “mtu” specifies the L2 frame size and “ip mtu” the L3 payload size.
Explanation about PPPoE on Wikipedia is very good: https://en.wikipedia.org/wiki/PPPoE
What do you think about this content?
Did it miss any important points?
Tell me in the comment section.
If you like this content, please share. Don’t forget to follow me and TechRebels by clicking “follow” down below :)
About the author:
Giuliano Barros is Network Consultant & Founder of Control Plane — Network Services.
Gratuated in Computer Science, CCIE certified by Cisco Systems and work for 15 years with projects for medium and big size companies.
