As everyone is fighting for the last available seats to do the R&S v3.0 exam, it’s getting time to get prepared for the new v4.0 blueprint.
I’d like to kick-off with some very basic stuff. Since people are scared of the new topics like MPLS and L3VPN on the blueprint. I think it’s a good idea to show you how easy it is to get MPLS up and running through LDP and BGP and configure some specific LDP features.
The topology is that we have 2 sites separated by a Frame-Relay cloud. In each site OSPF area 0 runs as IGP and BGP is used to advertise all the prefixes to the other site. The prefixes in the 172.16.x.x range are not allowed to be directly configured under OSPF. The goal of this task is to get an end-to-end label switched path (LSP) between 172.16.1.1 and 172.16.2.1.
First OSPF is configured on all routers and enabled on the R1-R3, R3-R4, R5-R6 and R6-R2 segments. After all OSPF neighbors are configured and have a state of FULL we verify full reachability.
R1:
R1#ping 150.1.34.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.1.34.4, timeout is 2 seconds:\ !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R2:
R2#ping 150.1.56.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.1.56.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
In both the sites we have achieved connectivity. Now we want to set-up LDP local within the site. To enable MPLS is one of the easiest things to do. There are some things to pay attention to.
LDP or TDP?
When ‘tag-switching’ was introduced by Cisco they created their own label distribution protocol called TDP. After tag switching became standardized they renamed it to MPLS and TDP was replaced with LDP. Most features of TDP are exactly the same in LDP with some added advantages like MD5 authentication. Since this is not explicitly stated on the blueprint it’s possible they could ask for both. The difference is not that hard. The only feature which is not in TDP is authentication and TDP uses TCP port 711 instead of 646 for LDP. Therefore this article will focus only on LDP.
Different IOS, different label protocol
During the migration from TDP to LDP, Cisco changed the default protocol quite some times. Therefore it’s not really easy to say which protocol will be the default. Now all the routers in the lab are ISR’s and running 12.4T, you might say that it’s almost certain that LDP is the default.
I personally always configure the global command ‘mpls label protocol ldp’ to be sure the right protocol is used on all interfaces, please be careful when configuring this, since the same command could be on an interface as well. The one configured on the interface is leading.
What rests is enabling MPLS on all interfaces within the site. This is done with the single command: ‘mpls ip’. That’s it!
But wait..now we enabled MPLS on all interfaces, but the LDP neighbors are not coming up. Why is that? After issuing ‘debug mpls transport events’, we see the following:
R6:
R6#debug mpls ldp transport events Aug 21 09:46:14.292: ldp: Send ldp hello; Ethernet0/1, src/dst 150.1.56.6/224.0.0.2, inst_id 0 Aug 21 09:46:15.844: ldp: Rcvd ldp hello; Ethernet0/0, from 150.1.26.2 (150.1.2.2:0), intf_id 0, opt 0xC Aug 21 09:46:15.844: ldp: ldp Hello from 150.1.26.2 (150.1.2.2:0) to 224.0.0.2, opt 0xC Aug 21 09:46:15.844: ldp: local idb = Ethernet0/0, holdtime = 15000, peer 150.1.26.2 holdtime = 15000 Aug 21 09:46:15.848: ldp: Link intvl min cnt = 2, intvl = 5000, idb = Ethernet0/0 Aug 21 09:46:15.848: ldp: Opening ldp conn; adj 0x65A44E84, 150.1.6.6 <-> 150.1.2.2; with normal priority Aug 21 09:46:15.848: ldp: Found adj 0x65A44E84 for 150.1.2.2 (Hello xport addr opt) Aug 21 09:46:15.848: ldp: MD5 setup for neighbor 150.1.2.2; password changed to [nil]Aug 21 09:46:15.848: ldp: No route to peer 150.1.2.2; set LDP_CTX_HANDLE_ROUTEUP
The LDP multicast hello is received, but there is no route to the loopback address of the other router. LDP uses the router-id as destination IP address for the TCP connection.
After all loopback interfaces are advertised in OSPF, all LDP neighbors are up and running.
R2:
R2(config)#router ospf 1 R2(config-router)#network 150.1.2.2 0.0.0.0 area 0 13:14:14: %LDP-5-NBRCHG: LDP Neighbor 150.1.6.6:0 is UP
To ensure that one specific loopback interfaces is chosen when setting up LDP neighbors, it’s highly recommended to use the command ‘mpls ldp router-id loopback0′. That way you are certain that you won’t break anything if you configure another loopback interface with a higher IP address, which is not advertised in an IGP and it could take a long time before you discover it.
Now all prefixes within the IGP network are receiving a label, which is advertised to the neighbor. That way within the site all prefixes are ‘label switched’!
R2:
R2#sh mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 16 Pop Label 150.1.6.6/32 0 Fa1/0 150.1.26.6 17 Pop Label 150.1.56.0/24 0 Fa1/0 150.1.26.6 18 18 150.1.5.5/32 0 Fa1/0 150.1.26.6
Let’s see if it really does what it promises:
R2:
R2#trace 150.1.5.5 Type escape sequence to abort. Tracing the route to 150.1.5.5 1 150.1.26.6 [MPLS: Label 18 Exp 0] 4 msec 4 msec 0 msec 2 150.1.56.5 4 msec * 0 msec
The traffic from R2 to the loopback of R5 is getting label switched over R6. R6 pops the label as it is the last hop to the destined prefix. This technique is called Penultimate Hop Popping or PHP.
It saves an extra look-up in the MPLS and IP forwarding table. The for last hop knows the prefix is directly connected to the next router, if it should only swap the label R5 had to do a MPLS lookup and had seen it needs to strip the label and then a IP forwarding lookup needs to be done to know the final destination interface. When this label is stripped on the router before, R5 only needs to do an IP forwarding lookup, saving time and resources.
Now label switching within the site is done, we need to get inter-site label switching enabled.
LDP will not work on this interface as LDP only uses the IGP learned prefixes for allocating and advertising labels and only BGP is enabled between R4 and R5. We will be using the BGP way of advertising labels.
First we set-up a peering between R4 and R5 and perform a mutual redistribution between OSPF and BGP on both sites. To enable allocating and advertising labels for BGP is quite easy to configure. Just add ‘neighbor x.x.x.x send-label’ to the configuration. With a ‘show ip bgp labels’ you can see all labels.
R5:
R5(config-if)#do sh ip bgp labels Network Next Hop In Label/Out Label 150.1.1.1/32 150.1.45.4 21/18 150.1.2.2/32 150.1.56.6 18/nolabel 150.1.3.3/32 150.1.45.4 22/19 150.1.5.5/32 0.0.0.0 imp-null/nolabel 150.1.6.6/32 150.1.56.6 19/nolabel 150.1.13.0/24 150.1.45.4 23/17 150.1.26.0/24 150.1.56.6 17/nolabel 150.1.34.0/24 150.1.45.4 24/imp-null 150.1.45.0/24 150.1.45.4 imp-null/imp-null 150.1.45.0/24 0.0.0.0 imp-null/nolabel 150.1.45.4/32 0.0.0.0 16/nolabel 150.1.45.5/32 150.1.45.4 nolabel/16 150.1.56.0/24 0.0.0.0 imp-null/nolabel 172.16.1.1/32 150.1.45.4 25/20
Now connectivity is established between R1 and R2:
R1:
R1#ping 150.1.2.2 sour lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds: Packet sent with a source address of 150.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/61/64 ms
When using traceroute you can see an end-to-end label switched path is established and we comply with the goal of this task:
R1
R1#trace 150.1.2.2 Type escape sequence to abort. Tracing the route to 150.1.2.2 1 150.1.13.3 [MPLS: Label 24 Exp 0] 96 msec 96 msec 96 msec 2 150.1.34.4 [MPLS: Label 29 Exp 0] 152 msec 100 msec 100 msec 3 150.1.45.5 [MPLS: Label 18 Exp 0] 64 msec 64 msec 64 msec 4 150.1.56.6 [MPLS: Label 24 Exp 0] 64 msec 64 msec 64 msec 5 150.1.26.2 32 msec * 40 msec
We issue a ‘redistribute connected subnets’ on both R1 and R2 to make sure that the 172.16.x.1 prefix is also advertised. After trying to ping the prefix, we see it’s not working. Why not?
R5:
R5#sh ip route 172.16.2.1 Routing entry for 172.16.2.1/32 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20 Last update from 150.1.56.6 on Ethernet0/1, 00:00:00 ago Routing Descriptor Blocks: * 150.1.56.6, from 150.1.2.2, 00:00:00 ago, via Ethernet0/1 Route metric is 20, traffic share count is 1
It’s known on R5, bot not on R1
R1:
R1#sh ip route 172.16.2.1 % Subnet not in table
Apparently it’s not getting advertised over the different sites. It’s also not visible in the BGP table on R5.
R5:
R5(config-router)#do sh ip bgp BGP table version is 33, local router ID is 150.1.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 150.1.1.1/32 150.1.45.4 21 0 200 ? *> 150.1.2.2/32 150.1.56.6 21 32768 ? *> 150.1.3.3/32 150.1.45.4 11 0 200 ? *> 150.1.5.5/32 0.0.0.0 0 32768 ? *> 150.1.6.6/32 150.1.56.6 11 32768 ? *> 150.1.13.0/24 150.1.45.4 20 0 200 ? *> 150.1.26.0/24 150.1.56.6 20 32768 ? *> 150.1.34.0/24 150.1.45.4 0 0 200 ? * 150.1.45.0/24 150.1.45.4 0 0 200 ? *> 0.0.0.0 0 32768 ? *> 150.1.45.4/32 0.0.0.0 0 32768 ? r> 150.1.45.5/32 150.1.45.4 0 0 200 ? *> 150.1.56.0/24 0.0.0.0 0 32768 ?
This problem has to do with the default redistribution behavior of OSPF. If you issue a ‘redistribute ospf 1′ on R4 and R5 only the INTERNAL routes are getting advertised. If you want the external routes getting redistributed as well you have to change the command to ‘redistribute ospf 1 match internal external’.
After we change this on both R4 and R5. The 172.16.x.1 prefixes are getting redistributed and now it’s known on R1 and R2:
R1:
R1#sh ip route 172.16.2.1 Routing entry for 172.16.2.1/32 Known via "ospf 1", distance 110, metric 1 Tag 100, type extern 2, forward metric 11 Last update from 150.1.13.3 on FastEthernet1/0, 00:00:15 ago Routing Descriptor Blocks: * 150.1.13.3, from 150.1.4.4, 00:00:15 ago, via FastEthernet1/0 Route metric is 1, traffic share count is 1 Route tag 100
And the subnets can reach each other through an end-to-end LSP (label switched path):
R1:
R1#ping 172.16.2.1 sour lo1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds: Packet sent with a source address of 172.16.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/64 ms
R2:
R2#ping 172.16.1.1 sour lo1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: Packet sent with a source address of 172.16.2.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/61/64 ms R2#trace 172.16.1.1 Type escape sequence to abort. Tracing the route to 172.16.1.1 1 150.1.26.6 [MPLS: Label 23 Exp 0] 96 msec 96 msec 96 msec 2 150.1.56.5 [MPLS: Label 25 Exp 0] 144 msec 100 msec 100 msec 3 150.1.45.4 [MPLS: Label 20 Exp 0] 64 msec 64 msec 68 msec 4 150.1.34.3 [MPLS: Label 17 Exp 0] 64 msec 64 msec 64 msec 5 150.1.13.1 36 msec * 32 msec
It seems like nothing has changed (ping still functions as normal), but in fact we changed the entire way of getting packets through a router! It’s not voodoo, just MPLS. When we setup a continuous ping on R1 to R2 and issue a ‘debug ip packet detail’ we see only management traffic for OSPF and LDP:
R3
R3#debug ip pack det IP packet debugging is on (detailed) Aug 21 11:14:49.952: IP: s=150.1.34.4 (Ethernet0/1), d=224.0.0.5, len 80, rcvd 0, proto=89 Aug 21 11:14:50.428: IP: s=150.1.34.3 (local), d=224.0.0.5 (Ethernet0/1), len 80, sending broad/multicast, proto=89 Aug 21 11:14:50.508: IP: s=150.1.13.3 (local), d=224.0.0.2 (Ethernet0/0), len 62, sending broad/multicast Aug 21 11:14:50.508: UDP src=646, dst=646 Aug 21 11:14:50.740: IP: s=150.1.13.1 (Ethernet0/0), d=224.0.0.2, len 62, rcvd 0 Aug 21 11:14:50.740: UDP src=646, dst=646 Aug 21 11:14:50.740: IP: s=150.1.34.4 (Ethernet0/1), d=224.0.0.2, len 62, rcvd 0 Aug 21 11:14:50.744: UDP src=646, dst=646
But if you issue a ‘debug mpls packets’, you do see a lot of traffic going through:
R3:
R3#debug mpls pack MPLS packet debugging is on Aug 21 12:03:54.384: MPLS: Et0/0: recvd: CoS=0, TTL=255, Label(s)=18 Aug 21 12:03:54.384: MPLS: Et0/1: xmit: CoS=0, TTL=254, Label(s)=21 Aug 21 12:03:54.444: MPLS: Et0/1: recvd: CoS=0, TTL=252, Label(s)=17 Aug 21 12:03:54.448: MPLS: Et0/0: xmit: (no label) Aug 21 12:03:54.448: MPLS: Et0/0: recvd: CoS=0, TTL=255, Label(s)=18 Aug 21 12:03:54.448: MPLS: Et0/1: xmit: CoS=0, TTL=254, Label(s)=21 Aug 21 12:03:54.508: MPLS: Et0/1: recvd: CoS=0, TTL=252, Label(s)=17 Aug 21 12:03:54.512: MPLS: Et0/0: xmit: (no label)
You see the ICMP echo coming in on e0/0 with label 18, swapped with label 21, TTL decreased by 1 and transmitted on e0/1. If we check this in the ‘show mpls forwarding-table’ we see this is the correct behavior:
R3:
R3#sh mpls for | in ^18 18 21 172.16.2.1/32 1212568 Et0/1 150.1.34.4
Than the ICMP echo-reply it coming in with label 17 on e0/1, the label is stripped (PHP) and transmitted on e0/0. Which also complies with the MPLS forwarding table.
R3:
R3#sh mpls for | in ^17 17 Pop tag 172.16.1.1/32 1173228 Et0/0 150.1.13.1
This is the key thing what we have trying to accomplish. No IP forwarding is done, just MPLS, not a single routing lookup is done in this process.
When the prefix and label are learned through BGP, it’s not shown in the ‘show mpls forwarding-table’. If you want to troubleshoot it, then the ‘show ip cef’ will help you with that, remind you that CEF is mandatory for MPLS to work. If we want to know which label is imposed on R4 to send the packet to R5:
R4:
R4#sh ip cef 172.16.2.1
172.16.2.1/32, version 53, epoch 0, cached adjacency to Serial0/0.1
0 packets, 0 bytes
tag information set
local tag: 21
fast tag rewrite with Se0/0.1, point2point, tags imposed: {20}
via 150.1.45.5, 0 dependencies, recursive
next hop 150.1.45.5, Serial0/0.1 via 150.1.45.5/32
valid cached adjacency
tag rewrite with Se0/0.1, point2point, tags imposed: {20}
The ‘local tag’ is the tag that is advertised and packets destined for this prefix should have label 21 set on the packet. That way CEF knows that it matches this entry and it should swap it with label 20 (in the ‘tag imposed’ section) and send out on Serial0/0.1.
I hope I could give you an introduction to MPLS and show the basics of the technology and the basic ideas behind it. The next article will be based on the same topology, but then without any LDP and solely based on Traffic Engineering tunnels.
–
Thanks!!!
Rick Mur
CCIE2 #21946 (R&S / Service Provider)
Sr. Support Engineer - IPexpert, Inc.
Thanks!!!
Rick Mur
CCIE2 #21946 (R&S / Service Provider)
Sr. Support Engineer - IPexpert, Inc.
