In message <19970923205326.10979.qmail@pool.pipex.net>, Tony Barber writes:
Curtis Villamizar wrote:
This is not true. If route flap damping is only applied to EBGP routes there are no problems except long secondary paths getting used. Some more specifics will be blocked in a few places and not in others and they will follow whatever route remains. If all of the more specifics are lost an aggregate will be followed and either blackholed at the aggregator or it will get to the dest.
I don't see any opportunity for routing loops. I don't see any issue at all with less specifics being withdrawn and more specifics remaining as described above (I assume you meant the opposite).
Curtis
Maybe it is better to say that inconsistent routing can occur ?
Only if you can substantiate it. Looks to me like alternate paths would be used by some providers. No big deal.
Further, after successful repair of the problem the access-provider ca
n
easily clear the flap-dampening for his customer on his local router instead of needing to contact upstream NOCs all over the Internet to g
et
the dampening cleared.
This would be an argument in favor of very aggressive damping of ones own customer routes which is unlikely to be a good idea.
Why,there should be no reason to do anything different on the customer access point than is done on the inter ISP peerings.
For a direct customer we would disable dampenning completely. If a customer is part of an aggregate that is a purely local issue. If not, we'd expect to keep connectivity to our paying customer and only enable damping if they requested it. If others want to damp, we'd just encourage our customer to number into an aggregate. If they were single homed then statics would be a consideration but we'd prefer the customer was part of an aggregate.
Why is a /24 being announced globally? Our private peerings use a prefix taken from one of the provider's aggregates.
Normally that would be the case. In many multihomed scenarios there is a requirement *not* to aggregate this /24 (or whatever longer prefix) This is why we should be seeing such small aggregates leaked out.
If the /24 flaps, that prefix had better be part of a larger aggregate. The two or more direct providers can agree to exchange the /24 with little or no damping so the backup from the rest of the world is to follow the aggregate. The aggregator would then forward the traffic to the working attachment. When damping restrictions are lifted, the path might just be more optimal. Better yet, the /24 should **always** not be announced outside of some aggregation boundary beyond which there would be no change in the path regardless of which provider attachment was in use. (ie: routing from one continent to a multihome on another continent).
The answer to this problem is to arrange things so the rest of the world doesn't need to know about a /24 that can be taken up and down by the software upgrade of a single router. That's what route flap damping can encourage and it seems to have worked in this case except the message didn't register.
This isn't always possible Curtis :-( Also remember that many of your customers do not want to renumber into your PA, they may have class Bs for instance.
Yep. That's their choice. When their /16 gets damped we can only remind them that it was their choice. We recommend that they dual home their /16 to the same provider (us of course:) so they don't get damped. Since we got rid of the last of our Cisco routers in our backbone very little route flap originates from ANS so that is a very safe thing to do (of course some flap does come from ANS but if you look at the AS paths you can see that the vast majority of it reflects our redistributing flap we heard from transit customers).
3.2 Is dampening of customer route-flaps a good idea ?
As already explained in section 1.3 flap-dampening is at its best valu e and most consistent and helpful if applied as near to the source of the problem as possible. Therefore flap-dampening should not only be applied at peering boundaries but even more at customer boundaries !
This is highly unreasonable. Do you really expect to shut off peer route damping every where and ask [insert irresponsible and clueless ISP name here] to damp at the customer attachment?
Don't damp the customer attachment. Aggregate!
Yes, but it's not always going to achieve anything, see above. I think that Christians assertion is highly reasonable. In an ideal world you would not dampen but aggregate if the downstream is in your PA. If not you would dampen. What is the best mode of attack and the gives consistency ? This will be down to ISP opinion probably. In your last sentence you agree with it :-?
I don't favor providing my customer consistency if that means no one at all can reach them to be consistent with a number of providers on another continnent not willing to put up with their prefix flapping. I have yet to meet a customer that thought this would be a better way to meet their needs. I doubt other providers have.
If the customer's connectivity gets hosed a few times, be very persistent in reminding them that renumbering into an aggregate is an option that will solve that problem. Then the rest of the Internet has less flapping routes to damp.
Curtis
I don't understand this last sentence as it seems to contradict your previous paragraph re Aggregate!, sorry.
If the customer renumbers into a provider aggregate, then the rest of the Internet has one less flapping prefix. The customer prefix disappears into the aggregate and is no longer part of the DFZ. If this is a dual home across providers, then it's also OK for the more specific to get damped as long as the providers can keep the more specific from being damped. If some subset of nearby providers can manage not to announce the more specific beyond some boundary (and do it reliably), then all the better. Curtis