May 2019 - dev - lists.frrouting.org

Re: [dev] Request to join Development Mailing List
by Quentin Young 24 May '19

24 May '19

Looks like you’re on it :-) Quentin > On May 23, 2019, at 8:51 PM, Rakesh Garg via dev <dev(a)lists.frrouting.org> wrote: > > > From: Rakesh Garg <rakesh.garg(a)mavenir.com <mailto:rakesh.garg@mavenir.com>> > Subject: Request to join Development Mailing List > Date: May 22, 2019 at 2:35:17 AM EDT > To: "dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org>" <dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org>> > > > Hi Team, > > We are planning to integrate FRRouting stack with one of our products, so wanted to join the list to discuss and document the issues and/or propose any enhancements. > Request you to add me to the mailing list for the same. > > Regards, > Rakesh > This e-mail message may contain confidential or proprietary information of Mavenir Systems, Inc. or its affiliates and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies in your control and contact us by e-mailing to security(a)mavenir.com <mailto:security@mavenir.com>. This message contains the views of its author and may not necessarily reflect the views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor email messages, but make no representation that such messages are authorized, secure, uncompromised, or free from computer viruses, malware, or other defects. Thank You > > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org <mailto:dev@lists.frrouting.org> > https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev>

1 0

About RFC 7854
by Sebastian Z. 24 May '19

24 May '19

Dear Sir/Madam, I hope you are doing well, and thank you for the development of FRR. My name is Sebastian, I am a researcher currently working on SDN between internet domains. For this I was looking at the BGP Monitoring Protocol as defined on the RFC7854, and I would like to kindly ask if there is any ongoing project for the inclusion of this protocol into the FRR implementation, or maybe in the future. I believe it is a very handy protocol for traffic engineering and BGP, but unfortunately there is no implementation among software routers, just in Cisco IOS, JuNOS, etc. I appreciate in advance your attention and advice. Kind Regards, Sebastian

2 1

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 22 May '19

22 May '19

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 1480402: (DEADCODE) /zebra/zebra_fpm_netlink.c: 444 in netlink_route_info_encode() /zebra/zebra_fpm_netlink.c: 499 in netlink_route_info_encode() ________________________________________________________________________________________________________ *** CID 1480402: (DEADCODE) /zebra/zebra_fpm_netlink.c: 444 in netlink_route_info_encode() 438 439 encap = nhi->encap_info.encap_type; 440 if (encap > FPM_NH_ENCAP_NONE) { 441 addattr_l(&req->n, in_buf_len, RTA_ENCAP_TYPE, &encap, 442 sizeof(uint16_t)); 443 switch (encap) { >>> CID 1480402: (DEADCODE) >>> Execution cannot reach this statement: "case FPM_NH_ENCAP_NONE:". 444 case FPM_NH_ENCAP_NONE: 445 break; 446 case FPM_NH_ENCAP_VXLAN: 447 vxlan = &nhi->encap_info.vxlan_encap; 448 nest = addattr_nest(&req->n, in_buf_len, 449 RTA_ENCAP); /zebra/zebra_fpm_netlink.c: 499 in netlink_route_info_encode() 493 if (encap > FPM_NH_ENCAP_NONE) { 494 rta_addattr_l(rta, sizeof(buf), RTA_ENCAP_TYPE, 495 &encap, sizeof(uint16_t)); 496 rtnh->rtnh_len += sizeof(struct rtattr) + 497 sizeof(uint16_t); 498 switch (encap) { >>> CID 1480402: (DEADCODE) >>> Execution cannot reach this statement: "case FPM_NH_ENCAP_NONE:". 499 case FPM_NH_ENCAP_NONE: 500 break; 501 case FPM_NH_ENCAP_VXLAN: 502 vxlan = &nhi->encap_info.vxlan_encap; 503 nest = rta_nest(rta, sizeof(buf), RTA_ENCAP); 504 rta_addattr_l(rta, sizeof(buf), VXLAN_VNI, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Request to join Development Mailing List
by Rakesh Garg 22 May '19

22 May '19

Hi Team, We are planning to integrate FRRouting stack with one of our products, so wanted to join the list to discuss and document the issues and/or propose any enhancements. Request you to add me to the mailing list for the same. Regards, Rakesh ________________________________ This e-mail message may contain confidential or proprietary information of Mavenir Systems, Inc. or its affiliates and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies in your control and contact us by e-mailing to security(a)mavenir.com. This message contains the views of its author and may not necessarily reflect the views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor email messages, but make no representation that such messages are authorized, secure, uncompromised, or free from computer viruses, malware, or other defects. Thank You

1 0

Protobuf (FPM) usage survey
by David Lamparter 21 May '19

21 May '19

Hello FRR users and developers, since some extensions to the FPM interface are currently happening, it'd be nice to know how much the Protobuf interface is used. We know the netlink encoding is well used, but we don't have data for Protobuf. If you're using **Protobuf** FPM, please send a mail (in private if necessary.) Again just to be clear: this is about Protobuf FPM, NOT Netlink FPM. Cheers, -David

1 0

FPM, vrf's and table-id
by Donald Sharp 20 May '19

20 May '19

All - Current behavior of the FPM code is to encode the vrf_id as a uint8_t piece of data and send to the remote listener. This current approach is broken for a variety of reasons, not the least of which is that the vrf_id of a vrf is either the ifindex of the vrf-lite device created or the namespace id. Both of which quite easily go beyond the limit of what can be smushed into a uint8_t size. Thus we have a situation where FPM listeners would get incorrect data about tables. After some discussion we have decided that since this is broken in a bunch of different ways that there is no real good course of action here other than to just update the code to behave like the netlink behavior we see in linux. Namely we will write the table_id we are writing the route to as an uint32_t attribute RTA_TABLE. If you have further questions about this please look at 6dfcd75461ff35ebf89e86f64fe6e982ed09b3e3 thanks! donald

1 0

FRR 7.1 & 8.0 release timelines
by Narendra Bandarupalli 20 May '19

20 May '19

Hello, Can someone please share planned release dates for FRR 7.1 and 8.0 releases. I see FRR 7.1 milestone is created – all submits into master branch as on today are targeted for 7.1 release? Thanks Narendra

2 1

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

17 May '19

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 5 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 1480235: Incorrect expression (NO_EFFECT) /vrrpd/vrrp.c: 1387 in vrrp_change_state_initialize() ________________________________________________________________________________________________________ *** CID 1480235: Incorrect expression (NO_EFFECT) /vrrpd/vrrp.c: 1387 in vrrp_change_state_initialize() 1381 * 1382 * r 1383 * VRRP Router to operate on 1384 */ 1385 static void vrrp_change_state_initialize(struct vrrp_router *r) 1386 { >>> CID 1480235: Incorrect expression (NO_EFFECT) >>> Assigning "r->vr->advertisement_interval" to itself has no effect. 1387 r->vr->advertisement_interval = r->vr->advertisement_interval; 1388 r->master_adver_interval = 0; 1389 vrrp_recalculate_timers(r); 1390 1391 r->advert_pending = false; 1392 r->garp_pending = false; ** CID 1480234: Integer handling issues (NEGATIVE_RETURNS) ________________________________________________________________________________________________________ *** CID 1480234: Integer handling issues (NEGATIVE_RETURNS) /vrrpd/vrrp_arp.c: 145 in vrrp_garp_send() 139 VRRP_LOGPFX VRRP_LOGPFX_VRID VRRP_LOGPFX_FAM 140 "Sending gratuitous ARP on %s for %s", 141 r->vr->vrid, family2str(r->family), ifp->name, astr); 142 if (DEBUG_MODE_CHECK(&vrrp_dbg_arp, DEBUG_MODE_ALL)) 143 zlog_hexdump(garpbuf, garpbuf_len); 144 >>> CID 1480234: Integer handling issues (NEGATIVE_RETURNS) >>> "garpbuf_len" is passed to a parameter that cannot be negative. 145 sent_len = vrrp_send_garp(ifp, garpbuf, garpbuf_len); 146 147 if (sent_len < 0) 148 zlog_warn(VRRP_LOGPFX VRRP_LOGPFX_VRID VRRP_LOGPFX_FAM 149 "Error sending gratuitous ARP on %s for %s", 150 r->vr->vrid, family2str(r->family), ifp->name, astr); ** CID 1480233: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1480233: Memory - corruptions (OVERRUN) /vrrpd/vrrp_ndisc.c: 142 in vrrp_ndisc_una_build() 136 struct ipv6_ph ph = {}; 137 138 ph.src = ip6h->ip6_src; 139 ph.dst = ip6h->ip6_dst; 140 ph.ulpl = htonl(len); 141 ph.next_hdr = IPPROTO_ICMPV6; >>> CID 1480233: Memory - corruptions (OVERRUN) >>> Overrunning struct type icmp6_hdr of 8 bytes by passing it to a function which accesses it at byte offset 31 using argument "len" (which evaluates to 32). 142 icmp6h->icmp6_cksum = in_cksum_with_ph6(&ph, (void *)icmp6h, len); 143 144 return 0; 145 } 146 147 int vrrp_ndisc_una_send(struct vrrp_router *r, struct ipaddr *ip) ** CID 1480232: Uninitialized variables (UNINIT) /vrrpd/vrrp.c: 984 in vrrp_read() ________________________________________________________________________________________________________ *** CID 1480232: Uninitialized variables (UNINIT) /vrrpd/vrrp.c: 984 in vrrp_read() 978 m.msg_namelen = sizeof(sa); 979 m.msg_iov = &iov; 980 m.msg_iovlen = 1; 981 m.msg_control = control; 982 m.msg_controllen = sizeof(control); 983 >>> CID 1480232: Uninitialized variables (UNINIT) >>> Using uninitialized value "m". Field "m.msg_flags" is uninitialized when calling "recvmsg". 984 nbytes = recvmsg(r->sock_rx, &m, MSG_DONTWAIT); 985 986 if ((nbytes < 0 && ERRNO_IO_RETRY(errno))) { 987 resched = true; 988 goto done; 989 } else if (nbytes <= 0) { ** CID 1480231: Error handling issues (CHECKED_RETURN) /vrrpd/vrrp.c: 766 in vrrp_send_advertisement() ________________________________________________________________________________________________________ *** CID 1480231: Error handling issues (CHECKED_RETURN) /vrrpd/vrrp.c: 766 in vrrp_send_advertisement() 760 761 if (DEBUG_MODE_CHECK(&vrrp_dbg_pkt, DEBUG_MODE_ALL)) 762 zlog_hexdump(pkt, (size_t)pktsz); 763 764 const char *group = r->family == AF_INET ? VRRP_MCASTV4_GROUP_STR 765 : VRRP_MCASTV6_GROUP_STR; >>> CID 1480231: Error handling issues (CHECKED_RETURN) >>> Calling "str2sockunion" without checking return value (as is done elsewhere 26 out of 27 times). 766 str2sockunion(group, &dest); 767 768 ssize_t sent = sendto(r->sock_tx, pkt, (size_t)pktsz, 0, &dest.sa, 769 sockunion_sizeof(&dest)); 770 771 XFREE(MTYPE_VRRP_PKT, pkt); ________________________________________________________________________________________________________ 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 16 May '19

16 May '19

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. 12 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 1480221: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1480221: Null pointer dereferences (NULL_RETURNS) /zebra/redistribute.c: 773 in zebra_import_table_rm_update() 767 768 rmap_name = zebra_get_import_table_route_map(afi, i); 769 if ((!rmap_name) || (strcmp(rmap_name, rmap) != 0)) 770 continue; 771 table = zebra_vrf_table_with_table_id(afi, SAFI_UNICAST, 772 i, VRF_DEFAULT); >>> CID 1480221: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "table" when calling "route_top". 773 for (rn = route_top(table); rn; rn = route_next(rn)) { 774 /* For each entry in the non-default 775 * routing table, 776 * add the entry in the main table 777 */ 778 if (!rn->info) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Feature List : #2639
by Harpreet Kaur 16 May '19

16 May '19

Hi, We are looking for the segment routing support in IS-IS implementation of FRrouting. We see that there is an issue #2639 which mentions this enhancement. Is there anyone who's working on this issue? Also, is it SRv6 or SR-MPLS (since OSPF in FRRouting has SR-MPLS only)? Thanks Harpreet DISCLAIMER: This electronic message and all of its contents, contains information which is privileged, confidential or otherwise protected from disclosure. The information contained in this electronic mail transmission is intended for use only by the individual or entity to which it is addressed. If you are not the intended recipient or may have received this electronic mail transmission in error, please notify the sender immediately and delete / destroy all copies of this electronic mail transmission without disclosing, copying, distributing, forwarding, printing or retaining any part of it. Hughes Systique accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus.

2 3