July 2019 - dev - lists.frrouting.org

Regarding support for rsvp-te support in free routing
by Rhene Kavi 20 Feb '20

20 Feb '20

Hi All, Do we have any plans to support rsvp-te Thanks in advance KaviRhene

4 3

FRR on NRL CORE (fyi)
by Phil Wiggins 22 Aug '19

22 Aug '19

If anyone is interested in running FRR in the NRL CORE emulation environment, I have some build scripts for FRR on CORE that I posted at the first link below. Normally CORE runs Quagga, so this script was a hack to shoehorn FRR as a Quagga replacement. These scripts are not part of CORE yet, so are unsupported. People on this list may want to use CORE for FRR experimentation and testing, so you can customize these scripts to suit your own needs. It's best to run this stuff in a VM with no internet connection (after installation) since CORE runs lots of processes as root - a well-known security issue. https://github.com/coreemu/core/issues/170 ( install_frr_for_core.sh) FRR on NRL CORE build script - assumes Ubuntu 16.04.4 clean installation in a VM or physical host: https://gist.github.com/apwiggins/44f3592a61965783372aea5881ed9f7a (core_misc_frr.py ) used by the install script above to install at ./core/misc/frr.py https://gist.github.com/apwiggins/d610c2794c8c0a12a45bfc093fd2e949 (core_services_frr.py) used by the install script above to install at ./core/services/frr.py https://gist.github.com/apwiggins/747a9a14feff2ce3a3b8760406b825a7 https://www.nrl.navy.mil/itd/ncs/products/core The Common Open Research Emulator (CORE) is a tool for emulating networks on one or more machines. You can connect these emulated networks to live networks. CORE consists of a GUI for drawing topologies of lightweight virtual machines, and Python modules for scripting network emulation. Cheers, Phil

3 6

Identical copy of buster and bullseye - deb.frrouting.org
by Christoffer Hansen 01 Aug '19

01 Aug '19

dev@, Possible to maintain an identical copy of packages for Debian 10 (buster) and Debian testing (bullseye) on http://deb.frrouting.org ? Distribution: * Debian unstable (sid) * Debian testing (bullseye) * Debian 10 (buster) -- Christoffer

3 3

Some doubts regarding asynchronous data plane in FRR
by sudhanshu kumar 30 Jul '19

30 Jul '19

Hi, I have 2 doubts regarding asynchronous dataplane implementation in FRR. 1. When there are multiple dplanes, each can process the same route context and modify the status in the context. But while processing rib_process_after(), we only consider the status returned by the last processed provider. Is this correct? We should, in this case, consider status returned by all the providers. If all of them return success, then only, we should consider the status as success in rib_process_after(). 2. Currently, zebra fpm interaction happens in rib context using hook. I would like to know why this was done ? Can this be made as a separate dplane ? Thanks, Sudhanshu

2 3

Question in relation to draft-sa-grow-maxprefix
by Christoffer Hansen 29 Jul '19

29 Jul '19

dev@, https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/?include_text=1 Do the current FRR master branch have support for both o Type A Pre-Policy, o Type B Post-Policy, and o Outbound BGP Maximum Prefix Limits? Christoffer """ 2.1. Type A: Pre-Policy Inbound Maximum Prefix Limits The Adj-RIBs-In stores routing information learned from inbound UPDATE messages that were received from another BGP speaker Section 3.2 [RFC4271]. The Type A pre-policy limit uses the number of NLRIs per Address Family Identifier (AFI) per Subsequent Address Family Identifier (SAFI) as input into its threshold comparisons. For example, when an operator configures the Type A pre-policy limit for IPv4 Unicast to be 50 on a given EBGP session, and the other BGP speaker announces its 51st IPv4 Unicast NLRI, the session MUST be terminated. Type A pre-policy limits are particularly useful to help dampen the effects of full table route leaks and memory exhaustion when the implementation stores rejected routes. 2.2. Type B: Post-Policy Inbound Maximum Prefix Limits RFC4271 describes a Policy Information Base (PIB) that contains local policies that can be applied to the information in the Routing Information Base (RIB). The Type B post-policy limit uses the number of NLRIs per Address Family Identifier (AFI) per Subsequent Address Family Identifier (SAFI), after application of the Import Policy as input into its threshold comparisons. For example, when an operator configures the Type B post-policy limit for IPv4 Unicast to be 50 on a given EBGP session, and the other BGP speaker announces a hundred IPv4 Unicast routes of which none are accepted as a result of the local import policy (and thus not considered for the Loc-RIB by the local BGP speaker), the session is not terminated. Type B post-policy limits are useful to help prevent FIB exhaustion and prevent accidental BGP session teardown due to prefixes not accepted by policy anyway. 3. Outbound Maximum Prefix Limits An operator MAY configure a BGP speaker to terminate its BGP session with a neighbor when the number of address prefixes to be advertised to that neighbor exceeds a locally configured upper limit. The BGP speaker then MUST send the neighbor a NOTIFICATION message with the Error Code Cease and the Error Subcode "Threshold reached: Maximum Number of Prefixes Send", and MAY support other actions. Reporting when thresholds have been exceeded is an implementation specific consideration, but SHOULD include methods such as Syslog [RFC5424]. By definition, Outbound Maximum Prefix Limits are Post-Policy. The Adj-RIBs-Out stores information selected by the local BGP speaker for advertisement to its neighbors. The routing information stored in the Adj-RIBs-Out will be carried in the local BGP speaker's UPDATE messages and advertised to its neighbors Section 3.2 [RFC4271]. The Outbound Maximum Prefix Limit uses the number of NLRIs per Address Family Identifier (AFI) per Subsequent Address Family Identifier (SAFI), after application of the Export Policy, as input into its threshold comparisons. For example, when an operator configures the Outbound Maximum Prefix Limit for IPv4 Unicast to be 50 on a given EBGP session, and were about to announce its 51st IPv4 Unicast NLRI to the other BGP speaker as a result of the local export policy, the session MUST be terminated. Outbound Maximum Prefix Limits are useful to help dampen the negative effects of a misconfiguration in local policy. In many cases, it would be more desirable to tear down a BGP session rather than causing or propagating a route leak. """ """ +-------------+----------------+-------------------------+----------+ | Vendor | Type A Pre- | Type B Post-Policy | Outbound | | | Policy | | | +-------------+----------------+-------------------------+----------+ | Cisco IOS | | maximum-prefix | | | XR | | | | +-------------+----------------+-------------------------+----------+ | Cisco IOS | | maximum-prefix | | | XE | | | | +-------------+----------------+-------------------------+----------+ | Juniper | prefix-limit | accepted-prefix-limit, | | | Junos OS | | or prefix-limit | | | | | combined with 'keep | | | | | none' | | +-------------+----------------+-------------------------+----------+ | Nokia SR OS | prefix-limit | | | +-------------+----------------+-------------------------+----------+ | NIC.CZ BIRD | 'import keep | 'import limit' or | export | | | filtered' | 'receive limit' | limit | | | combined with | | | | | 'receive | | | | | limit' | | | +-------------+----------------+-------------------------+----------+ | OpenBSD | max-prefix | | | | OpenBGPD | | | | +-------------+----------------+-------------------------+----------+ | Arista EOS | maximum-routes | maximum-accepted-routes | | +-------------+----------------+-------------------------+----------+ | Huawei | peer route- | | | | VRPv5 | limit | | | +-------------+----------------+-------------------------+----------+ | Huawei | peer route- | peer route-limit | | | VRPv8 | limit | accept-prefix | | +-------------+----------------+-------------------------+----------+ First presented by Snijders at [RIPE77] Table 1: Maximum prefix limits capabilities per implementation """

1 0

Re: [dev] FPM-Zebra interactions and EVPN MAC route handing
by Sri Mohana Singamsetty 25 Jul '19

25 Jul '19

Syed, I had given a wrong PR ID earlier. It is not 4293, but 4294. Thanks, Mohan From: Syed Hasan Raza Naqvi <syed.naqvi(a)broadcom.com> Date: Wednesday, July 24, 2019 at 10:35 PM To: Sri Mohana Singamsetty <msingamsetty(a)vmware.com> Cc: Mark Stapp <mjs(a)voltanet.io> Subject: Re: [dev] FPM-Zebra interactions and EVPN MAC route handing Thank you Mark and Mohan for pointers. Highly appreciate it! Hi Mark, Let me look closer into dplane changes in the master branch and get back with specific questions. Great to know that you will be adding EVPN support to dplane. Hi Mohan, Regarding: > "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." Are you referring to the custom channel via dplane? Or through fpm? I believe if the channel is not via dplane, you may not be able to upstream the changes. Regarding PR 4293, I had looked into this and the changes are for sending Type-5 router's MAC and L3VNI to FPM. We needed that as well. But I see this PR got closed without merging. I believe it was closed because there was already plan in place to migrate EVPN to dplane. Thanks, Hasan On Tue, Jul 23, 2019 at 7:38 AM Sri Mohana Singamsetty <msingamsetty(a)vmware.com<mailto:msingamsetty@vmware.com>> wrote: 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> Thanks, Mohan From: dev <dev-bounces(a)lists.frrouting.org<mailto:dev-bounces@lists.frrouting.org>> on behalf of Mark Stapp <mjs(a)voltanet.io<mailto:mjs@voltanet.io>> Date: Tuesday, July 23, 2019 at 8:53 AM To: Syed Hasan Raza Naqvi <syed.naqvi(a)broadcom.com<mailto:syed.naqvi@broadcom.com>> Cc: FRRouting-Dev <dev(a)lists.frrouting.org<mailto:dev@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(a)lists.frrouting.org<mailto:dev@lists.frrouting.org>> wrote: ---------- Forwarded message ---------- From: Syed Hasan Raza Naqvi <syed.naqvi(a)broadcom.com<mailto:syed.naqvi@broadcom.com>> To: dev(a)lists.frrouting.org<mailto:dev@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

1 0

Re: [dev] FPM-Zebra interactions and EVPN MAC route handing
by Mark Stapp 23 Jul '19

23 Jul '19

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(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: Syed Hasan Raza Naqvi <syed.naqvi(a)broadcom.com> > To: dev(a)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 > >

2 1

More complex PBR rules
by Markus Moeller 23 Jul '19

23 Jul '19

Hi FRR developers, I am new to this group and wonder if you can advise how I could implement more complex PBR rules to achieve for example load balancing. The requirement I have is to route based on e.g. a hash like: hash(src-ip+dst-ip) mod N routes via gwX 0<X<=N ( load balance over N gateways ) This would help in situations where I can not use a MAC for identifying a GW ( e.g. in cloud environments) . Would this be possible with FRR or do I have to look into the linux kernel. If it is in the kernel, could someone point me to the relevant kernel routines ? Thank you Markus

2 1

Open source routing @ ietf meetup -- Monday Lunch
by Lou Berger 22 Jul '19

22 Jul '19

Hi, We're continuing with the informal Open Source routing @ ietf meetup. Anyone interested in joining a "bring your own lunch" gathering of folks using/building open source routing code, please drop in to "C2 (21st Floor) " on *Monday* during lunch (noon). There is no agenda or slides. Please feel free to bring a topic that you'd like to discuss or just come and listen. Cheers, Lou

2 1

New Northbound API compatibility with vtysh commands
by Mukesh.Moopath.Velay＠dell.com 20 Jul '19

20 Jul '19

Hi Renato, We are very much interested in the new Northbound API for FRR as it provides programmatic access to configure FRR and read operational data. We have a use-case where the new Northbound API may be used in conjunction with the legacy VTYsh commands and have a few questions in this regard - 1. Does the new Northbound API architecture currently allow concurrent configuration using legacy VTYsh commands as well at the same time ? 2. How does configuration persistence work ? Will the frr.conf store ONLY configurations made using legacy VTYsh commands ? Are the new Northbound API configurations persisted separately ? 3. If separately persisted will both frr.conf and the Northbound APIs be restored independently at start-up ? Thanks, Mukesh

2 1