| Age | Commit message (Collapse) | Author |
|---|
|
Fix static-analyser warnings with BGP labels:
> $ scan-build make -j12
> bgpd/bgp_updgrp_packet.c:819:10: warning: Access to field 'extra' results in a dereference of a null pointer (loaded from variable 'path') [core.NullDereference]
> ? &path->extra->labels->label[0]
> ^~~~~~~~~
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
Before this convertion:
```
/* --- cacheline 3 boundary (192 bytes) --- */
struct bgp_attr_encap_subtlv * encap_subtlvs; /* 192 8 */
struct bgp_attr_encap_subtlv * vnc_subtlvs; /* 200 8 */
struct bgp_route_evpn evpn_overlay; /* 208 36 */
```
After this convertion:
```
/* --- cacheline 3 boundary (192 bytes) --- */
struct bgp_attr_encap_subtlv * encap_subtlvs; /* 192 8 */
struct bgp_attr_encap_subtlv * vnc_subtlvs; /* 200 8 */
struct bgp_route_evpn * evpn_overlay; /* 208 8 */
```
Saving 28 bytes when EVPN is not used.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Move labels from extra to extra->labels. Labels are now stored in a hash
list.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
8 bits are sufficient to store the number of labels because the current
maximum is 2.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
Add bgp_path_info_num_labels() to get the number of labels stored in
a path_info structure.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
The peer_established function should be connection oriented.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
When processing an interface up/create event from zebra, we insert that
interface's MAC address into the self_mac_hash used for dropping EVPN
routes carrying a 'self mac' (RMAC ext-comm or MAC in Type-2 NLRI).
However, we were unconditionally triggering a "rescan" of the EVPN RIB
to ensure we handle routes that match the MAC - even if the MAC already
existed in self_mac_hash (i.e. the change wasn't actionable).
This adds logic to only kick off a "rescan" if the MAC learned from
zebra is not already in the self_mac_hash.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
|
|
Remove useless `return` code, and correct a spelling.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
Add a hash_clean_and_free() function as well as convert
the code to use it. This function also takes a double
pointer to the hash to set it NULL. Also it cleanly
does nothing if the pointer is NULL( as a bunch of
code tested for ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Done with a combination of regex'ing and banging my head against a wall.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
These two functions always return 0. As such any and all
tests against this make no sense. Remove the return 0
to a void and follow the chain, logically, to remove all
the dead code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Not all places were checking to see if soft reconfiguration
was turned on before calling into it to do all that work.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Gateway IP overlay index is generated for EVPN RT-5 when following CLI is
configured.
router bgp 100 vrf vrf-blue
address-family l2vpn evpn
advertise ipv4 unicast gateway-ip
advertise ipv6 unicast gateway-ip
BGP nexthop of the VRF IP/IPv6 route is set as the gateway IP of the
corresponding EVPN RT-5
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
|
|
We are inconsistently using peer_establiahed(peer) with
sometimes using `peer->status == Established`. Just Convert
over to using the function for consistency.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Convert usage of the attr->evpn_overlay to get/set functionality.
Future commits will allow us to abstract this data to when
we actually need it for the `struct attr`.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Some of the `show memory` strings in bgp are longer than the
columns we have allocated for it. Shorten some strings to
make them fit and have the output pleasing to the eye.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
This is the bulk part extracted from "bgpd: Convert from `struct
bgp_node` to `struct bgp_dest`". It should not result in any functional
change.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Add new function `bgp_node_get_prefix()` and modify
the bgp code base to use it.
This is prep work for the struct bgp_dest rework.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Future work needs the ability to specify a
const struct prefix value. Iterate into
bgp a bit to get this started.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Running with --enable-address-sanitizer I am seeing this:
=================================================================
==19520==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020003ef850 at pc 0x7fe9b8f7b57b bp 0x7fffbac6f9c0 sp 0x7fffbac6f170
READ of size 6 at 0x6020003ef850 thread T0
#0 0x7fe9b8f7b57a (/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
#1 0x55e33d1071e5 in bgp_process_mac_rescan_table bgpd/bgp_mac.c:159
#2 0x55e33d107c09 in bgp_mac_rescan_evpn_table bgpd/bgp_mac.c:252
#3 0x55e33d107e39 in bgp_mac_rescan_all_evpn_tables bgpd/bgp_mac.c:266
#4 0x55e33d108270 in bgp_mac_remove_ifp_internal bgpd/bgp_mac.c:291
#5 0x55e33d108893 in bgp_mac_del_mac_entry bgpd/bgp_mac.c:351
#6 0x55e33d21412d in bgp_ifp_down bgpd/bgp_zebra.c:257
#7 0x7fe9b8cbf3be in if_down_via_zapi lib/if.c:198
#8 0x7fe9b8db303a in zclient_interface_down lib/zclient.c:1549
#9 0x7fe9b8db8a06 in zclient_read lib/zclient.c:2693
#10 0x7fe9b8d7b95a in thread_call lib/thread.c:1599
#11 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024
#12 0x55e33d09d463 in main bgpd/bgp_main.c:477
#13 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308
#14 0x55e33d09c189 in _start (/usr/lib/frr/bgpd+0x168189)
0x6020003ef850 is located 0 bytes inside of 16-byte region [0x6020003ef850,0x6020003ef860)
freed by thread T0 here:
#0 0x7fe9b8fabfb0 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0)
#1 0x7fe9b8ce4ea9 in qfree lib/memory.c:129
#2 0x55e33d10825c in bgp_mac_remove_ifp_internal bgpd/bgp_mac.c:289
#3 0x55e33d108893 in bgp_mac_del_mac_entry bgpd/bgp_mac.c:351
#4 0x55e33d21412d in bgp_ifp_down bgpd/bgp_zebra.c:257
#5 0x7fe9b8cbf3be in if_down_via_zapi lib/if.c:198
#6 0x7fe9b8db303a in zclient_interface_down lib/zclient.c:1549
#7 0x7fe9b8db8a06 in zclient_read lib/zclient.c:2693
#8 0x7fe9b8d7b95a in thread_call lib/thread.c:1599
#9 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024
#10 0x55e33d09d463 in main bgpd/bgp_main.c:477
#11 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7fe9b8fac518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fe9b8ce4d93 in qcalloc lib/memory.c:110
#2 0x55e33d106b29 in bgp_mac_hash_alloc bgpd/bgp_mac.c:96
#3 0x7fe9b8cb8350 in hash_get lib/hash.c:149
#4 0x55e33d10845b in bgp_mac_add_mac_entry bgpd/bgp_mac.c:303
#5 0x55e33d226757 in bgp_ifp_create bgpd/bgp_zebra.c:2644
#6 0x7fe9b8cbf1e6 in if_new_via_zapi lib/if.c:176
#7 0x7fe9b8db2d3b in zclient_interface_add lib/zclient.c:1481
#8 0x7fe9b8db87f8 in zclient_read lib/zclient.c:2659
#9 0x7fe9b8d7b95a in thread_call lib/thread.c:1599
#10 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024
#11 0x55e33d09d463 in main bgpd/bgp_main.c:477
#12 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308
Effectively we are passing to bgp_mac_remove_ifp_internal the macaddr
that is associated with the bsm data structure. There exists a path
where the bsm is freed and then we immediately pass the macaddr into
bgp_mac_rescan_all_evpn_tables. So just make a copy of the macaddr
data structure before we free the bsm
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Bgp mac rescan
|
|
bgpd: skip evpn remove marked routes from rescan
|
|
The variable count was being incremented but never used.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
On interface up/down, bgp stores the mac address of the interface
in a bgp_mac_hash table entry and then initiates a rescan
of the evpn l2vpn table. The problem with this scan is that
it is looking at every item in the table when only 1 mac
has changed. So every up/down event causes some major trauma
in the bgp_update processing.
Modify the mac scanning such that we know the mac that is changed
and as such we should reprocess those entries only.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
If we get a callback for a interface change but we do not
actually have to move the mac entry in the hash then
we were accidently leaking the Mac Hash String all over
ourselves. Messy Messy!
Ticket: CM-25351
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Skip evpn routes marked for removed from rescan list
when an interface is flapped.
Ticket:CM-24933
Testing Done:
Validated in a scenario where evpn route is marked
for remove as bgp evpn withdrawal is received. Due to
link flap (frr restart of downstream router), the route
was considered for readd via bgp_update. With this
fix, the remove marked routes are skipped from update.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
|
|
It doesn't make much sense for a hash function to modify its argument,
so const the hash input.
BGP does it in a couple places, those cast away the const. Not great but
not any worse than it was.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
|
Any evpn bgp update message comes with router mac extended
community, which can potentially contain the madd adddress
same as any of the local SVIs (L3VNI) MAC address.
Set route mac exist and during route processing in
bgp_update() filter the route.
Ticket:CM-23674
Reviewed By:CCR-8336
Testing Done:
Configure L3vni mac on TORS1 which is similar to TORC11
L3vni MAC. When TORC11 received the EVPN update with
Router mac extended community, this check rejected the
BGP update message.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
|
|
Presume typo from original author
Signed-off-by: Tim Bray <tim@kooky.org>
|
|
Add some code that will reject local mac's from
being installed and add some code that will cause
a rescan when we have a local mac change.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
|
|
When a mac address is added/changed/deleted track it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Add a bit of code that allows us to dump the mac hash. Future
commits will actually add entries to the mac hash and then operate
on it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
