The subject is a legacy and is no longer a big issue for the CCIE SP exam. However, it still worths mentioning few major features of cell-mode ATM. For our article we’ll conside a small network consisting of three routers:
Basically, cell-mode ATM is an MPLS implementation which uses native ATM tagging mechanism for label switching. In order for ATM cloud to become MPLS enabled the following is required:
1) A label distribution protocol
2) An IGP running over the ATM cloud
Both things need IP connectivity between ATM devices. However, manually configuring a PVC between every pair of directly connected ATM LSRs would be quite a burden, so they came up with another solution. A fixed (well-known) VPI/VCI pair is used on each MPLS-enabled ATM interface to establish a point-to-point link with the peer. This VC could be changed using mpls atm control-vc command. As soon as you enable mpls ip on an ATM mpls subinterace, peers start discovery phase and establish an LDP connection (TCP session) over the control-VC. Just as a side note, the control-VC uses ATM AAL5 SNAP encapsulation to run IP.
interface ATM3/0.1 mpls ip unnumbered Loopback0 no atm enable-ilmi-trap mpls atm control-vc 1 64 mpls label protocol ldp mpls ip
Note that the actual IP address on an MPLS subinterface does not matter much, since the connection is essentially point-to-point. So for the purpose of address conservation you may use ip unnumbered here. Also, you may configure to use TDP instead of LDP, if you are connecting to another network using different protocol.
Next, you need to enable an IGP on the MPLS interface, e.g. configure OSPF. The IGP will use the same control-VC to exchange IP packets with the peer. As soon as IGP converges, LDP will start label bindings process. The significant different with ATM is that cell-mode MPLS uses “downstream on-demand” label distribution model. That is, an upstream router will request a label binding (a VPI/VCI pair) from the router downstream with respect to a particular IGP prefix. The router being requested, in turn, will ask it’s own downstream for this prefix and so the process will continue until the tail-end router will respond. Let’s see how would RIB and ATM LDP bindings table look like on R1 for our sample configuration:
Rack1R1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 18.104.22.168 0 FULL/ - 00:00:33 22.214.171.124 ATM3/0.1 Rack1R1#sh ip route ospf 126.96.36.199/32 is subnetted, 1 subnets O 188.8.131.52 [110/3] via 184.108.40.206, 00:32:35, ATM3/0.1 220.127.116.11/32 is subnetted, 1 subnets O 18.104.22.168 [110/2] via 22.214.171.124, 00:32:35, ATM3/0.1 126.96.36.199/16 is variably subnetted, 2 subnets, 2 masks O 188.8.131.52/32 [110/3] via 184.108.40.206, 00:32:35, ATM3/0.1 Rack1R1#show mpls atm-ldp bindings Destination: 220.127.116.11/24 Tailend Router ATM3/0.1 1/34 Active, VCD=10 Destination: 18.104.22.168/32 Headend Router ATM3/0.1 (1 hop) 1/34 Active, VCD=10 Destination: 22.214.171.124/32 Headend Router ATM3/0.1 (1 hop) 1/35 Active, VCD=11 Destination: 126.96.36.199/32 Headend Router ATM3/0.1 (1 hop) 1/33 Active, VCD=9 Destination: 10.0.0.0/24 Tailend Router ATM3/0.1 1/33 Active, VCD=9
Label bindings table shows whether the prefix is local (we are the Tailend Router) or we have requested it from our downstream peer (we are the Headend, requesting router). Also you can see that the label imposed is a VPI/VCI pair, as it should be expected of ATM. Check the other edge of the cloud:
Rack1R2#show ip route ospf 10.0.0.0/32 is subnetted, 1 subnets O 10.0.0.1 [110/3] via 188.8.131.52, 01:00:47, ATM3/0.1 184.108.40.206/32 is subnetted, 1 subnets O 220.127.116.11 [110/2] via 18.104.22.168, 01:00:47, ATM3/0.1 22.214.171.124/16 is variably subnetted, 2 subnets, 2 masks O 126.96.36.199/32 [110/3] via 188.8.131.52, 01:00:47, ATM3/0.1 Rack1R2#show mpls atm-ldp bindings Destination: 184.108.40.206/24 Tailend Router ATM3/0.1 1/34 Active, VCD=9 Destination: 220.127.116.11/32 Headend Router ATM3/0.1 (1 hop) 1/35 Active, VCD=10 Destination: 18.104.22.168/32 Headend Router ATM3/0.1 (1 hop) 1/34 Active, VCD=9 Destination: 22.214.171.124/24 Tailend Router ATM3/0.1 1/33 Active, VCD=8 Destination: 10.0.0.1/32 Headend Router ATM3/0.1 (1 hop) 1/33 Active, VCD=8
This router is “tailend” for two prefixes: “126.96.36.199/32″ and “188.8.131.52″ – the ones it advertises into IGP.
Verify end-to-end connectivity now:
Rack1R2#ping 10.0.0.1 source loopback 1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds: Packet sent with a source address of 184.108.40.206 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/18/24 ms
Another two feature specific to cell-mode ATM are MPLS LDP loop-detection and VC-merge. The first feature is specific to “downstream on-demand” mode of LDP operations. When a downstream router responds to or forwards a label binding request, it prepends it’s LDP router-id to the list already in the binding requests/response. Using this mechanics, any requesting node may validate if it’s router-id already presents in the binding request, e.g. verify if a loop has formed for some reason. You may enable the loop detection with LDP using the global configuration mode command mpls ldp loop-detection on all ATM LSR routers. To verify the effect of this command issue the following command:
Rack1R1#show mpls atm-ldp bindings path Destination: 220.127.116.11/24 Tailend Router ATM3/0.1 1/34 Active, VCD=10 Path: 18.104.22.168 22.214.171.124* Destination: 126.96.36.199/32 Headend Router ATM3/0.1 (1 hop) 1/34 Active, VCD=10 Path: 188.8.131.52* 184.108.40.206 Destination: 220.127.116.11/32 Headend Router ATM3/0.1 (1 hop) 1/35 Active, VCD=11 Path: 18.104.22.168* 22.214.171.124 Destination: 126.96.36.199/32 Headend Router ATM3/0.1 (1 hop) 1/33 Active, VCD=9 Path: 188.8.131.52* 184.108.40.206 Destination: 10.0.0.0/24 Tailend Router ATM3/0.1 1/33 Active, VCD=9 Path: 220.127.116.11 18.104.22.168*
The asterisk sign marks the local router and the path shows the router-ids we got in request or response packets. The next feature is called “VC-merge” and it allows an ATM-LSR to decrease the number of downstream requested labels, by associating the same label to the upstream requests going over the same downstream interface. Technically, it will require a switch to buffer all AAL5SNAP cells to form a complete PDU, before forwading the packet down. This will make LSR perform less efficient with respect to forwarding performance but will greatly reduce the number of label bindings required. You can enable the VC-merge mode on a node that has multiple upstreams using the mpls ldp atm vc-merge command.
And probably the last configuration option you need to consider is manually specifying the range of VPI/VCI used in responses for label binding requests. Remember, you need to specifiy it on the both ends of a point-to-point link between two LSRs and this feature works only with TDP.
R2: interface ATM3/0.1 mpls ip unnumbered Loopback0 no atm enable-ilmi-trap mpls atm vpi 2 vci-range 64-128 mpls label protocol tdp mpls ip ATM: interface ATM2/0.1 mpls ip unnumbered Loopback0 ip router isis no atm enable-ilmi-trap mpls atm vpi 2 vci-range 64-128 mpls label protocol tdp mpls ip
Will result in the following output on ATM LSR:
ATM#show mpls atm-ldp bindings Destination: 22.214.171.124/32 Tailend Router ATM1/0.1 1/35 Active, VCD=19 Tailend Router ATM2/0.1 2/66 Active, VCD=20 Destination: 126.96.36.199/32 Headend Router ATM2/0.1 (1 hop) 2/65 Active, VCD=19 Tailend Router ATM1/0.1 1/34 Active, VCD=18 Destination: 188.8.131.52/32 Headend Router ATM1/0.1 (1 hop) 1/34 Active, VCD=18 Tailend Router ATM2/0.1 2/65 Active, VCD=19 Destination: 184.108.40.206/32 Headend Router ATM2/0.1 (1 hop) 2/64 Active, VCD=18 Tailend Router ATM1/0.1 1/33 Active, VCD=17 Destination: 10.0.0.1/32 Headend Router ATM1/0.1 (1 hop) 1/33 Active, VCD=17 Tailend Router ATM2/0.1 2/64 Active, VCD=18
This is it for the basic configuration aspects of cell-mode MPLS pertaining to the CCIE SP exam. Remember, nobody is going to ask you to configure BPX switches there, so focus on more relevant SP topics, such as L3/L2 VPNs and SP Multicast
About Petr Lapukhov, 4xCCIE/CCDE:
Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.
6 Responses to “Cell-Mode MPLS”
Leave a Reply