[Quagga-bugs] [Bug 418] changing address on an existing interface doesn't cause existing static routes to be revalidated

[bugzilla-daemon at allevil.dishone.st]

Please do not reply directly to this email. All additional  
comments should be made in the comments box of this bug  
report.  
  
http://bugzilla.quagga.net/show_bug.cgi?id=418  
  




------- Additional Comments From paul at dishone.st  2007-12-03 14:46 -------
Quoting Denis:

"Contrariwise, when a new connected route replaces existing
one, the sequence is: remove the old connected route, revalidate the whole RIB,
add the new connected route."

and

"Both connected_up_ipv4() and connected_doconnected_down_ipv4() end up calling
rib_update() in a hope, that it will schedule RIB revalidation, but the latter
doesn't requeue or reorder already queued RIB records."

But if the RIB node is queued, then it means it /must/ be looked at /after/
connected_up_ipv4(). There is no state attached to a queue entry other than a
route_node, ie a queue entry says "This route_node has been changed one or more
times, please process it again".

The order doesn't matter - that's not what the queue entry is about. All the
queue is an index of interesting RIB nodes - it saves us having to do a complete
walk of the RIB after we know change has occured, but otherwise is no different
to a RIB walk.


------- Additional Comments From paul at dishone.st  2007-12-06 21:37 -------
Denis explained this further on IRC and, *if* I understand correctly, the
problem is that we ignore dependencies. E.g. given a route R, whose nexthop is
covered by connected route C, we might put R on the queue before C.

What I dont understand is that Denis extended workqueue and the RIB to have
route_nodes for connected routes put at the head of the queueu, and yet Denis
reported there were still problems.

?  
  
  
  
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.