Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Quagga: Dev

[PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX

 

 

Quagga dev RSS feed   Index | Next | Previous | View Threaded


Joakim.Tjernlund at transmode

Jul 7, 2012, 8:06 AM

Post #1 of 15 (643 views)
Permalink
[PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX

OSPF really needs to specify interface in its routes. Otherwise
ospf may change the wrong route.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund [at] transmode>
---
ospfd/ospf_zebra.c | 130 +++++++++++++++++++++++++++++++++-------------------
zebra/zserv.c | 9 ++++
2 files changed, 91 insertions(+), 48 deletions(-)

diff --git a/ospfd/ospf_zebra.c b/ospfd/ospf_zebra.c
index f8d1cb7..6fde7d6 100644
--- a/ospfd/ospf_zebra.c
+++ b/ospfd/ospf_zebra.c
@@ -371,7 +371,14 @@ ospf_zebra_add (struct prefix_ipv4 *p, struct ospf_route *or)
/* Nexthop, ifindex, distance and metric information. */
for (ALL_LIST_ELEMENTS_RO (or->paths, node, path))
{
- if (path->nexthop.s_addr != INADDR_ANY)
+ if (path->nexthop.s_addr != INADDR_ANY &&
+ path->ifindex != 0)
+ {
+ stream_putc (s, ZEBRA_NEXTHOP_IPV4_IFINDEX);
+ stream_put_in_addr (s, &path->nexthop);
+ stream_putl (s, path->ifindex);
+ }
+ else if (path->nexthop.s_addr != INADDR_ANY)
{
stream_putc (s, ZEBRA_NEXTHOP_IPV4);
stream_put_in_addr (s, &path->nexthop);
@@ -418,60 +425,87 @@ ospf_zebra_add (struct prefix_ipv4 *p, struct ospf_route *or)
void
ospf_zebra_delete (struct prefix_ipv4 *p, struct ospf_route *or)
{
- struct zapi_ipv4 api;
+ u_char message;
+ u_char distance;
+ u_char flags;
+ int psize;
+ struct stream *s;
struct ospf_path *path;
- struct in_addr *nexthop;
- struct listnode *node, *nnode;
+ struct listnode *node;

if (zclient->redist[ZEBRA_ROUTE_OSPF])
{
- api.type = ZEBRA_ROUTE_OSPF;
- api.flags = 0;
- api.message = 0;
- api.safi = SAFI_UNICAST;
- api.ifindex_num = 0;
- api.nexthop_num = 0;
+ message = 0;
+ flags = 0;
+ /* Distance value. */
+ distance = ospf_distance_apply (p, or);
+ /* Make packet. */
+ s = zclient->obuf;
+ stream_reset (s);

- for (ALL_LIST_ELEMENTS (or->paths, node, nnode, path))
- {
- if (path->nexthop.s_addr != INADDR_ANY)
- {
- SET_FLAG (api.message, ZAPI_MESSAGE_NEXTHOP);
- api.nexthop_num = 1;
- nexthop = &path->nexthop;
- api.nexthop = &nexthop;
- }
- else if (if_lookup_by_index(path->ifindex))
- {
- SET_FLAG (api.message, ZAPI_MESSAGE_NEXTHOP);
- api.ifindex_num = 1;
- api.ifindex = &path->ifindex;
- }
- else if ( IS_DEBUG_OSPF(zebra,ZEBRA_REDISTRIBUTE) )
- {
- zlog_debug("Zebra: no ifp %s %d",
- inet_ntoa(p->prefix),
- p->prefixlen);
- }
+ /* Put command, type, flags, message. */
+ zclient_create_header (s, ZEBRA_IPV4_ROUTE_DELETE);
+ stream_putc (s, ZEBRA_ROUTE_OSPF);
+ stream_putc (s, flags);
+ stream_putc (s, message);
+ stream_putw (s, SAFI_UNICAST);

- zapi_ipv4_route (ZEBRA_IPV4_ROUTE_DELETE, zclient, p, &api);
+ /* Put prefix information. */
+ psize = PSIZE (p->prefixlen);
+ stream_putc (s, p->prefixlen);
+ stream_write (s, (u_char *) & p->prefix, psize);

- if (IS_DEBUG_OSPF (zebra, ZEBRA_REDISTRIBUTE) && api.nexthop_num)
- {
- char buf[2][INET_ADDRSTRLEN];
- zlog_debug("Zebra: Route delete %s/%d nexthop %s",
- inet_ntop(AF_INET, &p->prefix, buf[0], sizeof(buf[0])),
- p->prefixlen,
- inet_ntop(AF_INET, *api.nexthop,
- buf[1], sizeof(buf[1])));
- }
- if (IS_DEBUG_OSPF (zebra, ZEBRA_REDISTRIBUTE) && api.ifindex_num)
- {
- zlog_debug ("Zebra: Route delete %s/%d ifindex %d",
- inet_ntoa (p->prefix),
- p->prefixlen, *api.ifindex);
- }
- }
+ /* Nexthop count. */
+ stream_putc (s, or->paths->count);
+
+ /* Nexthop, ifindex, distance and metric information. */
+ for (ALL_LIST_ELEMENTS_RO (or->paths, node, path))
+ {
+ if (path->nexthop.s_addr != INADDR_ANY &&
+ path->ifindex != 0)
+ {
+ stream_putc (s, ZEBRA_NEXTHOP_IPV4_IFINDEX);
+ stream_put_in_addr (s, &path->nexthop);
+ stream_putl (s, path->ifindex);
+ }
+ else if (path->nexthop.s_addr != INADDR_ANY)
+ {
+ stream_putc (s, ZEBRA_NEXTHOP_IPV4);
+ stream_put_in_addr (s, &path->nexthop);
+ }
+ else
+ {
+ stream_putc (s, ZEBRA_NEXTHOP_IFINDEX);
+ stream_putl (s, path->ifindex);
+ }
+
+ if (IS_DEBUG_OSPF (zebra, ZEBRA_REDISTRIBUTE))
+ {
+ char buf[2][INET_ADDRSTRLEN];
+ zlog_debug("Zebra: Route add %s/%d nexthop %s",
+ inet_ntop(AF_INET, &p->prefix,
+ buf[0], sizeof(buf[0])),
+ p->prefixlen,
+ inet_ntop(AF_INET, &path->nexthop,
+ buf[1], sizeof(buf[1])));
+ }
+ }
+
+ if (CHECK_FLAG (message, ZAPI_MESSAGE_DISTANCE))
+ stream_putc (s, distance);
+ if (CHECK_FLAG (message, ZAPI_MESSAGE_METRIC))
+ {
+ if (or->path_type == OSPF_PATH_TYPE1_EXTERNAL)
+ stream_putl (s, or->cost + or->u.ext.type2_cost);
+ else if (or->path_type == OSPF_PATH_TYPE2_EXTERNAL)
+ stream_putl (s, or->u.ext.type2_cost);
+ else
+ stream_putl (s, or->cost);
+ }
+
+ stream_putw_at (s, 0, stream_get_endp (s));
+
+ zclient_send_message(zclient);
}
}

diff --git a/zebra/zserv.c b/zebra/zserv.c
index 0915217..9e47f23 100644
--- a/zebra/zserv.c
+++ b/zebra/zserv.c
@@ -775,6 +775,11 @@ zread_ipv4_add (struct zserv *client, u_short length)
nexthop.s_addr = stream_get_ipv4 (s);
nexthop_ipv4_add (rib, &nexthop, NULL);
break;
+ case ZEBRA_NEXTHOP_IPV4_IFINDEX:
+ nexthop.s_addr = stream_get_ipv4 (s);
+ ifindex = stream_getl (s);
+ nexthop_ipv4_ifindex_add (rib, &nexthop, NULL, ifindex);
+ break;
case ZEBRA_NEXTHOP_IPV6:
stream_forward_getp (s, IPV6_MAX_BYTELEN);
break;
@@ -852,6 +857,10 @@ zread_ipv4_delete (struct zserv *client, u_short length)
nexthop.s_addr = stream_get_ipv4 (s);
nexthop_p = &nexthop;
break;
+ case ZEBRA_NEXTHOP_IPV4_IFINDEX:
+ nexthop.s_addr = stream_get_ipv4 (s);
+ ifindex = stream_getl (s);
+ break;
case ZEBRA_NEXTHOP_IPV6:
stream_forward_getp (s, IPV6_MAX_BYTELEN);
break;
--
1.7.3.4

_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


jch at pps

Jul 7, 2012, 10:34 AM

Post #2 of 15 (600 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

> OSPF really needs to specify interface in its routes. Otherwise
> ospf may change the wrong route.

Have you looked at Denis' onlink changes in quagga-RE?

With your change, that would mean that we now have two very subtly
different kinds of routes in Quagga -- ZEBRA_NEXTHOP_IPV4_ONLINK and
ZEBRA_NEXTHOP_IPV4_IFINDEX.

Would anything bad happen if OSPF used ZEBRA_NEXTHOP_IPV4_ONLINK instead
of NEXTHOP_IPV4_IFINDEX?

-- Juliusz
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


joakim.tjernlund at transmode

Jul 7, 2012, 11:11 AM

Post #3 of 15 (595 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

Juliusz Chroboczek <jch [at] pps> wrote on 2012/07/07 19:34:31:
>
> > OSPF really needs to specify interface in its routes. Otherwise
> > ospf may change the wrong route.
>
> Have you looked at Denis' onlink changes in quagga-RE?

Just browsed it once so barely, didn't understand it all.

>
> With your change, that would mean that we now have two very subtly
> different kinds of routes in Quagga -- ZEBRA_NEXTHOP_IPV4_ONLINK and
> ZEBRA_NEXTHOP_IPV4_IFINDEX.

hmm, is there IPV4_ONLINK too? I figured there was only IFINDEX_ONLINK?
IPV4_IFINDEX contains both an interface and a nexthop dst. address.

>
> Would anything bad happen if OSPF used ZEBRA_NEXTHOP_IPV4_ONLINK instead
> of NEXTHOP_IPV4_IFINDEX?

I think so, but when is it needed?
How do you tell the kernel(Linux) to use ONLINK(reference please)?
I get by with the above with real ppp I/Fs(pppoe to be exact).

Jocke

_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


jch at pps

Jul 7, 2012, 11:31 AM

Post #4 of 15 (599 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

>> With your change, that would mean that we now have two very subtly
>> different kinds of routes in Quagga -- ZEBRA_NEXTHOP_IPV4_ONLINK and
>> ZEBRA_NEXTHOP_IPV4_IFINDEX.

> hmm, is there IPV4_ONLINK too? I figured there was only IFINDEX_ONLINK?
> IPV4_IFINDEX contains both an interface and a nexthop dst. address.

Please see my other mail (quagga-dev 9510). ONLINK uses both ifindex
and next hop, just like NEXTHOP_IFINDEX, it just disables some sanity
checks in the kernel.

Taken (with slight modifications) from babeld/kernel.c, function
kernel_route_v4.

api.type = ZEBRA_ROUTE_BABEL;
api.flags = 0;
api.message = 0;
api.safi = SAFI_UNICAST;
SET_FLAG(api.message, ZAPI_MESSAGE_NEXTHOP);
...
SET_FLAG (api.message, ZAPI_MESSAGE_ONLINK);
api.nexthop_num = 1;
api.nexthop = &nexthop_pointer;
api.ifindex_num = 1;
api.ifindex = &tmp_ifindex;
SET_FLAG(api.message, ZAPI_MESSAGE_METRIC);
api.metric = metric;
...
return zapi_ipv4_route (ZEBRA_IPV4_ROUTE_ADD,
zclient, &quagga_prefix, &api);
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


joakim.tjernlund at transmode

Jul 7, 2012, 11:46 AM

Post #5 of 15 (603 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

Juliusz Chroboczek <jch [at] pps> wrote on 2012/07/07 20:31:28:
>
> >> With your change, that would mean that we now have two very subtly
> >> different kinds of routes in Quagga -- ZEBRA_NEXTHOP_IPV4_ONLINK and
> >> ZEBRA_NEXTHOP_IPV4_IFINDEX.
>
> > hmm, is there IPV4_ONLINK too? I figured there was only IFINDEX_ONLINK?
> > IPV4_IFINDEX contains both an interface and a nexthop dst. address.
>
> Please see my other mail (quagga-dev 9510). ONLINK uses both ifindex
> and next hop, just like NEXTHOP_IFINDEX, it just disables some sanity
> checks in the kernel.

I just did, the "my bad" part :)

>
> Taken (with slight modifications) from babeld/kernel.c, function
> kernel_route_v4.

I was looking for the kernel interface, however, the impl.
below isn't any good. ONLINK should just be in flags. I guess it depends
on zapi_ipv4_route API, it is too limited and needs to either go or
be rewritten. Note that my delete ipv4_ifindex function doesn't
use it either nor does the existing ospf_zebra_add()

Jocke

>
> api.type = ZEBRA_ROUTE_BABEL;
> api.flags = 0;
> api.message = 0;
> api.safi = SAFI_UNICAST;
> SET_FLAG(api.message, ZAPI_MESSAGE_NEXTHOP);
> ...
> SET_FLAG (api.message, ZAPI_MESSAGE_ONLINK);
> api.nexthop_num = 1;
> api.nexthop = &nexthop_pointer;
> api.ifindex_num = 1;
> api.ifindex = &tmp_ifindex;
> SET_FLAG(api.message, ZAPI_MESSAGE_METRIC);
> api.metric = metric;
> ...
> return zapi_ipv4_route (ZEBRA_IPV4_ROUTE_ADD,
> zclient, &quagga_prefix, &api);

_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


jch at pps

Jul 7, 2012, 11:56 AM

Post #6 of 15 (602 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

> I was looking for the kernel interface, however, the impl.
> below isn't any good. ONLINK should just be in flags. I guess it depends
> on zapi_ipv4_route API, it is too limited and needs to either go or
> be rewritten.

Forwarded to Denis, since I'm not competent to comment.

-- Juliusz
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


infrastation at yandex

Jul 7, 2012, 1:18 PM

Post #7 of 15 (593 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

>> šTaken (with slight modifications) from babeld/kernel.c, function
>> škernel_route_v4.
>
> I was looking for the kernel interface, however, the impl.
> below isn't any good. ONLINK should just be in flags. I guess it depends
> on zapi_ipv4_route API, it is too limited and needs to either go or
> be rewritten. Note that my delete ipv4_ifindex function doesn't
> use it either nor does the existing ospf_zebra_add()
>
> šJocke

Joakim,

Juliusz is quoting a small portion of a larger, correctly behaving code. I can briefly explain its origins, if you are interested. There are two commits in QRE related to this thread:

b9c1e9a implement IPv4 onlink nexthops
7f450da babeld: manage IPv4 routes using onlink nexthops

The former establishes a feature, including necessary handling at Linux netlink level, and the latter is picking it up to meet Babel protocol specification. Besides the comments already contained in b9c1e9a, it needs to be stressed, that at RIB level NEXTHOP_TYPE_IPV4_IFINDEX_OL is really different from any other nexthop type, including ZEBRA_NEXTHOP_IPV4_IFINDEX. I studied the previous revision of your ifindex patch _very_ thoroughly before going with a completely different nexthop type. The difference is as subtle as it is meaningful. Look at the netlink flag and at nexthop_active_check() to see it.

So far I see NEXTHOP_TYPE_IPV4_IFINDEX_OL and ZEBRA_NEXTHOP_IPV4_IFINDEX as two different tools, each for its specific task. I can consider your ifindex change to ospfd route management for my network, if you declare it complete.

--
Denis Ovsienko
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


joakim.tjernlund at transmode

Jul 7, 2012, 2:20 PM

Post #8 of 15 (592 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

>
>
> >>  Taken (with slight modifications) from babeld/kernel.c, function
> >>  kernel_route_v4.
> >
> > I was looking for the kernel interface, however, the impl.
> > below isn't any good. ONLINK should just be in flags. I guess it depends
> > on zapi_ipv4_route API, it is too limited and needs to either go or
> > be rewritten. Note that my delete ipv4_ifindex function doesn't
> > use it either nor does the existing ospf_zebra_add()
> >
> >  Jocke
>
> Joakim,
>
> Juliusz is quoting a small portion of a larger, correctly behaving code. I can briefly explain its origins, if you are interested. There are two commits in QRE related to this thread:
>
> b9c1e9a implement IPv4 onlink nexthops
> 7f450da babeld: manage IPv4 routes using onlink nexthops
>
> The former establishes a feature, including necessary handling at Linux netlink level, and the latter is picking it up to meet Babel protocol specification. Besides the comments already contained in b9c1e9a, it needs to be stressed, that at RIB level NEXTHOP_TYPE_IPV4_IFINDEX_OL is really
different from any other nexthop type, including ZEBRA_NEXTHOP_IPV4_IFINDEX. I studied the previous revision of your ifindex patch _very_ thoroughly before going with a completely different nexthop type. The difference is as subtle as it is meaningful. Look at the netlink flag and at
nexthop_active_check() to see it.

After looking at the onlink impl.(thanks for the refs), I still think the current impl. is the wrong way even
if you think they are very different(I don't, but I am not up to speed either). My preferred way is to
impl. IPV4_IFINDEX first(it is a bug that it is missing, especially since OSPF requires it per RFC), then
just add ONLINK as a flag which could be used by several route types(if that makes any sense)

>
> So far I see NEXTHOP_TYPE_IPV4_IFINDEX_OL and ZEBRA_NEXTHOP_IPV4_IFINDEX as two different tools, each for its specific task. I can consider your ifindex change to ospfd route management for my network, if you declare it complete.

They are different, but their impl. should be stream lined, onlink is just an attribute you add to
any ground type, let it be IPV4_IFINDEX or just IFINDEX. As far as OSPF is concerned, I think one
could just make all routes onlink and it will just work as before with the extra possibility to use
eth IFs as PtoP IF once all unnumbered stuff is there.

I cannot declare IPV4_IFINDEX complete, it probably needs the same special code you
added for ONLINK too to be fully operational, note that the patch set I sent today is only compile
tested, see the cover letter to patches.

Jocke


_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


equinox at opensourcerouting

Jul 7, 2012, 10:30 PM

Post #9 of 15 (588 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

On Sun, Jul 08, 2012 at 12:18:55AM +0400, Denis Ovsienko wrote:
> >>  Taken (with slight modifications) from babeld/kernel.c, function
> >>  kernel_route_v4.
> >
> > I was looking for the kernel interface, however, the impl.
> > below isn't any good. ONLINK should just be in flags. I guess it depends
> > on zapi_ipv4_route API, it is too limited and needs to either go or
> > be rewritten. Note that my delete ipv4_ifindex function doesn't
> > use it either nor does the existing ospf_zebra_add()
> >
> >  Jocke
>
> Joakim,
>
> Juliusz is quoting a small portion of a larger, correctly behaving
> code. I can briefly explain its origins, if you are interested. There
> are two commits in QRE related to this thread:
>
> b9c1e9a implement IPv4 onlink nexthops
> 7f450da babeld: manage IPv4 routes using onlink nexthops
>
> The former establishes a feature, including necessary handling at
> Linux netlink level, and the latter is picking it up to meet Babel
> protocol specification. Besides the comments already contained in
> b9c1e9a, it needs to be stressed, that at RIB level
> NEXTHOP_TYPE_IPV4_IFINDEX_OL is really different from any other
> nexthop type, including ZEBRA_NEXTHOP_IPV4_IFINDEX. I studied the
> previous revision of your ifindex patch _very_ thoroughly before going
> with a completely different nexthop type. The difference is as subtle
> as it is meaningful. Look at the netlink flag and at
> nexthop_active_check() to see it.
>
> So far I see NEXTHOP_TYPE_IPV4_IFINDEX_OL and
> ZEBRA_NEXTHOP_IPV4_IFINDEX as two different tools, each for its
> specific task. I can consider your ifindex change to ospfd route
> management for my network, if you declare it complete.

Interesting.

How does this differ from adding a connected route for the nexthop and
then adding the route itself?

i.e. replace
10.12.34.0/24 via 1.2.3.4 onlink dev wlan0
with
1.2.3.4 dev wlan0
10.12.34.0/24 via 1.2.3.4 dev wlan0

Also, this isn't supported on any of the BSDs, is it?


-David
Attachments: signature.asc (0.22 KB)


infrastation at yandex

Jul 8, 2012, 2:36 AM

Post #10 of 15 (590 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

>
> Interesting.
>
> How does this differ from adding a connected route for the nexthop and
> then adding the route itself?
>
> i.e. replace
> šššššššš10.12.34.0/24 via 1.2.3.4 onlink dev wlan0
> with
> šššššššš1.2.3.4 dev wlan0
> šššššššš10.12.34.0/24 via 1.2.3.4 dev wlan0

The difference is better visible trying to replace this:

10.12.34.0/24 via 1.2.3.4 onlink dev wlan0
10.12.56.0/24 via 1.2.3.4 onlink dev wlan1

> Also, this isn't supported on any of the BSDs, is it?

I don't know. Linux implements this just fine. Scope of this work is limited to bringing this ability into ZAPI/RIB space.

--
Denis Ovsienko
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


jch at pps

Jul 8, 2012, 4:43 AM

Post #11 of 15 (590 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

> 10.12.34.0/24 via 1.2.3.4 onlink dev wlan0
> 10.12.56.0/24 via 1.2.3.4 onlink dev wlan1

Counterintuitive as this may seem, this is not unrealistic at all --
Babel can play such tricks when trying to minimise radio interference.

-- Juliusz
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


jch at pps

Jul 8, 2012, 4:48 AM

Post #12 of 15 (592 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

> Also, this isn't supported on any of the BSDs, is it?

Not to my knowledge. That's why (upstream) Babel has some limitations
under BSD -- you need to manually set up a prefix for the mesh, and
using multiple mesh interfaces is not supported.

-- Juliusz
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


equinox at opensourcerouting

Jul 13, 2012, 8:14 AM

Post #13 of 15 (550 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

On Sun, Jul 08, 2012 at 01:43:14PM +0200, Juliusz Chroboczek wrote:
> > 10.12.34.0/24 via 1.2.3.4 onlink dev wlan0
> > 10.12.56.0/24 via 1.2.3.4 onlink dev wlan1
>
> Counterintuitive as this may seem, this is not unrealistic at all --
> Babel can play such tricks when trying to minimise radio interference.

What if you do:

1.2.3.4 dev wlan0
1.2.3.4 dev wlan1 metric 2
10.12.34.0/24 via 1.2.3.4 dev wlan0
10.12.56.0/24 via 1.2.3.4 dev wlan1

... that still achieves what you want, doesn't it?
Though I don't think we actually support adding that "metric 2" route
currently, while the first one is in place...

On the other hand, I've just read the corresponding kernel code and
looked into some experiments and I'm pondering whether it might make
sense to have a global switch to set this flag on all IPV4_IFINDEX
routes.
One counterargument I see is that we might install BGP routes with
broken nexthops if it's enabled, since we're now missing the kernel
sanity check there. Hm...


-David
Attachments: signature.asc (0.22 KB)


jch at pps

Jul 13, 2012, 10:36 AM

Post #14 of 15 (543 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

>> > 10.12.34.0/24 via 1.2.3.4 onlink dev wlan0
>> > 10.12.56.0/24 via 1.2.3.4 onlink dev wlan1

>> Counterintuitive as this may seem, this is not unrealistic at all --
>> Babel can play such tricks when trying to minimise radio interference.

> What if you do:
>
> 1.2.3.4 dev wlan0
> 1.2.3.4 dev wlan1 metric 2
> 10.12.34.0/24 via 1.2.3.4 dev wlan0
> 10.12.56.0/24 via 1.2.3.4 dev wlan1

> ... that still achieves what you want, doesn't it?

Hmm... yes, I think so.

But which routing table do you find more intuitive? And which one would
you rather debug?

> One counterargument I see is that we might install BGP routes with
> broken nexthops if it's enabled, since we're now missing the kernel
> sanity check there.

Denis has also rejected my suggestion that ripd use onlink routes by
default, so you might want to check with him what are the issues he's
worrying about. (Note that ripngd uses the IPv6 equivalent of onlink
routes -- routes with a link-local nexthop --, so it's not a protocol
issue.)

-- Juliusz
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev


equinox at opensourcerouting

Jul 13, 2012, 10:43 AM

Post #15 of 15 (544 views)
Permalink
Re: [PATCH 3/4] zebra/ospf: Add support for ZEBRA_NEXTHOP_IPV4_IFINDEX [In reply to]

On Fri, Jul 13, 2012 at 07:36:05PM +0200, Juliusz Chroboczek wrote:
> >> > 10.12.34.0/24 via 1.2.3.4 onlink dev wlan0
> >> > 10.12.56.0/24 via 1.2.3.4 onlink dev wlan1
>
> >> Counterintuitive as this may seem, this is not unrealistic at all --
> >> Babel can play such tricks when trying to minimise radio interference.
>
> > What if you do:
> >
> > 1.2.3.4 dev wlan0
> > 1.2.3.4 dev wlan1 metric 2
> > 10.12.34.0/24 via 1.2.3.4 dev wlan0
> > 10.12.56.0/24 via 1.2.3.4 dev wlan1
>
> > ... that still achieves what you want, doesn't it?
>
> Hmm... yes, I think so.
>
> But which routing table do you find more intuitive? And which one would
> you rather debug?

Well, this variant might actually be supported on the BSDs ;)

I don't really have an opinion on this yet... I'll play with it some
more.

> > One counterargument I see is that we might install BGP routes with
> > broken nexthops if it's enabled, since we're now missing the kernel
> > sanity check there.
>
> Denis has also rejected my suggestion that ripd use onlink routes by
> default, so you might want to check with him what are the issues he's
> worrying about. (Note that ripngd uses the IPv6 equivalent of onlink
> routes -- routes with a link-local nexthop --, so it's not a protocol
> issue.)

Well, IPv6 has the concepts a little different here, with linklocal
addresses defined as they are a non-onlink nexthop wouldn't make
sense...


-David
Attachments: signature.asc (0.22 KB)

Quagga dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.