```
anlan(config-router-af)# vni 33
anlan(config-router-af-vni)# route-target both 44:55
anlan(config-router-af-vni)# no route-target both 44:55
vtysh: error reading from bgpd: Resource temporarily unavailable (11)Warning: closing connection to bgpd because of an I/O error!
```
When `bgp_evpn_vni_rt_cmd` deals with "both" type, it wrongly created
only one node ( should be two nodes ) for lists of both `vpn->import_rtl` and
`vpn->export_rtl`. At this time, the two lists are already wrong.
In `no route-target both RT`, it will free the single node from lists of both
`vpn->import_rtl` and `vpn->export_rtl`. After freed from `vpn->import_rtl`,
it is "use-after-free" at the time of freeing it from `vpn->export_rtl`.
It causes crash sometimes, or other unexpected behaviours.
This issue is introduced by commit `3b7e8d`, which have adjusted both
`bgp_evpn_vni_rt_cmd` and `bgp_evpn_vrf_rt_cmd`.
Since `bgp_evpn_vrf_rt_cmd/no_bgp_evpn_vrf_rt_cmd` works well again
unintentionally with commit `7022da`, only `bgp_evpn_vni_rt_cmd` needs to
modify - add two nodes for "both" type and some explicit comments for this
special case of "both" type.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Commit: 3cdb03fba7
changed the vty_json output to not be pretty printing.
The previous commit in the tree added vty_json_no_pretty
let's use that instead
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
For BGP evpn route table detail json to use
non pretty form of display.
Problem:
In scaled evpn route table detail json dump
occupies high resources (CPU + memory) of the system.
In high scale evpn route dump using pretty form
hogs CPU for a while which can trigger watchfrr
to kill bgpd.
Solution:
Avoid pretty JSON print for detail version dump
Signed-off-by: Chirag Shah <chirag@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>
In the case of without ':' in `ecom_str`, memleak on this `ecom_str` will
occur. Just free `ecom_str` for this case.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Rather than running selected source files through the preprocessor and a
bunch of perl regex'ing to get the list of all DEFUNs, use the data
collected in frr.xref.
This not only eliminates issues we've been having with preprocessor
failures due to nonexistent header files, but is also much faster.
Where extract.pl would take 5s, this now finishes in 0.2s. And since
this is a non-parallelizable build step towards the end of the build
(dependent on a lot of other things being done already), the speedup is
actually noticeable.
Also files containing CLI no longer need to be listed in `vtysh_scan`
since the .xref data covers everything. `#ifndef VTYSH_EXTRACT_PL`
checks are equally obsolete.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The "RTLIST..." list should be maintained integrity. If wildcard check
failed, it should immediately return failure. Otherwise user configuration
will be partial.
```
anlan(config-router-af)# route-target export *:55 33:33
% Wildcard '*' only applicable for import
anlan(config-router-af)# route-target both *:55 33:33
% Wildcard '*' only applicable for import
```
With this commit, the RTs without wildcard will not be executed as before. And
the same for `no` form.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Fix the vni_str NULL check for wildcard route-targets
in evpn show run. This will never be NULL if we add 1
here. Though it should also never be NULL since ":" should
always exist. Better to be safe than sorry.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add add show bgp vni <VNI|all> json commands.
This is very similar to the old `show bgp evpn l2vpn vni route json`
commands but adds a new `macTable` object under the normal output.
This may change in the future but doing it like this for now
VNI ALL:
```
{
"1002":{
"vni":1002,
"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]":{
"prefix":"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
...
...
...
"numPrefix":4,
"numPaths":7,
"macTable":{
"[2]:[0]:[48]:[00:02:00:00:00:09]":{
"prefix":"[2]:[0]:[48]:[00:02:00:00:00:09]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
```
VNI 1002:
```
{
"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]":{
"prefix":"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
...
...
...
"numPrefix":4,
"numPaths":7,
"macTable":{
"[2]:[0]:[48]:[00:02:00:00:00:09]":{
"prefix":"[2]:[0]:[48]:[00:02:00:00:00:09]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
```
Signed-off-by: Stephen Worley <sworley@nvidia.com>
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>
Add route-map as a possible word for the `no` form
of `advertise ipvX *** [route-map WORD] cmd.
Before this patch the cmd was only accepted if `no` form
was given without route-map WORD. So if you just copypaste
the original version of the cmd, it would fail.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Implement forcing L3 auto derivation via configs even when
manually RTs are set. This will allow both to coexist in
BGP RTs. Without using auto config command, it will remove
auto derived RTs when you manually configure your own. To allow
both, use the auto command ond import/export/both.
Implement '*' wildcard import L3 RTs so we can import a route into any AS.
This is necessary to avoid a user from having to configure an L3 RT for
every AS they care to import evpn route from.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Abstract the ecommunity into a container struct for L3
route targets so that we can add some additional info
via flags to go along with RT configs without modifying
the used elsewhere ecommunity struct. This functions as a
wrapper everywhere its used including the import/export lists.
The flags will be used in later commits to change behavior
when importing/exporting routes.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add functionality to allow EVPN L3 RTs to be configured via
a list rather than one at a time.
Also add boilerplate config for forcing auto derivation of RTs
via config.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Instead of changing the value of 'BUM flooding' field in
'show bgp l2vpn evpn vni' vty and JSON command from
'Head-end replication' to 'enabled', adding a new field named
'vxlanFlooding' to 'show bgp l2vpn evpn vni' vty and JSON output.
This is done to maintain backward compatibility.'BUM flooding' field
in vty and JSON output will be deprecated later.
Signed-off-by: Pooja Doijode <pdoijode@nvidia.com>
bgpd was crashing every time `show bgp l2vpn evpn route rd` was issued
with an RD that didn't match "all". This was introduced by 9b01d28988
which changed how argv_find() is handled in various vtysh commands, but
the new changes forgot a "!". So let's re-add the "!".
Before:
```
ub20# show bgp l2vpn evpn route rd 399672:100
vtysh: error reading from bgpd: Resource temporarily unavailable (11)Warning: closing connection to bgpd because of an I/O error!
ub20#
ub20# show bgp l2vpn evpn route rd 399672:100 mac 11:11:11:11:11:11
vtysh: error reading from bgpd: Resource temporarily unavailable (11)Warning: closing connection to bgpd because of an I/O error!
ub20#
```
After:
```
ub20# show bgp l2vpn evpn route rd 399672:100
ub20#
ub20# show bgp l2vpn evpn route rd 399672:100 mac 11:11:11:11:11:11
% Network not in table
ub20#
```
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
When `bgp_evpn_new()` is called, the `bgp` parameter MUST be non-NULL,
remove this unnecessary check and remove the NULL check for returned
`struct bgpevpn *`, which should be non-NULL.
And modify `import_rt_new()` in the same way.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Currently the warning is wrong:
```
root#show bgp vrf default vni
BGP instance for VRF default not foundACC1(config)#
```
Two changes for "show bgp vrf VRFNAME vni [json]":
- Correct the default VRF check
- Add newline for warning
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Small simplification for evpn RT commands, i.e. both per-VRF
and per-VNI - `bgp_evpn_vrf_rt_cmd` and `bgp_evpn_vni_rt_cmd`.
Just extract the duplicated code as a common code, there are
no functional changes.
Additionally correct one comment for `ecommunity_free()`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
The EAD-per-ES route can be fragmented to fit the EVIs on the switch. This
command allows the EVI limit to be configured -
!
router bgp 5556
!
address-family l2vpn evpn
ead-es-frag evi-limit 200
exit-address-family
!
!
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
The EAD-per-ES route carries ECs for all the ES-EVI RTs. As the number of VNIs
increase all RTs do not fit into a standard BGP UPDATE (4K) so the route needs
to be fragmented.
Each fragment is associated with a separate RD and frag-id -
1. Local ES-per-EAD -
ES route table - {ES-frag-ID, ESI, ET=0xffffffff, VTEP-IP}
global route table - {RD-=ES-frag-RD, ESI, ET=0xffffffff}
2. Remote ES-per-EAD -
VNI route table - {ESI, ET=0xffffffff, VTEP-IP}
global route table - {RD-=ES-frag-RD, ESI, ET=0xffffffff}
Note: The fragment ID is abandoned in the per-VNI routing table. At this
point that is acceptable as we dont expect more than one-ES-per-EAD fragment
to be imported into the per-VNI routing table. But that may need to be
re-worked at a later point.
CLI changes (sample with 4 VNIs per-fragment for experimental pruposes) -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
root@torm-11:mgmt:~# vtysh -c "show bgp l2vpn evpn es 03:44:38:39:ff:ff:01:00:00:01"
ESI: 03:44:38:39:ff:ff:01:00:00:01
Type: LR
RD: 27.0.0.21:3
Originator-IP: 27.0.0.21
Local ES DF preference: 50000
VNI Count: 10
Remote VNI Count: 10
VRF Count: 3
MACIP EVI Path Count: 33
MACIP Global Path Count: 198
Inconsistent VNI VTEP Count: 0
Inconsistencies: -
Fragments: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
27.0.0.21:3 EVIs: 4
27.0.0.21:13 EVIs: 4
27.0.0.21:22 EVIs: 2
VTEPs:
27.0.0.22 flags: EA df_alg: preference df_pref: 32767
27.0.0.23 flags: EA df_alg: preference df_pref: 32767
root@torm-11:mgmt:~# vtysh -c "show bgp l2vpn evpn es-evi vni 1002 detail"
VNI: 1002 ESI: 03:44:38:39:ff:ff:01:00:00:01
Type: LR
ES fragment RD: 27.0.0.21:13 >>>>>>>>>>>>>>>>>>>>>>>>>
Inconsistencies: -
VTEPs: 27.0.0.22(EV),27.0.0.23(EV)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
PS: The number of EVIs per-fragment has been set to 128 and may need further
tuning.
Ticket: #2632967
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
This is an alternate to EAD route fragmenation and allows the user to limit
the route to a single UPDATE (<4K) independent of the number of EVIs.
Sample config (add one l2-vni RT from each VRF) -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
!
router bgp 5556
!
address-family l2vpn evpn
ead-es-route-target export 5556:1001
ead-es-route-target export 5556:1004
ead-es-route-target export 5556:1008
exit-address-family
!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Sample route
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Network Next Hop Metric LocPrf Weight Path
*> [1]:[4294967295]:[03:44:38:39:ff:ff:01:00:00:01]:[32]:[27.0.0.21]
27.0.0.21 32768 i
ET:8 ESI-label-Rt:AA RT:5556:1001 RT:5556:1004 RT:5556:1008
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
When configured, the ead-es-route-target is used instead of
the auto-generated version that includes all associated EVI's RTs.
Ticket: #2632967
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
Before:
(config-router-af)# advertise-all-vni
% Please unconfigure EVPN in VRF (null)
After:
(config-router-af)# advertise-all-vni
% Please unconfigure EVPN in VRF default
Just use `bgp->name_pretty` to make it pretty.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
