bird 1.3.2 - kernel / learn / filters
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), or alternatively to filter which of those are exported? -- Alex Bligh
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? It is usually a good idea to either import nothing from kernel, or everything (because these routes wouldn't disappear if we do not import them, just the synchronization will be incomplete). But it is true that such filtering can make sense when the learned routes are later exported to the other routing protocols. OTOH, you can use more kernel routing tables, more kernel protocols (each for one kernel table) and filter learned routes based on that. -- 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."
--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. 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). I don't really need this to be available to a filter, but it would be useful if "learn" could take a parameter which was (say) a list of (linux kernel) routing protocols. I suspect other OS's have similar things. -- Alex Bligh
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."
--On 17 August 2011 22:50:06 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
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)?
Sorry, I meant the direct protocol. I didn't even realise you could export from the device protocol. However, this doesn't pick up situations where the interface itself is unnumbered, with just a static route pointing out of it (for /32 numbering), which is my issue. The static route is inserted by a separate call to "ip route" (by me), and looks like this: ip route add 4.4.4.4/32 proto SOMEPROTO nexthop dev evrr-000001 Even though it has a "dev" next-hop, it isn't a device route in bird terms, and only the kernel (bird) protocol sees it, as far as I can tell. -- Alex Bligh
On Wed, Aug 17, 2011 at 09:39:03PM +0100, Alex Bligh wrote:
--On 17 August 2011 22:50:06 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
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)?
Sorry, I meant the direct protocol. I didn't even realise you could export from the device protocol.
It is not a real route export, just some specific option to filter interfaces. But it is probably better to forget about this option :-)
However, this doesn't pick up situations where the interface itself is unnumbered, with just a static route pointing out of it (for /32 numbering), which is my issue. The static route is inserted by a separate call to "ip route" (by me), and looks like this: ip route add 4.4.4.4/32 proto SOMEPROTO nexthop dev evrr-000001
Even though it has a "dev" next-hop, it isn't a device route in bird terms, and only the kernel (bird) protocol sees it, as far as I can tell.
In my terms it is a device route, but it is not a route related to iface address prefix (so it is not a route generated by 'direct' protocol) prefix. BTW, you can add this as an interface address using something like: ip a a SOME_LOCAL_ADDR peer 4.4.4.4/32 dev evrr-000001 (where SOME_LOCAL_ADDR can be shared for all such ifaces) BTW2, For now, your requirement to filter out routes based on protocol could be easily done by modifying the source, there is already similar hack in BIRD code (see [*]), if you modify it (see attached patch), it will be applied on all routes and blocks import of routes with RTPROT_BOOT. [*] http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg01039.htm... -- 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."
--On 17 August 2011 23:22:57 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
BTW2, For now, your requirement to filter out routes based on protocol could be easily done by modifying the source, there is already similar hack in BIRD code (see [*]), if you modify it (see attached patch), it will be applied on all routes and blocks import of routes with RTPROT_BOOT.
Thanks. Would you take a patch to take an option to 'learn' if I have time some time? -- Alex Bligh
On Wed, Aug 17, 2011 at 11:29:39PM +0100, Alex Bligh wrote:
--On 17 August 2011 23:22:57 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
BTW2, For now, your requirement to filter out routes based on protocol could be easily done by modifying the source, there is already similar hack in BIRD code (see [*]), if you modify it (see attached patch), it will be applied on all routes and blocks import of routes with RTPROT_BOOT.
Thanks. Would you take a patch to take an option to 'learn' if I have time some time?
No, i think better solution would be to make it filterable route attribute. Also it would be nice to have an ability to remove unwanted routes from the kernel routing table. I will probably implement that sometimes. -- 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."
On Wed, Aug 17, 2011 at 09:54:57PM +0200, Ondrej Zajicek 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.
One thought - you can use 'ip route add proto kernel', such route (like other kernel routes) will not be learned even if you have 'learn' and 'import all' in kernel protocol. But it is a hack. -- 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."
Ondrej, --On 17 August 2011 22:08:19 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
One thought - you can use 'ip route add proto kernel', such route (like other kernel routes) will not be learned even if you have 'learn' and 'import all' in kernel protocol. But it is a hack.
Sure. I am more concerned about a random operator putting in a new route without thinking - this is essentially an appliance. We've all (at least once) leaked a pile of routes through unintended redistribution, and I want to make things as idiot-proof as possible. Manually installed routes all go in as "boot" (IIRC), whereas I'm currently installing mine as "static" (though I could choose anything). -- Alex Bligh
participants (2)
-
Alex Bligh -
Ondrej Zajicek