- dev - lists.frrouting.org

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 23 Jun '18

23 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 21 Jun '18

21 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 21 Jun '18

21 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 20 Jun '18

20 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 20 Jun '18

20 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