What You Will Learn By the end of this appendix, you...

What You Will Learn

By the end of this appendix, you should know and be able to explain the following:

�

What static MPLS labels are and how they can be used

�

The difference between static MPLS bindings and MPLS static crossconnect

�

That there is a label range dividing the range of all possible labels into a static label range and a dynamically assigned label range

A

P

P

E

N

D

I

X

B

Static MPLS Labels

Static MPLS Labels

Cisco IOS has static MPLS labels. This means that the operator can assign MPLS labels statically instead of Cisco IOS assigning them dynamically. The following are possible reasons to deploy static MPLS labels:

�

The neighboring router cannot run Label Distribution Protocol (LDP).

�

Label exchange is not wanted between two label switching routers (LSR) of two different autonomous systems.

�

A label range divides the range of all possible labels into a static label range and a dynamically assigned label range.

�

They can be useful for billing.

�

They can aid in troubleshooting.

The first reason is a rare one. A router that does not run LDP most likely also does not understand MPLS labels. As such, it will not switch received labeled packets. However, it might be that the router is capable of running LDP but that the operator prohibits it, which is the second reason for deploying static MPLS labels. One example is at the autonomous system border routers (ASBR) between two autonomous systems. These autonomous systems could be running the services inter-autonomous MPLS VPN, inter-autonomous AToM, inter-autonomous 6VPE, and so on. In those cases, you would like the ASBRs to switch labeled packets between them. You can run LDP or Border Gateway Protocol (BGP) and label exchange for IPv4 between the two ASBRs. However, if BGP and label exchange for IPv4 is not possible on one ASBR, the only option is LDP exchanging labels for Interior Gateway Protocol (IGP) routes. Because service providers do not like to run an IGP between two autonomous systems, static MPLS labels is a solution.

A third reason for deploying static MPLS labels might be billing. As Netflow has been made MPLS aware (see Chapter 13, “Troubleshooting MPLS Networks,” and Chapter 14, “MPLS Operation and Maintenance”), it is easier to track specific labels anywhere in the label stack if it is known in advance which label to keep track of. In the case of Inter-Autonomous MPLS services, you can more easily keep track of the amount of traffic bound to one prefix or pseudowire if that label never changes over time. For the label to remain constant, you can use a static MPLS label.

3

Appendix B: Static MPLS Labels

Finally, troubleshooting problems with labeled traffic can be easier if the labels that are bound to a prefix do not change even if the prefix is withdrawn by the routing protocol and advertised again later on. Temporarily configured static MPLS labels can help troubleshoot problems in the MPLS network.

Static MPLS labels have two components:

�

The static binding of a label to a prefix

�

The static entry of labels into the label forwarding information base (LFIB) (MPLS static crossconnect)

The first feature is the static creation of a label binding for a prefix. This label binding is statically inserted into the LIB. Whether the label binding makes it into the LFIB depends on if the next-hop information of the label binding matches the next-hop information for the prefix in the routing table. The statically configured label binding can be a local or a remote label binding. The second feature enables the direct insertion of an entry into the LFIB. This means that the user configures one incoming and one outgoing label with one outgoing next hop. This next hop is the neighboring LSR. Because this is a direct insertion into the LFIB, a label binding is not needed in the LIB.

These features do not preclude the use of dynamic label binding by LDP, Resource Reservation Protocol (RSVP), or BGP on the same LSR. This is particularly important for multiaccess interfaces, where you can have more than one peer MPLS router on one interface. The static MPLS labels are from the platform-wide label space. As such, it does not matter on which interface the incoming labeled packet with the statically assigned label as top label is received, as long as this incoming interface is also from the platform-wide label space and not from the per-interface label space. Label Controlled ATM (LC-ATM) interfaces are not compatible with static MPLS labels in Cisco IOS.

Label Range

Before you can get started with static MPLS labels, you need to specify the label range for the static labels. Following is the command to set this label range:

mmmmppppllllssss llllaaaabbbbeeeellll rrrraaaannnnggggeeee

min-label max-label

[

ssssttttaaaattttiiiicccc

min-static-label

max-static-label

]

For instance, you can reserve the labels 16 through 200 for static labels and keep the range above 200 for dynamic label assignment (LDP, RSVP, or BGP).

The reason for having a specific range of static versus dynamic labels is purely a practical one. The range of labels available to LDP, RSVP, or BGP for dynamic assignment becomes clear, and there is no chance of ending up with a label that is for static and dynamic use at the same time. In all other aspects, a static label is like a dynamically assigned label. The syntax of a static label is the same as for a dynamically assigned label.

Static MPLS Binding for an IPv4 Prefix

4


LSRs distribute label bindings (a prefix + a label) between them using a label distribution protocol such as LDP. It might be that in some cases the connecting LSR does not run LDP or is not allowed to have an LDP session to your LSR. In these cases, you can set up static MPLS bindings on your LSR. These static labels are put into the LIB of the LSR. If a matching prefix is found in the RIB/CEF table, the binding is used for the forwarding of labeled packets; this means it will be used in the LFIB or CEF table. When you have dynamically learned label bindings (received via LDP, for example) and statically configured label bindings for the same IPv4 prefixes, the dynamically learned label bindings take precedence and are used in the LFIB/CEF table.

Look at Figure B-1. It shows two autonomous systems with four LSRs. Because a kind of Inter-Autonomous MPLS service offering exists between them, there needs to be an end-to-end LSP from the LSR london to the LSR sydney, spanning the two autonomous systems. Because LSPs are unidirectional, one LSP needs to be in the opposite direction. Assume that the third LSR (new-york) cannot or will not establish an LDP peering with the second LSR (paris).

Figure B-1

Example of Static MPLS Labels

To make the LSP from the first LSR (london) to the fourth LSR (sydney) and the LSP in the opposite direction uninterrupted on the ASBRs paris and new-york, make sure that the bindings are set up for the prefix 10.200.254.4/32, which is the loopback 0 of the sydney router, and the prefix 10.200.254.1/32, which is the loopback 0 of the london router. You do this by using static bindings on the second and third LSRs. The service providers that own the two autonomous systems must agree on which incoming or outgoing label to use for each LSP between the autonomous systems.

NOTE

You must have

mpls ip

(LDP) or MPLS traffic engineering configured on the outgoing interface of the LSR to be able to use the statically configured outgoing label.

london

Loopback 0 10.200.254.1/32

Label Switched Path

Left to right

Label Switched Path

Right to left

No LDP AS 1

paris new-york

Loopback 0 10.200.254.4/32

AS 2

sydney

5


The following specifies what to configure in AS 1 on the ASBR LSR paris. The static labels to be configured on the new-york LSR are the responsibility of the service provider that owns AS 2. On the LSR paris, which is peering with router new-york, you have to make sure that the outgoing static label matches the incoming static label that is configured on new-york for the prefix 10.200.254.4/32, which is the LSP left to right. You also have to make sure that the incoming static label on paris matches the outgoing static label that is configured on new-york for the prefix 10.200.254.1/32, which is the LSP right to left.

The following command assigns a static binding to an IPv4 prefix:

MMMMppppllllssss ssssttttaaaattttiiiicccc bbbbiiiinnnnddddiiiinnnngggg iiiippppvvvv4444

prefix mask

[[[[iiiinnnnppppuuuutttt

||||

oooouuuuttttppppuuuutttt

nexthop

]]]]

label

The input keyword refers to local binding, and the output keyword refers to remote binding on the LSR on which this command is configured. Notice that you can configure only one local binding for an IPv4 prefix, but you can configure multiple remote bindings—namely, one per possible next hop. This is similar to what happens when you have LDP running. LDP advertises the static local binding that you configure on the LSR to all the LDP peers of this LSR.

Look at Figure B-2. It shows the outgoing static label for the left-to-right LSP that will be needed and the incoming static label for the right-to-left LSP that will be needed on the LSR paris.

Figure B-2

Static Label Binding

Following is the configuration needed on the paris LSR to complete the two LSPs that are using static bindings. First, you need to configure a range for the static labels. In this case, a range from 16 through 200 is reserved for the static labels. LDP, RSVP, or BGP can use the other labels (201 through 1048575).

mpls label range 201 1048575 static 16 200

london

Loopback 0 10.200.254.1/32

Label Switched Path

Left to right

Label Switched Path

Right to left

No LDP AS 1

paris new-york10.200.203.2

Loopback 0 10.200.254.4/32

AS 2

sydney

Label 101

Label 151


6

You can see the label ranges with the

show mpls label range

command, as in Example B-1. The labels 0 through 15 are reserved and cannot be used as static labels either.

Assume that the agreed outgoing label is 151 on the new-york router for the LSP right to left. You then configure the static local binding (or incoming label) to be 151 on the paris router, with the following command:

mpls static binding ipv4 10.200.254.1 255.255.255.255 151

Assume that the agreed incoming label is 101 on the new-york router for the LSP left to right. You then configure the static remote binding (or outgoing label) to be 101 on the paris router for the LSP left to right. The following command configures the static remote binding on LSR paris:

mmmmppppllllssss ssssttttaaaattttiiiicccc bbbbiiiinnnnddddiiiinnnngggg iiiippppvvvv4444 11110000....222200000000....222255554444....4444 222255555555....222255555555....222255555555....222255555555 oooouuuuttttppppuuuutttt 11110000....222200000000....222200003333....2222 111100001111

The IP address 10.200.203.2 is the next-hop link address on LSR new-york. The command

show mpls static binding

lets you verify the static label bindings on the LSR, as shown in Example B-2.

Example B-3 shows the static label bindings for both LSPs in the LIB of LSR paris.

Example B-1

Show MPLS Label Range

paris#

sssshhhhoooowwww mmmmppppllllssss llllaaaabbbbeeeellll rrrraaaannnnggggeeee

Downstream Generic label region: Min/Max label: 201/1048575

Range for static labels: Min/Max Number: 16/200

NOTE

The keyword

input

is missing; it is the default keyword for this command.

Example B-2

show mpls static binding

paris#

sssshhhhoooowwww mmmmppppllllssss ssssttttaaaattttiiiicccc bbbbiiiinnnnddddiiiinnnngggg

10.200.254.1/32: Incoming label: 151 (in LIB)

Outgoing labels: None

10.200.254.4/32: Incoming label: none;

Outgoing labels:

10.200.203.2 101

Example B-3

LIB Entries for Both LSPs

paris#

sssshhhhoooowwww mmmmppppllllssss llllddddpppp bbbbiiiinnnnddddiiiinnnnggggssss 11110000....222200000000....222255554444....4444 222255555555....222255555555....222255555555....222255555555

tib entry: 10.200.254.4/32, rev 30

local binding: tag: 206

remote binding: tsr: 10.200.254.1:0, tag: 22

remote binding: tsr: 10.200.203.2:0, tag: 101

7


Example B-4 shows that the static labels for both LSPs have made it into the LFIB of LSR paris.

MPLS Static Crossconnect

MPLS Static Crossconnect makes an LSR that does not run LDP or RSVP, capable of being an LSP midpoint router. You must configure the LSR with crossconnect commands that make the router switch an incoming label with an outgoing label that you configured from the static label range. The following command configures an MPLS static crossconnect:

mmmmppppllllssss ssssttttaaaattttiiiicccc ccccrrrroooossssssssccccoooonnnnnnnneeeecccctttt

inlabel

oooouuuutttt

interface

[[[[

nexthop

]]]] {{{{

outlabel

||||

eeeexxxxpppplllliiiicccciiiitttt----nnnnuuuullllllll

||||

iiiimmmmpppplllliiiicccciiiitttt----nnnnuuuullllllll

}

With this command, you directly populate the LFIB with an entry as you must configure an incoming label, an outgoing label, and a next hop. Note that the outgoing label can be implicit NULL to let you have penultimate hop popping (PHP); it can also be configured to be explicit NULL. On point-to-point interfaces, it is sufficient to specify the outgoing interface. On multiaccess interfaces, you must also specify the next-hop IP address to complete the next-hop information.

paris#

sssshhhhoooowwww mmmmppppllllssss llllddddpppp bbbbiiiinnnnddddiiiinnnnggggssss 11110000....222200000000....222255554444....1111 222255555555....222255555555....222255555555....222255555555

tib entry: 10.200.254.1/32, rev 32

local binding: tag: 151

remote binding: tsr: 10.200.254.1:0, tag: imp-null

Example B-4

LFIB Entries for Both LSPs

paris#

sssshhhhoooowwww mmmmppppllllssss ffffoooorrrrwwwwaaaarrrrddddiiiinnnngggg----ttttaaaabbbblllleeee 11110000....222200000000....222255554444....1111

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

151 Pop tag 10.200.254.1/32 30226 Et1/1 10.200.200.1

paris#

sssshhhhoooowwww mmmmppppllllssss ffffoooorrrrwwwwaaaarrrrddddiiiinnnngggg----ttttaaaabbbblllleeee 11110000....222200000000....222255554444....4444



206 101 10.200.254.4/32 3868 Et1/3 10.200.203.2

NOTE

The statically configured output label only makes it into the LFIB if the next hop that is configured for the remote binding matches the next hop in the routing table for that prefix. In other words, from all the possible remote bindings (static or dynamic), only one is used to populate the LFIB—namely, the one whose next hop matches the next hop in the routing table. By default, the LSP follows the least-cost IP path through the network.

Example B-3

LIB Entries for Both LSPs (Continued)

MPLS Static Crossconnect

8

Make sure that the static label range is configured:

mmmmppppllllssss llllaaaabbbbeeeellll rrrraaaannnnggggeeee 222200001111 1111000044448888555577775555 ssssttttaaaattttiiiicccc 11116666 222200000000

Look at Figure B-3.

Figure B-3

Static Crossconnect Example

Assume that the router paris will not distribute label bindings because it will not run LDP or RSVP. You can instruct the LSR to switch labeled packets coming from london on the left-to-right LSP to the router new-york. You can do the same for the LSP in the other direction. First, you need to know what labels the adjacent LSR expects to receive from the LSR paris. Second, you need to know what labels the adjacent LSRs will put on the packets that are sent to the LSR pairs. These label bindings on the adjacent LSRs need to be static; they should not change over time. Third, you can configure the crossconnects on the LSR paris. Before you can configure the router paris with static crossconnects, you must have determined the following:

�

The LSR new-york will send traffic to paris with a label 150 for the LSP right to left.

�

The LSR new-york expects an incoming label 101 for the LSP left to right.

�

The labeled packets on the left-to-right LSP come in on router paris with a label 100 on top of the packet. (One way of making this happen is to configure a static MPLS binding for the IPv4 prefix on the previous router [london] and assign the label 100 and a next hop, which is the router paris.)

Label 100 Label 101

No LDP No LDP

Implicit NULL Label 150

london

Loopback 0 10.200.254.1/32

Label Switched Path

Left to right

Label Switched Path

Right to left

paris new-york

Eth 1/2 10.200.201.1

Loopback 0 10.200.254.4/32

sydney

Eth 1/1 10.200.200.2

10.200.201.2

10.200.202.110.200.202.2 10.200.200.1

9


Then, the following two commands on the router paris make the router switch the labeled packets correctly for the two LSPs:

mmmmppppllllssss ssssttttaaaattttiiiicccc ccccrrrroooossssssssccccoooonnnnnnnneeeecccctttt 111100000000 EEEEtttthhhheeeerrrrnnnneeeetttt1111////2222 11110000....222200000000....222200001111....2222 111100001111mmmmppppllllssss ssssttttaaaattttiiiicccc ccccrrrroooossssssssccccoooonnnnnnnneeeecccctttt 111155550000 EEEEtttthhhheeeerrrrnnnneeeetttt1111////1111 11110000....222200000000....222200000000....1111 iiiimmmmpppplllliiiicccciiiitttt----nnnnuuuullllllll

The left-to-right LSP swaps the incoming top label 100 with the outgoing label 101 and switches it out to the next hop on interface Ethernet1/2. The right-to-left LSP swaps the incoming top label 150 with the outgoing implicit NULL label and switches it out to the next hop on interface Ethernet1/1. In effect, this means that the label operation is pop, because one label will be popped off before forwarding the packet. The reason for choosing implicit NULL as the outgoing label for the right-to-left LSP on the router paris is that the LSR paris is the penultimate LSR for this LSP (prefix 10.200.254.1/32). This is so because the prefix 10.200.254.1/32 is directly connected to the router london.

Example B-5 shows the LFIB on router paris.

For the left-to-right LSP, label 100 is swapped with label 101 on LSR paris and the packet is sent on the Ethernet 1/2. For the right-to-left LSP on LSR paris, the label 150 is popped off and the packet is sent onto Ethernet 1/1. This effectively turns paris into a P router or midpoint LSR, without utilizing LDP or RSVP on it. Notice that the labels 100, 101, and 150 are not bound to an IPv4 prefix. As such, the LFIB shows “nil tunnel” instead of an IPv4 prefix in the Prefix or Tunnel Id column.

Example B-5

LFIB on Router Paris

paris#

sssshhhhoooowwww mmmmppppllllssss ffffoooorrrrwwwwaaaarrrrddddiiiinnnngggg----ttttaaaabbbblllleeee



100 101 nil tunnel 12756 Et1/2 10.200.201.2

150 Pop tag nil tunnel 10833 Et1/1 10.200.200.1

201 Untagged 10.10.11.0/24 460 Et1/0 10.48.70.92

202 Untagged 10.48.92.61/32 0 Et1/0 10.48.70.1

203 Untagged 10.200.202.0/24 0 Et1/3 10.200.203.2

Untagged 10.200.202.0/24 0 Et1/2 10.200.201.2

204 Untagged 10.200.254.1/32 877 Et1/1 10.200.200.1

205 Untagged 10.200.254.3/32 0 Et1/3 10.200.203.2

Untagged 10.200.254.3/32 0 Et1/2 10.200.201.2

206 Untagged 10.200.254.4/32 0 Et1/2 10.200.201.2

Untagged 10.200.254.4/32 0 Et1/3 10.200.203.2

207 Untagged 10.2.0.0/16 0 Et1/3 10.200.203.2

Untagged 10.2.0.0/16 0 Et1/2 10.200.201.2

VRF-Aware Static MPLS Labels 10

You can verify the static crossconnect entries in the LFIB with the show mpls static crossconnect command, as in Example B-6.

Example B-7 shows a traceroute from the ingress LSR to the egress LSR for the left-to-right LSP confirming that the label 100 is correctly swapped with label 101 on router paris.

VRF-Aware Static MPLS Labels

So far, the statically assigned labels were assigned to IPv4 prefixes in the global routing table. In the case of Carrier's Carrier (CsC), however, labels can be assigned to IPv4 prefixes in a VPN (or VRF). In the case of CsC, the packets that enter the CSC-PE router on the VRF interface are already labeled. To assign label bindings statically to the IPv4 prefixes learned over the VRF interface, the static label binding feature had to be made aware of VRF. That enables you to assign labels statically to the prefixes learned over the VRF interfaces on the CSC-PE routers. You might want to statically assign labels to IPv4 prefixes you are advertising to the carrier (CSC-CE) routers for the same reasons mentioned in the beginning of this appendix.

This is the command to assign a static label binding to an IPv4 VRF prefix:

mmmmppppllllssss ssssttttaaaattttiiiicccc bbbbiiiinnnnddddiiiinnnngggg iiiippppvvvv4444 vvvvrrrrffff vpn-name prefix mask [[[[[[[[iiiinnnnppppuuuutttt]]]] label]]]]

Figure B-4 shows a simple network running CsC. With CsC, you are switching labeled packets between the CE and PE routers. Normally, you have LDP or eBGP + label running on the PE-CE link. The result is that the CE is sending the packets to the PE as labeled packets. Now you can have the same behavior by using static labels on the CSC-CE and the CSC-PE.

Example B-6 Show MPLS Static Crossconnect

paris#sssshhhhoooowwww mmmmppppllllssss ssssttttaaaattttiiiicccc ccccrrrroooossssssssccccoooonnnnnnnneeeecccctttt

Local Outgoing Outgoing Next Hop

label label interface

100 101 Et1/2 10.200.201.2 (in LFIB)

150 Pop Label Et1/1 10.200.200.1 (in LFIB) [Outgoing label is implicit-null]

Example B-7 Traceroute

london#ttttrrrraaaacccceeeerrrroooouuuutttteeee 11110000....222200000000....222255554444....4444

Type escape sequence to abort.

Tracing the route to 10.200.254.4

1 10.200.200.2 [MPLS: Label 100 Exp 0] 4 msec 4 msec 0 msec

2 10.200.201.2 [MPLS: Label 101 Exp 0] 0 msec 0 msec 0 msec

3 10.200.202.2 0 msec * 0 msec

Figure B-4 Example of Static MPLS Labels for IPv4 VRF Prefixes

The carrier and the CsC must agree on the labels to use. If the carrier agrees to send traffic toward the prefix 10.100.103.2/32, which is the loopback prefix on the remote CSC-CE (sydney-ce), with label 120, the CsC can assign a static incoming (local) label 120 to the VRF cust-one prefix 10.100.103.2/32 on the CSC-PE router london. This is the VPN label that is now statically assigned to the VRF prefix. If you do not implement static labels, BGP or LDP assigns this VPN label.

As always, you must first assign a range for the static labels.

london#sssshhhhoooowwww rrrruuuunnnnnnnniiiinnnngggg----ccccoooonnnnffffiiiigggg |||| iiiinnnncccclllluuuuddddeeee ssssttttaaaattttiiiiccccmpls label range 201 1048575 static 16 200

Then you need to assign the static label binding on the CSC-PE to the IPv4 VRF prefix, with the following command:

mmmmppppllllssss ssssttttaaaattttiiiicccc bbbbiiiinnnnddddiiiinnnngggg iiiippppvvvv4444 vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee 11110000....111100000000....111100003333....2222 222255555555....222255555555....222255555555....222255555555 111122220000

You can check whether the static label made it into the LIB. See Example B-8.

Example B-8 Checking the Static MPLS Binding

london#sssshhhhoooowwww mmmmppppllllssss ssssttttaaaattttiiiicccc bbbbiiiinnnnddddiiiinnnngggg iiiippppvvvv4444 vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee

10.100.103.2/32: (vrf: cust-one) Incoming label: 120

Outgoing labels: None

sydneylondon

CSC-PE

CSC-PE

london-ce

CSC-CE

CSC-CE

VPN cust-one VPN cust-one

sydney-ceparis new-york

P P

209 120

IPIP

100

Loopback 0 10.100.103.1/32

Loopback 0 10.100.103.2/32

VRF VRF

What You Will Learn By the end of this appendix, you...

Documents

Transcript of What You Will Learn By the end of this appendix, you...