Mailing List Archive: Quagga: Dev

[PATCH] Zebra rib/fib to be in sinc with kernel routing table

Index | Next | Previous | View Threaded

igorm at etf

Oct 20, 2011, 5:36 AM

Post #1 of 13 (564 views)
Permalink

[PATCH] Zebra rib/fib to be in sinc with kernel routing table

From: Igor Maravic <igorm [at] etf>

Enable Zebra rib/fib to be in sinc with kernel routing table. That means
when interface goes down, all routes that are directly connected to it are
deleted from Zebra's rib/fib just like they are delete from kernel
routing table.

Signed-off-by: Igor Maravic <igorm [at] etf>
---
:100644 100644 12f3fa5... 8fcefa4... M zebra/zebra_rib.c
zebra/zebra_rib.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/zebra/zebra_rib.c b/zebra/zebra_rib.c
index 12f3fa5..8fcefa4 100644
--- a/zebra/zebra_rib.c
+++ b/zebra/zebra_rib.c
@@ -758,6 +758,9 @@ rib_match_ipv6 (struct in6_addr *addr)
#define RIB_SYSTEM_ROUTE(R) \
((R)->type == ZEBRA_ROUTE_KERNEL || (R)->type == ZEBRA_ROUTE_CONNECT)

+#define RIB_KERNEL_ROUTE(R) \
+ ((R)->type == ZEBRA_ROUTE_KERNEL)
+
/* This function verifies reachability of one given nexthop, which can be
* numbered or unnumbered, IPv4 or IPv6. The result is unconditionally stored
* in nexthop->flags field. If the 4th parameter, 'set', is non-zero,
@@ -1127,7 +1130,9 @@ rib_process (struct route_node *rn)
buf, rn->p.prefixlen, fib);
redistribute_delete (&rn->p, fib);
if (! RIB_SYSTEM_ROUTE (fib))
- rib_uninstall_kernel (rn, fib);
+ rib_uninstall_kernel (rn, fib);
+ else if(RIB_KERNEL_ROUTE (fib))
+ del=fib;
UNSET_FLAG (fib->flags, ZEBRA_FLAG_SELECTED);

/* Set real nexthop. */
--
1.7.4.1

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

joakim.tjernlund at transmode

Oct 20, 2011, 7:37 AM

Post #2 of 13 (550 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

Just some minor remarks below:
>
> From: Igor Maravic <igorm [at] etf>
>
> Enable Zebra rib/fib to be in sinc with kernel routing table. That means
sinc -> sync

> when interface goes down, all routes that are directly connected to it are
> deleted from Zebra's rib/fib just like they are delete from kernel
> routing table.
>
> Signed-off-by: Igor Maravic <igorm [at] etf>
> ---
> :100644 100644 12f3fa5... 8fcefa4... M zebra/zebra_rib.c
> zebra/zebra_rib.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/zebra/zebra_rib.c b/zebra/zebra_rib.c
> index 12f3fa5..8fcefa4 100644
> --- a/zebra/zebra_rib.c
> +++ b/zebra/zebra_rib.c
> @@ -758,6 +758,9 @@ rib_match_ipv6 (struct in6_addr *addr)
> #define RIB_SYSTEM_ROUTE(R) \
> ((R)->type == ZEBRA_ROUTE_KERNEL || (R)->type == ZEBRA_ROUTE_CONNECT)
>
> +#define RIB_KERNEL_ROUTE(R) \
> + ((R)->type == ZEBRA_ROUTE_KERNEL)
> +
> /* This function verifies reachability of one given nexthop, which can be
> * numbered or unnumbered, IPv4 or IPv6. The result is unconditionally stored
> * in nexthop->flags field. If the 4th parameter, 'set', is non-zero,
> @@ -1127,7 +1130,9 @@ rib_process (struct route_node *rn)
> buf, rn->p.prefixlen, fib);
> redistribute_delete (&rn->p, fib);
> if (! RIB_SYSTEM_ROUTE (fib))
> - rib_uninstall_kernel (rn, fib);
> + rib_uninstall_kernel (rn, fib);

Is the above line really misindented or did you just happen to touch it?

> + else if(RIB_KERNEL_ROUTE (fib))
> + del=fib;
> UNSET_FLAG (fib->flags, ZEBRA_FLAG_SELECTED);
>
> /* Set real nexthop. */
> --
> 1.7.4.1
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev [at] lists
> http://lists.quagga.net/mailman/listinfo/quagga-dev

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

igorm at etf

Oct 20, 2011, 7:40 AM

Post #3 of 13 (551 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

> Just some minor remarks below:
>>
>> From: Igor Maravic <igorm [at] etf>
>>
>> Enable Zebra rib/fib to be in sinc with kernel routing table. That means
> sinc -> sync
>
>> when interface goes down, all routes that are directly connected to it are
>> deleted from Zebra's rib/fib just like they are delete from kernel
>> routing table.
>>
>> Signed-off-by: Igor Maravic <igorm [at] etf>
>> ---
>> :100644 100644 12f3fa5... 8fcefa4... M zebra/zebra_rib.c
>> zebra/zebra_rib.c | 7 ++++++-
>> 1 files changed, 6 insertions(+), 1 deletions(-)
>>
>> diff --git a/zebra/zebra_rib.c b/zebra/zebra_rib.c
>> index 12f3fa5..8fcefa4 100644
>> --- a/zebra/zebra_rib.c
>> +++ b/zebra/zebra_rib.c
>> @@ -758,6 +758,9 @@ rib_match_ipv6 (struct in6_addr *addr)
>> #define RIB_SYSTEM_ROUTE(R) \
>> ((R)->type == ZEBRA_ROUTE_KERNEL || (R)->type == ZEBRA_ROUTE_CONNECT)
>>
>> +#define RIB_KERNEL_ROUTE(R) \
>> + ((R)->type == ZEBRA_ROUTE_KERNEL)
>> +
>> /* This function verifies reachability of one given nexthop, which can be
>> * numbered or unnumbered, IPv4 or IPv6. The result is unconditionally stored
>> * in nexthop->flags field. If the 4th parameter, 'set', is non-zero,
>> @@ -1127,7 +1130,9 @@ rib_process (struct route_node *rn)
>> buf, rn->p.prefixlen, fib);
>> redistribute_delete (&rn->p, fib);
>> if (! RIB_SYSTEM_ROUTE (fib))
>> - rib_uninstall_kernel (rn, fib);
>> + rib_uninstall_kernel (rn, fib);
>
> Is the above line really misindented or did you just happen to touch it?
>
>
>> + else if(RIB_KERNEL_ROUTE (fib))
>> + del=fib;
>> UNSET_FLAG (fib->flags, ZEBRA_FLAG_SELECTED);
>>
>> /* Set real nexthop. */
>> --
>> 1.7.4.1
>>
>> _______________________________________________
>> Quagga-dev mailing list
>> Quagga-dev [at] lists
>> http://lists.quagga.net/mailman/listinfo/quagga-dev
>
>
Really was misindented.
BR
Igor

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

joakim.tjernlund at transmode

Oct 20, 2011, 8:17 AM

Post #4 of 13 (550 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

"Igor Maravi�" <igorm [at] etf> wrote on 2011/10/20 16:40:30:
>
> > Just some minor remarks below:
> >>
> >> From: Igor Maravic <igorm [at] etf>
> >>
> >> Enable Zebra rib/fib to be in sinc with kernel routing table. That means
> > sinc -> sync
> >
> >> when interface goes down, all routes that are directly connected to it are
> >> deleted from Zebra's rib/fib just like they are delete from kernel
> >> routing table.
> >>
> >> Signed-off-by: Igor Maravic <igorm [at] etf>
> >> ---
> >> :100644 100644 12f3fa5... 8fcefa4... M zebra/zebra_rib.c
> >> zebra/zebra_rib.c | 7 ++++++-
> >> 1 files changed, 6 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/zebra/zebra_rib.c b/zebra/zebra_rib.c
> >> index 12f3fa5..8fcefa4 100644
> >> --- a/zebra/zebra_rib.c
> >> +++ b/zebra/zebra_rib.c
> >> @@ -758,6 +758,9 @@ rib_match_ipv6 (struct in6_addr *addr)
> >> #define RIB_SYSTEM_ROUTE(R) \
> >> ((R)->type == ZEBRA_ROUTE_KERNEL || (R)->type == ZEBRA_ROUTE_CONNECT)
> >>
> >> +#define RIB_KERNEL_ROUTE(R) \
> >> + ((R)->type == ZEBRA_ROUTE_KERNEL)
> >> +
> >> /* This function verifies reachability of one given nexthop, which can be
> >> * numbered or unnumbered, IPv4 or IPv6. The result is unconditionally stored
> >> * in nexthop->flags field. If the 4th parameter, 'set', is non-zero,
> >> @@ -1127,7 +1130,9 @@ rib_process (struct route_node *rn)
> >> buf, rn->p.prefixlen, fib);
> >> redistribute_delete (&rn->p, fib);
> >> if (! RIB_SYSTEM_ROUTE (fib))
> >> - rib_uninstall_kernel (rn, fib);
> >> + rib_uninstall_kernel (rn, fib);
> >
> > Is the above line really misindented or did you just happen to touch it?
> >
> >
> >> + else if(RIB_KERNEL_ROUTE (fib))
> >> + del=fib;
> >> UNSET_FLAG (fib->flags, ZEBRA_FLAG_SELECTED);
> >>
> >> /* Set real nexthop. */
> >> --
> >> 1.7.4.1
> >>
> >> _______________________________________________
> >> Quagga-dev mailing list
> >> Quagga-dev [at] lists
> >> http://lists.quagga.net/mailman/listinfo/quagga-dev
> >
> >
> Really was misindented.

OK, lets see what the maintainers say then.

Jocke

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

shemminger at vyatta

Oct 20, 2011, 8:31 AM

Post #5 of 13 (559 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

The concept is good, in fact Vyatta added a patch to do this to Quagga
which I keep meaning to revise and submit. But your patch is not enough
to successfully manage kernel routes. There were another of other
related issues that need to be addressed:
1. When this was brought up in the past, there were users who did
not think this was what they wanted. In our version, the management
of connected routes is optional.

2. In order to delete routes successfully on Linux, more state is needed.
Otherwise when interface bounces you will see duplicate entries in
the FIB. At a minimum this includes scope and metric which have
to be tracked.

3. You have to deal with the case where link detect is enabled.
Normally (at least on Linux), IPv4 routes are maintained when carrier
is lost. If linkdetect is enabled in Quagga, then the RIB has
to actively delete those routes.

Also, there are some issues (on Linux) where IPv6 behaves differently
than IPv4 for this. Not sure what other OS's do.
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev

lsorense at csclub

Oct 20, 2011, 8:34 AM

Post #6 of 13 (549 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

On Thu, Oct 20, 2011 at 08:31:14AM -0700, Stephen Hemminger wrote:
> The concept is good, in fact Vyatta added a patch to do this to Quagga
> which I keep meaning to revise and submit. But your patch is not enough
> to successfully manage kernel routes. There were another of other
> related issues that need to be addressed:
> 1. When this was brought up in the past, there were users who did
> not think this was what they wanted. In our version, the management
> of connected routes is optional.
>
> 2. In order to delete routes successfully on Linux, more state is needed.
> Otherwise when interface bounces you will see duplicate entries in
> the FIB. At a minimum this includes scope and metric which have
> to be tracked.
>
> 3. You have to deal with the case where link detect is enabled.
> Normally (at least on Linux), IPv4 routes are maintained when carrier
> is lost. If linkdetect is enabled in Quagga, then the RIB has
> to actively delete those routes.
>
> Also, there are some issues (on Linux) where IPv6 behaves differently
> than IPv4 for this. Not sure what other OS's do.

Our solution has been that we patched the kernel to have a 'link_detect'
flag on the interfaces and if it is enabled, the kernel removes the
connect route on link down, and adds it back on link up.

I know some kernel developers think it's a userspace problem to solve,
but since the kernel creates the darn routes in the first place I consider
it a kernel problem and solved it there.

We have run it this way for a number of years and it has been great.

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

carlsonj at workingcode

Oct 20, 2011, 9:09 AM

Post #7 of 13 (548 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

Lennart Sorensen wrote:
> Our solution has been that we patched the kernel to have a 'link_detect'
> flag on the interfaces and if it is enabled, the kernel removes the
> connect route on link down, and adds it back on link up.

Depending on what "removes" means, this could be a pretty serious
usability problem.

If "removes" means that it's actually removed from the kernel forwarding
table, and the user-level "route" command cannot access the route when
the interface is down, then I think that'd be a bad thing.

This means that the administrator cannot see what routes are actually on
the box if any interface is down. The output from "netstat -nr" is a
lie, because it omits routes that are really there but that simply
cannot be seen at the moment.

Worse still, it means that the administrator cannot delete a route
that's "stuck" on a downed interface. As far as the "route" command is
concerned, the route doesn't exist and thus can't be deleted. But as
soon as the interface comes back up, it'll rise from the dead like an
extra in a Romero movie.

And it introduces some nasty edge cases into the kernel that have no
good solutions. For example, suppose an interface goes down and takes a
route with it. The user then adds a route that would have been rejected
as a duplicate if that route had been up ("SIOCADDRT: File exists") --
but it's accepted because the other route is currently missing. The
interface comes back up. Now what? Who (if anyone) gets the error
about the conflicting route? Are both installed in the table? Is one
discarded silently?

> I know some kernel developers think it's a userspace problem to solve,
> but since the kernel creates the darn routes in the first place I consider
> it a kernel problem and solved it there.

As someone who has straddled that boundary for a long time, I think
there are really only a few sane ways forward:

1. Routes "temporarily removed" by the kernel are made a first class
object. By this I mean that users can list, add, and delete these
routes as necessary, without regard to the status of the interface.
(One way to accomplish this would be to treat the underlying
interface status as an immutable flag on the route, rather than
removing/adding the route itself on link down/up.)

2. Routes are made independent of link status. If the underlying link
is down, the route becomes an ICMP reject/destun path. If you want
something else, run a routing daemon that can add or delete routes
as necessary.

3. Routes are deleted when a link goes down, but do not come back. If
you have interfaces that can go down, and you have static routes,
and want them to come back, you have to run something in user space
(such as a routing daemon) that can do this.

Solaris did the "cache the routes for down interfaces in hidden memory"
trick for many years, and it was horrible for routing daemons to work
with. I don't think it ever really worked quite right.

--
James Carlson 42.703N 71.076W <carlsonj [at] workingcode>
_______________________________________________
Quagga-dev mailing list
Quagga-dev [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-dev

lsorense at csclub

Oct 20, 2011, 9:34 AM

Post #8 of 13 (549 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

On Thu, Oct 20, 2011 at 12:09:08PM -0400, James Carlson wrote:
> Depending on what "removes" means, this could be a pretty serious
> usability problem.
>
> If "removes" means that it's actually removed from the kernel forwarding
> table, and the user-level "route" command cannot access the route when
> the interface is down, then I think that'd be a bad thing.

These are the implicit routes created by the IP of the interface.

All other routes are managed through zebra.

> This means that the administrator cannot see what routes are actually on
> the box if any interface is down. The output from "netstat -nr" is a
> lie, because it omits routes that are really there but that simply
> cannot be seen at the moment.

You ask zebra what routes on configured.

> Worse still, it means that the administrator cannot delete a route
> that's "stuck" on a downed interface. As far as the "route" command is
> concerned, the route doesn't exist and thus can't be deleted. But as
> soon as the interface comes back up, it'll rise from the dead like an
> extra in a Romero movie.

You can delete anything you want in zebra's config.

> And it introduces some nasty edge cases into the kernel that have no
> good solutions. For example, suppose an interface goes down and takes a
> route with it. The user then adds a route that would have been rejected
> as a duplicate if that route had been up ("SIOCADDRT: File exists") --
> but it's accepted because the other route is currently missing. The
> interface comes back up. Now what? Who (if anyone) gets the error
> about the conflicting route? Are both installed in the table? Is one
> discarded silently?

Again, zebra manages it fine. We ONLY manage routes through zebra
other than the ones the kernel creates because of the IP/netmask of
the interface.

> > I know some kernel developers think it's a userspace problem to solve,
> > but since the kernel creates the darn routes in the first place I consider
> > it a kernel problem and solved it there.
>
> As someone who has straddled that boundary for a long time, I think
> there are really only a few sane ways forward:
>
> 1. Routes "temporarily removed" by the kernel are made a first class
> object. By this I mean that users can list, add, and delete these
> routes as necessary, without regard to the status of the interface.
> (One way to accomplish this would be to treat the underlying
> interface status as an immutable flag on the route, rather than
> removing/adding the route itself on link down/up.)

That would be nice. A lot more complicated to implement though. Doable.
I had considered it.

> 2. Routes are made independent of link status. If the underlying link
> is down, the route becomes an ICMP reject/destun path. If you want
> something else, run a routing daemon that can add or delete routes
> as necessary.

I do run zebra, the problem is that zebra won't add a route if the kernel
already has one. So I can't rely on OSPF giving me an alternate route
to a directly attached network through another interface and another
router that still has a connection to that network. The kernel route
has to go away and stop being used first.

> 3. Routes are deleted when a link goes down, but do not come back. If
> you have interfaces that can go down, and you have static routes,
> and want them to come back, you have to run something in user space
> (such as a routing daemon) that can do this.

That's right. Which is why we use zebra to do that.

> Solaris did the "cache the routes for down interfaces in hidden memory"
> trick for many years, and it was horrible for routing daemons to work
> with. I don't think it ever really worked quite right.

Yeah hidding them isn't great. It has to be flagged as not currently
in use instead but visible.

But having the option to make the kernel's implicitly created routes
come and go based on link state and having zebra in user space handle
all other routes does work very well. But one without the other does not.

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

lsorense at csclub

Oct 20, 2011, 9:37 AM

Post #9 of 13 (552 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

On Thu, Oct 20, 2011 at 12:34:17PM -0400, Lennart Sorensen wrote:
> > 3. Routes are deleted when a link goes down, but do not come back. If
> > you have interfaces that can go down, and you have static routes,
> > and want them to come back, you have to run something in user space
> > (such as a routing daemon) that can do this.
>
> That's right. Which is why we use zebra to do that.

This is the main reason I haven't even considered trying to push that
patch upstream.

It works fine on a product where all configuration goes through a user
interface that makes sure only quagga is in charge or routes. It wouldn't
work well in general (although it does have to be enabled by a per
interface link_detect flag, so the default behaviour is normal linux
route behaviour).

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

igorm at etf

Oct 21, 2011, 5:05 AM

Post #10 of 13 (548 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

2011/10/20 Stephen Hemminger <shemminger [at] vyatta>:
> The concept is good, in fact Vyatta added a patch to do this to Quagga
> which I keep meaning to revise and submit. But your patch is not enough
> to successfully manage kernel routes. There were another of other
> related issues that need to be addressed:
> 1. When this was brought up in the past, there were users who did
> not think this was what they wanted. In our version, the management
> of connected routes is optional.
>
> 2. In order to delete routes successfully on Linux, more state is needed.
> Otherwise when interface bounces you will see duplicate entries in
> the FIB. At a minimum this includes scope and metric which have
> to be tracked.
>

When interface bounces, you think that kernel routes aren't deleted
from kernel table?

> 3. You have to deal with the case where link detect is enabled.
> Normally (at least on Linux), IPv4 routes are maintained when carrier
> is lost. If linkdetect is enabled in Quagga, then the RIB has
> to actively delete those routes.
>

I'm just started hacking Quagga, so I have to ask you this.
If link detection is enabled in Quagga, when carrier is lost for the
interface, all the routes that where connected to that interface are
deleted from quagga's RIB, but they are not deleted from kernel
tables? If this is the case,
to me, that seems like a problem.
Also when carrier goes up for the interface, is kernel going to
announce the creating of the routes that were maintained when carrier
was lost? Or is he going to make any announce for those routes(that
they gone up)?

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

joakim.tjernlund at transmode

Oct 21, 2011, 6:36 AM

Post #11 of 13 (544 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

>
> 2011/10/20 Stephen Hemminger <shemminger [at] vyatta>:
> > The concept is good, in fact Vyatta added a patch to do this to Quagga
> > which I keep meaning to revise and submit. But your patch is not enough
> > to successfully manage kernel routes. �There were another of other
> > related issues that need to be addressed:
> > �1. When this was brought up in the past, there were users who did
> > � � not think this was what they wanted. In our version, the management
> > � � of connected routes is optional.
> >
> > �2. In order to delete routes successfully on Linux, more state is needed.
> > � � Otherwise when interface bounces you will see duplicate entries in
> > � � the FIB. At a minimum this includes scope and metric which have
> > � � to be tracked.
> >
>
> When interface bounces, you think that kernel routes aren't deleted
> from kernel table?
>
> > �3. You have to deal with the case where link detect is enabled.
> > � � Normally (at least on Linux), IPv4 routes are maintained when carrier
> > � � is lost. If linkdetect is enabled in Quagga, then the RIB has
> > � � to actively delete those routes.
> >
>
> I'm just started hacking Quagga, so I have to ask you this.
> If link detection is enabled in Quagga, when carrier is lost for the
> interface, all the routes that where connected to that interface are
> deleted from quagga's RIB, but they are not deleted from kernel
> tables? If this is the case,
> to me, that seems like a problem.
> Also when carrier goes up for the interface, is kernel going to
> announce the creating of the routes that were maintained when carrier
> was lost? Or is he going to make any announce for those routes(that
> they gone up)?
>
> BR
> Igor Maravi�

BTW, if you are going to hack route delete code in Q you need at least this patch:
http://lists.quagga.net/pipermail/quagga-dev/2009-January/007704.html
People with route delete problems has found that this patch cure their problems.

Jocke

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

igorm at etf

Oct 23, 2011, 5:36 AM

Post #12 of 13 (528 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

>
> BTW, if you are going to hack route delete code in Q you need at least this patch:
> http://lists.quagga.net/pipermail/quagga-dev/2009-January/007704.html
> People with route delete problems has found that this patch cure their problems.
>
> Jocke
>
Why this patch wasn't excepted in upstream Quagga? It fixes a nasty Quagga bug.

I did some testing of my own and came up to another solution for problem with kernel routes.
It's quite simple really. It resembles to Stephen Hemminger patch for linux kernel(http://kerneltrap.org/mailarchive/linux-netdev/2008/6/2/2010564)
because if link detection is enabled, when carrier is lost, all routes from the kernel,linked to that interface, are deleted both in kernel and zebra.

1. when link detection is disabled and carrier was lost, only ipv4 routes that are linked to that interface will be deleted. They are deleted in kernel,
and after that Quagga receives RTM_DELROUTE message, and deletes them normally. All ipv6 routes, linked to that interface, are intact.
2. when link detection is enabled and carrier was lost, interface is declared as down. Then all routes that are linked to that interface are deleted
from zebra's fib. To be sure that zebra's fib is in sync with kernel routing table, if route is from kernel(RIB_KERNEL_ROUTE (fib))
and it wasn't previously marked for deletion(del == NULL), we call function rib_uninstall_kernel and after that we mark it to be deleted from rib (del=fib).
If route was previously deleted from kernel, rib_uninstall_kernel won't have any effect. But if the route still exists in kernel, it will be deleted.
3. when interface is manually set to down, all routes linked to that interface are deleted in kernel, and they are deleted from zebra's rib.

works perfectly with Joakim Tjernlund's patch.

BR
Igor Maravić

Signed-off-by: Igor Maravic <igorm [at] etf>
---
:100644 100644 12f3fa5... 7ee4801... M zebra/zebra_rib.c
zebra/zebra_rib.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/zebra/zebra_rib.c b/zebra/zebra_rib.c
index 12f3fa5..7ee4801 100644
--- a/zebra/zebra_rib.c
+++ b/zebra/zebra_rib.c
@@ -758,6 +758,9 @@ rib_match_ipv6 (struct in6_addr *addr)
#define RIB_SYSTEM_ROUTE(R) \
((R)->type == ZEBRA_ROUTE_KERNEL || (R)->type == ZEBRA_ROUTE_CONNECT)

+#define RIB_KERNEL_ROUTE(R) \
+ ((R)->type == ZEBRA_ROUTE_KERNEL)
+
/* This function verifies reachability of one given nexthop, which can be
* numbered or unnumbered, IPv4 or IPv6. The result is unconditionally stored
* in nexthop->flags field. If the 4th parameter, 'set', is non-zero,
@@ -1128,6 +1131,10 @@ rib_process (struct route_node *rn)
redistribute_delete (&rn->p, fib);
if (! RIB_SYSTEM_ROUTE (fib))
rib_uninstall_kernel (rn, fib);
+ else if(RIB_KERNEL_ROUTE (fib) && del == NULL){
+ rib_uninstall_kernel (rn, fib);
+ del=fib;
+ }
UNSET_FLAG (fib->flags, ZEBRA_FLAG_SELECTED);

/* Set real nexthop. */
--
1.7.4.1

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

lsorense at csclub

Oct 24, 2011, 7:20 AM

Post #13 of 13 (507 views)
Permalink

Re: [PATCH] Zebra rib/fib to be in sinc with kernel routing table [In reply to]

On Sun, Oct 23, 2011 at 02:36:51PM +0200, "Igor Maravić" wrote:
> >
> > BTW, if you are going to hack route delete code in Q you need at least this patch:
> > http://lists.quagga.net/pipermail/quagga-dev/2009-January/007704.html
> > People with route delete problems has found that this patch cure their problems.
> >
> > Jocke
> >
> Why this patch wasn't excepted in upstream Quagga? It fixes a nasty Quagga bug.

I thought it had gone in. If it hasn't that is awful. It is a totally
obvious bug with a totally obvious fix.

Hmm, yeah I see we still have a local patch applied to fix that on
0.99.16.

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads