| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
LDP ordered label distribution control only binds a label to
a FEC if it is the egress LSR, or the router received a label
binding for a FEC from the next hop router. In this mode,
an MPLS router will create a label binding for each FEC and
distribute it to its neighbors so long as he has a entry in
the RIB for the destination.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
Signed-off-by: Karen Schoener <karen@voltanet.io>
|
| |
|
|
|
|
|
|
|
| |
Use the route type and instance instead of the route distance
to identify MPLS FTNs. This is a more robust approach since the
routing daemons can modify the distance of their announced routes
via configuration, which can cause inconsistencies.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
| |
LDP should release labels allocated from zebra if its not getting used.
Signed-off-by: Binu <binu_abraham@looptelecom.com>
|
| |
|
|
|
|
|
| |
Fix up the assignment of the variable = RB_ROOT inside of
while loop patter we were using.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
| |
While here, fix the other SA warnings.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some scenarios, it's possible to send a Label Withdraw to a neighbor
and not receive a corresponding Label Release right away. This can happen
during reconvergence after a network failure or configuration change.
When this happens, the list of upstream mappings of a given FEC might
not be empty even after sending a Label Withdraw to all neighbors. This
situation holds until all neighbors either send a Label Release or are
torn down (e.g. keepalive timeout).
With that said, we shouldn't check for 'RB_EMPTY(&fn->upstream)'
in lde_kernel_update() because it can prevent ldpd from sending label
mappings in such circumstances. This check was introduced to avoid sending
the same label mapping more than once to the same neighbor, but we need
to remove this optimization for now until we find a better solution (which
probably involves refactoring the whole zebra<->ldpd communication).
While here, add a new debug message in lde_send_labelmapping() which
can aid in troubleshooting label problems in the future.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
| |
If we receive a notification from zebra indicating that the installation
of a pseudowire has failed (e.g. no reachability), send a PW Status
notification to the remote peer (or a Label Withdraw if the remote peer
doesn't support the PW Status TLV).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Switch the RB tree implementation completely to the new dlg@'s version
that uses pre-declared functions instead of macros for tree functions.
Original e-mail/diff:
https://marc.info/?l=openbsd-tech&m=147087487111068&w=2
Pros:
* Reduces the amount of code that the usage of those macros generate
* Allows the compiler to do a better compile-time check job
* Might have better i-cache utilization since the tree code is shared
Con:
* dlg@ benchmarks shows it has 'very slightly slower' insertions
* imported RB_* code must adapt the following calls:
RB_INIT(), RB_GENERATE(), RB_ROOT(), RB_EMPTY(), make compare
functions use 'const' (if not already) and maybe others.
|
| |
|
|
| |
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Pass pointer to pointer instead of assigning by return value. See
previous commit message.
To ensure that the behavior stays functionally correct, any assignments
with the result of a thread_add* function have been transformed to set
the pointer to null before passing it. These can be removed wherever the
pointer is known to already be null.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way thread.c is written, a caller who wishes to be able to cancel a
thread or avoid scheduling it twice must keep a reference to the thread.
Typically this is done with a long lived pointer whose value is checked
for null in order to know if the thread is currently scheduled. The
check-and-schedule idiom is so common that several wrapper macros in
thread.h existed solely to provide it.
This patch removes those macros and adds a new parameter to all
thread_add_* functions which is a pointer to the struct thread * to
store the result of a scheduling call. If the value passed is non-null,
the thread will only be scheduled if the value is null. This helps with
consistency.
A Coccinelle spatch has been used to transform code of the form:
if (t == NULL)
t = thread_add_* (...)
to the form
thread_add_* (..., &t)
The THREAD_ON macros have also been transformed to the underlying
thread.c calls.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once we send a Label Withdraw, we can't send a Label Mapping for the
same FEC until we receive a Label Release from the peer. This is due to
some limitations in the LDP algorithms described in Appendix A. ("LDP
Label Distribution Procedures") of RFC 5036.
To workaround this issue, make it possible to schedule the sending of
a Label Mapping as soon as a Label Release is received for the same FEC.
The easiest way to test this patch is by typing the "label local advertise
explicit-null" command. ldpd will withdraw all null labels using a
Wildcard FEC and then send new Label Mappings as soon the corresponding
Label Releases are received.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On unstable networks, routes can be lost and relearned very often. If
we deallocate the input label every time a route is lost and allocate
a new one when the route is relearned, a lot of changes are made in vain.
This patch introduces a logic in which labels are preserved for at least
five minutes before being deallocated by the LIB garbage collector. This
is consistent with what other implementations do.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
| |
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
| |
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
| |
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
This was missing from our original RFC 4447 VPLS implementation. Now
ldpd understands group wildcards as mandated by the RFC, but we still
don't send them ourselves. I can't see any case in which sending a group
wildcard would be useful, but nonetheless this patch provides a function
called lde_send_labelwithdraw_pwid_wcard() which is ready to be used in
the future anytime we feel like it might be useful.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever we receive a Label Withdraw message with an optional Label
TLV, we should check if this label matches the label previously
received from this neighbor for this FEC. If they don't match then we
shouldn't uninstall the previous label from the kernel. This fixes a
misinterpretation from the "Receive Label Withdraw" algorithm described
in the A.1.5 section of RFC 5036.
Also, simplify the check of pending withdraws in lde_check_release()
and lde_check_release_wcard().
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
| |
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ldpd allocates null labels for directly connected routes. If a connected
route is removed (interface goes down) and an IGP learned route takes its
place in the RIB, ldpd must update the local label of the associated FEC
entry with a non-null label. The same applies for the other way around
(an interface goes up and a connected route is selected in favour of an
IGP route). Labels should be dynamic and change when necessary.
Additionally, this patch fixes the processing of route delete messages
from zebra. Route delete messages don't contain any nexthop, meaning that
whenever we receive such messages we must delete all nexthop previously
received.
Based on a patch from Bingen Eguzkitza <bingen@voltanet.io>.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
|
| |
This patch introduces several new configuration commands to ldpd. These
commands should allow the operator to define advanced filtering policies
for things like label advertisement, label allocation, etc.
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>
|
| |
|
|
|
| |
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
(cherry picked from commit 7144dc12b55e05c9ae3d784dfb75817c9f881eb6)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
|
|
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
