bird 1.3.2 - kernel / learn / filters

[Ondrej Zajicek]

On Wed, Aug 17, 2011 at 08:57:20PM +0100, Alex Bligh wrote:
>
>
> --On 17 August 2011 21:54:57 +0200 Ondrej Zajicek 
> <santiago at 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 at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20110817/d463d2be/attachment-0001.asc>