August 2017 - dev - lists.frrouting.org

Missing developer documentation
by Olivier Dugeon 12 Dec '17

12 Dec '17

Hiall, There is missing developer documentation in FRR. In PR #805 I try to update an old Zebra hacking document, but that seems too old to be publish, so I prefer to remove it as suggested during the PR review. For me, the main problem is how to start writing a such documentation ? First, it is too huge and to complicated to be written by only one person. Second, we need a dedicated space (e.g. a new doc project inside FRRouting) to collectively write such documentation and then push into frr master documents when they are ready. Finally, we need to organize themselves in order to collectively decided how to write them, to formalize the document through a common template, to harmonize the documentation... I would start by proposing: * start discussion about this new topic (create a new issue in github) during regular meeting * decide the document format (Markdown, in line github Wiki, LaTeX, TeXi ...) * create a new doc project within FRRouting * propose template * propose Table of Content for each document (perhaps partially common) * open contribution to the different documents Comments are welcome. Regards Olivier

4 6

FRR, NVO3, VNC, .. what happens underneath?
by Raymond Burkholder 02 Sep '17

02 Sep '17

Hello, I have a network virtualisation scenario, and I think FRR might be a part of it, but I am not sure. I have taken a look at https://frrouting.org/user-guide/VNC-and-VNC_002dGW.html, and taken a quick skim of the NVO3 stuff. The NVO3 stuff references a bunch of possibilities. The FRR site provides command descriptions and a few examples. The bit missing from the FRR site is what happens underneath? What is actually used for encapsulation? How does FRR interact with the encapsulation layer? There was a one word reference to OpenFlow, but what is the glue that ties FRR, VNC, and the underpinnings together, particularly in a Linux environment? Are there any presentations, blog entries, black-magic or dark-art places describing example scenarios? Or is it really just that simple? An additional search problem is that VNC refers to screen virtualisation, so search parameters become delicate. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 4

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

31 Aug '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. 78 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 2 of 2 defect(s) ** CID 1455230: Resource leaks (RESOURCE_LEAK) /eigrpd/eigrp_packet.c: 275 in eigrp_make_sha256_digest() ________________________________________________________________________________________________________ *** CID 1455230: Resource leaks (RESOURCE_LEAK) /eigrpd/eigrp_packet.c: 275 in eigrp_make_sha256_digest() 269 if (keychain) 270 key = key_lookup_for_send(keychain); 271 272 if (!key) { 273 zlog_warn("Interface %s: Expected key value not found in config", 274 ei->ifp->name); >>> CID 1455230: Resource leaks (RESOURCE_LEAK) >>> Variable "auth_TLV" going out of scope leaks the storage it points to. 275 return 0; 276 } 277 278 inet_ntop(AF_INET, &ei->address->u.prefix4, source_ip, PREFIX_STRLEN); 279 280 memset(&ctx, 0, sizeof(ctx)); ** CID 1455229: (BUFFER_SIZE_WARNING) /eigrpd/eigrp_packet.c: 625 in eigrp_read() /eigrpd/eigrp_packet.c: 626 in eigrp_read() ________________________________________________________________________________________________________ *** CID 1455229: (BUFFER_SIZE_WARNING) /eigrpd/eigrp_packet.c: 625 in eigrp_read() 619 start of the eigrp TLVs */ 620 opcode = eigrph->opcode; 621 622 if (IS_DEBUG_EIGRP_TRANSMIT(0, RECV)) { 623 char src[PREFIX_STRLEN], dst[PREFIX_STRLEN]; 624 >>> CID 1455229: (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 51 bytes on destination array "src" of size 51 bytes might leave the destination string unterminated. 625 strncpy(src, inet_ntoa(iph->ip_src), PREFIX_STRLEN); 626 strncpy(dst, inet_ntoa(iph->ip_dst), PREFIX_STRLEN); 627 zlog_debug("Received [%s][%d/%d] length [%u] via [%s] src [%s] dst [%s]", 628 lookup_msg(eigrp_packet_type_str, opcode, NULL), 629 ntohl(eigrph->sequence), ntohl(eigrph->ack), length, 630 IF_NAME(ei), src, dst); /eigrpd/eigrp_packet.c: 626 in eigrp_read() 620 opcode = eigrph->opcode; 621 622 if (IS_DEBUG_EIGRP_TRANSMIT(0, RECV)) { 623 char src[PREFIX_STRLEN], dst[PREFIX_STRLEN]; 624 625 strncpy(src, inet_ntoa(iph->ip_src), PREFIX_STRLEN); >>> CID 1455229: (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 51 bytes on destination array "dst" of size 51 bytes might leave the destination string unterminated. 626 strncpy(dst, inet_ntoa(iph->ip_dst), PREFIX_STRLEN); 627 zlog_debug("Received [%s][%d/%d] length [%u] via [%s] src [%s] dst [%s]", 628 lookup_msg(eigrp_packet_type_str, opcode, NULL), 629 ntohl(eigrph->sequence), ntohl(eigrph->ack), length, 630 IF_NAME(ei), src, dst); 631 } ________________________________________________________________________________________________________ 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 30 Aug '17

30 Aug '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 1455175: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_vxlan.c: 3935 in zebra_vxlan_add_del_gw_macip() ________________________________________________________________________________________________________ *** CID 1455175: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_vxlan.c: 3935 in zebra_vxlan_add_del_gw_macip() 3929 NULL; /* link info for the SVI = bridge info */ 3930 3931 svi_if_zif = ifp->info; 3932 svi_if_link = 3933 if_lookup_by_index_per_ns(zebra_ns_lookup(NS_DEFAULT), 3934 svi_if_zif->link_ifindex); >>> CID 1455175: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "svi_if_zif" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 3935 if (svi_if_zif && svi_if_link) 3936 zvni = zvni_map_svi(ifp, svi_if_link); 3937 } else if (IS_ZEBRA_IF_BRIDGE(ifp)) { 3938 zvni = zvni_map_svi(ifp, ifp); 3939 } 3940 ________________________________________________________________________________________________________ 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 30 Aug '17

30 Aug '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 1455174: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 105 in ip_route() ________________________________________________________________________________________________________ *** CID 1455174: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_vty_clippy.c: 105 in ip_route() 99 #if 10 /* anything to parse? */ 100 int _i; 101 #if 1 /* anything that can fail? */ 102 unsigned _fail = 0, _failcnt = 0; 103 #endif 104 const char *no = NULL; >>> CID 1455174: Null pointer dereferences (FORWARD_NULL) >>> Assigning: "prefix" = "NULL". 105 const char *prefix = NULL; 106 struct in_addr mask = { INADDR_ANY }; 107 const char *mask_str = NULL; 108 struct in_addr gate = { INADDR_ANY }; 109 const char *gate_str = NULL; 110 const char *ifname = 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

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

25 Aug '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. 76 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 2 of 2 defect(s) ** CID 1454848: Error handling issues (CHECKED_RETURN) /eigrpd/eigrp_vty.c: 397 in eigrp_network() ________________________________________________________________________________________________________ *** CID 1454848: Error handling issues (CHECKED_RETURN) /eigrpd/eigrp_vty.c: 397 in eigrp_network() 391 "EIGRP network prefix\n") 392 { 393 VTY_DECLVAR_CONTEXT(eigrp, eigrp); 394 struct prefix p; 395 int ret; 396 >>> CID 1454848: Error handling issues (CHECKED_RETURN) >>> Calling "str2prefix" without checking return value (as is done elsewhere 66 out of 80 times). 397 str2prefix(argv[1]->arg, &p); 398 399 ret = eigrp_network_set(eigrp, &p); 400 401 if (ret == 0) { 402 vty_out(vty, "There is already same network statement.\n"); ** CID 1454847: Error handling issues (CHECKED_RETURN) /eigrpd/eigrp_vty.c: 420 in no_eigrp_network() ________________________________________________________________________________________________________ *** CID 1454847: Error handling issues (CHECKED_RETURN) /eigrpd/eigrp_vty.c: 420 in no_eigrp_network() 414 "EIGRP network prefix\n") 415 { 416 VTY_DECLVAR_CONTEXT(eigrp, eigrp); 417 struct prefix p; 418 int ret; 419 >>> CID 1454847: Error handling issues (CHECKED_RETURN) >>> Calling "str2prefix" without checking return value (as is done elsewhere 66 out of 80 times). 420 str2prefix(argv[2]->arg, &p); 421 422 ret = eigrp_network_unset(eigrp, &p); 423 424 if (ret == 0) { 425 vty_out(vty, "Can't find specified network configuration.\n"); ________________________________________________________________________________________________________ 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 24 Aug '17

24 Aug '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. 2 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 1454646: Control flow issues (DEADCODE) /ospf6d/ospf6_zebra.c: 238 in ospf6_zebra_read_route() ________________________________________________________________________________________________________ *** CID 1454646: Control flow issues (DEADCODE) /ospf6d/ospf6_zebra.c: 238 in ospf6_zebra_read_route() 232 prefix2str((struct prefix *)&api.prefix, prefixstr, 233 sizeof(prefixstr)); 234 if (nexthop) 235 inet_ntop(AF_INET6, nexthop, nexthopstr, 236 sizeof(nexthopstr)); 237 else >>> CID 1454646: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "snprintf(nexthopstr, 128UL,...". 238 snprintf(nexthopstr, sizeof(nexthopstr), "::"); 239 240 zlog_debug( 241 "Zebra Receive route %s: %s %s nexthop %s ifindex %ld tag %" ROUTE_TAG_PRI, 242 (command == ZEBRA_REDISTRIBUTE_ROUTE_ADD ? "add" 243 : "delete"), ________________________________________________________________________________________________________ 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

Re: [dev] (no subject)
by Renato Westphal 23 Aug '17

23 Aug '17

Hi Yuet Siu, The long term goal is to write a plugin for VPP in FRR. We're already working on a new southbound interface in zebra to make this possible. The problem with the VPPsb's router plugin is that it relies on Netlink messages to mirror the kernel's FIB into VPP's FIB, and Netlink is not a reliable protocol (think about thousands of routes being installed at the same time). Also, we need to have a tighter FRR/VPP integration in order to support advances features like VRF, MPLS L2/L3 VPNs, etc. Unfortunately we have no ETA for the moment. Cheers, Renato. On Wed, Aug 23, 2017 at 9:12 AM, Yuet Siu via dev <dev(a)lists.frrouting.org> wrote: > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev > > > ---------- Forwarded message ---------- > From: Yuet Siu <yfsiu1998(a)yahoo.com> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Wed, 23 Aug 2017 02:31:52 +0000 (UTC) > Subject: > Hello, > > I'm a developer interested in the FRR project. I'd like to know about the status of the vpp sandbox part: > > VPP Sandbox/router - fd.io > > VPP Sandbox/router - fd.io > > > > Has it been committed to official vpp lineup yet? > > Does the FRR-routing project has newer software updates as compared to the instructions in: > > FRRouting/frr > > FRRouting/frr > > frr - The FRRouting Protocol Suite > > > Thanks a lot, > > Yuet Siu > > -- Renato Westphal

1 0

(no subject)
by Yuet Siu 23 Aug '17

23 Aug '17

Hello, I'm a developer interested in the FRR project. I'd like to know about the status of the vpp sandbox part: VPP Sandbox/router - fd.io | | | | | | | | | | | VPP Sandbox/router - fd.io | | | | Has it been committed to official vpp lineup yet? Does the FRR-routing project has newer software updates as compared to the instructions in: FRRouting/frr | | | | | | | | | | | FRRouting/frr frr - The FRRouting Protocol Suite | | | | Thanks a lot, Yuet Siu

1 0

evpn on ovs
by Raymond Burkholder 22 Aug '17

22 Aug '17

Using https://vincent.bernat.im/en/blog/2017-vxlan-bgp-evpn as a guideline, I was able to get a test environment up and running. I used brctl for local bridging of test and vxlan interfaces. I switched over to openvswitch using ovs-vsctl commands, and was unsuccessful. When running the following, I am missing a "Master (bridge) ifindex __" line. Everything else seems similar, well, other than Type showing up as Ethernet rather than unknown. Is there a bit of secret sauce to run this against openvswitch, or is this not doable at the moment? I havn't poked at the source code to see how the interaction happens. # sh inter vxlan10 Interface vxlan10 is up, line protocol is up Link ups: 0 last: (never) Link downs: 0 last: (never) PTM status: disabled vrf: Default-IP-Routing-Table index 10 metric 0 mtu 1500 speed 0 flags: <UP,BROADCAST,RUNNING,MULTICAST> Type: Ethernet HWaddr: 2e:69:54:74:05:72 inet6 fe80::2c69:54ff:fe74:572/64 Interface Type Vxlan VxLAN Id 10 VTEP IP: 10.10.10.10 Access VLAN Id 1 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0