Hi, We have a (probably common) cosmetic problem regarding MPLS LSRs sending ICMP TTL exceeded along the LSP that carries the traffic.
The "problem" is that when the exit PE receives the packet it doesn't do a RIB lookup (to send the traffic back to the correct recipient) but instead it just uses the "adjacency" from the MPLS forwarding table to send it to the next (non MPLS) device. Is there any (easy-ish) way to force the exit PE to do a RIB lookup (e.g. using the allocated aggregate label) and send the packet the right way by itself? If so, would there be any significant performance penalty from this on a Sup720/PFC3B? The reason why it doesn't work now is that the device after the exit PE is a firewall. Specifically FWSM v3.1. It denies the ICMP TTL Exceeded, stating "no matching session" as the reason. When the trace probes have got to the point (TTL wise) where they pass the firewall, all TTL expired replies are accepted and in the end received by the originating client. If there's a way to make a FWSM accept TTL expired like this I'd love to know. (I tried "same-security-traffic permit intra-interface" to defeat the "no xlate" but then the reverse path check fails. I even tested with no reverse path checking, but still couldn't make it pass (=return) the ICMP TTL expired packets.) An example: +--------+ | Host X | +--------+ | | IP +---+ +---+ +---+ +---+ | A |------| B |--------| C |--------| D | +---+ IP +---+ MPLS +---+ MPLS +---+ | | IP +----------+ | Firewall | +----------+ | IP | +---+ IP +---+ MPLS +---+ MPLS +---+ | H |------| G |--------| F |--------| E | +---+ +---+ +---+ +---+ | IP | +--------+ | Host Y | +--------+ A is a "regular" IP router (CPE). B is a PE/LER doing tag imposition C is a P/LSR doing tag switching D is a PE/LER doing tag disposition The firewall is a FWSM v3.1 E is a PE/LER doing tag imposition F is a P/LSR doing tag switching G is a PE/LER doing tag disposition H is a "regular" IP router (CPE) An example traceroute gives: 1 [A] 2 [B] 3 * 4 [D] 5 [E] 6 [F] 7 [G] 8 [H] 9 [Y] Done Since the the path A -> D is often many hops some people tend to get confused and report this as an error. Or even worse: Use this as "proof" of the network being the cause of some badly configured server. :-| -- Peter _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/