nanog mailing list archives
Re: icmp rpf
From: "Patrick W. Gilmore" <patrick () ianai net>
Date: Sun, 24 Sep 2006 21:40:46 -0400
[Can we all have a moment of silence for a useful, interesting, and on-topic post?]
On Sep 24, 2006, at 5:59 PM, Mark Kent wrote:
A smaller North American network provider, with a modest North American backbone, numbers their internal routers on public IP space that they do not announce to the world. One of the largest North American network providers filters/drops ICMP messages so that they only pass those with a source IP address that appears in their routing table. As a result, traceroutes from big.net into small.net have numerous hops that time out. Traceroutes from elsewhere that go into small.net but return on big.net also have numerous hops that time out. We do all still think that traceroute is important, don't we?If so, which of these two nets is unreasonable in their actions/ policies?
Who said either was?First: Your network, your rules. Don't expect others to play by your rules.
But more importantly, there is nothing that says two perfectly reasonable, rational "rules" cannot create a problem when intersecting in interesting ways.
But if forced, I'd say Small.Net gets my vote for needing correction. I see less "wrongness" in a networking running what is essentially loose RPF than a network who expects supposedly bogon- sourced packets to be forwarded. (One could argue that non-announced space is bogus.)
Just remember, I would only say that if pushed. Normally I would say neither is wrong.
Please note that we're not talking about RFC1918 space, or reserved IP space of any kind. Also, think about the scenario where some failurehappens leaving big.net with an incomplete routing table, thus breakingtraceroute when it is perhaps most needed.
In such an instance, I would suggest Big.Net will have far, far larger problems than whether pings get returned from prefixes it can't reach anyway.
-- TTFN, patrick
Current thread:
- Re: icmp rpf, (continued)
- Re: icmp rpf Mark Kent (Sep 24)
- Re: icmp rpf Roland Dobbins (Sep 24)
- Re: icmp rpf virendra rode // (Sep 24)
- Re: icmp rpf Mark Smith (Sep 25)
- Re: icmp rpf Mark Kent (Sep 25)
- Re: icmp rpf Chris Adams (Sep 25)
- Re: icmp rpf william(at)elan.net (Sep 25)
- Re: icmp rpf Tony Rall (Sep 26)
- Re: icmp rpf Jared Mauch (Sep 26)
- Re: icmp rpf Mark Kent (Sep 24)
- Re: icmp rpf Bill Stewart (Sep 27)
- Re: icmp rpf Adrian Chadd (Sep 25)
- New router feature - icmp error source-interface [was: icmp rpf] Patrick W. Gilmore (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Joe Maimon (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Mark Smith (Sep 25)
- RE: New router feature - icmp error source-interface [was: icmp rpf] Berkman, Scott (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Patrick W. Gilmore (Sep 25)
- RE: New router feature - icmp error source-interface [was: icmp rpf] David Temkin (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Richard A Steenbergen (Sep 25)