Showing posts with label LDP. Show all posts
Showing posts with label LDP. Show all posts

Thursday, February 6, 2014

NTS: CsC

CsC




CsC (Carrier supporting Carrier) is defined in RFC 4364.



Control-Plane
  • The Customer Carrier PEs run BGP VPNv4 in order to exchange VPN labels
  • The Customer Carrier routers run IGP+LDP (or iBGP+Label) in order to exchange all their internal BGP next-hops and their labels
  • The CsC-PEs and CsC-CEs run eBGP (or IGP) in order to exchange BGP next-hop prefixes
  • The CsC-PEs and CsC-CEs run eBGP+Label (or IGP+LDP) in order to exchange labels for the BGP next-hop prefixes
  • The Backbone Carrier routers run IGP+LDP in order to exchange all their internal BGP next-hops and their labels

The Backbone Carrier offers a MPLS VPN service to the Customer Carrier which in turn offers a MPLS VPN or Internet service to its customers.

The Backbone Carrier doesn't need to know the final customer prefixes.

Using IGP+LDP in CsC is not as risky as with Inter-AS MPLS VPN Option 3 because:
  • Customer Carrier internal routes are put into a specific VRF in the Backbone Carrier
  • No Backbone Carrier internal routes are distributed into the Customer Carrier network

You can have multiple Backbone Carriers, using Inter-AS MPLS L3VPN for interconnection.

By default a CsC-PE runs PHP towards the CsC-CE. If using an ipv4-labeled PE-CE session, you can change this behavior (in order to keep the QoS consistent across providers) by using the "neighbor x.x.x.x send-label explicit-null" on the CsC-CE.

IOS-XR supports only the use of Labeled BGP as a PE-CE protocol in CsC topologies. LDP (+IGP) is not supported.



CsC Load Balancing

Load balancing between CsC-PE and CsC-CE can be achieved with:
  • directly connected loopback peering for one pair of PE/CE
    • one eBGP session between neighbors
    • multiple static routes for each other's loopback
    • mpls forwarding on all directly connected physical interfaces
  • eBGP multipath for multiple pairs of PEs/CEs
    • maximum-paths under bgp & vrf address family on PE
    • maximum-paths under bgp on CE

When using static routes, you also need to define the outgoing interface and the next-hop.

"mpls bgp forwarding" is not automatically added, because the BGP session is not between directly connected neighbors. You have to add it yourself.



Configuration


BC = Backbone Carrier (AS10)
CC = Customer Carrier (AS100)
C = Customer (AS200)

Backbone Carrier runs IS-IS or OSPF with MPLS/LDP in its core

Backbone Carrier (CsC-PE1) runs OSPF+LDP with Customer Carrier (CsC-CE1)
Backbone Carrier (CsC-PE2) runs eBGP+Label with Customer Carrier (CsC-CE2)

Customer Site 1 (C-CE1) runs OSPF with Customer Carrier (CC-PE1)
Customer Site 2 (C-CE2) runs ISIS with Customer Carrier (CC-PE2)

CC-PE (Customer Carrier PE serving the final customer site) and CsC-CE (Carrier supporting Carrier CE) functionalities can be collapsed into a single router.

CsC-PE1 and CsC-PE2 run iBGP VPNv4 in order to exchange Customer Carrier prefixes/labels
CsC-CE1 and CsC-CE2 run iBGP VPNv4 in order to exchange Customer prefixes/labels



IGP+LDP between CsC-PE1 and CsC-CE1


CsC-PE1 (IOS)
! for connectivity to BC core (IGP+LDP)
mpls ldp router-id Loopback0
mpls label protocol ldp
!
interface Ethernet0/2
 description ** Link to BC core **
 ip address x.x.x.x

 mpls ip
!
router isis/ospf x
!
! for connectivity to CsC-CE1 (OSPF+LDP)
vrf definition CC-VPN
 rd 10:X

 route-target 10:X
!
 address-family ipv4

 exit-address-family
!
interface Ethernet1/0

 description ** Link to CsC-CE1 **
 vrf forwarding CC-VPN
 ip address x.x.x.x
 mpls ip
!
router ospf 10 vrf CC-VPN
 redistribute bgp 10 subnets
 network x.x.x.x area 0
!

! for connectivity to BC-PE2 (iBGP VPNv4)
router bgp 10

 no bgp default ipv4-unicast
 neighbor BC-PE2 remote-as 10
 neighbor BC-PE2 update-source Loopback0
 !
 address-family vpnv4
  neighbor BC-PE2 activate
  neighbor BC-PE2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf CC-VPN
  redistribute ospf 10 vrf CC-VPN
 exit-address-family




CsC-CE1 (IOS)
! for connectivity to CsC-PE1 (OSPF+LDP)
mpls ldp router-id Loopback0
mpls label protocol ldp
!
interface Ethernet1/0
 description ** Link to CsC-PE1 **
 ip address x.x.x.x
 mpls ip
!

router ospf 10
 network x.x.x.x area 0
!


CC-PE1 (IOS)
! for connectivity to C-CE1 (OSPF+VRF)  
vrf definition C-VPN
 rd 100:Y
 route-target 100:Y
 !
 address-family ipv4
 exit-address-family
!

interface Ethernet1/3
 description ** Link to C-CE1 **
 vrf forwarding C-VPN
 ip address y.y.y.y
!

router ospf 200 vrf C-VPN
 redistribute bgp 100 subnets
 network y.y.y.y area 0
!

! for connectivity to CC-PE2 (iBGP VPNv4)  
router bgp 100
 no bgp default ipv4-unicast
 neighbor CC-PE2 remote-as 100
 neighbor
CC-PE2 update-source Loopback0
 !
 address-family vpnv4
  neighbor
CC-PE2 activate
  neighbor
CC-PE2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf C-VPN
  redistribute ospf 200 vrf C-VPN
 exit-address-family
!



BGP+Label between CsC-PE2 and CsC-CE2


CsC-PE2 (IOS-XR)
! for connectivity to BC core (IGP+LDP)
mpls ldp router-id Loopback0
mpls label protocol ldp
!
router isis/ospf x
!

mpls ldp
 router-id x.x.x.x
 interface x
!

! for connectivity to CsC-CE2  (eBGP+Label)
vrf CC-VPN
 address-family ipv4 unicast
  import route-target
   10:X
  export route-target
   10:X
!
interface GigabitEthernet0/2/1/1
 description ** Link to CsC-CE2 **
 vrf CC-VPN
 ipv4 address x.x.x.x
!

router static
 vrf CC-VPN
  address-family ipv4 unicast
   CsC-CE2/32 GigabitEthernet0/2/1/1

!
router bgp 10
 address-family ipv4 unicast
 !

 vrf CC-VPN
  rd 10:X
  address-family ipv4 unicast
   network x.x.x.x
   allocate-label all
  !
  neighbor CsC-CE2
   remote-as 100
   address-family ipv4 unicast
    route-policy PASS-RPL in
    route-policy PASS-RPL out
    as-override
    send-extended-community-ebgp
   !
   address-family ipv4 labeled-unicast
    route-policy PASS-RPL in
    route-policy PASS-RPL out
    as-override
    send-extended-community-ebgp
!

route-policy PASS-RPL 
  pass
end-policy

!
! for connectivity to BC-PE1 (iBGP VPNv4)  
router bgp 10
 address-family vpnv4 unicast
 !
 neighbor BC-PE1
  remote-as 10
  update-source Loopback0
  address-family vpnv4 unicast



CsC-CE2 (IOS)
! for connectivity to CsC-PE2  (eBGP+Label)
interface Ethernet1/0
 description ** Link to CsC-PE2 **
 ip address x.x.x.x
 mpls bgp forwarding
!

router bgp 100
 no bgp default ipv4-unicast
 neighbor CsC-PE2 remote-as 10
 !
 address-family ipv4
  neighbor CsC-PE2 activate
  neighbor CsC-PE2 send-label
 exit-address-family

!
! for connectivity to C-CE2 (ISIS+VRF)
vrf definition C-VPN
 rd 100:Y

 route-target 100:Y
 !
 address-family ipv4
 exit-address-family
!

interface Ethernet1/3
 description ** Link to C-CE2 **
 vrf forwarding C-VPN
 ip address y.y.y.y
 ip router isis 200
!
router isis 200
 vrf C-VPN
  redistribute bgp 100
!

! for connectivity to CC-PE1 (iBGP VPNv4)  
router bgp 100
 neighbor CC-PE1 remote-as 100
 neighbor CC-PE1 update-source Loopback0
 !
 address-family vpnv4
  neighbor CC-PE1 activate
  neighbor CC-PE1 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf C-VPN
  redistribute isis 200

 exit-address-family


IOS-XR configuration is similar to IOS, with the major difference of using the labeled unicast address-family instead of the send-label keyword.

Don't forget to create a /32 static route for the CsC-PE/CE next-hop in IOS-XR when using eBGP+Label. Always verify the installation of labels for /32 next-hops.



Verification
  • Customer Carrier PEs must have a BGP VPNv4 route and a label for the VPN prefix
  • Customer Carrier routers must have a label for the VPN prefix's next-hop
  • CsC-PEs must have a BGP VPNv4 route and a label for the VPN prefix's next-hop
  • Backbone Carrier routers must have a label for the next-hop of VPN prefix's next-hop



    Example

    Assume the following network:

    R1-R2-R3-R4-R5-R6-R7-R8-R9-R10

    where

    Customer Carrier Network
    Backbone Carrier Network


    Then the following would happen for a VPN packet originating at R1 and terminating at R10.
    • R1 (1.1.1.1) (Customer Carrier PE router) - vrf VPN
      • Transport label is 18, VPN label is 20
      • next-hop is R10 (10.10.10.10)
    • R2 (2.2.2.2) (Customer Carrier P router)
      • Transport label is 20, VPN label is 20
      • next-hop is R10 (10.10.10.10)
    • R3 (3.3.3.3) (CsC-CE)
      • Transport label is 26, VPN label is 20
      • next-hop is R10 (10.10.10.10)
    • R4 (4.4.4.4) (CsC-PE) - vrf CSC
      • Transport label is 16/21, VPN label is 20
      • next-hop is R7 (7.7.7.7)
    • R5 (5.5.5.5) Backbone Carrier P router)
      • Transport label is 16/21, VPN label is 20
      • next-hop is R7 (7.7.7.7)
    • R6 (6.6.6.6) (Backbone Carrier P router)
      • Transport label is 21, VPN label is 20
      • next-hop is R7 (7.7.7.7)
    • R7 (7.7.7.7) (CsC-PE) - vrf CSC
      • Transport label is 18, VPN label is 20
      • next-hop is R10 (10.10.10.10)
    • R8 (8.8.8.8) (CsC-CE)
      • Transport label is 17, VPN label is 20
      • next-hop is R10 (10.10.10.10)
    • R9 (9.9.9.9) (Customer Carrier P router)
      • Transport label is removed, VPN label is 20
      • next-hop is R10 (10.10.10.10)
    • R10 (10.10.10.10) (Customer Carrier PE router) - vrf VPN
      • VPN label is removed, destination reached in next-hop


    R1#trace vrf VPN 99.99.99.99

    Type escape sequence to abort.
    Tracing the route to 99.99.99.99

      1 20.1.2.2 [MPLS: Labels 18/20 Exp 0] 10 msec 10 msec 8 msec
      2 20.2.3.3 [MPLS: Labels 20/20 Exp 0] 7 msec 7 msec 7 msec

      3 20.3.4.4 [MPLS: Labels 26/20 Exp 0] 8 msec 8 msec 7 msec
      4 20.4.5.5 [MPLS: Labels 16/21/20 Exp 0] 7 msec 7 msec 8 msec
      5 20.5.6.6 [MPLS: Labels 16/21/20 Exp 0] 6 msec 5 msec 5 msec
      6 20.6.7.7 [MPLS: Labels 21/20 Exp 0] 3 msec 3 msec 3 msec

      7 20.7.8.8 [MPLS: Labels 18/20 Exp 0] 1 msec 1 msec 1 msec
      8 20.8.9.9 [MPLS: Labels 17/20 Exp 0] 1 msec 1 msec 1 msec
      9 20.9.10.10 [MPLS: Label 20 Exp 0] 1 msec 1 msec 1 msec

     10 30.10.10.99 1 msec 2 msec 2 msec



    Verification in every hop


    Customer Carrier PE router
    R1#sh ip route vrf VPN 99.99.99.99

    Routing Table: VPN
    Routing entry for
    99.99.99.99/32
      Known via "bgp 100", distance 200, metric 1, type internal
      Redistributing via rip
      Advertised by rip metric transparent
      Last update from 10.10.10.10 00:56:37 ago
      Routing Descriptor Blocks:
      *
    10.10.10.10 (default), from 10.10.10.10, 00:56:37 ago
          Route metric is 1, traffic share count is 1
          AS Hops 0
          MPLS label: 20
          MPLS Flags: MPLS Required


    R1#sh bgp vpnv4 unicast vrf VPN 99.99.99.99/32
    BGP routing table entry for 100:1:
    99.99.99.99/32, version 11
    Paths: (1 available, best #1, table VPN)
      Not advertised to any peer
      Local
       
    10.10.10.10 (metric 20) from 10.10.10.10 (10.10.10.10)
          Origin incomplete, metric 1, localpref 100, valid, internal, best
          Extended Community: RT:100:1
          mpls labels in/out nolabel/20


    VPN label is 20

    R1#sh mpls forwarding-table 10.10.10.10 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    23         18        
    10.10.10.10/32   0             Fa0/0.12   20.1.2.2
            MAC/Encaps=18/22, MRU=1500, Label Stack{18}
            CA0113DC0000CA03079400088100026C8847 00012000
            No output feature configured


    R1#sh ip cef vrf VPN 99.99.99.99 det99.99.99.99/32, epoch 0, flags rib defined all labels
      recursive via
    10.10.10.10 label 20
        nexthop 20.1.2.2 FastEthernet0/0.12 label 18


    Transport label is 18, VPN label is 20


    From here you have 2 options:
    • follow the next-hops
    • follow the labels (i prefer this one)



    Following the next-hops



    Customer Carrier P router
    R2#sh mpls forwarding-table 10.10.10.10 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    18         20        
    10.10.10.10/32   13707         Fa0/0.23   20.2.3.3
            MAC/Encaps=18/22, MRU=1500, Label Stack{20}
            CA0610240000CA0113DC00008100002E8847 00014000
            No output feature configured


    Transport label is 20, VPN label is 20

    CsC-CE
    R3#sh mpls forwarding-table 10.10.10.10 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    20         26        
    10.10.10.10/32   15048         Fa0/0.34   20.3.4.4
            MAC/Encaps=18/22, MRU=1500, Label Stack{26}
            CA0207940008CA0610240000810001A38847 0001A000
            No output feature configured


    Transport label is 26, VPN label is 20

    CsC-PE
    R4#sh mpls forwarding-table vrf CSC 10.10.10.10 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    26         21        
    10.10.10.10/32[V]16033         Fa0/0.45   20.4.5.5
            MAC/Encaps=18/26, MRU=1496, Label Stack{16 21}
            C20911080000CA0207940008810003338847 0001000000015000
            VPN route: CSC
            No output feature configured


    2 Transport labels are used (use "detail" to see them)

    R4#sh bgp vpnv4 unicast vrf CSC 10.10.10.10
    BGP routing table entry for 200:1:
    10.10.10.10/32, version 12
    Paths: (1 available, best #1, table CSC)
      Advertised to update-groups:
         3
      100
        7.7.7.7 (metric 4) from 7.7.7.7 (7.7.7.7)
          Origin incomplete, metric 20, localpref 100, valid, internal, best
          Extended Community: RT:200:1
          mpls labels in/out 26/21


    VPN label (21) for Backbone Carrier is actually Transport label (21) for Customer Carrier

    R4#sh mpls forwarding-table 7.7.7.7 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    16         16         7.7.7.7/32       0             Fa0/0.45   20.4.5.5
            MAC/Encaps=18/22, MRU=1500, Label Stack{16}
            C20911080000CA0207940008810003338847 00010000
            No output feature configured


    Transport label is 16/21, VPN label is 20

    Backbone Carrier P router
    R5#sh mpls forwarding-table 7.7.7.7 detail
    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
    tag    tag or VC   or Tunnel Id      switched   interface
    16     16          7.7.7.7/32        44218      Fa0/0.56   20.5.6.6
            MAC/Encaps=18/22, MRU=1500, Tag Stack{16}
            C20811080000C209110800008100004E8847 00010000
            No output feature configured
        Per-packet load-sharing


    Transport label is 16/21, VPN label is 20

    Backbone Carrier P router
    R6#sh mpls forwarding-table 7.7.7.7 detail
    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
    tag    tag or VC   or Tunnel Id      switched   interface
    16     Pop tag     7.7.7.7/32        42398      Fa0/0.67   20.6.7.7
            MAC/Encaps=18/18, MRU=1504, Tag Stack{}
            CA0415180000C20811080000810000118847
            No output feature configured
        Per-packet load-sharing


    Transport label is 21, VPN label is 20

    CsC-PE
    R7#sh mpls forwarding-table vrf CSC 10.10.10.10 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    21         18        
    10.10.10.10/32[V]24156         Fa0/0.78   20.7.8.8
            MAC/Encaps=18/22, MRU=1500, Label Stack{18}
            CA0710240000CA04151800008100000D8847 00012000
            VPN route: CSC
            No output feature configured


    Transport label is 18, VPN label is 20

    CsC-CE
    R8#sh mpls forwarding-table 10.10.10.10 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    18         17        
    10.10.10.10/32   24703         Fa0/0.89   20.8.9.9
            MAC/Encaps=18/22, MRU=1500, Label Stack{17}
            CA0013DC0000CA0710240000810000238847 00011000
            No output feature configured


    Transport label is 17, VPN label is 20

    Customer Carrier P router
    R9#sh mpls forwarding-table 10.10.10.10 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    17         Pop Label 
    10.10.10.10/32   23892         Fa0/0.910  20.9.10.10
            MAC/Encaps=18/18, MRU=1504, Label Stack{}
            CA0515180000CA0013DC0000810000198847
            No output feature configured


    Transport label is removed, VPN label is 20

    Customer Carrier PE router
    R10#sh mpls forwarding-table vrf VPN 99.99.99.99 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    20         No Label  
    99.99.99.99/32[V]1770          Fa0/0.1010 30.10.10.99
            MAC/Encaps=18/18, MRU=1504, Label Stack{}
            C20A0F840000CA05151800008100001D0800
            VPN route: VPN
            No output feature configured


    VPN label is removed, destination reached



    Following the labels


    Customer Carrier P router
    R2#sh mpls forwarding-table labels 18 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    18         20        
    10.10.10.10/32   13852         Fa0/0.23   20.4.6.4
            MAC/Encaps=18/22, MRU=1500, Label Stack{20}
            CA0610240000CA0113DC00008100002E8847 00014000
            No output feature configured



    Transport label is 20, VPN label is 20

    CsC-CE
    R3#sh mpls forwarding-table labels 20 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    20         26        
    10.10.10.10/32   15338         Fa0/0.34   20.4.19.19
            MAC/Encaps=18/22, MRU=1500, Label Stack{26}
            CA0207940008CA0610240000810001A38847 0001A000
            No output feature configured


    Transport label is 26, VPN label is 20

    CsC-PE
    R4#sh mpls forwarding-table labels 26 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    26         21        
    10.10.10.10/32[V]16645         Fa0/0.45   20.4.5.5
            MAC/Encaps=18/26, MRU=1496, Label Stack{16 21}
            C20911080000CA0207940008810003338847 0001000000015000
            VPN route: CSC
            No output feature configured


    2 Transport labels are used (use "detail" to see them)

    Transport label is 16/21, VPN label is 20

    Backbone Carrier P router
    R5#sh mpls forwarding-table labels 16 detail
    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
    tag    tag or VC   or Tunnel Id      switched   interface
    16     16          7.7.7.7/32        30421      Fa0/0.56   20.5.6.6
            MAC/Encaps=18/22, MRU=1500, Tag Stack{16}
            C20811080000C209110800008100004E8847 00010000
            No output feature configured
        Per-packet load-sharing


    Transport label is 16/21, VPN label is 20

    Backbone Carrier P router
    R6#sh mpls forwarding-table labels 16 detail
    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
    tag    tag or VC   or Tunnel Id      switched   interface
    16     Pop tag     7.7.7.7/32        29337      Fa0/0.67   20.6.7.7
            MAC/Encaps=18/18, MRU=1504, Tag Stack{}
            CA0415180000C20811080000810000118847
            No output feature configured
        Per-packet load-sharing


    Transport label is 21, VPN label is 20

    CsC-PE
    R7#sh mpls forwarding-table labels 21 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    21         18        
    10.10.10.10/32[V]17260         Fa0/0.78   20.7.8.8
            MAC/Encaps=18/22, MRU=1500, Label Stack{18}
            CA0710240000CA04151800008100000D8847 00012000
            VPN route: CSC
            No output feature configured


    Transport label is 18, VPN label is 20

    CsC-CE
    R8#sh mpls forwarding-table labels 18 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    18         17        
    10.10.10.10/32   17726         Fa0/0.89   20.8.9.9
            MAC/Encaps=18/22, MRU=1500, Label Stack{17}
            CA0013DC0000CA0710240000810000238847 00011000
            No output feature configured


    Transport label is 17, VPN label is 20

    Customer Carrier P router
    R9#sh mpls forwarding-table labels 17 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    17         Pop Label 
    10.10.10.10/32   17200         Fa0/0.910  20.9.10.10
            MAC/Encaps=18/18, MRU=1504, Label Stack{}
            CA0515180000CA0013DC0000810000198847
            No output feature configured


    Transport label is removed, VPN label is 20

    Customer Carrier PE router
    R10#sh mpls forwarding-table labels 20 detail
    Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
    Label      Label      or Tunnel Id     Switched      interface
    20         No Label  
    99.99.99.99/32[V]1770          Fa0/0.1010 30.10.10.99
            MAC/Encaps=18/18, MRU=1504, Label Stack{}
            C20A0F840000CA05151800008100001D0800
            VPN route: VPN
            No output feature configured


    VPN label is removed, destination reached




    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