Jeremy Hall <jhall@rex.isdn.net> wrote:

You may not have said it, but I remember someone said the route had to be in the routing table. I would agree with you if it looked up the source in the BGP table and if it considered history or dampened paths valid. If your asymetry runs over multiple interfaces, then the best path might not be on the interface the packet is arriving on.

Ok, i assume that was clarified.

I am referring to end-user problems. When a line flaps, especially a backbone line, lots of destinations suddenly become unreachable.

You don't do any filtering on backbone lines. Particularly because they belong to transit routing domains, where the reverse-routing filters cannot work. When a tail circuit flaps you lose connectivity in both directions, so that's also not a problem. Finally, if a multi-homed non-transit AS loses an access circuit there's no problem because all interfaces on remote ends of those circuits allow incoming packets, because their BGPs have reverse routes in their RIBs. (As a side note -- in cases when something is screwed up _not_ allowing packets through is a definite plus. It can prevent nasty routing loops and resulting BGP session flaps due to router overload.) -->The fact that source identification works, and works well enough even -->to do billing is beyond any doubt. RELCOM does that on large scale.

Do they deny packets because you aren't a relcom customer? This is a nice idea on a sunny day, don't get me wrong, but I am wondering how the routers would react when an unusual condition occurs. Are you certain relcom bills its customers for *EVERY* source packet, or can account for them at least?

Yes, they do, and bill differently for interior traffic (which is cheaper) and much more expensive capacity of international circuits. Nobody cares about tracing every packets, just counting them on per-customer basis.

Please explain. If your router does not know how to get back to the source in the split second it got the packet, it might know how to get to the destination and could send the packet on its way.

Communication requires bidirectional connectivity. So routers _must_ have both routes or you can't talk.

Maybe by the time the web server responded, traffic could resume a normal route, or perhaps outbound traffic for the web server is unimpared because you chose to implement asymetry.

Throwing packets aways (and reducing traffic in other ways) during periods of instability is a Good Thing; as most of the nastiness in instabilities is caused by the surges of load on the routers. Having the boxes to process traffic going in strange ways (often resulting in expensive things like sending out ICMPs) does not help for network to stabilize. --vadim