| Age | Commit message (Collapse) | Author |
|---|
|
Upon zebra shutdown hash_clean_and_free is called
where user free function is passed,
The free function should not call hash_release
which lead to double free of hash bucket.
Fix:
The fix is to avoid calling hash_release from
free function if its called from hash_clean_and_free
path.
10 0x00007f0422b7df1f in free () from /lib/x86_64-linux-gnu/libc.so.6
11 0x00007f0422edd779 in qfree (mt=0x7f0423047ca0 <MTYPE_HASH_BUCKET>,
ptr=0x55fc8bc81980) at ../lib/memory.c:130
12 0x00007f0422eb97e2 in hash_clean (hash=0x55fc8b979a60,
free_func=0x55fc8a529478 <svd_nh_del_terminate>) at
../lib/hash.c:290
13 0x00007f0422eb98a1 in hash_clean_and_free (hash=0x55fc8a675920
<svd_nh_table>, free_func=0x55fc8a529478 <svd_nh_del_terminate>) at
../lib/hash.c:305
14 0x000055fc8a5323a5 in zebra_vxlan_terminate () at
../zebra/zebra_vxlan.c:6099
15 0x000055fc8a4c9227 in zebra_router_terminate () at
../zebra/zebra_router.c:276
16 0x000055fc8a4413b3 in zebra_finalize (dummy=0x7fffb881c1d0) at
../zebra/main.c:269
17 0x00007f0422f44387 in event_call (thread=0x7fffb881c1d0) at
../lib/event.c:2011
18 0x00007f0422ecb6fa in frr_run (master=0x55fc8b733cb0) at
../lib/libfrr.c:1243
19 0x000055fc8a441987 in main (argc=14, argv=0x7fffb881c4a8) at
../zebra/main.c:584
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 1d4f5b9b19588d77d3eaf06440c26a8c974831a3)
|
|
In the context of SVD (Single VxLAN Device) for L3VNI,
the remote VTEP's nexthop is programmed neighbor entry against
SVD along with neighbor entry against SVI.
However, when L3VNI is removed or the VRF is disabled, all SVI
based remote nexthop neighbors are uninstalled and deleted.
The SVD based neigh entries remains in Zebra and the Kernel.
Subsequently, when reconfiguring L3VNI and relearning the same nexthop,
the neighbor entry is not programmed is because it is not removed
from Zebra SVD neighbor hash table, leading to the failure to
reprogram the entry.
With this fix, the SVD nexthop neigh entry is uninstalled
and deleted from Zebra and Kernel.
Ticket: #3729045
Testing:
borderleaf:# ip neigh show 2.2.2.2
2.2.2.2 dev vlan2560_l3 lladdr 00:01:00:00:1d:09 extern_learn NOARP proto zebra
2.2.2.2 dev vxlan99 lladdr 00:01:00:00:1d:09 extern_learn NOARP proto zebra
With the fix:
Zebra log shows both enties SVD (vxlan99) and SVI (vlan2560_l3)
neighbor entries are deleted.
2024/05/03 18:41:33.527125 ZEBRA: [NH6N7-54CD1] Tx RTM_DELNEIGH family
ipv4 IF vxlan99(16) Neigh 2.2.2.2 MAC null flags 0x10 state 0x0
ext_flags 0x0
2024/05/03 18:41:33.527128 ZEBRA: [NH6N7-54CD1] Tx RTM_DELNEIGH family
ipv4 IF vlan2560_l3(18) Neigh 2.2.2.2 MAC null flags 0x10 state 0x0
ext_flags 0x0
borderleaf:# ip neigh show 2.2.2.2
borderleaf:#
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit fde6dd7bb9161cf58fdd8ca066cce77bad159c9d)
|
|
Whenever a link up change was detected on a macvlan device where
the linked device wasn't visible in the namespace zebra was
running in, the linked zebra interface was NULL. This was already
handled in the event of a link down, but was ommitted from the
upside. Added the same null check to the up-side.
Signed-off-by: Tomi Salminen <tlsalmin@gmail.com>
(cherry picked from commit bdf6a9ba810b58146371e8a0000397d2ae9ea956)
|
|
A macvlan interface can have its underlying link-interface in another
namespace (aka. netns). However, by default, zebra does not know the
interface from the other namespaces. It results in a crash the pointer
to the link interface is NULL.
> 6 0x0000559d77a329d3 in zebra_vxlan_macvlan_up (ifp=0x559d798b8e00) at /root/frr/zebra/zebra_vxlan.c:4676
> 4676 link_zif = link_ifp->info;
> (gdb) list
> 4671 struct interface *link_ifp, *link_if;
> 4672
> 4673 zif = ifp->info;
> 4674 assert(zif);
> 4675 link_ifp = zif->link;
> 4676 link_zif = link_ifp->info;
> 4677 assert(link_zif);
> 4678
> (gdb) p zif->link
> $2 = (struct interface *) 0x0
> (gdb) p zif->link_ifindex
> $3 = 15
Fix the crash by returning when the macvlan link-interface is in another
namespace. No need to go further because any vxlan under the macvlan
interface would not be accessible by zebra.
Link: https://github.com/FRRouting/frr/issues/15370
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 44e6e3868d7a1488447f2be446dbd7cb5a5559ce)
|
|
- unnecessary command duplication
- usage of oper data during validation
- unnecessary checks for things that can't happen
Signed-off-by: Igor Ryzhov <iryzhov@nfware.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>
|
|
zebra:returns empty dict when evpn is disabled II
|
|
This is addressing remaining places returning
empty dict, earlier PR-13214 addressed few places.
Code has been changed to return {} for all the evpn clis
when evpn is disabled or no entry available.
```
cumulus@r2:mgmt:~$ sudo vtysh -c "show evpn json"
cumulus@r2:mgmt:~$
```
After Fix:-
```
cumulus@r1:mgmt:~$ sudo vtysh -c "show evpn json"
{
}
cumulus@r1:mgmt:~$
```
Ticket:#3417955
Issue:3417955
Testing: UT done
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
Currently, json output of evpn route command are no pretty format.
This is an extremely expensive operation at high VNI scale
EVPN json non-pretty command support added:
```
show evpn mac vni <vni-id> detail json
show evpn vni detail json
```
Ticket:#3513256
Issue:3513256
Testing: UT done
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
|
|
zebra:unlock node after route_next
|
|
When route_next return node, it has lock the node. if return or break loop, should unlock node.
Signed-off-by: guozhongfeng <guozhongfeng.gzf@alibaba-inc.com>
|
|
The default vrf is generally non-NULL, except when shutdown. So, most
of the time it is not necessary to check if it is NULL, we should
remove the useless checks for it.
Searched them with exact match:
```
grep -rI "zebra_vrf_lookup_by_id(VRF_DEFAULT)" | wc -l
31
```
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
EVPN RMAC (Router MAC) nexthop list compare
function needs to return all values so
the list element can be compared and added/deleted
properly.
Ticket:#3486989
Testing Done:
Originate EVPN Type-5 route with PIP IP and MAC as remote
nexthops.
Change the PIP IP address which triggers nexthop change.
Before fix:
When PIP IP changes RMAC is deleted from remote VTEPs.
TORS1# show evpn next-hops vni 4001 | include 00:02:00:00:00:2d
27.0.0.11 00:02:00:00:00:2d
TORS1# show evpn rmac vni 4001 | include 00:02:00:00:00:2d
00:02:00:00:00:2d 27.0.0.11
----- Remote VTEP change nexthop IP to 172.16.16.16 -----
TORS1# show evpn next-hops vni 4001 | include 00:02:00:00:00:2d
172.16.16.16 00:02:00:00:00:2d
TORS1# show evpn rmac vni 4001 | include 00:02:00:00:00:2d
TORS1#
After fix:
RMAC is retained as its nexthop list is not empty,
thus it is not deleted from remote VTEPs.
TORS1# show evpn rmac vni 4001 | include 00:02:00:00:00:2d
00:02:00:00:00:2d 172.16.16.16
Log:
2023/06/27 00:50:36.833474 ZEBRA: [XREH0-ZYMH6] L3VNI 4001 Remote VTEP
change(27.0.0.11 -> 172.16.16.16) for RMAC 00:02:00:00:00:2d
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
"show evpn json" returns nothing when evpn is disabled.
Code has been fixed to return {} when evpn is disabled or no entry
available.
Before Fix:-
```
cumulus@r2:mgmt:~$ sudo vtysh -c "show evpn json"
cumulus@r2:mgmt:~$
```
After Fix:-
```
cumulus@r1:mgmt:~$ sudo vtysh -c "show evpn json"
{
}
cumulus@r1:mgmt:~$
```
Ticket:#3417955
Issue:3417955
Testing: UT done
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Signed-off-by: Sindhu Parvathi Gopinathan <sgopinathan@nvidia.com>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Added "isDetectionFreeze" for show evpn json output to identify the
default and freeze permanent config.
Before fix:-
```
tor-2(config)# router bgp 65561
tor-2(config-router)# address-family l2vpn evpn
<cr>
tor-2(config-router)# address-family l2vpn evpn
tor-2(config-router-af)# dup-addr-detection freeze permanent
tor-2(config-router-af)# do show evpn
L2 VNIs: 21
L3 VNIs: 5
Advertise gateway mac-ip: No
Advertise svi mac-ip: No
Advertise svi mac: No
Duplicate address detection: Enable
Detection max-moves 5, time 180
Detection freeze permanent
EVPN MH:
mac-holdtime: 1080s, neigh-holdtime: 1080s
startup-delay: 180s, start-delay-timer: --:--:--
uplink-cfg-cnt: 0, uplink-active-cnt: 0
tor-2(config-router-af)#
tor-2(config-router-af)# do show evpn json
{
"advertiseGatewayMacip":"No",
"advertiseSviMacip":"No",
"advertiseSviMac":"No",
"numVnis":26,
"numL2Vnis":21,
"numL3Vnis":5,
"isDuplicateAddrDetection":true,
"maxMoves":5,
"detectionTime":180,
"detectionFreezeTime":0,
"macHoldtime":1080,
"neighHoldtime":1080,
"startupDelay":180,
"startupDelayTimer":"--:--:--",
"uplinkConfigCount":0,
"uplinkActiveCount":0
}
tor-2(config-router-af)#
```
After fix:-
```
cumulus@tor-1:mgmt:~$ sudo vtysh -c "show evpn json"
{
"advertiseGatewayMacip":"No",
"advertiseSviMacip":"No",
"advertiseSviMac":"No",
"numVnis":26,
"numL2Vnis":21,
"numL3Vnis":5,
"isDuplicateAddrDetection":true,
"maxMoves":5,
"detectionTime":180,
"detectionFreezeTime":0, ==> default case , i.e dad_freeze duration is 0
"isDetectionFreeze":false, ==> default case, i.e. dad_freeze disabled
"macHoldtime":1080,
"neighHoldtime":1080,
"startupDelay":180,
"startupDelayTimer":"--:--:--",
"uplinkConfigCount":0,
"uplinkActiveCount":0
}
cumulus@tor-1:mgmt:~$
tor-1(config-router-af)# dup-addr-detection freeze permanent
tor-1(config-router-af)# do show evpn json
{
"advertiseGatewayMacip":"No",
"advertiseSviMacip":"No",
"advertiseSviMac":"No",
"numVnis":26,
"numL2Vnis":21,
"numL3Vnis":5,
"isDuplicateAddrDetection":true,
"maxMoves":5,
"detectionTime":180,
"detectionFreezeTime":0, ==> dad_freeze with duration permanent
"isDetectionFreeze":true, ==> dad_freeze enabled
"macHoldtime":1080,
"neighHoldtime":1080,
"startupDelay":180,
"startupDelayTimer":"00:00:08",
"uplinkConfigCount":0,
"uplinkActiveCount":0,
"protodownReasons":[
"startupDelay"
]
}
tor-1(config-router-af)#
tor-1(config-router-af)# dup-addr-detection freeze 400
tor-1(config-router-af)#
tor-1(config-router-af)# do show evpn json
{
"advertiseGatewayMacip":"No",
"advertiseSviMacip":"No",
"advertiseSviMac":"No",
"numVnis":26,
"numL2Vnis":21,
"numL3Vnis":5,
"isDuplicateAddrDetection":true,
"maxMoves":5,
"detectionTime":180,
"detectionFreezeTime":400, ==> dad_freeze duration with numeric value
"isDetectionFreeze":true, ==> dad_freeze enabled
"macHoldtime":1080,
"neighHoldtime":1080,
"startupDelay":180,
"startupDelayTimer":"00:00:47",
"uplinkConfigCount":0,
"uplinkActiveCount":0,
"protodownReasons":[
"startupDelay"
]
}
tor-1(config-router-af)# no dup-addr-detection freeze permanent
tor-1(config-router-af)# do show evpn json
{
"advertiseGatewayMacip":"No",
"advertiseSviMacip":"No",
"advertiseSviMac":"No",
"numVnis":26,
"numL2Vnis":21,
"numL3Vnis":5,
"isDuplicateAddrDetection":true,
"maxMoves":5,
"detectionTime":180,
"detectionFreezeTime":0, ==> no dad_freeze duration
"isDetectionFreeze":false, ==> no dad_freeze enabled
"macHoldtime":1080,
"neighHoldtime":1080,
"startupDelay":180,
"startupDelayTimer":"--:--:--",
"uplinkConfigCount":0,
"uplinkActiveCount":0
}
tor-1(config-router-af)#
```
Ticket:#3404283
Issue:3404283
Testing: UT done
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
|
|
*: convert to SPDX License identifiers
|
|
clang-format style fixes
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Use new vni_info->access_vlan struct accessors
for network mac add code.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
The `show evpn next-hop svd *` command doesn't provide much
for users right now. Make it hidden so we can still debug
the tables with it.
Also remove SVD output from `show evpn next-hop vni all`.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Add some show commands and expand some already existing
commands so we can get debug info from the SVD global
neigh table inside zebra.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Install neigh entries always on SVD if it exists in
zebra. If zebra is using a Single Vxlan Device, we must
duplicate the install of our neigh entries to it so that
vxlan communication can also work across it in the downstream VNI
case.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Check for vni before doing comparion during vxlan vni search in zl3vni_map_to_vxlan_if_ns
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
|
|
vni removal
This patch addresses following issues,
- When the VLAN-VNI mapping is configured via a map and not using
individual VXLAN interfaces, upon removal of a VNI ensure that the
remote FDB entries are uninstalled correctly.
- When VNI configuration is performed using VLAN-VNI mapping (i.e., without
individual VXLAN interfaces) and flooded traffic is handled via multicast,
the multicast group corresponding to the VNI needs to be explicitly read
from the bridge FDB. This is relevant in the case of netlink interface to
the kernel and for the scenario where a new VNI is provisioned or comes up.
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
|
|
This patch addresses following
- Remove unused VLAN Id parameter when trying to determine the VNI associated
with a non-VLAN aware bridge. Also, add a check to ensure that in this case,
we have a per-VNI VXLAN interface. Due to sequence of events, it is possible
that we may have VLAN-VNI mappings, in which case the code should return
gracefully.
- With support for a container VXLAN interface that has VLAN-VNI mappings,
the VXLAN interface itself may be up but a particular VNI might have
been removed. Ensure that VNI mapping exists before proceeding with
further processing.
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
|
|
zl3vni_from_svi
Today to find the vni for a given (vlan, bridge) we walk over all interfaces
and filter the vxlan device associated with the bridge. With multiple vlan aware
bridge changes, we can derive the vni directly by looking up the hash table i.e.
the vlan_table of the associated (vlan, bridge) which would give the vni.
During vrf_terminate() call zebra_l2_bridge_if_cleanup if the interface
that we are removing is of type bridge. In this case, we walk over all
the vlan<->access_bd association and clean them up.
zebra_evpn_t is modified to record (vlan, bridge) details and the
corresponding vty is modified to print the same.
zevpn_bridge_if_set and zl3vni_bridge_if_set is used to set/unset the
association.
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
|
|
This change brings in following functionality
- netlink_bridge_vxlan_vlan_vni_map_update for single vxlan devices
This function is responsible for reading the vlan-vni map information
received from netlink and populating a new hash_table with the vlan-vni
data. Once all the vlan-vni data is collected, zebra_vxlan_if_vni_table_add_update
is called to update vni_table in vxlan interface and process each of the
vlan-vni data.
- refactoring changes for zevpn_build_hash_table
- existing zevpn_build_hash_table was walking over all the vxlan interfaces
and then processing the vni for each of them. In case of single vxlan device,
we will have more than one vni entries. This function is abstracted so that
it iterates over all the vni entries for single vxlan device. For traditional
vxlan device the zebra_vxlan_if_vni_iterate would only process single vni
associated with that device.
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
|
|
This change refactors the zebra_vxlan_if related functionality
to a new zebra_vxlan_if.c file. zebra_vxlan_if_up/down,
zebra_vxlan_if_add/update/del is moved zebra_vxlan_if.c
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
|
|
dplane_mac_info and dplane_neigh_info is modified to be vni aware.
dplane_rem_mac_add/del dplane_mac_init is modified to be vni aware.
During dplane context update (mac and neigh), we use the vni information
and if set, corresponding netlink attribute NDA_SRC_VNI is set and passed to the
dplane.
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
|
|
iftype derivation from netlink
This change set introduces data structure changes required for multiple vlan aware bridge
functionality. A new structure zebra_l2_bridge_if encapsulates the vlan to access_bd
association of the bridge. A vlan_table hash_table is used to record each instance
of the vlan to access_bd of the bridge via zebra_l2_bridge_vlan structure.
vxlan iftype derivation: netlink attribute IFLA_VXLAN_COLLECT_METADATA is used
to derive the iftype of the vxlan device. If the attribute is present, then the
vxlan interface is treated as single vxlan device, otherwise it would default to
traditional vxlan device.
zebra_vxlan_check_readd_vtep, zebra_vxlan_dp_network_mac_add/del is modified to
be vni aware.
mac_fdb_read_for_bridge - is modified to be (vlan, bridge) aware
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
|
|
This changeset introduces the data structure changes needed for
single vxlan device functionality. A new struct zebra_vxlan_vni_info
encodes the iftype and vni information for vxlan device.
The change addresses related access changes of the new data structure
fields from different files
zebra_vty is modified to take care of the vni dump information according
to the new vni data structure for vxlan devices.
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
|
|
Done with a combination of regex'ing and banging my head against a wall.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
zebra: fix JSON fields for show evpn vni detail
|
|
Few of the JSON field in show evpn vni detail command is
confusing and a few fields were missing. Following is the
updated output.
primary# show evpn vni detail json
[
{
"vni":200,
"type":"L2",
"vrf":"default",
"tenantVrf":"default",
"vxlanInterface":"vni200",
"ifindex":19,
"vxlanIfindex":19,
"sviInterface":"br200",
"sviIfindex":18,
"vtepIp":"2.2.2.1",
"mcastGroup":"0.0.0.0",
"advertiseGatewayMacip":"No",
"advertiseSviMacip":"No",
"numMacs":0,
"numArpNd":0,
"numRemoteVteps":1,
"remoteVteps":[
{
"ip":"2.2.2.2",
"flood":"HER"
}
]
},
{
"vni":100,
"type":"L3",
"vrf":"default",
"tenantVrf":"default",
"localVtepIp":"2.2.2.1",
"vxlanIntf":"vni100",
"sviIntf":"br100",
"state":"Up",
"sysMac":"aa:bb:cc:dd:ee:f1",
"routerMac":"aa:bb:cc:dd:ee:f1",
"vniFilter":"none",
"l2Vnis":[
20,
30,
200
]
}
]
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
|
|
The two commands ( `advertise-svi-ip` and `advertise-default-gw` ) can
be set in both `BGP_EVPN_NODE` and `BGP_EVPN_VNI_NODE`. So, when
configuring one of them, need to consider the configuration of the
other. Configuring it under `BGP_EVPN_NODE`, it does check the other.
However, the conversion is wrong when configured under `BGP_EVPN_VNI_NODE`.
One example:
With the following steps, the evpn routes with `SVI` will be mistakenly
withdrawn.
```
anlan(config-router-af)# advertise-svi-ip
anlan(config-router-af)# vni 100
anlan(config-router-af-vni)# advertise-svi-ip
anlan(config-router-af-vni)# no advertise-svi-ip
```
This commit fixed the conversion under `BGP_EVPN_VNI_NODE` for the
two commands.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
Remove redundant spaces for debug log. By the way, adjust one format problem.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
zebra: Evpn mac vni detail show command
|
|
Missing json attributes added for show evpn json
Before:
```
tor-1# show evpn json
{
"advertiseGatewayMacip":"No",
"numVnis":26,
"numL2Vnis":21,
"numL3Vnis":5,
"isDuplicateAddrDetection":true,
"maxMoves":5,
"detectionTime":180,
"detectionFreezeTime":0,
"macHoldtime":1080,
"neighHoldtime":1080,
"startupDelay":180,
"startupDelayTimer":"--:--:--",
"uplinkConfigCount":0,
"uplinkActiveCount":0
}
tor-1#
```
After:
```
tor-1# show evpn json
{
"advertiseGatewayMacip":"No",
"advertiseSviMacip":"No",
"advertiseSviMac":"No",
"numVnis":26,
"numL2Vnis":21,
"numL3Vnis":5,
"isDuplicateAddrDetection":true,
"maxMoves":5,
"detectionTime":180,
"detectionFreezeTime":0,
"macHoldtime":1080,
"neighHoldtime":1080,
"startupDelay":180,
"startupDelayTimer":"--:--:--",
"uplinkConfigCount":0,
"uplinkActiveCount":0
}
tor-1#
```
Ticket:#3323248
Issue:3323248
Testing: UT done
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
|
|
New show command "show evpn mac vni xx detail [json]"
to display details of all the mac entries for the
requested VNI.
Output of show evpn mac vni xx detail json:
{
"numMacs":2,
"macs":{
"ca:be:63:7c:81:05":{
"type":"local",
"intf":"veth100",
"ifindex":8,
"uptime":"00:06:55",
"localSequence":0,
"remoteSequence":0,
"detectionCount":0,
"isDuplicate":false,
"syncNeighCount":0,
"neighbors":{
"active":[
"fe80::c8be:63ff:fe7c:8105"
],
"inactive":[
]
}
}
}
}
Also added remoteEs field in the JSON output of
"show evpn mac vni xx json".
Output of show evpn mac vni xx json:
"00:02:00:00:00:0d":{
"type":"remote",
"remoteEs":"03:44:38:39:ff:ff:02:00:00:02",
"localSequence":0,
"remoteSequence":0,
"detectionCount":0,
"isDuplicate":false
}
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
|
|
Use "get" as the name for checking the status of the bgp
accept lower seq knob. This already has an equivalent "set"
so makes sense to keep it consistent.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Add a knob to accept lower seq number in evpn updates
from BGP in Zebra.
Note: Knob is enabled by default
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
zebra can change l2vni's tenant vrf with new `vid`, and then notify bgpd
to change also. But this notification is wrongly missed, so bgpd knows
nothing about it. It affects evpn routes, which are related to tenant vrf.
Need to notify bgpd of the `vid` change.
Changes l2vni 100 of vxlan's `vid` so as to change its svi interface from
default to vrf1, then check bgp's vni status.
Before: (Ignored irrelevent columns)
```
host#show bgp l2vpn evpn vni
VNI Type RD Tenant VRF
* 100 L2 66.66.66.66:2 default <- No change
```
After:(Ignored irrelevent columns)
```
host#show bgp l2vpn evpn vni
VNI Type RD Tenant VRF
* 100 L2 66.66.66.66:2 vrf1 <- Updated
```
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
`show evpn vni detail` doesn't reflect any change in vni transition.
Need to add processing in command of `[no] vni (1-16777215)`.
With the config:
```
!
vni 66
!
vrf vrf1
vni 88
exit-vrf
!
```
Before:
```
(config-vrf)# no vni 88
(config-vrf)# do show evpn vni detail
VNI: 66
Type: L3
Tenant VRF: default
L2 VNIs: <- Empty
```
After:
```
(config-vrf)# no vni 88
(config-vrf)# do show evpn vni detail
VNI: 66
Type: L3
Tenant VRF: default
L2 VNIs: 88 <-
```
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
These moved mac addresses are actually in active status during moving
phase, just correct comment.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
The test case is with `redirect-off` in evpn multi-homing environment:
```
evpn mh redirect-off
```
After the environment is setup, do the following steps:
1) Let one member of ES learn one mac:
```
2e:52:bb:bb:2f:46 dev ae1 vlan 100 master bridge0 static
```
Now everything is ok and the mac can be synced to other ES peers.
2) Shutdown bond1. At this time, zebra will get three netlink messages,
not one as current code expected. Like:
```
e4:f0:04:89:b6:46 dev vxlan10030 vlan 30 master bridge0 static <-A
e4:f0:04:89:b6:46 dev vxlan10030 nhid 536870913 self extern_learn <-B
e4:f0:04:89:b6:46 dev vxlan10030 vlan 30 self <-C
```
With A), zebra will wrongly remove this mac again:
```
ZEBRA: dpAdd remote MAC e4:f0:04:89:b6:46 VID 30
ZEBRA: Add/update remote MAC e4:f0:04:89:b6:46 intf vxlan10030(26) VNI 10030 flags 0xa01 - del local
ZEBRA: Send MACIP Del f None MAC e4:f0:04:89:b6:46 IP (null) seq 0 L2-VNI 10030 ESI - to bgp
```
With C), zebra will wrongly add this mac again:
```
ZEBRA: Rx RTM_NEWNEIGH AF_BRIDGE IF 26 VLAN 30 st 0x2 fl 0x2 MAC e4:f0:04:89:b6:46 nhg 0
ZEBRA: dpAdd remote MAC e4:f0:04:89:b6:46 VID 30
```
zebra should skip the two messages with `vid`. Otherwise, it will send many
*wrong* messages to bgpd, and the logic is wrong.
`nhg/dst` is in 2nd message without `vid`, it is useful to call
`zebra_evpn_add_update_local_mac()`. But it will fail with "could not find EVPN"
warning for no `vid`, can't call `zebra_evpn_add_update_local_mac()`:
With B):
```
ZEBRA: Rx RTM_NEWNEIGH AF_BRIDGE IF 26 st 0x2 fl 0x12 MAC e4:f0:04:89:b6:46 nhg 536870913
ZEBRA: dpAdd local-nw-MAC e4:f0:04:89:b6:46 VID 0
ZEBRA: Add/Update MAC e4:f0:04:89:b6:46 intf ae1(18) VID 0, could not find EVPN
```
Here, we can get `vid` from vxlan interface instead of from netlink message.
In summary, `zebra_vxlan_dp_network_mac_add()` will process the three messages
wrongly expecting only one messsage, so its logic is wrong. Just skip the two
unuseful messages with `vid`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
The rib_process_dplane_results function was having each
sub function handler process the results and then
free the ctx. Lot's of functionality that needs to remember
to free the context. Let's just free it in the main loop.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
The two checks for l3vni have been already done in
`lib_vrf_zebra_l3vni_id_modify()` as it should be. And it is improper that
the two checks are put after `zebra_vxlan_handle_vni_transition()`, which
will do real things.
My original fix is to remove them. But NB module can't guarantee many changes,
so we'd better keep them in `zebra_vxlan_process_vrf_vni_cmd()` in APPLY stage
for safe.
Just move them in front of `zebra_vxlan_handle_vni_transition()`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
When the kernel was sending an RTM_NEWLINK updating the MAC of a known
SVI, Type-2 routes created by advertise-svi-ip were not getting updated
with the new address.
This adds removal of any old Type-2 routes (with old MAC) and creation
of new Type-2 routes (with new MAC) into RTM_NEWLINK processing.
Fixes: #11174
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
|
