Site-Local Addresses

Site-local addresses were the first stab at having a private address space range for our internal organizations similar to RFC 1918 for IPv4. This address space was defined in RFC 3513 as being in the range FEC0::/10. Basically what this means is that the first 12 bits of the address had to look something like this:

1111 1110 11xx

[ F ] [ E ] [C-F]

So anyways, the site-local address was the first attempt at letting network admins assign their own private addressing for their “sites.” The issues with it were that the term “site” was somewhat ambiguous. Nobody could really agree on what a “site” was. Secondly, there was no guarantee that no two sites within the same organization would not end up using overlapping site addressing due to carelessness or whatever else. Site-Local addresses went to sleep permanently when deprecated officially in RFC 3879. Unfortunately for the current CCIE candidate, this site-local address range is still used quite extensively in some Cisco documentation

Unique-Local Addresses

Out with the old in with the new! Unique-Local addresses have officially replaced site-local addresses. These get a little bit more interesting because there are really two different “flavors.” Unique-Local Addresses (ULA) are defined in RFC 4193 and are given the range FC00::/7. Basically your first 8 bits will look like this:

1111 110x

[F ] [C-D]

Overall, your unique-local address will look something like this:

F[C-D]xx:xxxx:xxxx:yyyy:zzzz:zzzz:zzzz:zzzz

So obviously it starts with EITHER FC or FD in hexadecimal. The string of ‘x’s there represents what we call our “global-id” which would describe your company and is 40 bits long. The string of ‘y’s represent what we call the “subnet-id” which describes the sites within your company and is 16 bits long. The string of ‘z’s is the remaining 64 bits that represent a host. So essentially you have a 40-bit value that represents your company and 16 bits to play with for subnetting. If you do the math that gives you up to 65,535 /64 subnets…a LOT of addresses.

OK, so we have this FC00::/7 range. Now, here is where it gets a little extra interesting. Basically some people thought the 40-bit global-id should be something centrally assigned by a registrar of sorts (kind of like ARIN). The addresses would still not be routable on the public internet, but would be controlled by a trusted third party registrar. The reasoning was so that it was guaranteed that no two sites within an organization would ever get overlapping ranges. On the other hand, other people didn’t like the idea of having private addresses allocated to them. Therefore, what they did was a compromise. They took this massive FC00::/7 range and broke it up into two individual /8’s – FC00::/8 and FD00::/8 and each one works a bit differently.

Unique-Local Locally-Assigned Addresses (FD00::/8)

The folks that do not want their private addresses assigned to them by a third party get this range. The kicker is that in the RFC the way that 40-bit global-id get’s picked is still not really SUPPOSED to be up to you. It is a randomly generated number (at least “pseudo-random”). So, with FD00::/8 you get something like this

FDxx:xxxx:xxxx:yyyy:zzzz:zzzz:zzzz:zzzz

Here the string of ‘x’s is still the global-id and is 40-bits long…it is just randomly generated, or at least SHOULD be. The rest is the same…we still have 16 bits for subnetting and a /64 host address

Unique-Local Centrally-Assigned Addresses (FD00::/8)

The folks that WERE for the private addresses being centrally assigned by some sort of registrar get the FC00::/8 range. Now, as of right now this organization that is supposed to hand out the addresses really doesn’t exist yet :P ANYWAYS, the concept is similar except now you have something like this:

FCxx:xxxx:xxxx:yyyy:zzzz:zzzz:zzzz:zzzz

Here the string of ‘x’s is still the global-id and is 40-bits long…but it is ASSIGNED to you in theory. The rest is the same…we still have 16 bits for subnetting and a /64 host address

So now what?!

For purposes of the CCIE R&S v4.0 lab – IF you are asked to do “site-local” addressing I would verify with the proctor that they REALLY mean site-local as in the FEC0::/10 range. IF that is the case, go ahead and just pick something in the range and use it while smiling to yourself because it is really deprecated.

IF you are asked to do unique-local addressing I would watch the wording of your lab. If it says something about you being “assigned” such and such range, I would opt for the centrally assigned range of FC00::/8. They may say something like “You have been ASSIGNED a global-id of ABCD:EF12:34. Use the middle two octets of your IPv4 subnet as your subnet ID.” Let’s say the middle two octets were 4.4 in your IPv4 address space. That would equate to something like FCAB:CDEF:1234:0404::/64. Because they said ASSIGNED I would assume we were using the FC00::/8 range. The next 40 bits (global-id) were given to you, and you derived the next 16 bits from your IPv4 address.

IF you are told to do unique-local addressing and they mention something about you assigning your global-id yourself, or having it randomly generated I would opt for the FD00::/8 locally assigned range. Maybe you would have a task similar to this: “You have decided to assign the unique-local global-id of BABA:CACA:12. Use the middle two octets of your IPv4 subnet as your subnet ID.” That would equate to something like FDBA:BACA:CA12:0404::/64. Because they said YOU assigned it to yourself or that it was “randomly generated” I would use the FD00::/8 range of addressing there.

Don’t you miss RFC 1918 now? :P

–
Joe Astorino
CCIE #24347 (R&S)

Print Friendly

Alright, that doesn’t look so bad does it? Well…not if you already have read my MPLS L3 VPN blog heh… So what we have going on here is a simple MPLS L3 VPN setup. We have a customer, we’ll call them “Customer A” and they have two remote sites connected together via the services provider MPLS cloud here. Additionally, they have a direct “backdoor link” configured between them for backup purposes. The PE/CE routing protocol of choice here is OSPF.

To start things off, let’s disable the backdoor links and just see how things work normally. Also notice we are running the SAME OSPF process-ID on both PE routers for the customer VRF and that both customer sites are running in area 0 on all links. All the MPLS and redistribution has already been done here.

R1:

R1(config-router)#int fa0/1
R1(config-if)#shut

R7:

R7(config-router)#int fa0/1
R7(config-if)#shut

R2:

R2#sh ip proto vrf CustA | i Routing Protocol
Routing Protocol is "ospf 2"
Routing Protocol is "bgp 55"

R4:

R4(config)#do sh ip proto vrf CustA | i Routing Protocol
Routing Protocol is "ospf 2"
Routing Protocol is "bgp 55"

OK. So what do our routes look like on R1 and R7?

R1:

R1#sh ip ospf neigh
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.12.2         1   FULL/BDR        00:00:38    10.0.12.2       FastEthernet0/0

R1#sh ip route ospf
7.0.0.0/32 is subnetted, 1 subnets
O IA    7.7.7.7 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
O IA    10.0.47.0/24 [110/2] via 10.0.12.2, 00:04:35, FastEthernet0/0
O IA    10.0.204.7/32 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0
O IA    10.0.201.7/32 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0
O IA    10.0.200.7/32 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0
O IA    10.0.203.7/32 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0
O IA    10.0.202.7/32 [110/3] via 10.0.12.2, 00:04:35, FastEthernet0/0

R7:

R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
O IA    10.0.12.0/24 [110/2] via 10.0.47.4, 00:04:25, FastEthernet0/0
O IA    10.0.104.1/32 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0
O IA    10.0.103.1/32 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0
O IA    10.0.102.1/32 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0
O IA    10.0.101.1/32 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0
O IA    10.0.100.1/32 [110/3] via 10.0.47.4, 00:04:25, FastEthernet0/0

Alright, wait a tick…the site-to-site routes are showing up as O IA INTER-area routes via type-3 summary LSAs. But…aren’t I in the same area, area 0? Well…”sort of” By default, if our OSPF domain-ID matches on both sides and we are transporting routes over MPLS we will get inter-area routes here. The domain-ID is the OSPF process ID by default, but can be changed. If they are not the same, we will see the routes come in as external O E2 routes. Let’s see that in action.

R4:

R4(config-router)#router ospf 2
R4(config-router)#domain-id 0.0.0.3

R7:

R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2    1.1.1.1 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
O E2    10.0.12.0/24 [110/1] via 10.0.47.4, 00:00:17, FastEthernet0/0
O E2    10.0.104.1/32 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0
O E2    10.0.103.1/32 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0
O E2    10.0.102.1/32 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0
O E2    10.0.101.1/32 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0
O E2    10.0.100.1/32 [110/2] via 10.0.47.4, 00:00:17, FastEthernet0/0

Wow, that is pretty cool! Let’s change it back now…

R4:

R4(config-router)#no domain-id 0.0.0.3

R7:

R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
O IA    10.0.12.0/24 [110/2] via 10.0.47.4, 00:00:54, FastEthernet0/0
O IA    10.0.104.1/32 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0
O IA    10.0.103.1/32 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0
O IA    10.0.102.1/32 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0
O IA    10.0.101.1/32 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0
O IA    10.0.100.1/32 [110/3] via 10.0.47.4, 00:00:54, FastEthernet0/0

Alright…well that is neat and pretty cool and all, but we still don’t know what a sham-link is at this point! Let’s bring up that backup link. Notice that right now the MPLS path is the ONLY path we know traffic through.

R1:

R1(config)#int fa0/1
R1(config-if)#no shut

R7:

R7(config-if)#int fa0/1
R7(config-if)#no shut
R7(config-if)#do sh ip ospf neigh
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.104.1        1   FULL/DR         00:00:36    10.0.17.1       FastEthernet0/1
10.0.47.4         1   FULL/BDR        00:00:36    10.0.47.4       FastEthernet0/0
R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
O       10.0.12.0/24 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
O       10.0.104.1/32 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
O       10.0.103.1/32 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
O       10.0.102.1/32 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
O       10.0.101.1/32 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1
O       10.0.100.1/32 [110/2] via 10.0.17.1, 00:00:26, FastEthernet0/1

Hmmm…interesting! When I brought up the backup link over VLAN 17, my routes completely changed. NOW my best path is an INTRA-area route via VLAN 17. Why? Well, OSPF always preferes intra-area routes to inter-area routes. Even if we tweaked our OSPF metric all day long to give precedence to the MPLS route, we are screwed at this point due to this rule. This is a rule of OSPF we can NOT change…but can we manipulate other things? What if we could make the routes coming in from the MPLS intra-area routes as well? Enter the sham-link. The sham link is essentially an OSPF virtual-link that goes through the service provider cloud to connect two areas together. So basically, we can create a special virtual-link between our PE routers called a sham-link that connects our two area 0’s together. The routes over the sham link will then be considered inter-area routes. Let’s do it! For this to work, we need to do a few things:

• A /32 loopback address on each PE router. This loopback has to be in the customer VRF and can NOT be directly advertised into OSPF.
• Advertise these loopbacks into MP-BGP as vpnv4 routes. This is how the PE routers will learn about the endpoints of the sham-link.
• Configure the sham-link under the OSPF process on the PE routers

R2:

R2(config)#int lo22
R2(config-if)#ip vrf forwarding CustA
R2(config-if)#ip add 22.22.22.22 255.255.255.255
R2(config-if)#router bgp 55
R2(config-router)#address-family ipv4 vrf CustA
R2(config-router-af)#network 22.22.22.22 mask 255.255.255.255
R2(config-router-af)#router ospf 2
R2(config-router)#area 0 sham-link 22.22.22.22 44.44.44.44

R4:

R4(config-router)#int lo44
R4(config-if)#ip vrf forwarding CustA
R4(config-if)#ip add 44.44.44.44 255.255.255.255
R4(config-if)#router bgp 55
R4(config-router)#address-family ipv4 vrf CustA
R4(config-router-af)#network 44.44.44.44 mask 255.255.255.255
R4(config-router-af)#router ospf 2
R4(config-router)#area 0 sham-link 44.44.44.44 22.22.22.22
R4(config-router)#do sh ip ospf neigh
Neighbor ID     Pri   State           Dead Time   Address         Interface
6.6.6.6           0   FULL/  -        00:01:35    100.100.100.6   Serial0/0/0
10.0.12.2         0   FULL/  -           -        22.22.22.22     OSPF_SL1
10.0.204.7        1   FULL/DR         00:00:31    10.0.47.7       FastEthernet0/0

Rock N’ Roll!!! Notice the sham-link came up! (OSPF_SL1) So, to recap we added a loopback on both ends. We advertised that loopback into MP-BGP in the CustA VRF. We then created a sham-link that connected our two area 0’s together. NOW, let’s see those routes.

R7:

R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
22.0.0.0/32 is subnetted, 1 subnets
O E2    22.22.22.22 [110/1] via 10.0.47.4, 00:04:23, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
O       10.0.12.0/24 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
O       10.0.104.1/32 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
O       10.0.103.1/32 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
O       10.0.102.1/32 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
O       10.0.101.1/32 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
O       10.0.100.1/32 [110/2] via 10.0.17.1, 00:12:20, FastEthernet0/1
44.0.0.0/32 is subnetted, 1 subnets
O E2    44.44.44.44 [110/1] via 10.0.47.4, 00:02:48, FastEthernet0/0

Boooooo, hisssssss, stink! We still have the same problem. Why? Well, despite the fact that we now have intra-area routes through the MPLS, the cost over the directly connected FastEthernet interface still beats us (darn FastEthernet cost of 1!!!) Oh well, this is easily fixed…

R1:

R1(config-if)#int fa0/1
R1(config-if)#ip ospf cost 10

R7:

R7(config-if)#int fa0/1
R7(config-if)#ip ospf cost 10
R7(config-if)#do sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
22.0.0.0/32 is subnetted, 1 subnets
O E2    22.22.22.22 [110/1] via 10.0.47.4, 00:06:32, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
O       10.0.12.0/24 [110/3] via 10.0.47.4, 00:00:19, FastEthernet0/0
O       10.0.104.1/32 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
O       10.0.103.1/32 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
O       10.0.102.1/32 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
O       10.0.101.1/32 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
O       10.0.100.1/32 [110/4] via 10.0.47.4, 00:00:19, FastEthernet0/0
44.0.0.0/32 is subnetted, 1 subnets
O E2    44.44.44.44 [110/1] via 10.0.47.4, 00:04:57, FastEthernet0/0

R1:

R1(config-if)#do sh ip route ospf

22.0.0.0/32 is subnetted, 1 subnets
O E2    22.22.22.22 [110/1] via 10.0.12.2, 00:07:38, FastEthernet0/0
7.0.0.0/32 is subnetted, 1 subnets
O       7.7.7.7 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 13 subnets, 2 masks
O       10.0.47.0/24 [110/3] via 10.0.12.2, 00:00:16, FastEthernet0/0
O       10.0.204.7/32 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
O       10.0.201.7/32 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
O       10.0.200.7/32 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
O       10.0.203.7/32 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
O       10.0.202.7/32 [110/4] via 10.0.12.2, 00:00:16, FastEthernet0/0
44.0.0.0/32 is subnetted, 1 subnets
O E2    44.44.44.44 [110/1] via 10.0.12.2, 00:05:43, FastEthernet0/0

Rock N’ Roll…Notice the best path is now via the MPLS and they are INTRA-Area routes! There is also an option when we create the sham-link to set the cost of the sham-link. In this case, it wouldn’t really help use since our total path cost out VLAN 17 is like 2 :P So there you have it…that’s not so bad now is it?

–
Joe Astorino
CCIE #24347 (R&S)

Print Friendly

MPPE is a protocol defined by RFC 3078 which provides a way to do encryption over PPP links. The protocol allows for two different types of encryption which differ on the size of the key. The two key sizes supported are 40-bit, and 128-bit and the encryption itself uses an RC4 cipher. The session keys themselves also change dynamically. Encryption of the PPP links is something that is negotiated by a lower level sub-protocol of PPP known as CCP (Compression Control Protocol) during NCP phase of PPP link negotiation.

OK, now that we have looked at the important protocol information with a 5 minute summary of the RFC let’s look at how to actually get this working in a Cisco environment! For our test bed, we will simply be looking at two routers on a standard proctorlabs rack — R2 and R5. R2 and R5 have a direct PPP link between them on interface s0/2/0.

One thing to be aware of before we look at the configuration is that in order to get MPPE working on a Cisco router you must already have configured and working authentication. Specifically, you must run MS-CHAP authentication. MS-CHAP is a microsoft-ized version of the popular CHAP authentication protocol. Let’s get started. For our example, we will simply do 1-way authentication to make things simple. R2 will be authenticating R5. We will use the hostname as the username and a password of “pants.”

R2:

username R5 password pants
!
interface Serial0/2/0
 ip address 25.25.25.2 255.255.255.0
 encapsulation ppp
 clock rate 2000000
 ppp encrypt mppe 128 required
 ppp authentication ms-chap

R5:

interface Serial0/2/0
 ip address 25.25.25.5 255.255.255.0
 encapsulation ppp
 ppp encrypt mppe 128
 ppp chap password 0 pants

Let’s take a look at some debug and show command output to verify our configuration. Notice that on R2 we have specified the required keyword. This means that R2 will require that the other side of the link use 128-bit encryption for the line to come up properly. We have configured 128-bit encryption on the remote end so we are good. Also notice that we use the usual “ppp chap password” command on R5 even though technically it is MS-CHAP. There is no “ppp ms-chap…” command.

Let’s take a look at a “debug ppp negotiation” on R5 when the interface comes up

R5(config-if)#no shut
 R5(config-if)#
*Apr  6 13:23:27.832: Se0/2/0 PPP: Outbound cdp packet dropped
*Apr  6 13:23:29.832: %LINK-3-UPDOWN: Interface Serial0/2/0, changed state to up
*Apr  6 13:23:29.832: Se0/2/0 LCP: I CONFREQ [Closed] id 252 len 15
*Apr  6 13:23:29.832: Se0/2/0 LCP:    AuthProto MS-CHAP (0x0305C22380)
*Apr  6 13:23:29.832: Se0/2/0 LCP:    MagicNumber 0x18180FB4 (0x050618180FB4)
*Apr  6 13:23:29.832: Se0/2/0 LCP LCP: Missed a Link-Up transition, starting PPP
*Apr  6 13:23:29.832: Se0/2/0 PPP: Using default call direction
*Apr  6 13:23:29.836: Se0/2/0 PPP: Treating connection as a dedicated line
*Apr  6 13:23:29.836: Se0/2/0 PPP: Session handle[C500011F] Session id[474]
*Apr  6 13:23:29.836: Se0/2/0 PPP: Phase is ESTABLISHING, Active Open
*Apr  6 13:23:29.836: Se0/2/0 LCP: O CONFREQ [Closed] id 234 len 10
*Apr  6 13:23:29.836: Se0/2/0 LCP:    MagicNumber 0x19046115 (0x050619046115)
*Apr  6 13:23:29.836: Se0/2/0 LCP: O CONFACK [REQsent] id 252 len 15
*Apr  6 13:23:29.836: Se0/2/0 LCP:    AuthProto MS-CHAP (0x0305C22380)
*Apr  6 13:23:29.836: Se0/2/0 LCP:    MagicNumber 0x18180FB4 (0x050618180FB4)
*Apr  6 13:23:29.836: Se0/2/0 LCP: I CONFACK [ACKsent] id 234 len 10
*Apr  6 13:23:29.836: Se0/2/0 LCP:    MagicNumber 0x19046115 (0x050619046115)
*Apr  6 13:23:29.836: Se0/2/0 LCP: State is Open
*Apr  6 13:23:29.836: Se0/2/0 PPP: Phase is AUTHENTICATING, by the peer
*Apr  6 13:23:29.836: Se0/2/0 MS-CHAP: I CHALLENGE id 218 len 21 from "R2      "
*Apr  6 13:23:29.852: Se0/2/0 MS CHAP: Using hostname from unknown source
*Apr  6 13:23:29.852: Se0/2/0 MS CHAP: Using password from interface CHAP
*Apr  6 13:23:29.852: Se0/2/0 MS-CHAP: O RESPONSE id 218 len 56 from "R5"
*Apr  6 13:23:29.860: Se0/2/0 MS-CHAP: I SUCCESS id 218 len 4
*Apr  6 13:23:29.860: Se0/2/0 PPP: Phase is FORWARDING, Attempting Forward
*Apr  6 13:23:29.860: Se0/2/0 PPP: Queue CCP code[1] id[1]
*Apr  6 13:23:29.860: Se0/2/0 PPP: Discarded CDPCP code[1] id[1]
*Apr  6 13:23:29.860: Se0/2/0 PPP: Queue IPCP code[1] id[1]
*Apr  6 13:23:29.864: Se0/2/0 PPP: Phase is ESTABLISHING, Finish LCP
*Apr  6 13:23:29.864: Se0/2/0 PPP: Phase is UP
*Apr  6 13:23:29.864: Se0/2/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Apr  6 13:23:29.864: Se0/2/0 IPCP:    Address 25.25.25.5 (0x030619191905)
*Apr  6 13:23:29.864: Se0/2/0 CCP: O CONFREQ [Closed] id 1 len 10
*Apr  6 13:23:29.864: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.864: Se0/2/0 CDPCP: O CONFREQ [Closed] id 1 len 4
*Apr  6 13:23:29.864: Se0/2/0 PPP: Process pending ncp packets
*Apr  6 13:23:29.864: Se0/2/0 IPCP: Redirect packet to Se0/2/0
*Apr  6 13:23:29.864: Se0/2/0 IPCP: I CONFREQ [REQsent] id 1 len 10
*Apr  6 13:23:29.864: Se0/2/0 IPCP:    Address 25.25.25.2 (0x030619191902)
*Apr  6 13:23:29.868: Se0/2/0 IPCP: O CONFACK [REQsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 IPCP:    Address 25.25.25.2 (0x030619191902)
*Apr  6 13:23:29.868: Se0/2/0 CCP: Redirect packet to Se0/2/0
*Apr  6 13:23:29.868: Se0/2/0 CCP: I CONFREQ [REQsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.868: Se0/2/0 CCP: O CONFACK [REQsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.868: Se0/2/0 CCP: I CONFACK [ACKsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.868: Se0/2/0 CCP: State is Open
*Apr  6 13:23:29.868: Se0/2/0 CDPCP: I CONFACK [REQsent] id 1 len 4
*Apr  6 13:23:29.868: Se0/2/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 IPCP:    Address 25.25.25.5 (0x030619191905)
*Apr  6 13:23:29.868: Se0/2/0 IPCP: State is Open
*Apr  6 13:23:29.872: Se0/2/0 IPCP: Install route to 25.25.25.2
*Apr  6 13:23:30.864: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2/0, changed state to up
*Apr  6 13:23:31.856: Se0/2/0 CDPCP: I CONFREQ [ACKrcvd] id 2 len 4
*Apr  6 13:23:31.856: Se0/2/0 CDPCP: O CONFACK [ACKrcvd] id 2 len 4
*Apr  6 13:23:31.856: Se0/2/0 CDPCP: State is Open
R5(config-if)#do no deb all

All possible debugging has been turned off

We can see from the above output exactly what we would expect — The LCP phase of PPP negotiation begins which moves us into authentication via MS-CHAP. We can see that R5 gets an inbound authentication request from R2. R5 responds appropriately with the MD5 hash and R2 lets us know the authentication was successful. After LCP and authentication we move into the NCP phase. During NCP, we can see that encryption is being negotiated via the CCP protocol. If encryption is successfully negotiated you will see that the CCP state goes to Open as it has here. So, let’s take a look at our link and test

R2#sh ip int brie | i 0/2/0
Serial0/2/0                25.25.25.2      YES manual up                    up

R2#ping 25.25.25.5 re 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 25.25.25.5, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms

R2#show ppp mppe serial0/2/0
Interface Serial0/2/0 (current connection)
Software encryption, 128 bit encryption, Stateless mode
packets encrypted = 100      packets decrypted  = 100
sent CCP resets   = 0        receive CCP resets = 0
next tx coherency = 100      next rx coherency  = 100
tx key changes    = 100      rx key changes     = 100
rx pkt dropped    = 0        rx out of order pkt= 0
rx missed packets = 0

We can see from the above output that we are indeed running 128-bit encryption and that all of our ping packets were encrypted! We can also see that the key seems to actually change every packet! That is about it for setting up basic MPPE on a Cisco router PPP link!!!

Joe Astorino CCIE #24347

Print Friendly

QoS Actions For Ingress Traffic

When traffic arrives on a switchport, there is a set of different QoS functions we have the ability to apply.
• Classification
• Policing
• Marking
• Queueing
• Scheduling

Most of these functions are specific for ingress traffic. A few of the options, namely queueing and scheduling, we can also do for egress traffic. One important thing to remember with the 3560 is that when we talk about queueing or scheduling, we could be talking about it from the perspective of inbound traffic (ingress) or outbound traffic (egress). The queueing and scheduling is very similar, but with ingress queueing we have two queues, whereas with egress queueing we have four. In both situations, one queue can be configured as a strict priority queue. In this article we will take a look at Classification, Policing and Marking. Additionally, we will look at egress Queueing and Scheduling.

Classification

The entire point of QoS is to give prefferential treatment to some packets that are deemed “more important” than other packets during times of congestion. If we want to do that, we need a way to figure out what packets are more important. That is the basis of classification. There are multiple different ways to do classification on the 3560, depending on what type of environment you are working in and what it is you are trying to accomplish. We may classify traffic at the interface level through a variety of methods we will discuss below, or at the VLAN level. If you choose to do classification at the VLAN level you will need the mls qos vlan-based command on interfaces that are part of the VLAN you want to do classification on. If we are talking about non-IP traffic we can classify based on trusting the incoming CoS values or based on MAC ACLs. Recall that CoS is a layer 2 thing, so it makes sense that we can classify non-IP traffic with CoS. CoS bits get set in the L2 header, and really have nothing to do with IP. With IP traffic however, we can classify based on trusting incoming CoS, DSCP, IP Precendence values or with L3 ACLs. This also makes sense if you recall that DSCP and IP Precedence are marked in the ToS byte of the IP header. If you attempt to trust DSCP or IP Precendence for non IP traffic, one of two things will happen: If the frame has a CoS value, it will be retained. If not, the default port CoS value will be used. If you choose to classify with ACLs instead of trusting QoS markings, ultimately you will be configuring an ACL, calling the ACL in a class-map, and calling the class-map from a policy-map which you will apply to the interface. You can also configure VLAN based classification by applying a policy-map that does classification and marking to an SVI. Generally speaking, if you choose to not trust anything, and you don’t have any ACLs configured, things will be marked down to best-effort. If a packet is unmarked when it arrives, it will be assigned the default CoS value assigned to the interface, which is 0. This of course, is something we can change with the mls qos cos command.

Understanding trust states as well as the internal mapping table logic of your 3560 switch is probably one of the most important things to know about. It is also one of the most important things to know how to manipulate.

First of all, in order to turn on QoS processing on the switch, we need to enable it with the mls qos command. Secondly, we need to understand our options. As stated previously, you can configure your switch ports to trust certain QoS markings, or not trust QoS markings. By default, nothing is trusted. To trust the markings you will use a variant of the mls qos trust command as shown below. The device option gives us the ability to essentially say “ONLY trust the incoming QoS markings IF the device connected to this port is a Cisco phone.” This allows us to trust an IP phone’s QoS markings for voice packets while also protecting against a user unplugging his PC from the phone and running his cable directly into the switch and getting priority treatment of all packets.

3560(config)#mls qos
3560(config)#int fa0/1
3560(config-if)#mls qos trust ?
cos            cos keyword
device         trusted device class
dscp           dscp keyword
ip-precedence  ip-precedence keyword

So far we have seen that when a frame arrives at the switch port we can either trust the markings or not trust the markings. If we don’t trust the markings or if there is no marking we will get a CoS value of 0 by default. However, if we DO decide to trust the markings, we move on to the next step — mappings. You see, the 3560 has a variety of internal mapping tables that decide what the final markings are going to be, which are based on the incoming markings. For example, we have CoS-To-DSCP,and DSCP-To-CoS among others. The idea is that when a frame comes in, the switch can look at the incoming QoS markings, and from those incoming markings derive a new QoS marking which will ultimately determine how that traffic gets queued. Let’s have a look at some examples.

3560#sh mls qos maps ?
cos-dscp       cos-dscp map keyword
cos-input-q    cos-input queue map keyword
cos-output-q   cos-output queue map keyword
dscp-cos       dscp-cos map keyword
dscp-input-q   dscp-input queue  map keyword
dscp-mutation  dscp-mutation map keyword
dscp-output-q  dscp-output queue map keyword
ip-prec-dscp   ip-prec-dscp map keyword
policed-dscp   policed-dscp map keyword
|              Output modifiers

3560#sh mls qos maps cos-dscp
Cos-dscp map:
cos:   0  1  2  3  4  5  6  7
--------------------------------
dscp:   0  8 16 24 32 40 48 56

3560#sh mls qos maps dscp-cos
Dscp-cos map:
d1 :  d2 0  1  2  3  4  5  6  7  8  9
---------------------------------------
0 :    00 00 00 00 00 00 00 00 01 01
1 :    01 01 01 01 01 01 02 02 02 02
2 :    02 02 02 02 03 03 03 03 03 03
3 :    03 03 04 04 04 04 04 04 04 04
4 :    05 05 05 05 05 05 05 05 06 06
5 :    06 06 06 06 06 06 07 07 07 07
6 :    07 07 07 07

3560#sh mls qos maps cos-output-q
Cos-outputq-threshold map:
cos:  0   1   2   3   4   5   6   7
------------------------------------
queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1

In the examples above we are looking at three different tables: Cos-To-DSCP and DSCP-To-Cos as well as the CoS to output queue mapping. The idea is this — A frame comes in with some QoS marking (Let’s call it CoS for now) that we happen to trust on the port. The switch then looks at the CoS-To-DSCP mapping and derives a DSCP value to give to the packet. The switch then consults the DSCP-To-CoS map to derive a new CoS value. Finally, based on that CoS value, it chooses an output queue. For example, we can see that CoS 2 gets marked with DSCP 16 and that DSCP 16 gets marked with CoS 2. Let’s say we are trusting CoS and a frame comes in with a CoS of 3. We see that the CoS-To-DSCP map will map CoS 3 to DSCP 24. The DSCP-To-CoS map is then consulted, and we see the CoS value will end up remaining at 3. Finally, we see that CoS 3 gets mapped to output queue #3 with a drop threshold of 1. Keep in mind that this is one particular example of one particular function. If we decided to trust DSCP or IPP instead of CoS, we would consult different tables but the general idea is the same. If we are trusting DSCP instead of CoS on the interface, we can let that DSCP value remain intact and pass through, or we can change it with a DSCP mutation map.

Understanding this process is important for a CCIE candidate. What is equally as important is to know how to modify these default mappings. The key thing to remember is “mls qos map”. From there you can do mostly anything. Let’s go back to our example. Let’s say we are trusting CoS and we want to make sure that incoming frames marked as CoS 3 get mapped to DSCP 28 instead of DSCP 24.

3560(config)#mls qos map cos-dscp ?
  CoS values separated by spaces (up to 8 values total)

3560(config)#mls qos map cos-dscp 0 8 16 28 32 40 48 56
3560(config)#do sh mls qos map cos-dscp
Cos-dscp map:
cos:   0  1  2  3  4  5  6  7
--------------------------------
dscp:   0  8 16 28 32 40 48 56

Now suppose that we need to make sure DSCP 28 gets marked back to CoS 5 so that it is sent to priority queue #1 outbound.

3560(config)#mls qos map dscp-cos ?
     DSCP values separated by spaces (up to 8 values total)

3560(config)#mls qos map dscp-cos 28 ?
     DSCP values separated by spaces (up to 8 values total)
    to      to keyword

3560(config)#mls qos map dscp-cos 28 to ?
     cos value
3560(config)#mls qos map dscp-cos 28 to 5
3560(config)#do sh mls qos map dscp-cos
Dscp-cos map:
d1 :  d2 0  1  2  3  4  5  6  7  8  9
---------------------------------------
0 :    00 00 00 00 00 00 00 00 01 01
1 :    01 01 01 01 01 01 02 02 02 02
2 :    02 02 02 02 03 03 03 03 05 03
3 :    03 03 04 04 04 04 04 04 04 04
4 :    05 05 05 05 05 05 05 05 06 06
5 :    06 06 06 06 06 06 07 07 07 07
6 :    07 07 07 07

If you wish to modify the default CoS/DSCP to output queue mappings you can use the mls qos srr-queue output command.

Policing And Marking

After arriving traffic has been classified, things can move on to the next step if necessary, which is policing and marking. Policing, much like on routers, is for rate-limiting the bandwidth of a particular type of traffic. On the 3560 switch, we can police on an individual interface, or even on an SVI by using hierarchical policies. When we police traffic, we set bandwidth limits on that traffic, and decide what to do about it if things are misbehaving. Namely, we can pass the traffic, drop the traffic, or mark down the QoS markings of the packets. This is all decided on a per-packet basis. After being policed, and potentially marked down THEN we can move into queueing.

One thing to understand about policing on the 3560 switch, is that it works a bit differently than other types of policing or shaping you may be familiar with. Particuarly, people seem to get hung up on why everything they learned about with regards to frame-relay traffic-shaping or shaping in general no longer applies here. Well, for one thing we are talking about policing traffic and not shaping it. Shaping implies some sort of queueing in order to shape the traffic to a given rate over time. Policing on the other hand does not queue traffic. The old well known formula for FRTS Tc = Bc/CIR is not really appropriate for policing on a 3560 switch. The policing IS done using a token bucket type algorithm, but it is much different than the token bucket algorithm used for FRTS. With FRTS things are based on how much data you can send per time slice (Tc). With 3560 policing there is really no concept of hard set time slices. The amount of data you can send at any given moment is more determined by time and the configured policed rate / burst size than anything else. Letting formulas used for traffic-shaping confuse you when doing policing is like comparing apples and oranges. If you don’t allow yourself to confuse the two different but similar technologies, you should be OK.

Policing Physical Ports

Once you decide to police a physical port as opposed to an SVI, you stil have options : ) You can police an individual port based on a policy linked to a single class of traffic, or you can police an individual port based on a policy that is linked to multiple classes (aggregate policer.) The individual port policer is pretty simple. The aggregate policer just allows you to police a SET of classes all together. For example, you can configure multiple class-maps and police the rate of the sum of all the class maps to a certain rate. Let’s have a look at the syntax for the policer on a 3560 switch. This is something you would apply inside a policy-map.

police rate-bps burst-byte [exceed-action {drop | policed-dscp-transmit}]

The rate specified in bits per second tells us what the average rate is that we wish to police to. This is not necessarily a hard limit because we also have the ability to configure a burst size. The burst size allows the policed traffic to temporarily burst above and beyond the average rate. Keep in mind that the average rate is in terms of bits per second while the burst is in bytes. Notice I didn’t say bytes per second. The burst value specified is essentially defining how DEEP the token bucket is. It has nothing to do with how many bits or bytes PER anything. It is simply the size of the bucket in bytes. This parameter works in conjunction with how fast the bucket leaks (the policed rate) to determine if a packet comforms or does not conform. If the traffic conforms, it is transmitted. If the packet does not conform, we can either drop it or mark down the QoS based on the policed-dscp map. Many people learning this technology tend to get hung up on what values to use for burst. Part of this stems from the idea that when we conigure policing on a router using CAR, we are often told to use the formula Bc = [(CIR / 8) * 1.5] for the Bc burst value (as we are told in the command reference as recommended values). There is no such recommendation for burst values on the 3560. In short, do what you are told in the lab. If you are not given a burst value, I would not recommend you stress too much about what values to put here.

Let’s look at an example of a typical port-based policer on the 3560. Let’s say we want to police FTP traffic on port 19 to an average rate of 20Mbps with a burst of 10KB. We would configure something like this:

ip access-list extended FTP-TRAFFIC
permit tcp any any range ftp-data ftp
!
class-map match-all FTP-TRAFFIC
match access-group name FTP-TRAFFIC
!
policy-map POLICE-FTP
class FTP-TRAFFIC
police 20000000 10000 exceed-action drop
!
interface FastEthernet0/19
service-policy input POLICE-FTP

Now, let’s take a look at an aggregate policer. The idea here is this — We have a policy-map that will match multiple classes of traffic. If the rate of all the classes COMBINED goes over a certain level, we do something about that. In this case, let’s say we are matching HTTP, Telnet, and SSH traffic and we don’t want all that traffic combined to exceed 10 Mb/s with a burst of 50KB on interface fa0/1

mls qos aggregate-police WEB-TELNET-SSH 10000000 50000 exceed-action drop
!
ip access-list extended HTTP-TRAFFIC
permit tcp any any eq 80
!
ip access-list extended TELNET-TRAFFIC
permit tcp any any eq 23
!
ip access-list extended SSH-TRAFFIC
permit tcp any any eq 22
!
!
class-map HTTP
match access-group HTTP-TRAFFIC
!
class-map TELNET
match access-group TELNET-TRAFFIC
!
class-map SSH
match access-group SSH-TRAFFIC
!
!
policy-map AGGREGATE-POLICER
class HTTP
police aggregate WEB-TELNET-SSH
!
class TELNET
police aggregate WEB-TELNET-SSH
!
class SSH
police aggregate WEB-TELNET-SSH
!
!
interface FastEthernet0/1
service-policy input AGGREGATE-POLICER

Policing On SVIs

Policing at the SVI level can be a little more confusing at first. The reason it is more confusing is because it requires hierarchical policies. You cannot apply a policy-map that does policing directly to an SVI. This is similar to how you cannot apply queueing on a router to an ethernet sub-interface. You must configure a more general VLAN based “parent” policy and then call your more specific interface based “child” policy from inside the parent VLAN policy. For example, let’s say we want to police HTTP traffic inbound to VLAN 80 to 1Mb with a 20KB burst size. The interfaces in VLAN 80 we want to apply this to are Fa0/1 – Fa0/5. It would look something like this

! Apply VLAN-Based QoS to participating ports
!
interface range FastEthernet0/1 - 5
mls qos vlan-based
!
ip access-list extended HTTP
permit tcp any any eq 80
permit tcp any eq 80 any
!
class-map HTTP
match access-group name HTTP
!
class-map POLICED-PORTS
match interface FastEthernet 0/1 - FastEthernet 0/5
!
! Child policy to police the interfaces of VLAN 80
!
policy-map INTERFACE-POLICY
class POLICED-PORTS
police 1000000 20000
!
! Parent policy to apply to VLAN 80 in general
!
policy-map VLAN-POLICY
class HTTP
service-policy INTERFACE-POLICY
!
interface vlan 80
service-policy input VLAN-POLICY

Marking

The good news is that at this point, marking has really already been discussed. Marking can be done in a few ways. We have already seen how traffic can be marked through the classification process. If we trust markings on the port then incoming marked traffic can be re-marked either through the internal switch mappings, passed through in the case of DSCP, or remarked through a policy. If we don’t trust markings, we can still re-mark the traffic with a policy, or allow it to be marked down as best effort. If the traffic is not marked in the first place, we can choose to mark it ourselves, or assign it the default interface CoS.

Queueing And Scheduling

As I mentioned earlier, the 3560 has two input queues per interface with queue 2 being the default priority queue. The 3560 also has four output queues per interface, with queue 1 being the priority queue. The priority queue is not something that happens automagically, and must be enabled. To enable the input prioriity queue you will use the global command mls qos srr-queue input priority-queue. To enable the output priority queue you will use the interface level command priority-queue out.

When we are talking about Queueing on the 3560 there is a concept known as WTD or weighted tail drop that applies to both input and output queues. To put it simply, each queue has three different drop thresholds that correspond to different CoS values. Frames that are “less important” than others can be configured to be dropped at lower levels of congestion than “more important” frames. For example, maybe CoS values 5,6 and 7 are considered very important in your network, but CoS 1-4 are less important. Your WTD configuration would probably have CoS 1-4 mapped to the thresholds that get dropped sooner than CoS 5-7. Maybe CoS 1-4 gets dropped at 60% congestion, whereas CoS 5-7 only gets dropped when it absolutely HAS to at 100% congestion. In the grand scheme of things for routing and switching I would say understand the basic concept and know where to find the information if you have to.

Now, when we talk about how the queues actually get serviced and how much they get serviced (who gets better treatment by getting more attention), we are getting into SRR or shaped round robin. This happens again for both input and output queues. We will focus on egress queueing here. As usual, there are multiple options. Namely, we have shaped mode and shared mode. In short, with shaped mode each queue is guaranteed a certain amount of bandwidth, but also policed to that level. If the other queues are not filled, the extra bandwidth is not utilized. With shared mode as the name implies, the bandwidth among the queues is shared according to configured weights, but is not policed. There is a significant difference in understanding the syntax between the two modes.

With shaped mode we have the following interface command:

srr-queue bandwidth shape

In this case the weight values are talking about a specific amount of bandwidth guaranteed for that queue. Weight 1 is for queue 1, weight 2 for queue 2 , etc…The numbers that you enter are the denominator portion of a fraction. For example:

srr-queue bandwidth shape 4 4 4 4
srr-queue bandwidth shape 8 0 0 0

First of all, these are two different examples. In the first line, we are saying “each queue will get 1/4 of the bandwidth of this interface guaranteed.” In the second example, we are saying “Queue 1 will get 1/8 of the bandwidth guaranteed, and all other queues operate in shared mode”. When we use the 0 for the other three queues we tell them to operate in shared mode. So in the case of the second example, queues 2-4 would shared the remaining 87.5% equally.

With shared mode we have the following command:

srr-queue bandwidth share

In the case of shared mode, the numbers have different meanings. Now we are looking at a ratio or how the queues relate to each other. The values themselves have no real meaning. The only thing that matters in shared mode is the ratio of the queues. For example, the following three lines accomplish the exact same thing — They each would allocate 25% of the interface bandwidth to each queue because the ratio between the queues is 1:1.

srr-queue bandwidth share 1 1 1 1
srr-queue bandwidth share 25 25 25 25
srr-queue bandwidth share 100 100 100 100

Let’s try something a bit diferent:

srr-queue bandwidth share 10 20 30 40

With the last example, queue 4 gets 4x as much bandwidth as queue 1 because it has a ratio of 4:1 with queue 1. Queue 4 gets twice as much bandwidth as queue 2, and 1 1/3x bandwidth as queue 3.

Hopefully, this article has been of help to everbody out there learning QoS on the Catalyst 3560. I hope that his has given you some valuable insite into the many different options and capabilities of this switch. As you can see, the 3560 is a very powerful device! As always, I would highly recommend and encourage you guys to do more research, labbing and reading on your own to master this topic. The place to go is the 3560 software configuration guide on the DocCD which you can find here:

http://www.cisco.com/en/US/products/hw/switches/ps5528/products_installation_and_configuration_guides_list.html

Best regards and keep studying hard!!!
Joe Astorino – CCIE #24347

Print Friendly

Unfortunately, sometimes people neglect the information in the structured learning approach and dive in wherever they can. Oftentimes, this can be more detrimental to your success than it is helpful. Over the last 10+ years, we have developed a system that works in developing prepared CCIE candidates. When you stray from the system that is proven to work, you are taking a gamble. Some might argue that the CCIE is about thinking outside the box, and I would agree with them. However, why force yourself “against the grain” and make your journey to the holy digits harder than it has to be? We have already done all that hard work for you. Think of the structured learning approach as part of the reason you pay for the services of a company like IPexpert in the first place. Experience is important for a reason. This blog is going to focus on how you as an IPexpert student can fully utilize our program and get on the right path to becoming a CCIE.

Becoming a CCIE through the mentoring, concepts and approach of IPexpert is a very structured process that requires you as a student to fully understand to be successful. Follow the path, and you have a great shot at joining the ranks of the networking industry elite. Stray from the path, and you could be banging your head against the wall for years before you eventually pass, or just plain give up out of frustration. What I want to do is explain to you guys how to avoid the frustration by following our proven structured learning approach.

Step 1: Understand Advanced Theory & Concepts (After Passing The Written)

This is definitely one of the most important steps in your overall success. All too often, people pass the written examination and bang…they are off to dive into complex, multiprotocol mock labs. “If I do 25 mock labs I should be OK” people say. Another common mistake is to think “I passed the written, I must know the technology…I don’t need any more book theory.” Nothing could be further from the truth. The CCIE written exam and the CCIE lab exam are totally different beasts. In the IPexpert structured learning approach, the core knowledge, theory and concepts will come in the form of our industry leading CCIE R&S Video on Demand course. With the video on demand, you are going to come along with me, CCIE #24347 and go DEEP with technology. Through over 45 hours of lecture mixed with real hands on CCIE level configuration scenarios you are not only going to cement the core knowledge you learned for the written exam, but you are going to actually get your hands dirty as well through configurations. You really cannot expect yourself to jump into configuring labs without having a solid foundation. We don’t believe in building on a weak foundation. This is one of the biggest mistakes people make. Don’t cheat yourself — Start your preparation off right with the video on demand.

Step 2: Begin Technology-Focused, Targeted Learning

Once you have the core theory and concepts down, you need to start actually applying that knowledge. At this point, you already have seen CCIE level scenarios from the video on demand, but now you will go a step further and be doing it yourself. The *most* important part about this step, is that the labs are specific to individual technologies. In other words, you will do a lab on each individual technology by itself. No mixing and matching. Why is this so important? You cannot be expected to figure out how 25 different things are working together in a complex environment if you do not already understand each individual piece. This is how you get the advanced knowledge necessary to do that.

The ideal piece of the puzzle for you at this point is the IPexpert’s CCIE R&S Workbook Volume 1 technology focused workbook mixed together with the IPexpert’s CCIE R&S Volume 1 Walk-Through Video Tutorials. Fortunately, if you purchase the IPexpert’s CCIE R&S Blended Learning Solution, you get both those products. IPexpert’s CCIE R&S 4.0 Volume 1 Workbook will take you through 34 technology specific labs and the accompanying Detailed Solution Guide. If that is still not enough, watch as I take you right through the configurations and thought process in the IPexpert CCIE R&S Volume 1 Walk-Through Video Tutorial. At this point you have core theory down, and once you complete volume 1 you will have the knowledge necessary to continue. Do not cheat yourself by skipping volume 1 because you have extensive experience in the industry. The CCIE lab has nothing to do with best practices in the industry. The CCIE lab, the environment, and the structure of the questions are unlike anything you have probably done before. This will help prepare you for that.

Step 3: Reinforce Theory & Advanced Knowledge

Once you have the fundamental knowledge down, and you have gotten through the challenging volume 1 labs, it is time to move on to the IPexpert CCIE R&S Audio on Demand lecture series. This is a brand new product unlike anything else available in the industry today. For one, it is a completely different course than the video on demand. Secondly, it was designed purposely to cover different aspects, angles, scenarios, and extra “tips and tricks” for the CCIE candidate. Some of the stuff in the audio on demand series, you will not find in any vendor workbook, video or textbook because some things you just pick up from experience. Fortunately, we’ve taken all that expertise and experience and put it into audio format you can take with you anywhere. Finally, the audio on demand is coming at you from the perspective of a dual CCIE that has actually passed the newest v4.0 blueprint himself! Listen as Marko Milivojevic (CCIE #18427) takes you through each and every blueprint topic, with a focus on some specifics not considered core theory and knowledge as well as more “tips and tricks” to success. These audio lectures are directly downloadable from your members account, and available as part of the CCIE R&S Blended Learning Solution!

Step 4: Begin Multiprotocol Exercises

As I said earlier, many people feel they need to start at step #4. These are often the people that come back for 2nd, 3rd, 4th, and 5th attempts at the lab : ) The reason is simple — they didn’t follow the path. When you stray from the proven path to success, you will inevitably run into struggles. This is really not designed to be a sales letter, but really — There is a reason the program has worked for 10 years. There is a reason we have trained more CCIEs than anybody in the world. Stick to the plan!

Now, IPexpert’s CCIE R&S 4.0 Volume 2 Workbook with Detailed Solution Guide multi-protocol labs are where we get to the real meat and potatoes of becoming prepared to take the lab exam. These are CCIE level, full mock labs that will challenge you with all the different technologies and protocols you learned about in volume 1, but now all stuck together in one big nasty lab environment, just like the real deal. : ) This is where you will really cut your teeth and gain invaluable real world experience, which is probably the most important piece of becoming a CCIE. You cannot pass the CCIE by reading books alone. You must get in there and get your hands dirty. IPexpert’s CCIE R&S 4.0 Volume 2 workbook is where that is going to happen for you.

If you need equipment, my recommendation is to utilize our racks. Check out proctorlabs.com and you will not be disappointed. If you want to build your own rack, by all means do it. Just realize, you will spend a LOT of time, energy, and money guaranteed. The reason is that you will have to put together a topology that mimics the topology of the labs you are working on. To put together an exact replica of our lab is doable; it is just tedious and expensive. In addition, if all your interface numbers don’t match exactly, you end up having to modify startup-configurations for every lab which wasted about 30 minutes of your time every single lab. When I studied for my CCIE, I built my own rack. It was great to have, but in retrospect I spent way more $$$, invested way more time, and spent much too long modifying configs than it was worth. Once you complete the volume 2 and volume 3 workbooks you are getting very, very close to being prepared.

Step 5: Reinforce Advanced Knowledge

Once you are in the position where you think you are ready for the exam, you need to take it one step further. When you go through something as technical and lengthy as CCIE prep, and you do it all “on demand” and through self study, inevitably some things are going to happen. You forget things. Secondly, you have questions. While we do our best to deliver the best possible training experience, it is impossible to anticipate every single answer to every person’s questions through video and audio. Additionally, you want to reinforce and validate that the knowledge you have floating around up in your head is actually correct, and that you are ready to rock the lab. Step 5 is to attend one of IPexpert’s industry leading CCIE R&S 5 day ILT boot camps. These IPexpert boot camps are intense, 5 day courses designed to do exactly what I have just said. My boot camps usually have you putting in 60-80 hours of hardcore CCIE preparation within a 5 day period. We cover every technology on the blueprint from a lecture standpoint, as well as challenge you with more hands on lab work. With the lecture in a live environment, you obviously have the ability to ask many more specific questions, and to fill in gaps in your knowledge base. The ILT is designed to be all about filling in holes, one on one time with a world class CCIE instructor, and more hands on practice.

Let me tell you a little bit about what the ILT is not about. The reason I write about this is because this is hands down the biggest mistake our clients make!!!!! I teach a lot of boot camps and a large percentage of people we see coming to ILT have absolutely no previous experience doing CCIE level labs. They have no experience doing technology specific labs. They have no idea what our video on demand is. In other words, they are starting their preparation by coming to the ILT — at step #5 in the process. The vast majority of people that make the choice to skip steps 1 – 4 in the proven time tested approach are the ones that typically are lost during class, and do not get out of the class what it is designed to give them. They have no chance of completing their boot camp lab work because they do not have the prerequisite skills necessary to do so.

Remember, when you come to ILT we expect that you have followed steps 1-4. When you choose to ignore the first four steps, you are really doing yourself a disservice. Please, do the video on demand, do your volume 1, do your volume 2 mock labs, put in your blood sweat and tears and THEN come and see us so we can answer the questions that came up through all of it and make you BETTER.

Step 6: Polish Advanced Knowledge & Troubleshooting Skills

Everything you have done so far builds up to this point — the IPexpert CCIE R&S 4.0 Volume 3 mock lab workbook with Detailed Solution Guide. This is the most comprehensive, advanced and challenging mock lab workbook we offer. The nice thing about volume 3 is that it is has been redesigned from the ground up to cover you guys for CCIE R&S v4.0. That means our current team went through and personally took care of volume 3 to make sure it is the most current, up to date, and relevant material you need to pass. The exam structure is also taken directly from Cisco — 2 hour troubleshooting section followed by 6 hours of configuration on a separate topology! Our mock labs are designed to be harder than the real lab. The volume 3 labs are going to take all that fundamental core knowledge you learned in the IPexpert’s Video On Demand (VoD) and IPexpert’s Audio On Demand (AoD), the experience and knowledge you gained from the volume 1 and volume 2 labs, the information you took out of the ILT and put it all together to challenge you in a way that is going to prepare you to sit the real lab. Additionally, much like volume 1 you have the opportunity to watch an instructor do the lab via the IPexpert CCIE R&S Volume 3 Walk-Through Video Tutorial. Yes, you can watch as I or Marko painstakingly take you through FULL mock labs one single task at a time.  This includes the troubleshooting section as well as the configuration section! This is also part of of the blended learning solution!

Step 7: Practice Taking The REAL Lab

Finally, step 7 is going to be the IPexpert CCIE R&S One-Week-Lab Experience Boot Camp. Before you decide to come to OWLE, please understand what it is designed to do. This is the LAST step in your process before going to face the rigorous CCIE lab exam! This course is NOT designed for you until you have completed all the prerequisite material.

The worst experience for you will be coming to an OWLE and having to leave the class, or be so far buried that you get nothing out of it because you lack the understanding and speed to do anything useful. You build understanding, speed and efficiency through Steps 1 – 6 of course. The OWLE is designed to put everything to the test in a one week experience that has you doing a CCIE like mock lab all day, all week long mixed with feedback, questions, and one on one time with a real CCIE. You will put all your knowledge to the test and see if you are truly ready to sit the CCIE lab exam.

Our OWLE mock labs are going to put you in an environment similar to the real lab. You will have 2 hours of troubleshooting, 6 hours of configuration, and we will treat you as you would be treated taking the real test. That means your instructor is not there to white board and teach while you take the lab. The instructor is not there to hold your hand and baby you through the steps — That has already been accomplished in steps 1 – 6 : ) The instructor will be there to act as a proctor, and to answer questions as a proctor would do so.

Now, with that being said there is also time allotted for re-learning, cementing concepts, and getting last minute help, tips and instruction before your big day. That is also part of the OWLE as a whole. If you can get to step 7 and you can do fairly well on our OWLE labs (which are also designed to be much harder than the real thing) we at IPexpert feel that you have a great chance of passing your lab and becoming a CCIE!

Joe Astorino – CCIE #24347

Sr. Technical Instructor – IPexpert

Print Friendly

OK, so what is dampening first of all? Dampening is used to suppress routing updates when an interface is flapping. IP Event dampening can be used in conjunction with most all IGPs and even BGP. Basically, you are saying “if this route flaps too many times in a given period of time, I am going to stop advertising it into my routing protocol for a while until it cools off.” Everytime an interface configured with dampening goes from the up state to the down state, a penalty is assessed of 1000 “points.” This is not something you can change. However there are other values to review, some of which we do have control over.

Default Penalty: 1000 points

– This is the penalty that gets assessed to the interface when it flaps. We cannot control this

Suppression Value

– This is the # of points at which we start dampening and it is controllable directly by us. Default is 2000

Re-Use Value

– This is the # of points at which we will stop dampening and return back to normal. This is controllable directly by us. Default is 1000

Half-Life

– This is the amount of time it will take for a penalty to decrease by half. For example, if I have been assessed 3000 points in penalties and I have a half-life of 15 seconds, then in 15 seconds my penalty will have decayed to 1500 points. This is directly controllable by us as well. Default is 5 seconds.

Maximum Suppression Value

– This is the maximum amount of penalties we can assess to the interface. We can control this but not directly. Default is 20,000

Maximum Suppression Time

– This is the maxium amount of time an interface can be dampened. We can control this directly, and it is directly mathematically related to the re-use value and half-life.

The problem many people run into with dampening is the mathematics and ways tasks are worded. You see, the way these penalties decay is exponential, which can make it confusing to full grasp what is going on sometimes. Remember chemistry in high school? Then you probably remember exponential growth and exponential decay of elements and chemicals. Same exact concept.

Let’s take a look at an example.Let’s say you have configured dampening for whatever values, and your interface flaps. The router assesses a penalty of 1000 to the interface. Now, IMMEDIATELY, this 1000 point penalty starts exponentially decaying. That means that the very next second, it is not a 1000 point penalty anymore! The next second, it is a bit lower…the next second lower!!! So on and so forth. So how can you predict these values. Well there is the easy way and the hard way. The hard way involves a lot of very involved math ranging all the way into some pretty harry calculus. The easy way is much more manageable and is doable by anybody that took 7th grade math : )

So here it is, the forumula to remember:

Current Penalty = N * (0.5 ^ x) where N is the orignal penalty and x is the number of half lifes.

Let us look at that same example. Say the interface has assessed that 1000 point penalty, and we are using the default 5 second half-life. Let’s look at things

Time           Penalty
——-          ——-

0s                1000
5s                1000 * (0.5 ^ 1) = 500
10s             1000 * (0.5 ^ 2) = 250
15s             1000 * (0.5 ^ 3) = 125
… …

OK, those are some pretty simple values to show how it works. What if we wanted to know where the penalty was after say 8 seconds? Plug it in. 8 seconds is how many half lifes? 8/5 = 1.6 x 5 second half lifes so

Time           Penalty
——           ——-

8s               1000 * (0.5 ^ 1.6) = @330

Makes sense don’t it? More decayed than after 1 half life but less decayed than after 2.

Real World Example

OK, all this math is all well and good, but let’s look at an actual real life example and look at a real world example of how things could be worded in the CCIE lab! Assume we have a FastEthernet link between R5 and R9 running RIP and we are given the following task requirements:

IP event dampening will suppress the routes on an interface that is flapping from being advertised into supported routing protocols. The penalty assigned for an interface transitioning from UP –> DOWN is 1000. As soon as the penalty is assigned, it immediately begins decaying exponentially. At the half-life time the penalty will be exactly have of it’s original value. Once the penalty decays to the re-use value, it is unsuppressed.

With that in mind, if the interface flaps 3 times in 30 seconds, and we make the half-life 30 seconds then we know that after the first flap we are at 1000. At the second flap we can’t be any less than 500 at the time of the flap and any more than 1000 so it has to be between 500 and 1000 when the second flap occurs. Another 1000 point penalty is assessed and now we are somewhere between 1500 and 2000. Now we know when we flap again we can’t have decayed any lower than 1500 and we can’t be anywhere higher than 2000. Another 1000 points is assessed putting us between 2500 and 3000. This is a bit of a gap, but we know what we need to know!

We know that 3 flaps will definitely put us over 2500 so let’s make 2500 the suppress value. We want it to be suppressed for between 90 and 100 seconds if all is well after the 3 flaps. Think in terms of half-life. 90 seconds would be 3 half-lifes of 30 seconds. 100 seconds would be about 3.33 half lifes.

We know the penalty after 3 flaps is going to be somewhere between 2500 and 3000. If the penalty was 2500 we would decay to 313 after 3 half-lifes. If the penalty was 3000 on the high end we would decay to 375 in 90 seconds. Let’s take the lower value of 313 and go with that for the re-use value. Basically if we have the lowest possible penalty value after 3 flaps, we will re-use the prefixes after 90 seconds. If we have the highest possible penalty value of 3000 after 3 flaps it will take a few seconds longer to decay down to 313.

Now, the task said specifically “if it flaps 3 times”. What if it flaps 4 times, 5 times, 6 times, 7 times? Well it doesn’t specify, but it does tell us we should not let anything be suppressed for more than 2:59. That would be the max-suppress time. In terms of seconds that is 179 seconds.

We will blow out any logs on the router, turn on debugging for dampening, and make sure we have plenty of room in the logging buffer to catch what we need.

R5

interface fa0/0
dampening 30 313 2500 179

R5#clear log
Clear logging buffer

R5#debug dampening all
Dampening all debugging is on.

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#logging buffer 1000000

OK….Now, bounce our interface 3x within 30 seconds. I will spare you all the un-neccessary log messages:

R5(config-if)#do sh log | i Interface FastEthernet0/0, changed state to down|accum|charge

*** FIRST FLAP ***

Apr 16 12:24:04.351: EvD(FastEthernet0/0): charge penalty 1000, new accum. penalty 1000, flap count 10
Apr 16 12:24:04.351: EvD(FastEthernet0/0): accum. penalty 1000, not suppressed
Apr 16 12:24:07.342: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

*** SECOND FLAP ***

Apr 16 12:24:09.986: EvD(FastEthernet0/0): accum. penalty decayed to 890 after 5 second(s)
Apr 16 12:24:09.986: EvD(FastEthernet0/0): charge penalty 1000, new accum. penalty 1890, flap count 11
Apr 16 12:24:09.986: EvD(FastEthernet0/0): accum. penalty 1890, not suppressed
Apr 16 12:24:12.982: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

***THIRD FLAP***

Apr 16 12:24:17.077: EvD(FastEthernet0/0): accum. penalty decayed to 1607 after 7 second(s)
Apr 16 12:24:17.077: EvD(FastEthernet0/0): charge penalty 1000, new accum. penalty 2607, flap count 12
Apr 16 12:24:17.077: EvD(FastEthernet0/0): accum. penalty 2607, now suppressed with a reuse intervals of 92
Apr 16 12:24:20.073: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

***UNUPPRESSED AFTER 93 SECONDS***

Apr 16 12:25:49.069: IF-EvD: unsuppress interfaces
Apr 16 12:25:50.069: IF-EvD: unsuppress interfaces
Apr 16 12:25:50.069: EvD(FastEthernet0/0): accum. penalty decayed to 303 after 93 second(s)
Apr 16 12:25:50.069: EvD(FastEthernet0/0): accum. penalty 303, now unsuppressed

We see that our interface flapped 3 times in roughly about 14 seconds. After the 3rd flap, dampening kicked in. By that time we had accrued a penalty of 2607 which is higher than our suppress value. The 2607 point penalty started decaying immediately. It took 93 seconds to exponentially decay to the re-use value of 313

Hopefully, this will help some people out there in understanding BGP dampening, IP Event Dampening, and exponential decay in general!!!

Joe Astorino – CCIE #24347

Print Friendly

This blog will not be for the beginner or the faint of heart. A general knowledge of STP and the STP algorithm is assumed. In today’s blog, we will be running PVSTP+ and we will only be running VLAN 1 across all trunks in order to simplify things a bit. To get things started, let’s take a look at the L2 switching diagram we will be playing with in the lab this morning.

Before we get into the more specific and complicated aspects of STP, lets first have a quick review of how we got to the above state in the first place:

Quick review of the STP algorithm

1) There is a root bridge election. Basically, all the switches think they are the root bridge. By receiving superior BPDUs from other switches they all eventually agree on who is the root bridge. The root bridge is the bridge with the lowest BID. A BID is a priority appended to a MAC address. In this case Cat2 is the root bridge because we have manually given it the lowest priority. We can see this here:

Cat2#sh span vlan 1
VLAN0001
Spanning tree enabled protocol ieee
Root ID    Priority    24577
Address     001b.d4c7.f680
This bridge is the root
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
Bridge ID  Priority    24577  (priority 24576 sys-id-ext 1)
Address     001b.d4c7.f680
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
Aging Time 300
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- -----------------------------
Fa0/21              Desg FWD 19        128.23   P2p
Fa0/23              Desg FWD 19        128.25   P2p

2) Each Non-Root bridge elects a root-port (RP) which is the port on that switch with the lowest cost path to the root bridge. In the event of a tie, they will go with lowest sending BID, and finally lowest port-priority

3) On each segment, a designated port (DP) is elected. The DP is the port on that particular segment with the lowest cost path to the root bridge. The DP has the responsibility of sending BPDUs on to the segment.

4) At the end of all this, if a port is not a RP or a DP, it is put into the blocking state. In this case, we see Fa0/23 on Cat3 goes into the blocking state to prevent an L2 loop from occurring

STP Timers & States

Again, before we get into the more complex topics, it is important to understand some of the basics. In regular old STP we have a few timers that are important to understand, as well as a few different states our ports can be in. The important timers are as follows:

STP Timers

Hello Timer – This is how often the root bridge will send out BPDUs. These BPDUs get relayed down the spanning-tree to all the other switches. The default is 2 seconds.

Max Age Timer – This is how often a bridge will actually save the BPDU information it receives from other switches. Think of it as sort of a hold timer. The default is 20 seconds, and it helps prevent against loops in the event of indirect link failures.

Forward-Delay — This determines how long a switch will spend in each of the listening and learning states of STP. The default is 15 seconds, which means that out of the box we spend 15 seconds in listening and 15 seconds in learning.

The different states of STP are as follows:

STP States

Blocking — In the blocking state the port is essentially shut down. The switch discards frames received on the interface. It will receive BPDUs from the DP on the segment but will not pass them along to other switches. The important thing to note, and that we will see in this blog through actual logs is that the blocking state is not something that a port goes into every single time it comes up. A switch will go through the blocking state when it is first initialized (boots up) and it will place ports that could cause L2 loops into blocking when necessary. This does not mean that every single time you plug a device into the switch that the port goes into blocking before going to listening and learning. As we will see later, the blocking state is typically only seen during indirect link failures.

Listening — In listening state the port is starting to transition into doing something. In this state, the switch will actually process the BPDUs it receives on the port although we are still discarding frames at this point. Note that per the RFC Listening and Learning MUST be the same amount of time. There is no way to tweak one or the other. If you change one, you change the other.

Learning — In the learning state the port continues it’s transition by learning MAC addresses on the port, continuing to receive and process BPDUs, and transmitting BPDUs on to neighboring switches. Note that per the RFC Listening and Learning MUST be the same amount of time. There is no way to tweak one or the other. If you change one, you change the other.

Forwarding — In the forwarding state the port is up and running. At this point the port actually forwards frames and continues to monitor BPDUs

Disabled — This isn’t really a state of STP. This means STP is essentially turned off.

Bringing A Port Online Initially

Alright, now that we have covered the basics, lets get into our first hands on example. We are simply going to fire up the switchport on Cat1 that connects to R1 Fa0/0. In this case, R1 will be simulating a client plugging into the network. We will observe how spannting-tree reacts and show that when a device is first plugged into the network, the time it will take to reach forwarding state is actually 30 seconds. Some people and books will tell you it is 50 seconds, but what they are missing is the fact that the port will never go through the blocking state of STP. Let’s take a look.

Cat1#sh int status | i Fa0/1
Fa0/1                      disabled     1            auto   auto 10/100BaseTX
Cat1#debug spanning-tree events
Spanning Tree event debugging is on
Cat1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cat1(config)#int fa0/1
Cat1(config-if)#no shutdown
Feb 19 08:16:04.023: set portid: VLAN0001 Fa0/1: new port id 8001
Feb 19 08:16:04.023: STP: VLAN0001 Fa0/1 -> listening
Feb 19 08:16:19.023: STP: VLAN0001 Fa0/1 -> learning
Feb 19 08:16:34.023: STP: VLAN0001 sent Topology Change Notice on Fa0/23
Feb 19 08:16:34.023: STP: VLAN0001 Fa0/1 -> forwarding

OK, let’s break it down! As you can see, immediately upon enabling the interface, the port when directly into the listening state. There is no blocking state happening here in any way, shape or form. Do not pass go. Do not collect $200. Note the time stamp of when the port went into listening state. Exactly 15 seconds later (the default forward-delay) it enters the learning state. Exactly 15 seconds after that, the port goes forwarding. Total time from plugged in to forwarding frames: 30 seconds. So what does this tell us? If you are presented with a question in your lab regarding the time it takes for a PC to start forwarding frames, do not bother playing with the max-age timer. It won’t help us here. The only things we can really do would be enable portfast (it would then transition directly to forwarding) or change the forward-delay timer.

Convergence After Indirect Link Failure

Now we are going to take a look at what happens specifically to our topology during an indirect link failure. During an indirect link failure, one of the switches will likely have to deal with the max-age timer to expire (blocking state), as well as waiting 2x the forward delay. Therefore, an indirect link failure will yield a convergence time of about 50 seconds right out of the box (20 seconds max-age + 2x forward-delay). To demonstrate this, we will shutdown the link between Cat1 and Cat2. This will be an example of an indirect link failure from the perspective of Cat3 and a direct link failure from the perspective of Cat1. We will take a look at both Cat1 and Cat3 during this convergence period. For an explanation of the comments, check out the next paragraph.

Cat1:

Cat1#debug spanning-tree events
Spanning Tree event debugging is on
Cat1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cat1(config)#int fa0/23
Cat1(config-if)#shutdown

Cat1 lost it’s root-port and has no idea who the root bridge is. Therefore, Cat1 advertises ITSELF as the root bridge out fa0/21 towards Cat3 IMMEDIATELY.

Feb 19 08:27:31.528: STP: VLAN0001 we are the spanning tree root

After max-age expires over on Cat3, Cat3 transitions Fa0/23 into listening mode which means it now forwards BPDUs from the path Cat2 –> Cat4 –> Cat3 over to Cat1. Cat1 realizes it is not the real root bridge and submits to Cat2 being the real root!

Feb 19 08:27:49.528: STP: VLAN0001 heard root 24577-001b.d4c7.f680 on Fa0/21
Feb 19 08:27:49.528:     supersedes 32769-000b.bef0.6080
Feb 19 08:27:49.528: STP: VLAN0001 new root is 24577, 001b.d4c7.f680 on port Fa0/21, cost 57
Feb 19 08:27:49.528: STP: VLAN0001 sent Topology Change Notice on Fa0/21

Cat3:

As soon as the Cat1/Cat2 link goes down Cat3 starts receiving inferior BPDUs from Cat1 who is now claiming to be the root bridge. We will ignore these claims completely until the max-age timer expires.

Feb 19 08:27:31.530: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21
Feb 19 08:27:33.526: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21
Feb 19 08:27:35.531: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21
Feb 19 08:27:37.528: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21
Feb 19 08:27:39.524: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21
Feb 19 08:27:41.529: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21
Feb 19 08:27:43.525: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21
Feb 19 08:27:45.530: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21
Feb 19 08:27:47.527: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21

After max-age expires, Cat3 transitions Fa0/23 from blocking into listening. It learns it’s new root-port is via Fa0/23 and awaits to move it into learning and finally forwarding.

Feb 19 08:27:49.372: STP: VLAN0001 new root port Fa0/23, cost 38
Feb 19 08:27:49.372: STP: VLAN0001 Fa0/23 -> listening
Feb 19 08:27:49.523: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21
Feb 19 08:27:49.532: STP: VLAN0001 Topology Change rcvd on Fa0/21
Feb 19 08:27:49.532: STP: VLAN0001 sent Topology Change Notice on Fa0/23

15 seconds after going into listening Fa0/23 goes into learning.

Feb 19 08:28:04.379: STP: VLAN0001 Fa0/23 -> learning

15 seconds after going into learning Fa0/23 goes into forwarding.

Feb 19 08:28:19.387: STP: VLAN0001 sent Topology Change Notice on Fa0/23
Feb 19 08:28:19.387: STP: VLAN0001 Fa0/23 -> forwarding

Note the total convergence time for the network here is @50 seconds.

OK, let’s break down what just happened here, starting on Cat1 when we shutdown Fa0/23. Fa0/23 was Cat1′s root port. Remember also that at this point when we shut down the link Fa0/23 on Cat3 is in the blocking state. That means that when we shut down that link on Cat1, Cat1 now has no idea who the root bridge is. He obviously is no longer receiving the BPDU from Cat2 since we shut the link down. He is not receiving the BPDU from Cat2 –> Cat4 –> Cat3 –> Cat1 either because Cat3 Fa0/23 is in blocking and is not passing on the BPDU information at this point. This would be an example of a direct link failure from the perspective of Cat1.

We see in the log that Cat1 actually advertises itself as the root bridge. Over on Cat3, we see this inferior BPDU being received repeatedly. Interestingly enough, it is exactly every two seconds — The hello time. What happens is that Cat1 starts advertising out that it is the root bridge every hello interval. Cat3 receives these BPDUs but will ignore them until the max-age timer expires. This is 20 seconds by default.

After that max-age timer expires, Cat3 will transition Fa0/23 into the listening state. It does this because it has not heard about the root bridge it had before in a while (On Fa0/21 for max-age time). At this point Cat3 has BPDUs from Cat1 who is claiming to be the root bridge coming in Fa0/21, and from Cat2 who is the real root bridge and thus has a superior BPDU on Fa0/23. We can see in the log of Cat3 that it hears about the root port on Fa0/21 (from Cat1 , inferior BPDU) and from Cat2 on Fa0/23 and it chooses Fa0/23 to be the new root port.

Notice the timestamps indicate that the time interval from the point where Cat3 started hearing about Cat1′s bogus root bridge advertisement to the point where it moves Fa0/23 into listening is almost exactly 20 seconds (max age). It is a few seconds off because remember the hello-time is 2 seconds. Say Cat3 received the normal BPDU describing Cat2 as the root bridge on Fa0/21 at time t = 0. At time t = 2 the link between Cat1 and Cat2 goes down. Now, we only have 18 seconds left before max-age expires.

In summary, what just happened is that Cat3 had to wait the max-age timer before entering listening and learning, so the convergence time is now almost exactly 50 seconds. Look at the timestamps on Cat3. At 08:27:31 we hear our first BPDU from Cat1 claiming to be the root bridge. At 08:28:19 Fa0/23 goes forwarding. Total convergence time from indirect link failure: Roughly 48 seconds (two seconds fluff time here due to what I talked about in the last paragraph)

So, in a situation where we have an indirect link failure, and we wanted to tweek the time it takes for ports to go forwarding, we could actually play with the max-age timer, the forward-delay or both!!!

Bringing a new switch online

At this point our topology is going to look something like this:

Now that everything has settled down and converged, let’s break it again hehe…We wil now bring the link between Cat1 and Cat2 back up and analyse what happens. Take note, that at this point there is no loop in the network. Therefore, nothing is in the blocking state. If nothing is in the blocking state, max-age plays no role in anything. Bringing this link back up will essentially be simulating adding a new link into the network that will cause a loop to happen.

Cat1:

Cat1(config-if)#no shut
Feb 19 09:05:53.177: set portid: VLAN0001 Fa0/23: new port id 8017

The port comes online, and IMMEDIATELY goes into listening mode. As you see, blocking is not involved. Thus, max-age is not involved here.

Feb 19 09:05:53.177: STP: VLAN0001 Fa0/23 -> listening
Feb 19 09:05:54.005: STP: VLAN0001 new root port Fa0/23, cost 19
Feb 19 09:05:54.009: STP: VLAN0001 Topology Change rcvd on Fa0/21
Feb 19 09:05:54.009: STP: VLAN0001 sent Topology Change Notice on Fa0/23

15 seconds later Fa0/23 transitions from listening –> learning.

Feb 19 09:06:08.177: STP: VLAN0001 Fa0/23 -> learning

15 seconds later Fa0/23 transitions from learning –> forwarding.

Feb 19 09:06:23.177: STP: VLAN0001 sent Topology Change Notice on Fa0/23
Feb 19 09:06:23.177: STP: VLAN0001 Fa0/23 -> forwarding

Note the total convergence from Cat1′s perspective is 30 seconds.

Cat3:

Cat3 has no ports in the blocking state at the moment. As soon as it hears about a better cost path to the root bridge via Fa0/21, it switches the root port to Fa0/21 instead of Fa0/23. That means Fa0/23 is not a root port anymore. Because Cat4 on the Cat3/Cat4 segment has a superior BPDU on the segment, Cat4 Fa0/23 is the DP. Cat3 Fa0/23 is now neither a RP or a DP so it immediately goes into blocking.

Feb 19 09:05:54.002: STP: VLAN0001 new root port Fa0/21, cost 38
Feb 19 09:05:54.002: STP: VLAN0001 sent Topology Change Notice on Fa0/21
Feb 19 09:05:54.002: STP: VLAN0001 Fa0/23 -> blocking

Note that the total convergence from Cat3′s perspective is actually a matter of MILLISECONDS after the link came back online between Cat1/Cat2. However, just because Cat3 converged in less than a second, doesn’t really do us any good. Since the link between Cat1/Cat2 is still down for 30 seconds while Cat1 Fa0/23 goes from listening –> learning –> forwarding, the network will be down for 30 seconds effectively.

Let’s break down what happened here. Note that after we “no shut” Fa0/23 on Cat1, it went DIRECTLY to the listening state. There is no need to go to blocking first here. Exactly 30 seconds later (2x the forward-delay) we are up and running!

The more interesting part to me is actually on Cat3. Notice that it converges in under 1 second. We aren’t using RSTP or anything crazy. Plain old STP. Cat3 has no ports in the blocking state when all this goes down. As soon as the Cat1/Cat2 link comes back online, Cat3 will start to receive BPDUs on Fa0/21 that indicate Fa0/21 has a better path to the root bridge. IMMEDIATELY, it switches it’s root port to Fa0/21. Do not wait for max-age, do not pass go, do not collect $200! Now, since Fa0/23 is no longer the root port, and it is not the designated port (because Cat4 has a superior cost to the root), Fa0/23 goes into blocking immediately. We have now come full circle.

In summary, when you are looking at tweaking out your STP timers to influence how long it takes for things to go forwarding you should keep the following general rules in mind:

1) If you are just plugging a machine into the network for the first time on an access-port, you will wait 2x forward-delay to go forwarding (30 seconds). The only thing you can do here is play with the forward-delay timer. Max-age is useless to you. Portfast can get around the entire process entirely.

2) The convergence of your switch after a direct link failure may be quicker than the convergence of the entire network. The convergence of everything as a whole may take up to 50 seconds because of the max-age timer needing to expire on some other switch before moving a port that is currently blocking into listening, learning and forwarding.

3) The convergence of your switch after an indirect link failure will largely depend on weather or not the switch currently has a port in blocking mode or not. If not, the convergence can be quite fast. If so, it could take up to 50 seconds due to max-age.

–
Joe Astorino CCIE #24347 (R&S)
Sr. Technical Instructor – IPexpert
Mailto: jastorino@ipexpert.com

Print Friendly

In this beast of a topology, R7 and R8 each have a loopback configured of x.x.x.x where x is the router number. Additionally, they are running EIGRP AS 78 between them, and each router is advertising their loopback into EIGRP. Right now, all the default K-values are in place ( 0 1 0 1 0 0 ). Before we get into the theory, let’s take a look at the EIGRP topology table on R8 as well are the routing table.

R8(config-router)#do sh ip eigrp top
IP-EIGRP Topology Table for AS(78)/ID(8.8.8.8)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 7.7.7.7/32, 1 successors, FD is 2297856
via 78.78.78.7 (2297856/128256), Serial0/0/0
P 8.8.8.8/32, 1 successors, FD is 128256
via Connected, Loopback0
P 78.78.78.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0/0
R8(config-router)#do sh ip route eigrp
7.0.0.0/32 is subnetted, 1 subnets
D       7.7.7.7 [90/2297856] via 78.78.78.7, 00:12:27, Serial0/0/0

As we can see above, R8 has the route for R7’s 7.7.7.7 loopback address as expected. We see that the composite metric for the route is 2297856. Cool. First off, how in the world did we get that metric? How is the EIGRP metric calculated? The dreaded formula…this is right from the current 12.4T IOS configuration guide under EIGRP. Note that some other documentation seems to forget the fact that in EIGRP everything is scaled by a factor of 256 : )

EIGRP Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + K3*Delay)*(K5/(Reliability + K4)))

OK, bad…but not too too bad. Just ugly. Very ugly! Another thing to keep in mind is that when we say “bandwidth” in the formula we are talking about the minimum bandwidth from point A to point B. When we say “delay” we are talking about the cumulative delay between point A and point B. Let’s see if we can figure out how to calculate this and get the same numbers as the router. Before we can do that, we need to understand the other variables in the equation: K1,K2,K3,K4 and K5. These values are simply used to scale things in the metric calculation. A K value is simply an integer between 1 and 255. That’s IT. Nothing magical. They are NOT equal to things like bandwidth, delay, reliability, load, and MTU. They are simply integers we use to multiply times those values to come up with a composite metric. As we know, K1 and K3 are set to a value of 1 by default, and other values are set to 0. Armed with that information, we can reduce our formula to the following:

EIGRP Metric = 256*(Bw + Delay)

Ah…much prettier. That is until we find out that bandwidth and delay in and of themselves have their own formulas as well. So the variable “Bw” in our above equation is defined as:

Bw = (10^7/minimum Bw in kilobits per second)

Furthermore, “Delay” in our above formula is defined as the route delay in tens of microseconds. Interesting. Taking this information our metric formula becomes:

EIGRP Metric = 256*((10^7 / min. Bw) + Delay)

OK, now we are getting somewhere. Let’s go find our variables Bw and Delay. Keep in mind we are calculating the metric for the loopback interface of R7 over on R8. That means we need the MINIMUM bandwidth from point A to point B as well as the CUMULATIVE delay. This can trip you up if you are not careful. Let’s take a look moving from right to left to find the minimum bandwidth and the cumulative delay.

R8(config-router)#do sh int s0/0/0 | i BW
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

R7(config-router)#do sh int s0/0/0 | i BW
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
R7(config-router)#do sh int lo0 | i BW
MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,

At a glance we can see that the minimum bandwidth is 1544Kb/s. What about cumulative delay? The delay of my serial link between R8 and R7 is 20000 microseconds. Furthermore, the delay on the loopback interface itself on R7 is another 5000 usec. Doesn’t that mean my cumulative delay would be 25000 microseconds? Actually, it doesn’t. The reason is because R7 already calculated out the bandwidth, delay and metric and then sent it to us. This is the AD or the advertised distance. We can see that on R8 in the topology table as 128256. Essentially R7 calculated the metric to itself and sent us that information.

R8(config-router)#do sh ip eigrp top | beg 7.7.7.7
P 7.7.7.7/32, 1 successors, FD is 2297856
via 78.78.78.7 (2297856/128256), Serial0/0/0
P 8.8.8.8/32, 1 successors, FD is 128256
via Connected, Loopback0
P 78.78.78.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0/0

20,000 / 10 = 2000.

We should have what we need now. Going back to our formula:

EIGRP Metric = 256*((10^7 / min. Bw) + Delay) Let’s plug in our numbers: EIGRP Metric = 256*((10^7 / 1544) + 2000)… so

EIGRP Metric = 256*((10,000,000 / 1544) + 2000)

Time to whip out windows calculator and crunch some numbers…keep in mind decimals will be rounded DOWN to the nearest whole number.

10,000,000 / 1544 = 6476.68 == 6476 EIGRP Metric = 256*(6476 + 2000) = 2169856

Booyah! Nailed it right on the money!!! Nice. We came up with the exact same number as the router. Always a good thing! Next, let’s talk about some misconceptions with respect to K-Values and the EIGRP metric. You may have read somewhere that the various K-Values are EQUAL to various pieces of the metric. This is simply not true. For instance, you see this statement thrown around all over the place:

K1 = Bandwidth K2 = Load K3 = Delay K4 = Reliability K5 = MTU

Back in CCNA days this is what most of us were taught. Unfortunately, this is not technically correct. As I said in the beginning of the article, K values are just integers between 1 and 255 used to calculate the metric in conjunction with things like bandwidth, load, delay, and reliability. The K-Values themselves are not equal to what we see above. This is further confused when we do redistribution. Let’s see what happens on R7 when we attempt to redistribute connected routes…

R7(config)#router eigrp 78
R7(config-router)#redistribute connected metric ?
<1-4294967295>  Bandwidth metric in Kbits per second
R7(config-router)#redistribute connected metric 1 ?
<0-4294967295>  EIGRP delay metric, in 10 microsecond units
R7(config-router)#redistribute connected metric 1 2 ?
<0-255>  EIGRP reliability metric where 255 is 100% reliable
R7(config-router)#redistribute connected metric 1 2 3 ?
<1-255>  EIGRP Effective bandwidth metric (Loading) where 255 is 100% loaded
R7(config-router)#redistribute connected metric 1 2 3 4 ?
<1-65535>  EIGRP MTU of the path
R7(config-router)#redistribute connected metric 1 2 3 4 5

I don’t know about all you guys out there, but I was taught as a CCNA that when you redistribute into EIGRP you have to “set your K-Values.” This leads people to think that the numbers you enter during redistribution ARE the K-Values when in fact they are not. The numbers we enter here are simply values of which SOME are used in the calculation of the final composite metric. IF I was indeed inputting the value of K1 here on the first line, how could it possibly be a range between 1 and 4294967295 if a K-value by definition is an integer between 1 and 255? The answer is it can’t.

We are not specifying a K-Value. We are specifying the bandwidth variable used in the metric calculation. That value will in fact be MULTIPLIED by whatever value has been set for K1. I said SOME of these entered values are used in the calculation of metric. The reason I say SOME is because of the 5th and final value entered in the redistribution metric above. Take a look at the IOS help. It instructs us to enter the MTU of the path. Again, when people are under the impression that they are entering K-values here, it leads them to mistakenly believe that the 5th thing they enter must be K5 and therefore K5 must be equal to MTU. This is not true either. What we are entering here is indeed a value for MTU.

The MTU however is not used at any point during the calculation of the metric. Take a look at our full formula again.

EIGRP Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + K3*Delay)*(K5/(Reliability + K4)))

Where in that formula do we see MTU? Nowhere. It simply does not exist in the calculation. So why do we enter it then? Because MTU is actually carried in EIGRP packets. It just has nothing to do with metric calculation. We keep saying that K-Values are just integers between 1 and 255 right? If we do not specify them during redistribution, where DO we? Under the EIGRP process using the “metric weights” command. To further illustrate the fact that MTU has nothing to do with metric calculation in EIGRP, let’s go ahead and set K5 = 1 on both sides.

R7(config-router)#metric weights 0 1 1 1 1 1

R8(config-router)#metric weights 0 1 1 1 1 1

While we’re at it…what is that first value that we set to 0 ? It is supposed to be used to specify ToS but was never implemented. Therefore, it HAS to be set to 0. OK. Now that we have altered our K-Values, obviously our metric will change. Let’s take a look at R8’s metric to 7.7.7.7 again.

R8(config-router)#do sh ip eigrp top | beg 7.7.7.7
P 7.7.7.7/32, 1 successors, FD is 9001
via 78.78.78.7 (9001/501), Serial0/0/0
P 8.8.8.8/32, 1 successors, FD is 128256
via Connected, Loopback0
P 67.67.67.0/24, 1 successors, FD is 642667810
via 78.78.78.7 (642667810/642539810), Serial0/0/0
P 78.78.78.0/24, 1 successors, FD is 8501
via Connected, Serial0/0/0

As expected, our metric changed. Now, let’s change our MTU value and see if anything changes. R7:

R7(config-router)#int s0/0/0
R7(config-if)#mtu 1400
R8(config-router)#
R8(config-router)#int s0/0/0
R8(config-if)#mtu 1250
R8(config-if)#do sh ip eigrp top | beg 7.7.7.7
P 7.7.7.7/32, 1 successors, FD is 9001
via 78.78.78.7 (9001/501), Serial0/0/0
P 8.8.8.8/32, 1 successors, FD is 128256
via Connected, Loopback0
P 67.67.67.0/24, 1 successors, FD is 642667810
via 78.78.78.7 (642667810/642539810), Serial0/0/0
P 78.78.78.0/24, 1 successors, FD is 8501
via Connected, Serial0/0/0

Nope. Same thing. One last proof of concept – What if we add another loopback to R8 and redistribute it into EIGRP? When we redistribute, we’ll set the MTU value to 1500 and check the metric on R7. We will then take the redistribution off and try it again with an MTU value of 1000. IF MTU was used in the metric calculation, the metric on R7 for that route would have to change.

R8(config-line)#do sh ip int brie | i Loop
Loopback0                  8.8.8.8         YES manual up                    up
R8(config-line)#int lo88
R8(config-if)#ip add 88.88.88.88 255.255.255.255
R8(config-if)#router eigrp 78
R8(config-router)#network 88.0.0.0
R8(config-router)#redistribute connected metric 1 2 3 4 1500
R7(config-if)#do sh ip eigrp top | beg 88.88.88.88
P 88.88.88.88/32, 1 successors, FD is 9001
via 78.78.78.8 (9001/501), Serial0/0/0

OK, we see that we have set the MTU during redistribution to 1500 and that the metric for this route on R7 is 9001. Let’s take off the redistribution and try again with another value.

R8(config-router)#no redistribute connected metric 1 2 3 4 1500
R8(config-router)#redistribute connected metric 1 2 3 4 1000
R7(config-if)#do sh ip eigrp top | beg 88.88.88.88
P 88.88.88.88/32, 1 successors, FD is 9001
via 78.78.78.8 (9001/501), Serial0/0/0
P 8.8.8.8/32, 1 successors, FD is 9001
via 78.78.78.8 (9001/501), Serial0/0/0
P 7.7.7.7/32, 1 successors, FD is 128256
via Connected, Loopback0
P 67.67.67.0/24, 1 successors, FD is 2560000512
via Rconnected (2560000512/0)
P 78.78.78.0/24, 1 successors, FD is 8501
via Connected, Serial0/0/0

I rest my case.

--
Joe Astorino CCIE #24347 (R&S)

Print Friendly

Back in the “old days” of CCIE R&S, candidates were expected to know how to configure their own frame-relay switch. As time went on, and things went to CCIE R&S v3.0, that requirement went by the wayside. We were told specifically that we would not have to configure the frame-relay switch itself – Only the routers connecting into it. In fact, we were not even given access to the frame-relay switch itself. With CCIE R&S v4.0 here in full swing, it might be a good idea to revisit this old beast. We have not been told to definitely expect it (no mention on the blueprint) but we have not been specifically told not to know it either. Better safe than sorry! The good news is, a frame-relay switch configuration is relatively straight forward, and can even solidify your fundamental knowledge of how frame-relay works. Here is a simple diagram. Here we have four routers with a full mesh of PVCs between them. In fact, we are going to look at how we can configure three PVCs between EVERY router here, just like we have on Proctor Labs.

OK, let’s look at the configuration of the frame-relay switch. There is not much to it. We turn on frame-relay switching, and we define our DLCIs – “If something comes IN this interface with this DLCI then send it OUT this other interface with this other DLCI.” That is really about it!!

frame-relay switching
!
interface Serial0
 description R2 Serial
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 204 interface Serial1 402
 frame-relay route 205 interface Serial2 502
 frame-relay route 206 interface Serial3 602
 frame-relay route 214 interface Serial1 412
 frame-relay route 215 interface Serial2 512
 frame-relay route 216 interface Serial3 612
 frame-relay route 224 interface Serial1 422
 frame-relay route 225 interface Serial2 522
 frame-relay route 226 interface Serial3 622
!
interface Serial1
 description R4 Serial
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 402 interface Serial0 204
 frame-relay route 405 interface Serial2 504
 frame-relay route 406 interface Serial3 604
 frame-relay route 412 interface Serial0 214
 frame-relay route 415 interface Serial2 514
 frame-relay route 416 interface Serial3 614
 frame-relay route 422 interface Serial0 224
 frame-relay route 425 interface Serial2 524
 frame-relay route 426 interface Serial3 624
!
interface Serial2
 description R5 Serial
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 502 interface Serial0 205
 frame-relay route 504 interface Serial1 405
 frame-relay route 506 interface Serial3 605
 frame-relay route 512 interface Serial0 215
 frame-relay route 514 interface Serial1 415
 frame-relay route 516 interface Serial3 615
 frame-relay route 522 interface Serial0 225
 frame-relay route 524 interface Serial1 425
 frame-relay route 526 interface Serial3 625
!
interface Serial3
 description R6 Serial
 no ip address
 encapsulation frame-relay
 clockrate 64000
 frame-relay intf-type dce
 frame-relay route 602 interface Serial0 206
 frame-relay route 604 interface Serial1 406
 frame-relay route 605 interface Serial2 506
 frame-relay route 612 interface Serial0 216
 frame-relay route 614 interface Serial1 416
 frame-relay route 615 interface Serial2 516
 frame-relay route 622 interface Serial0 226
 frame-relay route 624 interface Serial1 426
 frame-relay route 625 interface Serial2 526
!

Let’s break down the configuration of the serial0 interface that connects to R2. First and foremost, before we do any interface configs we tell the router it is going to be a frame-relay switch with the “frame-relay switching” command. Then, we go into each interface that connects to a router and start defining things. Serial0 connects to R2. First we have “encapsulation frame-relay” which just tells the serial interface to actually run frame. I’ve elected to put my serial clocking on the frame-relay switch end of the circuit. We’ve also defined the frame-relay switch as the DCE end of the frame-relay itself. The rest is just defining DLCIs!!! For example “frame-relay route 204 interface Serial1 402” just says “If I get a frame in this interface with DLCI 204 in the frame-relay header switch it out interface serial1 with DLCI 402”. That’s it!!! Pretty cool huh?

Enjoy!

Joe Astorino CCIE #24347 (R&S)
Sr. Technical Instructor – IPexpert
Mailto: jastorino@ipexpert.com

Print Friendly