Label Bindings and Propagation in Frame-mode MPLS

The previous section identifies the mechanisms necessary to forward labeled packets between the LSRs using framed interfaces (LAN, point-to-point links, or WAN virtual circuits). This section focuses on FEC-to-label bindings and their propagation between LSRs over framed interfaces.

Cisco IOS software implements two label binding protocols that can be used to associate IP subnets with MPLS labels for the purpose of unicast destination-based routing:

• Tag Distribution Protocol (TDP)? Cisco's pro prietary protocol available in IOS software release 11.1CT, as well as 12.0 and all subsequent IOS releases

• Label Distribution Protocol (LDP)? IETF standard label binding protocol available in 12.2T release

TDP and LDP functionally are equivalent and can be used concurrently within the network, even on different interfaces of the same LSR. Due to their functional equivalence, this section shows only TDP debugging and monitoring commands.

To start MPLS packet labeling for unicast IP packets and associated protocols on an interface, use the commands in Table 2-2.

Table 2-2. IOS Configuration Commands Used to Start MPLS on an Interface

Task	IOS Command
Start MPLS packet labeling and run TDP on the specified interface.	tag-switching ip
Start MPLS packet labeling on the specified interface. TDP is used as the default label distribution protocol. Note: This command is equivalent to the tag-switching ip command:	mpls ip
Select the label distribution protocol on the specified interface.	mpls label-distribution [ ldp | tdp | both ]

LDP/TDP Session Establishment

When you start MPLS on the first interface in a router, the TDP/LDP process is started and the Label Information Base (LIB) structure is created. The router also tries to discover other LSRs on the interfaces running MPLS through TDP hello packets. The TDP hello packets are sent as broadcast or multicast UDP packets, making LSR neighbor discovery automatic. The debug tag tdp transport command can monitor the TDP hellos. Example 2-4 shows the TDP process startup and Example 2-5 illustrates the successful establishment of a TDP adjacency.

Example 2-4 TDP Startup After the First Interface Is Configured for MPLS

SanFrancisco#debug tag tdp transport

TDP transport events debugging is on

SanFrancisco#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

SanFrancisco(config)#interface serial 1/0/1

SanFrancisco(config-subif)#tag-switching ip



1d20h: enabling tdp on Serial1/0/1

1d20h: tdp: 1<tdp_start: tdp_process_ptr = 0x80B7826C

1d20h: tdp: tdp_set_intf_id: intf 0x80E49B74, Serial1/0/1, not tc-atm, intf_id 0

1d20h: enabling tdp on Serial1/0/1

1d20h: tdp: Got TDP Id

1d20h: tdp: Got TDP TCP Listen socket

1d20h: tdp: tdp_hello_process tdp inited

1d20h: tdp: tdp_hello_process start hello for Serial1/0/1

1d20h: tdp: Got TDP UDP socket

Example 2-5 TDP Neighbor Discovery

1d20h: tdp: Send hello; Serial1/0/1, src/dst 172.16.1.4/255.255.255.255, inst_id 0

1d20h: tdp: Rcvd hello; Serial1/0/1, from 172.16.1.1 (172.16.1.1:0), intf_id 0, opt

0x4

1d20h: tdp: Hello from 172.16.1.1 (172.16.1.1:0) to 255.255.255.255, opt 0x4

There also might be cases where an adjacent LSR wants to establish an LDP or TDP session with the LSR under consideration, but the interface connecting the two is not configured for MPLS due to security or other administrative reasons. In such a case, the debugging printout similar to the printout shown in Example 2-6 indicates ignored hello packets being received through interfaces on which MPLS is not configured.

Example 2-6 Ignored TDP Hello

1d20h: tdp: Ignore Hello from 172.16.3.1, Serial0/0/1; no intf

After the TDP hello process discovers a TDP neighbor, a TDP session is established with the neighbor. TDP sessions are run on the well-known TCP port 711; LDP uses TCP port 646. TCP is used as the transport protocol (similar to BGP) to ensure reliable information delivery. Using TCP as the underlying transport protocol also results in excellent flow control properties and good adjustments to interface congestion conditions. Example 2-7 shows the TDP session establishment.

Example 2-7 TDP Session Establishment

1d20h: tdp: New adj 0x80EA92D4 from 172.16.1.1 (172.16.1.1:0), Serial1/0/1

1d20h: tdp: Opening conn; adj 0x80EA92D4, 172.16.1.4 <-> 172.16.1.1

1d20h: tdp: Conn is up; adj 0x80EA92D4, 172.16.1.4:11000 <-> 172.16.1.1:711

1d20h: tdp: Sent open PIE to 172.16.1.1 (pp 0x0)

1d20h: tdp: Rcvd open PIE from 172.16.1.1 (pp 0x0)

After a TDP session is established, it's monitored constantly with TDP keepalive packets to ensure that it's still operational. Example 2-8 shows the TDP keepalive packets.

Example 2-8 TDP Keepalives

1d20h: tdp: Sent keep_alive PIE to 172.16.1.1:0 (pp 0x0)

1d20h: tdp: Rcvd keep_alive PIE from 172.16.1.1:0 (pp 0x0)

The TDP neighbors and the status of individual TDP sessions also can be monitored with show tag tdp neighbor command , as shown in Example 2-9. This printout was taken at the moment when the San Jose router was the only TDP neighbor of the San Francisco router.

Example 2-9 Show Tag TDP Neighbor Printout

SanFrancisco#show tag-switching tdp neighbor

  Peer TDP Ident: 172.16.1.1:0; Local TDP Ident 172.16.1.4:0

  TCP connection: 172.16.1.1.711 - 172.16.1.4.11000

                  State: Oper; PIEs sent/rcvd: 4/4; ; Downstream

                  Up time: 00:01:05

                  TDP discovery sources:

                   Serial1/0.1

    Addresses bound to peer TDP Ident:

    172.16.1.1

The command displays the TDP identifiers of the local and remote routers, the IP addresses and the TCP port numbers between which the TDP connection is established, the connection uptime and the interfaces through which the TDP neighbor was discovered, as well as all the interface IP addresses used by the TDP neighbor.

Label Binding and Distribution

As soon as the Label Information Base (LIB) is created in a router, a label is assigned to every Forward Equivalence Class known to the router. For unicast destination-based routing, the FEC is equivalent to an IGP prefix in the IP routing table. Thus, a label is assigned to every prefix in the IP routing table and the mapping between the two is stored in the LIB.

The Label Information Base is always kept synchronized to the IP routing table?as soon as a new non-BGP route appears in the IP routing table, a new label is allocated and bound to the new route. The debug tag tdp bindings printouts show the subnet-to-label binding. Example 2-10 shows a sample printout.

Example 2-10 Sample Label-to-prefix Bindings

SanFrancisco#debug tag-switching tdp bindings

TDP Tag Information Base (TIB) changes debugging is on

1d20h: tagcon: tibent(172.16.1.4/32): created; find route tags request

1d20h: tagcon: tibent(172.16.1.4/32): lcl tag 1 (#2) assigned

1d20h: tagcon: tibent(172.16.1.1/32): created; find route tags request

1d20h: tagcon: tibent(172.16.1.1/32): lcl tag 26 (#4) assigned

1d20h: tagcon: tibent(172.16.1.3/32): created; find route tags request

1d20h: tagcon: tibent(172.16.1.3/32): lcl tag 27 (#6) assigned

1d20h: tagcon: tibent(172.16.1.2/32): created; find route tags request

1d20h: tagcon: tibent(172.16.1.2/32): lcl tag 28 (#8) assigned

1d20h: tagcon: tibent(192.168.1.0/24): created; find route tags request

1d20h: tagcon: tibent(192.168.1.0/24): lcl tag 1 (#10) assigned

1d20h: tagcon: tibent(192.168.2.0/24): created; find route tags request

1d20h: tagcon: tibent(192.168.2.0/24): lcl tag 29 (#12) assigned

Because the LSR assigns a label to each IP prefix in its routing table as soon as the prefix appears in the routing table, and the label is meant to be used by other LSRs to send the labeled packets toward the assigning LSR, this method of label allocation and label distribution is called independent control label assignment, with unsolicited downstream label distribution:

• The label allocation in routers is done regardless of whether the router has received a label for the same prefix already from its next-hop router or not. Thus, label allocation in routers is called independent control.

• The distribution method is unsolicited because the LSR assigns the label and advertises the mapping to upstream neighbors regardless of whether other LSRs need the label. The on-demand distribution method is the other possibility. An LSR assigns only a label to an IP prefix and distributes it to upstream neighbors when asked to do so. Chapter 3 discusses this method in more detail.

• The distribution method is downstream when the LSR assigns a label that other LSRs (upstream LSRs) can use to forward labeled packets and advertises these label mappings to its neighbors. Initial tag switching architecture also contains provisions for upstream label distribution, but neither the current tag switching implementation nor the MPLS architecture needs this type of distribution method.

All label bindings are advertised immediately to all other routers through the TDP sessions. The advertisements also can be examined by means of debugging commands, as shown in Example 2-11. The printout was taken on the San Francisco router after the route toward 192.168.2.0/24 was propagated from New York to San Francisco via the IGP and entered into the San Francisco LSR's routing table.

Example 2-11 IP Prefix-to-label Binding Propagation Through TDP

1d20h: tagcon: adj 172.16.1.1:0 (pp 0x80EA98E4): advertise 192.168.2.0/24, tag 29

(#12)

1d20h: tagcon: adj 172.16.3.1:0 (pp 0x80EA98E4): advertise 192.168.2.0/24, tag 29

(#12)

1d20h: tagcon: adj 172.16.2.1:0 (pp 0x80EA98E4): advertise 192.168.2.0/24, tag 29

(#12)

1d20h: tagcon: adj 172.16.1.2:0 (pp 0x80EA98E4): advertise 192.168.2.0/24, tag 29

(#12)

1d20h: tagcon: adj 172.16.1.3:0 (pp 0x80EA98E4): advertise 192.168.2.0/24, tag 29

(#12)

1d20h: tdp: Sent bind PIE to 172.16.1.1:0 (pp 0x80EA98E4)



… rest deleted …

As you can see from the printout, the San Francisco router announces its IP prefix-to-label binding to all TDP neighbors, regardless of whether they are upstream or downstream. Even more, the binding also is sent to the next-hop router, so there is no split-horizon processing in TDP or LDP.

The adjacent LSRs receive prefix-to-label mappings, store them in their LIB, and use them in their FIB or LFIB if the mapping has been received from their downstream neighbor, which is the next-hop for the particular FEC in question. This storage method is called liberal retention mode as opposed to conservative retention mode, where an LSR retains only the labels assigned to a prefix by its current downstream routers.

The show tag-switching tdp bindings command can display all the label mappings generated by a router or received from its TDP neighbors. Example 2-12 displays the result of that command for IP prefix 192.168.2.0/24 on the San Francisco router.

Example 2-12 Label Information Base Entry on San Francisco Router

SanFrancisco#show tag-switching tdp bindings 192.168.2.0

  tib entry: 192.168.2.0/24, rev 7

                   local binding:  tag: 30

                   remote binding: tsr: 172.16.1.1:0, tag: 33

                   remote binding: tsr: 172.16.1.2:0, tag: 35

                   remote binding: tsr: 172.16.1.3:0, tag: 23

                   remote binding: tsr: 172.16.2.1:0, tag: 59

                   remote binding: tsr: 172.16.3.1:0, tag: 28

SanFrancisco#

A router might receive TDP bindings from a number of neighbors, but uses only a few of them in the forwarding tables as follows:

• The label binding from the next-hop router is entered in the corresponding FIB entry. If the router doesn't receive the label binding from the next-hop router, the FIB entry specifies that the packets for that destination should be sent unlabeled.

• If the router receives a label binding from the next-hop router, the local label and the next-hop label are entered in the LFIB. If the next-hop router didn't assign a label to the corresponding prefix, the outgoing action in LFIB is unlabeled. Example 2-13 shows both cases.

Example 2-13 Label Forwarding Information Base on San Francisco Router

SanFrancisco#show tag forwarding-table tags 30-31

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

30     28          192.168.2.0/32    0          Se0/0/1    172.16.3.1

31     untagged    192.168.100.4/32  0          Se1/0/3    172.16.1.3

Convergence in a Frame-mode MPLS Network

An important aspect in MPLS network design is the convergence time of the network. Some MPLS applications (for example, an MPLS/VPN or BGP design based on MPLS) do not work correctly unless a labeled packet can be sent all the way through from the ingress Edge-LSR to the egress Edge-LSR. In these applications, the convergence time needed by an Interior Gateway Protocol (IGP) to converge around a failure in the core network could be increased by the label propagation delay.

In a Frame-mode MPLS network, using liberal retention mode in combination with independent label control and unsolicited downstream label distribution minimizes the TDP/LDP convergence delay. Every router using liberal retention mode usually has label assignments for a given prefix from all its TDP/LDP neighbors, so it can always find a proper outgoing label following the routing table convergence without asking its new next-hop router for the label assignment.

The next set of examples, based on a failure scenario (the link between Washington and San Francisco fails) in the SuperNet network, illustrate the immediate convergence. The examples observe only the route toward network 192.168.100.2/32, which is attached to the New York router.

The show command printouts (see Example 2-14) in the initial state indicate that the target route is reachable through interface Serial0/0/1 through next-hop 172.16.3.1.

Example 2-14 TDP, LFIB, and FIB Entries Prior to Link failure

SanFrancisco#show tag-switching tdp binding 192.168.100.2 32

  tib entry: 192.168.100.2/32, rev 10

        local binding:  tag: 28

        remote binding: tsr: 172.16.2.1:0, tag: 28

        remote binding: tsr: 172.16.3.1:0, tag: 32



SanFrancisco#show tag-switching forwarding 192.168.100.2

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

28     32          192.168.100.2/32  0          Se0/0/1    point2point

SanFrancisco#show ip cef 192.168.100.2

192.168.100.2/32, version 76, attached

0 packets, 0 bytes

  tag information set, shared, unshareable

    local tag: 28

  via Serial0/0/1, 9 dependencies

    valid adjacency

    tag rewrite with Se0/0/1, point2point, tags imposed: {32}

Immediately following the link failure, the LFIB is scanned to clean up any entries that used the failed interface as the outgoing interface (see Example 2-15)

Example 2-15 LFIB Scan Following a Link Failure

SanFrancisco#sh debug

IP routing:

  IP routing debugging is on

Tag Switching:

  TDP Tag Information Base (TIB) changes debugging is on

  TDP tag and address advertisements debugging is on

  Cisco Express Forwarding related TFIB services debugging is on



SanFrancisco#

3d03h: %LINK-5-CHANGED: Interface Serial0/0/1, changed state to down

3d03h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state

to down

3d03h: TFIB: fib scan start:needed:1,unres:0,mac:0,mtu:0,loadinfo:0,scans aborted 0

3d03h: TFIB: fib check cleanup for 192.168.100.2/32,index=0,return_value=0

3d03h: TFIB: fib_scanner_walk,reslve path 0 of 192.168.100.2/32

3d03h: TFIB: resolve tag rew,prefix=192.168.100.2/32,has tag_info,no parent

3d03h: TFIB: finish fib res 192.168.100.2/32:index 0,parent outg tag no parent

3d03h: TFIB: set fib rew: pfx 192.168.100.2/32,index=0,add=1,tag_rew->adj=Serial 0/

0/1

3d03h: TFIB: Update TFIB for 192.168.100.2/32, fib no loadinfo, tfib no loadinfo,

per_pkt,resolved=1

3d03h: TFIB: fib_scanner_end

The failed interface then is removed from the routing table and the associated routes are removed from the IP routing table. Because no alternative equal-cost route toward 192.168.100.2/32 currently exists, the route is removed completely from the routing table and the associated entry is deleted from the LFIB (see Example 2-16).

Example 2-16 Routing Table and LFIB Cleanup

3d03h: RT: interface Serial0/0/1 removed from routing table

3d03h: RT: delete route to 192.168.100.2 via 0.0.0.0, Serial0/0/1

3d03h: RT: no routes to 192.168.100.2, flushing

3d03h: TFIB: tfib_fib_delete,192.168.100.2/32,fib->count=1

3d03h: TFIB: fib complete delete: prefix=192.168.100.2/32,inc tag=28,del info=1

3d03h: TFIB: deactivate tag rew for 192.168.100.2/32,index=0

3d03h: TFIB: Update TFIB for 192.168.100.2/32, fib no loadinfo, tfib no loadinfo

, per_pkt,resolved=0

3d03h: TFIB: set fib rew: pfx 192.168.100.2/32,index=0,add=0,tag_rew->adj=Serial 0/

0/1

An alternate route to 192.168.100.2 goes through the Denver router. The OSPF process immediately installs the alternate route in the routing table. Corresponding CEF and LFIB entries are created and the LFIB entry gets the label assigned by 172.16.2.1 (the Denver router) as its outgoing label. The new LFIB entry is installed without any TDP/LDP interaction with any TDP/LDP neighbors (see Example 2-17).

Example 2-17 Alternate Route Is Installed in the Routing Table

3d03h: RT: add 192.168.100.2/32 via 172.16.2.1, ospf metric [110/21]

3d03h: TFIB: post table chg,ROUTE_UP 192.168.100.2/32,loadinfo ct=1

3d03h: TFIB: find_rt_tgs,192.168.100.2/32,meth 1,res_next_hop=172.16.2.1, Se0/0/2

,next_hop 172.16.2.1

3d03h: TFIB: route tag chg 192.168.100.2/32,idx=0,inc=28,outg=28,enabled=0x1

3d03h: TFIB: create tag info 192.168.100.2/32,inc tag=28,has no info

3d03h: TFIB: resolve tag rew,prefix=192.168.100.2/32,has tag_info,no parent

3d03h: TFIB: finish fib res 192.168.100.2/32:index 0,parent outg tag no parent

3d03h: TFIB: set fib rew: pfx 192.168.100.2/32,index=0,add=1,tag_rew->adj=FastEt

hernet0/0

3d03h: TFIB: Update TFIB for 192.168.100.2/32, fib no loadinfo, tfib no loadinfo

, per_pkt,resolved=1

As the last step, all entries from the TDP neighbor 172.16.3.1 (the Washington router), which is no longer reachable, are removed from the Label Information Base (see Example 2-18)

Example 2-18 LIB Entries Received from Washington Router Are Removed

3d03h: tagcon: tibent(192.168.100.2/32): rem tag 1 from 172.16.3.1:0 removed

3d03h: tagcon: no route_tag_change for: 192.168.100.2/32

        for tsr 172.16.3.1:0: tsr is not next hop

3d03h: TFIB: resolve recursive: share rewrite of parent 192.168.100.2/32

Copyright eTutorials.org 2008-2023. All rights reserved.