February 2018 - dev - lists.frrouting.org

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

BGP Route Leaking for VRF-Lite and VPN's
by Donald Sharp 15 Mar '18

15 Mar '18

All - During discussions this morning w/ Lou we discovered that we are both working towards a BGP solution for Route Leaking. We have enough differences between our approaches that we need to spend some time consolidating our approach. The current plan is to have the meeting at 3:30 EDT this Friday Jan 19. If you would like to attend please let me know and I will put you on the invite for it. donald

4 15

FRR Technical Meeting Notes - 02/27/2018
by Quentin Young 03 Mar '18

03 Mar '18

*********************************************** FRR Technical Meeting Notes - February 27, 2018 *********************************************** Policy on support for EOL platforms ----------------------------------- - Should we support EOL platforms? Group consensus = No - Moving forward we will not explicitly support EOL platforms - Keep these platforms in CI, but remove as soon as it becomes inconvenient to maintain - Seeing as Centos 6 went EOL in May 2017, it is no longer supported; to be noted in docs Kernel minimum version requirement discussion --------------------------------------------- - What should our policy be on minimum kernel version needed for networking features? - Paul Z: Zebra should warn if a user tries to configure a feature and it's not supported - Martin W: `show features` command to inform user would be useful - Others: Agreed on both counts - Donald: If we implement the above, developers should be mindful when implementing kernel-specific features to update both of these things and it will be something to look for in future code reviews. Issues ------ Updates in individual issues. #1777, #1778 - Discussion postponed until Lou is present #1794 - General group consensus to stick with kernel style in this regard #1803 - Some people recall this being fixed in the past, Renato to take a look Pull Requests ------------- Updates in individual PRs. - #1711: Namespace VRF now in, thanks Philippe - #1704: Some packaging nits to fix, then good to go; ETA < 1 week Topotest PEP8 ------------- Martin & Rafael not too keen on reformatting whole codebase right now due to activity, but agree it might be worth looking at in the future. See further discussion here: https://github.com/FRRouting/topotests/issues/73#issuecomment-368952010

6 11

Style guidelines
by Quentin Young 23 Feb '18

23 Feb '18

Greetings developers, here is a reminder of the style guide and a summary of the tools FRR offers you to minimize the effort you spend ensuring your patches are compliant. FRR uses Linux kernel style. You can find that documented here: https://www.kernel.org/doc/html/v4.10/process/coding-style.html <https://www.kernel.org/doc/html/v4.10/process/coding-style.html> FRR’s style requirement is that patches submitted to FRR must comply with this style (with some exceptions covered in the docs). You are not required to run any tool, any script, etc, before submitting your patch. Feel free to do everything by hand if you want. If it complies with the style guidelines then from a style standpoint it is fine. FRR offers you a variety of tools for your convenience to help comply with the style guidelines and make it as easy as possible. In no particular order these are: * clang-format configuration file In the project root there is a file named .clang-format. This is a configuration file for the clang-format source formatting tool. This tool is part of the LLVM project. If you wish, you can use this tool to assist in complying with the style guide. There are good integrations for most editors, as well as an integration with git that you can use to do things like only format lines introduced in certain commits, only format staged changes, etc. Please note that while clang-format gets you 95% of the way there it’s not perfect and you are still responsible for styling your code properly. * indent.py This is a script that takes a filename and formats it with clang-format, doing some additional preprocessing to help reduce some edge-case mangling that happens with things like DEFUNs and macros. It operates on whole files. Usually you’re better off using clang-format integrations to format your code as you go. * tools/checkpatch.sh This is a script that wraps an adapted version of the Linux kernel’s checkpatch.pl script. It takes a git formatted patch or diff file and a path to your frr tree and does some magic to warn you about potential style issues. It does modify your frr tree in the process although it makes a best effort to save your working tree and restore it, if you don’t want to use `git stash` for some reason. You can run it like this: cd tools/ ./checkpatch.sh /path/to/patchfile /path/to/frr/sourcetree This script is also run by the CI system on new pull requests and its output is displayed to assist you with catching style errors. It’s not perfect but should catch the majority and have a relatively low false positive rate. DEFUNs are ignored so please use common sense when formatting these to avoid spending others’ time reviewing style. As always if you have any questions about style please refer to the kernel style guide, if you can’t find the answer to your question there ask on slack or this mailing list, and if you have improvements to indent.py or checkpatch.sh ideally submit a patch or alternatively open a Github issue. Again you are not required to use these tools, they are here for your personal convenience. We do not maintain clang-format so please don’t open bugs or feature requests about clang-format with us. Quentin

2 1

Today's Technical Meeting
by Donald Sharp 23 Feb '18

23 Feb '18

Today's Technical meeting is at the same bat time and place. If you would like to attend please let me know, I'll get you an invite. 1) Discuss and finalize release schedule: https://docs.google.com/presentation/d/1GdqVFn7s7kkOV_wDz7oJ1IYr_EVONuPX9t4… 2) Discuss meeting notes 3) Discuss New Issues 4) Discuss PR's in progress. donald

2 3

Multicast Trace added to PIM
by Donald Sharp 22 Feb '18

22 Feb '18

All - I'd like to thank Mladen for his contribution of a multicast trace program to FRR. This is a implementation of draft https://tools.ietf.org/html/draft-ietf-idmr-traceroute-ipm-05 . The command can be run from inside of vtysh with `mtrace <source>`. Alternatively it can be invoked from the command line as `mtracebis <source>`. thanks! donald

1 0

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

08 Feb '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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1453454: Resource leaks (RESOURCE_LEAK) /zebra/zebra_vxlan.c: 1857 in zvni_gw_macip_del() ________________________________________________________________________________________________________ *** CID 1453454: Resource leaks (RESOURCE_LEAK) /zebra/zebra_vxlan.c: 1857 in zvni_gw_macip_del() 1851 if (!CHECK_FLAG(n->flags, ZEBRA_NEIGH_LOCAL)) 1852 return -1; 1853 1854 /* only need to delete the entry from bgp if we sent it before */ 1855 if (advertise_gw_macip_enabled(zvni)) { 1856 if (IS_ZEBRA_DEBUG_VXLAN) >>> CID 1453454: Resource leaks (RESOURCE_LEAK) >>> Failing to save or free storage allocated by "prefix_mac2str(&n->emac, NULL, 18)" leaks it. 1857 zlog_debug("%u:SVI %s(%u) VNI %u, sending GW MAC %s IP %s del to BGP", 1858 ifp->vrf_id, ifp->name, 1859 ifp->ifindex, zvni->vni, 1860 prefix_mac2str(&(n->emac), 1861 NULL, 1862 ETHER_ADDR_STRLEN), ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Experimental OSPF SR
by Donald Sharp 07 Feb '18

07 Feb '18

All - We have added Experimental support of OSPF SR (draft-ietf-ospf-segment-routing-extensions-24). I would like to thanks Olivier for his hard work in getting this work done and Renato taking the time to fully review and test this feature. This feature is available on the master branch. For Instructions on how to use this new feature, please consult doc/OSPF-SR.rst. Thanks! donald

3 5

Today's Technical Meeting
by Donald Sharp 07 Feb '18

07 Feb '18

All - I was planning on going over the some high level overview of where I see zebra going. https://docs.google.com/presentation/d/1SeDS5b-Wgmp-2T_9povfHscP6Xpaihff_xs… thanks! donald

2 2

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

06 Feb '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 8 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 8 of 8 defect(s) ** CID 1464999: Memory - illegal accesses (BUFFER_SIZE_WARNING) /ospfd/ospf_ext.c: 1193 in ospf_ext_link_lsa_originate1() ________________________________________________________________________________________________________ *** CID 1464999: Memory - illegal accesses (BUFFER_SIZE_WARNING) /ospfd/ospf_ext.c: 1193 in ospf_ext_link_lsa_originate1() 1187 /* Flood new LSA through area. */ 1188 ospf_flood_through_area(area, NULL /*nbr */, new); 1189 1190 if (IS_DEBUG_OSPF(lsa, LSA_GENERATE)) { 1191 char area_id[INET_ADDRSTRLEN]; 1192 >>> CID 1464999: Memory - illegal accesses (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 16 bytes on destination array "area_id" of size 16 bytes might leave the destination string unterminated. 1193 strncpy(area_id, inet_ntoa(area->area_id), INET_ADDRSTRLEN); 1194 zlog_debug( 1195 "EXT (%s): LSA[Type%u:%s]: Originate Opaque-LSA " 1196 "Extended Link Opaque LSA: Area(%s), Link(%s)", 1197 __func__, new->data->type, inet_ntoa(new->data->id), 1198 area_id, exti->ifp->name); ** CID 1464998: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1464998: Null pointer dereferences (FORWARD_NULL) /ospfd/ospf_ext.c: 1396 in ospf_ext_pref_lsa_refresh() 1390 zlog_warn("EXT (%s): ospf_lsa_install() error", __func__); 1391 ospf_lsa_unlock(&new); 1392 return NULL; 1393 } 1394 1395 /* Flood updated LSA through the Prefix Area according to the RFC7684 */ >>> CID 1464998: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "area" to "ospf_flood_through_area", which dereferences it. 1396 ospf_flood_through_area(area, NULL /*nbr */, new); 1397 1398 /* Debug logging. */ 1399 if (IS_DEBUG_OSPF(lsa, LSA_GENERATE)) { 1400 zlog_debug( 1401 "EXT (%s): LSA[Type%u:%s] Refresh Extended Prefix LSA", ** CID 1464997: (BUFFER_SIZE_WARNING) /ospfd/ospf_sr.c: 2169 in show_vty_sr_node() /ospfd/ospf_sr.c: 2183 in show_vty_sr_node() ________________________________________________________________________________________________________ *** CID 1464997: (BUFFER_SIZE_WARNING) /ospfd/ospf_sr.c: 2169 in show_vty_sr_node() 2163 "\n\n Prefix or Link Label In Label Out " 2164 "Node or Adj. SID Interface Nexthop\n"); 2165 vty_out(vty, 2166 "------------------ -------- --------- " 2167 "--------------------- --------- ---------------\n"); 2168 for (ALL_LIST_ELEMENTS_RO(srn->ext_prefix, node, srp)) { >>> CID 1464997: (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 16 bytes on destination array "pref" of size 16 bytes might leave the destination string unterminated. 2169 strncpy(pref, inet_ntoa(srp->nhlfe.prefv4.prefix), 16); 2170 snprintf(sid, 22, "SR Pfx (idx %u)", srp->sid); 2171 if (srp->nhlfe.label_out == MPLS_IMP_NULL_LABEL) 2172 sprintf(label, "pop"); 2173 else 2174 sprintf(label, "%u", srp->nhlfe.label_out); /ospfd/ospf_sr.c: 2183 in show_vty_sr_node() 2177 srp->nhlfe.prefv4.prefixlen, srp->nhlfe.label_in, label, 2178 sid, itf ? itf->name : "-", 2179 inet_ntoa(srp->nhlfe.nexthop)); 2180 } 2181 2182 for (ALL_LIST_ELEMENTS_RO(srn->ext_link, node, srl)) { >>> CID 1464997: (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 16 bytes on destination array "pref" of size 16 bytes might leave the destination string unterminated. 2183 strncpy(pref, inet_ntoa(srl->nhlfe[0].prefv4.prefix), 16); 2184 snprintf(sid, 22, "SR Adj. (lbl %u)", srl->sid[0]); 2185 if (srl->nhlfe[0].label_out == MPLS_IMP_NULL_LABEL) 2186 sprintf(label, "pop"); 2187 else 2188 sprintf(label, "%u", srl->nhlfe[0].label_out); ** CID 1464996: Null pointer dereferences (REVERSE_INULL) /ospfd/ospf_sr.c: 153 in sr_node_new() ________________________________________________________________________________________________________ *** CID 1464996: Null pointer dereferences (REVERSE_INULL) /ospfd/ospf_sr.c: 153 in sr_node_new() 147 new->ext_link = list_new(); 148 new->ext_prefix = list_new(); 149 new->ext_link->del = del_sr_link; 150 new->ext_prefix->del = del_sr_pref; 151 152 /* Check if list are correctly created */ >>> CID 1464996: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "new->ext_prefix" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 153 if (new->ext_link == NULL || new->ext_prefix == NULL) { 154 list_delete_original(new->ext_link); 155 list_delete_original(new->ext_prefix); 156 XFREE(MTYPE_OSPF_SR_PARAMS, new); 157 return NULL; 158 } ** CID 1464995: Null pointer dereferences (REVERSE_INULL) /ospfd/ospf_sr.c: 153 in sr_node_new() ________________________________________________________________________________________________________ *** CID 1464995: Null pointer dereferences (REVERSE_INULL) /ospfd/ospf_sr.c: 153 in sr_node_new() 147 new->ext_link = list_new(); 148 new->ext_prefix = list_new(); 149 new->ext_link->del = del_sr_link; 150 new->ext_prefix->del = del_sr_pref; 151 152 /* Check if list are correctly created */ >>> CID 1464995: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "new->ext_link" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 153 if (new->ext_link == NULL || new->ext_prefix == NULL) { 154 list_delete_original(new->ext_link); 155 list_delete_original(new->ext_prefix); 156 XFREE(MTYPE_OSPF_SR_PARAMS, new); 157 return NULL; 158 } ** CID 1464994: Null pointer dereferences (FORWARD_NULL) /ospfd/ospf_sr.c: 443 in get_nexthop_by_addr() ________________________________________________________________________________________________________ *** CID 1464994: Null pointer dereferences (FORWARD_NULL) /ospfd/ospf_sr.c: 443 in get_nexthop_by_addr() 437 struct ospf_route *or; 438 struct ospf_path *path; 439 struct listnode *node; 440 struct route_node *rn; 441 442 /* Sanity Check */ >>> CID 1464994: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "top". 443 if ((top == NULL) && (top->new_table)) 444 return NULL; 445 446 if (IS_DEBUG_OSPF_SR) 447 zlog_debug(" |- Search Nexthop for prefix %s/%u", 448 inet_ntoa(p.prefix), p.prefixlen); ** CID 1464993: Memory - illegal accesses (BUFFER_SIZE_WARNING) /ospfd/ospf_ext.c: 1143 in ospf_ext_pref_lsa_originate1() ________________________________________________________________________________________________________ *** CID 1464993: Memory - illegal accesses (BUFFER_SIZE_WARNING) /ospfd/ospf_ext.c: 1143 in ospf_ext_pref_lsa_originate1() 1137 /* Flood new LSA through area. */ 1138 ospf_flood_through_area(area, NULL /*nbr */, new); 1139 1140 if (IS_DEBUG_OSPF(lsa, LSA_GENERATE)) { 1141 char area_id[INET_ADDRSTRLEN]; 1142 >>> CID 1464993: Memory - illegal accesses (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 16 bytes on destination array "area_id" of size 16 bytes might leave the destination string unterminated. 1143 strncpy(area_id, inet_ntoa(area->area_id), INET_ADDRSTRLEN); 1144 zlog_debug( 1145 "EXT (%s): LSA[Type%u:%s]: Originate Opaque-LSA " 1146 "Extended Prefix Opaque LSA: Area(%s), Link(%s)", 1147 __func__, new->data->type, inet_ntoa(new->data->id), 1148 area_id, exti->ifp->name); ** CID 1464992: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /ospfd/ospf_ext.c: 177 in ospf_ext_term() ________________________________________________________________________________________________________ *** CID 1464992: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /ospfd/ospf_ext.c: 177 in ospf_ext_term() 171 * @param - none 172 * @return - none 173 */ 174 void ospf_ext_term(void) 175 { 176 >>> CID 1464992: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> The "or" condition "OspfEXT.scope != 10 || OspfEXT.scope != 11" will always be true because "OspfEXT.scope" cannot be equal to two different values at the same time, so it must be not equal to at least one of them. 177 if ((OspfEXT.scope != OSPF_OPAQUE_AREA_LSA) 178 || (OspfEXT.scope != OSPF_OPAQUE_AS_LSA)) 179 zlog_warn( 180 "EXT: Unable to unregister Extended Prefix " 181 "Opaque LSA functions: Wrong scope!"); 182 else ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

dev/4.0
by Donald Sharp 06 Feb '18

06 Feb '18

All - I just pulled the dev/4.0 branch. We will now be working towards stabilization of the 4.0 changes and expect a release within a month or two. Additionally I've updated the master branch to build as 4.1-dev. We will be accepting new features on the master branch. donald

1 0

Debian Packaging
by Dan White 06 Feb '18

06 Feb '18

The Quagga Debian maintainer has expressed his intent to orphan his involvement with its packaging: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884919 FRRouting Debian packaging is currently distributed via its github page: https://github.com/FRRouting/frr/releases I would guess Cumulus maintains their own private repository, along with ptm packages. What plans are there for moving packaging into Debian main?

3 4

Manpage content
by Quentin Young 01 Feb '18

01 Feb '18

Hi folks, As part of the work I’m doing to convert all of our docs to RST, I’ve now reached the point where I am converting over the manpages from groff and want some community input on content. As it stands the manpages have not been significantly updated since ~2004 and contain little more than a brief summary of option flags. Now that all of the user documentation is in RST, as far as I can see we have two options: 1. Keep the manpages separate, with their current minimal content. Example (converted) manpage source: (bgpd.rst) http://ix.io/F0E <http://ix.io/F0E> (common-options.rst) http://ix.io/F0G <http://ix.io/F0G> 2. Add the standard SYNOPSIS, DESCRIPTION, OPTIONS etc. sections, as in the source above, to the top of each chapter in the user documentation that covers a daemon, and then generate manpages from the same source we use to generate the various other manuals (web, info, pdf, etc). The only downside I see to option #2 is that some of the manpages have small novels written inside them (for example the 24 paragraph section on MED in the BGP chapter), which degrades their usefulness as the “quick reference” people tend to use them for these days. Whereas the upside is 13 less (albeit small) files to update when things change and a significant increase in the amount of overall information in the manpages. Thoughts?

3 3

MPLS use cases and Linux Kernel Interactions
by Donald Sharp 01 Feb '18

01 Feb '18

All - We plan to have a MPLS use case and Linux Kernel Interactions meeting this Wed at 10am EDT. If you would like to attend please let me know and I'll get you an invite. thanks! donald

2 3

PR has sat for 14 days
by Donald Sharp 01 Feb '18

01 Feb '18

https://github.com/FRRouting/frr/pull/1654 This PR has sat for 14 days without anyone looking at it. I will push this in on Saturday the 3, if we do not start getting some reviews. donald

1 0