On 22/10/2015 17:24, Paul Jakma wrote: > Note, in terms of storage, Quagga does the same thing. Identical AS_PATHs > and attribute objects overall are shared via a common pool, across /all/ > RIBs - LocRIB, client-RIB, and AdjIn/Outs.
quagga is different because it has separate copies of the actual prefix for each loc-rib, even if the attribute objects are shared in a common pool. > If I understand that page right, you have to manually specify the groupings > by configuring peers in a set of tables, and best-path is run per virtual > table? Is that right? (And if enough peers are similar (e.g. promisc) in > policies, then #virt-tables will be << #peers, then win). no, it's done on a pre-prefix basis rather than a per-table. My understanding is that Bird has a single copy of each candidate prefix and each virtual table links to sets of candidate prefixes. Best path is then run on this set rather than on each virtual table. If there are duplicate sets of candidate prefixes in different tables, only one best-path calculation is performed, which is linked from each virtual table. In practice, this turns out to a pretty serious win because most organisations don't bother tinkering with policy hooks, which means that most prefix candidate sets are the same, which means that bird will typically run only a small fraction of the number of best-path calculations that quagga might. Nick _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
