[PATCH 2/4] Static protocol supports SADR

[Ondrej Zajicek]

On Tue, May 23, 2017 at 08:03:38PM +0200, Dean wrote:
> >>And routes from other protocols with normal IPv6 channels should be
> >>transformed to SADR routes with a ::/0 source?
> >That is a tricky issue. I see four possibilities:
> >
> >2) Soma hack to Pipe protocol that allows to bridge IP6 table and
> >SADR_IP6 table. I.e., SADR-aware protocols connected to SADR_IP6
> >table and other protocol to regular IP6 table, both tables connected
> >by pipe that translates IP6 routes to SADR routes with a ::/0 source
> >and vice versa (ignoring SADR routes with other source).

> In #2 which table would bird table would be used as the main kernel table?

Usually the SADR table. Otherwise, no SADR route could be pushed to main
kernel table.

Something like:

ipv6 table tab1;
ipv6 sadr table tab2:

protocol ospf v3 {
    ipv6 sadr {
        table tab2;
    }
}

protocol rip {
    ipv6 {
        table tab1;
    }
}

protocol kernel {
    ipv6 sadr {
        table tab2;
        export all;
    }
}

protocol pipe {
    table tab1;
    peer table tab2;
    export all;
    import all;
}

For clarity, the example uses explicit tables in channel definitions.


> What I'm worried about is that in a network that has both SADR and non-SADR
> routers, there can be routing loops if not explicitly avoided (my last patch
> tries to do this in OSPF). Keeping both SADR and non-SADR tables might cause
> a problem with this, the router might advertise to OSPF that it has SADR
> capability, but it would cause routing loops anyway when using the non-SADR
> routing table.

Well, it is potentially problematic issue, but IMHO it is more an
operational issue to have reasonable configuration and network design.
The alternatives #1-#4 are more or less equivalent w.r.t. that.


Also, we discussed that internally and agreed that #2 is a way to go. It
avoids pitfalls of #1 and allows additional configuration. As sometimes
it makes sense that non-SADR routes are translated to SADR routes with
configurable src/from other than ::/0. E.g.:

I have a gateway router with internal OSPF SADR network and two uplinks
from two ISPs that propagate a default route by RIP. Each uplink is valid
for associated prefix range assigned by that ISP, but RIP itself does not
know about that. So configuration would be like main SADR table connected
to OSPF and Kernel, and two non-SADR tables connected to appropriate RIPs,
and pipes between non-SADR tables and the SADR table, the pipes would be
configured to assign appropriate src/from to the routes propagated from
non-SADR to SADR table based on ISP range.

Now i have a pretty clear idea how to implement the pipe hack anyway, so
perhaps the best way to continue would be that you just ignore the issue
and implement just interaction between SADR-aware protocols, while i will
add the pipe hack later.

-- 
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."