NTS: MPLS/LDP

MPLS/LDP

LDP (Label Distribution Protocol) is defined in RFC 5036.
MPLS (Multi-Protocol Label Switching) architecture is defined in RFC 3031.
MPLS Label Stack Encoding is defined in RFC 3032.

LDP messages

LDP Discovery (to directly connected neighbors)

Multicast UDP to 244.0.0.2:646

targeted LDP Discovery (to non-directly connected neighbors)

Unicast UDP to x.x.x.x:646

LDP Session/Advertisement/Notification (to all)

Unicast TCP to x.x.x.x:646

A working IGP between neighbors is a requirement for all the above, besides LDP Discovery.

Label retention/distribution

Label retention

liberal
conservative

Label distribution

downstream

unsolicited
on-demand

Liberal, downstream, unsolicited is the most common case.

General

Although in latest software releases LDP is the default label protocol, it's a good practice to always enable it with "mpls label protocol ldp". The same applies with the "mpls ldp router-id", which should in most cases be loopback0.

Use "sh mpls ldp bindings" to check the LIB (labels for all IGP database prefixes)
Use "sh mpls forwarding" to check the LFIB (labels for RIB installed prefixes)

Outgoing Label under "show mpls forwarding-table":

X Label

Local device is an LSR

Pop Label

Local device is an LSR and also the PHP

No Label

Local device is a LER

You need to configure "mpls ldp explicit-null" if you want to keep the EXP QoS till the end PE. Default is implicit-null due to PHP.

"debug mpls packet" includes the label stack {Label EXP TTL} information

Fa0/0.1: rx: Len 122 Stack {29 0 253} - ipv4 data
Fa0/0.2: tx: Len 122 Stack {30 0 252} - ipv4 data

Debugging should be the last thing you should do in case of a problem in production networks. So learn not to depend on it.

Label Allocation Methods

an IGP/Transport Label is allocated through

LDP (+IGP)
RSVP (MPLS TE)
Labeled BGP

a VPN Label (L3VPN) is allocated through

MP-BGP (VPNv4/v6)

a PW Label (L2VPN) is allocated through

Targeted LDP

an IPv6 Label (6PE) is allocated through

Labeled BGP

Targeted LDP Sessions

You can create targeted LDP sessions (assuming ip connectivity exists) using the following methods:

IOS

Static LDP neighbors on both routers

R1
mpls ldp neighbor R2 targeted

R2
mpls ldp neighbor R1 targeted

Static LDP neighbor on one router and accept targeted hellos on the other

R1
mpls ldp neighbor R2 targeted

R2
mpls ldp discovery targeted-hello accept

MPLS/LDP under a TE tunnel interface on one router and static LDP neighbor on the other

R1
interface Tunnel0
tunnel destination R2
mpls ip

R2
mpls ldp neighbor R1 targeted

MPLS/LDP under a TE tunnel interface on one router and accept targeted hellos on the other

R1
interface Tunnel0
tunnel destination R2
mpls ip

R2
mpls ldp discovery targeted-hello accept

Something similar applies to IOS-XR too.

IOS-XR

R1
mpls ldp
neighbor R2 targeted

R2
mpls ldp
discovery targeted-hello accept

In case of RSVP in the core and LDP in the access, you can have tLDP sessions over RSVP, where end-to-end LSPs will have 1 label (LDP) in the access and 2 labels (RSVP/LDP) in the core.

You can also use RSVP solely for (one-hop) link protection, having tLDP on top of it.

Simple VPN with iBGP & LDP

The rule for LSP usage in BGP is that when an LSP is available for the BGP next-hop of a route, that LSP can be used to forward traffic to that route destination.

Assuming a network of R1-R2-R3-R4-R5-R6, where R2,R3,R4,R5 run LDP+IGP in the core and R2,R5 run iBGP between them, then R1 and R6 can communicate between each other as long as their networks as advertised to R2,R5 (i.e with eBGP) and R2,R5 are using their loopbacks as next-hops in their iBGP. The intermediate routers R3,R4 just do mpls switching based on the R2,R5 loopback labels.

R2,R5 have BGP-generated labels for the R1,R6 prefixes which according to BGP have R2,R5 as next-hops.
These labels (which are the same as the ones used for the BGP next-hop) are shown only if you exclusively define the network in "sh mpls forwarding-table" or use "sh ip cef".

IOS
R2#sh mpls forwarding-table | i 6.6.6.6
R2# -no entry shown-

R2#sh mpls forwarding-table 6.6.6.6
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
None       22         6.6.6.6/32 0             Fa0/0.23   20.2.3.3

R2#sh mpls forwarding-table | i 5.5.5.5
21         22         5.5.5.5/32    0             Fa0/0.23   20.2.3.3

R2#sh ip route 6.6.6.6
Routing entry for 6.6.6.6/32
Known via "bgp 100", distance 200, metric 0
Tag 20, type internal
Last update from 5.5.5.5 00:35:32 ago
Routing Descriptor Blocks:
* 5.5.5.5, from 5.5.5.5, 00:35:32 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 20
      MPLS label: none

R2#sh ip cef 6.6.6.6 det
6.6.6.6/32, epoch 0, flags rib only nolabel, rib defined all labels
recursive via 5.5.5.5
    nexthop 20.2.3.3 FastEthernet0/0.23 label 22

R3,R4 have LDP-generated labels for the R2,R5 next-hops

Static Labels

After you configure the label range, you need to remove the mpls ldp config from the IGP process or from the interfaces in order to use the label range. If you just clear the LDP neighbors, then the old labels remain.

Check "Inter-AS MPLS L3VPN" for more examples.

LDP Auto-configuration

Supported in OSPF and IS-IS
Not supported on MPLS-TE Tunnels

IOS
router ospf/isis X
mpls ldp autoconfig
!
interface X
no mpls ldp igp autoconfig

IOS-XR
mpls ldp
!
router ospf/isis X
mpls ldp auto-config
!
interface X
igp auto-config disable

Use "sh mpls interfaces detail" or "sh mpls ldp discovery detail" to find out how LDP was activated on an interface.

IOS-XR requires the explicit activation of MPLS LDP prior to LDP autoconfiguration.

LDP Authentication

Authentication is applicable only to the LDP TCP session.

After setting the LDP password, the LDP session might need to be cleared manually to have the password enabled.

When setting "mpls ldp password required", all LDP sessions are cleared automatically.

Password can be configured:

per neighbor

"mpls ldp neighbor x.x.x.x password" (IOS, IOS-XR)

per group of neighbors

"mpls ldp password option X for Y-ACL" (IOS)

as a default password for all neighbors

"mpls ldp password fallback" (IOS)
"mpls ldp neighbor password" (IOS-XR)

Label Filtering

The LDP default behavior is to allocate local labels for all non-BGP prefixes, which includes IGP learned prefixes and connected interfaces with LDP on.

Local Label Allocation Filtering

controls the allocation of local labels
uses prefix-lists for filtering
use "allocate global prefix-list" under "mpls ldp label" config (IOS)
use "mpls ldp label allocate" under global config (IOS-XR)
use "sh mpls ldp bindings local" to verify

Inbound Label Binding Filtering

controls label bindings that a router accepts from a specific neighbor
uses access-lists for filtering
use "mpls ldp neighbor x.x.x.x labels accept" under global config (IOS)
use "mpls ldp label accept" under global config (IOS-XR)
use "sh mpls ldp bindings neighbor" to verify

Outbound Label Binding Filtering

controls label bindings that a router sends to a specific neighbor
uses access-lists for filtering
use "mpls ldp advertise-labels" under global config (IOS) - "no mpls advertise" is needed first
use "mpls ldp label advertise" under global config (IOS-XR)
use "sh mpls ldp bindings neighbor" to verify

LDP does not apply the configured local label filter to redistributed BGP routes in the global table for which BGP allocates the local label, but LDP does the advertisements (i.e. Inter-AS Option C). LDP neither forwards these entries, nor releases the local labels allocated by BGP.

Common use of label filtering is to allocate labels only for PE loopback addresses.

LDP Session Protection

When enabled, a new targeted LDP session is created between the neighbors, in order to keep their LDP session active over any backup path, after the direct/primary link fails. When the primary/direct link is restored, label bindings do not need to be re-exchanged.

2 implementation choices:

both neighbors must be configured for session protection
one router must be configured for session protection and the other router must simply respond to targeted hellos

IOS
mpls ldp session protection
mpls ldp session protection for LDP-NEI-ACL duration X

IOS-XR
mpls ldp
session protection
session protection for LDP-NEI-ACL duration X

You can enable it for all LDP neighbors or for specific ones using an ACL.

IOS
R2#sh mpls ldp neighbor detail | i Protection|duration
        LDP Session Protection enabled, state: Ready
            duration: 86400 seconds
        LDP Session Protection enabled, state: Incomplete
            duration: 86400 seconds
        LDP Session Protection enabled, state: Protecting
            duration: 86400 seconds

R2#sh mpls ldp neighbor 3.3.3.3 detail
...
        LDP discovery sources:
          FastEthernet0/0.23; Src IP addr: 20.2.3.3
            holdtime: 15000 ms, hello interval: 5000 ms
          Targeted Hello 2.2.2.2 -> 3.3.3.3, active, passive;
            holdtime: infinite, hello interval: 10000 ms

Successful recovery

%LDP-5-SP: 3.3.3.3:0: session hold up initiated
%LDP-5-SP: 3.3.3.3:0: session recovery succeeded

Failed recovery

%LDP-5-SP: 4.4.4.4:0: session hold up initiated
%LDP-5-SP: 4.4.4.4:0: session recovery failed
%LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (1) is DOWN (Session Protection disabled targeted session)

LDP IGP Synchronization

When enabled, links where LDP adjacencies are not established, will have their IGP metric increased to the max by the local IGP process.

Generally when an IGP adjacency is established on a link with LDP-IGP Sync on, but LDP-IGP Sync is not yet achieved (or is lost), the IGP advertises the max-metric on that link. That way the link won't be preferred for passing traffic and black-holing will be prevented.

IOS
router ospf/isis X
mpls ldp sync
!
mpls ldp igp sync holddown x
!
interface X
no mpls ldp igp sync
mpls ldp igp sync delay x

IOS-XR
router ospf/isis X
mpls ldp sync
!
mpls ldp
igp sync delay x
interface X
igp sync delay x

IOS
R2#sh mpls ldp igp sync
    FastEthernet0/0.23:
        LDP configured; LDP-IGP Synchronization enabled.
        Sync status: sync achieved; peer reachable.
        Sync delay time: 0 seconds (0 seconds left)
        IGP holddown time: infinite.
        Peer LDP Ident: 3.3.3.3:0
        IGP enabled: OSPF 1

R2#sh mpls ldp igp sync
    FastEthernet0/0.23:
        LDP configured; LDP-IGP Synchronization enabled.
        Sync status: sync not achieved; peer reachable.
        Sync delay time: 0 seconds (0 seconds left)
        IGP holddown time: infinite.
        Peer LDP Ident: 3.3.3.3:0
        IGP enabled: OSPF 1

IOS-XR
GSR#sh mpls ldp igp sync

GigabitEthernet0/1/0/1.619:
Sync status: Ready
Peers:
    6.6.6.6:0

Targeted LDP sessions (i.e. AToM) are not supported, which is expected because these are already tLDP sessions that can use IGP for rerouting.

In IS-IS the maximum wide metric -1 (0XFFFFFE) is used with MPLS LDP IGP synchronization.

Links

TTL Propagation

Default behavior is to copy the TTL from the IP header to the MPLS header (topmost label).

2 extra options are available:

do not copy the TTL for forwarded packets

"no mpls ip propagate-ttl forwarded" (IOS)
"mpls ip-ttl-propagate disable forwarded" (IOS-XR)

do not copy the TTL for locally generated packets

"no mpls ip propagate-ttl local" (IOS)
"mpls ip-ttl-propagate disable local" (IOS-XR)

If the TTL is not copied for forwarded packets, then a traceroute from a local CE to a remote CE, will include the local PE, the remote PE and the remote CE (all the intermediate P routers won't be shown). You can use this in order to hide the MPLS hops from the customer.

You only need to disable the TTL propagation on the PEs, since the P (LSR) routers do not see the original IP packet, so no TTL propagation takes place there.

Traceroute in MPLS L3VPNs works a little bit differently than in normal IP networks, because when the traceroute packet reaches the MPLS core (P routers), the local generated ttl-exceeded response packet must first reach the PE at the other side of the VPN before it's returned back to the traceroute source.

i.e. in a traceroute from CE1 to CE2 (CE1-PE1-P-PE2-CE2), the following happens

CE1 sends a ICMP packet with TTL=1

Source=CE1
Destination=CE2
TTL=1

PE1 receives the ICMP packet
PE1 sends an ICMP ttl-exceeded response back to CE1

Source=PE1
Destination=CE1

CE1 receives the ICMP response
CE2 sends an ICMP packet with TTL=2

Source = CE1
Destination=CE2
TTL=2

PE1 receives the ICMP packet
PE1 forwards the ICMP packet to the next P

Source=CE1
Destination=CE2
TTL=1

P receives the ICMP packet
P creates an ICMP ttl-exceeded response and sends it to PE2 using the original label stack

Source=P
Destination=CE1
TTL=default

PE2 receives the ICMP response and forwards it to CE1 which is the actual destination

Source=P
Destination=CE1

CE1 receives the ICMP response
CE1 sends a ICMP packet with TTL=3

and so on...

MPLS MTU

Every label adds 4 bytes to the frame size.

Common label stacks

L3VPN

LDP label + VC label

L2VPN/VPLS

LDP label + VC label

MPLS-TE

TE label + VC label
TE label + LDP label + VC label

MPLS-TE/FRR

FRR label + TE label + VC label
FRR label + TE label + LDP label + VC label

AToM & TE/FRR & CsC

FRR label + TE label + LDP label + VPN label + VC label

Common transport header sizes (in bytes):

Ethernet port:14
Ethernet VLAN: 14 + 4 per vlan tag
Frame-Relay DLCI: 2 (Cisco), 8 (IETF)
HDLC/PPP: 4
AToM Control Word: 4

All L3 protocols (i.e. IPv4, IPv6, MPLS, CLNS) inherit their MTU settings from L2 MTU.

The default MPLS MTU value of a link equals the interface MTU value. You need to first change the interface MTU in order to be able to increase the MPLS MTU too.

IOS
R4#sh mpls int detail
Interface FastEthernet0/0:
        IP labeling not enabled
        LSP Tunnel labeling enabled
        BGP labeling not enabled
        MPLS operational
        MTU = 1500

IOS
interface FastEthernet0/0
mtu 1530

R4#sh mpls int detail
Interface FastEthernet0/0:
        IP labeling not enabled
        LSP Tunnel labeling enabled
        BGP labeling not enabled
        MPLS operational
        MTU = 1530

IOS
interface FastEthernet0/0
mtu 1530
mpls mtu 1508

R4#sh mpls int detail
Interface FastEthernet0/0:
        IP labeling not enabled
        LSP Tunnel labeling not enabled
        BGP labeling not enabled
        MPLS operational
        MTU = 1508

In IOS-XR, interface MTU includes the L2 header (i.e. +14 bytes in case of untagged ethernet).

IOS-XR
interface TenGigE0/0/0/6
mtu 9214

IOS-XR
ASR9k#sh imds int Te0/0/0/6

View: OWN - Owner, L3P - Local 3rd Party, G3P - Global 3rd Party,
      LDP - Local Data Plane, GDP - Global Data Plane, RED - Redundancy

Node 0/RSP0/CPU0 (0x41)

Interface TenGigE0/0/0/6, ifh 0x000002c0 (up, 9214)
Interface flags:          0x000000000010059f (IFCONNECTOR|IFINDEX
                            |SUP_NAMED_SUB|BROADCAST|CONFIG|HW|VIS|DATA
                            |CONTROL)
Encapsulation:            ether
Interface type:           IFT_TENGETHERNET
Control parent:           None
Data parent:              None
Views:                    GDP|G3P

Protocol        Caps (state, mtu)
--------        -----------------
None            spio (up, 9214)
None            ether (up, 9214)
arp             arp (up, 9200)
ipv4            ipv4 (up, 9200)
mpls            mpls (up, 9200)
ether_sock      ether_sock (up, 9200)
ether_link_oam ether_link_oam (up, 9200)

The "sh imds" command is hidden in most IOS-XR releases.

IOS-XR
ASR9k#sh ip int Te0/0/0/6
TenGigE0/0/0/6 is Up, ipv4 protocol is Up
Vrf is default (vrfid 0x60000000)
Internet address is 10.201.10.221/30
MTU is 9214 (9200 is available to IP)

In IOS-XR, if you change the interface MTU, then you need to take into account the L2 header. If you change the L3 protocol MTU, then it's the same as in IOS.

Fragmentation

If a labeled packet is received and the LSR notices that the outgoing MTU is not big enough for this packet, the LSR strips off the label stack, fragments the IP packet, puts the label stack (after the pop, swap, or push operation) onto all fragments, and forwards the fragments.

If the IP header has the DF bit set, the LSR doesn't fragment the IP packet, but it drops the packet and returns an ICMP error message "Fragmentation needed and do not fragment bit set" to the originator of the IP packet (following the same procedure as with traceroute).

Fragmentation should be avoided if possible.

IOS uses MRU in order to "inform" the LSR how big a received labeled packet of a certain FEC can be in order for that to be forwarded out of this LSR without fragmenting it.

IOS
R6#sh mpls forwarding-table 19.19.19.19 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
None       No Label   19.19.19.19/32   0             Fa0/0.619 20.6.19.19
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA020BB00008CA01063000008100026B0800
        No output feature configured

Pages

Thursday, February 6, 2014

NTS: MPLS/LDP

MPLS/LDP

2 comments: