Layer 2 Vpn Architectures [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Layer 2 Vpn Architectures [Electronic resources] - نسخه متنی

Carlos Pignataro, Dmitry Bokotey, Anthony Chan

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید









Verifying Pseudowire Data Connectivity



Fault detection, isolation, and verification techniques are critical for the deployment of MPLS applications, including pseudowire emulation. The ability to detect faults in the data plane or forwarding path for pseudowire services in a packet-switched network is critical for network operators. This section explores virtual circuit connectivity verification (VCCV), which provides an answer to pseudowire fault detection.


The connectivity verification model for pseudowires consists mainly of two distinctive building blocks that are specified in two different Internet drafts:



Advertising the VCCV capability



Verifying data plane connectivity




Case Studies 9-11 and 9-12 describe both building blocks in detail.


You can verify the pseudowire dataplane connectivity by creating a control channel within the pseudowire. This control channel is associated with the pseudowire, and data connectivity packets flow in this control channel. The control channel has two requirements:



To follow the pseudowire data path as closely as possible



To divert data connectivity verification packets so that they are processed by the receiving PE device as opposed to being forwarded out to the CE devices




As you will see in "Case Study 9-11: Advertising the VCCV Capability," three control channel types (CC types) provide the preceding two requirements.


After you define the control channel, you need to specify the connectivity verification packets and protocols that will use the control channel. You can use multiple protocols over the control channel, which have different data connectivity verification types (CV types). The three currently defined CV types are IP-based protocols.



Case Study 9-11: Advertising the VCCV Capability



The capability of VCCV is advertised as part of the MPLS Label Mapping message in the Pseudowire ID FEC as an interface parameter. Example 9-56 shows a decoding example of the VCCV interface parameter taken with Ethereal software.



Example 9-56. VCCV Interface Parameter


Interface Parameter: VCCV
ID: VCCV (0x0c)
Length: 4
CC Type
.... ...1 = PWE3 Control Word: True
.... ..1. = MPLS Router Alert: True
.... .0.. = MPLS Inner Label TTL = 1: False
CV Type
.... ...0 = ICMP Ping: False
.... ..1. = LSP Ping: True
.... .0.. = BFD: False


The ID value 0x0C indicates that this is a VCCV interface parameter. It consists of two fields that have various options:



Control Channel (CC) type Defines a bitmask that indicates the types of control channel that can be used to receive CC traffic to verify connectivity. If more than one is specified, the router agrees to accept control traffic at any time over any control channel:



PWE3 Control Word (type 1) The control channel traffic is carried inband with data traffic on the pseudowire being monitored using the same label stack. When you use this control channel, a special format of the AToM control word instructs the PE router to inspect the control channel traffic.


MPLS Router Alert Label (type 2) The control channel is created out-of-band from the pseudowire, and it utilizes the reserved Router Alert (RA) label. The notion of "out-of-band" comes from the fact that the connectivity verification packet has a slightly different MPLS label stack than the actual pseudowire data packet.


MPLS Inner Label TTL = 1 (type 3) It is also known as TTL Expiry that sets the TTL of the VC label to 1, which forces the control packet to be processed by the receiving PE router.



Connectivity Verification (CV) type Defines a bitmask that indicates the types of CV packets and protocols that can be sent on the specified control channel:



Internet Control Message Protocol (ICMP) Ping ICMP-based Echo Request and Reply.


LSP Ping MPLS-based Echo Request and Reply.


BFD Bidirectional Forwarding Detection provides a continuous monitoring and forward and backward defect indication and propagation.




Table 9-1 compares the three control channel types.




Control


Channel Type



Channel


Type



Pros



Cons and Limitations


Table 9-1. Comparing VCCV Control Channel Types


Type 1PWE Control Word



Inband



VCCV traffic follows the same path as pseudowire data traffic.



Pseudowire must use the control word.



Type 2MPLS RA Label



Out-of-band



Available even if the control word is not present or cannot be inspected.



VCCV traffic might take a different path than the pseudowire data traffic.



Type 3MPLS VC Label TTL = 1



Inband



VCCV traffic follows the same path as pseudowire data traffic, and no control word is necessary.



Might not work if the penultimate hop overwrites the TTL.



When you create an inband control channel of a pseudowire, the data flow and the control flow are effectively multiplexed over the same forwarding path, which is the most accurate picture of the data connectivity. This is why inband methods are preferred.


In contrast, the out-of-band control flow might follow a different forwarding path from the actual data flow because of the ECMP load sharing forwarding behavior described earlier in this chapter. There is no impact, however, if the pseudowire path is free of ECMPs, although that is not a realistic assumption. The out-of-band channel is created by using the reserved RA label. The RA label means that every router must examine the packet. With an RA label, all packets are punted to the route processor (RP) for processing; therefore, you can use this method to detect inconsistencies between the linecard and the RP. In an intermediate router, after the packet that contains the RA label is processed, if the packet needs to be forwarded further, the RA label is pushed back onto the label stack before forwarding.


Currently, Cisco routers advertise CC types 1 and 2, but the Cisco router prefers to use the control word CC type because of its inband capabilities to traverse the same path as the pseudowire data plane. The only CV type that is currently supported is LSP Ping.


You can display the VCCV capability advertisement by using the show mpls l2transport binding command. Example 9-57 provides output of this command.


Example 9-57. show mpls l2transport binding Command Output



PE1#show mpls l2transport binding 300
Destination Address: 10.0.0.203, VC ID: 300
Local Label: 18
Cbit: 1, VC Type: ATM VCC CELL, GroupID: 5
MTU: n/a, Interface Desc: *** Packed Cell VC AToM to CE1 ***
Max Concatenated ATM Cells: 10
VCCV Capabilities: Type 1, Type 2
Remote Label: 18
Cbit: 1, VC Type: ATM VCC CELL, GroupID: 2
MTU: n/a, Interface Desc: *** Packed Cell VC AToM to CE2 ***
Max Concatenated ATM Cells: 10
VCCV Capabilities: Type 1, Type 2


The VCCV CC types that are displayed with the show mpls l2transport binding command are displayed as type 1 for the control word and type 2 for the MPLS RA label.


To understand the ECMP implications of using CC type 1 versus CC type 2, you need to be familiar with the ECMP procedures. To load share traffic between multiple paths with equal cost in traditional IP networks, routers use a hashing algorithm performed on the source and destination IP addresses in the IPv4 or IPv6 packet header to choose the outgoing path within the multiple paths. This minimizes misordering of packets by sending IP flows on a single path.


MPLS networks adapted the same technique by inspecting the payload of MPLS packets. However, because LDP is a stateful protocol and the MPLS header does not have an upper layer protocol identification field, it uses a heuristic method to determine the payload type by inspecting the first nibble of the MPLS payload. The first field in an IP packet is the IP version. Therefore, if the value of the first nibble is 4, it is assumed that the payload is IPv4. If the first nibble is 6, however, it is assumed that the payload is IPv6. Because pseudowire packets do not carry raw IP traffic and do not guarantee that the first nibble is either 4 or 6, this can lead to undesired results, in which case pseudowire packets from the same flow are sent in different paths.


To avoid mistreatment for pseudowire data packets, the first nibble in the control word is reserved and set to 0. For VCCV traffic with control channel type 1, the control word is required. Its first nibble is set to 1 to avoid aliasing the payload with an IPv4 or IPv6 packet. However, for VCCV label; therefore, VCCV traffic can take a different path than pseudowire data traffic.



Case Study 9-12: Verifying Data Plane Connectivity



After the VCCV capability has been exchanged, each control channel distinguishes data and VCCV packets as follows:



For CC type 1, a special control word is used. The first nibble is set to 1 to indicate VCCV packets. The first nibble of the control word is set to 0 for all data packets.



For CC type 2, the RA label is placed immediately above the pseudowire label for VCCV packets, and data packets do not have the RA label in the MPLS label stack.




The special control word in CC type 1 also includes a protocol type field to indicate the protocol that is being carried. The protocol type field that is used is the Internet Assigned Numbers Authority (IANA) PPP Data Link Layer (DLL) Protocol Number.


LSP Ping is currently the only supported CV type, where MPLS Echo packets are IPv4 or IPv6 User Datagram Protocol (UDP) packets using the IANA assigned well-known UDP port of 3503. These UDP packets are possibly MPLS labeled. In an MPLS Echo Request, the source IP address is the originating router's outgoing interface address as expected, but the destination IP address is within the reserved range of internal host loopback addresses of 127.0.0.0/8. The IP TTL of the MPLS Echo Request packet is set to 1 so that when all of the MPLS labels are popped, the underlying LSP Ping IP packet is not forwarded, and the RA option is set in the IP header. The format of an LSP Echo packet is shown in Figure 9-10.




Figure 9-10. MPLS Echo Packet Format




The message type is either 1 for MPLS Echo Request or 2 for MPLS Echo Reply. The reply mode can specify no reply, reply via IPv4/IPv6 with or without RA option, or reply via application-level control channel. The ability to specify the reply mode gives great flexibility to LSP Ping. You can use the option with no reply to verify one-way connectivity by checking the Sequence Number field, or you can gather SLA statistics by checking the TimeStamp Sent field. The mode of reply via the application level control channel is currently not further defined. You can choose between the remaining two reply modes of IP with and without RA option when issuing LSP Ping packets from the Cisco IOS command line. The difference and applicability between these two reply modes are covered at the end of this case study.


Currently, the five Type Length Values (TLV) defined are as follows:



Target FEC Stack



Downstream Mapping



Pad



Error Code



Vendor Enterprise Code




In a pseudowire ping, you will use the Target FEC Stack TLV with a pseudowire sub-TLV to identify the pseudowire. Optionally, you will use the Pad TLV and the Vendor Enterprise Code TLV with a Cisco SMI enterprise number of 9.



Note


You can use the MPLS Echo procedures for many different FEC types by specifying a different sub-TLV in Target FEC stack TLV. Besides connectivity verification for pseudowires, you can use MPLS Echo to test the following FEC types: LDP signaled IPv4 and IPv6 prefix FECs, RSVP-TE signaled IPv4 and IPv6 session FECs, and VPN-IPv4 and IPv6 prefix FECs. LSP Ping is used to check connectivity, not only in ping mode, but also in traceroute mode. This section concentrates on pseudowire connectivity testing.


Example 9-58 shows an MPLS Echo Request decoding for a pseudowire.



Example 9-58. MPLS Echo Request Decoding



Ethernet II, Src: xx:xx:xx:xx:xx:xx, Dst: yy:yy:yy:yy:yy:yy
Destination: yy:yy:yy:yy:yy:yy (yy:yy:yy:yy:yy:yy)
Source: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
Type: MPLS label switched packet (0x8847)
MultiProtocol Label Switching Header
MPLS Label: Unknown (17)
MPLS Experimental Bits: 0
MPLS Bottom Of Label Stack: 0
MPLS TTL: 255
MultiProtocol Label Switching Header
MPLS Label: Unknown (22)
MPLS Experimental Bits: 0
MPLS Bottom Of Label Stack: 1
MPLS TTL: 2
MPLS PW Control Channel Header
Control Channel: 0x1
Reserved: 0x000
PPP DLL Protocol Number: IP (0x0021)
Internet Protocol, Src Addr: 10.0.0.201 (10.0.0.201), Dst Addr: localhost (127.0.0.1)
Version: 4
Header length: 24 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 100
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 1
Protocol: UDP (0x11)
Header checksum: 0x5cba (correct)
Source: 10.0.0.201 (10.0.0.201)
Destination: localhost (127.0.0.1)
Options: (4 bytes)
Router Alert: Every router examines packet
User Datagram Protocol, Src Port: 3503 (3503), Dst Port: 3503 (3503)
Source port: 3503 (3503)
Destination port: 3503 (3503)
Length: 76
Checksum: 0x4f8f (correct)
Multiprotocol Label Switching Echo
Version: 1
MBZ: 0
Message Type: MPLS Echo Request (1)
Reply Mode: Reply via an IPv4/IPv6 UDP packet with Router Alert (3)
Return Code: No return code (0)
Return Subcode: 0
Sender's Handle: 0xc8000033
Sequence Number: 1
Timestamp Sent: 2004-05-03 15:32:22.5040 UTC
Timestamp Received: NULL
Target FEC Stack
Type: Target FEC Stack (1)
Length: 20
FEC Element 1: L2 circuit ID
Type: L2 cirtuit ID (9)
Length: 16
Sender's PE Address: 10.0.0.203 (10.0.0.203)
Remote PE Address: 10.0.0.201 (10.0.0.201)
VC ID: 50
Encapsulation: HDLC (6)
MBZ: 0x0000
Pad
Type: Pad (3)
Length: 8
Pad Action: Drop Pad TLV from reply (1)
Padding: ABCDABCDABCDAB


The highlighted lines in Example 9-58 show how an MPLS Echo packet is encapsulated in IP/UDP with the RA option in the IP header, and in turn MPLS-labeled. You can also see that a Pseudowire Control Channel Header is included when using CC type 1.


To verify data connectivity using LSP Ping on Cisco routers, you can execute the ping mpls command with the pseudowire keyword in the EXEC mode. Other available keywords are ipv4 for an LDP IPv4 FEC and traffic-eng for an RSVP-TE Tunnel FEC (see Example 9-59).



Example 9-59. ping mpls pseudowire Command Output



PE1#ping mpls pseudowire 10.0.0.201 100
Sending 5, 100-byte MPLS Echos to 10.0.0.201/0,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not transmitted,
'.' - timeout, 'U' - unreachable,
'R' - downstream router but not target
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
PE1#
PE1#ping mpls pseudowire 10.0.0.201 200
Sending 5, 100-byte MPLS Echos to 10.0.0.201/0,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not transmitted,
'.' - timeout, 'U' - unreachable,
'R' - downstream router but not target
Type escape sequence to abort.
QQQQQ
Success rate is 0 percent (0/5)
PE1#
PE1#ping mpls pseudowire 10.0.0.201 200 reply mode ?
ipv4 Send reply via IPv4
router-alert Send reply via IPv4 UDP with router alert


The first test for the pseudowire with VC ID 100 is successful, and the result is "!!!!!". The second test for the pseudowire with VC ID 200 has a result of "QQQQQ", meaning "request not transmitted." The following are the most common reasons for not transmitting an MPLS Echo Request:



The VC is down.



The peer does not advertise VCCV capabilities.




The ping mpls command allows two different reply modes discussed before: ipv4 and router-alert. The default is ipv4, which is the option normally used. However, if an LSP Ping is unsuccessful and times out (resulting "....."), the failure might occur on the return path. In this case, retry the router-alert reply mode. This mode instructs all intermediate routers in the return path to process the packet. This option is most useful for isolating MPLS switching path problems.


If you do not get a reply to a ping mpls pseudowire using the default IPv4 reply mode, but you do get a successful reply using the RA reply mode, you can infer that a switching path problem exists in the return path, most likely a CEF inconsistency between the linecard and the RP card in an intermediate node. You can reach this conclusion because with RA reply mode, all MPLS Echo Reply packets are punted to the RP to be processed switched.


/ 101