the ipv4_ll address used for 5549 routes does not need
to be figured out every single time that we attempt
to install/remove a route of that type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Prior to the fix, labels weren't getting installed in zebra nor were the
ifindex values correctly set if labeled-unicast was used in conjunction
with bgp unnumbered.
Ticket: CM-16531
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6276
zebra_mpls_null.c should contain only dummy replacements for
platform-specific functions that may not be available on some systems
(e.g. add/delete LSPs in the kernel).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Revert "ospf6d: fix decimal area ID cli"
commit a27cb3cfe9
Revert "bgpd: add back unicast option to 'address-family vpnv(4&6)' Issue #459"
commit 399598bf6b
Revert "Fix the memory leak"
commit d8d58e9839
Revert "zebra: 'no ip route 4.1.1.19 255.255.255.255 99' is ambiguous"
commit 83f3561935
Revert "ospf6d: Allow unconfig of unknown lsa's"
commit 5b0747d71d
Revert "Fix the "Dead assignment" of clang SA."
commit 3a6570a1f1
Revert "snapcraft: Improve README.usage.md based on feedback received"
commit 2a3a819a9c
Revert "zebra: stop deregistering static nexthops unless removing the static"
commit 1dac3a9619
All of these changes do not apply on stable/3.0 due to either CLI
changes or another fix already being present.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem reported was that with some overlapping static route configurations,
when the link went down the less specific static was not re-installed after
the link came back up. Determined that with the overlapping statics, we
would recursively resolve the next-hop temporarily thru the more specific
static route, but since the next-hop wasn't actually reachable, we would go
through the code that clears the nht information for the static completely.
This caused the nht code to no longer process the static route.
After reviewing the process, there doesn't seem to be any reason that the
static should be deregistered in that section of code. Removed the
deregister and the problem is resolved and not addional failures seen in
manual testing. zebra_test.py completed successfully and ospf and bgp smokes
completed with no new failures.
Ticket: CM-14873
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-5696
Fix for another issue with next-hop tracking for overlapping static routes
created a problem removing the dead routes. This fix corrects that error.
Ticket: CM-13710
Signed-off-by: Don Slice
Reviewed By: Donald Sharp
Testing Done: ospf-smoke, bgp-smoke
Encountered a crash in zebra due to getting a delete on an SVI with
VRR configured. Since we don't actually do a delete but flag the interface
as inactive, slag VRR interfaces would remain on the vrf_iflist with a lock
count of zero, causing the crash. Since all other interface types are moved
to the default table before deleting, doing the same thing for any interfaces
that were left in the vrf.
Testing includes manual testing, bgp-min, ospf-min, vrf-min, bgp-smoke, and ospf-smoke.
All passed (first time or on rerun) or match known failures.
Ticket: CM-13288
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Whenever you did "redistribute" zebra would kick this off for ipv4 and
ipv6. No real issue other than this is sub-optimal
We only needed to add/change the vrf callbacks when we initialize
the vrf subsystem. As such it is not necessary to handle the callbacks
in any other way than through the init function.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Segregate the vrf enable/disable functionality from other vrf
code. This is to ensure that people are not actually using
the functions when they should not be. Also document the
why of it properly in the new vrf_int.h header.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
To avoid blocking zebra when it's acting as a proxy for an external
label manager.
Besides:
Fix get chunk reconnection. Socket was still being destroyed on failure,
so next attempt would never work.
Filter out unwanted messages in lm sync sock.
Until LDE client sends ZEBRA_LABEL_MANAGER_CONNECT message, zserv
doesn't know which kind of client it is, so it might enqueue unwanted
messages like interface add, interface up, etc. Changes in this commit
discard those messages in the client side in case they arrive before the
expected response.
Change function name for zclient_connect in label manager to avoid
confusion with zclient one.
Signed-off-by: ßingen <bingen@voltanet.io>
1) Fix the kernel send and recv hex dump of what we
are sending to the kernel
2) When configuring the debugs under 'conf t' display
it too.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
ZEBRA_FLAG_SELECTED hasn't been set yet by the time lsp_install is
called. The call path is:
rib_process -> rib_process_add_fib -> zebra_mpls_lsp_install -> lsp_install
but ZEBRA_FLAG_SELECTED is set in rib_process after it calls
rib_process_add_fib. I can't think of anything that it would hurt to
install the LSP regardless of whether ZEBRA_FLAG_SELECTED is set later.
I also cleaned up some UI (json and display the pretty label names
instead of their numeric values).
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
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>
Restore the original logic in netlink_link_change() which works like this:
* once an interface event is detected, lookup the associated interface
by its name;
* call the set_ifindex() function;
* set_ifindex() will lookup the interface again but now by its ifindex. If
the lookups by name and ifindex yield to different results, then the
interface was renamed and set_ifindex() will take care of that.
In the future, zns->if_table will be split into two different data
structures to allow faster lookups by both name and ifindex.
Fixes Issue #397.
Regression introduced by commit 12f6fb9.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
