Layer 2 WAN Technologies

Here we go – one last layer 2 topic before we cross the threshold into the heart of what the CCIE exam is really all about: Routing.  It’s been mind-blowing to reflect back on how much I’ve learned putting together the content for our Layer 2 series.  I can hardly wait to get into the next series.  Still, let’s do justice to our LAN Switching series by looking at our last set of topics at Layer 2:

2.3 Layer 2 WAN circuit technologies
2.3.a Implement and troubleshoot HDLC

 2.3.b Implement and troubleshoot PPP
2.3.b [i] Authentication [PAP, CHAP]
2.3.b [ii] PPPoE
2.3.b [iii] MLPPP

Implement and Troubleshoot HDLC

This feels silly to even write about.  Serial interfaces run HDLC by default.  This is perhaps the simplest protocol you’ll ever work with.  HDLC is the thing that makes it so that you can just toss an IP address on your serial interfaces and have them work.  Seriously, it’s that easy.  For troubleshooting, you might find a pair of links that accidentally has HDLC on one side, but not the other.  In such a case, you can just switch the encapsulation back with the encapsulation hdlc command.  Technically, you could see symptoms from the show interface output, where you would be seeing mismatched encapsulation and incrementing “unknown protocol” drops.


Honestly though, it’s most likely that you’d just notice the mismatched configuration when doing a side-by-side “show run” comparison.

Implement and Troubleshoot PPP

PPP, while more detailed than HDLC, is still very easy to use and troubleshoot.  It was designed by simply taking HDLC and adding some fields in order to allow it to specify protocols carried within the L2 frame.  This protocol field allows PPP to use many additional features such as authentication and address assignment.  Activating PPP itself on an interface is as simple as using the interface encapsulation ppp command.  While you could stop at this point and you would have a fully functional link, the basic reason to do so is to use some of the added features that PPP gives.

Authentication [PAP, CHAP]

Authentication is, of course, one of these added features that PPP offers.  The two flavors of PPP authentication covered on the CCIE exam are PAP and CHAP.  PAP sends passwords in plain text.  This might be acceptable over a trusted link.  More often than not though, you’ll see CHAP in use, as it offers some basic security for very little processing overhead, and is relatively simple enough that it would rarely require any major training of Engineering staff.  Before we even begin to talk about configuration, please note that any PPP authentication configuration will bring the links down.  Please remember this if you are implementing PPP in a production environment!

To turn on PAP, first, the routers need to be configured with appropriate login information.  On the authenticating router, create a local account with the credentials that the remote router will use to log in.  Both routers can be configured to mutually authenticate each other, but the authentication in each direction is considered a completely separate process, and does not need to be configured in both directions.  Also note that there is some documentation in existence that states that the username on the authenticating router must match the hostname of the router that is attempting to log in, however, we will see that this is not the case.  It can be done this way, and it certainly can make sense to use that convention in many scenarios, but it is not necessary.  Configure the username with the global username ID password 0 string command.  Next, on the router that will be attempting to log into the authenticating router, configure the username and password that you want to send with the interface ppp pap sent-username ID password 0 string command.  Finally, activate PAP with the interface ppp authentication pap command.  This command only needs to be entered on the router that is doing the authenticating.

For CHAP authentication, it still isn’t necessary to use a locally configured username that matches the neighbor’s hostname.  But the configuration is a little different.  Still, it’s quite simple to configure.  First, configure a sending hostname with the interface ppp chap hostname ID command, then the password with the ppp chap password string command.  Once you’re ready, activate the CHAP process with the interface ppp authentication chap command.  Again, this password should only be entered on the router that is requiring the remote router to authenticate to itself.





If you had a DSL connection 10 years ago, chances are that you used some sort of PPPoE client on your PC to get online.  Nowadays, PPPoE is still widely used, but it’s become a bit of a “behind the scenes” protocol.  Providers still use it, but they usually ship customers a router or modem that is running PPPoE to authenticate to their network, so the PPPoE authentication happens between the router and the provider cloud rather than the customer’s PCs and the cloud.  While Cisco’s implementation is not overly complicated, this is a technology that is most often used between a provider and a client, and as such, has two very different configurations on each side.  There’s a lot of stuff to configure, so it can seem a little overwhelming.  That said, it’s not complicated… there’s just a lot to remember.

While not necessary, it’s obviously a best practice to also configure a password for PPPoE sessions.  On the provider side, provision this by first creating a local username and password where the username matches the client’s hostname.  As we configure each side, I’ll show you how to leverage this account for authentication.

On the provider side, you first configure a local username for the customer router to authenticate against.  Next, create a pool of addresses that clients will use with the ip local pool pool_name start_ip end_ip command.  Next, define a virtual template that will be used for this PPPoE connection.  Do this with the global interface virtual-template # command.  Assign the virtual template an IP address as you would any interface.  Then, tell the virtual interface to hand out IP addresses to clients with the virtual-interface mode peer default ip address pool Pool_Name command.  Then, instruct the virtual-template to require authentication with the ppp authentication chap callin command.  Next, define a Broadband Access (BBA) group with the global bba-group pppoe bba_group_name command, and tell the bba-group to use the defined virtual-template with the bba-group config virtual-template # command.  Finally, assign all of this configuration to an interface with the interface no ip address command, then the pppoe enable group bba_group_name command.


On the client side, first create a dialer interface with the global interface dialer1 command.  From there, use the dialer pool 1 command, the encapsulation ppp command, and the ip address negotiated commands.  Because the PPPoE encapsulation adds 8 bytes to the frames, it is also best to use the dialer interface config mtu 1492 command.  If using authentication, you’ll also need to configure the password with the ppp chap password string command.  Finally, use the pppoe-client dial-pool-number 1 command.  You’ll receive a message saying “Interface Virtual-Access#, changed state to up” – where # is the dialer interface number configured.  The connection can be verified with the show pppoe session command.



Before moving onto our next topic, this is a great place to point out the value of having a good strategy for the exam.  I’ll be very frank, I have absolutely no intention of memorizing all of that.  I don’t use PPPoE in any capacity in the environment that I manage, and even if I were to spend the hours that it would take memorize all of that, I would forget it as soon as the exam is done, because it’s just not a commonly encountered technology for me.  Rather than memorize a massive list of commands, I’ll instead make sure I’m very comfortable working from the documentation that will be available to me during the exam, such as this command reference:

and even more importantly, the configuration guide:


Multi-link PPP works the way that we think etherchannels should work when we first begin learning about link-aggregation: it chops packets up and uses each member interface to send a part of the packet.  Given that statement, the reasonable follow-up question is “Why do MLPPP bundles use this concept, where EtherChannels don’t?”  The answer: CPU.  MLPPP connections are handled by the router’s CPU.  Because Serial interface link speeds don’t usually come anywhere near that of Ethernet interfaces, the burden on a router’s CPU is much more manageable than this concept would be for an Etherchannel bundle.

Configuration is simple – simply configure an MLPPP interface with the interface multilink1 command.  Assign the IP address here at the multilink interface, then complete your configuration with the encapsulation ppp command, the ppp multilink command, and the ppp-multilink group 1 command.  Then, simply add your interfaces to the MLPPP bundle with the serial interface encapsulation ppp command and the ppp multilink group 1 command.

Well, we’ve now covered two of the major exam objectives, Network Principles and LAN Switching.  The next one is the biggie: IP Routing.

Leave a Comment

Your email address will not be published. Required fields are marked *