On Fri, Mar 29, 2013 at 8:31 AM, Tore Anderson <tore@fud.no> wrote:
I've had some problems with my upstream providers' ingress filtering, for example:
- Traffic sourced from a prefix announced as a more-specific route at transit connection in location A got filtered on a transit connection in location B, where only a greater aggregate was announced.
Yep, I've heard of that. This is very bad behavior on your ISP's part. Spank them and if need be, name and shame.
- A GRE tunnel anchored in my routers' addresses in the eBGP link network (part of my provider's address space) stopped working, as my outbound packets was dropped by the provider's ingress filtering.
Yep, I've encountered that. One of my providers decided that the IP on the exterior address of my router should not reach the Internet. Bad behavior. Spank, then name and shame.
- Traceroutes that reaches my network through provider A show one missing hop if my best return path back to the traceroute source is through provider B, and provider B is doing ingress filtering. This is because the ICMP TTL/HL exceeded packet is sourced from provider A's address space (my router's interface address in the eBGP link net).
This is a bug, if you will, in router design. It isn't just traceroute that's missing a hop; if that router needed to send an ICMP destination unreachable in support of path MTU detection for some pair of hosts' TCP, the impacted TCP session would collapse. It gets even worse if you want to configure a particular router link with RFC1918 addresses. I've long thought router vendors should introduce a configuration option to specify the IP address from which ICMP errors are emitted rather than taking the interface address from which the packet causing the error was received. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004