-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zebra not deleting MAC/IP route #13973
Comments
This commit will probably fix your issue:
It was pushed in yesterday can you try again? |
Hi thanks for the reply :) We tried it once again. The issue persists and here is the log from the Zebra detects that the MAC should be locally installed: Full log from
Full log from
|
This issue is stale because it has been open 180 days with no activity. Comment or remove the |
This issue will be automatically closed in the specified period unless there is further activity. |
To Reproduce
We are using BGPEVPN with frr. We have the following setup:
We have three VTEPs two of them are Wi-Fi access points running OpenWRT and one Ubuntu 22.10 machine. The Ubuntu machine is also a route-reflector. They are all running master commit:
dee79c33a425d264e53e0e5d0ad51b1bc13945d0
. (The issue also occurred with frr 8.5.1).The access points are running a daemon that creates a VXLAN iface and bridges it to an iface created by hostapd when a station connects. The interface that is created by hostapd receives all the L2 traffic from this station.
We noticed the following problem. When a station roams from one access point to another it looses L2 connectivity although vtysh with the command
show evpn mac vni all
reports that the address is learned locally on the new VTEP.The Ubuntu machine properly forwards traffic to the new VTEP, but the new VTEP forwards it to the old VTEP instead of forwarding to the station.
We debugged it using a device with the MAC
34:cf:f6:b0:98:b6
. On the VTEP we moved to, the bridge now shows the following output:The Mac address is learned on both ports, although it should only be learnt on the local port
vlan4096
. We observed that the correct bgp messages get exchanged and zebra gets notified about the deletion of theMAC/IP
route. However zebra doesn't seem to apply the received information.Expected behavior
The MAC address of the device should only be learnt by port
vlan4096
Versions
dee79c33a425d264e53e0e5d0ad51b1bc13945d0
Additional context
For the access points we used the following config:
This is the log on the VTEP the device moved away from with IP
10.242.2.194
:This is the log on the VTEP the device moved to with IP
10.242.2.170
:The logs show that zebra on the new VTEP receives that it should delete the VNI entry on for the old VTEP but it seems like this is not happening. Do you have any idea what could be the reason for this or what we could do to mitigate this issue?
The text was updated successfully, but these errors were encountered: