Thursday, February 6, 2014

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






1 comment: