[dev] FPM-Zebra interactions and EVPN MAC route handing

Sri Mohana Singamsetty msingamsetty at vmware.com
Tue Jul 23 10:38:41 EDT 2019


Syed,

In addition to what Mark had mentioned, couple of inputs below.

For #2: Yes, currently there is no MAC learning through FPM and FPM can’t inject any information back to Zebra. We have a similar need and we are planning to add a custom channel through which MACs can be injected to Zebra/BGP so that BGP can pick them and advertise as Type-2 route advertisements. I can provide more details on the design and other things at later point.

For #3: Could you please check if the below PR addresses this requirement ?
https://github.com/FRRouting/frr/pull/4293

Thanks,
Mohan


From: dev <dev-bounces at lists.frrouting.org> on behalf of Mark Stapp <mjs at voltanet.io>
Date: Tuesday, July 23, 2019 at 8:53 AM
To: Syed Hasan Raza Naqvi <syed.naqvi at broadcom.com>
Cc: FRRouting-Dev <dev at lists.frrouting.org>
Subject: Re: [dev] FPM-Zebra interactions and EVPN MAC route handing

Hi Hasan,
FPM in one-way: it's a way of making some of zebra's information available to an external consumer. As you observed, it's not possible to use FPM to influence what information zebra holds or how it processes the information it receives.

We've begun adding a dataplane subsystem to zebra that is designed to be more complete, and to be bi-directional. The zebra dataplane is asynchronous, and it supports plugins to implement support for a system's forwarding path - the default plugin supports the local kernel, for example. We've moved ip route programming, interface address programming, and LSP programming into this kernel plugin so far. You can take a look at zebra/zebra_dplane.[ch] to see how the current support works.  I'll be working on EVPN this summer, as a matter of fact, and hopefully we'll be able to offer a useful set of features.

-- Mark

On Mon, Jul 22, 2019 at 5:00 PM Syed Hasan Raza Naqvi via dev <dev at lists.frrouting.org<mailto:dev at lists.frrouting.org>> wrote:



---------- Forwarded message ----------
From: Syed Hasan Raza Naqvi <syed.naqvi at broadcom.com<mailto:syed.naqvi at broadcom.com>>
To: dev at lists.frrouting.org<mailto:dev at lists.frrouting.org>
Cc:
Bcc:
Date: Mon, 22 Jul 2019 13:58:07 -0700
Subject: FPM-Zebra interactions and EVPN MAC route handing

Hi,

I have below queries related to Zebra-FPM interaction and EVPN MAC handling in FRR. Would appreciate if someone could answer.


(1)  First of all, I don't see any communication from Fpm to Zebra today. The code in Zebra just de-queues from the fpm socket and discards.
    zebra_fpm.c:zfpm_read_cb() ...
/*
* Just throw it away for now. */
    Wondering if we never had a situation where specific info or feedback is required from Fpm?
    For example, the route installation errors in Fpm communicated back to Zebra?



(2) This question is related to above. In systems where L2 forwarding/learning is achieved in hardware (asic) forwarding plane, not all of the MACs will be available in Linux FDB. Only the MACs which were learned due to ARP/ND would be present in Linux FDB.

    In such a case, it might be better to inject the local MACs into Zebra directly from Fpm. But looks like the only way for local MACs to be advertised into EVPN is to somehow inject  them into Linux FDB and let Zebra learn from Linux.

    Is this correct understanding? And will it be acceptable to introduce a knob in zebra to get the local MACs from Fpm instead of Linux FDB?


(3) On the similar lines as above, not all of the remote EVPN MACs need to be present in Linux FDB. Only those MACs which have corresponding IP (ARP/ND) are required in Linux FDB. In such a case, it might be better to selectively install MACs into Linux, and send all of the EVPN MACs to Fpm so that they can be installed in asic. But I don't see zebra gives any MAC to Fpm. I would like to hear the rationale behind this as well. And is it a good idea to introduce a knob in Zebra to achieve it?

Thanks in advance!

Regards,
Hasan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20190723/c6510ff2/attachment-0001.html>


More information about the dev mailing list