- dev - lists.frrouting.org

Announcing PBR for FRR
by Donald Sharp 11 Apr '18

11 Apr '18

All - I'd like to announce the availability of a new daemon for FRR on the master branch. PBR( Policy Based Routing ) allows operators to setup policy maps that allow special control forwarding. To configure PBR, see `doc/user/pbr.rst`. Here is a quick example of how to configure: nexthop-group EVA nexthop 4.3.2.1 swp5 nexthop 6.4.3.2 ! pbr-map DONNA seq 10 match src-ip 192.168.210.0/24 match dst-ip 192.168.140.0/24 set nexthop-group EVA ! int swp54 pbr-policy DONNA ! This configuration says, on the incoming interface swp54 if the src matches 192.168.210.0/24 and the dest matches 192.168.140.0/24, use nexthop-group EVA for forwarding the packet. I'd like to thank Vivek, Don, Quentin, Philippe and Russ for their hard work on getting this code into FRR. thanks! donald

1 0

FRRouting - RIP VRF Support.
by amit.tiwari＠inventum.net 09 Apr '18

09 Apr '18

Hi Kunihiro, I have compiled FRRouting master branch and deployed it on my router, bgp and ospf are working fine with vrf. Whereas, in case of RIP, vrf doesn't seems to be working, there is no vrf support even at CLI level. May we know, when are you guys releasing frrouting with full vrf support in RIP. Regards, Amit Kumar Tiwari 9953769181

3 2

please invite me to slack channel.
by abbas ali chezgi 09 Apr '18

09 Apr '18

please invite me to slack channel. -- ================================= chezgi,abbas ali MSC student at computer Architecture Department of Electronic and Computer Engineering Isfahan University of Technology Isfahan Iran email: chezgi(AT)ec(DOT)iut(DOT)ac(DOT)ir =================================

2 1

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

06 Apr '18

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 1467487: (RESOURCE_LEAK) /ospf6d/ospf6_intra.c: 1720 in ospf6_intra_prefix_lsa_remove() /ospf6d/ospf6_intra.c: 1914 in ospf6_intra_prefix_lsa_remove() ________________________________________________________________________________________________________ *** CID 1467487: (RESOURCE_LEAK) /ospf6d/ospf6_intra.c: 1720 in ospf6_intra_prefix_lsa_remove() 1714 if (prefix_num == 0) 1715 break; 1716 if (end < current + OSPF6_PREFIX_SIZE(op)) 1717 break; 1718 prefix_num--; 1719 >>> CID 1467487: (RESOURCE_LEAK) >>> Overwriting "route_to_del" in "route_to_del = ospf6_route_create()" leaks the storage that "route_to_del" points to. 1720 route_to_del = ospf6_route_create(); 1721 1722 memset(&route_to_del->prefix, 0, sizeof(struct prefix)); 1723 route_to_del->prefix.family = AF_INET6; 1724 route_to_del->prefix.prefixlen = op->prefix_length; 1725 ospf6_prefix_in6_addr(&route_to_del->prefix.u.prefix6, op); /ospf6d/ospf6_intra.c: 1914 in ospf6_intra_prefix_lsa_remove() 1908 1909 ospf6_route_delete(route_to_del); 1910 } 1911 1912 if (current != end && IS_OSPF6_DEBUG_EXAMIN(INTRA_PREFIX)) 1913 zlog_debug("Trailing garbage ignored"); >>> CID 1467487: (RESOURCE_LEAK) >>> Variable "route_to_del" going out of scope leaks the storage it points to. 1914 } 1915 1916 void ospf6_intra_route_calculation(struct ospf6_area *oa) 1917 { 1918 struct ospf6_route *route, *nroute; 1919 uint16_t type; ** CID 1467486: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_mplsvpn.c: 475 in leak_update() ________________________________________________________________________________________________________ *** CID 1467486: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_mplsvpn.c: 475 in leak_update() 469 /* 470 * nexthop tracking for unicast routes 471 */ 472 struct bgp *bgp_nexthop = bgp; 473 int nh_valid; 474 >>> CID 1467486: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "new->extra" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 475 if (new->extra && new->extra->bgp_orig) 476 bgp_nexthop = new->extra->bgp_orig; 477 478 /* 479 * No nexthop tracking for redistributed routes because 480 * their originating protocols will do the tracking and ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, 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 04 Apr '18

04 Apr '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 1467453: Resource leaks (RESOURCE_LEAK) /vtysh/vtysh.c: 318 in vtysh_execute_func() ________________________________________________________________________________________________________ *** CID 1467453: Resource leaks (RESOURCE_LEAK) /vtysh/vtysh.c: 318 in vtysh_execute_func() 312 if (vline == NULL) 313 return CMD_SUCCESS; 314 315 if (user_mode) { 316 if (strncmp("en", vector_slot(vline, 0), 2) == 0) { 317 fprintf(stdout, "%% Command not allowed: enable\n"); >>> CID 1467453: Resource leaks (RESOURCE_LEAK) >>> Variable "vline" going out of scope leaks the storage it points to. 318 return CMD_WARNING; 319 } 320 } 321 322 saved_ret = ret = cmd_execute_command(vline, vty, &cmd, 1); 323 saved_node = vty->node; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

why fork Quagga?
by Carla Schroder 04 Apr '18

04 Apr '18

Hello FRR devs, I'm writing an article on FRRouting for Linux.com. I've read a number of articles on why it was forked from Quagga (for example http://www.enterprisenetworkingplanet.com/netsp/free-range-routing-protocol… and http://packetpushers.net/free-range-routing-project-forks-quagga/) Is there anything anyone would like to add or correct? It's not a huge deal and I'm not looking for scandals. Readers will want to know the reasons for forking. It looks like the tl;dr version is 'quagga was bottlenecked by a single maintainer and development stalled'. I've also seen discussion on frrouting.org about new features and support for additional protocols-- anyone care to comment what these new things mean for network admins? You don't have to write a book, summaries like "We're working on support for Foov5, which means transferring good beer securely over untrusted networks!" are good. If there is anything else you think is cool and needs to be shared, throw that in too. I will attribute any comments that I use, so if you want to be anonymous let me know. My deadline is Tuesday evening. I know that's not much time--welcome to my world :) thanks, Carla -- ++++++++++++++++++++++++++++++++++++++++ Ace Linux guru + carlaschroder.com + Where words fail, music speaks. + ++++++++++++++++++++++++++++++++++++++++

8 10

Re: [dev] why fork Quagga?
by Russ White 03 Apr '18

03 Apr '18

Carla -- I saw your message on the FR dev list -- if there is anything I can help you with, in terms of getting the right information down, or reviewing, let me know. 😊 Russ

1 0

`default` keyword?
by Donald Sharp 31 Mar '18

31 Mar '18

So currently if you want to specify the default vrf as a string you have to use: Default-IP-Routing-Table Do people have opinions on what to use? I am thinking of making the keyword `default` special in that it will allow lookup of the default vrf if entered. thoughts? doanld

9 9

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

30 Mar '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 1467125: Resource leaks (RESOURCE_LEAK) /bgpd/bgp_flowspec.c: 176 in bgp_nlri_parse_flowspec() ________________________________________________________________________________________________________ *** CID 1467125: Resource leaks (RESOURCE_LEAK) /bgpd/bgp_flowspec.c: 176 in bgp_nlri_parse_flowspec() 170 snprintf(local_string, BGP_FLOWSPEC_NLRI_STRING_MAX, 171 "FS Rx %s %s %s %s", withdraw ? 172 "Withdraw":"Update", 173 afi2str(afi), return_string, 174 attr != NULL ? ec_string : ""); 175 zlog_info("%s", local_string); >>> CID 1467125: Resource leaks (RESOURCE_LEAK) >>> Variable "s" going out of scope leaks the storage it points to. 176 } 177 /* Process the route. */ 178 if (!withdraw) 179 ret = bgp_update(peer, &p, 0, attr, 180 afi, safi, 181 ZEBRA_ROUTE_BGP, BGP_ROUTE_NORMAL, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Question about EVPN route types
by Jay Chen 29 Mar '18

29 Mar '18

Hi all, I got a question about what EVPN route types are supported already in the latest version. It looks like type-2, type-3, and type-5 are supported. Type-1, and type-4 are not yet. If it is true, any plan the missing types are going to be supported? Another quick question, the fpm/fpm_pb.c file looks empty. Is there a missing patch need to be patched? It will be very helpful if anyone can point to a brief example how fpm is used by a switch that has a hardware forwarding path? Thanks, Jay

6 8