- dev - lists.frrouting.org

Telco / SP feature planning in FRR -- Please fwd the invite
by Alistair Woodman 20 Jan '20

20 Jan '20

BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 14.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VTIMEZONE TZID:Pacific Standard Time BEGIN:STANDARD DTSTART:16011104T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010311T020000 RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ATTENDEE;CN=olivier.dugeon@orange.com;RSVP=TRUE:mailto:olivier.dugeon@orang e.com ATTENDEE;CN="Lou Berger (lberger(a)labn.net)";RSVP=TRUE:mailto:lberger@labn.n et ATTENDEE;CN="Fredi Raspall (fredi(a)voltanet.io)";RSVP=TRUE:mailto:fredi@volt anet.io ATTENDEE;CN=adrian@voltanet.io;RSVP=TRUE:mailto:adrian@voltanet.io ATTENDEE;CN="Renato Westphal";RSVP=TRUE:mailto:renato@opensourcerouting.org ATTENDEE;CN="Mark Stapp";RSVP=TRUE:mailto:mjs@voltanet.io ATTENDEE;CN="Martin Winter (mwinter(a)netdef.org)";ROLE=OPT-PARTICIPANT;RSVP= TRUE:mailto:mwinter@netdef.org ATTENDEE;CN="David Lamparter";ROLE=OPT-PARTICIPANT;RSVP=TRUE:mailto:david@o pensourcerouting.org ATTENDEE;CN=dev@lists.frrouting.org;ROLE=OPT-PARTICIPANT;RSVP=TRUE:mailto:d ev(a)lists.frrouting.org ATTENDEE;CN="Donald Sharp";ROLE=OPT-PARTICIPANT;RSVP=TRUE:mailto:sharpd@cum ulusnetworks.com CLASS:PUBLIC CREATED:20200120T211304Z DESCRIPTION:All\,\n\nOn behalf of Olivier\, I’m sending out an invite to a call to discuss community activities around Telco / SP features in FRR.\ n\nThe call will be this Wednesday at 17:00 CET / 11:00 ET / 08:00 PT on D onald’s FRR Blue Jeans channel (hopefully)\n\nOrange\, LabN\, Volta and NetDEF have realized that they are each working on areas of Telco / SP fea tures that will probably interact with one another and that we ought to sp end some time coordinating activates so that we avoid the duplication of e ffort we ran into last year regarding Segment Routing.\n\nHere is a minima l list of the features that we feel ought to be discussed. Please send any further topics you feel ought to be added.\n\n1) BGP-LS\n2) TED and TED A PIs\n3) Zebra route and SR policy leaking \n4) SR\n5) TI-LFA\n6) PCEP\n7) PCC\n8) LDP enhancements\n9) YANG models for the above\n10) Carrier Grade\ n11) Performance on large scale network\n\nI’ll send out an agenda tomor row.\n\n/a\n DTEND;TZID="Pacific Standard Time":20200122T090000 DTSTAMP:20200120T211304Z DTSTART;TZID="Pacific Standard Time":20200122T080000 LAST-MODIFIED:20200120T211304Z LOCATION:Blue Jeans Call ORGANIZER;CN="Alistair Woodman":mailto:awoodman@netdef.org PRIORITY:5 SEQUENCE:0 SUMMARY;LANGUAGE=en-us:Telco / SP feature planning in FRR -- Please fwd the invite TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E008000000004067445D8DCFD501000000000000000 0100000006D99B0B9CDFF8D4C90C40D7C5AF624A3 X-ALT-DESC;FMTTYPE=text/html:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//E N">\n<HTML>\n<HEAD>\n<META NAME="Generator" CONTENT="MS Exchange Server ve rsion 14.02.5004.000">\n<TITLE></TITLE>\n</HEAD>\n<BODY>\n\n\nAll\,\n\nOn behalf of Olivier\, I’m sending out an invite to a call to di scuss community activities around Telco / SP features in FRR.\n\nThe call will be this Wednesday at 17:00 CET / 11:00 ET / 08:00 PT on Donald’s FRR Blu e Jeans channel (hopefully)\n\nOrange\, LabN\, Volta and NetDEF have realized t hat they are each working on areas of Telco / SP features that will probab ly interact with one another and that we ought to spend some time coordina ting activates so that we avoid the duplication of effort we ran into last year regarding Segment Routing.\n\nHere is a minimal list of the features that we feel ought to be discussed. Please send any further topics you feel ought to be added.</FO NT>\n\n\n\n 1) BGP-L S\n\n 2) TED and TED APIs\n\n<FO NT FACE="Calibri">3) Zebra route and SR policy leaking \n\n4) SR\n\n<FO NT FACE="Calibri">5) TI-LFA\n\n6) PCEP\n\n7) PCC\n\n<SP AN LANG="en-us">8) LDP enhancements \n\n9) YANG models for the above\n\n10) <FO NT FACE="Calibri">Carrier Grade\n\n11) Performance on large scale network\n\nI ’ll send out an agenda tomorrow.\n\n/a\n\n</BODY>\n</HTML> X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR

1 0

Re: [dev] FRRouting
by Eric Frazier 18 Jan '20

18 Jan '20

sudo snap install frr On Sat, Jan 18, 2020 at 5:16 AM Mike Mazarick < mike.mazarick(a)virtudatacenter.com> wrote: > I am running Ubuntu 18.04 and would like some assistance with FRRouting. > I have been trying all day and the latest effort is attached. > > > > Please assist me. > > > > Mike Mazarick > > > > *From:* Mike Mazarick [mailto:mike.mazarick@virtudatacenter.com] > *Sent:* Monday, December 30, 2019 8:50 PM > *To:* 'dev(a)lists.frrouting.org' > *Subject:* ask on mailing list > > > > I am running Ubuntu 19.04 (disco) and would like to try out frr. > > > > Mike Mazarick > > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev > -- Eric Frazier Chief Operations Officer Tensor Networks, LLC 1289 Reamwood Ave., Ste G Sunnyvale, CA 94089 efrazier(a)tensornetworks.net iPhone 210.995.1328 https://calendly.com/efrazier/30min

2 1

FRRouting
by Mike Mazarick 17 Jan '20

17 Jan '20

I am running Ubuntu 18.04 and would like some assistance with FRRouting. I have been trying all day and the latest effort is attached. Please assist me. Mike Mazarick From: Mike Mazarick [mailto:mike.mazarick@virtudatacenter.com] Sent: Monday, December 30, 2019 8:50 PM To: 'dev(a)lists.frrouting.org' Subject: ask on mailing list I am running Ubuntu 19.04 (disco) and would like to try out frr. Mike Mazarick

1 0

Re: [dev] FRR interface config mode errors seen
by Igor Ryzhov 14 Jan '20

14 Jan '20

Hi Naveen, We faced the same issue when moving interfaces between VRFs. This commit helped - https://github.com/FRRouting/frr/commit/c6982533ba5769a590d089fa1eebf17a7ec… Igor On Tue, Jan 14, 2020 at 5:30 AM Naveen K Suvarna via dev < dev(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: Naveen K Suvarna <naveen.suvarna(a)broadcom.com> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Mon, 13 Jan 2020 10:42:46 +0000 > Subject: FRR interface config mode errors seen > > Hi All, > > In FRR 7.2, I am seeing interface command Failures as below. This > is happening randomly. Once system goes in to this state, failure happens > for all interfaces. > > Is this a known issue ? Is there any fix for this ? > > > > > > *dut4(config)# interface Vlan2* > > % Configuration failed: validation error. > > Please check the logs for more details. > > dut4(config)# interface Ethernet0 > > % Configuration failed: validation error. > > Please check the logs for more details. > > *dut4(config)# interface Ethernet0* > > % Configuration failed: validation error. > > Please check the logs for more details. > > dut4(config)# interface Vlan2 > > % Configuration failed: validation error. > > Please check the logs for more details. > > *dut4(config)# * > > > > Not much logs generated, except below. > > Call to if_lookup_by_name_all_vrf(ifname) Fails leading to below error > > root@dut4:/# tail -f /var/log/frr/myfrr.log > > 2020/01/06 04:21:37 ZEBRA: lib_interface_destroy: only inactive interfaces > can be deleted > > 2020/01/06 04:21:37 ZEBRA: [EC 100663331] nb_callback_configuration: error > processing configuration change: error [validation error] event [validate] > operation [destroy] xpath > [/frr-interface:lib/interface[name='Ethernet32'][vrf='default']] > > 2020/01/06 04:21:37 ZEBRA: [EC 100663337] nb_candidate_commit_prepare: > failed to validate candidate configuration > > 2020/01/06 04:22:24 ZEBRA: lib_interface_destroy: only inactive interfaces > can be deleted > > 2020/01/06 04:22:24 ZEBRA: [EC 100663331] nb_callback_configuration: error > processing configuration change: error [validation error] event [validate] > operation [destroy] xpath > [/frr-interface:lib/interface[name='Ethernet32'][vrf='default']] > > 2020/01/06 04:22:24 ZEBRA: [EC 100663337] nb_candidate_commit_prepare: > failed to validate candidate configuration > > Regards > > Naveen > > > > ---------- Forwarded message ---------- > From: Naveen K Suvarna via dev <dev(a)lists.frrouting.org> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Tue, 14 Jan 2020 05:30:58 -0800 (PST) > Subject: [dev] FRR interface config mode errors seen > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev >

1 0

Reminder: Tomorrow is the last day for submission of abstracts for the Netdev 0x14 conference
by Donald Sharp 14 Jan '20

14 Jan '20

All - Tomorrow is the last day for submission of abstracts for presentation at the Netdev 0x14 conference in March. https://netdevconf.info/0x14/ Please consider attending and getting a chance to interact with some of the other FRR developers. thanks! donald

1 0

FRR interface config mode errors seen
by Naveen K Suvarna 13 Jan '20

13 Jan '20

Hi All, In FRR 7.2, I am seeing interface command Failures as below. This is happening randomly. Once system goes in to this state, failure happens for all interfaces. Is this a known issue ? Is there any fix for this ? dut4(config)# interface Vlan2 % Configuration failed: validation error. Please check the logs for more details. dut4(config)# interface Ethernet0 % Configuration failed: validation error. Please check the logs for more details. dut4(config)# interface Ethernet0 % Configuration failed: validation error. Please check the logs for more details. dut4(config)# interface Vlan2 % Configuration failed: validation error. Please check the logs for more details. dut4(config)# Not much logs generated, except below. Call to if_lookup_by_name_all_vrf(ifname) Fails leading to below error root@dut4:/# tail -f /var/log/frr/myfrr.log 2020/01/06 04:21:37 ZEBRA: lib_interface_destroy: only inactive interfaces can be deleted 2020/01/06 04:21:37 ZEBRA: [EC 100663331] nb_callback_configuration: error processing configuration change: error [validation error] event [validate] operation [destroy] xpath [/frr-interface:lib/interface[name='Ethernet32'][vrf='default']] 2020/01/06 04:21:37 ZEBRA: [EC 100663337] nb_candidate_commit_prepare: failed to validate candidate configuration 2020/01/06 04:22:24 ZEBRA: lib_interface_destroy: only inactive interfaces can be deleted 2020/01/06 04:22:24 ZEBRA: [EC 100663331] nb_callback_configuration: error processing configuration change: error [validation error] event [validate] operation [destroy] xpath [/frr-interface:lib/interface[name='Ethernet32'][vrf='default']] 2020/01/06 04:22:24 ZEBRA: [EC 100663337] nb_candidate_commit_prepare: failed to validate candidate configuration Regards Naveen

1 0

Re: [dev] Northbound regular meeting
by Santosh P K 10 Jan '20

10 Jan '20

Hello All, Today we would like to bring up BGP Yang tree discussion if time permits. We are working on Yang and it should be ready by next week. If we can discuss Yang tree then it will help. I have attached BGP Yang tree. Thanks Santosh P K On 08/01/20, 12:52 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: OSPF neighbour-ship on multi-ip P2P interface
by Santosh P K 09 Jan '20

09 Jan '20

In case of unnumbered I do not think we can work with multiple IP address for OSPF. Simply because fetching right OSPF interface would not be possible when multiple IP address configured. Thanks Santosh P K From: Naveen K Suvarna <naveen.suvarna(a)broadcom.com> Date: Thursday, 9 January 2020 at 6:23 PM To: Santosh P K <sapk(a)vmware.com>, "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> Subject: Re: OSPF neighbour-ship on multi-ip P2P interface Hi Santosh, Thanks a lot for the analysis. My base software does not allow me to configure non /32 ip addresses. Hence I had configured two non /32 ip addresses on same interface and sessions came up for both IP addresses. Interface was considered as regular interface rather than unnumbered interface. In case of session flap with unnumbered interface dual IP, Can we consider it as an expected behaviour or there is room for fix ? Regards Naveen From: Santosh P K <sapk(a)vmware.com> Date: Thursday, 9 January 2020 at 2:39 PM To: Naveen K Suvarna <naveen.suvarna(a)broadcom.com>, "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> Subject: Re: OSPF neighbour-ship on multi-ip P2P interface Naveen, The issue is with unnumbered interface. With this you see flap only when multiple interface address is configured even if prefix is no /32. I tried with /31 and /24 as well but I still see flaps. Not sure how it worked for you. The reason for flap is due to the code below. Sending hello: There are two ospf interface created when you have multiple IP address. Hello will be sent on both with each IP address as the source address in it and rest of the hello content remains the same. Receiving hello: When hello is received then OSPF tries to get the OSPF interface. In case of unnumbered it gets the first ospf interface on that IFP. As in case of unnumbered there is no way we can match on prefix as received source may not have any overlapping IP address with what is configured as source. In function ospf_if_lookup_recv_if which is called by ospf_read to get the ospf interface. if (CHECK_FLAG(oi->connected->flags, ZEBRA_IFA_UNNUMBERED)) match = oi; >>>>> Gets the fist OI and uses that. else if (prefix_match(CONNECTED_PREFIX(oi->connected), (struct prefix *)&addr)) { if ((match == NULL) || (match->address->prefixlen < oi->address->prefixlen)) match = oi; } Flap: Flap is caused due to receiving two hellos from peer and mapping to only single ospf interface. Now take the case where you have two IP address configured on the same interface on either end (R1- 10.10.10.1, 20.20.20.1 and R2- 10.10.10.2, 20.20.20.2). When Router R1 sends hello with source IP in IP header as 10.10.10.1 to R2 then it receives it and matches with first ospf interface let’s assume that is associated with IP 10.10.10.2. When R1 sends hello with source IP in IP header as 20.20.20.1 then R2 will still map to 10.10.10.2 ospf interface as that is first in list. R2 will keep receiving hello from R1 one with neighbour seen and other without it and hence we see OSPF session flapping. Thanks Santosh P K From: Naveen K Suvarna <naveen.suvarna(a)broadcom.com> Date: Wednesday, 8 January 2020 at 8:58 AM To: Santosh P K <sapk(a)vmware.com>, "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> Subject: Re: OSPF neighbour-ship on multi-ip P2P interface Hi Santosh, Yes, I have tried /31 prefix. Sessions do come up in /31 prefix. I am using version 7.2. I have a loopback interface with multiple /32 prefix IPs assigned. This loopback is borrowed by an unnumbered OSPF interface. Two node, directly connected single link ospf topology, as give below. When only one IP is present in the loopback interface, sessions comes up. If more than one Ip is added to the loopback interface, ospf session keep getting flap/reset. Difference I see between /32 and / <1-31> Prefix is that, in hello packet network mask is set to 0 in case of /32. Upon receiving Hello for the other IP which is different from current adjacency ip, adjacency will be re-inited. static int ospf_make_hello(struct ospf_interface *oi, struct stream *s) if (!(CHECK_FLAG(oi->connected->flags, ZEBRA_IFA_UNNUMBERED) && oi->type == OSPF_IFTYPE_POINTOPOINT) && oi->type != OSPF_IFTYPE_VIRTUALLINK) masklen2ip(oi->address->prefixlen, &mask); else memset((char *)&mask, 0, sizeof(struct in_addr)); <<<< DUT1# Sudo config loopback add Loopback0 sudo config interface ip add Loopback0 10.0.0.1/32; sudo config interface ip add Loopback0 11.1.1.1/32; config interface ip unnumbered add Ethernet16 Loopback0 interface Ethernet16 ip ospf network point-to-point ip ospf area 0 router ospf ospf router-id 1.1.1.1 DUT2# Sudo config loopback add Loopback0 sudo config interface ip add Loopback0 10.0.0.2/32; sudo config interface ip add Loopback0 11.1.1.2/32; config interface ip unnumbered add Ethernet16 Loopback0 interface Ethernet16 ip ospf network point-to-point ip ospf area 0 router ospf ospf router-id 2.2.2.2 Regards Naveen From: Santosh P K <sapk(a)vmware.com> Date: Tuesday, 7 January 2020 at 9:54 PM To: Naveen K Suvarna <naveen.suvarna(a)broadcom.com>, "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> Subject: Re: OSPF neighbour-ship on multi-ip P2P interface Naveeen, Did you test with /31 prefix configured on interface and did that work too? Could you also let me know which version of FRR you are using? Thanks Santosh P K From: Naveen K Suvarna <naveen.suvarna(a)broadcom.com> Date: Tuesday, 7 January 2020 at 2:33 PM To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> Subject: OSPF neighbour-ship on multi-ip P2P interface Hi, Does FRR OSPF support neighborship on an P2P interface with Multiple Interface IP addresses? I am using multiple 32bit host ip address on same interface. When I try to establish ospf neighborship on an P2P interface with multiple IP addresses assigned, OSPF neighborship keeps resetting due to, receival of interleaving hello of 1st or 2nd ip-address. Is there any way to avoid this and bring up sessions on the Interface. Above thing works good if the Interface IP addresses are assigned < 32 bit subnet mask (for example, 10.0.0.1/24 instead of 10.0.0.1/32). Regards Naveen

1 0

OSPF neighbour-ship on multi-ip P2P interface
by Naveen K Suvarna 09 Jan '20

09 Jan '20

Hi, Does FRR OSPF support neighborship on an P2P interface with Multiple Interface IP addresses? I am using multiple 32bit host ip address on same interface. When I try to establish ospf neighborship on an P2P interface with multiple IP addresses assigned, OSPF neighborship keeps resetting due to, receival of interleaving hello of 1st or 2nd ip-address. Is there any way to avoid this and bring up sessions on the Interface. Above thing works good if the Interface IP addresses are assigned < 32 bit subnet mask (for example, 10.0.0.1/24 instead of 10.0.0.1/32). Regards Naveen

2 3

Northbound regular meeting
by Santosh P K 07 Jan '20

07 Jan '20

Hello All, We will have recurring meeting for northbound discussion on Friday at 8:00AM PST. We will be using https://bluejeans.com/9192742159<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> . Thanks Santosh P K

1 0