December 2019 - dev - lists.frrouting.org

Interface mode ospf config not getting deleted opon unconfiguring ospf router
by Naveen K Suvarna 13 Dec '19

13 Dec '19

Hi, In FRR 7.2 OSPF, When ospf router is Unconfigured, interface mode ospf configurations are not getting deleted from running config. Is this behavior designed with any specific reason ? Example: router ospf ospf rouer-id 1.1.1.1 interface Ethernet8 ip ospf area 0 With above config, if I issue command “no router ospf”, interface level ospf configs will not get removed/deleted. Regards Naveen

2 5

Northbound changes discussion - MOM 12/12/2019
by Santosh P K 12 Dec '19

12 Dec '19

Hello All, Below are the points discussed and concluded in today’s meeting. Please correct me If I have missed or captured few conclusions not as we concluded. Discussion: 1. Use of nexthop as leaf ref. * FRR will have to satisfy nexthop being independent object and can be programed independently. * Currently kernel supports this feature and so does FRR with nexthop groups. 2. NULL0 attribute handling * We may not need NULL0 as this special nexthop and we should only provide blackhole interface. * Discussed about different type of interface avalible today in FRR. 3. FRR interface yang v/s IETF yang * Why was FRR interface yang defined while we could have used IETF yang and added augmented more leaf to it. * It was done as a placeholder and we will need to revisit it. 4. VRF usage * Discussed VRF usage for protocols. Should VRF be top of the tree or should be used as leafref. * Discussed different use of VRF being at top of tree and how it may help with configuration. 5. IETF data models usage * Use of IETF data models should not restrict any existing feature that FRR supports today. * We should try to use existing IETF data model with deviations. 6. We will conclude on Staticd review before PIM and IGMP data model. Conclusion: 1. Staticd Yang module will have leafref to nexthop. For this we need to deviate from IETF nexthop and have our own nexthop container defined. 2. Null0 is not required and providing blockhole is enough. 3. VRF should not be restricted on how it should be used with in FRR. It should be used as appropriate for a given protocol. We will meet again on Friday to discuss over the next review items and questions will be published beforehand. Thanks Santosh P K

1 1

Next northbound meeting
by Santosh P K 11 Dec '19

11 Dec '19

Hello All, As discussed in meeting today. We will meet again at 8:00AM PST on Friday 13th Dec 2019. The link for the meeting is as below. https://bluejeans.com/9192742159<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Agenda and topics to be discussed in upcoming meeting. 1. Review and conclude Static yang. 2. VRF usage conclusion. * We may not be able to use IETF network instance as currently libyang does not support mount option. * Making changes to existing IETF yang to allow VRF at top of the tree. 3. Port of all existing IETF Yang which could be used as is or with extensions in to FRR. * Interface yang. * Routing yang. * And so on. 4. Issues we encountered with libyang while using standard yang. * Currently if we are using ipv6-unicast-routing from IETF routing yang then libyang goes in a loop. * Remove few augment statements from rib-ext, as it is pointing to path which is not available in ietf-routing.yang Thanks Santosh P K

1 0

Odds and Ends from tech meeting
by Donald Sharp 10 Dec '19

10 Dec '19

All - 1) Dec 24 and Dec 31 meetings tech meetings are cancelled. 2) I plan to spend a bit of time on the Jan 7 meeting to allow us to have a bit of a retrospective. Please spend a few minutes thinking about what we've done well and what we've done poorly so we can discuss them in the meeting on the 7th. As always there is always room for improvement and we would love to hear the ideas 3) We plan to pull the next stabilization branch of FRR the week of Jan 5 as well. Please take a few minutes and help us get what is in PR now into the code base if you can. 4) One part of today's meeting centered around adding a new requirement for feature work in FRR. Namely all new Feature work *must* have a CI test that can be run the code to ensure it stays working as people make changes to how the underlying system works. Please be prepared to discuss this further and to see if we can come to a conclusion next week. thanks! donald

1 0

Re: [dev] Northbound work reviews and progress
by Santosh P K 10 Dec '19

10 Dec '19

Below is the link for meeting tomorrow. https://bluejeans.com/9192742159 Thanks Santosh P K On 10/12/19, 10:25 PM, "dev on behalf of Santosh P K via dev" <dev-bounces(a)lists.frrouting.org on behalf of dev(a)lists.frrouting.org> wrote: _______________________________________________ dev mailing list dev(a)lists.frrouting.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.frr…

1 0

Re: [dev] Northbound work reviews and progress
by Santosh P K 10 Dec '19

10 Dec '19

Hello All, Gentle reminder. We will have Yang discussion/review tomorrow at 8AM PST. We will be using Donal's link for the same. Agenda of the meeting. 1. Use of IETF yangs. 2. Review Static, PIM and VRF yang. 3. VRF usage for protocols. Thanks Santosh P K On 09/12/19, 11:37 AM, "dev on behalf of Santosh P K via dev" <dev-bounces(a)lists.frrouting.org on behalf of dev(a)lists.frrouting.org> wrote: _______________________________________________ dev mailing list dev(a)lists.frrouting.org https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.frr…

1 0

Re: [dev] Northbound work reviews and progress
by Quentin Young 09 Dec '19

09 Dec '19

I think this is appropriate. Probably an hour will be sufficient. Does the hour before next week's technical meeting work for you? On Fri, Dec 6, 2019 at 3:28 AM Santosh P K via dev <dev(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: Santosh P K <sapk(a)vmware.com> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 6 Dec 2019 08:27:37 +0000 > Subject: Northbound work reviews and progress > > 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 <sharpd(a)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 > > > > ---------- Forwarded message ---------- > From: Santosh P K via dev <dev(a)lists.frrouting.org> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 06 Dec 2019 00:28:16 -0800 (PST) > Subject: [dev] Northbound work reviews and progress > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev >

2 4

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

07 Dec '19

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. 6 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 6 of 6 defect(s) ** CID 1488935: Error handling issues (CHECKED_RETURN) /pimd/pim_vxlan.c: 248 in pim_vxlan_orig_mr_up_del() ________________________________________________________________________________________________________ *** CID 1488935: Error handling issues (CHECKED_RETURN) /pimd/pim_vxlan.c: 248 in pim_vxlan_orig_mr_up_del() 242 __PRETTY_FUNCTION__); 243 } 244 /* if there are other references register the source 245 * for nht 246 */ 247 if (up) >>> CID 1488935: Error handling issues (CHECKED_RETURN) >>> Calling "pim_rpf_update" without checking return value (as is done elsewhere 4 out of 5 times). 248 pim_rpf_update(vxlan_sg->pim, up, NULL, __func__); 249 } 250 } 251 252 static void pim_vxlan_orig_mr_up_iif_update(struct pim_vxlan_sg *vxlan_sg) 253 { ** CID 1488934: Uninitialized variables (UNINIT) /pimd/pim_mroute.c: 989 in pim_mroute_add() ________________________________________________________________________________________________________ *** CID 1488934: Uninitialized variables (UNINIT) /pimd/pim_mroute.c: 989 in pim_mroute_add() 983 * to the correct IIF afterwords. 984 */ 985 if (!c_oil->installed && c_oil->oil.mfcc_origin.s_addr != INADDR_ANY 986 && c_oil->oil.mfcc_parent != 0) { 987 tmp_oil.mfcc_parent = 0; 988 } >>> CID 1488934: Uninitialized variables (UNINIT) >>> Using uninitialized value "tmp_oil". Field "tmp_oil.mfcc_pkt_cnt" is uninitialized when calling "setsockopt". 989 err = setsockopt(pim->mroute_socket, IPPROTO_IP, MRT_ADD_MFC, 990 &tmp_oil, sizeof(tmp_oil)); 991 992 if (!err && !c_oil->installed 993 && c_oil->oil.mfcc_origin.s_addr != INADDR_ANY 994 && c_oil->oil.mfcc_parent != 0) { ** CID 1488933: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_nhg.c: 1415 in nexthop_active() ________________________________________________________________________________________________________ *** CID 1488933: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_nhg.c: 1415 in nexthop_active() 1409 1410 /* Lookup should halt if we've matched against ourselves ('top', 1411 * if specified) - i.e., we cannot have a nexthop NH1 is 1412 * resolved by a route NH1. The exception is if the route is a 1413 * host route. 1414 */ >>> CID 1488933: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "top" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1415 if (top && rn == top) 1416 if (((afi == AFI_IP) && (rn->p.prefixlen != 32)) 1417 || ((afi == AFI_IP6) && (rn->p.prefixlen != 128))) { 1418 if (IS_ZEBRA_DEBUG_RIB_DETAILED) 1419 zlog_debug( 1420 "\t%s: Matched against ourself and prefix length is not max bit length", ** CID 1488932: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1488932: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_evpn_vty.c: 3804 in bgp_evpn_advertise_pip_ip_mac_magic() 3798 update_advertise_vrf_routes(bgp_vrf); 3799 3800 /* Update (svi) type-2 routes */ 3801 for (ALL_LIST_ELEMENTS_RO(bgp_vrf->l2vnis, node, vpn)) { 3802 if (!bgp_evpn_is_svi_macip_enabled(vpn)) 3803 continue; >>> CID 1488932: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "bgp_evpn" to "update_routes_for_vni", which dereferences it. 3804 update_routes_for_vni(bgp_evpn, vpn); 3805 } 3806 } 3807 3808 return CMD_SUCCESS; 3809 } ** CID 1485637: Incorrect expression (SIZEOF_MISMATCH) /qpb/qpb_allocator.h: 57 in qpb_alloc_ptr_array() ________________________________________________________________________________________________________ *** CID 1485637: Incorrect expression (SIZEOF_MISMATCH) /qpb/qpb_allocator.h: 57 in qpb_alloc_ptr_array() 51 * 52 * Allocate space for the specified number of pointers. 53 */ 54 static inline void *qpb_alloc_ptr_array(qpb_allocator_t *allocator, 55 size_t num_ptrs) 56 { >>> CID 1485637: Incorrect expression (SIZEOF_MISMATCH) >>> Passing argument "num_ptrs * 8UL /* sizeof (void *) */" to function "qpb_alloc" which returns a value of type "void *" is suspicious. 57 return qpb_alloc(allocator, num_ptrs * sizeof(void *)); 58 } 59 60 /* 61 * qpb_free 62 */ ** CID 1485635: Incorrect expression (SIZEOF_MISMATCH) /qpb/qpb.h: 124 in qpb__l3_prefix__get() ________________________________________________________________________________________________________ *** CID 1485635: Incorrect expression (SIZEOF_MISMATCH) /qpb/qpb.h: 124 in qpb__l3_prefix__get() 118 uint8_t family, struct prefix *prefix) 119 { 120 121 switch (family) { 122 123 case AF_INET: >>> CID 1485635: Incorrect expression (SIZEOF_MISMATCH) >>> Passing argument "prefix" of type "struct prefix *" and argument "16UL" ("sizeof (struct prefix_ipv4)") to function "memset" is suspicious because a multiple of "sizeof (struct prefix) /*48*/" is expected. 124 memset(prefix, 0, sizeof(struct prefix_ipv4)); 125 break; 126 127 case AF_INET6: 128 memset(prefix, 0, sizeof(struct prefix_ipv6)); 129 break; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

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