- dev - lists.frrouting.org

OSPFv2 VRF support is now available
by Chirag Shah 04 Oct '17

04 Oct '17

Hi All, We have OSPFv2 VRF-lite support is now available in FRR master. List of ospf interface and list of area are part of "struct ospf" which would divide per vrf. Type1-5 LSAs and Opaque LSAs are handled i vrf aware instance. LSA and LSDB would be operate on per area and per ospf interface which would use its parent ospf vrf_id. OSPF Route Add/delete will have struct ospf or vrf_id passed as argument and ospf->vrf_id used to program the routes to zebra. External route are vrf aware. BFD sessions are vrf aware. Primary OSPF show CLIs like neighbor, interface, database, route are converted to take vrf <all | word> as arguement and follows "show ip ospf vrf [all|word] ....." format. json output containing VRF anchor point will be added in future check-ins. A new CLI 'show ip ospf vrfs' outlines all vrf configured ospf instances. MI-OSPF with VRF is not tested but configuration cli allows the combination. Kind Regards, Chirag Shah

1 0

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

03 Oct '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 1457301: Resource leaks (RESOURCE_LEAK) /ospfd/ospf_te.c: 1172 in ospf_mpls_te_lsa_new() ________________________________________________________________________________________________________ *** CID 1457301: Resource leaks (RESOURCE_LEAK) /ospfd/ospf_te.c: 1172 in ospf_mpls_te_lsa_new() 1166 lsa_type = OSPF_OPAQUE_AREA_LSA; 1167 } 1168 tmp = SET_OPAQUE_LSID(OPAQUE_TYPE_INTER_AS_LSA, lp->instance); 1169 lsa_id.s_addr = htonl(tmp); 1170 1171 if (!ospf) >>> CID 1457301: Resource leaks (RESOURCE_LEAK) >>> Variable "s" going out of scope leaks the storage it points to. 1172 return NULL; 1173 1174 lsa_header_set(s, options, lsa_type, lsa_id, ospf->router_id); 1175 } else { 1176 options |= LSA_OPTIONS_GET(area); /* Get area default option */ 1177 options |= LSA_OPTIONS_NSSA_GET(area); ** CID 1457300: Null pointer dereferences (FORWARD_NULL) /ospfd/ospf_vty.c: 8730 in config_write_interface_one() ________________________________________________________________________________________________________ *** CID 1457300: Null pointer dereferences (FORWARD_NULL) /ospfd/ospf_vty.c: 8730 in config_write_interface_one() 8724 vty_out(vty, " %s", 8725 inet_ntoa(rn->p.u.prefix4)); 8726 vty_out(vty, "\n"); 8727 } 8728 8729 /* Cryptographic Authentication Key print. */ >>> CID 1457300: Null pointer dereferences (FORWARD_NULL) >>> Comparing "params" to null implies that "params" might be null. 8730 if (params && params->auth_crypt) { 8731 for (ALL_LIST_ELEMENTS_RO(params->auth_crypt, 8732 n2, ck)) { 8733 vty_out(vty, 8734 " ip ospf message-digest-key %d md5 %s", 8735 ck->key_id, ck->auth_key); ** CID 1457299: Resource leaks (RESOURCE_LEAK) /ospfd/ospf_ri.c: 664 in ospf_router_info_lsa_originate1() ________________________________________________________________________________________________________ *** CID 1457299: Resource leaks (RESOURCE_LEAK) /ospfd/ospf_ri.c: 664 in ospf_router_info_lsa_originate1() 658 659 /* Get ospf info */ 660 top = ospf_lookup_by_vrf_id(vrf_id); 661 if (top == NULL) { 662 zlog_debug("%s: ospf instance not found for vrf id %u", 663 __PRETTY_FUNCTION__, vrf_id); >>> CID 1457299: Resource leaks (RESOURCE_LEAK) >>> Variable "new" going out of scope leaks the storage it points to. 664 return rc; 665 } 666 667 /* Install this LSA into LSDB. */ 668 if (ospf_lsa_install(top, NULL /*oi */, new) == NULL) { 669 zlog_warn( ** CID 1457298: Resource leaks (RESOURCE_LEAK) /ospfd/ospf_network.c: 268 in ospf_sock_init() ________________________________________________________________________________________________________ *** CID 1457298: Resource leaks (RESOURCE_LEAK) /ospfd/ospf_network.c: 268 in ospf_sock_init() 262 ospf->fd = ospf_sock; 263 out: 264 if (ospfd_privs.change(ZPRIVS_LOWER)) { 265 zlog_err("ospf_sock_init: could not lower privs, %s", 266 safe_strerror(errno)); 267 } >>> CID 1457298: Resource leaks (RESOURCE_LEAK) >>> Handle variable "ospf_sock" going out of scope leaks the handle. 268 return ret; ** CID 1457297: (RESOURCE_LEAK) /ospfd/ospf_zebra.c: 1140 in ospf_distribute_list_update() /ospfd/ospf_zebra.c: 1144 in ospf_distribute_list_update() ________________________________________________________________________________________________________ *** CID 1457297: (RESOURCE_LEAK) /ospfd/ospf_zebra.c: 1140 in ospf_distribute_list_update() 1134 args[0] = ospf; 1135 args[1] = (void *)((ptrdiff_t) type); 1136 1137 /* External info does not exist. */ 1138 ext = ospf_external_lookup(type, instance); 1139 if (!ext || !(rt = EXTERNAL_INFO(ext))) >>> CID 1457297: (RESOURCE_LEAK) >>> Variable "args" going out of scope leaks the storage it points to. 1140 return; 1141 1142 /* If exists previously invoked thread, then let it continue. */ 1143 if (ospf->t_distribute_update) 1144 return; 1145 /ospfd/ospf_zebra.c: 1144 in ospf_distribute_list_update() 1138 ext = ospf_external_lookup(type, instance); 1139 if (!ext || !(rt = EXTERNAL_INFO(ext))) 1140 return; 1141 1142 /* If exists previously invoked thread, then let it continue. */ 1143 if (ospf->t_distribute_update) >>> CID 1457297: (RESOURCE_LEAK) >>> Variable "args" going out of scope leaks the storage it points to. 1144 return; 1145 1146 /* Set timer. */ 1147 ospf->t_distribute_update = NULL; 1148 thread_add_timer_msec(master, ospf_distribute_list_update_timer, 1149 (void **)args, ospf->min_ls_interval, ________________________________________________________________________________________________________ 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 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