Routing
Routing

RSVP ldp-tunneling strange problem

[ Edited ]
3 weeks ago

Hello everyone.

I`m having strange issue with ldp-tunneling over rsvp lsp.

My network diagram looks like this:

image.png

RSVP sessions is istablished between two mx routers. ldp-tunneling is enabled:

label-switched-path LSP-1 {
    from 172.18.2.1;
    to 172.18.2.2;
    ldp-tunneling;
}

traffic engineering is turned on MX104-1 and MX104-2

There is no traffic engineering in area 1.

on MX104-1 and MX104-2 interface lo0.0 is configured under protocols ldp.

on EX4600 ldp is turned on interfaces facing MXs and on interface between EX4600s and lo0.0.

So far so good. I got all loopbacks in ldp database and inet.3 tables.

So i configure l2circuit between two EX switches:

neighbor 172.18.1.254 {
    interface xe-0/0/0.700 {
        virtual-circuit-id 1000;
        no-control-word;
        encapsulation-type ethernet-vlan;
        ignore-mtu-mismatch;
    }
}

Circuit is up and running.

But when i tear link between two EX switches l2circuit goes down.

Neighbor: 172.18.1.254
    Interface                 Type  St     Time last up          # Up trans
    xe-0/0/0.700(vc 1000)     rmt   OL

So after checking inet.3 table on EX4600-2 i see that all loopbacks there 

 

172.18.1.254/32    *[LDP/9] 00:01:45, metric 1
                    >  to 172.18.1.2 via xe-0/0/0.2, Push 312560
172.18.2.2/32 *[LDP/9] 00:00:45, metric 1
                    >  to 172.18.1.2 via xe-0/0/0.2
172.18.2.1/32 *[LDP/9] 00:01:45, metric 1
                    >  to 172.18.1.2 via xe-0/0/0.2, Push 312192

But from the side of EX4600-1 i can see only MX104-1 172.18.2.1/32.

While in ldp database i can see all FECs:

Input label database, 172.18.1.254:0--172.18.1.253:0
Labels received: 5
  Label     Prefix
      3      172.18.1.253/32
     23      172.18.1.254/32
     19      172.18.2.2/32
     17      172.18.2.1/32
     20      L2CKT NoCtrlWord VLAN VC 1000

Output label database, 172.18.1.254:0--172.18.1.253:0
Labels advertised: 3
  Label     Prefix
      3      172.18.1.254/32
     21      172.18.2.1/32
  

Input label database, 172.18.1.254:0--172.18.2.1:0
Labels received: 2
  Label     Prefix
    381      172.18.1.254/32
      3      172.18.2.1/32


Output label database, 172.18.1.254:0--172.18.2.1:0
Labels advertised: 2
  Label     Prefix
      3      172.18.1.254/32
     21      172.18.2.1/32
 

 

show l2circuit connections:

Legend for interface status
Up -- operational
Dn -- down
Neighbor: 172.18.1.253
    Interface                 Type  St     Time last up          # Up trans
    xe-0/0/3.700(vc 1000)     rmt   VC-Dn  -----                          0
      Remote PE: 172.18.1.253, Negotiated control-word: No
      Incoming label: 17, Outgoing label: 20
      Negotiated PW status TLV: No
      Local interface: xe-0/0/3.700, Status: Up, Encapsulation: VLAN
      Flow Label Transmit: No, Flow Label Receive: No

 

10 REPLIES 10
Routing

Re: RSVP ldp-tunneling strange problem

3 weeks ago

Hi Smelnik

 

Can you share the configurations from MX and EX?

 

 

Routing

Re: RSVP ldp-tunneling strange problem

3 weeks ago

Hello.

I`m sorry, but i can not do this Smiley Sad

I`ve noticed one strange thing on MX1:

172.18.1.253 (EX2 lo0) is in database:

Input label database, 172.18.2.1:0--172.18.2.2:0
Labels received: 5
  Label     Prefix
 312240      172.18.1.253/32
 312560      172.18.1.254/32

But its not in inet.3 tables, and its not in hidden routes:

run show route 172.18.1.253 table inet.3

inet.3: 6 destinations, 8 routes (4 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 19w0d 08:35:14
                      Discard

show route 172.18.1.253 table inet.3 hidden [edit]
Routing

Re: RSVP ldp-tunneling strange problem

3 weeks ago

Hi Smelnik

What about the inet.0 route in MX1?

show route 172.18.1.253

 

Also, how is the EX1 route in MX2?

show route 172.18.1.254

Routing

Re: RSVP ldp-tunneling strange problem

3 weeks ago

Both routes are in inet.0:

show route 172.18.1.253

172.18.1.253/32    *[OSPF/10] 04:43:24, metric 9
                    > to x.x.x.x via xe-2/0/1.100

show route 172.18.1.254
172.18.1.254/32    *[OSPF/10] 05:48:59, metric 1
                    > to 172.18.1.1 via xe-2/0/0.2

inet.3: 6 destinations, 8 routes (4 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both

172.18.1.254/32    *[LDP/9] 05:45:46, metric 1
                    > to 172.18.1.1 via xe-2/0/0.2

I can ping all of the loopbacks.

Routing

Re: RSVP ldp-tunneling strange problem

3 weeks ago
show route 172.18.1.253

172.18.1.253/32    *[OSPF/10] 04:43:24, metric 9
                    > to x.x.x.x via xe-2/0/1.100

 

Which is this next-hop?

From the metric, it looks to me that it is a longer path unlike the route below

show route 172.18.1.254
172.18.1.254/32    *[OSPF/10] 05:48:59, metric 1
                    > to 172.18.1.1 via xe-2/0/0.2

 

 

Routing

Re: RSVP ldp-tunneling strange problem

[ Edited ]
3 weeks ago

Right now i`ve got link between EX4600-1 and EX4600-2 teared down. 

So next-hop for 172.18.1.253 is interface address on MX104-2.

image.png

Routing

Re: RSVP ldp-tunneling strange problem

3 weeks ago
There is no traffic engineering in area 1.

Why is traffic engineering for ospf not enabled for area 1?

You have a ring in this area so this should be enabled and required.

 

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Routing

Re: RSVP ldp-tunneling strange problem

3 weeks ago

Hello.

But there is no rsvp in area 1. Dont think it will be something in ted after turning on te for area 1.

Routing
Solution
Accepted by topic author smelnik
2 weeks ago

Re: RSVP ldp-tunneling strange problem

2 weeks ago

So the problem was on MX104-2.

In protocols ospf for area 0 interface lo0.0 there was set "metric 10". After removing this statement everything worked as expected.

The only question left - why removing metric helped?

Routing

Re: RSVP ldp-tunneling strange problem

2 weeks ago

Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks Some other vendors use an OSPF metric of 1 for the loopback address. Juniper Networks routers use an OSPF metric of 0 for the loopback address. This might require that you manually configure the RSVP metric when deploying LDP tunneling over RSVP LSPs in heterogeneous networks. When a Juniper Networks router is linked to another vendor’s router through an RSVP tunnel, and LDP tunneling is also enabled, by default the Juniper Networks router might not use the RSVP tunnel to route traffic to the LDP destinations downstream of the other vendor’s egress router if the RSVP path has a metric of 1 larger than the physical OSPF path. To ensure that LDP tunneling functions properly in heterogeneous networks, you can configure OSPF to ignore the RSVP LSP metric by including the ignore-lsp-metrics