لطفا منتظر باشید ...
Configuring WAN Protocols over MPLS Case Studies
This 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
[View full size image]
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:
1. | Create a loopback interface and assign a /32 IP address to it. |
2. | Enable IP Cisco Express Forwarding (CEF) globally. |
3. | Enable MPLS globally and select LDP as the label distribution protocol. Specify the loopback interface's IP address as the LDP Router ID. |
4. | Assign IP addresses to all physical links connecting the core routers, and enable Link LDP on them. |
5. | Enable an Interior Gateway Protocol (IGP) among the core routers and include the loopback and the interfaces connecting P and PE routers. These case studies use Open Shortest Path First (OSPF) with a single area 0. |
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 Preconfiguration
service 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:
First, that the LDP neighbors have discovered themselves. LDP discovery is performed by sending LDP Hellos over UDP to the all-routers multicast address (224.0.0.2). It is a prerequisite to LDP session establishment. You can check the LDP discovery status using the command show mpls ldp discovery.
Second, that IP routes for the loopback addresses are being propagated. After LDP session discovery, you establish the LDP session by setting up a TCP session between the addresses that are advertised in the IPv4 Transport address TLV in the Hello messagein this case, the loopback IP addresses. The higher LDP session ID (active) sets up a TCP connection to the lower LDP session ID (passive) at the well-known LDP port of 646. You can also check the IP routing information using the command show ip route, and verify the LDP transport address using the command show mpls ldp discovery detail.
Example 8-2 shows the Link LDP sessions highlighting that the state is "operational."
Example 8-2. Verifying the Core LDP Session
Denver#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 State
SanFran#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 MPLS
Case Study 8-2: PPP over MPLS
Case Study 8-3: Frame Relay DLCI over MPLS
Case Study 8-4: ATM AAL5 SDU over MPLS
Case Study 8-5: ATM Cell over MPLS
Case Study 8-1: HDLC over MPLS
This 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
[View full size image]
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 HDLCoMPLS
You 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 Configuration
SanFran#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 Configuration
Oakland#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 HDLCoMPLS
When 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 Session
SanFran#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 Distribution
SanFran#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:
Type 1 PWE3 control word (0001b as the first nibble in the control word)
Type 2 MPLS Router Alert label (Label == 1)
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 Details
SanFran#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:
UP VC can carry data between the two endpoints. (Imposition and disposition are programmed.) Two conditions need to hold true:
Disposition interfaces are programmed The VC is configured, and the CE interface is up.
Imposition interfaces are programmed The disposition interface is programmed, and you received a remote VC label and an IGP label (LSP to the peer).
DOWN VC is not ready to carry traffic between the two VC endpoints.
ADMINDOWN A user has disabled the VC.
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 Adjacency
SanFran#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 Routers
Oakland#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 HDLCoMPLS
So 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:
MTU == 1500 by default for Serial and Ethernet
MTU == 4470 by default for High-Speed Serial Interface (HSSI), ATM, and Packet over SONET (POS)
Try to calculate the maximum packet size that you can send between CEs with the default settings. You have the following overheads in place:
Table 8-2)
AToM Header 4 bytes of control word
MPLS Label Stack * MPLS Header Size 8 bytes from 2 MPLS headers of 4 bytes each
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 CEs
Oakland#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 Packets
SanFran#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 MACtop_shim-->
etype = MPLS Unicast
*May 19 02:51:21.095: 00 FF 00 01 31 02 00 00 00 00 0F 00 08 00 45 00
^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^ ^^ ^^ ^^^^^ ^^^^^...
<--top_shim VC_Label Ctrl-word | | | Begins IP Packet
Label=16 Label=19 | | etype = IPv4
S=0 S=1 | Control
TTL=255 TTL=2 Address = Unicast Frame
*May 19 02:51:21.095: 00 64 00 32 00 00 FF 01 30 13 C0 A8 05 01 C0 A8
*May 19 02:51:21.095: 05 02 08 00 03 A7 00 06 00 04 00 00 00 00 07 C1
*May 19 02:51:21.095: 72 D8 AB CD AB CD AB CD AB CD AB CD AB CD AB CD
*May 19 02:51:21.095: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
*May 19 02:51:21.095: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
*May 19 02:51:21.095: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
*May 19 02:51:21.095: AB CD
*May 19 02:51:21.143: ATOM disposition: in Et1/0, size 104, seq 2905, control
word 0xB59
*May 19 02:51:21.143: 0F 00 08 00 45 00 00 64 00 32 00 00 FF 01 30 13
^^ ^^ ^^^^^ ^^^^^...
| | | Begins IP Packet
| | etype = IPv4
| Control
Address = Unicast Frame
*May 19 02:51:21.143: C0 A8 05 02 C0 A8 05 01 00 00 0B A7 00 06 00 04
*May 19 02:51:21.143: 00 00 00 00 07 C1 72 D8 AB CD AB CD AB CD AB CD
*May 19 02:51:21.143: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
*May 19 02:51:21.143: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
*May 19 02:51:21.143: AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD
*May 19 02:51:21.143: AB CD AB CD AB CD AB CD
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 MPLS
The 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
[View full size image]
Configuring PPPoMPLS
The 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 PPPoMPLS
SanFran#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 Router
SanFran(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 Devices
Oakland#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 PPPoMPLS
The 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 Status
SanFran#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 Messages
NewYork#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 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 Packets
SanFran#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 Adjacency
SanFran#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 MPLS
This 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
[View full size image]
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 MPLS
The 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 Configuration
SanFran#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 Configuration
interface 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 MPLS
For 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 FRoMPLS
SanFran#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 Connection
SanFran#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:
Segment 1 The local attachment circuit out of Serial 7/0 DLCI 100
Segment 2 The remote endpoint of the pseudowire in the NewYork PE
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 VC
SanFran#show mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------- ----------------------- --------------- ---------- ----------
Se7/0 FR DLCI 100 10.0.0.203 70 UP
SanFran#show mpls l2transport vc 70 detail
Local interface: Se7/0 up, line protocol up, FR DLCI 100 up
Destination address: 10.0.0.203, VC ID: 70, 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 21}
Create time: 00:47:09, last status change time: 00:47:08
Signaling protocol: LDP, peer 10.0.0.203:0 up
MPLS VC labels: local 22, remote 21
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 317, send 346
byte totals: receive 110374, send 119708
packet drops: receive 0, seq error 0, send 0
SanFran#
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 PVC
SanFran#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:
LOCAL PVC STATUS Status of the PVC that is locally configured
NNI PVC STATUS Status of the PVC as learned from the LMI peer
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.
USAGE | LOCAL | If DLCI is configured on the router as a DTE device. |
SWITCHED | If DLCI is configured and the router is acting as a switch. | |
UNUSED | If DLCI is not configured on the router but the switch is reporting it. | |
STATUS | STATIC | If keepalives (Frame Relay LMI) are disabled. |
DELETED | If DLCI is defined on the router (Frame Relay DTE) but not the switch (Frame Relay DCE). | |
INACTIVE | If DLCI is defined on the switch (Frame Relay DCE) but the PVC is not up (that is, network, AToM, VC failure). | |
ACTIVE | If DLCI is defined on the switch (Frame Relay DCE) and is enabled. |
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 Pseudowires
NewYork(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. Figure 8-5 for comparison of the Frame Relay packets.
Example 8-27. Capturing and Decoding of FRoMPLS DLCI Packets
SanFran#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 MPLS
The 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
[View full size image]
Configuring AAL5oMPLS
The 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:
Step 1. | Configure the encapsulation as encapsulation aal5. |
Step 2. | Apply the xconnect command with the same format as before. |
Example 8-28 shows a sample configuration for the SanFran and NewYork PE nodes.
Example 8-28. Configuring AAL5oMPLS PEs
SanFran#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 CEs
Oakland#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#
Case Study 8-9: Understanding Different ATM Transfer Modes."
Verifying and Troubleshooting AAL5oMPLS
The 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 Mode
SanFran#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 VC
SanFran#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 Binding
SanFran#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 Routers
Oakland#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:
The encapsulation type that is displayed for the CE is AAL5-LLC/SNAP (although it could have been AAL5-MUX or something else), whereas for the PE PVC it is always AAL5 l2transport.
The CE PVC shows OAM configuration (OAM frequency), whereas the PE PVC displays OAM Cell Emulation configuration. You can enable cell emulation by using the commands oam-ac emulation-enable and oam-pvc manage so that the PE locally terminates OAM cells (as opposed to transporting them).
The PE PVC shows AToM-specific information such as the remote pseudowire status and the interworking type.
The OAM cells received and sent counters have a slightly different interpretation.
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 Cells
SanFran#
*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 MPLS
The 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
[View full size image]
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 CRoMPLS
The 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 PEs
SanFran#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:
VC mode Apply the xconnect command under pvc l2transport configuration submode (cfg-if-atm-l2trans-pvc).
VP mode Apply the xconnect command under atm pvp l2transport configuration submode (cfg-if-atm-l2trans-pvp).
Port mode Apply the xconnect command under the interface configuration 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 CRoMPLS
This 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:
CRoMPLS VC Mode 0x0009 (9)
CRoMPLS VP Mode 0x000A (10)
CRoMPLS Port Mode 0x0003 (3)
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 VC
SanFran#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:
VC mode ATM VCC CELL VPI/VCI
VP mode ATM VPC CELL VPI
Port mode ATM CELL Interface_name
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 Binding
SanFran#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 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:
VC Mode F5 (VC-level) AIS OAM cells are sent. Note that this applies to both AAL5oMPLS and CRoMPLS VC Mode.
VP Mode F4 (VP-level) AIS OAM cells are sent.
Port Mode Line (for example Layer 1 SONET-level) AIS is sent.
