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. adam _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
