cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2004
Views
20
Helpful
7
Replies

ASR 9000 - mpls LDP labels are not passed over Traffic engineering tunnels

yevgenyl
Level 1
Level 1

Hello,

I am encountering a strange issue during a setup of a new ASR9K router.

 

Simplified illustration of the nodes:

(PE-A)  -  (PE-B)  -  (PE-C)
1.1.1.1   2.2.2.2    3.3.3.3   

I have established rsvp tunnels between A to B, and B to A.

Traffic to C is to B and B to C over LDP.

 

Traffic flow direction from C to B to A is working well.

Traffic flow from A to B is working well, but between A to C is not working when TE between A to B is up.

 

From my checks, it's clearly that LDP labels are not passing through the tunnels, and I'm missing the outgoing levels.

 

Before establishing the TE tunnels, traffic was passing between all 3 nodes.
Meaning, LDP labels are in place.

I have added the tunnels at the head lsp router to the "mpls lsp" hierarchy.

I'm not seeing what I'm missing here.

Kindly suggest further checks that I could do.

 

I replaced the real ips in notepad out of privacy reasons, but other than that, the output is real.

The following output is all from PE-A alone and contains ldp and rsvp sessions and settings to PE-B

 

mpls ldp
router-id 1.1.1.1
!
interface tunnel-te5247
!
interface tunnel-te5747
!
interface TenGigE0/0/2/1.2552
!
interface TenGigE0/0/2/2.2557

Tunnel example:
======================

 

 

interface tunnel-te5247
description TO_PE-B
ipv4 unnumbered Loopback0
load-interval 30
signalled-bandwidth 0
load-share 750
autoroute announce
!
destination 2.2.2.2
path-option 1 explicit name EP_TO_PE-B

With LDP Alone (tunnels are shutdown):
=====================================

 

PE-A#sh mpls forwarding prefix 3.3.3.3/32 det
Tue Jan  2 22:50:19.660 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes       
Label  Label       or ID              Interface                    Switched    
------ ----------- ------------------ ------------ --------------- ------------
24057  24000       3.3.3.3/32    Te0/0/2/1.2552 10.46.0.213     7443889704  
     Updated: Dec 30 15:34:55.590
     Version: 4045, Priority: 3
     Label Stack (Top -> Bottom): { 24000 }
    NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0
     MAC/Encaps: 18/22, MTU: 8986
     Packets Switched: 7131894

       24000       3.3.3.3/32    Te0/0/2/2.2557 10.46.0.217     3516632056  
     Updated: Dec 31 17:14:05.727
    Version: 4045, Priority: 3
     Label Stack (Top -> Bottom): { 24000 }
     NHID: 0x0, Encap-ID: N/A, Path idx: 1, Backup path idx: 0, Weight: 0
     MAC/Encaps: 18/22, MTU: 8986
     Packets Switched: 4441161

With TE up (tunnels unshut):
=============================

 

RP/0/RSP0/CPU0:PE-B#sh mpls forwarding prefix 3.3.3.3/32 det
Tue Jan  2 22:55:52.704 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes       
Label  Label       or ID              Interface                    Switched    
------ ----------- ------------------ ------------ --------------- ------------
24057  Unlabelled  3.3.3.3/32    tt5247       2.2.2.2     0           
     Updated: Jan  2 22:54:45.001
     Version: 4349, Priority: 3
     Label Stack (Top -> Bottom): { Imp-Null Unlabelled }
     NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0
     MAC/Encaps: 18/18, MTU: 8986
     Packets Switched: 0

       Unlabelled  3.3.3.3/32    tt5747       2.2.2.2     7108        
     Updated: Jan  2 22:54:45.001
     Version: 4349, Priority: 3
     Label Stack (Top -> Bottom): { Imp-Null Unlabelled }
     NHID: 0x0, Encap-ID: N/A, Path idx: 1, Backup path idx: 0, Weight: 0
     MAC/Encaps: 18/18, MTU: 8986
     Packets Switched: 172
                
                 
RP/0/RSP0/CPU0:PE-B#sh mpls forwarding prefix 2.2.2.2/32 det 
Tue Jan  2 22:56:47.603 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes       
Label  Label       or ID              Interface                    Switched    
------ ----------- ------------------ ------------ --------------- ------------
24008  Pop         2.2.2.2/32     tt5247       2.2.2.2     414         
     Updated: Jan  2 22:54:45.001
     Version: 4347, Priority: 3
     Label Stack (Top -> Bottom): { Imp-Null Imp-Null }
     NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0
     MAC/Encaps: 18/18, MTU: 8986
     Packets Switched: 5

       Pop         2.2.2.2/32     tt5747       2.2.2.2     0           
     Updated: Jan  2 22:54:45.001
     Version: 4347, Priority: 3
     Label Stack (Top -> Bottom): { Imp-Null Imp-Null }
     NHID: 0x0, Encap-ID: N/A, Path idx: 1, Backup path idx: 0, Weight: 0
     MAC/Encaps: 18/18, MTU: 8986
     Packets Switched: 0
                

RP/0/RSP0/CPU0:PE-B#sh mpls interfaces 
Tue Jan  2 22:57:12.589 UTC
Interface                  LDP      Tunnel   Static   Enabled 
-------------------------- -------- -------- -------- --------
tunnel-te5247              Yes      No       No       Yes
tunnel-te5747              Yes      No       No       Yes
TenGigE0/0/2/1.2552        Yes      Yes      No       Yes
TenGigE0/0/2/2.2557        Yes      Yes      No       Yes


RP/0/RSP0/CPU0:PE-B#sh mpls ldp bindings 3.3.3.3/32
Tue Jan  2 23:04:06.598 UTC
3.3.3.3/32, rev 171
        Local binding: label: 24057
        Remote bindings: (2 peers)
            Peer                Label    
            -----------------   ---------
            2.2.2.2:0       24000   
            4.4.4.4:0     24003   

Under "sh mpls ldp forwarding detail" all ldp sessions going through the TE tunnels are down.

1 Accepted Solution

Accepted Solutions

Hello yevgenl1,

thanks for your kind remarks

>> I appears that not all TE tunnels from router PE-B facing PE-A were also under mpls ldp.

this was the root cause

 

>>

I'm not sure why. Could it be that the labels signaling were from B to A was passing via rsvp tunnels which were not carrying them?

Could you explain the logic?

 

The logic is that the LSR node when performs LDP tunneling might choice a tunnel not properly configured, because MPLS operations are quite "brute force."

 

To make an example connectivity in an MPLS L3 VPN can be broken if two IGP equal cost paths exist between PE nodes one with MPLS LDP enabled and the other with MPLS disabled

 

You are running quite new IOS XR 6.1.4 that might not need anymore the command with the accept option.

However, for correct LDP tunneling operation all the tunnels have to be listed within the mpls ldp config section because the choice of the exit tunnel to be used is based on the LDP label value of the MPLS frame to be tunneled. Traffic carried inside the LDP signaled label switched path might be not inspected deeper.

Again to make a comparison Juniper LDP tunneling requires tunnel interface to be configured under the hierarchy [edit protocols ldp ] and [edit mpls].

 

This helps the backbone node to save on memory used and allows the LDP signaled LSPs to travel an inner core made of MPLS traffic engineered RSVP TE signaled LSPs.

 

This is a scalability tecnique.

 

Hope to help

Giuseppe

 

View solution in original post

7 Replies 7

Harold Ritter
Level 12
Level 12

Hi,

 

What version of XR are you running? Could you provide the output of the "show mpls ldp discovery"from PE-A and PE-B? Could you try configuring the following on both PE-A and PE-B and see if it fixes the issue:

 

mpls ldp discovery targeted-hello accept

 

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hello,

 

I appreciate the answers of all of you, guys.

The version of the routers PE-A and PE-B is  Version 6.1.4 which is ASR9000, and of PE-C is 1K 03.13.03.S.

 

I also tried the command "mpls ldp discovery targeted-hello accept" but i dont have the "accept" part.

I have:

PE-A(config-ldp)#discovery hello ?
  holdtime  Hello holdtime
  interval  Hello interval

 

However, I did manage to solve it by "accident".

I appears that not all TE tunnels from router PE-B facing PE-A were also under mpls ldp.

Adding all of them resolved the original issue (labels of PE-C not appearing on PE-A when TE facing PE-B was up).

I'm not sure why. Could it be that the labels signaling were from B to A was passing via rsvp tunnels which were not carrying them?

Could you explain the logic?

Hello yevgenl1,

thanks for your kind remarks

>> I appears that not all TE tunnels from router PE-B facing PE-A were also under mpls ldp.

this was the root cause

 

>>

I'm not sure why. Could it be that the labels signaling were from B to A was passing via rsvp tunnels which were not carrying them?

Could you explain the logic?

 

The logic is that the LSR node when performs LDP tunneling might choice a tunnel not properly configured, because MPLS operations are quite "brute force."

 

To make an example connectivity in an MPLS L3 VPN can be broken if two IGP equal cost paths exist between PE nodes one with MPLS LDP enabled and the other with MPLS disabled

 

You are running quite new IOS XR 6.1.4 that might not need anymore the command with the accept option.

However, for correct LDP tunneling operation all the tunnels have to be listed within the mpls ldp config section because the choice of the exit tunnel to be used is based on the LDP label value of the MPLS frame to be tunneled. Traffic carried inside the LDP signaled label switched path might be not inspected deeper.

Again to make a comparison Juniper LDP tunneling requires tunnel interface to be configured under the hierarchy [edit protocols ldp ] and [edit mpls].

 

This helps the backbone node to save on memory used and allows the LDP signaled LSPs to travel an inner core made of MPLS traffic engineered RSVP TE signaled LSPs.

 

This is a scalability tecnique.

 

Hope to help

Giuseppe

 

Thank you, Giuseppe.

Your detailed answer helps a lot for my understanding of how this works.

You are wellcome
CSC forums are this
Best Regards
Giuseppe Larosa

Francesco Molino
VIP Alumni
VIP Alumni
Hi

As the LSR is more than 1 hop, then it's normally sending targeted ldp hello packets.
The default behavior is to ignore those packets.
You can allow the LSR to accept those packets by issuing the mpls ldp discovery targeted-hello accept command.

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Rated as deserved both you Francesco and Harold.
This is one of the differences between IOS and IOS XR.

Here the original poster is attempting to have end to end LDP LSPs transported inside MPLS TE tunnels. From the point of view of the IOS XR signaling plane the LDP messages are exchanged over the tunnel (because the tunnel is listed within mpls ldp config section).
In Juniper world this is called LDP tunneling. The principles and the commands are similar.

Best Regards
Giuseppe Larosa
Review Cisco Networking for a $25 gift card