Paul wrote:
> Is it possible to have a src inserted into the routes received by
> zebra from bgpd/ripd/etc?
[...]
Seems that what you're asking for is very very Linux specific, isn't it?
Well, in this case I can recommend that
#1, either you patch your sources in some ad-hoc manner, so as to allow
you add a source attribute to netlink messages; I've done that at least
for one case (I had to insert explicit connected routes into the
kernel), it's basically quite an easy fix to
zebra/rt_netlink.c/netlink_route_multipath(). However, if you also need
to code a more flexible framework to define dynamic policy for such
source attributes, then it may take more design and coding (VTY, RIB, etc.)
#2, as for the multiple routing table question -- I've once posted a
preliminary patch that allows associating routes of daemon X with Linux
forwarding table Y; you should look through zebra's archives, because
there's no way I can restore it locally... ;-) But anyway, that was a
heavy-weigth, Linux-specific piece of code, and definitely nothing I
would apply to a package that claims platform independence, standard
compliance, or the like. Note that this approach suffers from some
serious conceptual flaws, and if you are considering multi-context
routing seriously, then I would recommend that you promote VRFs in
zebra/quagga (then again, a long discussed issue, but nothing practical
so far ;-) )
HTH, good luck!
Gilad
> Is it possible to have a src inserted into the routes received by
> zebra from bgpd/ripd/etc?
[...]
Seems that what you're asking for is very very Linux specific, isn't it?
Well, in this case I can recommend that
#1, either you patch your sources in some ad-hoc manner, so as to allow
you add a source attribute to netlink messages; I've done that at least
for one case (I had to insert explicit connected routes into the
kernel), it's basically quite an easy fix to
zebra/rt_netlink.c/netlink_route_multipath(). However, if you also need
to code a more flexible framework to define dynamic policy for such
source attributes, then it may take more design and coding (VTY, RIB, etc.)
#2, as for the multiple routing table question -- I've once posted a
preliminary patch that allows associating routes of daemon X with Linux
forwarding table Y; you should look through zebra's archives, because
there's no way I can restore it locally... ;-) But anyway, that was a
heavy-weigth, Linux-specific piece of code, and definitely nothing I
would apply to a package that claims platform independence, standard
compliance, or the like. Note that this approach suffers from some
serious conceptual flaws, and if you are considering multi-context
routing seriously, then I would recommend that you promote VRFs in
zebra/quagga (then again, a long discussed issue, but nothing practical
so far ;-) )
HTH, good luck!
Gilad