In bgp global commands northbound local-as modify callback
check for backend db for checking existing bgp instance.
In an instance where no router bgp with old ASN cleaned up
followed by new bgp instance with new AS is created,
the nb_running_get_entry in validation phase returns stale
bgp reference, which leads to rejection of the router bgp command.
Uncovered via:
toptotest evpn_type5_test_topo1/test_evpn_type5_topo1.py
test_bgp_attributes_for_evpn_address_family_p1
Signed-off-by: Chirag Shah <chirag@nvidia.com>
if (pcout > (pcount * peer->max_threshold[afi][safi] / 100 ))
is always true. So the very first route received will always
trigger the warning. We actually want the warning to happen
when we hit the threshold.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The code pattern:
for (ALL_LSDB(lsdb, lsa)) {
remove_lsa(lsa)
}
has a use after free in ALL_LSDB, since we ask for the next pointer,
after it has been freed.
Modify the code such that we grab the next pointer before we can
possibly free it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The normal ospf6_lsa_lock call should return the pointer
to the lock data structure we are holding. This is the
normal pattern for locking a data structure in FRR.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In zebra_evpn_es_evi_show_vni the zevpn pointer if passed into
zebra_evpn_es_evi_show_one_evi will crash if it is null and
we have code that checks that it is non null and then immediately
calls the function. Add a return to prevent a crash.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
No need to check for n->mac existence as that all paths
leading to this code have n->mac already derefed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When nexthop is allocated, default value of blockhole type
was not getting set, this leads to below problem. The default
value should be in-sync with the deafult value in yang model.
c t
ip route 131.1.1.0/24 Null0
do show running-config
...
!
ip route 131.1.1.0/24 blackhole
!
end
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
The code in isisd uses `circuit->area->isis` all the time
but we know that circuit now has a valid `circuit->isis` pointer
so let's use that and cleanup the long dereference.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
rip(ng)d_instance_disable unlinks the vrf from the instance which means
that rip(ng)_interfaces_clean never works, because rip(ng)->vrf is
always NULL there. This leads to the crash #6477.
Clean interfaces before disabling the instance to fix the issue.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There are code paths where we were not always setting the
circuit->isis on creation. Fix that up so it will always
happen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When we enter `router bgp` it enters non-VRF instance which is default.
No need to check for VRF/VIEW name, kinda dead code.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
ospf6_network.h needs ospf6_top.h to be included
first.
This makes newer versions of gcc much much happier.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Lookup in C_STATE_NA must be made before the new circuit creation, or it
will be leaked if the isis instance is not found. All other lookups are
unnecessary - we just need to remember the previously used instance.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The bgp_l3vpn_to_bgp_vrf test is looking for a prefix
on multiple routers that the ordered received is non-deterministic.
As such the regex's are failing occassionaly when the
route is received in an unexpected order.
One possible order:
(#89) scripts/check_routes.py:120 COMMAND:ce3:vtysh -c "show bgp ipv4 uni 6.0.1.0":2 available, best .*192.168.1.1.* Local.* 99.0.0.3 from 0.0.0.0 .99.0.0.3.* Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best .Weight.* Community: 0:67.* Extended Community: RT:89:123.* Large Community: 12:34:56.* Local.* 192.168.1.1 from 192.168.1.1 .192.168.1.1.* Origin IGP, metric 98, localpref 123, valid, internal.* Community: 0:67.* Extended Community: RT:52:100 RT:89:123.* Large Community: 12:34:56:pass:Redundant route 1 details c:
COMMAND OUTPUT:BGP routing table entry for 6.0.1.0/24^M
Paths: (2 available, best #1, table default)^M
Advertised to non peer-group peers:^M
192.168.1.1^M
Local^M
99.0.0.3 from 0.0.0.0 (99.0.0.3)^M
Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best (Weight)^M
Community: 0:67^M
Extended Community: RT:89:123^M
Large Community: 12:34:56^M
Last update: Wed Oct 7 11:12:22 2020^M
Local^M
192.168.1.1 from 192.168.1.1 (192.168.1.1)^M
Origin IGP, metric 98, localpref 123, valid, internal^M
Community: 0:67^M
Extended Community: RT:52:100 RT:89:123^M
Large Community: 12:34:56^M
Last update: Wed Oct 7 11:12:41 2020:
R:89 ce3 Redundant route 1 details c 1 0
Second possible order:
(#89) scripts/check_routes.py:120 COMMAND:ce3:vtysh -c "show bgp ipv4 uni 6.0.1.0":2 available, best .*192.168.1.1.* Local.* 99.0.0.3 from 0.0.0.0 .99.0.0.3.* Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best .Weight.* Community: 0:67.* Extended Community: RT:89:123.* Large Community: 12:34:56.* Local.* 192.168.1.1 from 192.168.1.1 .192.168.1.1.* Origin IGP, metric 98, localpref 123, valid, internal.* Community: 0:67.* Extended Community: RT:52:100 RT:89:123.* Large Community: 12:34:56:pass:Redundant route 1 details c:
COMMAND OUTPUT:BGP routing table entry for 6.0.1.0/24^M
Paths: (2 available, best #2, table default)^M
Advertised to non peer-group peers:^M
192.168.1.1^M
Local^M
192.168.1.1 from 192.168.1.1 (192.168.1.1)^M
Origin IGP, metric 98, localpref 123, valid, internal^M
Community: 0:67^M
Extended Community: RT:52:100 RT:89:123^M
Large Community: 12:34:56^M
Last update: Wed Oct 7 11:14:45 2020^M
Local^M
99.0.0.3 from 0.0.0.0 (99.0.0.3)^M
Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best (Weight)^M
Community: 0:67^M
Extended Community: RT:89:123^M
Large Community: 12:34:56^M
Last update: Wed Oct 7 11:14:27 2020:
R:89 ce3 Redundant route 1 details c 0 1
BGP displays the paths in the order received since it's just a linked list.
For this test modify/add the luCommands to track that we may
receive the paths in a non-deterministic order.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
