Vxlan route updates not going zfpm
Hi, When I checked latest FRR code all Vxlan updates[type2, type5] are going to Linux kernel. It means VTEP information is not giving to Zfpm from 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. For this to work whether I can add "route_node" to rib_queue. Will it solve the issue. Could you please provide your inputs. Thanks, Srinivas
Srinivas - Vxlan updates are typically a mac address and a ip address, which are placed into the linux neighbor table. This is l2 information. At this point in time the zebra rib is meant for l3 routes. At this point in time zebra is used for pass through to the data plane. If you need this information stored in the zebra rib, it would be a different table and more work to consolidate all this information. donald On Wed, Feb 6, 2019 at 12:34 AM Srinivasulu P <srinivas.pichika@gmail.com> wrote:
Hi,
When I checked latest FRR code all Vxlan updates[type2, type5] are going to Linux kernel. It means VTEP information is not giving to Zfpm from 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.
For this to work whether I can add "route_node" to rib_queue. Will it solve the issue. Could you please provide your inputs.
Thanks,
Srinivas
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
When considering to add VxLAN to Zfpm, I suggest to review the Zfpm design to avoid sending routes information to Zfpm from many different places in the Zebra update code. Is it possible to send/queue a copy to Zfpm right where a route or routes are “send” to kernel via netlink? Jay From: dev <dev-bounces@lists.frrouting.org> on behalf of Donald Sharp <sharpd@cumulusnetworks.com> Date: Monday, February 11, 2019 at 5:26 PM To: Srinivasulu P <srinivas.pichika@gmail.com> Cc: FRRouting-Dev <dev@lists.frrouting.org> Subject: Re: [dev] Vxlan route updates not going zfpm Srinivas - Vxlan updates are typically a mac address and a ip address, which are placed into the linux neighbor table. This is l2 information. At this point in time the zebra rib is meant for l3 routes. At this point in time zebra is used for pass through to the data plane. If you need this information stored in the zebra rib, it would be a different table and more work to consolidate all this information. donald On Wed, Feb 6, 2019 at 12:34 AM Srinivasulu P <srinivas.pichika@gmail.com<mailto:srinivas.pichika@gmail.com>> wrote: Hi, When I checked latest FRR code all Vxlan updates[type2, type5] are going to Linux kernel. It means VTEP information is not giving to Zfpm from 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. For this to work whether I can add "route_node" to rib_queue. Will it solve the issue. Could you please provide your inputs. Thanks, Srinivas _______________________________________________ dev mailing list dev@lists.frrouting.org<mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_listinfo_dev&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=WFEc2yCNjgymSPtaWgHv93-39sLEXnE2zh-1IwycCl8&s=W2TAHxF32GfX-ingXKk1Tq4wW_IU1HseMDRP7DXbjTo&e=>
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. On Tue, Feb 12, 2019 at 8:05 AM Jia Chen <jchen1@paloaltonetworks.com> wrote:
When considering to add VxLAN to Zfpm, I suggest to review the Zfpm design to avoid sending routes information to Zfpm from many different places in the Zebra update code. Is it possible to send/queue a copy to Zfpm right where a route or routes are “send” to kernel via netlink?
Jay
*From: *dev <dev-bounces@lists.frrouting.org> on behalf of Donald Sharp < sharpd@cumulusnetworks.com> *Date: *Monday, February 11, 2019 at 5:26 PM *To: *Srinivasulu P <srinivas.pichika@gmail.com> *Cc: *FRRouting-Dev <dev@lists.frrouting.org> *Subject: *Re: [dev] Vxlan route updates not going zfpm
Srinivas -
Vxlan updates are typically a mac address and a ip address, which are placed into the linux neighbor table. This is l2 information. At this point in time the zebra rib is meant for l3 routes. At this point in time zebra is used for pass through to the data plane. If you need this information stored in the zebra rib, it would be a different table and more work to consolidate all this information.
donald
On Wed, Feb 6, 2019 at 12:34 AM Srinivasulu P <srinivas.pichika@gmail.com> wrote:
Hi,
When I checked latest FRR code all Vxlan updates[type2, type5] are going to Linux kernel. It means VTEP information is not giving to Zfpm from 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.
For this to work whether I can add "route_node" to rib_queue. Will it solve the issue. Could you please provide your inputs.
Thanks,
Srinivas
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_listinfo_dev&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=WFEc2yCNjgymSPtaWgHv93-39sLEXnE2zh-1IwycCl8&s=W2TAHxF32GfX-ingXKk1Tq4wW_IU1HseMDRP7DXbjTo&e=>
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hi Vivek, Thanks for response. Could you please suggest the best way from Zebra to FPM interface for these BGP EVPN(type-2 or type-5) routes : 1. Have a callback in FPM, when zebra installed type-2 or type-5 routes into linux kernel and update the FPM through callback. Less changes are required in FRR side. Or 2. From Zebra to ZFPM pass these routes to FPM via the tcp socket. For this we need to modify the FRR code. Please provide your inputs. Thanks and Regards, Srinivas On Wed, Feb 13, 2019 at 11:30 PM Vivek Venkatraman < vivek@cumulusnetworks.com> wrote:
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.
On Tue, Feb 12, 2019 at 8:05 AM Jia Chen <jchen1@paloaltonetworks.com> wrote:
When considering to add VxLAN to Zfpm, I suggest to review the Zfpm design to avoid sending routes information to Zfpm from many different places in the Zebra update code. Is it possible to send/queue a copy to Zfpm right where a route or routes are “send” to kernel via netlink?
Jay
*From: *dev <dev-bounces@lists.frrouting.org> on behalf of Donald Sharp < sharpd@cumulusnetworks.com> *Date: *Monday, February 11, 2019 at 5:26 PM *To: *Srinivasulu P <srinivas.pichika@gmail.com> *Cc: *FRRouting-Dev <dev@lists.frrouting.org> *Subject: *Re: [dev] Vxlan route updates not going zfpm
Srinivas -
Vxlan updates are typically a mac address and a ip address, which are placed into the linux neighbor table. This is l2 information. At this point in time the zebra rib is meant for l3 routes. At this point in time zebra is used for pass through to the data plane. If you need this information stored in the zebra rib, it would be a different table and more work to consolidate all this information.
donald
On Wed, Feb 6, 2019 at 12:34 AM Srinivasulu P <srinivas.pichika@gmail.com> wrote:
Hi,
When I checked latest FRR code all Vxlan updates[type2, type5] are going to Linux kernel. It means VTEP information is not giving to Zfpm from 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.
For this to work whether I can add "route_node" to rib_queue. Will it solve the issue. Could you please provide your inputs.
Thanks,
Srinivas
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_listinfo_dev&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=WFEc2yCNjgymSPtaWgHv93-39sLEXnE2zh-1IwycCl8&s=W2TAHxF32GfX-ingXKk1Tq4wW_IU1HseMDRP7DXbjTo&e=>
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hi Srinivas, My apologies for the delayed response. I haven't looked closely at how the FPM interface is in the latest upstream tree, so please examine that and seek input from others too. My general comment is that the approach should closely mirror what is done for routes. IIRC, zebra directly talks to FPM, FPM being just one of the forwarding plane interfaces, similar to netlink and route sockets. If so, for (VTEP) flood list and MAC database, you need to modify the zebra code to invoke the appropriate FPM interface. For ARP suppression, you need to add interactions with the appropriate entity if it is the CPU looking at ARP to end hosts and performing the suppression and the entity doing it is not the kernel. Vivek On Thu, Feb 14, 2019 at 5:49 PM Srinivasulu P <srinivas.pichika@gmail.com> wrote:
Hi Vivek,
Thanks for response. Could you please suggest the best way from Zebra to FPM interface for these BGP EVPN(type-2 or type-5) routes :
1. Have a callback in FPM, when zebra installed type-2 or type-5 routes into linux kernel and update the FPM through callback. Less changes are required in FRR side.
Or
2. From Zebra to ZFPM pass these routes to FPM via the tcp socket. For this we need to modify the FRR code.
Please provide your inputs.
Thanks and Regards, Srinivas
On Wed, Feb 13, 2019 at 11:30 PM Vivek Venkatraman < vivek@cumulusnetworks.com> wrote:
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.
On Tue, Feb 12, 2019 at 8:05 AM Jia Chen <jchen1@paloaltonetworks.com> wrote:
When considering to add VxLAN to Zfpm, I suggest to review the Zfpm design to avoid sending routes information to Zfpm from many different places in the Zebra update code. Is it possible to send/queue a copy to Zfpm right where a route or routes are “send” to kernel via netlink?
Jay
*From: *dev <dev-bounces@lists.frrouting.org> on behalf of Donald Sharp <sharpd@cumulusnetworks.com> *Date: *Monday, February 11, 2019 at 5:26 PM *To: *Srinivasulu P <srinivas.pichika@gmail.com> *Cc: *FRRouting-Dev <dev@lists.frrouting.org> *Subject: *Re: [dev] Vxlan route updates not going zfpm
Srinivas -
Vxlan updates are typically a mac address and a ip address, which are placed into the linux neighbor table. This is l2 information. At this point in time the zebra rib is meant for l3 routes. At this point in time zebra is used for pass through to the data plane. If you need this information stored in the zebra rib, it would be a different table and more work to consolidate all this information.
donald
On Wed, Feb 6, 2019 at 12:34 AM Srinivasulu P < srinivas.pichika@gmail.com> wrote:
Hi,
When I checked latest FRR code all Vxlan updates[type2, type5] are going to Linux kernel. It means VTEP information is not giving to Zfpm from 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.
For this to work whether I can add "route_node" to rib_queue. Will it solve the issue. Could you please provide your inputs.
Thanks,
Srinivas
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_listinfo_dev&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=WFEc2yCNjgymSPtaWgHv93-39sLEXnE2zh-1IwycCl8&s=W2TAHxF32GfX-ingXKk1Tq4wW_IU1HseMDRP7DXbjTo&e=>
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
I think there are three cases for VxLAN routes. 1. One is that when a new route got added by BGP (route add or route change), the routes will need to be sent to FPM 2. Remote dataplane restart, Zebra will need to resend all routes 3. Zebra restart Jay From: Vivek Venkatraman <vivek@cumulusnetworks.com> Date: Saturday, February 23, 2019 at 11:03 PM To: Srinivasulu P <srinivas.pichika@gmail.com> Cc: Jia Chen <jchen1@paloaltonetworks.com>, Donald Sharp <sharpd@cumulusnetworks.com>, FRRouting-Dev <dev@lists.frrouting.org> Subject: Re: [dev] Vxlan route updates not going zfpm Hi Srinivas, My apologies for the delayed response. I haven't looked closely at how the FPM interface is in the latest upstream tree, so please examine that and seek input from others too. My general comment is that the approach should closely mirror what is done for routes. IIRC, zebra directly talks to FPM, FPM being just one of the forwarding plane interfaces, similar to netlink and route sockets. If so, for (VTEP) flood list and MAC database, you need to modify the zebra code to invoke the appropriate FPM interface. For ARP suppression, you need to add interactions with the appropriate entity if it is the CPU looking at ARP to end hosts and performing the suppression and the entity doing it is not the kernel. Vivek On Thu, Feb 14, 2019 at 5:49 PM Srinivasulu P <srinivas.pichika@gmail.com<mailto:srinivas.pichika@gmail.com>> wrote: Hi Vivek, Thanks for response. Could you please suggest the best way from Zebra to FPM interface for these BGP EVPN(type-2 or type-5) routes : 1. Have a callback in FPM, when zebra installed type-2 or type-5 routes into linux kernel and update the FPM through callback. Less changes are required in FRR side. Or 2. From Zebra to ZFPM pass these routes to FPM via the tcp socket. For this we need to modify the FRR code. Please provide your inputs. Thanks and Regards, Srinivas On Wed, Feb 13, 2019 at 11:30 PM Vivek Venkatraman <vivek@cumulusnetworks.com<mailto:vivek@cumulusnetworks.com>> wrote: 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. On Tue, Feb 12, 2019 at 8:05 AM Jia Chen <jchen1@paloaltonetworks.com<mailto:jchen1@paloaltonetworks.com>> wrote: When considering to add VxLAN to Zfpm, I suggest to review the Zfpm design to avoid sending routes information to Zfpm from many different places in the Zebra update code. Is it possible to send/queue a copy to Zfpm right where a route or routes are “send” to kernel via netlink? Jay From: dev <dev-bounces@lists.frrouting.org<mailto:dev-bounces@lists.frrouting.org>> on behalf of Donald Sharp <sharpd@cumulusnetworks.com<mailto:sharpd@cumulusnetworks.com>> Date: Monday, February 11, 2019 at 5:26 PM To: Srinivasulu P <srinivas.pichika@gmail.com<mailto:srinivas.pichika@gmail.com>> Cc: FRRouting-Dev <dev@lists.frrouting.org<mailto:dev@lists.frrouting.org>> Subject: Re: [dev] Vxlan route updates not going zfpm Srinivas - Vxlan updates are typically a mac address and a ip address, which are placed into the linux neighbor table. This is l2 information. At this point in time the zebra rib is meant for l3 routes. At this point in time zebra is used for pass through to the data plane. If you need this information stored in the zebra rib, it would be a different table and more work to consolidate all this information. donald On Wed, Feb 6, 2019 at 12:34 AM Srinivasulu P <srinivas.pichika@gmail.com<mailto:srinivas.pichika@gmail.com>> wrote: Hi, When I checked latest FRR code all Vxlan updates[type2, type5] are going to Linux kernel. It means VTEP information is not giving to Zfpm from 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. For this to work whether I can add "route_node" to rib_queue. Will it solve the issue. Could you please provide your inputs. Thanks, Srinivas _______________________________________________ dev mailing list dev@lists.frrouting.org<mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_listinfo_dev&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=WFEc2yCNjgymSPtaWgHv93-39sLEXnE2zh-1IwycCl8&s=W2TAHxF32GfX-ingXKk1Tq4wW_IU1HseMDRP7DXbjTo&e=> _______________________________________________ dev mailing list dev@lists.frrouting.org<mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_listinfo_dev&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=7cwfZc21hxljGkl54CTOFYnwld9jszPa6tMxETT8yow&s=BLk1issOffRFDLVvecP6HNUzBGyazyrP9N-yWgY9DEA&e=>
Hi Donald, Thanks for the response. In EVPN case for Type-2, locally learned mac address and ip address will be send to other VTEP device. In this case, Zebra needs to update BGP to prepare Type-2 routes and send it to remote device. Could you please suggest, how zebra can receive these locally learned mac/ip address from the ASIC. It is via rt_netlink socket or any other mechanism to achieve this. Thanks and regards Srinivas On Tue, Feb 12, 2019 at 6:55 AM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Srinivas -
Vxlan updates are typically a mac address and a ip address, which are placed into the linux neighbor table. This is l2 information. At this point in time the zebra rib is meant for l3 routes. At this point in time zebra is used for pass through to the data plane. If you need this information stored in the zebra rib, it would be a different table and more work to consolidate all this information.
donald
On Wed, Feb 6, 2019 at 12:34 AM Srinivasulu P <srinivas.pichika@gmail.com> wrote:
Hi,
When I checked latest FRR code all Vxlan updates[type2, type5] are going to Linux kernel. It means VTEP information is not giving to Zfpm from 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.
For this to work whether I can add "route_node" to rib_queue. Will it solve the issue. Could you please provide your inputs.
Thanks,
Srinivas
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
participants (4)
-
Donald Sharp -
Jia Chen -
Srinivasulu P -
Vivek Venkatraman