The bi->net pointer that is being unlocked had a commit
that removed the `bi->net = NULL;` recently. This code
was preventing a use after free crash being experienced
in other code paths. While commit 37e679629f was fixing
a different code path crash.
Make the parent->net pointer aware it may be locked/freed
from multiple places and to not NULL the pointer to it
unless we have actually freed the data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There is a default BGP VPN and BGP VRF instance in L3VPN configuration.
The routes are imported and exported between BGP VPN and BGP VRF.
Suppose there is one route in BGP VRF and exported to BGP VPN.
In BGP VPN there is bgp_info struct with bgp_info_extra struct has parent pointer pointing to the bgp_info of BGP VRF.
We take the lock for bgp_node and bgp_info of BGP VRF in the context of BGP VPN.
bgp_info has a back pointer to bgp_node via net.
Now when we have done "no rd vpn" in BGP VRF then in bgp_info_extra_free we have to free the parent resources.
In this context only unlocking is required. It should not set the BGP VRF (bgp_info->net) to NULL.
Signed-off-by: vishaldhingra vdhingra@vmware.com
Adding EVPN prefix of Type 2, 3 and 5 routes to bgp updates
prefix filters.
Ticket:CM-14476
Testing Done:
Configure multiple evpn options under 'debug bgp updates prefix'.
Below is the running-config output.
MAC-IP route with just MAC:
debug bgp updates prefix l2vpn evpn type macip mac
00:02:00:0a:0a:0a
MAC-IP route with MAC and IP:
debug bgp updates prefix l2vpn evpn type macip mac
00:02:00:00:00:0c ip 45.0.1.9
MAC-IP route with just MAC and IPv6:
debug bgp updates prefix l2vpn evpn type
macip mac 00:02:00:00:00:0a ip 2001:fee1:0:1::8
Type-3:
debug bgp updates prefix l2vpn evpn type multicast ip 27.0.1.19
Type-5:
debug bgp updates prefix l2vpn evpn type prefix
ip 2060:1:1:1::/64
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When configuring an interface, the no local-install any command appears,
and leads to confusions. because the effect of that command differs if
it is executed after local-install <interfaces> or before executing
local-install <interfaces>, the proposal fix here is to suppress that
command from the vty available commands.
PR=59595
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Acked-by: Alain Ritoux <alain.ritoux@6wind.com>
because the IP destination criterium may match several entries, the show
command may return more than one entry.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When adding an entry, a check is done in order to flush previously
configured entries. The whole parameters are checked so as to not remove
some entries that have ipset entries equal, but not iptable settings.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Instead of relying on jhash_1word for some parameters that are not 32
bit size, the jash(pointer, len) function is used.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Because one flowspec entry can create 1-N bgp pbr entries, the list is
now updated and visible. Also, because the bgp_extra structure is used,
this list is flushed when the bgp_extra structure is deleted.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
EVPN ND ext community support NA flag R-bit, to have proxy ND.
Set R-bit in EVPN NA if a given router is default gateway or there is a
local
router attached, which can be determine based on local neighbor entry.
Implement BGP ext community attribute to generate and parse R-bit and
pass along zebra to program neigh entry in kernel.
Upon receiving MAC/IP update with community type 0x06 and sub_type 0x08,
pass the R-bit to zebra to program neigh entry.
Set NTF_ROUTER in neigh entry and inform kernel to do proxy NA for EVPN.
Ref:
https://tools.ietf.org/html/draft-ietf-bess-evpn-na-flags-01
Ticket:CM-21712, CM-21711
Reviewed By:
Testing Done:
Configure Local vni enabled L3 Gateway, which would act as router,
checked
show evpn arp-cache vni x ip <ip of svi> on originated and remote VTEPs.
"Router" flag is set.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
This commit removes various parts of the bgpd implementation code which
are unused/useless, e.g. unused functions, unused variable
initializations, unused structs, ...
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current behavior of the `bgp default shutdown` command is to set the
state of all newly configured peers to shutdown. This leads to a problem
when restarting bgpd, because all peers will then be seen as newly
configured, which leads to all peers being set to shutdown after each
restart.
This behavior is undesired and not common when comparing the
implementation against other vendors. This commit moves the `bgp default
shutdown` configuration underneath the peer-group and peer
configuration, to ensure that existing peers will not be set to shutdown
after a daemon restart.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
In Symmetric routing case, L3VNI stores evpn MAC_IP routes
as IP_PREFIX routes in associated bgp_vrf and fib.
When vxlan device for l3vni goes down, triggers l3vni delete
in bgp.
As part l3vni delete, evpn ip prefix routes associated
with the vni need to be withdrawn from zebra as well
bgpinfo needs to be freed.
bgp_delete does not free bgp_info associated
to evpn ip prefix routes (link to bgp_vrf).
Call to uninstall_evpn_route_entry_in_vrf() properly
cleanup bgp_info as well triggers appropriate updates.
Ticket:CM-21443
Testing Done:
On DUT, bringup symmetric routing configuration, learn
EVPN Type-2 and Type-3 Routes.
Type-2 MAC_IP routes will be stored as ip_prefix in vrf table
during l3vni bring up.
Remove L3vni, deletes all ip_prefix routes from the zebra, kernel
vrf route table and bgp_info is freed.
Check the show bgp memory stats for bgp_info post l3vni flap.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The warning given by PVS-Studio is related to per-element overflow (there is
no real overflow, because of how elements are mapped in the union). This
same warning is typically reported by Coverity, too.
Signed-off-by: F. Aragon <paco@voltanet.io>
If a cache server was added after rpki was started it's tr_socket would
not be initialized. This would lead to a segfault if the rtr manager
ever decides to switch to that socket or if rpki support is stopped.
Signed-off-by: Marcel Röthke <marcel.roethke@haw-hamburg.de>
Issue 2473
VRF-VPN route-leaking configuration commands assumed existence of
default bgp instance. If a non-default vrf configuration occurred
before the default vrf configuration, it would result in a (NULL)
dereference to the non-existent default vrf.
This change 1) detects non-existence of default vrf and skips corresponding
RIB updating that normally occurs during configuration changes of the
route-leaking parameters; and 2) when the default bgp instance is defined,
runs the deferred RIB updating.
In vpn_leak_to_vrf_update_all(), replace early return if bgp_vpn is NULL
with assert, as the former would lead to subtly wrong RIB contents. The
underlying issue that led to commit 73aed5841a
should be fixed by the above changes.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
