Routing

last person joined: 3 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  RSVP ldp-tunneling strange problem

    Posted 08-27-2019 08:13

    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
    

     



  • 2.  RE: RSVP ldp-tunneling strange problem

     
    Posted 08-27-2019 11:51

    Hi Smelnik

     

    Can you share the configurations from MX and EX?

     

     



  • 3.  RE: RSVP ldp-tunneling strange problem

    Posted 08-27-2019 12:14

    Hello.

    I`m sorry, but i can not do this 😞

    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]


  • 4.  RE: RSVP ldp-tunneling strange problem

     
    Posted 08-27-2019 12:23

    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



  • 5.  RE: RSVP ldp-tunneling strange problem

    Posted 08-27-2019 12:50

    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.



  • 6.  RE: RSVP ldp-tunneling strange problem

     
    Posted 08-27-2019 13:15
    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
    

     

     



  • 7.  RE: RSVP ldp-tunneling strange problem

    Posted 08-28-2019 01:12

    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



  • 8.  RE: RSVP ldp-tunneling strange problem

    Posted 08-28-2019 02:52
    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.

     

     



  • 9.  RE: RSVP ldp-tunneling strange problem

    Posted 08-28-2019 06:37

    Hello.

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



  • 10.  RE: RSVP ldp-tunneling strange problem
    Best Answer

    Posted 09-04-2019 00:38

    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?



  • 11.  RE: RSVP ldp-tunneling strange problem

    Posted 09-04-2019 02:53

    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