September 2017 - dev - lists.frrouting.org

Missing developer documentation
by Olivier Dugeon 12 Dec '17

12 Dec '17

Hiall, There is missing developer documentation in FRR. In PR #805 I try to update an old Zebra hacking document, but that seems too old to be publish, so I prefer to remove it as suggested during the PR review. For me, the main problem is how to start writing a such documentation ? First, it is too huge and to complicated to be written by only one person. Second, we need a dedicated space (e.g. a new doc project inside FRRouting) to collectively write such documentation and then push into frr master documents when they are ready. Finally, we need to organize themselves in order to collectively decided how to write them, to formalize the document through a common template, to harmonize the documentation... I would start by proposing: * start discussion about this new topic (create a new issue in github) during regular meeting * decide the document format (Markdown, in line github Wiki, LaTeX, TeXi ...) * create a new doc project within FRRouting * propose template * propose Table of Content for each document (perhaps partially common) * open contribution to the different documents Comments are welcome. Regards Olivier

4 6

Problems regarding BGP code 2, sub-code 7 when peering with Cisco IOS-XR Version 4.2.3 over IPv6
by Christoffer Hansen 19 Oct '17

19 Oct '17

FRRouting-Dev <dev(a)lists.frrouting.org> Hit an interesting issue today. (for reference a lot of technical details below) I found myself unable to locate the option of turning BGP code 2, sub-code 7 off when sending capabilities to a neighbor. (Spent some time googling around but mostly found Cisco IOS-XR related stuff) It appears Cisco IOS-XR does not yet support the use off 'additional-paths' (BGP code 2, sub-code 7) when exchanging neighbor capabilities. But ONLY for IPv6 (IPv4 is supported). So my question to the list (if anyone finds the time to answer) is: Does FFRouting contain an option to turn off the multi-path feature / specific sub-code when announcing BGPv4 capabilities to it's neighbor(s) over IPv6 (or both IPv4/v6) ? Nb: And yes. Have tried disabling sending capabilities to the IOS-XR router altogether. But the the Cisco router just refuses because no capabilities is announced from neighbor. Nb(2): Capability option is set to 'Dynamic' when announcing to neighbor. -- Regards, Christoffer. gpg: c8b3 82a8 a1cd cdb7 71fe b24c c654 948f da86 becd Software Details ================ pfSense v2.3.4 -------------- * Name: frr * Category: net * Version: 0.0.2 * Description: FRR routing daemon for BGP, OSPF, and OSPF6 Conflicts with Quagga OSPF and OpenBGPD. These packages cannot be installed at the same time. Debug output from Cisco IOS XR Software, Version 4.2.3[Default] =============================================================== * NOTE(1): IPv6 network prefix replaced with '2001:db8::' RP/0/RSP0/CPU0:Sep 26 16:49:36.532 MEST: bgp[1048]: [default-ioct] VRF Internet: 2001:db8:::250:56ff:febd:7e57 went from Idle to Connect RP/0/RSP0/CPU0:Sep 26 16:49:36.754 MEST: bgp[1048]: [default-iord] VRF Internet: Received message from 2001:db8:::250:56ff:febd:7e57 with type 1, length (incl. header) 102 RP/0/RSP0/CPU0:Sep 26 16:49:36.754 MEST: bgp[1048]: [default-iord] VRF Internet: Receive message dump for 2001:db8:::250:56ff:febd:7e57: RP/0/RSP0/CPU0:Sep 26 16:49:36.754 MEST: bgp[1048]: [default-iord] VRF Internet: ffff ffff ffff ffff ffff ffff ffff ffff RP/0/RSP0/CPU0:Sep 26 16:49:36.755 MEST: bgp[1048]: [default-iord] VRF Internet: 0066 0104 ff4c 0078 5774 0604 4902 0601 RP/0/RSP0/CPU0:Sep 26 16:49:36.755 MEST: bgp[1048]: [default-iord] VRF Internet: 0400 0100 0102 0280 0002 0202 0002 0641 RP/0/RSP0/CPU0:Sep 26 16:49:36.755 MEST: bgp[1048]: [default-iord] VRF Internet: 0400 00ff 4c02 0645 0400 0101 0102 0242 RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: 0002 0243 0002 1949 1715 6677 3031 2e6c RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: 6162 2e6e 6574 7261 766e 656e 2e65 7500 RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: 0204 4002 8078 RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: Received OPEN from 2001:db8:::250:56ff:febd:7e57, version 4, holdtime 120 secs RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 6 RP/0/RSP0/CPU0:Sep 26 16:49:36.756 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has MULTIPROTOCOL_EXTENSION capability for afi/safi: 1/1 RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 2 RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has ROUTE-REFRESH capability(old) for all address-families RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 2 RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has ROUTE-REFRESH capability for all address-families RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 6 RP/0/RSP0/CPU0:Sep 26 16:49:36.757 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has 4-byte AS capability with AS 65356 RP/0/RSP0/CPU0:Sep 26 16:49:36.758 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 6 RP/0/RSP0/CPU0:Sep 26 16:49:36.758 MEST: bgp[1048]: [default-iord] VRF Internet: 2001:db8:::250:56ff:febd:7e57 Addr-family 1/1 not supported: Ignoring the ADDPATH capability RP/0/RSP0/CPU0:Sep 26 16:49:36.758 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 2 RP/0/RSP0/CPU0:Sep 26 16:49:36.758 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has unrecognized capability code: 66, length 0 (ignored) RP/0/RSP0/CPU0:Sep 26 16:49:36.758 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 2 RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has unrecognized capability code: 67, length 0 (ignored) RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 25 RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has unrecognized capability code: 73, length 23 (ignored) RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has optional parameter type: 2 (Capability) len: 4 RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: bgp_io_read_schedule_updgrp: NO updgrp scheduled after Open processing: nbr=2001:db8:::250:56ff:febd:7e57, nbrfl=0x08314080 RP/0/RSP0/CPU0:Sep 26 16:49:36.759 MEST: bgp[1048]: [default-iord] VRF Internet: 2001:db8:::250:56ff:febd:7e57 went from Connect to OpenSent RP/0/RSP0/CPU0:Sep 26 16:49:36.760 MEST: bgp[1048]: [default-iord] VRF Internet: Sending OPEN to 2001:db8:::250:56ff:febd:7e57, version 4, my as: 31027, holdtime 120 seconds RP/0/RSP0/CPU0:Sep 26 16:49:36.760 MEST: bgp[1048]: [default-iord] VRF Internet: OPEN from 2001:db8:::250:56ff:febd:7e57 has capabilities with no supported address-family. RP/0/RSP0/CPU0:Sep 26 16:49:36.760 MEST: bgp[1048]: [default-iord] VRF Internet: Sending NOTIFICATION 2/7 (unsupported/disjoint capability) to 2001:db8:::250:56ff:febd:7e57 (0 bytes: ) RP/0/RSP0/CPU0:Sep 26 16:49:36.760 MEST: bgp[1048]: [default-iord] VRF Internet: 2001:db8:::250:56ff:febd:7e57 went from OpenSent to Closing RP/0/RSP0/CPU0:Sep 26 16:49:36.761 MEST: bgp[1048]: [default-ioct] VRF Internet: 2001:db8:::250:56ff:febd:7e57 send message type 3, length (incl. header) 21 RP/0/RSP0/CPU0:Sep 26 16:49:36.761 MEST: bgp[1048]: [default-ioct] VRF Internet: Send message dump for 2001:db8:::250:56ff:febd:7e57: RP/0/RSP0/CPU0:Sep 26 16:49:36.761 MEST: bgp[1048]: [default-ioct] VRF Internet: ffff ffff ffff ffff ffff ffff ffff ffff RP/0/RSP0/CPU0:Sep 26 16:49:36.761 MEST: bgp[1048]: [default-ioct] VRF Internet: 0015 0302 07 RP/0/RSP0/CPU0:Sep 26 16:49:36.762 MEST: bgp[1048]: [default-event] VRF Internet: 2001:db8:::250:56ff:febd:7e57 went from Closing to Idle RP/0/RSP0/CPU0:Sep 26 16:49:36.762 MEST: bgp[1048]: [default-event] VRF Internet: 2001:db8:::250:56ff:febd:7e57 reset due to BGP Notification sent Output from pfSense FRR routing daemon ====================================== * NOTE(1): IPv6 network prefix replaced with '2001:db8::' * NOTE(2): IPv4 next-hop replaced with TEST-NET-3 address 203.0.113.4 BGP neighbor is 2001:db8::1, remote AS #ISP-ASN#, local AS 65356, external link BGP version 4, remote router ID 0.0.0.0 BGP state = Idle Last read 00:00:27, Last write 00:00:11 Hold time is 120, keepalive interval is 40 seconds Message statistics: Inq depth is 0 Outq depth is 0 Sent Rcvd Opens: 4 0 Notifications: 0 4 Updates: 0 0 Keepalives: 0 0 Route Refresh: 0 0 Capability: 0 0 Total: 4 4 Minimum time between advertisement runs is 0 seconds Update source is 2001:db8::250:56ff:febd:7e57 For address family: IPv4 Unicast Not part of any update group Community attribute sent to this neighbor(extended) 0 accepted prefixes Connections established 0; dropped 0 Last reset 00:00:27, due to NOTIFICATION received (OPEN Message Error/Unsupported Capability) Local host: 2001:db8::250:56ff:febd:7e57, Local port: 57277 Foreign host: 2001:db8::1, Foreign port: 179 Nexthop: 203.0.113.4 Nexthop global: 2001:db8::250:56ff:febd:7e57 Nexthop local: fe80::250:56ff:febd:7e57 BGP connection: shared network BGP Connect Retry Timer in Seconds: 120 Next start timer due in 5 seconds Read thread: off Write thread: off

2 5

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 28 Sep '17

28 Sep '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 5 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 1457194: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 102 in ip_route_blackhole() ________________________________________________________________________________________________________ *** CID 1457194: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 102 in ip_route_blackhole() 96 #if 8 /* anything to parse? */ 97 int _i; 98 #if 1 /* anything that can fail? */ 99 unsigned _fail = 0, _failcnt = 0; 100 #endif 101 const char *no = NULL; >>> CID 1457194: Null pointer dereferences (FORWARD_NULL) >>> Assigning: "prefix" = "NULL". 102 const char *prefix = NULL; 103 struct in_addr mask = { INADDR_ANY }; 104 const char *mask_str = NULL; 105 const char *flag = NULL; 106 long tag = 0; 107 const char *tag_str = NULL; ** CID 1457193: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 489 in ipv6_route_address_interface() ________________________________________________________________________________________________________ *** CID 1457193: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 489 in ipv6_route_address_interface() 483 int _i; 484 #if 1 /* anything that can fail? */ 485 unsigned _fail = 0, _failcnt = 0; 486 #endif 487 const char *no = NULL; 488 struct prefix_ipv6 prefix = { }; >>> CID 1457193: Null pointer dereferences (FORWARD_NULL) >>> Assigning: "prefix_str" = "NULL". 489 const char *prefix_str = NULL; 490 struct prefix_ipv6 from = { }; 491 const char *from_str = NULL; 492 struct in6_addr gate = IN6ADDR_ANY_INIT; 493 const char *gate_str = NULL; 494 const char *ifname = NULL; ** CID 1457192: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 195 in ip_route_address_interface() ________________________________________________________________________________________________________ *** CID 1457192: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 195 in ip_route_address_interface() 189 #if 9 /* anything to parse? */ 190 int _i; 191 #if 1 /* anything that can fail? */ 192 unsigned _fail = 0, _failcnt = 0; 193 #endif 194 const char *no = NULL; >>> CID 1457192: Null pointer dereferences (FORWARD_NULL) >>> Assigning: "prefix" = "NULL". 195 const char *prefix = NULL; 196 struct in_addr mask = { INADDR_ANY }; 197 const char *mask_str = NULL; 198 struct in_addr gate = { INADDR_ANY }; 199 const char *gate_str = NULL; 200 const char *ifname = NULL; ** CID 1457191: Uninitialized variables (UNINIT) /pimd/pim_cmd.c: 6505 in interface_no_ip_pim_boundary_oil() ________________________________________________________________________________________________________ *** CID 1457191: Uninitialized variables (UNINIT) /pimd/pim_cmd.c: 6505 in interface_no_ip_pim_boundary_oil() 6499 "Define multicast boundary\n" 6500 "Filter OIL by group using prefix list\n" 6501 "Prefix list to filter OIL with") 6502 { 6503 VTY_DECLVAR_CONTEXT(interface, iif); 6504 struct pim_interface *pim_ifp; >>> CID 1457191: Uninitialized variables (UNINIT) >>> Declaring variable "idx" without initializer. 6505 int idx; 6506 6507 argv_find(argv, argc, "WORD", &idx); 6508 6509 PIM_GET_PIM_INTERFACE(pim_ifp, iif); 6510 ** CID 1457190: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 393 in ipv6_route_blackhole() ________________________________________________________________________________________________________ *** CID 1457190: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 393 in ipv6_route_blackhole() 387 int _i; 388 #if 1 /* anything that can fail? */ 389 unsigned _fail = 0, _failcnt = 0; 390 #endif 391 const char *no = NULL; 392 struct prefix_ipv6 prefix = { }; >>> CID 1457190: Null pointer dereferences (FORWARD_NULL) >>> Assigning: "prefix_str" = "NULL". 393 const char *prefix_str = NULL; 394 struct prefix_ipv6 from = { }; 395 const char *from_str = NULL; 396 const char *flag = NULL; 397 long tag = 0; 398 const char *tag_str = NULL; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Modify ZEBRA_ROUTE_KERNEL priority/metric read in linux
by Donald Sharp 27 Sep '17

27 Sep '17

All - This PR: https://github.com/FRRouting/frr/pull/1237 has received a request that we spend a bit of time disseminating the problem and this proposed fix for more feedback. The Problem: Linux kernel VRF table lookups follow this behavior: Lookup up in the table prefix A. If no route is found fall back to the main default table and lookup prefix A again. This behavior is considered 'surprising' to people who expect the behavior of VRF's to stop looking when nothing is found in the corresponding table. The linux kernel coders documented that a default unreachable route with a high metric should be installed into the VRF table to prevent the fallback mechanism from being invoked in the kernel. Prior to mid-August this was not that big of a deal as that default unreachable routes were being ignored by rt_netlink.c. As such when a zebra( or higher ) installed a default route, zebra would not have knowledge of the default unreachable route and so zebra would make the decision to just install the default route. Since zebra installs routes into the kernel with a metric of 20, the new default route would be used. So After mid August, zebra started seeing the default unreachable kernel route. This default unreachable received an admin distance of 0. As such when FRR attempted to install another default route it would fail the admin distance check and not be installed. The Proposal: Since there is no good way to specify admin distance to/from the kernel currently, let's interpret the metric/priority for ZEBRA_ROUTE_KERNEL routes a bit differently admin distance == High order byte of metric passed from kernel metric == Low 3 bytes of metric passed from kernel What this allows: The vrf creator scripts( something like iproute2 ) can be modified to use a metric that would correspond to an admin distance of 255. This way when the default unreachable is read we translate the metric to Admin distance = 255 metric = <some value> This allows zebra to allow static routes and routing protocols to override the default unreachable and it allows people who do not modify the metric values for normal ( ip route .... commands ) for their routes to behave like they think it should (the kernel should win) This does not affect *bsd because most bsd's have a uint8_t metric and we will not change behavior their. donald

1 1

IPv6 Multihop BGP & Vendor specific capability 131
by David Hooton 27 Sep '17

27 Sep '17

Hi All, I’m running 3.0-rc2 and appear to have found a bug in the IPv6 multihop BGP code. The box is configured to peer with a 3rd party ASR9000 and can’t seem to keep the session up. It will download ~30,000 routes then reset the session with the following errors in the logs. Sep 27 19:19:45 ord-285eec43a74305dd bgpd[16943]: bgp_mp_reach_parse: (2001:XX00:100::30:XXX) Failed to read NLRI Sep 27 19:19:45 ord-285eec43a74305dd bgpd[16943]: %NOTIFICATION: sent to neighbor 2001:XX00:100::30:XXX 3/1 (UPDATE Message Error/Malformed Attribute List) 0 bytes Sep 27 19:19:45 ord-285eec43a74305dd bgpd[16943]: 2001:XX00:100::30:XXX: Attribute MP_REACH_NLRI, parse error Sep 27 19:19:45 ord-285eec43a74305dd bgpd[16943]: %ADJCHANGE: neighbor 2001:XX00:100::30:XXX(Unknown) in vrf Default Down BGP Notification send Sep 27 19:19:47 ord-285eec43a74305dd bgpd[16943]: 2001:XX00:100::30:XXX Vendor specific capability 131 Sep 27 19:19:47 ord-285eec43a74305dd bgpd[16943]: %ADJCHANGE: neighbor 2001:XX00:100::30:XXX(Unknown) in vrf Default Up Sep 27 19:19:49 ord-285eec43a74305dd bgpd[16943]: bgp_mp_reach_parse: (2001:XX00:100::30:XXX) Failed to read NLRI Sep 27 19:19:49 ord-285eec43a74305dd bgpd[16943]: %NOTIFICATION: sent to neighbor 2001:XX00:100::30:XXX 3/1 (UPDATE Message Error/Malformed Attribute List) 0 bytes Sep 27 19:19:49 ord-285eec43a74305dd bgpd[16943]: 2001:XX00:100::30:XXX: Attribute MP_REACH_NLRI, parse error Sep 27 19:19:49 ord-285eec43a74305dd bgpd[16943]: %ADJCHANGE: neighbor 2001:XX00:100::30:XXX(Unknown) in vrf Default Down BGP Notification send A single hop BGP session seems to work fine, it is just the multihop sessions which won’t stay up. Any suggestions? Kind Regards, David Hooton Founder | Ordnance Cloud Scale, Carrier Grade P: +61415850000<tel:+61415850000> T: @dave_hooton W: ordnance.co

2 2

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 27 Sep '17

27 Sep '17

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. 1 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 1457145: Memory - corruptions (ARRAY_VS_SINGLETON) /lib/plist.c: 726 in prefix_list_apply_which_prefix() ________________________________________________________________________________________________________ *** CID 1457145: Memory - corruptions (ARRAY_VS_SINGLETON) /lib/plist.c: 726 in prefix_list_apply_which_prefix() 720 721 if (--depth) { 722 if (!table->entries[*byte].next_table) 723 break; 724 725 table = table->entries[*byte].next_table; >>> CID 1457145: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Using "byte" as an array. This might corrupt or misinterpret adjacent memory locations. 726 byte++; 727 continue; 728 } 729 730 for (pentry = table->entries[*byte].final_chain; pentry; 731 pentry = pentry->next_best) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

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

22 Sep '17

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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1457040: Possible Control flow issues (DEADCODE) /zebra/rt_netlink.c: 1346 in netlink_route_multipath() ________________________________________________________________________________________________________ *** CID 1457040: Possible Control flow issues (DEADCODE) /zebra/rt_netlink.c: 1346 in netlink_route_multipath() 1340 else { 1341 req.r.rtm_table = RT_TABLE_UNSPEC; 1342 addattr32(&req.n, sizeof req, RTA_TABLE, re->table); 1343 } 1344 1345 if (discard) >>> CID 1457040: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "goto skip;". 1346 goto skip; 1347 1348 if (re->mtu || re->nexthop_mtu) { 1349 char buf[NL_PKT_BUF_SIZE]; 1350 struct rtattr *rta = (void *)buf; 1351 u_int32_t mtu = re->mtu; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "frr(a)lists.nox.tf", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

List of Maintainers
by Donald Sharp 19 Sep '17

19 Sep '17

All -- During todays technical meeting we discussed formalizing the list of maintainers on github -> frrouting.org website list. The current list is( in no particular order ): Russ White Daniel Walton Bingen Eguzkitza Renato Westphal Christian Franke Martin Winter David Lamparter JR Rivers Lou Berger Donnie Savage Quentin Young Olivier Dugeon Vincent Jardin Donald Sharp Jafar Al-Gharaibeh Nicolas Dichtel Philippe Guibert 1) If you are on this list and no-longer want to be, please feel free to let the TSC know and we will remove you 2) If you are not on this list and would like to be, please feel free to let the TSC know Thanks! donald

1 0

Babel Admin Distance
by Donald Sharp 13 Sep '17

13 Sep '17

All - Renato and I noticed that zebra was not properly handling Admin distance correctly. As part of cleaenup we created this PR: https://github.com/FRRouting/frr/pull/1160 Which has this commit: https://github.com/FRRouting/frr/pull/1160/commits/c710b277cfde65fab8ae071f… During discussion about this the other night, I guessed at an admin distance of 100 for Babel. In conversation this morning with Don Slice he indicated that a number of 100 might be a bit low as that do we really trust Babel more than OSPF? Do people have opinions on what the Admin Distance should be set too? thanks! donald

4 5

Some TSC discussion during next weeks Technical Meeting(9/19)
by Donald Sharp 12 Sep '17

12 Sep '17

All - During next weeks Technical Meeting I'd like to carve out 10-15 minutes for a TSC discussion related to our Maintainers List and the upcoming yearly October elections. If you are interested in this conversation please take a moment to ensure your schedule is clear. I'd like to discuss these items: 1) Consolidation of github Maintainers and frrouting.org maintainers lists. 2) Do we need to modify the nomination process? Opening of Nominees? 3) Selection of a person to be in charge of voting in Oct. If you would like to attend and do not regularly attend please feel free to send me an email either here or on slack so I can get you added to the fun. Thanks! donald

1 0