Re: [PATCH 2/4] Static protocol supports SADR
On 05/23/2017 07:29 PM, Ondrej Zajicek wrote:
On Tue, May 23, 2017 at 03:27:43PM +0200, Dean wrote:
On 05/23/2017 03:04 PM, Ondrej Zajicek wrote:
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. So if I understand correctly, you are saying that if the static or OSPF protocols use SADR, the kernel protocol should be required to use SADR? Not exactly, protocol instances are independent and may be connected to unrelated tables or just configured differently.
I am saying that both OSPF and Kernel protocols should be designed and implemented in consistent way w.r.t. mixing SADR and non-SADR in one routing domain.
If OSPF is designed to mix SADR and non-SADR routes in SADR_IP6 channel connected to SADR_IP6 table, so should do Kernel protocol when attached to SADR_IP6 table.
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:
1) Some hack that allows connecting IP6 channels to SADR_IP6 tables, so unmodified protocols could add SADR routes with a ::/0 source.
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).
3) Modify other protocols to support SADR_IP6 (with ::/0 source).
4) Ignore the issue (use only SADR-aware protocols).
I don't like variant #3. I am not sure how acceptable is variant #4, but it may be OK - seems to me that mixing SADR-aware and SADR-unaware routing protocols rarely makes sense and in cases it does (disjunct IP ranges), it can be done by using two real kernel tables. Variant #2 is probably more clean than variant #1 from implementation POW, but probably more confusing from user POW. What is your opinion?
In #2 which table would bird table would be used as the main kernel table? 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.
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@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."
participants (2)
-
Dean -
Ondrej Zajicek