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:
R1—ATM—R2
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
150.100.100.254 0 FULL/ - 00:00:33 150.100.100.254 ATM3/0.1
Rack1R1#sh ip route ospf
20.0.0.0/32 is subnetted, 1 subnets
O 20.0.0.1 [110/3] via 150.100.100.254, 00:32:35, ATM3/0.1
150.100.0.0/32 is subnetted, 1 subnets
O 150.100.100.254 [110/2] via 150.100.100.254, 00:32:35, ATM3/0.1
150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
O 150.1.2.2/32 [110/3] via 150.100.100.254, 00:32:35, ATM3/0.1
Rack1R1#show mpls atm-ldp bindings
Destination: 150.1.1.0/24
Tailend Router ATM3/0.1 1/34 Active, VCD=10
Destination: 150.1.2.2/32
Headend Router ATM3/0.1 (1 hop) 1/34 Active, VCD=10
Destination: 150.100.100.254/32
Headend Router ATM3/0.1 (1 hop) 1/35 Active, VCD=11
Destination: 20.0.0.1/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 150.100.100.254, 01:00:47, ATM3/0.1
150.100.0.0/32 is subnetted, 1 subnets
O 150.100.100.254 [110/2] via 150.100.100.254, 01:00:47, ATM3/0.1
150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
O 150.1.1.1/32 [110/3] via 150.100.100.254, 01:00:47, ATM3/0.1
Rack1R2#show mpls atm-ldp bindings
Destination: 150.1.2.0/24
Tailend Router ATM3/0.1 1/34 Active, VCD=9
Destination: 150.100.100.254/32
Headend Router ATM3/0.1 (1 hop) 1/35 Active, VCD=10
Destination: 150.1.1.1/32
Headend Router ATM3/0.1 (1 hop) 1/34 Active, VCD=9
Destination: 20.0.0.0/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: “150.2.2.2/32″ and “20.0.0.1″ – 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 20.0.0.1
!!!!!
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: 150.1.1.0/24
Tailend Router ATM3/0.1 1/34 Active, VCD=10
Path: 150.100.100.254 150.1.1.1*
Destination: 150.1.2.2/32
Headend Router ATM3/0.1 (1 hop) 1/34 Active, VCD=10
Path: 150.1.1.1* 150.100.100.254
Destination: 150.100.100.254/32
Headend Router ATM3/0.1 (1 hop) 1/35 Active, VCD=11
Path: 150.1.1.1* 150.100.100.254
Destination: 20.0.0.1/32
Headend Router ATM3/0.1 (1 hop) 1/33 Active, VCD=9
Path: 150.1.1.1* 150.100.100.254
Destination: 10.0.0.0/24
Tailend Router ATM3/0.1 1/33 Active, VCD=9
Path: 150.100.100.254 150.1.1.1*
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: 150.100.100.254/32
Tailend Router ATM1/0.1 1/35 Active, VCD=19
Tailend Router ATM2/0.1 2/66 Active, VCD=20
Destination: 150.1.2.2/32
Headend Router ATM2/0.1 (1 hop) 2/65 Active, VCD=19
Tailend Router ATM1/0.1 1/34 Active, VCD=18
Destination: 150.1.1.1/32
Headend Router ATM1/0.1 (1 hop) 1/34 Active, VCD=18
Tailend Router ATM2/0.1 2/65 Active, VCD=19
Destination: 20.0.0.1/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 
Loading ...
