Routing

 View Only
last person joined: 2 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.  LDP Tunneling over RSVP. TTL value for LDP discovery Multicast packets

    Posted 11-18-2017 16:22

    Dear collegues,

     

    We know that LDP uses UDP 646 to find directly connected LDP neighbours and then establishes LDP seassion over TCP 646.

    During LDP neighbour discovery TTL=1 value is used to make sure we do not jump hops, aftewards TCP seassion uses TTL>1.

     

    My question is, when we use LDP tunneling over RSVP LSP  (not targeted LDP) how TTL value changes to allow us to reach remote LDP neighbour and discover it. Refering to Juniper : " LDP automatically establishes sessions with the router at the other end of the LSP. LDP control packets are routed hop-by-hop, rather than carried through the LSP" on this link

     

    https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-ldp-lsp-in-rsvp-lsp-overview.html

    But it does not make sense since TTL=1 Neihbour discovery message should be dropped on its way to egress Node. 

    According to Junos implementation by default TTL value of the IP packet header is copied to MPLS shim header which means we copy TTL of IP to MPLS header. In this case when we sent IP Multicast packets from interface to discover our LDP neighbours , RSVP will add the MPLS label with TTL=1 (copied from IP header)  and forward it to LSP (which can have multiple nodes in between). First P router should drop the packet and send TTL expired back to sender if it knows the source IP (most probably) or send it to egress node if it does not ( very rare)

    Your help is appriciates!

    Thanks,

     

     

     



  • 2.  RE: LDP Tunneling over RSVP. TTL value for LDP discovery Multicast packets
    Best Answer

    Posted 11-18-2017 23:19

    with ldp tunneling enabled , we do not require discovery , junos just try establish tcp session from lo0.0 to address mentioned in "to" configuration of mpls lsp.

    P.S. and this tcp packet has ttl 64.

     

    You can see this with monitor traffic interface ... command