PPP (Point to Point Protocol) is one of those protocols that I’m absolutely irritated about having to learn. I’ve never had to use or configure PPP in my life, and I had to ask around a couple of study groups to find someone who had. Prior to asking anyone, I thought PPP (and it’s bastard child, PPPoE) were outdated protocols, used only by aboriginal tribes who still had AOL discs. That being said I was wrong; I was informed that it is very much in use today for places that use T1/E1 for some of their more rural sites, and ISPs use it regularly (well, PPPoE) for connecting users to DSL.
The more unfortunate part of learning this technology is that the documentation isn’t very well organized. At best there are some books that cover it (namely The TCP/IP Illustrated v1, 2nd Ed.) and some Cisco documentation… but you don’t really get a good idea of what you need to configure with it. While I’m one CCIE certification away from being able to tell you what you need to configure with it, I can at least help you figure out the basics.
So What is PPP, anyway?
PPP is a media-independent encapsulation protocol. But why make yet another encapsulation protocol? There was already HDLC and Cisco’s proprietary HDLC, as well as SLIP, To answer the question of what is PPP, we need to answer a more fundamental question:
What problem does PPP solve that other protocols don’t?
A few simple answers:
- HDLC is an ISO standard, but every vendor put their own spin on it.
- These “spins” may as well be considered proprietary, as they don’t interoperate.
- SLIP was lightweight and interoperable, but it doesn’t have many features
- PPP has many features:
- Open Standard (yay, interoperability!)
- Error Correction (Link Quality Management)
- Load Balancing
- Efficiency features (LFI, compression)
These aren’t the only features that PPP has over it’s competitors, but they are some of the more important ones. PPP is mostly used for it’s vendor interoperability, load-balancing, and authentication features.
What do you mean, poorly documented?
For starters, to find any usable Cisco configuration guides on PPP, you have to scavenge through the IOS 12.2(SR) code. Only there will you find the stuff that gives you a nice, from-the-ground-up explanation of PPP. Aside from that, there’s the “Network Technologies” page for PPP, with its various sub-pages and their sub-pages; these are plagued with broken links and documentation that is dense for those of us who are just getting started on it.
Before I found the page in the IOS 12.2(SR) code, I found a couple good pages on Wikipedia, and the always wonderful TCP/IP Illustrated v1, 2nd Ed.
What do I need to know about PPP?
There are some core things that are important about this. The first of which is that PPP uses a different frame format than Cisco’s HDLC.
At first glance, the cHDLC packet looks very similar to the PPP packet — and that’s actually because the PPP packet is largely based on HDLC. The difference really boils down the standardized “Protocol” field belonging to the PPP header (as opposed to cHDLC’s proprietary “Type” header), and the fact that PPP pads its payload with extra bits.
Another important thing here is that there are different phases that PPP uses when building it’s connection. You should probably make sure to remember them:
- Link Establishment
- Authentication (optional)
- Network Layer Protocol
Each one of these phases has a different protocol to handle it. The Link Establishment phase uses the Link Control Protocol to do a few things; namely, verifying that both devices speak PPP, and that they agree (more or less) on the parameters of the connection. The devices negotiate Authentication Type, whether or not they’ll use multiple physical connections (multilink PPP), if they’ll monitor the quality of the connection, and the MTU size for the link (called MRU). These are negotiated with a series of messages that you’ll of course need to memorize:
- Configuration Request (CONFREQ): A list of proposed parameters for link establishment
- Configuration Acknowledge (CONFACK): A copy of the CONFREQ message, with duplicate information, agreeing to the parameters.
- Configuration Negative Acknowledge (CONFNAK): Contains the unacceptable parameters listed in the CONFREQ, but with acceptable options listed with it.
- Configuration Reject (CONFREJ): Contains unacceptable or unrecognizable options. This doesn’t necessarily mean the connection will fail, but the rejected parameter/config will not be enabled.
Once the link is negotiated, authentication comes into play. The two most popular types of authentication are PAP (Password Authentication Protocol) and CHAP (Challenge-Handshake Authentication Protocol). Those are important too, and you’ll use them even more when you get to configuring PPPoE (so remember them too).
After the Authentication phase, the Network Layer Protocol phase begins. In this aptly-named phase, the devices must negotiate for each upper–layer protocol they’re going to use. I say upper-layer instead of layer 3 because CDP must also be negotiated, and it isn’t a layer 3 protocol.
Are you going to show me how to configure any of this stuff?
No. Mostly because I’m in the middle of learning it myself, but also because there are MANY use cases for this that one blog article can’t cover. This one has gone on long enough.
- The TCP/IP Illustrated Vol 1, 2nd Ed;
- Cisco Documentation: