On Wed, Aug 17, 2011 at 08:57:20PM +0100, Alex Bligh wrote: > > > --On 17 August 2011 21:54:57 +0200 Ondrej Zajicek > <[email protected]> wrote: > >> On Wed, Aug 17, 2011 at 07:59:39PM +0100, Alex Bligh wrote: >>> Is it possible either to control what routes the kernel protocol >>> learns from the kernel using "learn" by what /kernel/ protocol >>> they are (meaning the "protocol xxxx" field to the "ip route add" >>> command on linux), >> >> This is not possible - although the value of (kernel) protocol field is >> learned, it is not accessible to filters. It will be trivial to add this >> feature. But i wonder if there are any sensible use cases. Perhaps an >> import of routes from other routing daemons through kernel table? > > Perhaps an explanation of the use case would be useful. > > I have a separate program (not a routing daemon, but I suppose > similar) which is busy creating, numbering and deleting interfaces > and adding routes to them. I need to learn both device routes > (where the interface is numbered) and static routes pointing out > the device (where the interface is not). These get distributed > by bird into a routing protocol and sent elsewhere. My concern > is to ensure I am not picking up (and thus distributing) any > bogus routes other than those created & destroyed by the other > program. > > Using the device protocol, I can mask out all the interfaces > bar these autogenerated ones because I give them a name with a > constant prefix.
Perhaps the direct protocol (to filter generated device routes)? Device protocol should almost always be active for all ifaces - it controls which interfaces BIRD sees for all purposes (e.g. if you filter out eth0 in 'device' protocol, you cannot even run OSPF on that iface) > However, that's not posssible with routes; > the only way to tag them (short of using a different kernel > table, which is a overkill and also conflicts with some other > stuff) is by routing protocol number (in the linux kernel sense). You can also abuse realm field (krt_realm attribute) for that purpose. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
