On Tue, Aug 13, 2013 at 01:57:48PM +0300, Sergey Popovich wrote:
Hello!
Another issue I spot last time: assigning value in protocol export filter invalidates route and prevents its from being installed in KRT.
Yes, this is a known issue. Works just for setting gw on the same iface.
--------------------------------------------------------------------------------------- This is probably due to not updating iface, nexthops (multihop config) and other fields of "rta" struct.
Provided patch in attachment tries to address this issue by calling rta_set_recursive_next_hop() in filter/filter.c to properly assign to "gw" attribute. Special cases for bgp and static protocols was taken to use "igp table" configuration parameter if present (tested, and found working with static protocol, probably some with bgp).
The patch does not make sense to me - if user sets 'gw' attribute, BIRD should set immediate nexthop of the route, not setup a route with a recursive nexthop - that would be inconsistent, because reading of 'gw' attribute returns the immediate nexhop and not the recursive nexthop of a route. The attached patch should do that (essentially just lookup iface, fix it and force the route to RTD_ROUTER in case of setting 'gw'). Is this OK for you?
--------------------------------------------------------------------------------------- Brief explanation why "gw" attribute might be wery important (at least in my case).
There is common technique to stop DDoS in large ISP network: blackholing.
However implementations of this might wary from vendor to vendor. In BIRD simplest way to implement this is to set "dest" attribute to something like RTD_BLACKHOLE, and all other route attributes gets deleted (gw, iface, ...). Route installed in KRT as blackhole.
...
In this case we setup some system looped back interface (in Linux this is dummy interface type), configure some network on it (say something 192.0.2.0/24), And instead of setting blackholed route type to RTD_BLACKHOLE we change its "gw" to any address within subnet assigned on looped back interface.
Thats servers same as route with blackhole type, but behaves differently on trace paths: router sends ICMP Time To Live Exceeded messages from its incoming interface address indicating last hop before dropping blackholed traffic. This has no impact on DDoS traffic, except it transmitted to looped back interface instead of being dropped immediately after matching route and wasting few CPU cycles.
Thanks for the thorough explanation. I am surprised that route to a Linux dummy interface works like that, i always thought that dummy interface would behave more like an ethernet with nothing connected on it than like a loopback (therefore you would get ICMP Destination unreachable instead of TTL exceeded), but i didn't tested that. And why not just use RTD_UNREACHABLE or RTD_PROHIBIT? Both would return some ICMP message. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."