In function ls_find_subnet(), prefix argument is directly copied into
subnet.key structure to find corresponding subnet in RB Tree. This could leadr
to a memory corruption. Function prefix_copy() must be used instead.
This patch replaces the direct prefix copy by a call to prefix_copy() function
to avoid this memory issue.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When using ls_stream2ted() function to parse Opaque Link State message to local
TED, in case of vertex or subnet deletion, the function return a pointer to the
deleted ls_element instead of NULL. This could lead into a potential pointer
corruption when caller try to access to the deleted ls_element.
This patch ensure that the ls_element pointer return by ls_stream2ted()
function is NULL when the message event is a delete operation for vertex and
subnet. Note that edge deletion was correctly handled.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
FRR has a memory leak in the case when int X does not
exist and a memory leak when int X does exist. Fix
these
Fixes: #13434
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 74e21732db)
When the router is non dr for an interface, it installs mroute to drop
the packets from directly connected source. This was done to avoid packets
coming to cpu as nocache hit. Later when it gets change from non-DR to DR,
these entries are not cleared. So the packets are still dropped.
This causes register packets not getting generated.
So cleaning up the mroute entries and channel oil without
upstream reference which was created to drop.
Co-authored-by: Saravanan K <saravanank@vmware.com>
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
(cherry picked from commit 1c883aef96)
The current local mac delete event send to flag with force
always which breaks the duplicate detected MACs where
it requires to be resynced from bgpd to earlier state.
Ticket:#3233019
Issue:3233019
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 89844a9678)
Upon receiving local mobility event for MAC + NEIGH,
both are detected as duplicate upon hitting DAD threshold.
Duplicated detected ( freezed) MAC + NEIGH are not known
to bgpd.
If locally learnt MAC + NEIGH are deleted in kernel,
the MAC is marked as AUTO after sending delete event
to bgpd.
Bgpd only reinstalls best route for MAC_IP route (NEIGH)
but not for MAC event.
This puts a situation where MAC is AUTO state and
associated neigh as remote.
Fix:
DUPLICATE + LOCAL MAC deletion, set MAC delete request
as reinstall from bgpd.
Ticket:#2873307
Reviewed By:
Testing Done:
Freeze MAC + two NEIGHs in local mobility event.
Delete MAC and NEIGH from kerenl.
bgp rsync remote mac route which puts MAC to remote state.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit ad7685de28)
* Bug Fixes
bgpd
- Fix crash due to community aliases size
- Aggregate-address memory leak fix
- Bmp fix peer-up ports byte order
- Check 7 bytes for long-lived graceful-restart capability
- Copy the password from the previous peer on peer_xfer_config()
- Do not allow a `no router bgp xxx` when autoimport is happening
- Do not allow l3vni changes when shutting down
- Do not announce routes immediatelly on filter updates
- Do not call bgp_soft_reconfig_in() twice in a row on policy change
- Evpn-mh esi not active suppress ead-es route
- Fix crash for `show bgp ... neighbor received-routes detail|prefix`
- Fix debug output for route-map names when using a unsuppress-map
- Fix ecommunity parsing for as4
- Fix for ain->attr corruption during path update
- Increase buffer size used for dumping bgp to mrt files
- Limit flowspec to no attribute means a implicit withdrawal
- Prevent null pointer deref when outputting data
lib
- Adjust only `any` flag for prefix-list entries if destroying
- Destroy `any` flag when creating a prefix-list entry with prefix
- Fix clear route-map cmd using defpy
- Fix link state memory leak
- Include clippy generated commands for routemap.c
- On bfd peer shutdown actually stop event
ospfd
- Cleanup some memory leaks on shutdown in ospf_apiserver.c
- Fix for vitual-link crash in signal handler
- Fix ospf_lsa memory leak
- Fix ospf_ti_lfa drop of an entire table
- Fixing summary origination after range configuration
- Free up q_space in early return path
- Log adjacency changes with neighbor ip in addition to neighbor id
pbrd
- Fix mismatching in match src-dst
pim6d
- Fixing mroutes not created after disabling and enabling pimv6.
pimd
- Fix use after free issue for ifp's moving vrfs
- In_multicast needs host order
- Process no-forward bsm packet
ripd
- Fix malformed route-map
- Fix memory leak for ripd's route-map
staticd
- Tell bfd that we are shutting down
tools
- Fix missing remote-as configuration when reload
- Frr-reload fix list value not present
- Make check flag really work for reload
- Set correct directory of vtysh for frr-reload.py
zebrad
- Add link_nsid to zebra interface
- Cleanup ctx leak on shutdown and turn off event
- Evpn mh sync mac install as inactive
- Fix for heap-use-after-free in evpn
- Fix race during shutdown
- Install directly connected route after interface flap
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
If you have a very large number of large communities whose
string length happened to be greater than BUFSIZ FRR's bgpd
would crash. This is because bgpd would write beyond
the end of the string.
Originally the code auto-calculated the string size appropriately
but commit ed0e57e3f0 modified
the string length to be a hard coded BUFSIZ. When a route-map
like this is added:
route-map LARGE-OUT permit 10
set large-community 4635:0:0 4635:1:906 4635:1:2906 4635:1:4515 4635:1:4594 4635:1:4641 4635:1:4760 4635:1:7979 4635:1:9253 4635:1:9293 4635:1:9304 4635:1:9908 4635:1:13335 4635:1:16265 4635:1:17924 4635:1:18013 4635:1:20940 4635:1:22822 4635:1:24429 4635:1:24482 4635:1:32590 4635:1:32934 4635:1:36692 4635:1:38008 4635:1:38819 4635:1:41378 4635:1:45753 4635:1:46489 4635:1:49544 4635:1:51847 4635:1:54574 4635:1:54994 4635:1:55720 4635:1:56059 4635:1:57724 4635:1:65021 4635:1:134823 4635:1:136907 4635:1:146961 24115:0:24115 24115:1:906 24115:1:2906 24115:1:4515 24115:1:4594 24115:1:4641 24115:1:4760 24115:1:7979 24115:1:9253 24115:1:9293 24115:1:9304 24115:1:9908 24115:1:13335 24115:1:16265 24115:1:17924 24115:1:18013 24115:1:20940 24115:1:22822 24115:1:24429 24115:1:24482 24115:1:32590 24115:1:32934 24115:1:36692 24115:1:38008 24115:1:38819 24115:1:41378 24115:1:45753 24115:1:46489 24115:1:49544 24115:1:51847 24115:1:54574 24115:1:54994 24115:1:55720 24115:1:56059 24115:1:57724 24115:1:65021 24115:1:134823 24115:1:136907 24115:1:100000 24115:1:100001 24115:1:100002
exit
BGP would have issues and crash.
Modify the code to correctly determine the string length of the communities
and to also double check if the string has an alias and ensure that the
string is still sufficiently large enough. If not auto size it again.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
1. Consider a established L2VPN EVPN BGP peer with soft-reconfiguartion
inbound configured
2. When the interface of this directly connected BGP peer is shutdown,
bgp_soft_reconfig_table_update() is called, which memsets the evpn buffer
and calls bgp_update() with received attributes stored in ain table(ain->attr).
In bgp_update(), evpn_overlay attribute in ain->attr (which is an interned
attr) was modified by doing a memcpy
3. Above action causes 2 attributes in the attrhash (which were previously different)
to match!
4. Later during fsm change event of the peer, bgp_adj_in_remove() is called
to clean up the ain->attr. But, because 2 attrs in attrhash match, it causes
BGP to assert in bgp_attr_unintern()
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
(cherry picked from commit 6e076ba523)
EVPN MH ES reduendant VTEPs need to install
sync MAC as notify inactive and generate
ND:Proxy stamped extended community on Type-2
route.
Ticket:#3436621
Issue:3436621
Testing Done:
tor-11 originates type-2 MAC route:
tor-11# bridge -d fdb show | grep 00:65:00:00:00:01
00:65:00:00:00:01 dev hostbond1 vlan 1000 notify master bridge static
tor-12 receives sync MAC route:
Before fix:
----------
tor-12:/# bridge -d fdb show | grep 00:65:00:00:00:01
00:65:00:00:00:01 dev hostbond1 vlan 1000 notify master bridge static
After fix: inactive is set to MAC entry
----------
tor-12:/#bridge -d fdb show | grep 00:65:00:00:00:01
00:65:00:00:00:01 dev hostbond1 vlan 1000 notify inactive master bridge
static
Notice the difference in `inactive` post notify on tor-12
with the fix.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 4a1f91a366)
The check flag of `found_pg_cmd` is already there, but not used.
So, make it really work for reload.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
(cherry picked from commit 9ea17a5d49)
From commit `411d1a2`, `bgp_delete_nbr_remote_as_line()` is added to
remove some specific bgp neighbors. But, when reloading the following
configuration, it will wrongly remove some good ones:
`neighbor 66.66.66.6 remote-as internal`:
```
router bgp 66
bgp router-id 172.16.204.6
neighbor ANLAN peer-group
neighbor ANLAN remote-as internal
neighbor 66.66.66.6 remote-as internal <- LOST
neighbor 66.66.66.60 peer-group ANLAN
```
The reason is that "66.66.66.6" is included in "66.66.66.60" literally,
then it is mistakenly thought to be a match. Just fix it with
excat match.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
(cherry picked from commit a70895e83a)
When ospf6 is started up and SPF is run depending on which route is
selected as the parent route we could miss adding a NH. If one
possible parent route has two equal cost paths and the second possible
parent route has only one depending on which one is selected first
determines if we have have one or two NHs.
In the network below when creating a route 2001:db8:3:4::/64 in R2.
When SPF is run there are two possible parent routes R3 and R4.
2001:db8:1:2 +-----+ 2001:db8:2:5
+--------------+ 2 +---------------+
| ::2 | | ::2 |
| +-----+ |
| |
::1| |
+-----+ |::5
| 1 |2001:db8:1:3+-----+2001:db8:3:5+-----+2001:db8:5:6+-----+
| +------------+ 3 +------------+ 5 +------------+ 6 |
+-----+ ::1 ::3 | |::3 ::5 | |::5 ::6| |
::1| +-----+ +-----+ +-----+
| |::3
| | 2001:db8:3:4
| |
| |::4
| 2001:db8:1:4 +-----+
+--------------+ 4 |
::4 | |
+-----+
The problem was if we first created the route to 2001:db8:3:4::/64 with R3
as the parent route all is fine. The code was merging the NH from the parent
route and R3 has 2 NH, one pointing to R1 and one to R5. But if route
2001:db8:3:4::/64 was first created with parent as R4, it has only one NH
pointing to R1, and then later a new vertex was created pointing to R3 the
code would only copy the nhs from the vertex not from the parent route. The
vertex always has just one NH. But the parent route could have more. So
when we would bringup this setup one time we would see one NH for
2001:db8:3:4::/64 and the next time we would see two NHs. The code has been
modified so that it behaves the same when the route is first created, or when
a vertex is created, it selects the NHs from the parent route.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
(cherry picked from commit 637e6f293b)
After doing "no ipv6 pim" and "ipv6 pim" on receiver interface in LHR,
mroutes were not created.
When we enable pim after disabling it, we refresh the membership on pim interface.
First we clear the membership on the interface, then we add it back.
For PIMv6 we were only clearing it, membership was not added back. So mroutes were not created.
Now added code to fetch all the local membership information into PIM.
Fixes: #12005, #12820
Signed-off-by: Abhishek N R <abnr@vmware.com>
(cherry picked from commit 00fed6ed3b)
Topology Used:
=============
Cisco---FRR4----FRR2
Initially PIM nbr is down between FRR4----FRR2 from FRR2 side
Cisco is sending BSR packet to FRR4.
Problem Statement:
=================
No shutdown the PIM neighbor on FRR2 towards FRR4.
FRR2, receives BSR packet immediately as the new neighbor
comes up. This BSR packet is having no-forward bit set.
FRR2 is not able to process the BSR packet, and drop the
BSR packet.
Root Cause:
==========
When PIMD comes up, we start BSM timer for 60 seconds.
Here, the value accept_nofwd_bsm is setting to false.
FRR2, when receives no-forward BSR packet, it is getting
accept_nofwd_bsm value as false.
So, it drops, the no-forward BSM packet.
Fix:
===
Set accept_nofwd_bsm as false after first BSM packet received.
Signed-off-by: Sarita Patra <saritap@vmware.com>
(cherry picked from commit 8b462d5579)
Issue:
After vlan flap, zebra was not marking the selected/best route as installed.
As a result, when a static route was configured with nexthop as directly
connected interface's(vlan) IP, the static route was not being installed
in the kernel since its nexthop was unresolved. The nexthop was marked
unresolved because zebra failed to mark the best route as installed after
interface flap.
This was happening because, in dplane_route_update_internal() if the old and
new context type, and nexthop group id are the same, then zebra doesn't send
down a route replace request to kernel. But, the installed (ROUTE_ENTRY_INSTALLED)
flag is set when zebra receives a response from kernel. Since the
request to kernel was being skipped for the route entry, installed flag
was not being set
Fix:
In dplane_route_update_internal() if the old and new context type, and
nexthop group id are the same, then before returning, installed flag will
be set on the route-entry if it's not set already.
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
(cherry picked from commit e25a0b138a)
Create VRF and interfaces:
ip netns add vrf1
ip link add veth1 index 100 type veth
ip link add link veth1 veth1.200 type vlan id 200
ip link set veth1.200 netns vrf1
ip -n vrf1 link add veth2 index 100 type veth
After reloading zebra, "show interface veth1.200" shows wrong parent
interface:
test# show interface veth1.200
Interface veth1.200 is down
...
Parent interface: veth2
This is because veth1.200 and veth1 are in different netns, and veth2
happens to have the same ifindex as veth1, in the same netns of
veth1.200.
When looking for parent, link-ifindex 100 should be looked up within
link-netns, rather than that of the child interface.
Add link_nsid to zebra interface, so that the <link_nsid, link_ifindex>
pair can uniquely identify the link interface.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
(cherry picked from commit af19624b00)
During shutdown, the main pthread stops the dplane pthread
before exiting. Don't try to clean up any events scheduled
to the dplane pthread at that point - just let the thread
exit and clean up. This is the 8.5 version.
Signed-off-by: Mark Stapp <mjs@labn.net>
When cleaning `ripd`, it should free `ctx->name` of `struct if_rmap_ctx`,
not `ctx` itself. Otherwise, it will lead to memory leak.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
(cherry picked from commit d3ec0066e5)
update_type1_routes_for_evi() is called from
L3VNI/L2VNI up event, if ESI is not UP then
do not advertise EAD-ES Type-1 route.
Just like from multiple places EAD-ES route
origination checks for its oper status.
Ticket:#3413454
Issue:3413454
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit c683b7baad)
When we have these sequence of events causing a crash in
evpn_type5_test_topo1:
(A) no router bgp vrf RED 100
this schedules for deletion the vrf RED instance
(B) a l3vni change event from zebra
this creates a bgp instance for VRF RED in some cases
additionally it auto imports evpn routes into VRF RED
Please note this is desired behavior to allow for the
auto importation of evpn vrf routes
(C) no router bgp 100
The code was allowing the deletion of the default
instance and causing tests to crash.
Effectively the test in bgp_vty to allow/dissallow
the removal of the default instance was not correct
for the case when (B) happens.
Let's just not allow the command to succeed in this case as that
the test was wrong.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 746e0522f3)
When a `no router bgp XXX` is issued and the bgp instance
is in the process of shutting down, do not allow a l3vni
change coming up from zebra to do anything. We can just
safely ignore it at this point in time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 5a7c43c77e)
Let's cut to the chase, we know the pointer type and
it allows us to not to some gyrations.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit ef96e3753f)
All other parsing functions done from bgp_nlri_parse() assume
no attributes == an implicit withdrawal. Let's move
bgp_nlri_parse_flowspec() into the same alignment.
Reported-by: Matteo Memelli <mmemelli@amazon.it>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit cfd04dcb3e)
FRR's standards state that function declarations should
have actual variable names for parameters passed in.
Let's make this so for bgp_packet.h
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 78745b8700)
