If bgp is coming up and bgp has not received the interface address yet
but bgp has knowledge about a bfd peering, allow it to set the peering
data appropriately.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
a) timers are really large preventing convergence in 30 seconds
b) The same configuration does not need to be initiated 60 times
when things are not working properly. Once is enough.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This function when it is run by bgp_start is expected
to return a `enum connect_result`. But instead
the function returns a variety of values that are
not really being checked for. Consolidate to a correct
choice.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Remove from MSDP peer data structure two temporary variables
that should only be used when calling library functions.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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>
When using bfd in remote-dataplane client mode, don't close
a new client socket if we're going to try to use it.
Signed-off-by: Mark Stapp <mjs@cisco.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 change adds a topotest to test various case of OSPF multi-instance
origination including cases where the criteria route is from another
instance of OSPF, as well as the same OSPF instance (where a default
should not be originated).
Signed-off-by: Acee Lindem <acee@lindem.com>
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>
When originating a default AS-External LSA in one OSPF instance,
it wasn't working if the criteria route was installed by another OSPF
instance. This required more flexible processing of the OSPF external
route information.
Also fix problem multi-instance display for "show ip ospf
<instance> database ...".
Signed-off-by: Acee Lindem <acee@lindem.com>
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>
Json object could lead to out-of-memory in scaled bgp l2vpn evpn route setup.
Changes:
- not use pretty print and stringify smaller json objects to reduce memory
usage
- free memory after ouput of json_rd
- minor formatting of json output
Commands supported with this Json stringify:
show bgp l2vpn evpn route detail json
show bgp l2vpn evpn route detail type 2 json
show bgp l2vpn evpn route detail type 2 self-originate json
show bgp l2vpn evpn route detail self-originate json
show bgp l2vpn evpn route json
show bgp l2vpn evpn route type 2 json
show bgp l2vpn evpn route type 2 self-originate json
show bgp l2vpn evpn route self-originate json
Ticket:#3513249
Issue:3513249
Signed-off-by: Ashwini Reddy <ashred@nvidia.com>
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
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>
