Before:
```
$ vtysh -c 'show bgp l2vpn evpn route detail json'
<<<<<<<<<<<<<<<<<<<< empty line
<<<<<<<<<<<<<<<<<<<< empty line
<<<<<<<<<<<<<<<<<<<< empty line
<<<<<<<<<<<<<<<<<<<< empty line
{
...
"numPrefix":4,
"numPaths":4 <<<<< four paths = four empty lines
}
```
Contain as much "empty lines" before the JSON string as the number
of paths displayed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Let's convert to our actual library call instead
of using yet another abstraction that makes it fun
for people to switch daemons.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Running `bgp_srv6l3vpn_to_bgp_vrf` and `bgp_srv6l3vpn_to_bgp_vrf2`
topotests with `--valgrind-memleaks` gives several memory leak errors.
This is due to the way SRv6 locators are removed/unset in bgpd: when
an SRv6 locator is deleted or unset, the memory allocated for the
locator prefix (`tovpn_sid_locator`) is not freed.
This patch adds a `for` loop that iterates over the list of BGP
instances. For each BGP instance using the SRv6 locator to be
removed/unset, we use `XFREE()` to properly free the memory allocated
for `tovpn_sid_locator` after the SRv6 locator is removed or unset.
The memory allocated for `tovpn_sid_locator` cannot be freed before
calling `vpn_leak_postchange_all()`. This is because
after deleting an SRv6 locator, we call `vpn_leak_postchange_all()`
to handle the SRv6 locator deletion and send a BGP Prefix SID withdraw
message. `tovpn_sid_locator` is required to properly build the BGP
Prefix SID withdraw message. After calling `vpn_leak_postchange_all()`
we can safely remove the `tovpn_sid_locator` and free the allocated
memory.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Running `bgp_srv6l3vpn_to_bgp_vrf` and `bgp_srv6l3vpn_to_bgp_vrf2`
topotests with `--valgrind-memleaks` gives several memory leak errors.
This is due to the way SRv6 SIDs are removed in bgpd: when
an SRv6 locator is deleted/unset, all the SIDs allocated from that
locator are removed from the SRv6 functions list
(`bgp->srv6_functions`),but the memory allocated for the SIDs is not
freed.
This patch adds a call to `XFREE()` to properly free the allocated
memory when an SRv6 SID is removed.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Running `bgp_srv6l3vpn_to_bgp_vrf` and `bgp_srv6l3vpn_to_bgp_vrf2`
topotests with `--valgrind-memleaks` gives several memory leak errors.
This is due to the way SRv6 locators are deleted/unset in bgpd: when
an SRv6 locator is deleted/unset, all the chunks of the locator are
removed from the SRv6 locator chunks list (`bgp->srv6_locator_chunks`).
However, the memory allocated for the chunks is not freed.
This patch adds a call to the `srv6_locator_chunk_free()` function to
properly free the allocated memory when an SRv6 locator is removed or
unset.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
BGP SoO is a tag that is appended on BGP updates to allow a peer to mark
a particular peer as belonging to a particular site. In certain MPLS L3 VPN
configurations, the BGP AS-Path may not provide the granularity needed
prevent a loop in the control-plane. With this in mind, BGP SoO is designed
to fill this gap and prevent a routing loop that may occur.
If we configure for example, `neighbor soo 65000:1` at PEs, routes won't be
announced between CPEs if soo matches. This is especially needed when using
as-override or allowas-in.
Also, this is the automated way of the same behavior as configuring route-maps
for each peer like:
```
bgp extcommunity-list cpe permit soo 65000:1
!
route-map cpe permit 10
set extcommunity soo 65000:1
...
route-map cpe deny 10
match extcommunity cpe
route-map cpe permit 20
...
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before this, if the community-list has an entry with permit internet (0:0),
then it's treated as permit everything and returned as MATCH.
So if we have something like:
```
bgp community-list standard OUT_AS_PERMIT seq 5 permit internet
bgp community-list standard OUT_AS_PERMIT seq 10 deny 4:1
bgp community-list standard OUT_AS_PERMIT seq 20 permit 3:1
```
It's not gonna work because it will return MATCH and stops parsing.
Routes with 4:1 community will be advertised.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before:
```
donatas-laptop# show bgp ipv4 unicast community-list testas
% testas is not a valid community-list name
donatas-laptop# con
donatas-laptop(config)# bgp community-list standard testas permit internet
donatas-laptop(config)# do show bgp ipv4 unicast community-list testas
donatas-laptop(config)#
```
`is not a valid community-list name` is a misleading warning message.
Doing the same for filter-list, access-list, prefix-list, route-map.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
For now, only if the knob is enabled. Later this gonna be (most likely) removed
and routes with AS_SET / AS_CONFED_SET will be denied by default.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If we have conditional advertisement enabled, and conditionally withdrew
some prefixes, and then we do a 'clear bgp', those routes were getting
advertised again, and then withdrawn the next time the conditional
advertisement scanner executed.
When we go to advertise check the prefix against the conditional
advertisement status so we don't do that.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
The new outbound filter to apply conditional advertisement policy was
not working properly due to complications with update groups. The two
routemaps were properly copied into the update group peer filter but not
the conditional advertisement state.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
When `-l` is used, then no routes are exported to the kernel.
```
$ grep bgpd_options /etc/frr/daemons
bgpd_options=" -A 127.0.0.1 -l 127.0.0.2"
```
Before:
```
donatas-pc# sh run | include no-rib
bgp no-rib
donatas-pc#
```
After:
```
donatas-pc# sh run | include no-rib
donatas-pc#
```
Signed-off-by: Kris Shannon <k.shannon@amaze.com.au>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Handle ORF REMOVE_ALL events as well, because now we just silently return, and
a stale dynamic prefix-list is used instead of the new one.
Before this, soft clear/route refresh was needed. Don't know the reason, but
we didn't send updates when modifying the filters.
Probably due to a massive change of filters and to avoid automatic updates :/
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
RFC 4760 states we SHOULD ignore the NEXT_HOP attribute for BGP Update
messages carrying only MP_REACH_NLRI attributes. Thus we should use the
Network Address of Next Hop field of the MP_REACH_NLRI as the nexthop.
Instead of always looking for BGP_ATTR_NEXT_HOP, this commit ensures:
1) we set mp_nexthop_len to BGP_ATTR_NHLEN_IPV4 for v4 bgp_static routes
2) we check mp_nexthop_len when choosing the nexthop to use for nht
3) we check mp_nexthop_len when choosing the nexthop to send to zebra
4) we check mp_nexthop_len when picking the nexthop to shown by vtysh
Reported-by: Binon Gorbutt <binon@aervivo.com>
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Instead of changing the value of 'BUM flooding' field in
'show bgp l2vpn evpn vni' vty and JSON command from
'Head-end replication' to 'enabled', adding a new field named
'vxlanFlooding' to 'show bgp l2vpn evpn vni' vty and JSON output.
This is done to maintain backward compatibility.'BUM flooding' field
in vty and JSON output will be deprecated later.
Signed-off-by: Pooja Doijode <pdoijode@nvidia.com>
Move the logic to check the mp_nexthop_len against v6 lengths into its
own macro so we can apply that logic elsewhere on its own without always
checking for presence of BGP_ATTR_NEXT_HOP.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
bgpd was crashing every time `show bgp l2vpn evpn route rd` was issued
with an RD that didn't match "all". This was introduced by 9b01d28988
which changed how argv_find() is handled in various vtysh commands, but
the new changes forgot a "!". So let's re-add the "!".
Before:
```
ub20# show bgp l2vpn evpn route rd 399672:100
vtysh: error reading from bgpd: Resource temporarily unavailable (11)Warning: closing connection to bgpd because of an I/O error!
ub20#
ub20# show bgp l2vpn evpn route rd 399672:100 mac 11:11:11:11:11:11
vtysh: error reading from bgpd: Resource temporarily unavailable (11)Warning: closing connection to bgpd because of an I/O error!
ub20#
```
After:
```
ub20# show bgp l2vpn evpn route rd 399672:100
ub20#
ub20# show bgp l2vpn evpn route rd 399672:100 mac 11:11:11:11:11:11
% Network not in table
ub20#
```
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
The same as with prefix-list/route-maps/etc.
```
donatas-pc# show ip access-list spine
ZEBRA:
Zebra IP access list spine
seq 5 permit 200.200.200.200/32
BGP:
Zebra IP access list spine
seq 5 permit 200.200.200.200/32
PIM:
Zebra IP access list spine
seq 5 permit 200.200.200.200/32
BABELD:
Zebra IP access list spine
seq 5 permit 200.200.200.200/32
donatas-pc# show bgp ipv4 unicast access-list
ACCESSLIST_NAME Access-list name
spine
donatas-pc# show bgp ipv4 unicast access-list spine
BGP table version is 9, local router ID is 172.17.0.3, vrf id 0
Default local pref 100, local AS 1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 200.200.200.200/32
enp3s0 0 0 65000 3456 ?
Displayed 1 routes and 10 total paths
donatas-pc#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The bgp_path_info_to_ipv6_nexthop will correctly set
the nexthop value. There is no need to test this to
display something that won't be used in debug
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
fixes the recent support bmp monitor of VPNv4 afi/safi
the bmp updates messages (MP_REACH_NLRI) are never sent for VPNv4 and bmp withdraws (MP_UNREACH_NRLI) are sent instead
this is caused by bgp_node_lookup which fails to find VPNv4 bgp_node in the rib which results in NULL path info attributes passed to bmp_monitor
using bgp_afi_node_lookup instead of bgp_node_lookup solves the problem
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
