if (BGP_IS_VALID_STATE_FOR_NOTIF(peer->connection->status))
peer_notify_config_change(peer->connection);
else
bgp_session_reset_safe(peer, &nnode);
Let's add a bool return to peer_notify_config_change of whether or
not it should call the peer session reset. This simplifies
the code a bunch.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We have about a bajillion tests of if we can
notify the peer and then we send a config change
notification. Let's just make a function that
does this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The json display of the version attribute is originally an
integer. It has changed, most probably mistakenly.
> {
> "vrfId": 7,
> "vrfName": "vrf1",
> "tableVersion": 3,
> "routerId": "192.0.2.1",
> "defaultLocPrf": 100,
> "localAS": 65500,
> "routes": {
> "172.31.0.1/32": {
> "prefix": "172.31.0.1/32",
> "version": "1", <--- int or string ??
Let us fix it, by using the integer display instead.
Fixes: f9f2d188e3 ("bgpd: fix 'json detail' output structure")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Deprecate gracefulRestartCapability which is inconsistent with an existing
format if advertised and received are printed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Slipped somehow that peer-groups with GR is just completely broken, but it was
working before.
Strikes again, that we MUST have more and more topotests.
Fixes: 15403f521a ("bgpd: Streamline GR config, act on change immediately")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If the desired state is the same - do nothing instead of resetting once again.
Fixes: bdb5ae8bce ("bgpd: Make suppress-fib-pending clear peering")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
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>
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>
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>
Without the patch only the best path is displayed.
With the patch, display all paths including addpaths, but only for non-JSON
output to avoid breaking existing output.
E.g.:
```
munet> r2 shi vtysh -c 'sh ip bgp nei 192.168.2.3 advertised-routes'
Network Next Hop Metric LocPrf Weight Path
*> 172.16.16.254/32 192.168.2.3 0 0 65003 ?
* 172.16.16.254/32 192.168.2.4 0 0 65004 ?
*> 192.168.2.0/24 192.168.2.3 0 0 65003 ?
* 192.168.2.0/24 192.168.2.4 0 0 65004 ?
```
Before it was:
```
munet> r2 shi vtysh -c 'sh ip bgp nei 192.168.2.3 advertised-routes'
Network Next Hop Metric LocPrf Weight Path
*> 172.16.16.254/32 192.168.2.3 0 0 65003 ?
*> 192.168.2.0/24 192.168.2.3 0 0 65003 ?
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
CID: 1601739
Fixes: 937cf4db17 ("bgpd:support of color extended community color-only types")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If BFD is down, we should try to detect the source automatically from the given
interface.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Having something like:
```
neighbor 192.168.1.222 ebgp-multihop 32
neighbor 192.168.1.222 update-source 192.168.1.5
neighbor 192.168.1.222 bfd
```
Won't work and the result is (empty):
```
$ show bfd peers
BFD Peers:
```
bgp_stop() is called in BGP FSM multiple times (even at startup) that
causes intermediate session interruption when update-source/ebgp-multihop
is triggered.
With this fix, the ordering does not matter and the BFD session's parameters
are updated correctly.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
While populating the nexthop info for "show bgp nexthop json", resolvedPrefix
is added in parent json object instead of json_nexthop object.
This results in displaying wrong resolvedPrefix for nexthops.
Fixing the same by adding resolvedPrefix to json_nexthop object, so that
the proper resolvedPrefix would be displayed for the respective nexthop
Signed-off-by: Krishnasamy R <krishnasamyr@nvidia.com>
A redistribute cmd can have a route-map attached to it and adding the
match source-protocol to that route-map means BGP to filter which
protocol routes to accept among the bunch of routes zebra is sending.
Fixing this since this wasnt implemented earlier.
Ticket :#4119692
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
We have this:
if ( (safi == SAFI_UNICAST) && ...)
do stuff
if ( (safi == SAFI_MPLS_VPN) && ... )
do stuff
this leads to having to test safi multiple times if safi is
SAFI_UNICAST. Let's make it a else if as that we know that
the safi is going to not change.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In an attempt to make the code faster let's just pass
in the prefix instead of having to do a lookup a majillion
times again after we already have it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Without this patch we set only the first path for the route (if multiple exist)
as LLGR stale and stop doing that for the rest of the paths, which is wrong.
Fixes: 1479ed2fb3 ("bgpd: Implement LLGR helper mode")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
