On Wed, Aug 17, 2011 at 08:57:20PM +0100, Alex Bligh wrote:
--On 17 August 2011 21:54:57 +0200 Ondrej Zajicek <santiago@crfreenet.org> 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: 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."