Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The library libzebra that is installed with FRR will
conflict with Quagga. So let's rename it to libfrr.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This replaces Quagga -> FRR in most configure.ac settings as well as
a handful of preprocessor macros in the source code.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The ZEBRA_ROUTE_ALL route type can be used by a client to request
all routes from zebra. The main motivation for introducing this is
to allow ldpd to get routes from all OSPF instances, not only from
the default one. Without ZEBRA_ROUTE_ALL, ldpd would need to send a
ZEBRA_REDISTRIBUTE_ADD message for each possible OSPF instance (65k),
which doesn't scale very well.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
If a command is put into the VIEW_NODE, it is going into the
ENABLE_NODE as well. This is especially true for show commands.
As such if a command is in both consolidate it down to VIEW_NODE.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
ldpd was keeping track of the vty session's position in config editing
with 3 global static variables. This worked because only one vty could
be in configuration-editing mode before.
Replace with vty->qobj_index infrastructure and enable
vty_config_lockless.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Place the appropriate QOBJ_* calls. A bit more complicated for ldpd due
to the dup-merge config scheme.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These functions are currently unused but will be used by the Cap'n Proto
interface. They're not a particular burden to maintain in-tree, so here
they go.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Extend configuration duplication-merge mechanism to allow keeping track
of a single specific object. A "void **" pointer is passed in; the
"void *" pointer it points to is updated with the new address of the
object it points to.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is necessary to prevent the same old configuration to come back
when the interface is reactivated later for a given address-family.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Whenever a routing daemon advertises a new version of a route to zebra,
zebra removes the old version of this route (implicit withdraw) and then
create a new 'rib' structure for the new version of the route.
In this process, the previously received label(s) from ldpd are lost. This
is because upon receiving a ZEBRA_MPLS_LABELS_ADD message, zebra only
adds a label to a nexthop of an existing route. And routes are volatile,
they can be removed while being updated.
To workaround this issue, this patch makes ldpd always advertise the
appropriate labels whenever it receives a redistributed route, even
if it was already received before (an older version). This way, when
ldpd receives the updated version of a route, it will readvertise the
appropriate label(s) and zebra will reinstall them.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Commit 5048fe changed the way zebra behave when a route is updated. Now,
whenever a route is changed, zebra advertises its new version without
withdrawing the old one. This patch adapts ldpd to understand this new
behavior. After processing a ZEBRA_REDISTRIBUTE_IPV[46]_ADD message,
we need to check for nexthops that were removed and, for each of them
(if any), withdraw the associated labels from zebra.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Since recently zebra uses only the ZEBRA_REDISTRIBUTE_* messages
to advertise redistributed routes to its clientes. Now the old
ZEBRA_IPV*_ROUTE_* messages are only used for client->zebra communication.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
On a SUN/Solaris system the string "sun" is a preprocessor define and
can't be used for program variables.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
