Curtis Villamizar <curtis@ans.net> wrote:

I guess a picture would help:

AS X R1 ------ AS Y R3 | | | | AS X R2 ------ AS Y R4

If the route learned at AS Y R4 is preferred, AS Y R3 may get packets although the forwarding entry (Fib) points toward AS Y R4, the LocRib does not contain the entry (no preferred), only the AdjRibIn contains the entry. If the filter must be set according to AdjRibIn,

That's what i meant.

you now have a filter list **in the forwarding path** considerably longer than the current routing table. Won't scale at the very least.

Not. Every entry in the filter contains the following data: [Prefix] [Prefix Length] [Bitmask] where bitmask has a bit per every interfaces, so the bit if set if packet matching the prefix is allowed from that interface. Since in practically all cases all prefixes (NOT routes!) found in all RIBs are also found in FIB (exceptions are proxy aggregation and/or restricted end-to-end reacheability) the size of the list is the same as size of FIB. In fact, you don't even need to keep a separate table. Just add a bitmask field to the FIB entries. (On customer-access routers with many interfaces each allowing only very small portion of routes in it may be more economical to implement explicit per-interface lists than to add fields to FIB).

...

Or if the "known route" goes through an AS that uses YOU as their best route but the reverse traffic goes a different way..

So what? The assumption is that multi-homed AS announces all its routes to all exits (maybe with different "metrics").

In this case:

AS a R1 ------ AS b R2 ------ AS d R4 | | | | | | +----------- AS c R3 -----------+

In this case AS c prefers AS a. AS d prefers AS c. AS b prefers the routes it hears from AS b. AS a prefers some route through AS d that it hears from AS b over the route it hears from AS c. Therefore AS d has no Fib, LocRib, or even AdjRibIn from AS b R2, but will get legitimate traffic from R2 that is dstined for places that is reachable through AS d but for which AS d uses AS c for the return path.

ASes a and d are transit. I clearly stated that the reverse-route filtering technique is inapplicable for transit AS-es. Fortunately, the number of transit ASes is very small (two years ago i measured it as 170-something), and they generally form a backbone. On the other hand, practically all customer AS-es or intra-AS tail links are not transit.

The first case is clearly less scalable than the current routing table (consider putting all AdjRibIn entries at a NAP into your filters on the forwarding card).

Er. That statement is just plain wrong.

The second just plain doesn't work.

It is exactly within the restriction i stated beforehand. You don't want to do packet filtering on backbone in any case. --vadim