Mailing List Archive

On Fri, 19 Mar 2004, Jean-Yves Simon wrote:

> Hello,
>
> I've patched ripd so it now takes care of the administrative distance of
> his own routes to update them.
>
> This bug is described better at
> http://bugzilla.quagga.net/show_bug.cgi?id=81
> proposed patch at
> http://bugzilla.quagga.net/attachment.cgi?id=30&action=view
>
>
> But this making me dig a lot more into RIP, brought some other thing to
> my mind:
>
> ripd apparently only build a table of the used routes, shouldn't he,
> like ospfd, grab all the possible routes into the table instead, and
> then make his decision on that table on which one he will use?
>
> Why? Let's say we have 2 routes for 1 destination, if 1 route fails, it
> will take the time to detect the link is failing (can be immediate, or
> can take XX minutes), then all the traffic will be replied with an "Icmp
> unreachable", until a new message of another interface comes in saying
> "hey, i know that route too" (can take as long as ~30 seconds)
>
> This is only an idea, but i think this will force big internal changes
> in ripd
> Don't know if it's really worth the trouble

Yes, I have been working on that for some time now. Unfortunately
currently I do not have enough time to finish it, but it is neraly ready.
There are still some things, mostly bugfixes. If you like I can send you
my patch for testing.

Best regards,

Krzysztof Olêdzki

On Fri, 19 Mar 2004, Jean-Yves Simon wrote:

> On Fri, 2004-03-19 at 18:33, Krzysztof Oledzki wrote:
>
> > Yes, I have been working on that for some time now. Unfortunately
> > currently I do not have enough time to finish it, but it is neraly ready.
> > There are still some things, mostly bugfixes. If you like I can send you
> > my patch for testing.
> Yup i'd like to get my eyes on it, i don't promise anything (the last 2
> lines code take me about 7 hours to write, because i had to learn most
> of the rip internals arg;) ) so i think i'm more or less ready ;)

OK, so there it is. It is my first public (but still alpha) version of patch
for ripd routing daemon which adds multipath support. It works in my small and
very limited netlab testing enviroment but I'm not sure if I am ready to run
it in my routers on my production network. So, please consider this code as
something which is ready for testing not for use. Before testing this patch,
please applay my distance patch for zebra daemon.

How it works? Previously each route_node was holding one rip_info structure
with data about nexthop, metric, distance, etc. Now, it contains two-way
list of rip_info structures. Most functions from ripd.c file were changed and
some of them nearly completly rewrited. There are many new functions -
rip_connected_check(), rip_get_distance(), rip_rinfo_add(), rip_rinfo_remove()
and rip_process_route(). The most important function - rip_process_route()
is called every time when something happens (added/removed/changed) in one
of the rip_info structures. What this function does is documented in the code:
/*
* - Find the best rinfo to specific destination.
* - If possible, remove rinfo which has just been marked with RIP_RTF_DELETED,
* else set metric to RIP_METRIC_INFINITY.
* - Remove old route (if appropriate) from zebra routing table.
* - Install new route (if appropriate) to zebra routing table.
* - Return 1 if selected different rinfo as the best one.
*/

This is a very usefull function, which does the main job for most
other functions. Please compare, for example, old and new rip_timeout()
function:

--- old one/begin ---
int
rip_timeout (struct thread *t)
{
struct rip_info *rinfo;
struct route_node *rn;

rinfo = THREAD_ARG (t);
rinfo->t_timeout = NULL;

rn = rinfo->rp;

/* - The garbage-collection timer is set for 120 seconds. */
RIP_TIMER_ON (rinfo->t_garbage_collect, rip_garbage_collect,
rip->garbage_time);

rip_zebra_ipv4_delete ((struct prefix_ipv4 *)&rn->p, &rinfo->nexthop,
rinfo->metric);
/* - The metric for the route is set to 16 (infinity). This causes
the route to be removed from service. */
rinfo->metric = RIP_METRIC_INFINITY;
rinfo->flags &= ~RIP_RTF_FIB;

/* - The route change flag is to indicate that this entry has been
changed. */
rinfo->flags |= RIP_RTF_CHANGED;

/* - The output process is signalled to trigger a response. */
rip_event (RIP_TRIGGERED_UPDATE, 0);

return 0;
}
--- old one/end ---

--- new one/begin ---
int
rip_timeout (struct thread *t)
{
struct rip_info *rinfo;

rinfo = THREAD_ARG (t);
rinfo->t_timeout = NULL;

rinfo->flags |= RIP_RTF_DELETED;

/*
* Process the route after this modification.
*
* If the best nexthop has just changed then signall
* the output process to trigger a response.
*/
if (rip_process_route(rinfo->rp))
rip_event (RIP_TRIGGERED_UPDATE, 0);

return 0;
}
--- new one/end ---

With help from rip_process_route() this function is much shorter. So.. if there
are any important errors in the code they are probably around this function.
Two main ripd functions: rip_rte_process() and DEFUN(show_ip_rip) were totaly
rewrited, so please check them also.

Other changes:
- There are no longer CONNECT/interface routes. CONNECT routes are marked
"inactive" if they are not matched by any of "network addr" or "nework ifname".
Inactive routes are no longer being redistributed, AFAIK exactly like in
modern Cisco IOS. If you need to redistribute connected route but don't
like to send/receive rip packets on specific interface plese use:
ip prefix-list filter_all deny any
router rip
distribute-list prefix filter_all out <device>
distribute-list prefix filter_all in <device>
You can also use "passive-interface" for disabling outgoing traffic.

And again: Before testing this patch please applay my distance patch for
zebra deamon.

TODO:
- Add rip_info limit (number of stored path informations for one prefix)

- What distance should be added to networks from the "route" command?

- Test, test, test and again - test!

- Port changes to ripng. Maybe it is possible to create something
like librip with shared code for ripd and ripngd?


Best regards,

Krzysztof Olêdzki