LDP Tunneling over RSVP. TTL value for LDP discovery Multicast packets

[ Edited ]
‎11-18-2017 04:21 PM

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

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!





Networking or Notworking
Accepted by topic author HasanovElshan
‎11-26-2017 09:39 AM

Re: LDP Tunneling over RSVP. TTL value for LDP discovery Multicast packets

‎11-18-2017 11:18 PM

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