>> If you relax criteria for reverse-route filtering to "known route" instead
>> of "best route" then any customer (non-transit) AS can be filtered safely
>> at border routers.>And if the "known route" is know by another router but suppressed from
>IBGP advertisement because there is a better route ..But you still have the exterior route in the RIB. So you know it.
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, you now
have a filter list **in the forwarding path** considerably longer than
the current routing table. Won't scale at the very least.
>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.
Is there any practical example of _properly configured_ multihomed
non-transit AS which advertises more routes at one exit than another?>Both of these cases and other cause a blackhole.
Not at all.
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). The second just plain doesn't work.
Curtis