On 1/9/14, 7:09 AM, John R Levine wrote:
I was at a meeting talking to ops people from some large ISPs, who tell
me that when they tell their large customers about BCP 38, the customers
say forget it, because they're multihomed. I gather the situation is
typically that the customer has multiple address ranges, say from
providers A and B. Normally traffic from range A goes out through
provider A, and vice-versa, except sometimes when it doesn't. Sometimes
it's failover, or it may be deliberate asymmetic routing. The customers
may not be running BGP, or if they do, they don't want to announce range
A to provider B for business reasons I don't entirely understand but
that are not going away.
The ISPs tell me that the customers are often ISPs themselves, so there
are lots of address ranges, far more than anyone could track manually
even if they wanted to.
I see BCP 84, which is now ten years old. The ISPs are aware of it, but
it doesn't seem to have done the trick. I can think of some hacks to
pseudo-announce ranges for filtering purposes, but surely I am not the
only person to have noticed this problem. What have people done to
address this issue?* I figure the first thing to do is to understand
what's failed before.
Peers the do URPF strict, and also having regionally distinct prefix
range advertisements (e.g. we peer in multiple regions) for peers are a
problem e.g. due to internal issues traffic that was flowing through a
port where the prefix was announced is now flowing towards me through a
port which it is not, likewise in the other direction, in a case where
the out of region prefix would due to local pref be reached via a
transit provider, if the transit route goes away may well blackhole at
the other peer if it instead crosses your backbone to another exit. We
use loose to prevent this in the inboud direction with those peers we
also announce covering agregates to particular URPF strict peer.
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
* - other than calling the customers stupid, which they are not, and is
not helpful
signature.asc
Description: OpenPGP digital signature