LDP for LCATM

This section covers some specifics on LDP when running on an LC-ATM interface.

Label Space

Per-interface label space is used for LC-ATM interfaces. As you can see in Example 5-12, it means that the peer LDP is not identified with router-id:0 as in the non-LC-ATM case. The number following the peer LDP router Identifier is now non-zero. If you have multiple links between a pair of ATM LSRs, multiple label spaces will exist between them. Look at Example 5-12 to see that the ATM LSRs washington-atm and brussels-atm have two ATM links between them and two label spaces.

Example 5-12 Per-Interface Label Space

washington-atm#show mpls ldp discovery

Local LDP Identifier:

10.200.253.2:0

Discovery Sources:

Interfaces:

ATM0/0/0 (ldp)

xmit/recv

LDP Id: 10

200.253.3:1

ATM0/0/1 (ldp)

xmit/recv

LDP Id: 10

200.253.1:1

ATM0/0/2 (ldp)

xmit/recv

LDP Id: 10

200.253.4:1

ATM0/0/3 (ldp)

xmit/recv

LDP Id: 10

200.253.3:4

washington-atm#show mpls ldp neighbor 10.200.253.3

Peer LDP Ident: 10.200

253.3:1; Local LDP Ident 10.200.253.2:3

TCP connection

10.200.253.3.11215 - 10.200.253.2.646

State: Oper; Msgs sent/rcvd: 471/450; Downstream on demand

Up time: 04:46

55

LDP discovery sources:

ATM0/0/0, Src IP addr: 10.200.253.3

Peer LDP Ident: 10.200

253.3:4; Local LDP Ident 10.200.253.2:4

TCP connection:

10.200.253.3.11225 - 10.200.253.2.646

State: Oper; Msgs sent/rcvd: 4/4; Downstream on demand

Up time: 00:02

02

LDP discovery sources:

ATM0/0/3, Src IP addr: 10.200.253.3

Loop Detection by LDP

Loop detection in LDP is optional. It consists of the usage of a Hop Count TLV and a Path Vector TLV to find out if an LSP is looping or if Label Request messages are looping. Routing loops can be permanent, but these are rather rare or are the result of a configuration error. Transient loops do occur more often and can be short in nature. They are often the result of the routing protocol converging and one LSR converging faster than the other. If labeled packets are looping, the label TTL eventually reaches 0, and the packet is dropped. However, ATM LSRs forward cells instead of frames. The ATM cells do not have a TTL value, so ATM LSRs cannot use this mechanism. Because an LSP is a VC on ATM LSRs, a mechanism is needed to make sure that the VCs do not loop. Cisco ATM LSRs use both the Hop Count TLV and Path Vector TLV to prevent a looped LSP from being signaled in the first place. When a loop is detected in Cisco IOS, the LSR periodically resends Label Request messages to try to set up the LSP.

Loop Detection by Hop Count TLV

A Hop Count TLV holds the number of LSRs that the LDP message has traversed. Every LSR that sees this TLV must increment the hop count by 1. A loop is detected when a configured maximum hop count value is reached. Following is the command to enable loop detection by means of the Hop Count TLV in Cisco IOS:

mpls ldp maxhops number

The default value for the maximum hop count argument (number) is 254.

You can configure the maximum hop count to be n. The ingress LSR of a FEC sends an LDP Label Request message with a hop count of 1. The next LSR that receives this request must increase the hop count by 1 in its request, and so on. The same is true for Label Mapping messages. There, the egress LSR must send the first LDP Label Mapping message with a hop count of 1. Subsequent LSRs increase the hop count value by 1. If the MPLS network consists of a part with ATM LSRs and a part with router LSRs, the LSRs at the edge of the ATM domain reset the hop count value to 1, because the ATM LSRs are not "hop count-capable." When an ATM LSR detects that the hop count has reached the maximum configured value n, it returns a Loop Detected Notification message to the source of the Label Request or Label Mapping message. The Label Request or Label Mapping message is not answered with a Label Mapping message. It also is not propagated or used.

Figure 5-8 shows how to use the mpls ldp maxhops command. If the routing protocol is in a looped status around the network, the Label Request message can also be looping.

Figure 5-8 Usage of ldp maxhops Command

Loopback 0 10.200.253.1/32

Loopback 0 10.200.253.1/32

Label Request for 10.200.253.6/32

Label Request for 10.200.253.6/32

Example 5-13 shows the ATM LSR brussels, which detected a hop count that exceeded the maximum hop count configured. The LSR learns this as soon as it receives an LDP Notification message indicating that the hop count was exceeded.

Example 5-13 Hop Count Exceeded brussels#show mpls atm-ldp bindings

Destination: 10.200.253.4/32

Headend Router ATM3/0.10 (3 hops) 1/36 Active, VCD=748 Destination: 10.200.253.5/32

Headend Router ATM3/0.10 (hop count exceeded) -/- BindWait

%TDP-4-HOPCOUNT_EXCEEDED: Peer = 10.200.253.3:3 Label Mapping(10.200.253.5/32) Maxhop=10 hopcount=10 ATM3/0.10

If the ATM LSRs are running LDP in Independent Control mode, the initial hop count value is set to 0. A hop count of 0 indicates that the real hop count is unknown. If an ATM LSR later receives a Label Mapping message from a downstream neighbor with a non-zero hop count, it sends a new Label Mapping message to the upstream neighbor with an updated hop count. This continues until the ingress ATM LSR receives the Label Mapping message with the real hop count through the ATM network.

Example 5-14 shows the prefix 10.200.253.6/32 with an unknown hop count as a result of the Independent Control mode. The correct hop count is learned later from a downstream LSR.

Example 5-14 Unknown Hop Count denver#show mpls atm-ldp bindings

Destination: 10.200.253.1/32

denver#show mpls atm-ldp bindings

Destination: 10.200.253.1/32

Headend

Router

ATM1/0/0.10

(1

hop) 1

/33

Active,

VCD=189

Destination

: 10.200.253.2/32

Headend

Router

ATM1/0/0.10

(2

hops)

1/34

Active

VCD

=190

Destination

: 10.200.253.3/32

Headend

Router

ATM1/0/0.10

(2

hops)

1/35

Active

VCD

=191

Destination

: 10.200.253.4/32

Headend

Router

ATM1/0/0.10

(3

hops)

1/36

Active

VCD

=192

Destination: 10.200.253.6/32

Headend Router ATM1/0/0.10 (hop count unknown) 1/44 Active, VCD=200 Destination: 10.200.253.5/32

Tailend Router ATM1/0/0.10 1/33 Active, VCD=189

Destination: 10.200.253.6/32

Headend Router ATM1/0/0.10 (hop count unknown) 1/44 Active, VCD=200 Destination: 10.200.253.5/32

Tailend Router ATM1/0/0.10 1/33 Active, VCD=189

TTL Manipulation

ATM LSRs cannot decrement the TTL value at each hop. You can use the mechanism described in the previous section by means of the hop count propagated by LDP to set the TTL value of a labeled packet before it enters the ATM domain. As you can see in Example 5-14, the hop count is present for each binding that is received. You can determine the incoming TTL of a packet on the ingress ATM LSR either from the IP TLL if the packet is received as an IP packet or from the TTL in the top label if the packet is received as a labeled packet. This incoming TLL is decremented by 1 to arrive at the new TTL. Then two things are possible: You can use this TTL on the ingress ATM LSR to send the packet, or you can use this TTL minus the reported hop count in the label binding for the prefix to send the packet. The result of the latter is that the TTL set on the packet when it leaves the ingress ATM LSR already has the number of hops through the ATM domain calculated in. If, however, the result of that subtraction is 0 or less, the packet is discarded on the ingress ATM LSR. Look at Figure 5-9. If a packet arrives with a TTL of 3, the ingress ATM LSR does not forward it, because the hop count through the ATM domain is deemed too large. If, however, a packet that has a TTL of 200 arrives on the ingress ATM LSR, it is forwarded with a TTL of 197. The egress ATM LSR then sees an incoming packet with a TTL of 197.

Figure 5-9 TTL Through ATM Domain

Figure 5-9 TTL Through ATM Domain

IP

Label Mapping

Label Mapping

Label Mapping

Hop Count = 3

Hop Count = 2

Hop Count = 1

<-

<-

<-

Cisco IOS uses the first possible method. The ingress ATM LSR only decrements the TTL by 1 before sending the packet—as ATM cells—into the ATM cloud. This method has the advantage of a clean traceroute output. If Cisco IOS were to use the second method, the ingress ATM LSR would have to reply to multiple traceroute probes, as many as there are ATM LSRs on the path. That would cause the ingress ATM LSR to show up in multiple lines of the traceroute output.

A traceroute through the MPLS network does not show the ATM part of the network. The ATM part is missing from the traceroute output. The ATM LSRs have the same affect on traceroute as if you were to configure no mpls ip propagate-ttl on the edge LSRs of an MPLS network without ATM. Example 5-15 shows a traceroute from the router LSR san-francisco (connected to the LSR denver) to the LSR brussels. As you can see, the ATM switches are not reported in the traceroute output.

Example 5-15 Traceroute Example san-francisco#traceroute 10.200.253.6

Type escape sequence to abort. Tracing the route to 10.200.253.6

1 10.200.200.2 [MPLS: Label 21 Exp 0] 4 msec 0 msec 0 msec (LSR denver)

NOTE Refer to Chapter 13, "Troubleshooting MPLS Networks," to see how tracerouting through an MPLS network operates and what the command mpls ip propagate-ttl does.

Loop Detection by Path Vector TLV

A Path Vector TLV holds the list of the LSRs that an LDP message has traversed. The list holds the LSR Identifier—the first four bytes of the LDP Identifier—of the traversed LSRs. Each LSR that propagates the LDP message containing the Path Vector TLV must add its own LSR Identifier to the TLV. A loop is detected when an LSR receives an LDP message with a Path Vector TLV containing its own LSR Identifier. In Cisco IOS, the command to enable loop detection by means of the Path Vector TLV is this:

mpls ldp loop-detection

When an LSR detects a loop in the received Label Request message or in the Label Mapping message, it must send a Loop Detected Notification message to the source of that LDP message. Example 5-16 shows the result of turning on loop detection with the Path Vector TLV. The path information of the label bindings lists the LSR Identifier of the traversed LSRs.

Example 5-16 Bindings with Path Information

denver#show

mpls atm-ldp bindings

path

Destination

: 10.200.253.1/32

Headend

Router ATM1/0/0.10

(1

hop)

1/33

Active,

VCD=254

Path:

10.200.253.5*

1(

.200.

253.1

Destination

: 10.200.253.2/32

Headend

Router ATM1/0/0.10

(2

hops)

1/52

Active

VCD=

263

Path:

10.200.253.5*

1(

.200.

253.1

10.200.253

.2

Destination

: 10.200.253.3/32

Headend

Router ATM1/0/0.10

(2

hops)

1/44

Active

VCD=

260

Path:

10.200.253.5*

1(

.200.

253.1

10.200.253

.3

Destination

: 10.200.253.4/32

Headend

Router ATM1/0/0.10

(3

hops)

1/53

Active,

VCD=

264

Path:

10.200.253.5*

1(

.200.

253.1

10.200.253

.2

10.200.253.4

When the LSRs are running in Independent Control mode, they might need to send multiple Label Mapping messages when either method of loop detection is turned on. As an LSR receives a Label Mapping message from a downstream neighbor with either an updated Hop Count TLV or Path Vector TLV present, it must send a Label Mapping message upstream with that updated TLV. That means many Label Mapping messages might be sent for one LSP. You can avoid this when running Ordered Control mode on the ATM LSRs because the LSRs send only one Label Request and one Label Mapping message per LSP.

For either loop detection method to properly function, it must be turned on for all LSRs that are running LDP. Otherwise, inconsistencies can occur.

LDP Address Messages

An LSR that is running LDP can advertise its IP addresses via LDP. As mentioned in Chapter 2, labels can be advertised in two modes: UD and DoD. LDP can run in both modes. Chapter 4, "Label Distribution Protocol," deals with LDP and explains a bit more the differences in the two modes. It covers why LDP in UD mode must advertise the IP addresses of the LSRs. Without it, the LSRs cannot build the LFIB needed to forward labeled packets, because they need to associate a next hop from the routing table with a peer LDP Router Identifier.

ATM LSRs run in DoD mode and only need to request a label from their downstream neighbor. Furthermore, only one LDP peer exists per LC-ATM interface. Therefore, mapping the received label to the downstream LDP peer is straightforward, and as a result, ATM LSRs really do not need to send their IP addresses to their LDP neighbors. Cisco ATM LSRs run label advertisement in DoD mode and do not advertise their IP addresses. However, you can enable them to advertise their IP addresses anyway. The advantage of doing this is that other vendor ATM LSRs might require the IP addresses to be sent. The Cisco IOS interface command to enable the advertisement of the IP addresses to LC-ATM LDP peers is this:

mpls ldp address-message

When this command is enabled on the brussels-atm LSR, it advertises its IP addresses to its neighbors. Example 5-17 shows that the neighboring LSR brussels has the one IP address of brussels-atm as a bound IP address to that LDP peer.

Example 5-17 Advertised Addresses brussels#show mpls ldp neighbor

Peer LDP Ident: 10.200.253.3:3; Local LDP Ident 10.200.253.6:1 TCP connection: 10.200.253.3.646 - 10.200.253.6.47852 State: Oper; Msgs sent/rcvd: 75/93; Downstream on demand Up time: 00:53:41 LDP discovery sources:

ATM3/0.10, Src IP addr: 10.200.253.3 Addresses bound to peer LDP Ident: 10.200.253.3

Blocking Label Requests

The command mpls ldp request-labels is used for LC-ATM interfaces instead of the command mpls ldp advertise-labels to block label advertisements.

mpls ldp request-labels for acl

You can configure this command on the ATM LSRs to stop them from sending Label Requests for IP prefixes that do not need an LSP to be set up. Example 5-18 shows the edge ATM LSR denver with this command and 1 stopping it from sending Label Requests for anything other than IP addresses from the range 10.200.253.0/24.

Example 5-18 Blocking Label Requests on Edge ATM LSR

hostname denver !

mpls label protocol ldp

mpls ldp router-id Loopback0 force

mpls ldp request-labels for 1 !

access-list 1 permit 10.200.253.0 0.0

.0.255

access-list 1 deny any !

In general, you want to block LVCs from being set up for IP prefixes that are not important—IP prefixes that do not carry customer or through traffic. In the example of MPLS VPN, the important prefixes in the MPLS network are the PE loopback IP addresses because they are the BGP next-hop IP addresses. These IP addresses carry the VPN customer traffic across the MPLS cloud. Refer to Chapter 7, "MPLS VPN," to understand why the BGP next-hop IP addresses are important prefixes in MPLS VPN networks.

Micro Expression Master

Micro Expression Master

If You Could Read Everyone Life A Book You Can Have Better Career, Great Relationships And Become Successful. This Book Is One Of The Most Valuable Resources In The World When It Comes To Reading the smallest and tiniest body Language and know what people are thinking about.

Get My Free Ebook


Post a comment