On 22 May 2017 11:28, "Toke Høiland-Jørgensen" wrote:
Dean writes:
> Hello,
>
> This is another try at extending the static and OSPFv3 protocols to
> support Source Address Dependent Routing (SADR), also called Source
> Specific Routing. This basically means that routing will take into
> accoun
From: dean
In networks with both routers that support SADR and routers that
don't, there is the possibility of routing loops.
draft-ietf-rtgwg-dst-src-routing-04 describes some ways to avoid
these loops. One of these ways is to detect that the path for an
SADR route passes through a non-SADR rout
From: dean
A new OSPF variant can be used to support SADR.
protocol ospf v3_sadr {
...
}
The channel type should be the same as for the static protocol,
sadr_ip6.
Static routes are distributed in OSPF using external LSAs. A new
LSA type was created (LSA_T_EXT_SADR 0x4025) to distribute
From: dean
A new channel, sadr_ip6, is used for SADR both in the kernel
and static protocols. In the static protocol, routes can be
inserted with the following syntax:
route from via "interface"
route from recursive
There is a bug in the Linux kernel that causes undefined behavior
when bot
From: dean
This patch adds a new network of type NET_SADR_IP6, including new
structures, constants, and switch cases for the new network type.
Some existing functions are duplicates to handle the new network
type, and netlink can now handle SADR routes.
The net_route_sadr_ip6 function is a bit o
I see, I'll look into it.
On 7 Mar 2017 11:49, "Ondrej Zajicek" wrote:
> On Tue, Mar 07, 2017 at 12:56:25AM +0100, Dean Luga wrote:
> > From: dean
> >
> > It compiles with the macro SADR_OSPF defined.
> > ---
> > configure | 13 -
&
LSAs to support SADR,
but the extended LSAs are also still drafts, and I am not sure they would
cooperate with the current ospf standard.
So yes, the design details are mine, but they are based on the OSPF
behavior specified in these documents.
On 7 Mar 2017 11:41, "Toke Høiland-Jørgensen&quo
I used the configure switch since SADR makes changes to the LSAs and it
will slightly impact network traffic even with source 0::/0. If someone
doesn't want that, they can disable it.
About the name, you are right, it should be changed.
On 7 Mar 2017 10:32, "Toke Høiland-Jørgensen"
From: dean
This last patch updates the function in OSPF that handles routing
table update notifications to use source information. Similar changes
are applied to the function that synchronizes OSPF routing tables with
nest's routing tables.
Finally, some work of area border routers (like decidin
From: dean
As with the previous LSAs, there won't be just simple destination
prefixes in the LSA, but pairs of (destination, source) prefixes
instead. The parsing and validation functions of external LSAs will
handle these changes.
The installation of the external routes in the OSPF routing tabl
From: dean
The add_network and ri_install_net functions that install networks
in the OSPF routing tables when processing intra-area and inter-area
routes were changed to use addr_data objects and support SADR entries.
The respective calls to these functions also use addr_data objects.
---
proto/
From: dean
Again with the same concept as for prefix LSAs, summary LSAs will
include pairs of (destination, source) prefixes instead of just
destination prefixes when SADR is enabled.
To match this change, the functions that handle the summary LSA
parsing and validation were also changed. Parsin
From: dean
Instead of prefix LSAs containing destination prefixes, they now
contain pairs of (destination, source) prefixes. Meaning there will
always be an even number of prefixes in the LSAs if SADR is enabled.
Functions that process the prefix LSAs now also take into account
that there are pa
From: dean
If SADR is enabled, to specify a source constraint for a route,
the RTA_SRC attribute, which contains the source address, is added
to the netlink message, and the source prefix length is set.
If SADR is enabled, the source attribute is also handled when
parsing routes in nl_parse_rout
From: dean
Two grammar rules were added that allow addition of source dependent
routes in the configuration of the static protocol.
route from via
route from via ""
Added a function that returns an addr_data object initialized from
a static_route object.
static_install and static_remove f
From: dean
When SADR is enabled, fib_node contains source address prefix
and prefix length.
A data structure addr_data was added to be passed to
fib_{get|find|route} and net_{get|find} functions and allow
the same call syntax for the functions, independently of
whether SADR is enabled. Two funct
From: dean
It compiles with the macro SADR_OSPF defined.
---
configure | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 09c6acf..ad92c7f 100755
--- a/configure
+++ b/configure
@@ -704,6 +704,7 @@ enable_debug
enable_memcheck
enable_c
>
> Hmm, I have been running babeld with source-specific routes for quite
> some time and never run into this problem. Are you sure you didn't botch
> the netlink calls? ;)
I don't think so, I even tested inserting the routes with ip route without
running bird. It was a documented behavior in net
18 matches
Mail list logo
