[c-nsp] MPLS TTL exceeded "problems"

Pshem Kowalczyk pshem.k at gmail.com
Fri Jan 8 18:14:18 EST 2010


Hi,

You're right, it's quite common. We hit it on the sup720 (3bxl). The
simple answer is what you're asking for can't be done. According to
some Cisco guys we spoke to the hardware is not capable of doing that
lookup if there is a forwarding adjacency.
We tried various tricks (creating aggregates, pseudo-aggregates (like
0.0.0.0/1 ;-) ) none of that worked - in the best case scenario the
control plane showed the correct information, but the packet wasn't
processed correctly.

kind regards
Pshem

2010/1/9 Peter Rathlev <peter at rathlev.dk>:
> 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list