Following on from part one where we set up trunking, vtp, port aggregation and load balancing, we are going to move to the other side of our topology now and set up PPP between R1 and R2.
This will cover item 1.70 if the CCIE exam list (Implement High-Level Data Link Control (HDLC) and PPP). Now thankfully as HDLC is the default within PPP for Cisco devices then the process is pretty straight forward.
Remember from the first post when I said that the topology will probably change throughout this lab, well already its going to change, by adding a second link between R1 and R2 so we can check out multi-link PPP. Considering the topology has already changed and it's only part 2 of this series I reckon that the topology will be far different as we near the end!
The topology now looks like this:
And the netmap now looks like this
1:0/0 2:0/0
1:0/1 2:0/1
2:0/2 3:0/0
2:0/3 4:0/0
4:0/1 5:0/0
5:0/1 6:0/0
6:0/1 7:0/1
4:0/2 8:0/0
5:0/2 9:0/0
8:0/1 9:0/1
8:0/2 10:1/0
10:0/1 11:1/1
11:0/0 12:0/0
11:0/1 12:0/1
11:0/2 13:0/2
13:0/0 14:0/0
13:0/1 14:0/1
12:0/2 14:0/2
So lets get started with PPP.
Basic PPP configuration
The basic set up of PPP is three commands. Firstly we create a username and password on one router for the second router (i.e. a user called R2 will be created on R1 and vice versa). Secondly we set the encapsulation, and thirdly we set the authentication type.
There is very little difference on the other side of the link:
And (once we remember to do a "no shut"), we can see that the link is up:
Now let's see how to throw another link into the mix.
Multi-link PPP
When we create a multi-link connection we start by removing the ip addresses from the individual serial links, and assign the interface to the multilink group instead:
We do the same on R2 and check the multilink interface is up, and that we can ping back to R1:
We can now start to see the benefit of multi-link PPP, in that it balances traffic by fragmenting each frame and sending these fragments out over different links.
I cleared the counters on both the serial interfaces in R2 and on the multilink interface, then sent a ping with a repeat of 100. Now if we look at the interface statistics, starting with the multilink interface:
Firstly we can see that the bandwidth is 3088 Kbit/sec, and we can see that we have 11011 bytes input and 12707 bytes output. Now lets look at s0/0:
The bandwidth is the standard 1544 for a serial link and we have 6376 bytes going in and out, and if we have a look at s0/1:
We can see here that the bandwidth is also 1544 (which accounts for the 3088 bandwidth we saw for the multilink interface), and they byte count is 6651 (in and out). 6376 + 6651 = 13027, which is close to the byte count seen on the multilink interface (it's not exact as there was probably some packets sent in between clearing the counters and doing the "sh int" commands).
PPP Link fragmentation and interleaving (LFI)
So what else can we do with PPP and PPP Multi-link? Well we can implement compression and play around with the link fragmentation and interleaving (LFI).LFI
LFI is a form of QoS that prevents small, delay-sensitive packets from having to wait longer for larger packets to be completely serialized out of an interface. LFI fragments the larger packets and send the smaller packet after just a portion of the larger packet. This only takes two commands, and these are:
The first command will interleave the packets (as specified above), the second command sets the fragment delay to 10ms.
Compression we'll leave until nearer the end of the series when we'll look at optimizing our network, but for the last part of this post we'll look at AAA authentication.
AAA for PPP
We can setup AAA authentication for PPP as seen below:
We start with the aaa new-model command (which sets up new access-control commands and functions) , we then set the command "aaa authentication login default line" which will then accept the line password for authentication. We then set the login to be radius with local case as a fallback with the command "aaa authentication ppp default group radius local-case" and we should also create the local usernames as we did earlier as the fallback mechanism. We then set the radius host, and specify the key to be used, and lastly we set the authentication for chap to use the default authentication list (radius then local-case).
And that's PPP, PPP Multilink, interleaving and AAA for PPP covered.
So what's next? Well, I'd like to do the tunnel between R7 and R9, but that will require getting frame-relay, RIP and EIGRP all set up, so instead, let's not run before we can walk, and we'll do OSPF instead.
So next up in part 3 we'll look at OSPF, concentrating on locking our updates down to loopback addresses, advertising these loopback addresses, and join our OSPF instances to R1 - not just because it would be lonely out there on the edge of our topology, but also because at the end of our series we'll need to test end to end connectivity.