- dev - lists.frrouting.org

Northbound work reviews and progress
by Santosh P K 06 Dec '19

06 Dec '19

Hello All, I would like to know if it makes sense to have a call for all the northbound work going on against branch nb_conversions. We have received comments for staticd yang PR https://github.com/FRRouting/frr/pull/5460 we can discuss them as well. We are ready with PIM Yang file which we would like to raise PR but before that if we wanted to have common understanding of how VRF needs to be handled for protocols. There are different data models around and FRR RIP using VRF in different way. 1. In case of IETF – uses VRF at top level and all protocols are under that. 2. In case of Openconfig – uses VRF at the top level and all protocols are under that. +--rw network-instances +--rw network-instance* [name] +--rw name -> ../config/name +--rw protocols +--rw protocol* [identifier name] +--rw identifier -> ../config/identifier +--rw name -> ../config/name +--rw config | +--rw identifier? identityref | +--rw name? string | +--rw enabled? boolean | +--rw default-metric? uint32 +--ro state +--ro identifier? identityref +--ro name? string +--ro enabled? boolean +--ro default-metric? uint32 1. In case of FRR rip – uses VRF as a list under RIP. module: frr-ripd +--rw ripd +--rw instance* [vrf] +--rw vrf string Also I see that there is a new PR for VRF https://github.com/FRRouting/frr/pull/5492 and we have one defined in staticd Yang (as it was not there before). To have common understanding and avoid duplicate effort a call would help. @Donald Sharp<mailto:sharpd@cumulusnetworks.com> Can we use next week Tuesday slot for this discussion? Or shall we schedule a separate meeting on Wednesday or Friday? Please do suggest. Thanks Santosh P K

1 0

Re: [dev] bug fix: ospf6d self orig MaxAge LSA
by Chirag Shah 05 Dec '19

05 Dec '19

Hi Yasuhiro/Santhosh, The commit has introduced the RFC compliance feature to handle premature aging of the LSAs via sending MAXAGEd LSAs. One of the prominent occurrences is router reboot (OSPF6d restart). Narrative: The feature was extensively tested back then and found that there could be an instance where MAX_AGEd LSA lingered in routing domain and received post processing of most recent lower aged LSA (with the same originated router-id). So there is a case where database copy is recent and the received MAXAGEd LSA should not overwrite it. How do you want to handle this? Santhos pointed to a snippet of the code which purges old MAX_AGEd LSA but it can *only* executed if *ismore_recent* is greater than 0. @yasu In your case where OSPF_MAXAGEd LSA is genuine and should not be dropped. *What is the output of the debug where ismore_recent value is printed*? If the value of *ismore_recent *is greater than 0 then it is safe to put that as part of the if statement rather than @yasu suggestion to remove the code snippet. @sapk the action should be taken accordingly as mentioned above "narrative" case where MAXAGEd LSA could overwrite our recent copy of the LSA and flushes out the ospf6 routes. My take away: I do not think MAXAGE LSA will flush out immediately from routing domain so corrective action needs to be taken. Regards, Chirag P.S. It has been roughly more than two years back the ospf6 improvements were handled (specially this feature) so my memory is faded about the full context of the testing of the scenario. I am beginning to restore the context. On Wed, Dec 4, 2019 at 8:55 AM Santosh P K via dev <dev(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: Santosh P K <sapk(a)vmware.com> > To: Yasuhiro Ohara <yasu(a)nttv6.jp>, "dev(a)lists.frrouting.org" < > dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Wed, 4 Dec 2019 16:54:46 +0000 > Subject: Re: [dev] bug fix: ospf6d self orig MaxAge LSA > Hello Yasu, > You are right that your network will be back-holed until the old > MAXAGE is flushed out from neighbors. MAXAGE self originated should be > accepted for flushing out old instance from network faster and then > generate the new version. By accepting maxaged self originated LSA we > trigger event to refresh LSA as part of that we originate new LSA. With > early return that is getting short circuited which is causing issue. > > > With the same commit I saw the below code changes too. > > /* Neighbor router sent recent age for LSA, > * Router could be restarted while current copy is > * MAXAGEd and not removed.*/ > if (OSPF6_LSA_IS_MAXAGE(old) && > !OSPF6_LSA_IS_MAXAGE(new)) { > > if (is_debug) > zlog_debug("%s: Current copy of > LSA %s is MAXAGE, but new has recent Age.", > old->name, > __PRETTY_FUNCTION__); > > ospf6_lsa_purge(old); > if (new->header->adv_router > != from->ospf6_if->area-> > ospf6->router_id) > ospf6_flood(from, new); > > ospf6_install_lsa(new); > return; > } > > I am not sure if this is right as if there is a MAXAGE copy in local > database then we should not be accepting new instance of the same as router > wishes to FLUSH it from the network. Not sure why this is done. Chirag who > did this changes can help with some background. > > Thanks > Santosh P K > > On 04/12/19, 5:05 PM, "dev on behalf of Yasuhiro Ohara" < > dev-bounces(a)lists.frrouting.org on behalf of yasu(a)nttv6.jp> wrote: > > > Hi, > > Today I fixed a bug in ospf6d. > The bug seems to be introduced in the following commit. > > commit 76249532faadfb429f46dd94cf6bbc61d78b3f26 > Date: Fri Jan 26 14:53:43 2018 -0800 > > ospf6d: Handle Premature Aging of LSAs > > When ospf6d is restarting, self originated MaxAged LSAs > may be floating around in the network, and the rebooting ospf6d > is likely to receive them from the neighbor, probably with the > higher LS-Seq-Num (which is more recent). > The code introduced by the above commit in ospf6_flood.c: > @@ -806,6 +818,17 @@ > was removing the more-recent self-originated MaxAged LSAs > immediately in the receiving process of the LSA, prevent the > LSAs from being installed in the local LSDB. > The just rebooted ospf6d will have the lower LS-Seq-Num, so > it cannot refresh the higher LS-Seq-Num version of the old LSA. > So the ospf6d essentially couldn't advertise any information > when the situation occured. > > The bug was significant: the LSAs that can't be updated > in my network included the Router-LSA and the Intra-Area-Prefix-LSA, > so the address in the loopback I/F was not advertised > and the BGP session cannot be established at all. > At some point, the MaxAged LSAs floating in the > network may vanish (I don't know the reason why yet), > and sometimes the problem doesn't occur. > > Commenting out the code by #if 0 immediately solved the problem: > the self-originated MaxAged LSAs are installed in the local LSDB > once, and then ospf6d refreshes it with the updated contents, > and then floods. > > I will make a pull-request later. > > ~/frr/ospf6d# git diff > diff --git a/ospf6d/ospf6_flood.c b/ospf6d/ospf6_flood.c > index 0828c2beb..67172dd4a 100644 > --- a/ospf6d/ospf6_flood.c > +++ b/ospf6d/ospf6_flood.c > @@ -842,6 +842,7 @@ void ospf6_receive_lsa(struct ospf6_neighbor *from, > zlog_debug("Received is duplicated > LSA"); > SET_FLAG(new->flag, OSPF6_LSA_DUPLICATE); > } > +#if 0 > if (old->header->adv_router > == from->ospf6_if->area->ospf6->router_id > && OSPF6_LSA_IS_MAXAGE(new)) { > @@ -854,6 +855,7 @@ void ospf6_receive_lsa(struct ospf6_neighbor *from, > ismore_recent); > return; > } > +#endif /*0*/ > } > > /* if no database copy or received is more recent */ > > Best regards, > Yasu > > > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.frr… > > > > > > ---------- Forwarded message ---------- > From: Santosh P K via dev <dev(a)lists.frrouting.org> > To: Yasuhiro Ohara <yasu(a)nttv6.jp>, "dev(a)lists.frrouting.org" < > dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Wed, 04 Dec 2019 08:55:32 -0800 (PST) > Subject: Re: [dev] bug fix: ospf6d self orig MaxAge LSA > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev >

2 1

bug fix: ospf6d self orig MaxAge LSA
by Yasuhiro Ohara 04 Dec '19

04 Dec '19

Hi, Today I fixed a bug in ospf6d. The bug seems to be introduced in the following commit. commit 76249532faadfb429f46dd94cf6bbc61d78b3f26 Date: Fri Jan 26 14:53:43 2018 -0800 ospf6d: Handle Premature Aging of LSAs When ospf6d is restarting, self originated MaxAged LSAs may be floating around in the network, and the rebooting ospf6d is likely to receive them from the neighbor, probably with the higher LS-Seq-Num (which is more recent). The code introduced by the above commit in ospf6_flood.c: @@ -806,6 +818,17 @@ was removing the more-recent self-originated MaxAged LSAs immediately in the receiving process of the LSA, prevent the LSAs from being installed in the local LSDB. The just rebooted ospf6d will have the lower LS-Seq-Num, so it cannot refresh the higher LS-Seq-Num version of the old LSA. So the ospf6d essentially couldn't advertise any information when the situation occured. The bug was significant: the LSAs that can't be updated in my network included the Router-LSA and the Intra-Area-Prefix-LSA, so the address in the loopback I/F was not advertised and the BGP session cannot be established at all. At some point, the MaxAged LSAs floating in the network may vanish (I don't know the reason why yet), and sometimes the problem doesn't occur. Commenting out the code by #if 0 immediately solved the problem: the self-originated MaxAged LSAs are installed in the local LSDB once, and then ospf6d refreshes it with the updated contents, and then floods. I will make a pull-request later. ~/frr/ospf6d# git diff diff --git a/ospf6d/ospf6_flood.c b/ospf6d/ospf6_flood.c index 0828c2beb..67172dd4a 100644 --- a/ospf6d/ospf6_flood.c +++ b/ospf6d/ospf6_flood.c @@ -842,6 +842,7 @@ void ospf6_receive_lsa(struct ospf6_neighbor *from, zlog_debug("Received is duplicated LSA"); SET_FLAG(new->flag, OSPF6_LSA_DUPLICATE); } +#if 0 if (old->header->adv_router == from->ospf6_if->area->ospf6->router_id && OSPF6_LSA_IS_MAXAGE(new)) { @@ -854,6 +855,7 @@ void ospf6_receive_lsa(struct ospf6_neighbor *from, ismore_recent); return; } +#endif /*0*/ } /* if no database copy or received is more recent */ Best regards, Yasu

2 1

running topotests
by Aleksey Romanov 03 Dec '19

03 Dec '19

Hi, 1. I had built frr from recent sources on ubuntu-18.04. 2. Made sure it starts and ospfd when configured logs events in the specified log and interacts with master agentx. 3. Reset configurations to default and stopped frr. 4. Followed instructions to run topotests http://docs.frrouting.org/projects/dev-guide/en/latest/topotests.html sudo py.test -s -v --tb=no > /var/tmp/topo_test_out 2>&1 It seems that every test is either failed or skipped. Among other things I noticed vtysh errors that seems quite unexpected. 2019-12-02 10:49:14,139 WARNING: vtysh_cmd: failed to convert json output 2019-12-02 10:49:14,642 WARNING: vtysh_cmd: failed to convert json output 2019-12-02 10:49:15,146 WARNING: vtysh_cmd: failed to convert json output 2019-12-02 10:49:15,651 WARNING: vtysh_cmd: failed to convert json output See attached file for more. Thanks, Aleksey

2 3

debian vs ubuntu config
by Aleksey Romanov 02 Dec '19

02 Dec '19

Hi, I am new to frr. I had built recent frr from sources for debian and ubuntu. I noticed that debian one uses config file per daemon vs ubuntu uses one frr.conf file. There are also differences in 'daemons' file content. Is this behavior configurable by 'configure' process? Thanks, Aleksey

3 4

make indent
by Aleksey Romanov 27 Nov '19

27 Nov '19

It seem to me that 'make indent' producing default format instead of one specified in .clang-format file. Am I getting it right? Thanks, Aleksey

2 1

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

22 Nov '19

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 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 3 of 3 defect(s) ** CID 1487027: Uninitialized variables (UNINIT) /zebra/zebra_mlag_private.c: 192 in zebra_mlag_connect() ________________________________________________________________________________________________________ *** CID 1487027: Uninitialized variables (UNINIT) /zebra/zebra_mlag_private.c: 192 in zebra_mlag_connect() 186 return 0; 187 } 188 len = sizeof(struct ucred); 189 ucred.pid = getpid(); 190 191 set_nonblocking(mlag_socket); >>> CID 1487027: Uninitialized variables (UNINIT) >>> Using uninitialized value "ucred". Field "ucred.uid" is uninitialized when calling "setsockopt". 192 setsockopt(mlag_socket, SOL_SOCKET, SO_PEERCRED, &ucred, len); 193 194 if (IS_ZEBRA_DEBUG_MLAG) 195 zlog_debug("%s: Connection with MLAG is established ", 196 __func__); 197 ** CID 1487026: (TAINTED_SCALAR) /zebra/zebra_mlag_private.c: 124 in zebra_mlag_read() /zebra/zebra_mlag_private.c: 124 in zebra_mlag_read() ________________________________________________________________________________________________________ *** CID 1487026: (TAINTED_SCALAR) /zebra/zebra_mlag_private.c: 145 in zebra_mlag_read() 139 } 140 } 141 142 if (IS_ZEBRA_DEBUG_MLAG) { 143 zlog_debug("Received a MLAG Message from socket: %d, len:%u ", 144 mlag_socket, tot_len); >>> CID 1487026: (TAINTED_SCALAR) >>> Passing tainted variable "tot_len" to a tainted sink. 145 zlog_hexdump(mlag_rd_buffer, tot_len); 146 } 147 148 tot_len -= ZEBRA_MLAG_LEN_SIZE; 149 150 /* Process the packet */ /zebra/zebra_mlag_private.c: 124 in zebra_mlag_read() 118 /* This will be the actual length of the packet */ 119 tot_len = h_msglen + ZEBRA_MLAG_LEN_SIZE; 120 121 if (curr_len < tot_len) { 122 ssize_t data_len; 123 >>> CID 1487026: (TAINTED_SCALAR) >>> Passing tainted variable "tot_len - curr_len" to a tainted sink. 124 data_len = read(mlag_socket, mlag_rd_buffer + curr_len, 125 tot_len - curr_len); 126 if (data_len == 0 || data_len == -1) { 127 if (IS_ZEBRA_DEBUG_MLAG) 128 zlog_debug("MLAG connection closed socket : %d", 129 mlag_socket); /zebra/zebra_mlag_private.c: 145 in zebra_mlag_read() 139 } 140 } 141 142 if (IS_ZEBRA_DEBUG_MLAG) { 143 zlog_debug("Received a MLAG Message from socket: %d, len:%u ", 144 mlag_socket, tot_len); >>> CID 1487026: (TAINTED_SCALAR) >>> Passing tainted variable "tot_len" to a tainted sink. 145 zlog_hexdump(mlag_rd_buffer, tot_len); 146 } 147 148 tot_len -= ZEBRA_MLAG_LEN_SIZE; 149 150 /* Process the packet */ /zebra/zebra_mlag_private.c: 124 in zebra_mlag_read() 118 /* This will be the actual length of the packet */ 119 tot_len = h_msglen + ZEBRA_MLAG_LEN_SIZE; 120 121 if (curr_len < tot_len) { 122 ssize_t data_len; 123 >>> CID 1487026: (TAINTED_SCALAR) >>> Passing tainted variable "tot_len - curr_len" to a tainted sink. 124 data_len = read(mlag_socket, mlag_rd_buffer + curr_len, 125 tot_len - curr_len); 126 if (data_len == 0 || data_len == -1) { 127 if (IS_ZEBRA_DEBUG_MLAG) 128 zlog_debug("MLAG connection closed socket : %d", 129 mlag_socket); ** CID 1487023: Error handling issues (CHECKED_RETURN) /zebra/zebra_mlag_private.c: 192 in zebra_mlag_connect() ________________________________________________________________________________________________________ *** CID 1487023: Error handling issues (CHECKED_RETURN) /zebra/zebra_mlag_private.c: 192 in zebra_mlag_connect() 186 return 0; 187 } 188 len = sizeof(struct ucred); 189 ucred.pid = getpid(); 190 191 set_nonblocking(mlag_socket); >>> CID 1487023: Error handling issues (CHECKED_RETURN) >>> Calling "setsockopt(mlag_socket, 1, 17, &ucred, len)" without checking return value. This library function may fail and return an error code. 192 setsockopt(mlag_socket, SOL_SOCKET, SO_PEERCRED, &ucred, len); 193 194 if (IS_ZEBRA_DEBUG_MLAG) 195 zlog_debug("%s: Connection with MLAG is established ", 196 __func__); 197 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

FRR 7.2 Deb Packages are Now Available
by Jafar Al-Gharaibeh 21 Nov '19

21 Nov '19

Dear FRR users, FRR 7.2 stable release deb packages for various platforms are are now available on https://deb.frrouting.org/ Please update and let us know if you have any issues. Thanks, Jafar

2 1

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

21 Nov '19

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. 1 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 1488737: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1488737: Null pointer dereferences (FORWARD_NULL) /ospfd/ospf_nsm.c: 246 in ospf_db_summary_add() 240 241 /* Stay away from any Local Translated Type-7 LSAs */ 242 if (CHECK_FLAG(lsa->flags, OSPF_LSA_LOCAL_XLT)) 243 return 0; 244 245 if (IS_LSA_MAXAGE(lsa)) >>> CID 1488737: Null pointer dereferences (FORWARD_NULL) >>> Passing "nbr" to "ospf_ls_retransmit_add", which dereferences null "nbr->oi". 246 ospf_ls_retransmit_add(nbr, lsa); 247 else 248 ospf_lsdb_add(&nbr->db_sum, lsa); 249 250 return 0; 251 } ** CID 1488736: Incorrect expression (COPY_PASTE_ERROR) /bgpd/bgp_route.c: 3473 in bgp_update() ________________________________________________________________________________________________________ *** CID 1488736: Incorrect expression (COPY_PASTE_ERROR) /bgpd/bgp_route.c: 3473 in bgp_update() 3467 3468 if (pi->extra && pi->extra->bgp_orig) 3469 bgp_nexthop = pi->extra->bgp_orig; 3470 3471 nh_afi = BGP_ATTR_NH_AFI(afi, pi->attr); 3472 >>> CID 1488736: Incorrect expression (COPY_PASTE_ERROR) >>> "bgp" in "bgp_find_or_add_nexthop(bgp, bgp_nexthop, nh_afi, pi, NULL, connected)" looks like a copy-paste error. 3473 if (bgp_find_or_add_nexthop(bgp, bgp_nexthop, nh_afi, 3474 pi, NULL, connected) 3475 || CHECK_FLAG(peer->flags, PEER_FLAG_IS_RFAPI_HD)) 3476 bgp_path_info_set_flag(rn, pi, BGP_PATH_VALID); 3477 else { 3478 if (BGP_DEBUG(nht, NHT)) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Opensource routing @ ietf meetup -- Monday Lunch
by Lou Berger 18 Nov '19

18 Nov '19

Hi, We're continuing with the informal Open Source routing @ ietf meetup. Anyone interested in joining a "bring your own lunch" gathering of folks using/building open source routing code, please drop in to "Bras Basah" on *Monday* during lunch (noon). There is no agenda or slides. Please feel free to bring a topic that you'd like to discuss or just come and listen. Cheers, Lou

3 2