Advertising of Label Mappings

Advertising label mappings or label bindings is the main purpose of LDP. Chapter 2 explains the three different modes in which the LSRs can behave: advertisement, label retention, and LSP control mode. Each of the three modes has two possibilities, which leads to the following six modes:

■ Unsolicited Downstream (UD) versus Downstream-on-Demand (DoD) advertisement mode

■ Liberal Label Retention (LLR) versus Conservative Label Retention (CLR) mode

■ Independent LSP Control versus Ordered LSP Control mode

No matter what mode the LDP peers operate in, the purpose is to advertise label bindings. In UD advertisement mode, the LDP peer distributes the label bindings unsolicited to its LDP peers. However, the label bindings are a set of (LDP Identifier, label) per prefix. An LDP router receives multiple label bindings for each prefix—namely, one per LDP peer. All these label bindings are stored in the LIB of the router. However, only one LDP peer is the downstream LSR for that particular prefix. Of course, if load balancing exists, it is possible to have more than one downstream LSR.

The downstream LSR is found by looking up the next hop for that prefix in the routing table. Only the remote binding associated with that next-hop LSR should be used to populate the LFIB. This means that only one label from all the advertised label bindings from all the LDP neighbors of this LSR should be used as outgoing label in the LFIB for that prefix. The problem is that the label bindings are advertised as (LDP Identifier, label) without the IP addresses of the interfaces. This means that to find the outgoing label for a particular prefix, you must map to the LDP Identifier the IP address of the interface—pointing back to this LSR—on the downstream LSR. You can only do this if each LDP peer advertises all its IP addresses. These IP addresses are advertised by the LDP peer with Address messages and withdrawn with Withdraw Address messages. You can find these addresses when you are looking at the LDP peer. They are called the bound addresses for the LDP peer. Example 4-8 shows the bound addresses to peer 10.200.254.2 (london) on LSR new-york.

Example 4-8 LDP Bound IP Addresses

new-york#show mpls ldp neighbor detail

Peer LDP Ident: 10.200.254.2:0; Local LDP

Ident 1

0.200.254.1:0

TCP connection: 10.200.254.2.646 - 10.

200.255

.1

.64481

State: Oper; Msgs sent/rcvd: 1303/1289

; Downstream; Last TIB

rev sent 743

Up time: 17:20:24; UID: 101; Peer Id 0

;

LDP discovery sources:

Ethernet1/1; Src IP addr: 10.200.210

.2

holdtime: 15000 ms, hello interval

: 5000

ms

Ethernet1/2; Src IP addr: 10.200.218

.2

holdtime: 15000 ms, hello interval

: 5000

ms

Addresses bound to peer LDP Ident:

10.200.254.2 10.200.210.2 10.200.218.

2

10.200.211

1

10.200.215.1

Peer holdtime: 180000 ms; KA interval:

60000

ms

; Peer state:

estab

Each LSR assigns one local label to each IGP prefix in the routing table. This is the local label binding. These local bindings are stored in the LIB on the router. Each of these labels and the prefixes they are assigned to are advertised via LDP to all the LDP peers. These label bindings are the remote bindings on the LDP peers and are stored in the LIB. Example 4-9 shows the LIB on an LSR.

Example 4-9 Example of a LIB

london#show mpls ldp bindings

lib entry: 10.200.210

0/24,

rev 4

local binding:

label:

imp-null

remote binding:

lsr: 1

0.200.254

5

0, label:

16

remote binding:

lsr: 1

0.200.254

1:

0, label:

imp

null

remote binding:

lsr: 1

0.200.254

3:

0, label:

19

lib entry: 10.200.211

0/24,

rev 12

local binding:

label:

imp-null

remote binding:

lsr: 1

0.200.254

5:

0, label:

18

remote binding:

lsr: 1

0.200.254

1:

0, label:

32

remote binding:

lsr: 1

0.200.254

3:

0, label:

imp

null

lib entry: 10.200.254

1/32,

rev 31

local binding:

label:

24

remote binding:

lsr: 1

0.200.254

5:

0, label:

22

remote binding:

lsr: 1

0.200.254

1:

0, label:

imp

null

remote binding:

lsr: 1

0.200.254

3:

0, label:

26

As you can see, for each prefix, the LSR always has one local binding and one remote binding per LDP peer.

Example 4-10 shows another command to have a look at the LIB on the LSR. The one "in label" entry refers to the local binding. The "out label" entries refer to the remote bindings. Each time, you can see the label and the LDP Identifier of the LSR that sent the remote binding.

Example 4-10 Example of a LIB

london#show mpls ip

binding

10.200.210.0/24

in label:

imp-null

out label:

16

lsr:

10

0 0 2

254

5:

0

out label:

imp-null

lsr:

10

0 0 2

254

1:

0

out label:

19

lsr:

10

0 0 2

254

3:

0

10.200.211.0/24

in label:

imp-null

out label:

18

lsr:

10

0 0 2

254

5:

0

out label:

32

lsr:

10

0 0 2

254

1:

0

out label:

imp-null

lsr:

10

0 0 2

254

3:

0

10.200.254.1/32

in label:

24

out label:

22

lsr:

10

0 0 2

254

5:

0

out label:

imp-null

lsr:

10

0 0 2

254

1:

0 inuse

out label:

26

lsr:

10

0 0 2

254

3:

0

The advantage of the command show mpls ip binding is that it also shows which label from all possible remote bindings is used to forward traffic by indicating inuse. Inuse indicates the outgoing label in the LFIB for that prefix.

Look at Figure 4-4 to see the association among the RIB, the bound addresses from the LDP peers, the LIB, and the LFIB.

Figure 4-4 Relationship Among Bound Addresses, RIB, LIB, and LFIB

RIB (Routing Table)

london#show mpls Idp bindihgs':j£,_200,254,4 255,255,255,255;:'

local binding; C}.abel; 2$: remote binding; Isr; ~10,200,!254,1 ;0, label! 19 remote binding; Isr; 10,200,¡254,5:0, labelY 23 remote binding; lfir:«;"1*0**200,254,3fRelabel:

london#show ip routfiT.'j0,200,254,4 255.255.25_5_._2C5:-Routing entry for 10,2^0,254,4/32 \

Known via "ospf^l", distance 110, metric 21,Xype intra area Last update /torn 10,200,211,2 on POS5/0/0, 00;00>;[email protected] aoo Routing De^briptor Blocks; ^

C?**10,200,211 from 10,200,254,4 , 00:00:09 ago,<via POS5/0/0 ^ Route metric is 21, traffic share count is 1

Next-hop IP Address

LFIB

LDP Peers lond^h#show mpls forwarding-table 10,200,254,4 255,255,255,255

Lo^l Label

Ousting Label or VC

Prefix or Tunnel Id

10,200,254,4/32

Bytes Label Outgoing Ne«t Hop Swit ch ed in t e r face ^ 0 PO5/0/0 point2poir

1632/1632; Downstream london#show mpls Idp neic^bor pos 5/0/0

Peer LDP I dentil¡0,200,^54,3?jj&* Local LDP Ident 10,200,254,2;i TCP connect ion; ^.{0,^00,254,3,28676 - 10,200,254,2,646 State; Oper; Us^s sei^t/rcvd; Up time; 23:31;56* \ LDP discovery sourfees; \

POS5/0/0, Src IP Sddr;^ 10,200,2-Addresses bound to pteer LDP Ident: 10,200,254,3 O®• 200,2112"J> *

Figure 4-4 shows the example of building the LFIB entry for one FEC bound to the prefix 10.200.254.4/32. The incoming/local label for the prefix is found directly in the LIB, but the outgoing label is found through the RIB, the bound addresses of the LDP peers, and the LIB.

Note that LDP assigns local labels to all IGP prefixes and advertises the bindings to all LDP peers. The concept of split horizon does not exist; an LDP peer assigns its own local label to a prefix and advertises that back to the other LDP peer, even though that other LDP peer owns the prefix (it is a connected prefix) or that other LDP peer is the downstream LSR. Look at Figure 4-5, which shows a simple network with two LSRs. Router london owns the prefix 10.200.254.2/32 because it is the prefix on the loopback 0. This router advertises its binding for the prefix to rome. The advertised label is label implicit NULL. In turn, router london receives the remote binding for the prefix 10.200.254.2/32 from router rome, even though the router london owns the prefix.

Figure 4-5 No LDP Split Horizon

LDP Label Mapping Message <10.200.254.2/32, imp-null>

24 is the local label for 10.200.254.2/32

Loopback 0

Loopback 0

10.200.211.1

10.2

10.2

rome

LDP Label Mapping Message <10.200.254.2/32,24>

Look at Example 4-11 for the label bindings for that prefix on routers london and rome. Example 4-11 Bindings for 10.200.254.2/32 for Figure 4-5

london#show interfaces loopback 0

Loopback0 is up, line protocol is up Hardware is Loopback Internet address is 10.200.254.2/32

london#show mpls ldp bindings 10.200.254.2 255.255.255.255

rome#show mpls ldp bindings 10.200.254.2 255.255.255.255

lib entry: 10.200.254.2/32, rev 787 local binding: label: 24

remote binding: lsr: 10.200.254.4:0, label: 23 remote binding: lsr: 10.200.254.2:0, label: imp-null

Label Withdrawing

When an LDP peer advertises a label binding, the receiving LDP peers keep it until the LDP session goes down or until the label is withdrawn. The label might be withdrawn if the local label changes. The local label might change if, for example, the interface with a certain prefix on it goes down, but another LSR still advertises the prefix. Therefore, the local label for that prefix changes from implicit NULL to a non-reserved label. If this happens, the implicit NULL label is immediately withdrawn by sending a Label Withdraw message to the LDP peers. The new label local binding: label: imp-null remote binding: lsr: 10.200.254.5:0, label: 21 remote binding: lsr: 10.200.254.1:0, label: 25 remote binding: lsr: 10.200.254.3:0, label: 24

is advertised in a Label Mapping message. In Example 4-12, the Ethernet interface with IP prefix 10.200.210.0/24 goes down on the LSR london. That is why london withdraws the prefix with the label implicit NULL. The LSR new-york still announces the prefix, though, assuming that there is a Layer 2 switch between new-york and london, so that the new-york side of the Ethernet link remains up. LSR london assigns a new local label (27) to the prefix and announces that new label in a label mapping message to the LSR madrid.

Example 4-12 Label Withdraw madrid#debug mpls ldp messages received

LDP received messages, excluding periodic Keep Alives debugging is on madrid#debug mpls ldp bindings

LDP Label Information Base (LIB) changes debugging is on madrid#show debugging MPLS ldp:

LDP Label Information Base (LIB) changes debugging is on

LDP received messages, excluding periodic Keep Alives debugging is on

:06

29:

:06

29:

:06

ldp: Rcvd address withdraw msg from 10.200.254.2:0 (pp 0x63E3C128) tagcon: 10.200.254.2:0: 10.200.210.2 removed from addr<->ldp ident map tagcon: rib change: 10.200.210.0/24; event 0x4; ndb attrflags 0x1000000; ndb->pdb_index 0x2

):06:34: tagcon: rib change: 10.200.210.0/255.255.255.0; event 0x4; ndb attrflags 0x1000000; ndb->pdb_index 0x2/undef ldp: Rcvd label withdraw msg from 10.200.254.2:0 (pp 0x63E3C128) tagcon: tibent(10.200.210.0/24): label imp-null from 10.200.254.2:0 removed tib: get path labels: 10.200.210.0/24, tableid: 0, Et3/1, nh 10.200.215.1 tagcon: announce labels for: 10.200.210.0/24; nh 10.200.215.1, Et3/1, inlabel 17, outlabel unknown (from 10.200.254.2:0), get path labels ldp: Rcvd label mapping msg from 10.200.254.2:0 (pp 0x63E3C128) tagcon: tibent(10.200.210.0/24): label 27 from 10.200.254.2:0 added tib: get path labels: 10.200.210.0/24, tableid: 0, Et3/1, nh 10.200.215.1 tagcon: announce labels for: 10.200.210.0/24; nh 10.200.215.1, Et3/1, inlabel 17, outlabel 27 (from 10.200.254.2:0), get path labels

:06

36:

:06

36:

:06

36:

:06

36:

:06

36:

:06

36:

:06

36:

:06

36:

In older Cisco IOS software (pre 12.0(21)ST), the default behavior was not to send a Label Withdraw message to withdraw the label before advertising the new label for the FEC. The new label advertisement was also an implicit label withdraw. If you want to keep the old behavior, you must configure the command mpls ldp neighbor neighbor implicit-withdraw. Example 4-13 shows what happens when a new label is advertised for the prefix 10.200.210.0/24 with implicit-withdraw configured on the LDP peer london. The label withdraw message is missing from the debug output. The advantage of this command is the avoidance of sending the Label Withdraw messages, which equates to less overhead.

Example 4-13 Label Implicit-Withdraw hostname london

mpls ldp neighbor 10.200.254.5 implicit-withdraw mpls ldp router-id Loopback0 force mpls label protocol ldp

madrid#

00:15:03: ldp: Rcvd address withdraw msg from 10.200.254.2:0 (pp 0x63E3C128) 00:15:03: tagcon: 10.200.254.2:0: 10.200.210.2 removed from addr<->ldp ident map 00:15:06: ldp: Rcvd label mapping msg from 10.200.254.2:0 (pp 0x63E3C128) 00:15:06: tagcon: tibent(10.200.210.0/24): label imp-null from 10.200.254.2:0 impl withdraw

00:15:06: tagcon: tibent(10.200.210.0/24): label 27 from 10.200.254.2:0 added 00:15:06: tib: get path labels: 10.200.210.0/24, tableid: 0, Et3/1, nh 10.200.215.1 00:15:06: tagcon: announce labels for: 10.200.210.0/24; nh 10.200.215.1, Et3/1, inlabel 17, outlabel 27 (from 10.200.254.2:0), get path labels

00:15:08: tagcon: rib change: 10.200.210.0/24; event 0x4; ndb attrflags 0x1000000; ndb->pdb_index 0x2

00:15:08: tagcon: rib change: 10.200.210.0/255.255.255.0; event 0x4; ndb attrflags 0x1000000; ndb->pdb_index 0x2/undef

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