- dev - lists.frrouting.org

Fwd: Re: EVPN (and L3VPN) configuration
by Lou Berger 15 Jun '17

15 Jun '17

Resend -- looks like previous message didn't make it to the list. -------- Forwarded Message -------- Subject: Re: [dev] EVPN (and L3VPN) configuration Date: Tue, 13 Jun 2017 20:49:05 -0400 From: Lou Berger <lberger(a)labn.net> To: dev(a)lists.frrouting.org Hi Vivek, Thanks for this message - discussing on list is useful. My view is that we had lots of discussions the last time around and cam up with a compromise solution. (From my view, I'm okay with changing this past agreement as long as there is community agreement on the new syntax.) Here's what I see in the notes document from the last time around: ** *config term* * router bgp .... !core instance vrf-policy <vrf-name> rd <value> route-map <mapname> label <value> #nexthop ip <> | ipv6 <> Rt import <> | export <> | both <> [no] tunnel advertisement-method <encap-attribute|evpn> tunnel type <none| l2tpv3overip | gre | ipinip | vxlan | mpls | mplsovergre > route-map rmap permit 10 Set label <value> set extcommunity rt 10:100 set extcommunity soo 10:102 set ip nexthop <> | ipv6 nexthop <>* router bgp XXX vrf <vrf-name>* ! (address-family ipv4) network 1.2.3.0/24 <http://1.2.3.0/24>route-map foo neighbor ... ! CE session (or alternately, VRF-lite session) !make vrf redistribution (import/export)the default redistribute static|ospf|vrf [route map] ...! CE setup for OSPF no redistribute vrf no export vrf export vrf [route map] ... add [vrf <vrf-name>] prefix <prefix> [rd <value>] [label <value>] [pref (0-255)] clear [vrf <vrf-name>] <all|prefix <prefix> [rd <value>]|rd <value>> <extracted from google docs notes> Lou On 6/13/2017 3:08 PM, Vivek Venkatraman wrote: > 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 <http://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 > > > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev

1 0

FRR web site source in git
by JR Rivers 15 Jun '17

15 Jun '17

Hi all- I wanted to let you know that I've committed the web site code into the FRR GitHub project at https://github.com/FRRouting/frr-www. The Maintainers group has the ability to write the repository and myself, Donald, and Martin currently have access to the web server to enact updates. cheers, JR

1 0

Announcing BABEL availability for FRR on master
by Donald Sharp 13 Jun '17

13 Jun '17

I'd like to thank Juliusz, Matthieu, and David for putting their time forward for helping getting BABEL Integrated into FRR. This code is available on the master branch. The RFC is https://tools.ietf.org/html/rfc6126 thanks! donald

2 1

Today's Technical Meeting 11 am EST
by Donald Sharp 13 Jun '17

13 Jun '17

https://bluejeans.com/9192742159 1) 3.0 bugs 2) New Issues 3) PR's 4) Anything else? donald

2 2

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

13 Jun '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. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1441571: Security best practices violations (DC.WEAK_CRYPTO) /babeld/util.c: 144 in timeval_min_sec() ________________________________________________________________________________________________________ *** CID 1441571: Security best practices violations (DC.WEAK_CRYPTO) /babeld/util.c: 144 in timeval_min_sec() 138 /* set d to min(d, x) with x in [secs, secs+1] */ 139 void 140 timeval_min_sec(struct timeval *d, time_t secs) 141 { 142 if(d->tv_sec == 0 || d->tv_sec > secs) { 143 d->tv_sec = secs; >>> CID 1441571: Security best practices violations (DC.WEAK_CRYPTO) >>> "random" should not be used for security related applications, as linear congruential algorithms are too easy to break. 144 d->tv_usec = random() % 1000000; 145 } 146 } 147 148 /* parse a float value in second and return the corresponding mili-seconds. 149 For example: ** CID 1441570: Security best practices violations (DC.WEAK_CRYPTO) /babeld/babeld.c: 200 in babel_init_routing_process() ________________________________________________________________________________________________________ *** CID 1441570: Security best practices violations (DC.WEAK_CRYPTO) /babeld/babeld.c: 200 in babel_init_routing_process() 194 /* Zebra will give some information, especially about interfaces. This function 195 must be call with a litte timeout wich may give zebra the time to do his job, 196 making these inits have sense. */ 197 static int 198 babel_init_routing_process(struct thread *thread) 199 { >>> CID 1441570: Security best practices violations (DC.WEAK_CRYPTO) >>> "random" should not be used for security related applications, as linear congruential algorithms are too easy to break. 200 myseqno = (random() & 0xFFFF); 201 babel_get_myid(); 202 babel_load_state_file(); 203 debugf(BABEL_DEBUG_COMMON, "My ID is : %s.", format_eui64(myid)); 204 babel_initial_noise(); 205 babel_main_loop(thread);/* this function self-add to the t_update thread */ ** CID 1441569: Security best practices violations (DC.WEAK_CRYPTO) /babeld/babel_interface.c: 1423 in babel_interface_allocate() ________________________________________________________________________________________________________ *** CID 1441569: Security best practices violations (DC.WEAK_CRYPTO) /babeld/babel_interface.c: 1423 in babel_interface_allocate() 1417 1418 /* Here are set the default values for an interface. */ 1419 memset(babel_ifp, 0, sizeof(babel_interface_nfo)); 1420 /* All flags are unset */ 1421 babel_ifp->bucket_time = babel_now.tv_sec; 1422 babel_ifp->bucket = BUCKET_TOKENS_MAX; >>> CID 1441569: Security best practices violations (DC.WEAK_CRYPTO) >>> "random" should not be used for security related applications, as linear congruential algorithms are too easy to break. 1423 babel_ifp->hello_seqno = (random() & 0xFFFF); 1424 babel_ifp->rtt_min = 10000; 1425 babel_ifp->rtt_max = 120000; 1426 babel_ifp->max_rtt_penalty = 150; 1427 babel_ifp->hello_interval = BABEL_DEFAULT_HELLO_INTERVAL; 1428 babel_ifp->update_interval = BABEL_DEFAULT_UPDATE_INTERVAL; ** CID 1441568: Security best practices violations (DC.WEAK_CRYPTO) /babeld/util.c: 50 in roughly() ________________________________________________________________________________________________________ *** CID 1441568: Security best practices violations (DC.WEAK_CRYPTO) /babeld/util.c: 50 in roughly() 44 { 45 if(value < 0) 46 return -roughly(-value); 47 else if(value <= 1) 48 return value; 49 else >>> CID 1441568: Security best practices violations (DC.WEAK_CRYPTO) >>> "random" should not be used for security related applications, as linear congruential algorithms are too easy to break. 50 return value * 3 / 4 + random() % (value / 2); 51 } 52 53 /* d = s1 - s2 */ 54 void 55 timeval_minus(struct timeval *d, ** CID 743090: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 743090: Memory - corruptions (OVERRUN) /babeld/message.c: 1249 in flushupdates() 1243 channels[0] = babel_route_ifp->channel; 1244 } 1245 memcpy(channels + 1, route->channels, DIVERSITY_HOPS - 1); 1246 } 1247 1248 chlen = channels_len(channels); >>> CID 743090: Memory - corruptions (OVERRUN) >>> Overrunning array "route->src->id" of 8 bytes by passing it to a function which accesses it at byte offset 15. 1249 really_send_update(ifp, route->src->id, 1250 route->src->prefix, 1251 route->src->plen, 1252 seqno, metric, 1253 channels, chlen); 1254 update_source(route->src, seqno, metric); ** CID 743089: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 743089: Memory - corruptions (OVERRUN) /babeld/message.c: 1207 in flushupdates() 1201 } 1202 1203 xroute = find_xroute(b[i].prefix, b[i].plen); 1204 route = find_installed_route(b[i].prefix, b[i].plen); 1205 1206 if(xroute && (!route || xroute->metric <= kernel_metric)) { >>> CID 743089: Memory - corruptions (OVERRUN) >>> Overrunning array "myid" of 8 bytes by passing it to a function which accesses it at byte offset 15. 1207 really_send_update(ifp, myid, 1208 xroute->prefix, xroute->plen, 1209 myseqno, xroute->metric, 1210 NULL, 0); 1211 last_prefix = xroute->prefix; 1212 last_plen = xroute->plen; ________________________________________________________________________________________________________ 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 09 Jun '17

09 Jun '17

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 2 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1440982: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1440982: Null pointer dereferences (NULL_RETURNS) /bgpd/bgp_routemap.c: 3700 in set_label_index() 3694 "set label-index (0-1048560)", 3695 SET_STR 3696 "Label index to associate with the prefix\n" 3697 "Label index value\n") 3698 { 3699 int idx_number = 2; >>> CID 1440982: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_add". 3700 return generic_set_add (vty, VTY_GET_CONTEXT(route_map_index), "label-index", 3701 argv[idx_number]->arg); 3702 } 3703 3704 DEFUN (no_set_label_index, 3705 no_set_label_index_cmd, ** CID 1440981: (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1440981: (NULL_RETURNS) /bgpd/bgp_routemap.c: 3714 in no_set_label_index() 3708 SET_STR 3709 "Label index to associate with the prefix\n" 3710 "Label index value\n") 3711 { 3712 int idx_label_index = 3; 3713 if (argc <= idx_label_index) >>> CID 1440981: (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_delete". 3714 return generic_set_delete (vty, VTY_GET_CONTEXT(route_map_index), 3715 "label-index", NULL); 3716 return generic_set_delete (vty, VTY_GET_CONTEXT(route_map_index), "label-index", 3717 argv[idx_label_index]->arg); 3718 } 3719 /bgpd/bgp_routemap.c: 3716 in no_set_label_index() 3710 "Label index value\n") 3711 { 3712 int idx_label_index = 3; 3713 if (argc <= idx_label_index) 3714 return generic_set_delete (vty, VTY_GET_CONTEXT(route_map_index), 3715 "label-index", NULL); >>> CID 1440981: (NULL_RETURNS) >>> Dereferencing a pointer that might be null "(struct route_map_index *)qobj_get_typed(vty->qobj_index, &qobj_t_route_map_index)" when calling "generic_set_delete". 3716 return generic_set_delete (vty, VTY_GET_CONTEXT(route_map_index), "label-index", 3717 argv[idx_label_index]->arg); 3718 } 3719 3720 DEFUN (set_aspath_prepend_asn, 3721 set_aspath_prepend_asn_cmd, ________________________________________________________________________________________________________ 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

FRR Packaging: existing guidelines and future plans
by Scott Leggett 07 Jun '17

07 Jun '17

Hi, I'm the current maintainer of quagga in Debian (new maintainer - only as of < 1 year). I just wanted to start a discussion about frr distro integration, and have some questions about the frr roadmap :-) I see that on your wiki[0] and in at least one recent merge[1] that you are moving towards a single system service controlling multiple daemons. I recently removed this feature from the Debian quagga package and replaced it with individual services because I think that the single service controlling multiple daemons is a mistake. There are some subtle bugs in the old debian service management scripts (e.g. [2],[3]), and having a special new mechanism to learn to control the frr daemons, which is different to the way that every other service works, is quite annoying. From the viewpoint of a distro maintainer, it is inconsistent with the unified distribution experience. And finally, disallowing the system service manager (e.g. systemd) from having proper oversight of individual services leads to a significant loss in functionality (e.g. all the features of systemd.exec[4]). In [0] you describe the main motivation for the single system service being that watchfrr is going to start and stop daemons in response to config or vtysh commands. Have you considered using dbus to command the service manager to start and stop daemons instead[5]? On a totally different topic, I thought I saw somewhere that frr is planning to deprecate individual service config files in favour of the integrated config. Is that the case? [0] https://github.com/FRRouting/frr/wiki/Distro-&-Packaging-README-FAQ [1] https://github.com/FRRouting/frr/pull/378 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678946 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412483 [4] https://www.freedesktop.org/software/systemd/man/systemd.exec.html [5] https://www.freedesktop.org/wiki/Software/systemd/dbus/ -- Regards, Scott.

2 2

Todays Technical Meeting Agenda
by Donald Sharp 06 Jun '17

06 Jun '17

1 ) New Issues 2) PR's 3) Anything else? donald

1 1

Re: [dev] Zebra Dataplane module meeting
by Bingen Eguzkitza 06 Jun '17

06 Jun '17

Sorry, I forgot the Subject. :-o On Tue, May 30, 2017 at 10:40 AM, Bingen Eguzkitza <bingen(a)voltanet.io> wrote: > Hi all, > > as we talked during last weekly technical meeting, here you have a Doodle > to set up a meeting to discuss the Zebra Dataplane module: > > https://doodle.com/poll/uwyy7t6edqbg2ucu > > For reference, this is the PR: > > https://github.com/FRRouting/frr/pull/602 > > Choose the options that work for you if you want to be part of the > discussion. > > Thanks, > > ßingen. > > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev > >

2 4

[Update] Zebra Dataplane Module discussion
by bingen＠voltanet.io 06 Jun '17

06 Jun '17

Does it work now, Vincent? ßingen. You have been invited to the following event. Title: Zebra Dataplane Module discussion Donald, can we use you BlueJeans meeting? https://bluejeans.com/9192742159 When: Wed Jun 7, 2017 5pm – 6pm Madrid Where: https://bluejeans.com/9192742159 Video call: https://plus.google.com/hangouts/_/voltanet.io/bingen <https://plus.google.com/hangouts/_/voltanet.io/bingen?hceid=YmluZ2VuQHZvbHR…> Who: * bingen(a)voltanet.io - organizer

2 1