Mailing List Archive: [Bug 431] Wishlist for any future redesign of the Zebra RIB

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=431

------- Additional Comments From paul@dishone.st 2008-03-26 21:04 -------
Another example from Denis, via IRC:

20:20 < Pilot> eth0: 10.0.0.0/24
20:20 < Pilot> eth1: 10.0.1.0/24
20:20 < Pilot> eth2: 10.0.2.0/24
20:20 < Pilot> and 3 statics:
20:21 < Pilot> 10.0.0.0/24 via 10.0.1.254
20:21 < Pilot> 10.0.1.0/24 via 10.0.2.254
20:21 < Pilot> 10.0.2.0/24 via 10.0.0.254

20:43 < Pilot> B> 10.0.0.0/24 via 10.0.2.254
20:43 < Pilot> B> 10.0.1.0/24 via 10.0.0.254
20:43 < Pilot> B> 10.0.2.0/24 via 10.0.1.254

20:44 < Pilot> whichever order you try, you always get one record with
incorrectly resolved B> RIB and one record with incorrectly resolved S> RIB

20:46 < Pilot> in the above case you'll get the last RN evaluated correctly
20:46 < Pilot> (cause all 3 C> RIBs and 2 S> RIBs will be processed as should be)
20:47 < Pilot> the RN before the last will have one RIB incorrect
20:47 < Pilot> and the first RN will have only C> correct
20:48 < Pilot> the RIB records for some RNs will be there, but they won't have
their nexthops updated the right way
20:49 < Pilot> this way, to produce the correct RIB from this "3 RN, 3
protocols" setup, you'll need to repeat rib_process() 3 times
20:50 < Pilot> 1 pass: you have 3 C> RIBs for sure and probably 2 S> RIBs and
may be 1 B> RIB
20:50 < Pilot> 2nd pass: 3 C> RIBs are left untouched and you end up with 3
correct S> RIBs
20:51 < Pilot> 3rd pass: now you can be 100% sure all 3 B> RIBs have recursive
nexthop resolved properly
20:51 < paul> what should be the correct result (another dumb question perhaps ;) )
20:52 < Pilot> 3 RNs, each holding 3 RIBs
20:52 < Pilot> only C> ones will be selected

20:53 < Pilot> let's change the setup a little
20:53 < Pilot> B> 20.0.0.0/24 via 10.0.2.254
20:53 < Pilot> B> 20.0.1.0/24 via 10.0.0.254
20:53 < Pilot> B> 20.0.2.0/24 via 10.0.1.254
20:55 < Pilot> after the traditional rib_process() run some of the 20's could
happen inactive just because the nexthop wasn't yet available at the moment they
were processed

------- 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

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=431

------- Additional Comments From web@pilot.org.ua 2008-03-26 21:13 -------
Okay, my last invention was to maintain as many RIB queues, as we have routing
protocols running. rib_add_queue() would have to queue particular RNs into each
RIB qeueue, for which the RN has got RIB records; and rib_process() would only
have to process the queues in a fixed order (connected -> static -> IGP -> EGP).

This approach adds considerable coding overhead, but it's better than adding a
priority field to the RIB queue, because many records only need to be reviewed
once, if it is done when necessary (when everything is ready for current nexthop
resolution). With per-protocol queues we only run as many iterations as we
really need to revalidate the RIB.

That is the solution.

------- 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