Ignorer les commandes du ruban
Passer au contenu principal
SharePoint

Networking

juin 16
LDP session establishment

In Luc de Ghein's « MPLS fundamentals », at page 72, we learn that « In Cisco IOS, the MPLS LDP router ID needs to be present in the routing table of the LDP neighboring routers. If it is not, the LDP session is not formed. °»

We want to verify this assertion.

 

Software used in this scenario :

  • Hypervisor : VMware ESXi 6.0.0 build-2494585
  • Virtual router : IOS XE version 03.14.01.S, IOS version 15.5(1)S1
  • Cisco 3825 : Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9-M), Version 12.3(11)T7, RELEASE SOFTWARE (fc3)
  • Sniffer : Wireshark 2.0.1


 

Figure 1 : Network Topology Diagram

 

Find below the starting configuration of R1 and R2 :

​​===================================
R1
===================================
!
! to enable LDP because the default on IOS 12.3(11)T7 is TDP
!
mpls label protocol ldp
!
interface GigabitEthernet0/0
 ip address 192.168.10.1 255.255.255.0
 no shutdown
 mpls ip
!
!
===================================
R2
===================================
!
interface GigabitEthernet2
 ip address 192.168.10.2 255.255.255.0
 no shutdown
 mpls ip
!

        

First we need to understand how the LDP session is formed, to do that let's fire up wireshrak on Gi2 of R2

 

We see that R2 is trying to discover another LDP peer by sending « Hello Message ». Let' take a closer look at one of these frames, for example the frame numbered one

 

As you can see on the capture above, R2 (192.168.10.2) is trying to establish a LDP connection with a neighbor, by sending a « Hello Message » to the multicast group 224.0.0.2 (all routers on the same network segment) using the source and destination port UDP 646. You can also see that with no loopback or static LDP router ID configured, the LDP session uses the IP address of interface Gi2.

Digression : Before the IETF standardized LDP for exchanging labels between LSR, Cisco routers used a protocol developped by Cisco called TDP for « Taggued Distribution Protocol ». TDP uses the UDP port 711 to the broadcast address 255.255.255.255.

With the command below, we can see that the LDP identifier (4 bytes) on R2 is indeed Gi2, notice the platform-wide label space (2 bytes) after the LDP ID and also the Transport IP address (which we will discuss later):

​ R2#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.2:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet2 (ldp): xmit
            Enabled: Interface config
            Hello interval: 5000 ms; Transport IP addr: 192.168.10.2
            Clients: IPv4, mLDP

        

The different MPLS LDP default parameters for the session and the discovery can be seen with this command :

​R1#show mpls ldp parameters
Protocol version: 1
No label generic region for downstream label distribution
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 255
LDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec
LDP loop detection: off

 

​R2#show mpls ldp parameters
LDP Feature Set Manager: State Initialized
  LDP features:
    Auto-Configuration
    Basic
    ICPM
    IP-over-MPLS
    IGP-Sync
    LLAF
    TCP-MD5-Rollover
    TDP
    NSR
Protocol version: 1
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 255
LDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec
LDP loop detection: off
LDP NSR: Disabled

 

Let's take a closer look at the wireshark capture

 

As you can see on the screenshot above, the LSR R2 sends a TCP SYN to the LSR R1 using its interface GigaEthernet 2 (192.168.10.2) plus the destination port 646. The LSR R1 responds with a SYN/ACK using its interface GigaEthernet 0/0, as we configured. The LDP TCP connection is initiated by the highest LDP ID (LID), here R2 with the LID 192.168.10.2.

 

We now add a loopback on each LSR R1 and R2 :

===================================
R1
===================================
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 
===================================
R2
===================================
interface Loopback0
 ip address 2.2.2.2 255.255.255.255

        

Let's see if the LID or the Transport Address on R1 and R2 has not changed by using the command below,

​R1#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.1:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet0/0 (ldp): xmit/recv
            Hello interval: 5000 ms; Transport IP addr: 192.168.10.1
            LDP Id: 192.168.10.2:0
              Src IP addr: 192.168.10.2; Transport IP addr: 192.168.10.2
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
 

 

R2#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.2:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet2 (ldp): xmit/recv
            Enabled: Interface config
            Hello interval: 5000 ms; Transport IP addr: 192.168.10.2
            LDP Id: 192.168.10.1:0
              Src IP addr: 192.168.10.1; Transport IP addr: 192.168.10.1
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
              Reachable via 192.168.10.0/24
              Password: not required, none, in use
            Clients: IPv4, mLDP

        

Next, let's disable and re-enable the interface Gi0/0 on R1 and Gi2 on R2 and use the same command as before

​R1#show mpls ldp discovery detail
 Local LDP Identifier:
    1.1.1.1:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet0/0 (ldp): xmit/recv
            Hello interval: 5000 ms; Transport IP addr: 1.1.1.1
            LDP Id: 2.2.2.2:0; no route to transport addr
              Src IP addr: 192.168.10.2; Transport IP addr: 2.2.2.2
              Hold time: 15 sec; Proposed local/peer: 15/15 sec

 

​R2#show mpls ldp discovery detail
 Local LDP Identifier:
    2.2.2.2:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet2 (ldp): xmit/recv
            Enabled: Interface config
            Hello interval: 5000 ms; Transport IP addr: 2.2.2.2
            LDP Id: 1.1.1.1:0; no route to transport addr
              Src IP addr: 192.168.10.1; Transport IP addr: 1.1.1.1
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
              Password: not required, none, in use
            Clients: IPv4, mLDP

        

Look at the result above, the LID and the transport address are now equal to the value of the loopback.

As you migth know, the LDP ID is determined by the three rules below, in order of precedence :

  1. Configuration
  2. Highest IP address of an up and running loopback when LDP comes up
  3. Highest IP address of an up and running nonloopback when LDP comes up

 

We see in Wireshark that  the LSR ID and the Transport Address on R1 and R2 are now equal to their respective Loopback0.

 

 

 

What if we want to influence this behavior by specifying a physical interface, according to the previous rules, we can. Let's say we desire to use the interface Gi0/0 as a LID on R1, we just have to use this command :

​mpls ldp router-id GigabitEthernet 0/0 force

        

 

Note : the command above will break any LDP connection already established on the link.

Let's do the same on R2 and check the results with the previous command on R1 and R2

 

​R1#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.1:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet0/0 (ldp): xmit/recv
            Hello interval: 5000 ms; Transport IP addr: 192.168.10.1
            LDP Id: 192.168.10.2:0
              Src IP addr: 192.168.10.2; Transport IP addr: 192.168.10.2
              Hold time: 15 sec; Proposed local/peer: 15/15 sec

         

 

​R2#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.2:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet2 (ldp): xmit/recv
            Enabled: Interface config
            Hello interval: 5000 ms; Transport IP addr: 192.168.10.2
            LDP Id: 192.168.10.1:0
              Src IP addr: 192.168.10.1; Transport IP addr: 192.168.10.1
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
              Reachable via 192.168.10.0/24
              Password: not required, none, in use
            Clients: IPv4, mLDP

        

 

According to the RFC 5036, the Transport Address is an optional field defined as such :

      IPv4 Transport Address

         Specifies the IPv4 address to be used for the sending LSR when

         opening the LDP session TCP connection.  If this optional TLV

         is not present, the IPv4 source address for the UDP packet

         carrying the Hello SHOULD be used.

 

In summary, if the Transport Address is configured, it is used to establish the LDP TCP connection.

In Cisco IOS Version 12.3(11)T7 of R1 (platform 3825), we have the command below to configure the Transport Address using the Loopback0°:

​mpls ldp discovery transport-address 1.1.1.1

 

Note : Virtual router : IOS XE version 03.14.01.S, IOS version 15.5(1)S1 does not support the command above.

Let's switch to the Wireshark capture

 

 

LSR R1 is now using its Loopback0 interface as its Transport Address though the LSR ID of R1 is still its interface GigabitEthernet 0/0.

R1#show mpls ldp discovery detail
 Local LDP Identifier:
    192.168.10.1:0
    Discovery Sources:
    Interfaces:
        GigabitEthernet0/0 (ldp): xmit/recv
            Hello interval: 5000 ms; Transport IP addr: 1.1.1.1
            LDP Id: 192.168.10.2:0
              Src IP addr: 192.168.10.2; Transport IP addr: 192.168.10.2
              Hold time: 15 sec; Proposed local/peer: 15/15 sec

 

Notice that in the Wireshark capture, the LDP session is down

 

 

Now, if we add a static route to the Loopback0 of R1 on R2, the LDP session should be up again.

ip route 1.1.1.1 255.255.255.255 192.168.10.1

        

Indeed, we observe the LDP session is established in the Wireshark capture below. R1 is now using its transport address to establish the LDP session.

 

Conclusion,

​Luc de Ghein's assertion « In Cisco IOS, the MPLS LDP router ID needs to be present in the routing table of the LDP neighboring routers. If it is not, the LDP session is not formed. °» is verified but it is a particular case. It is  Mr de Ghein's assumes that the value of the LDP ID is equal to the transport address, this is true in most  MPLS cases but as we learned in this lab, you can customize your LDP session to use the transport address instead of the LDP router ID to establish the LDP session. If you do you will have to configure a static route or advertise the address using an IGP because the neighboring LSR needs to know how to reach the transport address you configured.

Commentaires

Aucun commentaire sur ce billet.