search

FRRouting / frr

The FRRouting Protocol Suite
https://frrouting.org/
Other
3.33k stars 1.25k forks source link

Vxlan route updates not going zebra-rib #3740

Open spichika opened 5 years ago

spichika commented 5 years ago

Hi,

When I checked latest FRR code all Vxlan updates are going to Linux kernel. It means VTEP information is not giving to Zebra rib, like zebra_vxlan_remote_vtep_add, zebra_vxlan_remote_vtep_del, zebra_vxlan_remote_macip_add, zebra_vxlan_remote_macip_del.

The code flow

zebra_vxlan_remote_vtep_add |zvni_vtep_install |kernel_add_vtep

Could you please let me know whether my understanding is correct. if so, Is there any provision or any plan to update the zebra rib for Vxlan updates.

Thanks, Srinivas

spichika commented 5 years ago

To clarify more, Currently, the Vxlan updates are going to Linux kernel from zebra rib, none of Vxlan updates [type 2, type 5] are not giving to ZFPM. For this to work whether I can add "route_node" to rib_queue. Could you please provide your inputs.

Thanks, Srinivas

qlyoung commented 5 years ago

Reposting Vivek's response from the dev list:

If the point here is that the EVPN-VxLAN "L2" information (flooding information, MACs and neighbors) is only installed into the kernel (specifically, via the netlink interface) and does not have an interface into FPM, that is correct. Whoever has an immediate use case (need) for it can take it up. I would definitely recommend not to try to merge data structures etc. as part of the effort to add an FPM interface for the L2 information; that should be taken up separately, if warranted.

As far as routes go, irrespective of whether they originated in BGP from an EVPN (type-2 or type-5) route or otherwise, the zebra installation towards the kernel and FPM should be the same. There is some special "sideband" handling for an EVPN-sourced route currently, but it is not for the route itself, and this code will be reduced/eliminated soon.