It is possible that the if_lookup_by_index() call will return
a NULL value and calling zclient_send_interface_radv_req. Just
test that we have a valid interface pointer.
Found by Coverity
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The netlink_vrf_change() function is called both when a VRF device
is created in the Linux kernel and when it is activated. This
commit changes this function to perform the VRF misconfiguration
detection only when the VRF device is created, as doing the check
twice would cause a false positive followed by a hard failure (not
to mention the double check is unnecessary since the VRF table ID
can't change once the device is created).
Fixes#6319.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
All custom "exit-*" commands that exit from a YANG-modeled
CLI node need to use cmd_exit() to ensure the CLI xpath index
(vty->xpath_index) will be updated accordingly.
Fixes#6316.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Changes to ACL rules were not applied to LDP. This fix allows
LDP to be notified when a rule in an ACL filter is modified by
the user. The filter is properly applied to the LDP session.
The filter may cause a LDP session to go down/up or to remove/add
labels being advertised/received from a neighbor.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
Signed-off-by: Karen Schoener <karen@voltanet.io>
The function zebra_vxlan_print_neigh_vni_vtep does not create
a json object when json has been requested from the CLI and as a
result it prints out the information in normal CLI format.
Fix is to allocate the json object when required.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
Reported by testing agency that rfc 4861 section 6.2.1 states
that all implementations must have a configuration knob to change
the setting of the advertised retransmit timer sent in RA packets.
This fix adds that capability.
Ticket: CM-29199
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Modify the import-check command to require the underlying prefix
to exist in the rib. General consensus is that this is the correct
behavior.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Intermittently, there is a 30 second delay for a LDP pseudowire to become
operational.
One way to reproduce the issue is: Once PW is up, shutdown link to trigger
a change to the pseudowire's next hop, and then restore link to cause
pseudowire to return to original NH.
Problem Descripton:
The Zebra PW manager installs pseudowires in the data plane when the
following two conditions are met:
1. Pseudowire is labeled via LDP mapping messages
2. A labeled NH route exists to reach the remote pseudowire endpoint
The Zebra PW manager registers a NHT callback when a pseudowire is enabled.
This allows the Zebra PW manager to install or reinstall the pseudowire.
The Zebra PW manager deregisters for the NHT callback when the pseudowire is
disabled. When LDP learns the remote-pseudowire status is 'not forwarding',
LDP notifies Zebra that the pseudowire is disabled.
This creates a race condition where a new labeled NH can be resolved after the
Zebra PW manager deregistered for the NHT callback.
For static pseudowires, it makes sense for Zebra PW manager to deregister for
NHT callbacks for disabled pseudowires. Static pseudowires become disabled
via CLI configuration commands.
For LDP pseudowires, the Zebra PW manager should not deregister for NHT
callbacks for disabled pseudowires.
Overview of changes:
1. Zebra PW manager should not deregister for NHT callbacks when an LDP
pseudowire is disabled.
Zebra PW manager will register for NHT callbacks when the LDP pseudowire
is first enabled.
Zebra PW manager will deregister for NHT callbacks when the LDP
pseudowire is deleted.
2. Remove the 30 second timer that was added in PR4122.
PR4122 tried to fix this race condition with a timer.
Once we eliminate the race condition (by keeping the Zebra PW manager
registered for NHT callbacks), this timer can be removed.
3. Zebra PW manager handling of static pseudowires will remain as-is.
Zebra PW manager will register for NHT callbacks when the static
pseudowire is enabled.
Zebra PW manager will deregister for NHT callbacks when the static
pseudowire is disabled.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
Signed-off-by: Karen Schoener <karen@voltanet.io>
This reverts commit d741915ecd.
This is because it breaks this behavior:
router ospf6
<commands>
!
int enp39s0
<more commands>
!
This is a very legal set of commands and completely destroys the
ability to do this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The question here isn't "why does it break on PowerPC?", but rather "why
doesn't it break on x86_64 or ARM?"
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem reported that in many circumstances, RAs created in the
process of bringing up numbered IPv6 peers with extended-nexthop
capability enabled (for ipv4 over ipv6) were not stopped on the
interface when those peers were deleted. Found several circumstances
where this occurred and fix them in this patch.
Ticket: CM-26875
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
when removing a whole address-family block from ldpd config
we were erroneously trying to also remove each of the interface
sub-sub-contexts that belonged to it; this would effectively
re-enable the AF we just removed. Work around this by ignoring
these sub-sub-contexts if we detect that we are already
removing the parent block.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
An async route notification can indicate that installation
has failed, but the handling code wasn't dealing with that
possibility correctly.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Dealing with PRIu64 is unfortunately a bit hacky in the frr-format
plugin, as in, it works correctly with snprintfrr, but breaks on plain
snprintf. There's no good solution unfortunately :/.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These are easy to get subtly wrong, and doing so can cause
nondeterministic failures when racing in parallel builds.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
