Routing

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



  • 1.  ldp-tunneling over rsvp

    Posted 10-24-2021 19:17
    Hello! Im preparing for JNCIE-SP and got a question regarding ldp-tunneling over rsvp. we have 2 LDP islands. each island has 4 ldp routers, connected in a ring fashion. Routers have a ldp route to other routers in the same island, but not the remote island. the task is to connect the two islands via ldp-tunneling over rsvp. The end goal is to have each router have a LDP route to every other router. there are multiple rsvp sessions between the two islands but no LDP. my question is why do we need more than one rsvp session with ldp-tunneling enabled between the two islands?

    for example:
    island1: R1/ R2/ R3/ R4
    Island2: R8/ R7/ R6/ R5

    enabling ldp-tunneling between the two islands on one pair (for example R3-R8) would only get R3's lo0.0 into island2 and R8's into island1 - not the other routers. the only way I was able to meet the requirement is by enabling ldp-tunneling , meaning each ldp router have a ldp session over rsvp to remote island - semi full mesh in a way. can someone explain this behavior? if someone has self-study bundle this revolved around the same ask as in Chapter 4, Task2,  requirement 17.


  • 2.  RE: ldp-tunneling over rsvp

    Posted 25 days ago
    Hi,

    Did you enable LDP on R3 and R8's lo0 ? ldp-tunneling is establishing a TLDP session between the router's lo0 to change all LDP learned labels. 

    Regards,
    C

    ------------------------------
    CHRISTOPHE LEMAIRE
    ------------------------------



  • 3.  RE: ldp-tunneling over rsvp

    Posted 25 days ago
    Hi Christopher, 
    Yes I have interface lo0.0 added to ldp, and ldp-tunneling is enabled between R3-R8. this however only results in having R3 lo0.0 address redistributed into remote island, but not R1/R2/R4. not sure if any other policy is needed! 

    to simplify I have the following setup:

    High-level:
    island1 (10 routers in island1, R10 to R19)  < -----RSVP session with LDP-tunneling enabled----->  island2 ( 10 routers in island2,
    R20 to R29) 

    low-level:
    R10 < -----RSVP session with LDP-tunneling enabled----->  R20 

    Should this scenario have all R10-R19 loopback redistributed in island2 and vice versa? this is not working for me in code 20.1


  • 4.  RE: ldp-tunneling over rsvp

    Posted 23 days ago
    Hi Ali,
    Two more things to check:

    - LDP bindings received from R10 on R20. "show ldp database <R10's lo0 IP>"
    If R20 does not receive label bindings for R10-R19's lo0, there should be an issue on R10. Does R10 have all those lo0 in inet.3 learned from LDP ?

    - Routes in inet.0. LDP rely on IGP to install FEC in inet.3. If R20 has no routes towards R10-R19's lo0, it will not install FEC into inet.3.

    HTH,
    C


    ------------------------------
    Christophe Lemaire
    ------------------------------



  • 5.  RE: ldp-tunneling over rsvp

    Posted 23 days ago
    Hi Christophe, 
    I'm going to share some outputs hoping to answer your questions, please do no hesitate to ask more and correct my mistakes:

    Referring to the original topology, loopbacks are 172.30.5.x 
    island1: R1/ R2/ R3/ R4
    Island2: R8/ R7/ R6/ R5

    ldp-tunneling will be formed between R3/R8. 

    Checking R3 - we have active routes to all lo0 IPs:
    root@R3# run show route 172.30.5/24 active-path 
    
    inet.0: 733 destinations, 742 routes (674 active, 0 holddown, 61 hidden)
    @ = Routing Use Only, # = Forwarding Use Only
    + = Active Route, - = Last Active, * = Both
    
    172.30.5.1/32      @[IS-IS/15] 00:03:22, metric 15
                        >  to 172.30.0.13 via ge-0/0/4.123
    172.30.5.2/32      @[IS-IS/15] 00:03:22, metric 10
                        >  to 172.30.0.13 via ge-0/0/4.123
    172.30.5.3/32      *[Direct/0] 00:30:01
                        >  via lo0.0
    172.30.5.4/32      @[IS-IS/15] 00:03:22, metric 10
                        >  to 172.30.0.22 via ge-0/0/4.134
    172.30.5.5/32      *[IS-IS/15] 00:03:22, metric 16777219
                        >  to 172.30.0.26 via ge-0/0/4.136
    172.30.5.6/32      @[IS-IS/15] 00:03:22, metric 16777214
                        >  to 172.30.0.26 via ge-0/0/4.136
    172.30.5.7/32      *[IS-IS/15] 00:03:22, metric 16777224
                        >  to 172.30.0.13 via ge-0/0/4.123
                           to 172.30.0.26 via ge-0/0/4.136
    172.30.5.8/32      @[IS-IS/15] 00:03:22, metric 16777229
                           to 172.30.0.13 via ge-0/0/4.123
                        >  to 172.30.0.26 via ge-0/0/4.136
    172.30.5.41/32     *[IS-IS/15] 00:03:22, metric 16777224
                        >  to 172.30.0.13 via ge-0/0/4.123


    ldp neighbor is formed:

    Notice R8 loopback on lo0 ldp neighbor:
    root@R3# run show ldp interface 
    Interface          Address                          Label space ID   Nbr   Next
                                                                        count  hello
    lo0.0              172.30.5.3                       172.30.5.3:0      1      0
    ge-0/0/4.123       172.30.0.14                      172.30.5.3:0      1      3
    ge-0/0/4.134       172.30.0.21                      172.30.5.3:0      1      0
    
    [edit]
    root@R3# run show ldp neighbor 
    Address                             Interface       Label space ID     Hold time
    172.30.5.8                          lo0.0           172.30.5.8:0         33
    172.30.0.13                         ge-0/0/4.123    172.30.5.2:0         11
    172.30.0.22                         ge-0/0/4.134    172.30.5.4:0         12
    
    ​


    and bindings are received/ sent, we see R8 route in lnet.3 ldp, but not R5/ R6/ R7:

    root@R3# run show ldp database session 172.30.5.8    
    Input label database, 172.30.5.3:0--172.30.5.8:0
    Labels received: 5
      Label     Prefix
     300736      172.30.5.3/32
     300688      172.30.5.5/32
     300704      172.30.5.6/32
     300720      172.30.5.7/32
          0      172.30.5.8/32
    
    Output label database, 172.30.5.3:0--172.30.5.8:0
    Labels advertised: 5
      Label     Prefix
     301456      172.30.5.1/32
     301472      172.30.5.2/32
          0      172.30.5.3/32
     301488      172.30.5.4/32
     301504      172.30.5.8/32
     301472      192.168.1.0/24​
    
    
    but not seeing 172.30.5.5/ 172.30.5.6/ 172.30.5.7 in inet.3:
    
    root@R3# run show route table inet.3 protocol ldp 
    
    inet.3: 13 destinations, 16 routes (6 active, 0 holddown, 9 hidden)
    + = Active Route, - = Last Active, * = Both
    
    172.30.5.1/32      *[LDP/9] 00:09:23, metric 15
                        >  to 172.30.0.13 via ge-0/0/4.123, Push 300480
    172.30.5.2/32      *[LDP/9] 00:09:23, metric 10
                        >  to 172.30.0.13 via ge-0/0/4.123, Push 0
    172.30.5.4/32      *[LDP/9] 00:09:23, metric 10
                        >  to 172.30.0.22 via ge-0/0/4.134, Push 0
    172.30.5.8/32       [LDP/9] 00:09:23, metric 16777229
                        >  to 172.30.0.22 via ge-0/0/4.134, label-switched-path L_R3-R8
    192.168.1.0/24     *[LDP/9] 00:09:23, metric 20
                        >  to 172.30.0.13 via ge-0/0/4.123, Push 0
    
    
    (hidden routes are not related to this scenario)
    
    root@R3# run show route table inet.3 protocol ldp hidden 
    
    inet.3: 13 destinations, 16 routes (6 active, 0 holddown, 9 hidden)
    
    [edit]
    root@R3# 


    Same applies for the reverse scenario, checking R8:
    root@R8# run show route 172.30.5/24 active-path 
    
    inet.0: 835 destinations, 1226 routes (671 active, 0 holddown, 549 hidden)
    @ = Routing Use Only, # = Forwarding Use Only
    + = Active Route, - = Last Active, * = Both
    
    172.30.5.1/32      @[IS-IS/15] 00:08:47, metric 16777214
                        >  to 172.30.0.9 via ge-0/0/4.118
    172.30.5.2/32      *[IS-IS/15] 00:08:47, metric 16777219
                        >  to 172.30.0.9 via ge-0/0/4.118
    172.30.5.3/32      @[IS-IS/15] 00:08:47, metric 16777229
                        >  to 172.30.0.9 via ge-0/0/4.118
                           to 172.30.0.37 via ge-0/0/4.158
    172.30.5.4/32      *[IS-IS/15] 00:08:47, metric 16777224
                        >  to 172.30.0.9 via ge-0/0/4.118
                           to 172.30.0.37 via ge-0/0/4.158
    172.30.5.5/32      @[IS-IS/15] 00:08:47, metric 10
                        >  to 172.30.0.37 via ge-0/0/4.158
    172.30.5.6/32      @[IS-IS/15] 00:08:47, metric 15
                        >  to 172.30.0.37 via ge-0/0/4.158
    172.30.5.7/32      @[IS-IS/15] 00:08:47, metric 10
                        >  to 172.30.0.45 via ge-0/0/4.178
    172.30.5.8/32      *[Direct/0] 00:36:27
                        >  via lo0.0
    172.30.5.41/32     *[IS-IS/15] 00:08:47, metric 33554428
                        >  to 172.30.0.9 via ge-0/0/4.118
    
    
    root@R8# run show ldp interface    
    Interface          Address                          Label space ID   Nbr   Next
                                                                        count  hello
    lo0.0              172.30.5.8                       172.30.5.8:0      1      0
    ge-0/0/4.158       172.30.0.38                      172.30.5.8:0      1      1
    ge-0/0/4.178       172.30.0.46                      172.30.5.8:0      1      2
    
    [edit]
    root@R8# run show ldp neighbor     
    Address                             Interface       Label space ID     Hold time
    172.30.5.3                          lo0.0           172.30.5.3:0         35
    172.30.0.37                         ge-0/0/4.158    172.30.5.5:0         11
    172.30.0.45                         ge-0/0/4.178    172.30.5.7:0         12
    
    [edit]
    root@R8# run show ldp database session 172.30.5.3 
    Input label database, 172.30.5.8:0--172.30.5.3:0
    Labels received: 5
      Label     Prefix
     301456      172.30.5.1/32
     301472      172.30.5.2/32
          0      172.30.5.3/32
     301488      172.30.5.4/32
     301504      172.30.5.8/32
     301472      192.168.1.0/24
    
    Output label database, 172.30.5.8:0--172.30.5.3:0
    Labels advertised: 5
      Label     Prefix
     300736      172.30.5.3/32
     300688      172.30.5.5/32
     300704      172.30.5.6/32
     300720      172.30.5.7/32
          0      172.30.5.8/32
    
    
    root@R8# run show route table inet.3 protocol ldp 
    
    inet.3: 18 destinations, 21 routes (5 active, 0 holddown, 15 hidden)
    + = Active Route, - = Last Active, * = Both
    
    172.30.5.3/32       [LDP/9] 00:14:58, metric 16777229
                        >  to 172.30.0.37 via ge-0/0/4.158, label-switched-path K_R8-R3
    172.30.5.5/32      *[LDP/9] 00:14:59, metric 10
                        >  to 172.30.0.37 via ge-0/0/4.158, Push 0
    172.30.5.6/32      *[LDP/9] 00:14:59, metric 15
                        >  to 172.30.0.37 via ge-0/0/4.158, Push 300592
    172.30.5.7/32      *[LDP/9] 00:14:59, metric 10
                        >  to 172.30.0.45 via ge-0/0/4.178, Push 0
    
    (hidden routes are not related to this scenario)
    root@R8# run show route table inet.3 protocol ldp hidden 
    
    inet.3: 18 destinations, 21 routes (5 active, 0 holddown, 15 hidden)
    
    [edit]
    root@R8# 


    so it looks like all the bindings and the routes necessary is there! still not sure why ldp routes wont show up on R3/R8 for the remote island (only 1 out of 4 shows up). I assume once R3/R8 install the ldp routes they will also start advertising it out to the neighbors in local island. for example, R3 is not advertising remote island to R4 (local island) at the moment:

    root@R3# run show ldp database session 172.30.5.4           
    Input label database, 172.30.5.3:0--172.30.5.4:0
    Labels received: 4
      Label     Prefix
     300816      172.30.5.1/32
     300832      172.30.5.2/32
     300848      172.30.5.3/32
          0      172.30.5.4/32
     300816      192.168.1.0/24
    
    Output label database, 172.30.5.3:0--172.30.5.4:0
    Labels advertised: 5
      Label     Prefix
     301456      172.30.5.1/32
     301472      172.30.5.2/32
          0      172.30.5.3/32
     301488      172.30.5.4/32
     301504      172.30.5.8/32
     301472      192.168.1.0/24


    so I checked R4, inet.0 routes are availableR4 is receiving bindings for 172.30.5.8, however no ldp route in inet.3

    root@R4# run show ldp database session 172.30.5.3 
    Input label database, 172.30.5.4:0--172.30.5.3:0
    Labels received: 5
      Label     Prefix
     301456      172.30.5.1/32
     301472      172.30.5.2/32
          0      172.30.5.3/32
     301488      172.30.5.4/32
     301504      172.30.5.8/32
     301472      192.168.1.0/24
    
    Output label database, 172.30.5.4:0--172.30.5.3:0
    Labels advertised: 4
      Label     Prefix
     300816      172.30.5.1/32
     300832      172.30.5.2/32
     300848      172.30.5.3/32
          0      172.30.5.4/32
     300816      192.168.1.0/24
    
    
    [edit]
    root@R4# run show route protocol ldp table inet.3 
    
    inet.3: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    172.30.5.1/32      *[LDP/9] 00:31:03, metric 10
                        >  to 172.30.0.5 via ge-0/0/4.114, Push 0
    172.30.5.2/32      *[LDP/9] 00:31:03, metric 15
                        >  to 172.30.0.5 via ge-0/0/4.114, Push 300624
    172.30.5.3/32      *[LDP/9] 00:35:17, metric 10
                        >  to 172.30.0.21 via ge-0/0/4.134, Push 0
    192.168.1.0/24     *[LDP/9] 00:31:03, metric 20
                        >  to 172.30.0.5 via ge-0/0/4.114, Push 0

    Technically speaking ldp egress-policy dictates the bindings in the ldp database, I tried configuring a specific egress policy on R3 to "force" advertisement of any ldp /32 route part of /24 but this was a bad choice! with this egress policy R3  started advertising remote island to local island neighbors but all with label0 (explicit null) which is wrong. not sure whats causing this still.....

    the only way to achieve this for me is to enable ldp-tunneling to far end island on every router! Apologies for the long response


  • 6.  RE: ldp-tunneling over rsvp

    Posted 15 days ago
    Previously I was using junos 20.1, I also tested this on 19.4 and got the same results.
    Any suggestion is highly appreciated!!