| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
these changes are for improving the code maintainability and readability
Signed-off-by: sri-mohan1 <sri.mohan@samsung.com>
|
|
|
|
|
|
| |
these changes are for improving the code maintainability and readability
Signed-off-by: sri-mohan1 <sri.mohan@samsung.com>
|
|
|
|
| |
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
|
|
| |
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
|
|
|
|
|
|
|
| |
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
|
|
|
|
| |
Done with a combination of regex'ing and banging my head against a wall.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
|
|
| |
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
|
|
|
|
| |
Just convert all uses of thread_cancel to THREAD_OFF
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
|
|
|
|
|
| |
The int return value is never used. Modify the code
base to just return a void instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
|
|
|
|
|
|
| |
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 220e848cc5 introduced an optimization that would prevent ldpd
from sending redundant label mappings when it receives notifications
from zebra about routes that didn't effectively change (such
notifications can happen under certain circumstances).
The problem is that that commit didn't take into account the metric
of the received routes, so it would dismiss a notification of a
route with a better metric taking the place of another route in the
RIB, preventing the newly selected route from receiving the label
mappings it needs.
Revert 220e848cc5 temporarily to fix sporadic failures in the CI
system until we have a better solution.
Debugged-by: Lynne Morrison lynne@voltanet.io
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an API that allows IGP client daemons to register/unregister
RLFAs with ldpd.
IGP daemons need to be able to query the LDP labels needed by RLFAs
and monitor label updates that might affect those RLFAs. This is
similar to the NHT mechanism used by bgpd to resolve and monitor
recursive nexthops.
This API is based on the following ZAPI opaque messages:
* LDP_RLFA_REGISTER: used by IGP daemons to register an RLFA with ldpd.
* LDP_RLFA_UNREGISTER_ALL: used by IGP daemons to unregister all of
their RLFAs with ldpd.
* LDP_RLFA_LABELS: used by ldpd to send RLFA labels to the registered
clients.
For each RLFA, ldpd needs to return the following labels:
* Outer label(s): the labels advertised by the adjacent routers to
reach the PQ node;
* Inner label: the label advertised by the PQ node to reach the RLFA
destination.
For the inner label, ldpd automatically establishes a targeted
neighborship with the PQ node if one doesn't already exist. For that
to work, the PQ node needs to be configured to accept targeted hello
messages. If that doesn't happen, ldpd doesn't send a response to
the IGP client daemon which in turn won't be able to activate the
previously computed RLFA.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
|
|
|
|
|
|
|
| |
Add some code to detect when a route received from zebra hasn't
changed and ignore the notification in that case, preventing ldpd
from sending unnecessary label mappings.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
|
|
|
|
|
|
|
|
| |
Replace all lib/thread cancel macros, use thread_cancel()
everywhere. Only the THREAD_OFF macro and thread_cancel() api are
supported. Also adjust thread_cancel_async() to NULL caller's pointer (if
present).
Signed-off-by: Mark Stapp <mjs@voltanet.io>
|
|
|
|
|
|
|
|
| |
LDP would mark all routes as learned on a non-ldp interface. Then
when LDP was configured the labels were not updated correctly. This
commit fixes issues 6841 and 6842.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
|
|
|
|
|
|
|
|
| |
When LDP is configured in Order Control mode and we receive a
label withdraw message, we should only resend label withdraws to
peers that are the NH for that fec being withdrawn.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
|
|
|
|
|
|
|
|
| |
Update LDP to process received pw-status in received order.
Update LDP to save pw-status regardless of whether the PW is configured.
When the PW is configured, LDP checks for any saved PW pw-status.
Signed-off-by: Karen Schoener <karen@voltanet.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|