On 05/24/2017 03:53 PM, Ondrej Zajicek wrote:
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
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
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 t
On 05/22/2017 03:30 PM, Ondrej Zajicek wrote:
@@ -231,6 +232,20 @@ fib_find(struct fib *f, const net_addr *a)
case NET_ROA6: return FIB_FIND(f, a, roa6);
case NET_FLOW4: return FIB_FIND(f, a, flow4);
case NET_FLOW6: return FIB_FIND(f, a, flow6);
+ case NET_SADR_IP6:
+{
+ i
On 05/22/2017 01:57 PM, Ondrej Zajicek wrote:
On Sun, May 21, 2017 at 11:01:35PM +0200, Dean Luga wrote:
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
On 05/22/2017 12:36 PM, Dean wrote:
On 05/22/2017 12:07 PM, Toke Høiland-Jørgensen wrote:
Yes, they can. You can use two kernel protocols, one with the SADR
channel and the other with ipv6. Both sets of routes are stored in
the same kernel table.
Ah, yes, but I meant inside Bird in this
On 05/22/2017 12:07 PM, Toke Høiland-Jørgensen wrote:
Yes, they can. You can use two kernel protocols, one with the SADR
channel and the other with ipv6. Both sets of routes are stored in
the same kernel table.
Ah, yes, but I meant inside Bird in this instance. Can the bird 'struct
fib' hold bo
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 th
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
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
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 beh
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
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
account not only the destination address, but the source address as well.
IPv6 sub
On 05/17/2017 03:57 PM, Dean wrote:
Hello,
I am using bird 2.0.0 (from the int-new branch) and I noticed that
OSPF is flooding unknown LSAs. According to RFC 5340, unknown LSAs
shouldn't be flooded if the U-bit isn't set. But the
lsa_flooding_allowed function doesn't che
nknown type. Is that
a mistake or did I miss something?
Regards,
Dean Luga.
Hi,
I'm running some scalability tests for OSPFv3 using Bird in docker
containers. I'm getting some error messages in the logs if I run too
many instances.
2017-04-20 21:59:57 ospf1: Socket error on ln971_if1: Invalid argument
I have 1000 nodes connected linearly (each node connects to two
On 03/07/2017 09:51 PM, Toke Høiland-Jørgensen wrote:
Dean writes:
On 03/07/2017 09:23 PM, Toke Høiland-Jørgensen wrote:
Basically, I want to do the opposite: We are going to have several
(well, at least two) protocols that understand source-specific routing,
so the nest data
On 03/07/2017 09:23 PM, Toke Høiland-Jørgensen wrote:
Basically, I want to do the opposite: We are going to have several
(well, at least two) protocols that understand source-specific routing,
so the nest data structures should work with both. And since Babel at
least is perfectly happy to mix s
On 03/07/2017 01:17 PM, Toke Høiland-Jørgensen wrote:
Dean Luga writes:
That is correct, it will not be compatible with other OSPF implementations.
From what I've searched, there is no standard for supporting SADR in
OSPF, only some IETF drafts (some of which expired) that describ
On 03/07/2017 12:05 PM, Ondrej Zajicek wrote:
On Tue, Mar 07, 2017 at 12:56:26AM +0100, Dean Luga wrote:
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
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
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 ro
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
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
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
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 sta
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
Note: I used BIRD 1.6.2 when working on these patches. I don't know if
they will work on other versions.
The following patches extend the static and OSPFv3 protocol to support
Source Address Dependent Routing (SADR), also called Source Specific
Routing. This basically means that routing will t
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
On 03/06/2017 12:40 PM, Dean wrote:
On 03/06/2017 12:10 PM, Toke Høiland-Jørgensen wrote:
Dean Luga writes:
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
On 03/06/2017 12:10 PM, Toke Høiland-Jørgensen wrote:
Dean Luga writes:
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 ins
n, Mar 6, 2017 at 11:40 AM, Toke Høiland-Jørgensen
wrote:
> Dean writes:
>
> > There is already an implementation for that here
> > (https://github.com/jech/babeld), if you want to check. I think this
> supports
> > both IPV6_SUBTREES and policy routing, not sure.
>
&
worked.
On 03/06/2017 11:27 AM, Toke Høiland-Jørgensen wrote:
Dean writes:
Static routes can be added in the configuration file with a source
address constraint. To match an entry in the routing table, you have to
match both the source and destination address. The same thing as running
the
t the patch: it might be a little long, about 60 commits. And I
started working last year, on BIRD 1.6.2, so some things might be
different. Should I still just send each commit one by one here?
On 03/05/2017 08:57 PM, Ondrej Zajicek wrote:
On Sun, Mar 05, 2017 at 07:39:57PM +0100, Dean wrote:
Hell
Hello,
I have been working on implementing SADR (Source Address Dependent
Routing) in BIRD for the static and OSPFv3 protocols.
What's the procedure for publishing the code? Should I put it on a
repository online and send you a link?
Regards,
Dean
Hello,
I'm modifying some parts of the code, and I've added a new grammar rule
for creating static routes in the config.Y file.
However, I would like this rule to only be enabled based on a
preprocessor definition, with an #ifdef, or throw a syntax error otherwise.
I can't figure out a way
Never mind,
Apparently I just needed to allow OSPF packets in iptables. It's working
now.
On 01/25/2017 11:40 PM, Dean wrote:
Hello,
I'm trying to setup OSPF to run between docker containers, and I have
connected three containers to a bridge using veth interfaces.
However, each
Hello,
I'm trying to setup OSPF to run between docker containers, and I have
connected three containers to a bridge using veth interfaces.
However, each container considers itself to be Designated Router for the
network, and doesn't even acknowledge the others (none is in the
neighbor list). B
42 matches
Mail list logo
