|
|
Configuring WAN Protocols over MPLS Case StudiesThis section covers the configuration required to enable Layer 2 transport using AToM for different WAN protocols. Using a case study approach, this section covers configuration for HDLCoMPLS, PPPoMPLS, FRoMPLS, and ATMoMPLS, concentrating on generic configurations rather than platform specifics. After the configuration, each case study also covers verification and some troubleshooting for each WAN protocol over MPLS. All case studies use the same underlying MPLS PSN, shown in Figure 8-10. The objective of all the case studies is to establish Layer 2 transport connectivity between the two customer sites, with host names Oakland and Albany. Figure 8-10. WAN Protocols over MPLS Case Study Topology
All case studies require common configuration and verification of the MPLS core. The following list details the required pre-AToM configuration steps on all P and PE routers:
The configuration for the SanFran router is shown in Example 8-1. The configuration for the other two core routers is analogous to this one. Example 8-1. Required Preconfigurationservice timestamps debug datetime msec service timestamps log datetime msec ! hostname SanFran ! ip cef mpls ip mpls label protocol ldp mpls ldp explicit-null mpls ldp router-id Loopback0 force ! interface Loopback0 ip address 10.0.0.201 255.255.255.255 ! interface Ethernet1/0 ip address 10.1.1.201 255.255.255.0 no ip directed-broadcast mpls ip ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.255.255.255 area 0 In Example 8-1, you can see service timestamps configured for logging and debug with the msec option. This is done so that you have more time granularity in the debug and error message output to better understand the protocols and ease troubleshooting. Example 8-1 also shows mpls ldp explicit-null configured to advertise an IPv4 explicit null label (a label with a value of 0) instead of the default implicit null (Pop label operation). Now you can verify that the core configuration is working as expected. Use the command show mpls ldp neighbors in the Denver P router to confirm that the two link LDP sessions are UP. Implicitly, you are validating two other things:
Example 8-2 shows the Link LDP sessions highlighting that the state is "operational." Example 8-2. Verifying the Core LDP SessionDenver#show mpls ldp neighbor Peer LDP Ident: 10.0.0.203:0; Local LDP Ident 10.0.0.202:0 !This is NewYork PE TCP connection: 10.0.0.203.11022 - 10.0.0.202.646 State: Oper; Msgs sent/rcvd: 47/48; Downstream Up time: 00:34:06 LDP discovery sources: Ethernet2/0, Src IP addr: 10.1.2.203 Addresses bound to peer LDP Ident: 10.0.0.203 10.1.2.203 Peer LDP Ident: 10.0.0.201:0; Local LDP Ident 10.0.0.202:0 !This is SanFran PE TCP connection: 10.0.0.201.646 - 10.0.0.202.11006 State: Oper; Msgs sent/rcvd: 46/46; Downstream Up time: 00:33:57 LDP discovery sources: Ethernet1/0, Src IP addr: 10.1.1.201 Addresses bound to peer LDP Ident: 10.0.0.201 10.1.1.201 Denver# You can also verify the MPLS forwarding state in a PE and a P router (see Example 8-3). Example 8-3. Verifying the MPLS Forwarding StateSanFran#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 0 10.1.2.0/24 0 Et1/0 10.1.1.202 17 0 10.0.0.202/32 0 Et1/0 10.1.1.202 18 16 10.0.0.203/32 0 Et1/0 10.1.1.202 SanFran# Denver#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 0 10.0.0.203/32 1580313 Et2/0 10.1.2.203 17 0 10.0.0.201/32 1614352 Et1/0 10.1.1.201 Denver# At this point, you are ready for the specific Layer 2 WAN protocols transport configuration. The upcoming sections detail the configuration and verification in the following case studies: Case Study 8-1: HDLC over MPLSThis section describes the configuration and verification of HDLCoMPLS for transport of HDLC-like frames, including HDLC and Cisco HDLC. See Figure 8-11 for the case study topology. Figure 8-11. HDLCoMPLS Case Study Topology
In Figure 8-11, you can see that building from the generic topology in Figure 8-10, you will be using interfaces Serial 5/0 in both PE routers (SanFran and NewYork) and in both CE routers (Oakland and Albany). Configuring HDLCoMPLSYou know from previous chapters that the AToM states and all Layer 2 transport-specific configuration exist only in the edge routers. This adds to the scalability of the whole AToM solution. Start by configuring HDLCoMPLS on the Serial interfaces in the PE routers SanFran and NewYork, as shown in Example 8-4. Example 8-4. HDLCoMPLS PE ConfigurationSanFran#conf t Enter configuration commands, one per line. End with CNTL/Z. SanFran(config)#interface Serial5/0 SanFran(config-if)#no shutdown SanFran(config-if)# xconnect 10.0.0.203 50 encapsulation mpls SanFran(config-if)# *May 19 01:44:32.328: %LINK-3-UPDOWN: Interface Serial5/0, changed state to up *May 19 01:44:33.360: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial5/0, changed state to up SanFran(config-if)#end SanFran# NewYork#conf t Enter configuration commands, one per line. End with CNTL/Z. NewYork(config)#pseudowire-class atom_hdlc NewYork(config-pw-class)# sequencing transmit NewYork(config-pw-class)# encapsulation mpls NewYork(config-pw-class)#interface Serial5/0 NewYork(config-if)#no shutdown NewYork(config-if)# xconnect 10.0.0.201 50 pw-class hdlc NewYork(config-if)#end NewYork# In Example 8-4, the configurations that are applied to both PE routers are slightly different, although both achieve the same result. NewYork uses the pseudowire-class configuration, which is more versatile than the one liner xconnect configuration and allows for different characteristics to be applied to a pseudowire in a class fashion. This way, you can reuse the pseudowire class across multiple pseudowires. Also note that the encapsulation for the Serial interfaces is not configured. This is because the default of Cisco HDLC is used. When you configure the xconnect command, Cisco Discovery Protocol (CDP) is automatically disabled on the interface so that CDP packets are not sent to the CE router. The VC ID that is used in the xconnect command (50 in this example) needs to match in both ends. You will analyze the sequencing transmit configuration under the pseudowire class in the subsequent "Troubleshooting HDLCoMPLS" subsection. The CE configuration for the Oakland side is included in Example 8-5 for completeness. The far CE is a mirror of this configuration except for the IP address. Example 8-5. HDLCoMPLS CE ConfigurationOakland#conf t Enter configuration commands, one per line. End with CNTL/Z. Oakland(config)#interface Serial5/0 Oakland(config-if)# ip address 192.168.5.1 255.255.255.252 Oakland(config-if)#no shutdown Oakland(config-if)#end Oakland# At this point, all specific configuration and states that pertain to the transport of Layer 2 frames over MPLS reside in the PE devices. You have not configured the P router Denver. Verifying HDLCoMPLSWhen you configure AToM, the targeted LDP session between PE routers is established, as shown in Example 8-6. Example 8-6 highlights the local and peer LDP identifiers and the targeted discovery source. Example 8-6. Verifying the Targeted LDP SessionSanFran#show mpls ldp neighbor 10.0.0.203 Peer LDP Ident: 10.0.0.203:0; Local LDP Ident 10.0.0.201:0 TCP connection: 10.0.0.203.11007 - 10.0.0.201.646 State: Oper; Msgs sent/rcvd: 2215/2209; Downstream Up time: 1d08h LDP discovery sources: Targeted Hello 10.0.0.201 -> 10.0.0.203, active, passive Addresses bound to peer LDP Ident: 10.0.0.203 10.1.2.203 SanFran# Local labels are assigned and distributed using the targeted LDP session. See Example 8-7, which highlights the Layer 2 circuit (l2ckt) local and remote labels. Example 8-7. AToM Label DistributionSanFran#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 0 10.1.2.0/24 0 Et1/0 10.1.1.202 17 0 10.0.0.202/32 0 Et1/0 10.1.1.202 18 16 10.0.0.203/32 0 Et1/0 10.1.1.202 19 Untagged l2ckt(50) 149313 Se5/0 point2point SanFran#show mpls l2transport binding 50 Destination Address: 10.0.0.203, VC ID: 50 Local Label: 19 Cbit: 1, VC Type: HDLC, GroupID: 0 MTU: 1500, Interface Desc: n/a VCCV Capabilities: Type 1, Type 2 Remote Label: 19 Cbit: 1, VC Type: HDLC, GroupID: 0 MTU: 1500, Interface Desc: n/a !-+ Signaled as VCCV Capabilities: Type 1, Type 2 !-+ Interface Parameter SanFran# From the output of the command show mpls forwarding-table, you can see that local label 19 was assigned for the Layer 2 circuit (l2ckt). From the output of the command show mpls l2transport binding, you can see that the remote VC label is also 19. The fact that label 19 is being used on both sides is irrelevant. The local and remote labels are assigned independently and do not need to match. This last command also shows that the VC Type for HDLC is 0x0006 (from Table 8-1), the control word bit is set, the local and remote MTU are 1500, there is no interface description, and virtual circuit connectivity verification (VCCV) types supported are type 1 and type 2. These VCCV capabilities are as follows: The command show mpls l2transport binding details all information advertised in an LDP Label Mapping message. Note Both local and remote attachment circuits' MTUs need to match for the circuit to come up. The MTU is advertised in the MTU interface parameter in the pseudowire ID FEC element through the LDP Label Mapping message. The interface description is also advertised in an interface parameter. If you add an interface description, it is not automatically sent to the remote peer, because it is included in a label mapping. For the description to appear in the remote PE, you must force the resending of the label mapping, for example, by flapping the interface by means of a shutdown followed by a no shutdown. Another useful command is show mpls l2transport vc 50 detail, displayed in Example 8-8. The highlighted parts show the VC status and the label stack used in forwarding at imposition. Example 8-8. Displaying AToM VC DetailsSanFran#show mpls l2transport vc 50 detail Local interface: Se5/0 up, line protocol up, HDLC up Destination address: 10.0.0.203, VC ID: 50, VC status: up Preferred path: not configured Default path: active Tunnel label: 16, next hop 10.1.1.202 Output interface: Et1/0, imposed label stack {16 19} Create time: 1d08h, last status change time: 00:37:20 Signaling protocol: LDP, peer 10.0.0.203:0 up MPLS VC labels: local 19, remote 19 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: Sequencing: receive disabled, send disabled Sequence number: receive 0, send 0 VC statistics: packet totals: receive 1363, send 1402 byte totals: receive 237913, send 246646 packet drops: receive 0, seq error 0, send 231 SanFran# Among other things, the VC status is displayed in the command output along with the imposed label stack. In this case, 16 is the IGP label and 19 is the VC label. The VC can be in one of three different statuses:
A RAW adjacency, in which the protocol is shown as "raw" because no upper-layer adjacencies exist between the PE and CE, is created out of the attachment circuit (see Example 8-9). Example 8-9. AToM HDLC RAW AdjacencySanFran#show adjacency serial 5/0 detail Protocol Interface Address RAW Serial5/0 point2point(4) 0 packets, 0 bytes Raw never Epoch: 0 SanFran# Note that in the case of HDLCoMPLS, the adjacency contains a null encapsulation prepended to the packet that is switched through this adjacency, because the complete HDLC header is transported unmodified. Keep this in mind on the PPPoMPLS case study for comparison. Finally, you can verify that connectivity between CE routers indeed exists (see Example 8-10). Example 8-10. Testing Connectivity Between CE RoutersOakland#ping 192.168.5.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/38/60 ms Oakland# Troubleshooting HDLCoMPLSSo far, you have not configured an MTU in the network. All the PE and CE router's interfaces are using the following default MTU settings:
Try to calculate the maximum packet size that you can send between CEs with the default settings. You have the following overheads in place:
Based on the preceding list, you can calculate a total of 16 bytes of overhead added to CE frames. This means that only packets up to 1484 bytes from Oakland can reach the remote CE and vice versa. You can test this theory by using an extended ping with a sweep range of sizes that allows you to vary the sizes of the echo packets being sent and verbose output (see Example 8-11). Example 8-11. Probing for MTU Between CEsOakland#ping Protocol [ip]: Target IP address: 192.168.5.2 Repeat count [5]: 1 Datagram size [100]: Timeout in seconds [2]: 1 Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: y Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: v Loose, Strict, Record, Timestamp, Verbose[V]: Sweep range of sizes [n]: y Sweep min size [36]: 1480 Sweep max size [18024]: 1490 Sweep interval [1]: Type escape sequence to abort. Sending 11, [1480..1490]-byte ICMP Echos to 192.168.5.2, timeout is 1 seconds: Reply to request 0 (40 ms) (size 1480) Reply to request 1 (48 ms) (size 1481) Reply to request 2 (28 ms) (size 1482) Reply to request 3 (64 ms) (size 1483) Reply to request 4 (28 ms) (size 1484) Request 5 timed out (size 1485) Request 6 timed out (size 1486) Request 7 timed out (size 1487) Request 8 timed out (size 1488) Request 9 timed out (size 1489) Request 10 timed out (size 1490) Success rate is 45 percent (5/11), round-trip min/avg/max = 28/41/64 ms Oakland# Only packets up to 1484 bytes make it to the other end and back. You either need to increase the core MTU to 1516 bytes using the mtu command or reduce the CE interface's MTU to 1484. Make sure you understand the implications to IGP protocols before you change the MTU value. Finally, capture HDLCoMPLS AToM packets in the SanFran router, from an ICMP Echo (PING) from the Oakland CE. The imposition refers to AToM packets that are sent toward the NewYork PE out of the Ethernet interface, and disposition means AToM packets that are received from Denver and sent to the Oakland CE. Use the command debug mpls l2transport packet data, as shown in Example 8-12. Example 8-12. Capturing and Decoding HDLCoMPLS PacketsSanFran#debug mpls l2transport packet data AToM packet data debugging is on SanFran# *May 19 02:51:21.095: ATOM imposition: out Et1/0, size 130, EXP 0x0, seq 0, control word 0x0 *May 19 02:51:21.095: XX XX XX XX XX XX YY YY YY YY YY YY 88 47 00 01 ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^ SA MAC DA MAC Note Note in Example 8-12 and in the following examples dealing with packet decoding that the offline hand decoding of the packets is shown in bold. Analyzing the disposition as dumped in the SanFran PE, you can see that the control word has a non-null value, whereas the control word in imposition is null. This is because you have configured the NewYork endpoint to perform sequencing, and you can see the sequence number increasing in the control word. The sequence number in the control word is included in the rightmost 2 bytes. From Example 8-12, the control word is 0x00000B59 so the sequence number is 0x0B59. That number is 2905 in decimal. At disposition, only the AToM payload or SDU is displayed. At imposition, the complete AToM packet is dumped. Case Study 8-2: PPP over MPLSThe case study for PPPoMPLS is quite similar to HDLCoMPLS. In this case study, you concentrate on the differences with Case Study 8-1. For the PPPoMPLS case study, you use interfaces Serial 6/0 in all PEs and CEs (see Figure 8-12). Figure 8-12. PPPoMPLS Case Study Topology
Configuring PPPoMPLSThe configuration for PPPoMPLS is analogous to HDLCoMPLS, except that the PPP encapsulation needs to be specified in the Serial interface. Example 8-13 shows the configuration for the two PE devices. Example 8-13. Configuring PPPoMPLSSanFran#show running-config interface serial 6/0 Building configuration... Current configuration : 188 bytes ! interface Serial6/0 description *** To Oakland Serial 6/0 *** no ip address encapsulation ppp no cdp enable xconnect 10.0.0.203 60 encapsulation mpls end SanFran# NewYork#show running-config interface serial 6/0 Building configuration... Current configuration : 187 bytes ! interface Serial6/0 description *** To Albany Serial 6/0 *** no ip address encapsulation ppp no cdp enable xconnect 10.0.0.201 60 encapsulation mpls end NewYork# It is important to note, however, that after you configure the xconnect command under the PE interface, PPP is closed. That is, no LCP or NCP takes place between PE and CE, and no PPP state machine runs in the PE device. You can enable debug ppp negotiation in the PE to prove this concept (see Example 8-14). Example 8-14. Debug PPP Negotiation in the PE RouterSanFran(config-if)# xconnect 10.0.0.203 60 encapsulation mpls *May 18 17:16:35.583: Se6/0 LCP: State is Closed *May 18 17:16:35.583: Se6/0 PPP: Phase is DOWN *May 18 17:16:35.583: Se6/0 PPP: Phase is ESTABLISHING, Passive Open *May 18 17:16:35.583: Se6/0 LCP: State is Listen *May 18 17:16:35.583: Se6/0 LCP: State is Closed *May 18 17:16:35.583: Se6/0 PPP: Phase is DOWN *May 18 17:16:36.631: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial6/0, changed state to up SanFran(config-if)#do show interface serial 6/0 Serial6/0 is up, line protocol is up Hardware is HD64570 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) Last input 00:03:10, output 00:00:06, output hang never The output of the command show interface for the Serial 6/0 shows the encapsulation as PPP, but LCP and NCP are not indicated. For comparison, the same command shows LCP and NCPs state in the CE device (see Example 8-15). Example 8-15. PPP State in the PE DevicesOakland#show interfaces serial 6/0 Serial6/0 is up, line protocol is up Hardware is HD64570 Internet address is 10.10.6.200/24 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) LCP Open Open: OSICP, IPCP, CDPCP Last input 00:00:02, output 00:00:02, output hang never Last clearing of "show interface" counters never The PPP negotiation happens between CE devices, and the core network acts as a transport. Verifying and Troubleshooting PPPoMPLSThe first verification that CE-CE communication exists was shown in Example 8-15. From the CE device, you can check the status of PPP negotiation using the command show interface. From the PE device, you can verify that the VC is up (see Example 8-16). Example 8-16. Verifying the PPPoMPLS VC StatusSanFran#show mpls l2transport vc 60 Local intf Local circuit Dest address VC ID Status ------------- ----------------------- --------------- ---------- ---------- Se6/0 PPP 10.0.0.203 60 UP SanFran#show mpls l2transport vc 60 detail Local interface: Se6/0 up, line protocol up, PPP up Destination address: 10.0.0.203, VC ID: 60, VC status: up Preferred path: not configured Default path: active Tunnel label: 16, next hop 10.1.1.202 Output interface: Et1/0, imposed label stack {16 20} Create time: 12:45:20, last status change time: 12:44:36 Signaling protocol: LDP, peer 10.0.0.203:0 up MPLS VC labels: local 20, remote 20 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: *** To Albany Serial 6/0 *** Sequencing: receive disabled, send disabled Sequence number: receive 0, send 0 VC statistics: packet totals: receive 18291, send 18289 byte totals: receive 3577950, send 3403595 packet drops: receive 0, seq error 0, send 0 SanFran# From Example 8-16, you can see that the VC is up and the interface parameters of MTU and interface description have been advertised. The VC type is PPP, which has a value of 0x0007. You might wonder, however, how you can see the value of the VC type in real time when it is advertised. The answer is by using the debug command debug mpls l2transport signaling message. After you enable the debug in NewYork, you must bounce the remote interface to force withdrawing and remapping of the label (see Example 8-17). Example 8-17. Debugging AToM Signaling MessagesNewYork#debug mpls l2transport signaling message AToM LDP message debugging is on NewYork# SanFran(config)#int s 6/0 SanFran(config-if)#shut *May 19 16:19:44.995: AToM LDP [10.0.0.201]: Received label withdraw msg, id 1822, graceful restart instance 2 vc type 7, cbit 1, vc id 60, group id 0, vc label 20, status 0, mtu 0 *May 19 16:19:45.203: AToM LDP [10.0.0.201]: Sending label release msg vc type 7, cbit 1, vc id 60, group id 0, vc label 20, status 0, mtu 0 SanFran(config-if)#no shutdown NewYork# *May 19 16:20:40.071: AToM LDP [10.0.0.201]: Received label mapping msg, id 1825, graceful restart instance 2 vc type 7, cbit 1, vc id 60, group id 0, vc label 20, status 0, mtu 1500 From Example 8-17, you can see that when you shut down the interface in SanFran, an LDP label withdraw message is sent, which is acknowledged with an LDP label release message. When you enable the interface, an LDP label mapping message is sent, including the VC type of 7. More details on this procedure are covered in "Case Study 8-6: Decoding LDP Label Mapping and Pseudowire ID FEC Elements." It is also useful to capture PPPoMPLS AToM packets to fully understand the encapsulation. You can do this with the command debug mpls l2transport packet data, as shown in Example 8-18. Example 8-18. Capturing and Decoding of PPPoMPLS PacketsSanFran#debug mpls l2transport packet data *May 19 17:33:26.916: ATOM imposition: out Et1/0, size 128, EXP 0x0, seq 0, control word 0x0 *May 19 17:33:26.916: XX XX XX XX XX XX YY YY YY YY YY YY 88 47 00 01 ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^ SA MAC DA MAC | top_shim--> etype = MPLS Unicast *May 19 17:33:26.916: 00 FF 00 01 41 02 00 00 00 00 00 21 45 00 00 64 ^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ ^^^^^ ^^^^^... <--top_shim VC_Label Ctrl-word | Begins IP Packet Label=16 Label=20 PPP DLL Protocol# = IPv4 S=0 S=1 TTL=255 TTL=2 *May 19 17:33:26.916: 00 FA 00 00 FF 01 2D 4B C0 A8 06 01 C0 A8 06 02 *May 19 17:33:26.916: 08 00 6B C8 00 0F 00 02 00 00 00 00 0A E9 07 88 *May 19 17:33:26.916: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 17:33:26.916: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 17:33:26.916: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 17:33:26.916: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 17:33:26.932: ATOM disposition: in Et1/0, size 102, seq 0, control word 0x0 *May 19 17:33:26.932: 00 21 45 00 00 64 00 FA 00 00 FF 01 2D 4B C0 A8 ^^^^^ ^^^^^... | Begins IP Packet PPP DLL Protocol # = IPv4 *May 19 17:33:26.932: 06 02 C0 A8 06 01 00 00 73 C8 00 0F 00 02 00 00 *May 19 17:33:26.932: 00 00 0A E9 07 88 AB CD AB CD AB CD AB CD AB CD *May 19 17:33:26.932: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 17:33:26.932: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 17:33:26.932: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 17:33:26.932: AB CD AB CD AB CD As noted before, the output of the debug command displays the complete packet for imposition operations. It displays only the AToM payload for disposition actions. Example 8-19 shows the new RAW adjacency that is created for PPPoMPLS. Example 8-19. PPPoMPLS RAW AdjacencySanFran#show adjacency serial 6/0 detail Proocol Interface Address RAW Serial6/0 point2point(4) 0 packets, 0 bytes FF03 Raw never Epoch: 0 SanFran# From Example 8-19, you can see that the rewrite that was null for HDLCoMPLS has become 0xFF03. These two bytes are no more than the two bytes (Address and Control) from each PPP packet that are stripped in imposition and regenerated at disposition. They make the encapsulation that is prepended to the packet switched through this adjacency. Case Study 8-3: Frame Relay DLCI over MPLSThis case study concentrates on Frame Relay DLCI mode over MPLS. This case study is fundamentally different from the two previous case studies because control messaging interaction occurs between PE and CE routers. This case study uses Frame Relay IETF encapsulation. The topology is included in Figure 8-13. Figure 8-13. Frame Relay DLCI over MPLS Case Study Topology
In Frame Relay DLCI mode, PE and CE routers run Frame Relay LMI between them. If you instead tunnel and transport Frame Relay in port mode using HDLCoMPLS, the LMI session runs between CE devices. If those CE devices are Frame Relay switches, configure them to run LMI NNI. If the CEs are routers, configure one end as LMI DCE and leave the other as the default LMI DTE. Alternatively, configure both routers as LMI NNI so that the CE can provide status information about its DLCIs to the PE. Configuring Frame Relay DLCI over MPLSThe general PE configuration for a PE that is running Frame Relay DLCI over MPLS (also known as Frame Relay DLCI-Mode AToM) is shown in Example 8-20. The configuration in the NewYork PE is parallel to this one. Example 8-20. FRoMPLS PE ConfigurationSanFran#conf t Enter configuration commands, one per line. End with CNTL/Z. SanFran(config)#frame-relay switching SanFran(config)#interface serial7/0 SanFran(config-if)#encapsulation frame-relay ietf SanFran(config-if)#frame-relay intf-type dce SanFran(config-if)#no shutdown SanFran(config-if)#exit SanFran(config)# SanFran(config)#connect frompls serial7/0 100 l2transport SanFran(config-fr-pw-switching)#xconnect 10.0.0.203 70 encapsulation mpls SanFran(config-fr-pw-switching)#end SanFran# In Example 8-20, the global command frame-relay switching is enabled. This is required so that Frame Relay LMI types DCE or NNI can be enabled later. Next, create a "switched" Frame Relay PVC by using the global command connect extended with the l2transport keyword. You apply the xconnect command under the connect configuration mode (fr-pw-switching). Note You can configure the MTU on a switched Frame Relay PVC (pseudowire endpoint) basis by using the command mtu under the connect configuration mode. Example 8-21 depicts a typical CE configuration from the Oakland CE, including Frame Relay quality of service (QoS) parameters. Example 8-21. FRoMPLS CE Configurationinterface Serial7/0 no ip address encapsulation frame-relay IETF ! interface Serial7/0.1 point-to-point ip address 192.168.7.1 255.255.255.252 frame-relay interface-dlci 100 IETF class myfrpvc map-class frame-relay myfrpvc frame-relay cir 64000 frame-relay bc 8000 frame-relay be 0 frame-relay mincir 32000 A Frame Relay map-class is defined, including all the desired Frame Relay parameter values. Then this map-class is applied to the Frame Relay PVC using the class command. Verifying and Troubleshooting Frame Relay DLCI over MPLSFor FRoMPLS DLCI mode, you can use most verification techniques that were outlined for the previous two case studies. Checking IP layer connectivity between CE devices is the real verification. The output of the debug mpls l2transport signaling message command included in Example 8-22 shows that for Frame Relay DLCI mode, the VC type is 0x0001. Example 8-22. VC Type for FRoMPLSSanFran#debug mpls l2transport signaling message *May 19 18:10:25.119: AToM LDP [10.0.0.201]: Sending label mapping msg vc type 1, cbit 1, vc id 70, group id 0, vc label 21, status 0, mtu 1500 You can use a few commands on the PE router to verify the FRoMPLS pseudowire status. The most often used commands are included in the upcoming examples. Example 8-23 shows the show connection command output. Example 8-23. Verifying the Status of the FRoMPLS ConnectionSanFran#show connection all ID Name Segment 1 Segment 2 State =========================================================================== 4 frompls Se7/0 100 10.0.0.203 70 UP SanFran#show connection id 4 FR/Pseudo-Wire Connection: 4 - frompls Status - UP Segment 1 - Serial7/0 DLCI 100 Segment status: UP Line status: UP PVC status: ACTIVE NNI PVC status: ACTIVE Segment 2 - 10.0.0.203 70 Segment status: UP Requested AC state: UP PVC status: ACTIVE NNI PVC status: ACTIVE SanFran# In Example 8-23, you can observe that a switched connection has two segments:
Example 8-24 shows the output of the show mpls l2transport vc command, which you have seen in the previous case studies for other WAN protocols. Example 8-24. Verifying the Status of the FRoMPLS VCSanFran#show mpls l2transport vc This output is similar to other Layer 2 protocols that are transported over MPLS, but the VC Type is displayed as FR DLCI DLCI. Example 8-25 shows the command show frame-relay pvc in PE and CE routers for comparison. See the difference highlighted in the DLCI Usage field (Local for the CE and Switched for the PE) and the additional counters on the PE side. This command also shows the PVC status. Example 8-25. Verifying the Status of the FRoMPLS Frame Relay PVCSanFran#show frame-relay pvc interface serial 7/0 100 PVC Statistics for interface Serial7/0 (Frame Relay DCE) DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial7/0 input pkts 358 output pkts 329 in bytes 121796 out bytes 112624 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 switched pkts 358 Detailed packet drop counters: no out intf 0 out intf down 0 no out PVC 0 in PVC down 0 out PVC down 0 pkt too big 0 pvc create time 00:48:13, last time pvc status changed 00:47:53 SanFran# Oakland# Oakland#show frame-relay pvc interface serial 7/0 100 PVC Statistics for interface Serial7/0 (Frame Relay DTE) DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial7/0.1 input pkts 329 output pkts 358 in bytes 112624 out bytes 121796 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 348 out bcast bytes 120756 pvc create time 2d04h, last time pvc status changed 00:47:56 Oakland# The output of the command show frame-relay pvc in the SanFran PE router shows one line of DLCI Usage and PVC Status. This is because SanFran's Serial interface is configured as Frame Relay DCE. If a Frame Relay interface is configured for Frame Relay NNI LMI, two separate fields are displayed:
Table 8-3 lists the different values that the Usage and Status fields on the show frame-relay pvc command output can take and what they mean.
Specific Frame Relay LMI details such as the LMI type, LMI side, and statistics are available with the show frame-relay lmi and debug frame-relay lmi commands. One specific command for troubleshooting Frame Relay pseudowires is debug frame-relay pseudowire (see Example 8-26). Example 8-26. Debugging Frame Relay PseudowiresNewYork(config-if)#do debug frame-relay pseudowire Frame Relay pseudowire events debugging is on NewYork(config-if)#no shut NewYork(config-if)# *Apr 27 14:16:51.247: %LINK-3-UPDOWN: Interface Serial7/0, changed state to up *Apr 27 14:16:51.247: FRoPW [10.0.0.201, 70]: Local up, sending acmgr_circuit_up *Apr 27 14:16:51.247: FRoPW [10.0.0.201, 70]: Setting pw segment UP *Apr 27 14:16:51.263: Se7/0 ACMGR: Receive <Circuit Up> msg *Apr 27 14:16:51.263: Se7/0 ACMGR: circuit up event, SIP state chg fsp up to connected, action is p2p up forwarded *Apr 27 14:16:51.263: FRoPW [10.0.0.201, 70]: PW nni_pvc_status set ACTIVE *Apr 27 14:16:51.607: Se7/0 ACMGR: Rcv SIP msg: resp peer-to-peer msg, hdl 78000004, sss_hdl B000006 *Apr 27 14:16:51.607: Se7/0 ACMGR: remote up event, SIP connected state no chg, action is ignore *Apr 27 14:16:52.267: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial7/0, changed state to up *Apr 27 14:17:01.271: FRoPW [10.0.0.201, 70]: SW AC update circuit state to up *Apr 27 14:17:01.271: ACLIB: Update switching plane with circuit UP status The highlighted lines show the different state transition changes starting from the attachment circuit being set to up, the connect segment being set to up, the Frame Relay NNI PVC being set to active, and the circuit state being set to up. Example 8-27 shows a capture and decode of an FRoMPLS packet. The packet dump was generated in the same way as the other case studies by using the command debug mpls l2transport packet data. Refer to Figure 8-5 for comparison of the Frame Relay packets. Example 8-27. Capturing and Decoding of FRoMPLS DLCI PacketsSanFran#debug mpls l2transport packet data *May 19 19:14:41.080: ATOM imposition: out Et1/0, size 128, EXP 0x0, seq 0, control word 0x0 *May 19 19:14:41.080: XX XX XX XX XX XX YY YY YY YY YY YY 88 47 00 01 ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^ SA MAC DA MAC | top_shim--> etype = MPLS Unicast *May 19 19:14:41.080: 00 FF 00 01 51 02 00 00 00 00 03 CC 45 00 00 64 ^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ ^^ ^^ ^^^^^... <--top_shim VC_Label Ctrl-word | | Begins IP Packet Label=16 Label=21 | NLPID = IP (0xCC) S=0 S=1 Control = 0x03 TTL=255 TTL=2 *May 19 19:14:41.080: 01 11 00 00 FF 01 2B 34 C0 A8 07 01 C0 A8 07 02 *May 19 19:14:41.080: 08 00 BC 31 00 14 00 03 00 00 00 00 0B 45 B6 BC *May 19 19:14:41.080: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 19:14:41.080: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 19:14:41.080: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 19:14:41.080: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 19:14:41.104: ATOM disposition: in Et1/0, size 102, seq 0, control word 0x0 *May 19 19:14:41.104: 03 CC 45 00 00 64 01 11 00 00 FF 01 2B 34 C0 A8 ^^ ^^ ^^^^^... | | Begins IP Packet | NLPID = IP (0xCC) Control = 0x03 *May 19 19:14:41.104: 07 02 C0 A8 07 01 00 00 C4 31 00 14 00 03 00 00 *May 19 19:14:41.104: 00 00 0B 45 B6 BC AB CD AB CD AB CD AB CD AB CD *May 19 19:14:41.104: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 19:14:41.104: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 19:14:41.104: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD *May 19 19:14:41.104: AB CD AB CD AB CD You can see that the IP NLPID of 0xCC is used. For Frame Relay IETF encapsulation, Cisco IOS uses the NLPID value when one is available; otherwise, it uses a SNAP header with NLPID 0x80. Case Study 8-4: ATM AAL5 SDU over MPLSThe final two case studies explore the transport of ATMoMPLS. In particular, Case Study 8-4 analyzes AAL5 SDU over MPLS. The topology used is shown in Figure 8-14. Figure 8-14. AAL5 SDU over MPLS Case Study Topology
Configuring AAL5oMPLSThe configuration of AAL5oMPLS SDU mode only applies to an ATM VC. AAL5 VP or port modes are nonexistent. To configure AAL5oMPLS, you create an ATM PVC with the l2transport keyword and then apply the following two configuration steps under an ATM PVC configuration mode:
Example 8-28 shows a sample configuration for the SanFran and NewYork PE nodes. Example 8-28. Configuring AAL5oMPLS PEsSanFran#show running-config interface ATM 4/0.1 Building configuration... Current configuration : 230 bytes ! interface ATM4/0.1 point-to-point description *** AAL5 SDU AToM to Oakland *** pvc 0/100 l2transport encapsulation aal5 xconnect 10.0.0.203 100 encapsulation mpls ! end SanFran # NewYork#show running-config interface ATM 1/0.1 Building configuration... Current configuration : 229 bytes ! interface ATM1/0.1 point-to-point description *** AAL5 SDU AToM to Albany *** pvc 0/100 l2transport encapsulation aal5 xconnect 10.0.0.201 100 encapsulation mpls ! end NewYork # The CE configuration is no different than if the CE routers were connected to a traditional ATM switch (see Example 8-29). Example 8-29. Configuring AAL5oMPLS CEsOakland#show running-config interface ATM 3/0.1 Building configuration... Current configuration : 147 bytes ! interface ATM3/0.1 point-to-point ip address 192.168.1.1 255.255.255.252 pvc 0/100 oam-pvc manage ! end Oakland # Albany#show running-config interface ATM 3/0.1 Building configuration... Current configuration : 147 bytes ! interface ATM3/0.1 point-to-point ip address 192.168.1.2 255.255.255.252 pvc 0/100 oam-pvc manage ! end Albany# In this case, the CEs are configured for unspecified bit rate (UBR) service-type PVCs. You can change the service type and traffic parameters either by explicit configuration under the PVC mode or by defining a VC class. Example 8-29 shows OAM management enabled under the CE PVCs, which will be transported as raw cells over the AToM pseudowire. More details about OAM cell transport over AAL5 SDU Mode pseudowires are covered in the upcoming section titled "Case Study 8-9: Understanding Different ATM Transfer Modes." Verifying and Troubleshooting AAL5oMPLSThe VC Type for ATM AAL5 SDU VCC is 0x0002. By enabling the debug mpls l2transport signaling message command, you can see the targeted LDP label mapping message, including the VC Type in the pseudowire ID FEC TLV (see Example 8-30). Example 8-30. Checking the VC Type for AAL5oMPLS SDU ModeSanFran#debug mpls l2transport signaling message 1d21h: AToM LDP [10.0.0.201]: Received label mapping msg, id 3040 vc type 2, cbit 1, vc id 100, group id 4, vc label 20, status 0, mtu 4470 One of the first things you can verify is the pseudowire status and details. You can use the command show mpls l2transport vc (see Example 8-31). Example 8-31. Verifying the AAL5oMPLS SDU Mode VCSanFran#show mpls l2transport vc 100 Local intf Local circuit Dest address VC ID Status ------------- ----------------------- --------------- ---------- ---------- AT4/0.1 ATM AAL5 0/100 10.0.0.203 100 UP SanFran#show mpls l2transport vc 100 detail Local interface: AT4/0.1 up, line protocol up, ATM AAL5 0/100 up Destination address: 10.0.0.203, VC ID: 100, VC status: up Preferred path: not configured Default path: active Tunnel label: 16, next hop 10.0.1.203 Output interface: Fa0/0, imposed label stack {16 21} Create time: 01:10:38, last status change time: 00:12:25 Signaling protocol: LDP, peer 10.0.0.203:0 up MPLS VC labels: local 20, remote 21 Group ID: local 4, remote 3 MTU: local 4470, remote 4470 Remote interface description: *** AAL5 SDU AToM to Albany *** Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 141, send 141 byte totals: receive 8460, send 8460 packet drops: receive 0, send 1 SanFran The VC Type is displayed as ATM AAL5, and the VPI/VCI pair is included also. As usual, MTUs need to match for the PVC to come up. You can also see the l2transport bindings, including all information advertised through the targeted LDP session for this FEC in the LDP label mapping message (see Example 8-32). Example 8-32. Displaying the AAL5oMPLS SDU Mode BindingSanFran#show mpls l2transport binding 100 Destination Address: 10.0.0.203, VC ID: 100 Local Label: 20 Cbit: 1, VC Type: ATM AAL5, GroupID: 4 MTU: 4470, Interface Desc: *** AAL5 SDU AToM to Oakland *** VCCV Capabilities: Type 1, Type 2 Remote Label: 21 Cbit: 1, VC Type: ATM AAL5, GroupID: 3 MTU: 4470, Interface Desc: *** AAL5 SDU AToM to Albany *** VCCV Capabilities: Type 1, Type 2 SanFran Together with FRoMPLS, AAL5 SDU mode requires the use of the control word. You can see in Example 8-32 that the C-bit indicating control word disposition capability is set in both LDP advertisements. Example 8-33 displays the ATM VC information from the Oakland CE and the Albany PE to compare them. Example 8-33. Comparing the ATM PVCs in the CE and PE RoutersOakland#show atm vc interface ATM 3/0.1 detail ATM3/0.1: VCD: 1, VPI: 0, VCI: 100 UBR, PeakRate: 155000 AAL5-LLC/SNAP, etype:0x0, Flags: 0xC20, VCmode: 0x0 OAM frequency: 10 second(s) InARP frequency: 15 minutes(s) InPkts: 304, OutPkts: 222, InBytes: 16975, OutBytes: 15897 InPRoc: 304, OutPRoc: 222 InFast: 0, OutFast: 0, InAS: 0, OutAS: 0 Giants: 0 OAM cells received: 340 OAM cells sent: 340 Status: UP Oakland# SanFran#show atm vc interface ATM 4/0.1 detail ATM4/0.1: VCD: 1, VPI: 0, VCI: 100 UBR, PeakRate: 149760 AAL5 L2transport, etype:0xF, Flags: 0x10000C2E, VCmode: 0x0 OAM Cell Emulation: not configured Interworking Method: like to like Remote Circuit Status = No Alarm, Alarm Type = None InPkts: 496, OutPkts: 216, InBytes: 34359772357, OutBytes: 12677 InPRoc: 0, OutPRoc: 0 InFast: 156, OutFast: 216, InAS: 0, OutAS: 0 InPktDrops: 0, OutPktDrops: 0 CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0 Out CLP=1 Pkts: 0 OAM cells received: 340 OAM cells sent: 29 Status: UP SanFran# By contrasting the output of the display of ATM PVC in the PE and CE routers, you can see the following:
On the Oakland CE router, the OAM for cells received and sent display the total number of OAM cells that are received and sent from and to the Albany CE. On the SanFran PE router, OAM counter for received cells displays the total number of OAM cells from the Oakland CE. These cells are encapsulated in an AToM packet as cells (setting the T-bit in the required AAL5oMPLS SDU mode control word) and sent to the remote PE router NewYork. However, the OAM cells sent counter in the PE router does not count the OAM cells received in AToM packets from the remote NewYork PE and sent to the Oakland CE router. It counts the OAM cells that are generated from the SanFran PE, which explains the number discrepancy (see Example 8-34). Example 8-34. Alarm Indication Signal (AIS) OAM CellsSanFran# *May 19 16:51:40.207: AToM LDP [10.0.0.203]: Received label withdraw msg, id 3340 vc type 2, cbit 1, vc id 100, group id 3, vc label 21, status 0, mtu 0 *May 19 16:51:40.207: ATM VC alarm condition: remote acircuit DOWN forATM4/0.1:VC#1 0/100 *May 19 16:51:40.207: atm_oam_setstate - VCD#1, VC 0/100: newstate = AIS Xmitted *May 19 16:51:40.207: F5 OAM alarm: AIS sent, VC#1 0/100 ATM4/0.1 *May 19 16:51:40.207: atm_oam_start_timer VC = 1, curr_q_index = 19016 q_index = 19047, freq = 1000, cnt = 0 div = 31 *May 19 16:51:40.207: atm_oam_start_timer VC = 1, q_index = 19047, freq = 1000cnt = 0 *May 19 16:51:40.207: ATM VC alarm condition: remote acircuit DOWN forATM4/0.1:VC#1 0/100 From Example 8-34, you can see that when the pseudowire VC is withdrawn because of an MPLS network failure, the SanFran PE router sends OAM AIS cells to the Oakland CE router. The attachment circuit, which in this case is the ATM PVC with VPI/VCI 0/100 in the sub-interface ATM4/0.1 in SanFran, goes into a remote attachment circuit down alarm. The fault management aspects of the ATM attachment circuits and the relationship between pseudowire status and AIS signals are covered in the next case study. Case Study 8-5: ATM Cell over MPLSThe other mode of transporting ATMoMPLS is to transport raw cells in Cell Relay mode. This section presents a detailed example of CRoMPLS in VC mode. The topology used is shown in Figure 8-15. Figure 8-15. CRoMPLS Case Study Topology
Although this section focuses on CRoMPLS VC mode, it also presents some configuration and verification examples for CRoMPLS in its other two modes of operation: VP mode and port mode. Configuring CRoMPLSThe configuration steps to set up the cell relay transport of an ATM VC are similar to those required to configure AAL5 transport. The difference is that under the l2transport PVC configuration, the encapsulation is specified as aal0, implying no adaptation layer (raw cells). Example 8-35 lists the configuration of both PE routers. Example 8-35. Configuring CRoMPLS PEsSanFran#show running-config interface ATM 4/0.2 Building configuration... Current configuration : 229 bytes ! interface ATM4/0.2 point-to-point description *** Cell VC AToM to Oakland *** pvc 0/200 l2transport encapsulation aal0 xconnect 10.0.0.203 200 encapsulation mpls ! end SanFran# NewYork#show running-config interface ATM 1/0.2 Building configuration... Current configuration : 228 bytes ! interface ATM1/0.2 point-to-point description *** Cell VC AToM to Albany *** pvc 0/200 l2transport encapsulation aal0 xconnect 10.0.0.201 200 encapsulation mpls ! end NewYork# Note In earlier versions of ATM CRoMPLS implementations on the Cisco 12000 series routers with engine 2 ATM linecards, the interface command atm cell-relay was required as an initial configuration step. This initial step is no longer required. You can configure the different modes of CRoMPLS by applying the xconnect command under the different configuration modes (see Example 8-36). The context of the xconnect command determines the mode:
Example 8-36. Configuring CRoMPLS in VC, VP, and Port Modes
! Configuring Cell Relay over MPLS VC Mode
interface ATM4/0.300 point-to-point
pvc 0/300 l2transport
encapsulation aal0
xconnect 10.0.0.200 300 encapsulation mpls
! Configuring Cell Relay over MPLS VP Mode
interface ATM 5/0
atm pvp 1 l2transport
xconnect 10.0.0.200 400 encapsulation mpls
! Configuring Cell Relay over MPLS Port Mode
interface ATM 6/0
xconnect 10.0.0.200 500 encapsulation mpls
You can see from Example 8-36 that you only need the encapsulation aal0 command in VC mode, where it is necessary to distinguish between AAL5 and cell transport. Verifying CRoMPLSThis section describes verification of the CRoMPLS configuration. Start by verifying the circuit type of all the CRoMPLS transport modes. Following are the VC types used: The debug mpls l2transport signaling message command output provides the circuit type information (see Example 8-37). Example 8-37. Verifying the VC Type for All CRoMPLS Transport Modes! Configuring a remote Attachment Circuit for CRoMPLS Port Mode SanFran# *May 19 17:35:07.207: AToM LDP [10.0.0.203]: Received label mapping msg, id 3395 vc type 3, cbit 1, vc id 500, group id 0, vc label 18, status 0, mtu 0 ! Configuring a remote Attachment Circuit for CRoMPLS VP Mode SanFran# *May 19 17:35:44.511: AToM LDP [10.0.0.203]: Received label mapping msg, id 3397 vc type 10, cbit 1, vc id 400, group id 0, vc label 18, status 0, mtu 0 ! Configuring a remote Attachment Circuit for CRoMPLS VC Mode SanFran# *May 19 17:36:28.411: AToM LDP [10.0.0.203]: Received label mapping msg, id 3400 vc type 9, cbit 1, vc id 200, group id 0, vc label 18, status 0, mtu 0 In Example 8-37, the MTU that is advertised appears as null. The method and reason for this will become clear in this section. Given that the transport of cells is inherently different from the transport of packets, some differences exist in the AToM pseudowire setup. See the output of the command show mpls l2transport vc in Example 8-38. Example 8-38. Verifying the ATM Cell over MPLS VCSanFran#show mpls l2transport vc 200 Local intf Local circuit Dest address VC ID Status ------------- ----------------------- --------------- ---------- ---------- AT4/0.2 ATM VCC CELL 0/200 10.0.0.203 200 UP SanFran#show mpls l2transport vc 200 detail Local interface: AT4/0.2 up, line protocol up, ATM VCC CELL 0/200 up Destination address: 10.0.0.203, VC ID: 200, VC status: up Preferred path: not configured Default path: active Tunnel label: 16, next hop 10.0.1.203 Output interface: Fa0/0, imposed label stack {16 20} Create time: 1d23h, last status change time: 00:08:05 Signaling protocol: LDP, peer 10.0.0.203:0 up MPLS VC labels: local 21, remote 20 Group ID: local 0, remote 3 MTU: local n/a, remote n/a Remote interface description: *** Cell VC AToM to Albany *** Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 0, send 1 byte totals: receive 0, send 60 packet drops: receive 0, send 0 SanFran# The textual version of the VC Type for CRoMPLS in Cisco IOS Software is displayed as follows: Also note that the local and remote MTU values appear as not available (n/a). In all flavors of CRoMPLS, the MTU value is not advertised in the LDP label mapping, because it does not apply. This can also be noted in Example 8-39. Example 8-39. Verifying the ATM Cell over MPLS BindingSanFran#show mpls l2transport binding 200 Destination Address: 10.0.0.203, VC ID: 200 Local Label: 19 Cbit: 1, VC Type: ATM VCC CELL, GroupID: 0 MTU: n/a, Interface Desc: *** Cell VC AToM to Oakland *** Max Concatenated ATM Cells: 1 VCCV Capabilities: Type 1, Type 2 Remote Label: 20 Cbit: 1, VC Type: ATM VCC CELL, GroupID: 3 MTU: n/a, Interface Desc: *** Cell VC AToM to Albany *** Max Concatenated ATM Cells: 1 VCCV Capabilities: Type 1, Type 2 SanFran# From Example 8-39, you can see again that the MTU value does not apply to the transport of ATM cells over MPLS. The pseudowire comes up even if the MTUs in the two attachment circuits differ. However, a new interface parameter is advertised and displayed in the bindings. This new interface parameter is the maximum number of concatenated ATM cells, also known as the maximum number of cells packed (MNCP). This advertised parameter specifies the maximum number of packed cells that the egress PE can process in a single AToM packet disposition. The MNCP value defaults to 1, meaning that by default only one ATM cell is included in an AToM packet. This subject is covered in more detail in the upcoming section "Case Study 8-8: Packed Cell Relay over MPLS." From a fault management perspective, the pseudowire status is conveyed to the CE device's ATM endpoints by using AIS of the appropriate hierarchy. The following alarm indications are sent out of the AC for each of the ATM transport modes if the VC label is withdrawn because of an MPLS core network or remote AC failure:
|
|
|
top_shim-->
etype = MPLS Unicast