North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: SYN flood messages flooding my mailbox
In message <[email protected]>, Vadim Antonov writes: > Curtis Villamizar <[email protected]> wrote: > > >> 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 - - - - - - - - - - - - - - - - -
|