Mailing List Archive

[Bug 418] changing address on an existing interface doesn't cause existing static routes to be revalidated
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


daniel_ng11@lycos.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |daniel_ng11@lycos.com






------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-bugs
[Bug 418] changing address on an existing interface doesn't cause existing static routes to be revalidated [ In reply to ]
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 daniel_ng11@lycos.com 2007-11-30 06:47 -------
*** Bug 428 has been marked as a duplicate of this bug. ***



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-bugs
[Bug 418] changing address on an existing interface doesn't cause existing static routes to be revalidated [ In reply to ]
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@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@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.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-bugs