[c-nsp] Caution ME3600CX breaks TCP forwarded/local !!!

Adam Vitkovsky adam.vitkovsky at swan.sk
Tue Feb 4 05:14:17 EST 2014

Hi folks,

Just would like to share the below with the community so that you don't need
to go over it on your own. 

Stay away from "no mpls ip propagate-ttl [forwarded|local]" it will break
the switch. 

Unfortunately we are using: no mpls ip propagate-ttl  forwarded. 
Some time ago I created a case to report not working Targeted LDP sessions
between two MEs or ME and A9K if there's (are) another ME(s) in between. 
The packet capture confirmed that the tLDP packets have TTL0 -which works
for directly connected peers but fails for non-directly connected peers. 
The fail occurs on a penultimate MEs doing PHP -where I believe the problem
is that the IP packet with TTL0 is revealed and consequently dropped. 

The workaround I have found is to use explicit-null labels so that the
packet is label-switched all the way to destination where the stripped IP
packet with TTL0 is just processed. 
The Cisco recommended workaround is to enable MPLS IP TTL propagation at the
penultimate MEs - since it will copy whatever the remaining TTL value is
from the MPLS header and use it for IP TTL -this way the IP packet is
successfully forwarded to the destination node where it is processed. 

Bug CSCum23849 has been opened for this issue. -still not resolved. 

For past couple of days I have been involved with an issue where customers
newly migrated to ME access network where complaining about broken or slow
TCP connections. 
It has been identified that the TCP path MTU discovery process is failing
somehow and manually tuning "ip tcp mss" on a CE or lowering MTU on hosts
solves the issue. (Tuning "ip tcp mss" on MEs did not have any effect). 
Since we ran out of ideas to pin point the failure I have decided to enable
MPLS IP TTL propagation on the penultimate ME which fixed the problem. 
How? I don't know. 


More information about the cisco-nsp mailing list