Now with a full AutoRP implementation, we can test AutoRP in a full network setup
beginning with candidate RP announcements all the way through discovery and active RP
selection.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Fully flushed out the AutoRP implementation now with the AutoRP mapping agent.
This touched most of AutoRP in order to have common reuse of containers for each
section of AutoRP operation (Candidate RP announcement, Mapping agent, Discovery).
Many debugs had guards added and many more debug logs added.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
If at least one community alias is configured, then let's do the work,
otherwise we don't need to spend time on splitting stuff and creating
a new string.
This should improve the performance.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This is an issue for big-endian architectures, that causes incorrect castings.
lua_tointegerp() uses int*, not long long*.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When building for big-endian architectures, this is failing because of
long long / int casting issues, let's use a separate integer to get the
results.
This is especially important when building the Docker images for multiple arches.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Fix Coverity Scan CID 1601875: use the return value to tell user about
the availability of a next hop to the learned RP (needs debug enabled).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
If we have (default enabled) enabled `bgp ebgp-require-policy`, then first check
it before applying the route-maps.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If we receive an IPv6 prefix e.g.: 2001:db8:100::/64 with nextop: 0.0.0.0, and
mp_nexthop: fc00::2, we should not treat this with an invalid nexthop because
of 0.0.0.0. We MUST check for MP_REACH attribute also and decide later if we
have at least one a valid nexthop.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In cases such as 'no advertise-all-vni' and L2 VNI DELETE, we need to
pop all the VPN routes present in the bgp_zebra_announce FIFO yet to
be processed regardless of VNI is configured or not.
NOTE: NO need to pop the VPN routes in two cases
1) In free_vni_entry
- Called by bgp_free()->bgp_evpn_cleanup().
- Since bgp_delete is called before bgp_free and we pop all the dest
pertaining to bgp under delete.
2) evpn_delete_vni() when user configures "no vni" since the withdraw
of all routes happen in normal cycle.
Fixes: a07df6f754
("bgpd : backpressure - Handle BGP-Zebra(EPVN) Install evt Creation")
Ticket :#4163611
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
as is not initialized and it's assigned only later.
CID: 1601739
Fixes: 937cf4d ("bgpd:support of color extended community color-only types")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Signalize termination to functions so they can avoid accessing pointers
that might be no longer available.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When a multicast route is created with embedded RP the channel oil
never gets decremented when `clear ipv6 mroute` is called.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
