[quagga-dev 10380] sub-optimal filtering in rip_rte_process(), (patch attached)

Jim Carroll jim at carroll.com
Mon Mar 25 20:39:38 GMT 2013


I've discovered what I believe to be a sub-optimal design with how RIPD
handles received routes that lack strict precedence.

 

If RIP receives a route for which the new-distance is greater than the
old-distance (for non RIP routes), it discards the route.  By discarding the
route, it prevents the installation of lower priority (aka: "backup")
routes. It seems it would be better to instead install the route, and allow
natural distance/metric selection to decide which is best.

 

--- Quick Explanation ---

 

We have two locations. At the prime location we use OSPF as our IGP. We
accept default route origination from our BGP session with our upstream and
redistribute it into OSPF. We run RIP in a simple point-to-point
configuration over a leased line to interconnect the two facilities. 

 

We have been trying to accept a default route from our remote facility over
RIP but it is being filtered due to the fact that the distance of the new
route is greater than the distance of the OSPF route (RIP default distance
120, OSPF default distance 110)

 

Under normal operation, it's not terrible that the default is filtered. But
as it stands, to accept the default from our remote location, we'd need to
wait for out BGP session to time out, and then for OSPF to flood this loss
of default, and then the next RIP RECV from our remote facility take place,
at which point we'd then accept the default route and we could initiate
another OSPF flood.  This represents a couple of minutes without a default.

 

This also creates a somewhat more complicated understanding of our routing
tables as it requires remembering that these routes will only appear when
other routes are removed.  Which of course leads people to be apprehensive
<grin>.

 

It would seem to be a better design (and harmless no?) if RIP just accepted
the default?

 

See attached patch (against quagga 0.99.22)

 

We'd been running this in production for awhile with no ill effects.

 

Jim C.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130325/f40d96ef/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ripd-c.patch
Type: application/octet-stream
Size: 541 bytes
Desc: not available
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130325/f40d96ef/attachment-0001.obj>


More information about the Quagga-dev mailing list