Add more details to these logs to help make it easier to determine why
ospf6 adjacency is not coming up. Also make these logs show up without
having to turn on debug logging, again making it easier to debug the
misconfiguration.
Signed-off-by: Lynne Morrison <lynne@voltaio.net>
Only ask the event-loop poll() to awaken if a newly-added timer
actually might have changed the required timeout. Also compute
timer deadline outside of mutex locks.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Recent changes to allow bgpd to handle v6 LL slightly
differently in the nexthop tracking code has not
interacted well with the blackhole nexthop change
for peers. Modify the code to do the right thing
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The existing code was using the oid2in_addr API to copy IPv6
addresses passing an IPv6 length. Create a utility to do this
properly and avoid annoying coverity with type checking.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
bgp is currently registering v6 LL as nexthops to be tracked
from zebra. This presents several problems.
a) zebra does not properly track multiple prefixes that match
the same route properly at this point in time.
b) BGP was receiving nexthops that were just incorrect because
of (a).
c) When a nexthop changed that really didn't affect the v6 LL
we were responding incorrectly because of this
Modify the code such that bgp nexthop tracking notices that
we are trying to register a v6 LL. When we do so, shortcut
and watch interface up/down events for this v6 LL and do
the work when an interface goes up / down for this type
of tracking.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When enabling the VRF, we should not install the nexthops that rely on
non-existent VRF.
For example, if we have route "1.1.1.0/24 2.2.2.2 vrf red nexthop-vrf blue",
and VRF red is enabled, we should not install it if VRF blue doesn't exist.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Currently, staticd creates a VRF for the nexthop it is trying to install.
Later, when this nexthop is deleted, the VRF stays in the system and can
not be deleted by the user because "no vrf" command doesn't work for this
VRF because it was not created through northbound code.
There is no need to create the VRF. Just set nh_vrf_id to VRF_UNKNOWN
when the VRF doesn't exist.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When checking for local connected address used as a nexthop gateway, we
should check nexthop VRF, not route VRF.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Commit: 996c93142d
is a bit of a reformat and the .git-blame-ignore-revs
is missing this commit. Add it to it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When looking up the conversion from kernel protocol to
internal protocol family make sure we use the correct
AF_INET( what the kernel uses ) instead of AFI_IP (which
is what FRR uses ).
Routes from OSPF will show up from the kernel as OSPF6 instead of
OSPF. Which will cause mayhem
Ticket: CM-33306
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Adding agentx_enabled hook.
This permits the main LDP process to signal the lde and ldpe
processes when agentx is enabled.
Signed-off-by: Karen Schoener <karen@voltanet.io>
Some ICC command-line options can cause confusion for other
compilers; test for ICC specifically, and only try to use those
options if ICC is being used.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Make the generate-support-bundle script and interactions more
python3-friendly, and use python3 explicitly.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
CR, NL and CRNL are all OK, but CRNL shouldn't get treated as 2
newlines (which causes an empty command to be executed => empty prompt
line.)
Signed-off-by: David Lamparter <equinox@diac24.net>
The FDs are in struct vty, and there's ->fd and ->wfd, which shouldn't
be confused. Passing vty_sock along separately just creates mixups.
Signed-off-by: David Lamparter <equinox@diac24.net>
The return code from smux_trap is never used. If we have
never used it after all this time. Remove the return from
the function.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The new bgp_mplsvpn_snmp.c code increments i and
never uses that value. Comment the code out
to make the clang SA analyzer happy. Shouldn't
be a problem since this code will never probably
be touched again(ha!).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>