June 2018 - dev - lists.frrouting.org

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

Re: [dev] Dataplane API
by Donald Sharp 10 Sep '18

10 Sep '18

I actually agree with both Vincent and Lou :) The current paradigm is a kernel based infrastructure and will be so for the foreseeable future. So if you are doing development *now* I would highly recommend working towards this paradigm. So Vincent is correct. Having said that, we are looking towards more formally defining the DataPlane API so that it becomes possible to allow a fully implemented dataplane api that if someone wanted to implement non-kernel based interfaces they could. So Lou is correct too! There is a lot of work here though, mainly of a infrastructure updates. I've currently (slowly) started trying to define this api( See https://github.com/FRRouting/frr/pull/2292 ). The current api line for the dataplane is fuzzy at best and lots of assumptions are made about behavior and how data structures are created. This line must be wedged apart as a first step. If you are unsure where to start here, please ask and we'll have suggestions. We also have additional goals for zebra such as true pthreads and nexthop-group route entry indirection to name a few. Please note we are not doing this work specifically to allow a full dataplane outside of a kernel, it should fall out if I do the work correctly for what I am interested in. I am doing this work because I think this work will allow me to do some work with route-aggregation as well as more efficiently pass data to the kernel for route installs. I'm sure other people have their own reasons, just as long as we keep those in mind and work together. thanks! donald On Tue, May 29, 2018 at 3:04 PM, Jay Chen <jchen1(a)paloaltonetworks.com> wrote: > A quick question about FRR interfaces. The Zebra get interface information/status from Kernel. > > In our platform, it is almost impossible to put interface into kernel (due to history reasons people object to do so). Is there anyone else facing the same situation and any suggestions for a work around? Or anything similarly to FPM existing for interface to bypass kernel (from interface manager to Zebra instead)? > > Thanks, > Jay > >

5 12

no soft bgp clear is triggered on modification to prefixlist / routemap
by François 02 Aug '18

02 Aug '18

Hello, This issue has been discussed here : https://github.com/FRRouting/frr/issues/126 To sum up, when a route-map is modified (tried 2 things: adding a new entry and modifying prefix-list involved), no soft bgp clear is performed, so it looks like other peers never get new results (the "show advertised route" output is correct). Looks like "no route-map ... " and "route-map ..." again does the trick. My question is: do someone has an idea on how to fix that? I can give a shot, but I would appreciate some inputs ;) Ps: I use version 2 of FRR (because Vincent Jardin told that version 3 was not production ready at FRNog 29 ;)) Thanks! -- François

3 6

Fwd: FW: FRRouting - RIP VRF Support.
by Amit Tiwari 27 Jul '18

27 Jul '18

Hi Kunihiro, I have compiled FRRouting master branch and deployed it on my router, bgp and ospf are working fine with vrf. Whereas, in case of RIP, vrf doesn't seems to be working, there is no vrf support even at CLI level. May we know, when are you guys releasing frrouting with full vrf support in RIP. Regards, Amit Kumar Tiwari 9953769181

3 2

Current Maintainers
by Donald Sharp 01 Jul '18

01 Jul '18

All - This is the current list of maintainers: - Jafar Al-Gharaibeh - [@jafarl](https://github.com/jafaral) - Lou Berger - [@louberger](https://github.com/louberger) - Nicolas Dichtel [@nicolasdichtel](https://github.com/nicolasdichtel) - Olivier Dugeon - [@odd22](https://github.com/odd22) - Bingen Eguzkitza - [@bingen](https://github.com/bingen) - Christian Franke - [@cfra](https://github.com/cfra) - Philippe Guibert - [@pguibert6WIND](https://github.com/pguibert6WIND) - Vincent Jardin - [@vjardin6WIND](https://github.com/vjardin6WIND) - David Lamparter - [@eqvinox](https://github.com/eqvinox) - JR Rivers - [@jrrivers](https://github.com/jrrivers) - Donnie Savage - [@diivious](https://github.com/diivious) - Donald Sharp - [@donaldsharp](https://github.com/donaldsharp) - Daniel Walton [@dwalton76](https://github.com/dwalton76) - Renato Westphal - [@rwestphal](https://github.com/rwestphal) - Russ White - [@riw777](https://github.com/riw777) - Martin Winter - [@mwinter-osr](https://github.com/mwinter-osr) - Quentin Young - [@qlyoung](https://github.com/qlyoung) - Rafael Zalamena - [@rzalamena](https://github.com/rzalamena) If you would like to nominate yourself or someone else, please do so. I would like to discuss this at the next technical meeting. thanks! donald

2 2

FRR vrf, multi-instance
by Jia Chen 29 Jun '18

29 Jun '18

Hi All, A question about FRR way of supporting vrf, multi-instance, or logical router. A. OSPF/IS-IS multi-instance is a control plane concept, not forwarding B. VRF is both routing and forwarding, for example, L3vpn and EVPN, which uses RT, RD in BGP updates C. Virtual router is a non-VPN instance, which does not require RT, RD Both B and C, has a one-to-one interface to routing instance mapping. Are A, B, C all supported by FRR? Juniper has a logical system (or router), which divided physical router into logical sub-routers. Each logical router has dedicated interface, routing protocols, routing and forwarding table. Are there equivalent in FRR? Thanks, Jay On 6/28/18, 9:31 AM, "dev on behalf of Donald Sharp" <dev-bounces(a)lists.frrouting.org on behalf of sharpd(a)cumulusnetworks.com> wrote: Mark - Great idea, We'll start the meeting off with your talk. thanks! donald On Thu, Jun 28, 2018 at 11:58 AM, Mark Stapp <mjs(a)voltanet.io> wrote: > Hi, > I've been doing some work on the dataplane side of zebra, and I'd like to > talk a bit about the approach and outline some of the possible next-steps. > Could I have a few minutes at next week's dev meeting to introduce the > topic? The broad goals are sort of: > > * to harden the interface that zebra has with the dataplane or -planes that > are in use, > * to improve support for remote dataplanes, > * to allow dataplane/kernel updates to be moved to a dedicated pthread, > * to improve integration of FPM, and to include more events > > I've been working at first just to support asynchronous route/fib updates, > just to start exploring the possible approaches and to raise some questions. > > Thanks, > Mark > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_li… > _______________________________________________ dev mailing list dev(a)lists.frrouting.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_li…

3 5

intro asynch zebra work
by Mark Stapp 28 Jun '18

28 Jun '18

Hi, I've been doing some work on the dataplane side of zebra, and I'd like to talk a bit about the approach and outline some of the possible next-steps. Could I have a few minutes at next week's dev meeting to introduce the topic? The broad goals are sort of: * to harden the interface that zebra has with the dataplane or -planes that are in use, * to improve support for remote dataplanes, * to allow dataplane/kernel updates to be moved to a dedicated pthread, * to improve integration of FPM, and to include more events I've been working at first just to support asynchronous route/fib updates, just to start exploring the possible approaches and to raise some questions. Thanks, Mark

2 1

Recursive lookup through BGP-LU route
by Carl Baldwin 27 Jun '18

27 Jun '18

Hi, We're experimenting with BGP-LU and frr in our lab. We have two host machines running frr. Each is connected to two TOR switches through their eth0 and eth1 links (four TORs total). Those are connected through another pair of switches. We have configured BGP-LU to distribute MPLS labels over ebpg throughout. Connectivity between loopback addresses on the two hosts works well at this point. Then, I created some namespaces in the hosts and gave them addresses. We use BGP to announce those addresses as /32 routes with the loopback address as the next hop. The route between namespaces on the two machines is recursively resolved so that they push the same MPLS label as the path to the other loopback. This all works well to start off with and we did some iperf runs that showed pretty good results. ECMP was working because the bandwidth was higher than any single link. After some link state changes, we seemed to lose the connection. However, pings between the loopback addresses still worked. After some time, we noticed that the MPLS labels in the routes to the namespace addresses (/32s) were different than the label in the route to the loopback. Since the former routes are resolved recursively using the latter, the labels should always be the same. Could this be a bug in FRR? Shouldn't the routes to the namespaces be invalidated or updated as soon as the route it was based on changed? The traffic between namespaces is getting dropped because the switch doesn't know about the label being pushed by the host. Any insight would be very helpful. Thanks! Carl Baldwin Here are /32 routes received. 10.112.128.1 is the loopback on the other host. The four routes are to four namespaces on the other host. lab1r2u05# show ip bgp neighbor 10.112.97.1 received-routes BGP table version is 0, local router ID is 10.112.128.2 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.224.12.10/32 10.112.128.1 0 4206900001 4206909998 i *> 10.224.12.15/32 10.112.128.1 0 4206900001 4206909998 i *> 10.224.12.70/32 10.112.128.1 0 4206900001 4206909998 i *> 10.224.12.75/32 10.112.128.1 0 4206900001 4206909998 i Total number of prefixes 4 Below is the routing table as it looked when we lost connectivity. Notice that the mpls label for the loopback route is 306592 via eth1 but the label for the four namespace addresses is 306576. root@lab1r2u05:~/ovs-droplets# ip route default via 10.112.2.132 dev eth2 10.112.2.128/25 dev eth2 proto kernel scope link src 10.112.2.145 10.112.128.1 encap mpls 306592 via 10.112.129.9 dev eth1 proto 186 metric 20 10.112.129.8/30 dev eth1 proto kernel scope link src 10.112.129.10 10.112.129.12/30 dev eth0 proto kernel scope link src 10.112.129.14 10.224.12.10 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186 metric 20 10.224.12.15 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186 metric 20 10.224.12.70 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186 metric 20 10.224.12.75 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186 metric 20 10.224.12.20 dev br0 scope link 10.224.12.25 dev br0 scope link 10.224.12.80 dev br0 scope link 10.224.12.85 dev br0 scope link

2 3

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 22 Jun '18

22 Jun '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 28 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1470150: Null pointer dereferences (NULL_RETURNS) /lib/command.c: 2474 in command_setup_early_logging() ________________________________________________________________________________________________________ *** CID 1470150: Null pointer dereferences (NULL_RETURNS) /lib/command.c: 2474 in command_setup_early_logging() 2468 if (strcmp(dest, "syslog") == 0) { 2469 zlog_set_level(ZLOG_DEST_SYSLOG, zlog_default->default_lvl); 2470 return; 2471 } 2472 2473 token = strstr(dest, ":"); >>> CID 1470150: Null pointer dereferences (NULL_RETURNS) >>> Incrementing a pointer which might be null: "token". 2474 token++; 2475 2476 set_log_file(NULL, token, zlog_default->default_lvl); 2477 } 2478 2479 DEFUN (config_log_file, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

NetDev0x12 conference
by Donald Sharp 21 Jun '18

21 Jun '18

All - Just wanted to let everyone know that there is an upcoming NetDev conference in mid July: https://netdevconf.org/0x12/accepted-sessions.html I'll be presenting there and there will be a lot of people from the linux networking community at this conference. If you are interested check it out! donald

2 1

Participation in Public Slack Channel
by Cody Haas 20 Jun '18

20 Jun '18

Devs, The development team I am a part of has been working with FRR. We would like to participate in the public slack channel, emails are listed below: cody.haas(a)fuseintegration.com marc.haase(a)fuseintegration.com michael.covarrubias(a)fuseintegration.com Thanks, Cody Cody Haas Fuse 631.742.4173 <mailto:Cody.Haas@fuseintegration.com> Cody.Haas(a)fuseintegration.com

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 20 Jun '18

20 Jun '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1470113: (TAINTED_SCALAR) /zebra/zebra_netns_notify.c: 215 in zebra_ns_notify_read() /zebra/zebra_netns_notify.c: 219 in zebra_ns_notify_read() /zebra/zebra_netns_notify.c: 215 in zebra_ns_notify_read() /zebra/zebra_netns_notify.c: 219 in zebra_ns_notify_read() /zebra/zebra_netns_notify.c: 215 in zebra_ns_notify_read() /zebra/zebra_netns_notify.c: 219 in zebra_ns_notify_read() /zebra/zebra_netns_notify.c: 215 in zebra_ns_notify_read() /zebra/zebra_netns_notify.c: 219 in zebra_ns_notify_read() ________________________________________________________________________________________________________ *** CID 1470113: (TAINTED_SCALAR) /zebra/zebra_netns_notify.c: 215 in zebra_ns_notify_read() 209 struct zebra_netns_info *netnsinfo; 210 211 if (!(event->mask & (IN_CREATE | IN_DELETE))) 212 continue; 213 if (event->mask & IN_DELETE) 214 return zebra_ns_delete(event->name); >>> CID 1470113: (TAINTED_SCALAR) >>> Using tainted variable "event->len" as an index into an array "event->name". 215 if (&event->name[event->len] >= &buf[sizeof(buf)]) { 216 zlog_err("NS notify read: buffer underflow"); 217 break; 218 } 219 event->name[event->len] = 0; 220 netnspath = ns_netns_pathname(NULL, event->name); /zebra/zebra_netns_notify.c: 219 in zebra_ns_notify_read() 213 if (event->mask & IN_DELETE) 214 return zebra_ns_delete(event->name); 215 if (&event->name[event->len] >= &buf[sizeof(buf)]) { 216 zlog_err("NS notify read: buffer underflow"); 217 break; 218 } >>> CID 1470113: (TAINTED_SCALAR) >>> Using tainted variable "event->len" as an index into an array "event->name". 219 event->name[event->len] = 0; 220 netnspath = ns_netns_pathname(NULL, event->name); 221 if (!netnspath) 222 continue; 223 netnspath = XSTRDUP(MTYPE_NETNS_MISC, netnspath); 224 netnsinfo = XCALLOC(MTYPE_NETNS_MISC, /zebra/zebra_netns_notify.c: 215 in zebra_ns_notify_read() 209 struct zebra_netns_info *netnsinfo; 210 211 if (!(event->mask & (IN_CREATE | IN_DELETE))) 212 continue; 213 if (event->mask & IN_DELETE) 214 return zebra_ns_delete(event->name); >>> CID 1470113: (TAINTED_SCALAR) >>> Using tainted variable "event->len" as an index into an array "event->name". 215 if (&event->name[event->len] >= &buf[sizeof(buf)]) { 216 zlog_err("NS notify read: buffer underflow"); 217 break; 218 } 219 event->name[event->len] = 0; 220 netnspath = ns_netns_pathname(NULL, event->name); /zebra/zebra_netns_notify.c: 219 in zebra_ns_notify_read() 213 if (event->mask & IN_DELETE) 214 return zebra_ns_delete(event->name); 215 if (&event->name[event->len] >= &buf[sizeof(buf)]) { 216 zlog_err("NS notify read: buffer underflow"); 217 break; 218 } >>> CID 1470113: (TAINTED_SCALAR) >>> Using tainted variable "event->len" as an index into an array "event->name". 219 event->name[event->len] = 0; 220 netnspath = ns_netns_pathname(NULL, event->name); 221 if (!netnspath) 222 continue; 223 netnspath = XSTRDUP(MTYPE_NETNS_MISC, netnspath); 224 netnsinfo = XCALLOC(MTYPE_NETNS_MISC, /zebra/zebra_netns_notify.c: 215 in zebra_ns_notify_read() 209 struct zebra_netns_info *netnsinfo; 210 211 if (!(event->mask & (IN_CREATE | IN_DELETE))) 212 continue; 213 if (event->mask & IN_DELETE) 214 return zebra_ns_delete(event->name); >>> CID 1470113: (TAINTED_SCALAR) >>> Using tainted variable "event->len" as an index into an array "event->name". 215 if (&event->name[event->len] >= &buf[sizeof(buf)]) { 216 zlog_err("NS notify read: buffer underflow"); 217 break; 218 } 219 event->name[event->len] = 0; 220 netnspath = ns_netns_pathname(NULL, event->name); /zebra/zebra_netns_notify.c: 219 in zebra_ns_notify_read() 213 if (event->mask & IN_DELETE) 214 return zebra_ns_delete(event->name); 215 if (&event->name[event->len] >= &buf[sizeof(buf)]) { 216 zlog_err("NS notify read: buffer underflow"); 217 break; 218 } >>> CID 1470113: (TAINTED_SCALAR) >>> Using tainted variable "event->len" as an index into an array "event->name". 219 event->name[event->len] = 0; 220 netnspath = ns_netns_pathname(NULL, event->name); 221 if (!netnspath) 222 continue; 223 netnspath = XSTRDUP(MTYPE_NETNS_MISC, netnspath); 224 netnsinfo = XCALLOC(MTYPE_NETNS_MISC, /zebra/zebra_netns_notify.c: 215 in zebra_ns_notify_read() 209 struct zebra_netns_info *netnsinfo; 210 211 if (!(event->mask & (IN_CREATE | IN_DELETE))) 212 continue; 213 if (event->mask & IN_DELETE) 214 return zebra_ns_delete(event->name); >>> CID 1470113: (TAINTED_SCALAR) >>> Using tainted variable "event->len" as an index into an array "event->name". 215 if (&event->name[event->len] >= &buf[sizeof(buf)]) { 216 zlog_err("NS notify read: buffer underflow"); 217 break; 218 } 219 event->name[event->len] = 0; 220 netnspath = ns_netns_pathname(NULL, event->name); /zebra/zebra_netns_notify.c: 219 in zebra_ns_notify_read() 213 if (event->mask & IN_DELETE) 214 return zebra_ns_delete(event->name); 215 if (&event->name[event->len] >= &buf[sizeof(buf)]) { 216 zlog_err("NS notify read: buffer underflow"); 217 break; 218 } >>> CID 1470113: (TAINTED_SCALAR) >>> Using tainted variable "event->len" as an index into an array "event->name". 219 event->name[event->len] = 0; 220 netnspath = ns_netns_pathname(NULL, event->name); 221 if (!netnspath) 222 continue; 223 netnspath = XSTRDUP(MTYPE_NETNS_MISC, netnspath); 224 netnsinfo = XCALLOC(MTYPE_NETNS_MISC, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Adding SQLite as a new optional dependency
by Renato Westphal 20 Jun '18

20 Jun '18

Hi all, As part of the work in the new northbound architecture, I implemented support for configuration rollbacks in FRR. Here's a short demo: https://gist.github.com/rwestphal/caedd9f3e4888cab2d631cc21967e93d To make this work, FRR needs to keep track of all committed configuration transactions in non-volatile memory (so they persist across reboots). One possibility to implement this would be to store the transactions using text files in the filesystem. The problem with this approach is that it would be necessary to write a lot of code to do things correctly, handling all possible errors (lots of things can go wrong). Using SQLite we have database transactions, which make things much easier (either all operations succeed or none do). SQLite in general provides a much better interface to store and retrieve transactions, not to mention its high-performance properties. I consider it to be the right tool for the job. But if anyone has an objection against using SQLite in FRR please speak up. Initially SQLite should be added as an optional dependency tied to the --enable-config-rollbacks configuration option. This way users not interested on configuration rollbacks won't need to install the new dependency. We might revisit this in the future if we find other use cases for SQLite in FRR. When FRR is built with --enable-config-rollbacks, all daemons will have a new option to specify the path of the daemon-specific database file: --db-file (the default is ${localstatedir}/<daemon-name>.db). The special :memory: filename can be used to open a new in-memory database (which doesn't persist across reboots or daemon restarts). I should say that configuration rollbacks will only work for daemons converted to the new northbound model. Speaking of which, the Northbound API is almost ready to be submitted as a PR. I'm finishing to polish the code and writing documentation, my estimation is that everything should be ready within the following two weeks. Regards, -- Renato Westphal

7 8

[19/06/2018] FRR Technical Meeting Notes
by Quentin Young 19 Jun '18

19 Jun '18

FRR Technical Meeting Notes - 06/19/2018 ========================================= Misc Issues ----------- - Chat software - We want to move off Slack due to message history loss, proprietary platform, etc. - Options considered thus far are Rocket.chat and MatterMost - Some discussion on importance of VOIP call support - Beyond VOIP they seem largely equivalent - Quentin to evaluate Matrix / Riot and report back - Aiming to have a decision within next 2 weeks - Maintainers - It's been roughly a year since the maintainers list was updated - Nominate yourself or others to become maintainers on the dev mailing list over the next couple weeks - Moving EVPN commands out of #ifdef ENABLE_CUMULUS - EVPN requires --enable-cumulus at present - This requires people to build FRR themselves if they want EVPN support - Many people have asked that EVPN be enabled without this flag - General agreement: this is a good idea - lberger: Need to evaluate collateral damage on affected other commands - sharpd: Will list out the affected commands for individual evaluation by all parties (see dev alias email) Github Issues & PR’s ——————————— See updates in the issues and PRs

2 1

evpn commands under --enable-cumulus
by Donald Sharp 19 Jun '18

19 Jun '18

As discussed in today's technical meeting: address-family l2vpn evpn (BGP_EVPN_NODE) [no] advertise-default-gw [no] advertise-all-vni [no] autort rfc8365-compatible [no] default-originate <ipv4|ipv6> [no] advertise AFI SAFI [route-map WORD] [no] rd ASN:NN_OR_IP-ADDRESS:NN [no] route-target <both|import|export> RT advertise es ESI withdraw es ESI [no] vni (1-1677721) (BGP_EVPN_VNI_NODE) [no] advertise-default-gw [no] advertise-subnet (This is hidden) [no] rd ASN:NN_OR_IP-ADDRESS:NN [no] route-target <both|import|export> RT exit-vni show bgp l2vpn evpn vni [(1-16777215)] [json] show bgp l2vpn evpn es [ESI] [json] show bgp [vrf VRFNAME] l2vpn evpn summary [json] show bgp l2vpn evpn route [type <macip|multicast|es|prefix>] [json] show bgp l2vpn evpn route rd ASN:NN_OR_IP-ADDRESS:NN [type <macip|multicast|es|prefix>] [json] show bgp l2vpn evpn route rd ASN:NN_OR_IP-ADDRESS:NN mac WORD [ip WORD] [json] show bgp l2vpn evpn route esi ESI [json] show bgp l2vpn evpn route vni (1-16777215) [<type <macip|multicast> | vtep A.B.C.D>] [json] show bgp l2vpn evpn route vni (1-16777215) mac WORD [ip WORD] [json] show bgp l2vpn evpn route vni (1-16777215) multicast A.B.C.D [json] show bgp l2vpn evpn route vni all [vtep A.B.C.D] [json] show bgp l2vpn evpn vrf-import-rt [json] show bgp l2vpn evpn import-rt [json] show bgp vrf VRFNAME vni [json] Hidden Show commands( To provide backwards compatability for anyone who may have used these ) show bgp evpn vni [(1-16777215)] show bgp evpn summary [json] show bgp evpn route [type <macip|multicast>] show bgp evpn route rd ASN:NN_OR_IP-ADDRESS:NN [type <macip|multicast>] show bgp evpn route rd ASN:NN_OR_IP-ADDRESS:NN mac WORD [ip WORD] show bgp evpn route vni (1-16777215) [<type <macip|multicast> | vtep A.B.C.D>] show bgp evpn route vni (1-16777215) mac WORD [ip WORD] show bgp evpn route vni (1-16777215) multicast A.B.C.D show bgp evpn route vni all [vtep A.B.C.D] show bgp evpn import-rt

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 19 Jun '18

19 Jun '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1470098: Control flow issues (DEADCODE) /bgpd/bgp_vpn.c: 232 in show_adj_route_vpn() ________________________________________________________________________________________________________ *** CID 1470098: Control flow issues (DEADCODE) /bgpd/bgp_vpn.c: 232 in show_adj_route_vpn() 226 route_vty_out_tmp(vty, &rm->p, attr, 227 SAFI_MPLS_VPN, 228 use_json, json_array); 229 } 230 } 231 if (use_json && rm) { >>> CID 1470098: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "char buf_a[8192];". 232 char buf_a[BUFSIZ]; 233 char buf_b[BUFSIZ]; 234 sprintf(buf_a, "%s/%d", 235 inet_ntop(rm->p.family, rm->p.u.val, 236 buf_b, BUFSIZ), 237 rm->p.prefixlen); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Invite to Slack channel?
by JP Senior 12 Jun '18

12 Jun '18

Hello, there! I wonder if I or our domain @apstra.com can get an invite or whitelist to the FRRouting slack channel? We've got a lot of cool stuff to talk about with regards to EVPN and EVPN inter-operability. -- JP Senior | Apstra, Inc c: +1.403.970.4965 e: jp(a)apstra.com www.apstra.com | Vendor-Agnostic Data Center Network Automation

7 9

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 11 Jun '18

11 Jun '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 6 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 4 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1469898: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1469898: Uninitialized variables (UNINIT) /lib/command.c: 270 in argv_concat() 264 int cnt = argc - shift; 265 const char *argstr[cnt]; 266 267 for (int i = 0; i < cnt; i++) 268 argstr[i] = argv[i + shift]->arg; 269 >>> CID 1469898: Uninitialized variables (UNINIT) >>> Using uninitialized element of array "argstr" when calling "frrstr_join". 270 return frrstr_join(argstr, cnt, " "); 271 } 272 273 vector cmd_make_strvec(const char *string) 274 { 275 if (!string) ** CID 1469897: Memory - corruptions (OVERRUN) /bgpd/bgp_route.c: 6978 in route_vty_out_tag() ________________________________________________________________________________________________________ *** CID 1469897: Memory - corruptions (OVERRUN) /bgpd/bgp_route.c: 6978 in route_vty_out_tag() 6972 } else if (attr->mp_nexthop_len 6973 == BGP_ATTR_NHLEN_IPV6_GLOBAL_AND_LL) { 6974 if (json) { 6975 inet_ntop(AF_INET6, 6976 &attr->mp_nexthop_global, 6977 buf_a, BUFSIZ); >>> CID 1469897: Memory - corruptions (OVERRUN) >>> Overrunning array "buf_b" of 512 bytes by passing it to a function which accesses it at byte offset 8191 using argument "8192U". 6978 inet_ntop(AF_INET6, 6979 &attr->mp_nexthop_local, 6980 buf_b, BUFSIZ); 6981 sprintf(buf_c, "%s(%s)", buf_a, buf_b); 6982 json_object_string_add( 6983 json_out, ** CID 1469896: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1469896: Null pointer dereferences (FORWARD_NULL) /vtysh/vtysh.c: 556 in vtysh_execute_func() 550 551 if (vline == NULL && vty->is_paged) { 552 vty_close_pager(vty); 553 return CMD_SUCCESS; 554 } 555 >>> CID 1469896: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "vline" to "cmd_execute_command", which dereferences it. 556 ret = cmd_execute_command(vline, vty, &cmd, 1); 557 cmd_free_strvec(vline); 558 if (ret != CMD_SUCCESS_DAEMON) 559 break; 560 } else if (cmd->func) { 561 (*cmd->func)(cmd, vty, 0, NULL); ** CID 1469895: Null pointer dereferences (FORWARD_NULL) /lib/vty.c: 129 in vty_set_include() ________________________________________________________________________________________________________ *** CID 1469895: Null pointer dereferences (FORWARD_NULL) /lib/vty.c: 129 in vty_set_include() 123 if (!regexp && vty->filter) { 124 regfree(&vty->include); 125 vty->filter = false; 126 return true; 127 } 128 >>> CID 1469895: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "regexp" to "regcomp", which dereferences it. 129 errcode = regcomp(&vty->include, regexp, 130 REG_EXTENDED | REG_NEWLINE | REG_NOSUB); 131 if (errcode) { 132 ret = false; 133 regerror(ret, &vty->include, errbuf, sizeof(errbuf)); 134 vty_out(vty, "%% Regex compilation error: %s", errbuf); ** CID 1469894: Null pointer dereferences (NULL_RETURNS) /lib/command.c: 1216 in handle_pipe_action() ________________________________________________________________________________________________________ *** CID 1469894: Null pointer dereferences (NULL_RETURNS) /lib/command.c: 1216 in handle_pipe_action() 1210 1211 if (!succ) { 1212 vty_out(vty, "%% Bad regexp '%s'\n", regexp); 1213 goto fail; 1214 } 1215 *cmd_out = XSTRDUP(MTYPE_TMP, cmd_in); >>> CID 1469894: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "strstr(*cmd_out, "|")". 1216 *(strstr(*cmd_out, "|")) = '\0'; 1217 } else { 1218 vty_out(vty, "%% Unknown action '%s'\n", token); 1219 goto fail; 1220 } 1221 ** CID 1469893: Memory - corruptions (OVERRUN) /bgpd/bgp_route.c: 6975 in route_vty_out_tag() ________________________________________________________________________________________________________ *** CID 1469893: Memory - corruptions (OVERRUN) /bgpd/bgp_route.c: 6975 in route_vty_out_tag() 6969 AF_INET6, 6970 &attr->mp_nexthop_global, 6971 buf_a, BUFSIZ)); 6972 } else if (attr->mp_nexthop_len 6973 == BGP_ATTR_NHLEN_IPV6_GLOBAL_AND_LL) { 6974 if (json) { >>> CID 1469893: Memory - corruptions (OVERRUN) >>> Overrunning array "buf_a" of 512 bytes by passing it to a function which accesses it at byte offset 8191 using argument "8192U". 6975 inet_ntop(AF_INET6, 6976 &attr->mp_nexthop_global, 6977 buf_a, BUFSIZ); 6978 inet_ntop(AF_INET6, 6979 &attr->mp_nexthop_local, 6980 buf_b, BUFSIZ); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0