On Sun, May 21, 2017 at 11:01:35PM +0200, Dean Luga wrote:
> struct static_route {
> diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c
> index d89ae10..073bf65 100644
> --- a/sysdep/linux/netlink.c
> +++ b/sysdep/linux/netlink.c
> @@ -1937,7 +1937,8 @@ krt_sys_start(struct krt_proto *p)
> {
> struct krt_proto *old = HASH_FIND(nl_table_map, RTH, p->af,
> krt_table_id(p));
>
> - if (old)
> + // checking net_type as well so that ipv6 and sadr_ip6 are put in the same
> table
> + if (old && old->p.net_type == p->p.net_type)
This is not completely correct. If you do HASH_INSERT for both IP6 and
SADR_IP6, you end up with two hash entries with the same hash key, but
subsequent HASH_FIND finds (here or in nl_parse_route()) just the first
table.
I am not really sure what is the best way to fix this. Sure, one can
change hash key to involve net_type instead of af. But IMHO this is
deeper issue related to the question asked by Toke before:
> It looks like a separate channel is needed for SADR routes; (right?) but
> can SADR and non-SADR ipv6 routes co-exist in the same FIB?
I just glimpsed at the OSPF changes and if i undertand it correctly, only
external routes are SADR, while regular internal routes are non-SADR?
But they are both connected by one SADR_IP6 channel to one SADR_IP6 routing
table? Non-SADR internal routes are represented as SADR routes with source
set to ::/0?
Alternative way would be to have OSPFv3 dual-channel - one IP6 for
regular routes and one SADR_IP6 for SADR routes, connected to two
separate tables. But that is probably an overkill.
My opinion is that behavior of OSPF and Kernel protocols should be
consistent. If OSPFv3 uses one channel and one table for SADR and
non-SADR routes, then Kernel should do the same and there is no
reason to connect two Kernel protocols to one kernel table.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@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."
