July 2017 - dev - lists.frrouting.org

EVPN (and L3VPN) configuration
by Vivek Venkatraman 18 Jul '17

18 Jul '17

About 3 weeks ago, I submitted PR 619 ( https://github.com/FRRouting/frr/pull/619) which provides the standardized EVPN control plane for VxLAN. This is the EVPN implementation that is available/shipping with Cumulus Linux, just merged with the FRR 'master' branch. The PR provides a summary of the functionality. The essential configuration involves only two steps as documented in the file doc/evpn.md: 1. Enable (activate) the EVPN (AFI/SAFI 25/70) address-family between BGP speakers 2. Enable EVPN itself on the local system - to advertise local VNIs and MACs and Neighbors (ARP/ND) associated with those VNIs using BGP/EVPN procedures. The RD and RT parameters will be automatically derived as specified in these procedures and/or prevalent best practice. Step #2 is of course not needed on a Route Reflector. In addition, there are commands to configure the RD and RTs if auto-derivation is not desired - for e.g., peering with third-party BGP system. The syntax for this is shown through an example configuration below (which also shows steps #1 and #2). router bgp 65001 address-family l2vpn evpn neighbor SPINE activate vni 10100 rd 1:10100 route-target import 1:10100 exit-vni advertise-all-vni exit-address-family One topic of discussion is regarding this optional VNI configuration. Instead of the keyword being "vni", should it be "vni-policy" to match with "vrf-policy"? I don't think "vni-policy", or for that matter, "vrf-policy" is the best choice due to the following two main reasons: 1. A "policy" is a fairly familiar construct in routing parlance. It commonly refers to a set of rules or definitions that are generically specified and can then be applied to different "attach points". In FRR, a "route-map" would be a good example of such a policy. It may be misleading to call the specific configuration for a VNI or VRF as "policy", particularly when the VNI/VRF may later support import/export policies (route-maps). 2. The configuration syntax that emerged for VRFs after the last round of discussions separates out the "CE side" configuration (e.g., CE neighbors, redistribution etc.) from the "PE side" configuration (e.g., RD and RT configuration). From the user/operator's perspective, I do not see any value add in this separation, only a potential source of confusion since the same entity (VRF) needs to be configured in multiple places. It can also be debatable where a configuration lies. For e.g., should "vrf-import-policy" reside on the "PE side" as it deals with received L3VPN routes or on the "CE side" as it decides which routes to import into which VRF table? I see it as being very useful to have all the configuration relevant to a VRF (or VNI) in one place. The purpose of this email is to solicit wider feedback since only a few people participated in the earlier discussion and their positions are very likely unchanged. My suggestion would be to have the initial deliberations on the list and if that does not converge or indicates the need for a meeting, the maintainers will call one. Based on the consensus that emerges, I shall update my PR and/or introduce modifications in a subsequent PR - if needed. Vivek

3 11

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

17 Jul '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 4 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 7 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 4 of 4 defect(s) ** CID 1451363: Null pointer dereferences (FORWARD_NULL) /ospf6d/ospf6_lsdb.c: 392 in ospf6_lsdb_show() ________________________________________________________________________________________________________ *** CID 1451363: Null pointer dereferences (FORWARD_NULL) /ospf6d/ospf6_lsdb.c: 392 in ospf6_lsdb_show() 386 return; 387 } 388 389 if (level == OSPF6_LSDB_SHOW_LEVEL_NORMAL) 390 ospf6_lsa_show_summary_header(vty); 391 >>> CID 1451363: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "type". 392 end = ospf6_lsdb_head(lsdb, !!type + !!(type && adv_router), *type, 393 *adv_router, &lsa); 394 while (lsa) { 395 if ((!adv_router || lsa->header->adv_router == *adv_router) 396 && (!id || lsa->header->id == *id)) 397 (*showfunc)(vty, lsa); ** CID 1451362: Null pointer dereferences (REVERSE_INULL) /ospf6d/ospf6_lsdb.c: 395 in ospf6_lsdb_show() ________________________________________________________________________________________________________ *** CID 1451362: Null pointer dereferences (REVERSE_INULL) /ospf6d/ospf6_lsdb.c: 395 in ospf6_lsdb_show() 389 if (level == OSPF6_LSDB_SHOW_LEVEL_NORMAL) 390 ospf6_lsa_show_summary_header(vty); 391 392 end = ospf6_lsdb_head(lsdb, !!type + !!(type && adv_router), *type, 393 *adv_router, &lsa); 394 while (lsa) { >>> CID 1451362: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "adv_router" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 395 if ((!adv_router || lsa->header->adv_router == *adv_router) 396 && (!id || lsa->header->id == *id)) 397 (*showfunc)(vty, lsa); 398 399 lsa = ospf6_lsdb_next(end, lsa); 400 } ** CID 1451361: Null pointer dereferences (REVERSE_INULL) /lib/command_match.c: 598 in disambiguate() ________________________________________________________________________________________________________ *** CID 1451361: Null pointer dereferences (REVERSE_INULL) /lib/command_match.c: 598 in disambiguate() 592 vector vline, unsigned int n) 593 { 594 // doesn't make sense for these to be inequal length 595 assert(first->count == second->count); 596 assert(first->count == vector_active(vline) - n + 1); 597 >>> CID 1451361: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "second" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 598 struct listnode *fnode = listhead(first), *snode = listhead(second); 599 struct cmd_token *ftok = listgetdata(fnode), *stok = listgetdata(snode), 600 *best = NULL; 601 602 // compare each token, if one matches better use that one 603 for (unsigned int i = n; i < vector_active(vline); i++) { ** CID 1451360: Null pointer dereferences (FORWARD_NULL) /ospf6d/ospf6_lsdb.c: 392 in ospf6_lsdb_show() ________________________________________________________________________________________________________ *** CID 1451360: Null pointer dereferences (FORWARD_NULL) /ospf6d/ospf6_lsdb.c: 392 in ospf6_lsdb_show() 386 return; 387 } 388 389 if (level == OSPF6_LSDB_SHOW_LEVEL_NORMAL) 390 ospf6_lsa_show_summary_header(vty); 391 >>> CID 1451360: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "adv_router". 392 end = ospf6_lsdb_head(lsdb, !!type + !!(type && adv_router), *type, 393 *adv_router, &lsa); 394 while (lsa) { 395 if ((!adv_router || lsa->header->adv_router == *adv_router) 396 && (!id || lsa->header->id == *id)) 397 (*showfunc)(vty, lsa); ________________________________________________________________________________________________________ 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

Lunch Thursday?
by Lou Berger 15 Jul '17

15 Jul '17

Shall we meet for our usual FRR Thursday lunch?

4 4

Announcing EVPN support merged to FRRouting master
by David Lamparter 14 Jul '17

14 Jul '17

Hello everyone, just an hour ago, we've merged EVPN support into FRRouting's master branch. I'd particularly like to thank Vivek Venkatraman (author of most of it), Donald Sharp, Lou Berger, Philippe Guibert and Russ White for their hard work in getting this rather large chunk of code through. As always there are things left to be polished, but right now it's time to have some cake! Cheers, -David P.S.: as context for the FROG list, this will be in the next release /after/ 3.0, so it's still some time out.

3 2

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

14 Jul '17

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. 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 6 of 6 defect(s) ** CID 1450988: Error handling issues (CHECKED_RETURN) /bgpd/bgp_evpn.c: 2533 in bgp_evpn_derive_auto_rd() ________________________________________________________________________________________________________ *** CID 1450988: Error handling issues (CHECKED_RETURN) /bgpd/bgp_evpn.c: 2533 in bgp_evpn_derive_auto_rd() 2527 { 2528 char buf[100]; 2529 2530 vpn->prd.family = AF_UNSPEC; 2531 vpn->prd.prefixlen = 64; 2532 sprintf (buf, "%s:%hu", inet_ntoa (bgp->router_id), vpn->rd_id); >>> CID 1450988: Error handling issues (CHECKED_RETURN) >>> Calling "str2prefix_rd" without checking return value (as is done elsewhere 15 out of 16 times). 2533 str2prefix_rd (buf, &vpn->prd); 2534 UNSET_FLAG (vpn->flags, VNI_FLAG_RD_CFGD); 2535 } 2536 2537 /* 2538 * Lookup VNI. ** CID 1450987: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_evpn.c: 509 in add_mac_mobility_to_attr() ________________________________________________________________________________________________________ *** CID 1450987: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_evpn.c: 509 in add_mac_mobility_to_attr() 503 /* Build MM */ 504 encode_mac_mobility_extcomm (0, seq_num, &eval); 505 506 /* Find current MM ecommunity */ 507 ecom_mm = NULL; 508 >>> CID 1450987: Null pointer dereferences (FORWARD_NULL) >>> Comparing "attr->ecommunity" to null implies that "attr->ecommunity" might be null. 509 if (attr->ecommunity) 510 { 511 for (i = 0; i < attr->ecommunity->size; i++) 512 { 513 pnt = attr->ecommunity->val + (i * 8); 514 type = *pnt++; ** CID 1450986: (RESOURCE_LEAK) /bgpd/bgp_mpath.c: 775 in bgp_info_mpath_aggregate_update() /bgpd/bgp_mpath.c: 775 in bgp_info_mpath_aggregate_update() ________________________________________________________________________________________________________ *** CID 1450986: (RESOURCE_LEAK) /bgpd/bgp_mpath.c: 775 in bgp_info_mpath_aggregate_update() 769 bgp_attr_unintern (&old_attr); 770 bgp_info_mpath_attr_set (new_best, new_attr); 771 SET_FLAG (new_best->flags, BGP_INFO_ATTR_CHANGED); 772 } 773 else 774 bgp_attr_unintern (&new_attr); >>> CID 1450986: (RESOURCE_LEAK) >>> Variable "lcomm" going out of scope leaks the storage it points to. /bgpd/bgp_mpath.c: 775 in bgp_info_mpath_aggregate_update() 769 bgp_attr_unintern (&old_attr); 770 bgp_info_mpath_attr_set (new_best, new_attr); 771 SET_FLAG (new_best->flags, BGP_INFO_ATTR_CHANGED); 772 } 773 else 774 bgp_attr_unintern (&new_attr); >>> CID 1450986: (RESOURCE_LEAK) >>> Variable "lcomm" going out of scope leaks the storage it points to. ** CID 1450985: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_vxlan.c: 841 in zvni_neigh_uninstall() ________________________________________________________________________________________________________ *** CID 1450985: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_vxlan.c: 841 in zvni_neigh_uninstall() 835 836 if (!(n->flags & ZEBRA_NEIGH_REMOTE)) 837 return 0; 838 839 zvrf = vrf_info_lookup(zvni->vxlan_if->vrf_id); 840 assert(zvrf); >>> CID 1450985: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "zvni->vxlan_if" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 841 if (!zvni->vxlan_if) 842 { 843 zlog_err ("VNI %u hash %p couldn't be uninstalled - no intf", 844 zvni->vni, zvni); 845 return -1; 846 } ** CID 1450984: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_evpn.c: 279 in map_vni_to_rt() ________________________________________________________________________________________________________ *** CID 1450984: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_evpn.c: 279 in map_vni_to_rt() 273 */ 274 memcpy (&eval_tmp, eval, ECOMMUNITY_SIZE); 275 if (!is_import_rt_configured (vpn)) 276 mask_ecom_global_admin (&eval_tmp, eval); 277 278 irt = lookup_import_rt (bgp, &eval_tmp); >>> CID 1450984: Null pointer dereferences (FORWARD_NULL) >>> Comparing "irt->vnis" to null implies that "irt->vnis" might be null. 279 if (irt && irt->vnis) 280 if (is_vni_present_in_irt_vnis (irt->vnis, vpn)) 281 /* Already mapped. */ 282 return; 283 284 if (!irt) ** CID 1450983: (CONSTANT_EXPRESSION_RESULT) /bgpd/bgp_evpn.c: 2089 in evpn_mpattr_encode_type5() /bgpd/bgp_evpn.c: 2099 in evpn_mpattr_encode_type5() ________________________________________________________________________________________________________ *** CID 1450983: (CONSTANT_EXPRESSION_RESULT) /bgpd/bgp_evpn.c: 2089 in evpn_mpattr_encode_type5() 2083 else 2084 len = 32; /* ipv6 */ 2085 stream_putc(s, BGP_EVPN_IP_PREFIX_ROUTE); 2086 /* Prefix contains RD, ESI, EthTag, IP length, IP, GWIP and VNI */ 2087 stream_putc(s, 8 + 10 + 4 + 1 + len + 3); 2088 stream_put(s, prd->val, 8); >>> CID 1450983: (CONSTANT_EXPRESSION_RESULT) >>> The expression "attr && attr" does not accomplish anything because it evaluates to either of its identical operands, "attr". 2089 if (attr && attr) 2090 stream_put(s, &(attr->evpn_overlay.eth_s_id), 10); 2091 else 2092 stream_put(s, &temp, 10); 2093 stream_putl(s, p_evpn_p->eth_tag); 2094 stream_putc(s, p_evpn_p->ip_prefix_length); /bgpd/bgp_evpn.c: 2099 in evpn_mpattr_encode_type5() 2093 stream_putl(s, p_evpn_p->eth_tag); 2094 stream_putc(s, p_evpn_p->ip_prefix_length); 2095 if (IS_IPADDR_V4(&p_evpn_p->ip)) 2096 stream_put_ipv4(s, p_evpn_p->ip.ipaddr_v4.s_addr); 2097 else 2098 stream_put(s, &p_evpn_p->ip.ipaddr_v6, 16); >>> CID 1450983: (CONSTANT_EXPRESSION_RESULT) >>> The expression "attr && attr" does not accomplish anything because it evaluates to either of its identical operands, "attr". 2099 if (attr && attr) 2100 { 2101 if (IS_IPADDR_V4(&p_evpn_p->ip)) 2102 stream_put_ipv4(s, attr->evpn_overlay.gw_ip.ipv4. s_addr); 2103 else 2104 stream_put(s, &(attr->evpn_overlay.gw_ip.ipv6), 16); ________________________________________________________________________________________________________ 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 12 Jul '17

12 Jul '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 1450665: Resource leaks (RESOURCE_LEAK) /lib/hash.c: 435 in show_hash_stats() ________________________________________________________________________________________________________ *** CID 1450665: Resource leaks (RESOURCE_LEAK) /lib/hash.c: 435 in show_hash_stats() 429 430 pthread_mutex_lock (&_hashes_mtx); 431 if (!_hashes) 432 { 433 pthread_mutex_unlock (&_hashes_mtx); 434 vty_outln (vty, "No hash tables in use."); >>> CID 1450665: Resource leaks (RESOURCE_LEAK) >>> Variable "tt" going out of scope leaks the storage it points to. 435 return CMD_SUCCESS; 436 } 437 438 for (ALL_LIST_ELEMENTS_RO (_hashes, ln, h)) 439 { 440 if (!h->name) ________________________________________________________________________________________________________ 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

Topotests - Call for users
by Rafael Zalamena 06 Jul '17

06 Jul '17

Hello all, I've been working with Martin these past weeks and we came up with improvements for the topotests testing framework. This improvements main objectives are: * Make topotests user-friendlier by removing boiler plate code * Have guidelines to help users write new tests * Document some parts of the framework Who is this for: * People that want to build big topologies with minimal manual labor and still have reproducible 'build's of it. See the py.test flag '--topology-only' available for new tests * Developers that want to automate execution of specific tests for frr development * Developers that want to create topology tests for the CI System * Developers that want to reproduce locally a CI topology that is failing * Users that want to build topologies bootstrapping from already existing topologies Where to start: * Read the guidelines file: https://github.com/FRRouting/topotests/blob /master/GUIDELINES.md * Look at already written tests: https://github.com/opensourcerouting/t opotests/tree/ospf-topo1 (it is still under development, but almost ready) * Play with the template test: https://github.com/FRRouting/topotests/b lob/master/example-test/test_template.py Tip: when accessing the routers via Mininet CLI, prefer launching equipments terminal using the command 'xterm' (e.g. 'xterm r1'). Using 'bash' or 'vtysh' directly may cause a reported problem: https://github.com/FRRouting/frr/issues/727 Regards, Rafael

3 5

Routing Performance
by Richard Barger 05 Jul '17

05 Jul '17

Hello, I would like to ask if there are any performance numbers for 10GbE packet throughput with the latest release of FFR and BGP. Such as a RFC-2544 throughput test result.. We are using Intel X710 10GbE NIC cards and new INTEL XEON E5V3-4 based servers. We have used QUAGGA prior to build a BGP Network Latency Emulator on 10/100/1000 XEON E5-1620V2 system. The packet throughput was not great. So, we are very interested to learn of the performance enhancements of FRR over prior Quagga from three years ago. We are wanting to understand how to obtain the fastest possible Packet throughput. Sincerely, Richard Barger, President East Coast Datacom, Inc. 245 Gus Hipp Blvd., STE 3 Rockledge, FL 32955 USA Tel: (321) 637-9922 Fax: (321) 637-9980 email: rbarger(a)ecdata.com Web: www.ecdata.com LOGO ecdata

2 1

Increase the number of MPLS tags in zebra
by Алексей Болдырев 05 Jul '17

05 Jul '17

By the way, kernel 4.12 is already available: (https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.12.tar.xz) In this kernel, according to the developers, the number of MPLS tags on the stack is 30. Therefore, I suggest that this limit in Zebra should be avoided. https://github.com/FRRouting/frr/issues/776

3 3

Meeting Notes "Technical Discussion of FRR Code" - July 4, 2017
by Martin Winter 04 Jul '17

04 Jul '17

Meeting Notes FRR Technical Call Attendance: Martin, Lou, Philippe, Alistair, Emmanual, Renato, David, Rafael Issues: 3.0 - *bsd interface speed from the kernel #407 Not a bug, but enhancement. On Renato's list sometime next week. - problem with static route and dynamic interface. #560 David thinks that this is a real issue (ie tunnels) and need fix Waiting for Donald - BGPd: global-buffer-overflow #670 David looking at cherry-picking it from master Other 3.0 issues (not on issue tracker) - From FRR Dev List: "[dev] Synchronization issue between bgp and vtysh states" Not sure how to debug this. They should open an issue for this to track it. Other Issues: - CI system Static Analysis is mixing branches #761 Closed as resolved - EIGRP Neighbor adjacency became full #765 Waiting for Donald - bgpd: allow neighbor to be active for both ipv4 unicast and labeled-unicast #766 Lou working with Daniel on it. Compability change in PR which needs to be resolved first - ldp ipv4 tests are inconsistent #772 Closed. Was a CI system cleanup issue between testruns - (Increasing the number of MPLS-tags in) zebra #776 New issue... discussion in progress on mailing list Should it go into 3.0? PRs: - zebra: Remove duplicate next hops when installing routes #554 Waiting for Donald - EVPN for VxLAN #619 Waiting for status & opinion from Vivek - frr: Fix up the rpmbuild process to solidify on one unified way of wo… #639 Lower prio, waiting for some Debian Pkg Work. Tracking PR - Evpn flebominator( struct attr_extra collapsed struct attr ) #682 Waiting for evpn split (# 619) - Add Pseudowire management in Zebra #724 Renato working with Bingen, Bingen supposed to send new PR - bgpd: Install SAFI_LABELED_UNICAST routes in SAFI_UNICAST table #733 Discussion between Lou and Daniel in progress - Hashtable statistics #742 Merged. - Bgp buffer #750 Moved to Rafael as he is working on topotests right now anyway - PREVIEW: Debian pkg for 2.0 #758 Waiting on more hands with Debian Pkg Experience - Allow for more than 1 NH recursion level #762 Waiting on Donald Should probably schedule TSC meeting on - Release signing (discussion on GPG Keys) - Access to frrouting.org servers (How to get more "root" users to fix) FRR Meetup at IETF? - Lou, Alistair, others?

1 0