| Age | Commit message (Collapse) | Author |
|---|
|
Clean up -Wshadow warnings in bgp.
Signed-off-by: Mark Stapp <mjs@cisco.com>
|
|
Only call attrhash_cmp when necessary.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
The following static analysis can be seen :
> *** CID 1636504: (ARRAY_VS_SINGLETON)
> /bgpd/bgp_evpn_mh.c: 1241 in bgp_evpn_type1_route_process()
> 1235 build_evpn_type1_prefix(&p, eth_tag, &esi, vtep_ip);
> 1236 /* Process the route. */
> 1237 if (attr) {
> 1238 bgp_update(peer, (struct prefix *)&p, addpath_id, attr, afi, safi, ZEBRA_ROUTE_BGP,
> 1239 BGP_ROUTE_NORMAL, &prd, &label, num_labels, 0, NULL);
> 1240 } else {
> >>> CID 1636504: (ARRAY_VS_SINGLETON)
> >>> Passing "&label" to function "bgp_withdraw" which uses it as an array. This might corrupt or misinterpret adjacent memory locations.
> 1241 bgp_withdraw(peer, (struct prefix *)&p, addpath_id, afi, safi, ZEBRA_ROUTE_BGP,
> 1242 BGP_ROUTE_NORMAL, &prd, &label, num_labels);
> 1243 }
> 1244 return 0;
> 1245 }
> 1246
> /bgpd/bgp_evpn_mh.c: 1238 in bgp_evpn_type1_route_process()
> 1232 * table
> 1233 */
> 1234 vtep_ip.s_addr = INADDR_ANY;
> 1235 build_evpn_type1_prefix(&p, eth_tag, &esi, vtep_ip);
> 1236 /* Process the route. */
> 1237 if (attr) {
> >>> CID 1636504: (ARRAY_VS_SINGLETON)
> >>> Passing "&label" to function "bgp_update" which uses it as an array. This might corrupt or misinterpret adjacent memory locations.
> 1238 bgp_update(peer, (struct prefix *)&p, addpath_id, attr, afi, safi, ZEBRA_ROUTE_BGP,
> 1239 BGP_ROUTE_NORMAL, &prd, &label, num_labels, 0, NULL);
> 1240 } else {
> 1241 bgp_withdraw(peer, (struct prefix *)&p, addpath_id, afi, safi, ZEBRA_ROUTE_BGP,
> 1242 BGP_ROUTE_NORMAL, &prd, &label, num_labels);
> 1243 }
Fix this by declaring a label array instead of a single array.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
Remove the num_labels variable, the received bgp_update() and
bgp_withdraw() function will read the message as including one
label or vni value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
When peering with an EVPN device from other vendor, FRR acting as route
reflector is not able to read nor transmit the label value.
Actually, EVPN AD routes completely ignore the label value in the code,
whereas in some functionalities like evpn-vpws, it is authorised to
carry and propagate label value.
Fix this by handling the label value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
EVPN imported routes AF is not AF_EVPN, in that case
the path info extra with EVPN is nver created.
In order to create evpn info under path extra, define
new api which does not specifically check for AF_EVPN
afi type.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
In symmetric routing, when local ESI is down,
the MH peer learnt local mac-ip
prefix is installed into teannt vrf (given l3vni).
When ESI is back up and associated to evi/vni then
remove the local synced mac-ip imported routes from the
tenant vrf as local neigh/arp is present.
Ticket: #3878699
Testing:
peer advertised mac-ip route:
*> [2]:[0]:[48]:[aa:aa:aa:00:00:01]:[32]:[45.0.0.51] RD 27.0.0.4:9
27.0.0.4 (spine-1)
0 64435 65016 i
ESI:03:44:38:39:ff:ff:01:00:00:01
RT:65016:1000 RT:65016:4000 ET:8 Rmac:44:38:39:ff:ff:16
When local ESI is flapped
torm-11:# ip neigh show 45.0.0.51
45.0.0.51 dev vlan1000 lladdr aa:aa:aa:00:00:01 REACHABLE proto zebra
Before fix:
(The imported route remained in tenant-vrf)
torm-11:# ip route show vrf vrf1 45.0.0.51
45.0.0.51 nhid 257 proto bgp metric 20
After fix:
torm-11# ip route show vrf vrf1 45.0.0.51
torm-11#
trace:
2024/10/11 18:19:29 BGP: [JMP3T-178G8] route [2]:[0]:[48]:[00:02:00:00:00:08]:[32]:[21.1.0.5]
is matched on local esi 03:00:00:00:77:01:04:00:00:0e, uninstall from VRF tenant1 route table
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
these changes are for improving the code maintainability and readability
Signed-off-by: sri-mohan1 <sri.mohan@samsung.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>
|
|
lib, bgpd, tests, zebra: prefix_sg changes for V6 VTEP
|
|
Move labels from extra to extra->labels. Labels are now stored in a hash
list.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
Signed-off-by: Mike RE Mallin <mremallin@gmail.com>
|
|
bgp_process work
|
|
Current changes deals with EVPN routes installation to zebra.
In evpn_route_select_install() we invoke evpn_zebra_install/uninstall
which sends zclient_send_message().
This is a continuation of code changes (similar to
ccfe452763d16c432fa81fd20e805bec819b345e) but to handle evpn part
of the code.
Ticket: #3390099
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
|
|
Currently evpn code calls bgp_best_selection for local
decisions for local tables to figure out what to do.
This is also pi based so let's note that the pi has
been changed before calling bgp_best_selection.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
This will allow a consistency of approach to adding/removing
pi's to from the workqueue for processing as well as properly
handling the dest->info pi list more appropriately.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Add nexthop fied when import/unimport evpn route in vrf,
print bgp vrf instance name which contains "VRF" keyword.
Include pathcount which is list of paths linked to nexthop.
add and delete l3vni to keep symmetric "L3VNI" keyword as
used in other debug statements.
Ticket: #3671288
Testing Done:
2023/12/27 05:10:03.339616 BGP: [HPE1G-3H7F2] ... new pi VRF vrf2
dest 0x55663e8372c0 (l 2) pi 0x55663e8374d0 (l 1, f 0x4010) nh 6.0.0.1
2023/12/27 05:58:56.650116 BGP: [MC0JJ-7ZYQB] ... delete pi VRF vrf2
dest 0x55663e885110 (l 5) pi 0x55663e8851e0 (l 1, f 0x4098) nh 6.0.0.1
2023/12/27 05:10:03.339581 BGP: [P4TBX-3W31N] evpn VRF vrf2 nh
6.0.0.1 rmac 00:02:00:00:00:04 add to zebra
2023/12/27 06:13:12.685906 BGP: [SWSCZ-2Z6M4] evpn vrf VRF vrf1 nh
6.0.0.1 del to zebra
2023/12/27 05:10:03.339603 BGP: [Y2EAK-4N7FV] path 60.1.1.111/32 linked
to VRF vrf2 nh 6.0.0.1 pathcount 0
2023/12/27 05:58:56.650125 BGP: [GVE17-CSNTB] path 81.1.1.0/24 unlinked
from VRF vrf2 nh 6.0.0.1 pathcount 16
2023/12/27 05:08:10.108038 ZEBRA: [Q8ZEK-CT776] Send L3VNI ADD 104001
VRF vrf1 RMAC 00:04:ba:10:10:62 VRR 1c:34:da:19:59:62 local-ip 6.0.0.31
filter none to bgp
2023/12/27 05:08:26.043121 ZEBRA: [R43YF-2MKZ3] Send L3VNI DEL 104001
VRF vrf1 to bgp
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
This rework separates l3nhg functionality from the nexthop
tracking code, by introducing two bgp_nhg.[ch] files. The
calling functions are renamed from bgp_l3nhg* to bgp_nhg*.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
Ticket:#3597393
Testing Done:
2023-09-08T22:53:03.532 frr_bgp:evpn_withdraw_type5 {'vrf_id': 42, 'ip':
'53.1.1.0'}
2023-09-08T22:53:06.207 frr_bgp:evpn_advertise_type5 {'vrf_id': 42,
'ip': '53.1.1.0', 'rmac': '00:02:00:00:00:38', 'vtep': '27.0.0.15'}
2023-09-08T21:51:15.637 frr_bgp:evpn_mh_local_ead_es_evi_route_upd
{'esi': '03:44:38:39:ff:ff:01:00:00:03', 'vni': 1000, 'route_type': 1,
'vtep': '27.0.0.15'}
2023-09-08T20:45:17.059 frr_bgp:evpn_mh_local_ead_es_evi_route_del
{'esi': '03:44:38:39:ff:ff:01:00:00:01', 'vni': 0, 'route_type': 4,
'vtep': '27.0.0.15'}
2023-09-08T21:51:18.363 frr_bgp:evpn_mh_es_evi_vtep_add {'esi':
'03:44:38:39:ff:ff:01:00:00:02', 'vni': 1000, 'vtep': '27.0.0.16',
'ead_es': 1}
2023-09-08T20:43:50.206 frr_bgp:evpn_mh_es_evi_vtep_del {'esi':
'03:44:38:39:ff:ff:01:00:00:01', 'vni': 1002, 'vtep': '27.0.0.16',
'ead_es': 0}
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
Again the dest pointer should be still locked by the table walk. Ensure
that coverity is happy that this is not happening.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Again coverity believes that dest may be freed but it should not
be because of how locking is done. Make coverity happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
This is based on @donaldsharp's work
The current code base is the struct bgp_node data structure.
The problem with this is that it creates a bunch of
extra data per route_node.
The table structure generates ‘holder’ nodes
that are never going to receive bgp routes,
and now the memory of those nodes is allocated
as if they are a full bgp_node.
After splitting up the bgp_node into bgp_dest and route_node,
the memory of ‘holder’ node which does not have any bgp data
will be allocated as the route_node, not the bgp_node,
and the memory usage is reduced.
The memory usage of BGP node will be reduced from 200B to 96B.
The total memory usage optimization of this part is ~16.00%.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Yuqing Zhao <xiaopanghu99@163.com>
|
|
Even if some of the attributes in bgp_path_info_extra are
not used, their memory is still allocated every time. It
cause a waste of memory.
This commit code deletes all unnecessary attributes and
changes the optional attributes to pointer storage. Memory
will only be allocated when they are actually used. After
optimization, extra info related memory is reduced by about
half(~400B -> ~200B).
Signed-off-by: Valerian_He <1826906282@qq.com>
|
|
FRR "show bgp l2 evpn es <esi-id> json" output shows 'dfAlgorithm'
same as 'dfPreference' value instead of algorithm.
Modified the code to set the correct DF algorithm value into
'dfAlgorithm' field.
torm-11# show bgp l2 evpn es
ES Flags: B - bypass, L local, R remote, I inconsistent
VTEP Flags: E ESR/Type-4, A active nexthop
ESI Flags RD #VNIs
VTEPs
03:44:38:39:ff:ff:01:00:00:01 LR 27.0.0.15:15 10
27.0.0.16(EA),27.0.0.17(EA)
03:44:38:39:ff:ff:01:00:00:02 LR 27.0.0.15:16 10
27.0.0.16(EA),27.0.0.17(EA)
03:44:38:39:ff:ff:01:00:00:03 LR 27.0.0.15:17 10
27.0.0.16(EA),27.0.0.17(EA)
03:44:38:39:ff:ff:02:00:00:01 R - 10
27.0.0.18(A),27.0.0.19(A),27.0.0.20(A)
03:44:38:39:ff:ff:02:00:00:02 R - 10
27.0.0.18(A),27.0.0.19(A),27.0.0.20(A)
03:44:38:39:ff:ff:02:00:00:03 R - 10
27.0.0.18(A),27.0.0.19(A),27.0.0.20(A)
torm-11#
Before Fix:-
```
torm-11# show bgp l2 evpn es 03:44:38:39:ff:ff:01:00:00:01 json
{
"esi":"03:44:38:39:ff:ff:01:00:00:01",
"rd":"27.0.0.15:15",
"type":[
"local",
"remote"
],
"vteps":[
{
"vtep_ip":"27.0.0.16",
"flags":[
"esr",
"active"
],
"dfPreference":32767,
"dfAlgorithm":32767 =====> dfAlgorithm is same as dfPreference
},
{
"vtep_ip":"27.0.0.17",
"flags":[
"esr",
"active"
],
"dfPreference":32767,
"dfAlgorithm":32767 =====> dfAlgorithm is same as dfPreference
}
],
"flags":[
"up",
"advertiseEVI"
],
"originator_ip":"27.0.0.15",
"remoteVniCount":10,
"vrfCount":3,
"macipPathCount":33,
"macipGlobalPathCount":264,
"inconsistentVniVtepCount":0,
"localEsDfPreference":50000,
"fragments":[
{
"rd":"27.0.0.15:15",
"eviCount":10
}
]
}
torm-11#
```
After Fix:-
```
torm-11# show bgp l2vpn evpn es 03:44:38:39:ff:ff:01:00:00:01 json
{
"esi":"03:44:38:39:ff:ff:01:00:00:01",
"rd":"27.0.0.15:4",
"type":[
"local",
"remote"
],
"vteps":[
{
"vtep_ip":"27.0.0.16",
"flags":[
"esr",
"active"
],
"dfPreference":32767,
"dfAlgorithm":"preference" ---- dfAlgorithm shows properly
},
{
"vtep_ip":"27.0.0.17",
"flags":[
"esr",
"active"
],
"dfPreference":32767,
"dfAlgorithm":"preference" --- dfAlgorithm shows properly
}
],
"vniCount":10,
"flags":[
"up",
"advertiseEVI"
],
"originator_ip":"27.0.0.15",
"remoteVniCount":10,
"vrfCount":3,
"macipPathCount":33,
"macipGlobalPathCount":264,
"inconsistentVniVtepCount":0,
"localEsDfPreference":50000,
"fragments":[
{
"rd":"27.0.0.15:4",
"eviCount":10
}
]
}
torm-11#
```
Ticket:#3411912
Issue:3411912
Testing: UT done
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
|
|
bgpd:add local_es_df_preference into l2vpn-evpn es json output
|
|
Added "Local ES DF preference" into bgp l2vpn evpn es json output.
- show bgp l2vpn evpn es <es-id> json
- show bgp l2vpn evpn es detail json
Before Fix:-
```
cumulus@torm-11:mgmt:~$ sudo vtysh -c "show bgp l2vpn evpn es
03:44:38:39:ff:ff:01:00:00:01 json"
{
"esi":"03:44:38:39:ff:ff:01:00:00:01",
"rd":"27.0.0.21:15",
"type":[
"local",
"remote"
],
"vteps":[
{
"vtep_ip":"27.0.0.22",
"flags":[
"esr",
"active"
],
"dfPreference":32767,
"dfAlgorithm":32767
},
{
"vtep_ip":"27.0.0.23",
"flags":[
"esr",
"active"
],
"dfPreference":32767,
"dfAlgorithm":32767
}
],
"vniCount":10,
"flags":[
"up",
"advertiseEVI"
],
"originator_ip":"27.0.0.21",
"remoteVniCount":10,
"vrfCount":3,
"macipPathCount":33,
"macipGlobalPathCount":132,
"inconsistentVniVtepCount":0,
"fragments":[
{
"rd":"27.0.0.21:15",
"eviCount":10
}
]
}
cumulus@torm-11:mgmt:~$
```
After Fix:-
```
cumulus@torm-11:mgmt:~$
cumulus@torm-11:mgmt:~$ sudo vtysh -c "show bgp l2vpn evpn es
03:44:38:39:ff:ff:01:00:00:01 json"
{
"esi":"03:44:38:39:ff:ff:01:00:00:01",
"rd":"27.0.0.21:4",
"type":[
"local",
"remote"
],
"vteps":[
{
"vtep_ip":"27.0.0.22",
"flags":[
"esr",
"active"
],
"dfPreference":32767,
"dfAlgorithm":32767
},
{
"vtep_ip":"27.0.0.23",
"flags":[
"esr",
"active"
],
"dfPreference":32767,
"dfAlgorithm":32767
}
],
"vniCount":10,
"flags":[
"advertiseEVI"
],
"originator_ip":"27.0.0.21",
"remoteVniCount":10,
"vrfCount":3,
"macipPathCount":33,
"macipGlobalPathCount":132,
"inconsistentVniVtepCount":0,
"localEsDfPreference":50000, ====> Added Local ES DF preference
"fragments":[
{
"rd":"27.0.0.21:4",
"eviCount":10
}
]
}
cumulus@torm-11:mgmt:~$
```
Ticket:#3411906
Issue:3411906
Testing: UT done
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
|
|
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>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.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>
|
|
Crash:
(gdb) bt
0 0x00007fee27de15cb in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
1 0x00007fee280ecd9c in core_handler (signo=11, siginfo=0x7ffe56001bb0, context=<optimized out>) at lib/sigevent.c:264
2 <signal handler called>
3 0x0000555e321c41b2 in prefix_rd2str (prd=0x10, buf=buf@entry=0x7ffe56002080 "27.0.0.R\340\373\062\062^U", size=size@entry=28) at bgpd/bgp_rd.c:168
4 0x0000555e321c431a in printfrr_prd (buf=0x7ffe560021a0, ea=<optimized out>, ptr=<optimized out>) at bgpd/bgp_rd.c:224
5 0x00007fee2812069b in vbprintfrr (cb_in=cb_in@entry=0x7ffe56002330, fmt0=fmt0@entry=0x555e3229a3ad " RD: %pRD\n", ap=ap@entry=0x7ffe560023d8) at lib/printf/vfprintf.c:564
6 0x00007fee28122ef7 in vasnprintfrr (mt=mt@entry=0x7fee281cb5e0 <MTYPE_VTY_OUT_BUF>, out=out@entry=0x7ffe560023f0 " RD: : R\n", outsz=outsz@entry=1024, fmt=fmt@entry=0x555e3229a3ad " RD: %pRD\n", ap=ap@entry=0x7ffe560023d8) at lib/printf/glue.c:103
7 0x00007fee28103504 in vty_out (vty=vty@entry=0x555e33f82d10, format=format@entry=0x555e3229a3ad " RD: %pRD\n") at lib/vty.c:190
8 0x0000555e32185156 in bgp_evpn_es_show_entry_detail (vty=0x555e33f82d10, es=0x555e33c38420, json=<optimized out>) at bgpd/bgp_evpn_mh.c:2655
9 0x0000555e32188fe5 in bgp_evpn_es_show (vty=vty@entry=0x555e33f82d10, uj=false, detail=true) at bgpd/bgp_evpn_mh.c:2721
notice prd=0x10 in #3. This is because in bgp_evpn_mh.c we are sending &es->es_base_frag->prd.
There is one spot in the code where during output the es->es_base_frag is checked for non nullness
Let's just make sure it's right in all the places.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Not used.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
bgpd: Drop struct attr from bgp_withdraw()
|
|
lib, bgp: add initial support for asdot format
|
|
It's not used at all.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
*: convert to SPDX License identifiers
|
|
Disable the use of NHGs with D-VNI for now. We don't support them.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
The bgp_evpn_es_evi_show_entry() function tries to access the vni
attribute, while the vpn structure may be null.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
RD may be built based on an AS number. Like for the AS, the RD
may use the AS notation. The two below examples can illustrate:
RD 1.1:20 stands for an AS4B:NN RD with AS4B=65536 in dot format.
RD 0.1:20 stands for an AS2B:NNNN RD with AS2B=0.1 in dot+ format.
This commit adds the asnotation mode to prefix_rd2str() API so as
to pick up the relevant display.
Two new printfrr extensions are available to display the RD with
the two above display methods.
- The pRDD extension stands for dot asnotation format
- The pRDE extension stands for dot+ asnotation format.
- The pRD extension has been renamed to pRDP extension
The code is changed each time '%pRD' printf extension is called.
Possibly, the asnotation may change the output, then a macro defines
the asnotation mode to use. A side effect of forging the mode to
use is that the string could not be concatenated with other strings
in vty_out and snprintfrr. Those functions have been called multiple
times. When zlog_debug needs to display the RD with some other string,
the prefix_rd2str() old API is used instead of the printf extension.
Some code has been kept untouched:
- code related to running-config. Actually, wherever an RD is displayed,
its configured name should be dumped.
- bgp rfapi code
- bgp evpn multihoming code (partially done), since the logic is
missing to get the asnotation of 'struct bgp_evpn_es'.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.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>
|
|
The default vrf in bgp when created, ends up having the
bgp->name as NULL. This of course crashes the ilk
of `json_object_string_add` when a NULL is passed in.
Go through all the places in bgp_evpn_mh.c and fix
so that it doesn't crash.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Use %pI4/%pI6 where possible, otherwise at least atjust stack buffer sizes
for inet_ntop() calls.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Re-work the bgp vni table to use separately keyed tables for type2
routes.
So, with type2 routes, we have the main table keyed off of the IP and a
new MAC table keyed off of MACs.
By separating out the two, we are able to run path selection separately
for the neigh and mac. Keeping the two separate is also more in-line
with what happens in zebra (they are managed comptletely seperate).
With this change type2 routes go into each table like so:
```
Remote MAC-IP -> IP Table & MAC Table
Remote MAC -> MAC Table
Local MAC-IP -> IP Table
Local MAC -> MAC Table
```
The difference for local is necessary because we should not ever allow
multiple paths for a local MAC.
Also cleaned up the commands for querying the vni tables:
```
show bgp vni all type ...
show bgp vni VNI type ...
```
Old commands will be deprecated in a separate commit.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Use the IP addr of type2/macip routes only for the hash/key
of the VNI table and carry the MAC in a path_info_extra attribute.
There is exists situations that can be hit during extended MAC mobility events
where two MACs could be pointing to the same IP in our global table. It
is requires very specific timings.
When that happens, BPG would (because we key'd on both MAC and IP)
install both into it's VNI table as separate entries, but zebra only
knows/needs to know about a single IP -> MAC relationship for it's VNI
table's type2 routes. So it was compleletly undeterministic which one
zebra would end up with in these timing situations.
With these changes, we move BGP's VNI table to key'd the same as Zebra's
and now a single IP will have multiple path_info's with a path_info_extra
that is carrying the MAC info for each path.
BGP will then run best path to deterministically decide which one to send to
zebra during the occasions where there exist's two possible MACs.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Convert a bunch of prefix_rd2str() for json/vty stuff.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
