- frog - lists.frrouting.org

Slack channel invite
by Ivanov Petar 04 Mar '19

04 Mar '19

Hi, I am a student at ETH Zurich doing some work in Network verification and recently found FRRouting, which I think is a great project. Could I please get an invite to the Slack channel? Email: ivanovpe(a)student.ethz.ch Best Regards, Petar Ivanov

1 0

Getting an error while installing FRR
by muhammed ibrahim 02 Mar '19

02 Mar '19

Hello, I need help with this error helpers/python/frrtest.py:200: TestRefMismatch ----------------------------------------------------------- Captured stderr call ----------------------------------------------------------- 2019/03/01 18:22:41 warnings: NONE: libyang: Failed to open libyang user types plugins directory "/usr/lib/frr/frr/libyang_plugins" (Not a directory). 2019/03/01 18:22:41 errors: NONE: [EC 100663342] yang_init: failed to load frr_user_types.so ----------------------------------------------- generated xml file: /etc/frr/tests/tests.xml ----------------------------------------------- ============================================ 191 failed, 212 passed, 2 skipped in 17.67 seconds ============================================ make: *** [tests/tests.xml] Error 1 I am installing FRR on CENTOS 7 and I installed libyang in /etc/ folder following the instructions http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr -for-centos7.html Not sure what I am doing wrong. incerely, *Muhammed Ibrahim * *muhe31(a)gmail.com* <muhe31(a)gmail.com>

1 0

frr 5.0.2, remove-private-AS and ebgp multihop
by Chris Malton 01 Mar '19

01 Mar '19

Hi all, Weird one here: In my config I have an eBGP Multihop peer, and for some reason, despite the config looking like this: router bgp 65001 neighbor w.x.y.z remote-as nnnnn neighbor w.x.y.z local-as 205804 neighbor w.x.y.z description Upstream - Peering Router - b neighbor w.x.y.z ebgp-multihop 2 neighbor w.x.y.z disable-connected-check neighbor w.x.y.z update-source 81.187.56.158 address-family ipv4 unicast neighbor w.x.y.z remove-private-AS all replace-AS nnnnn is the correct peer ASN. The resulting PCAP in wireshark shows: Path Attribute - AS_PATH: 205804 65001 Flags: 0x50, Transitive, Extended-Length, Well-known, Complete Type Code: AS_PATH (2) Length: 10 AS Path segment: 205804 65001 Segment type: AS_SEQUENCE (2) Segment length (number of ASN): 2 AS4: 205804 AS4: 65001 I am convinced I have done something wrong, as I expected FRR to strip 65001 from the sequence. I'm running frr 5.0.2 on a pfSense (so alas, upgrading to 6 isn't an option at the moment). Any hints what I've done wrong - or is this a known bug? Regards, Chris Malton -- Delta V Technologies Limited 03333 402 402 www.deltav-tech.co.uk Office: 17 Elm Close, Southampton, SO16 7DT Company No. 11006104 Registered in England and Wales

2 2

RFC 4364 configuration example
by Mark Tees 26 Feb '19

26 Feb '19

Hi there, Does anyone have a full MPLS layer 3 VPN example I can test out? Also, which version I should try with. I have tried with FRR 6.0 and can see routes under the VRF like below: ord-b457489f5df65f1f# show bgp vrf vrf2 ipv4 </snip> Network Next Hop Metric LocPrf Weight Path *> 5.5.5.1/32 0.0.0.0 0 32768 ? *> 10.13.12.0/30 0.0.0.0 0 32768 ? However I can't see them in the main vpn table or sent to vpn peers. ord-b457489f5df65f1f# show bgp ipv4 vpn No BGP prefixes displayed, 0 exist Have tried with rt/rd/label config under vrf-policy in 'router bgp xxxx' and also under 'router xxxx vrf vrf2'. redistribute connected redistribute static label vpn export 34712 rd vpn export 10.12.12.1:100 nexthop vpn export 10.12.12.1 rt vpn both 45437:100 I followed the Linux VRF instructions for setting up VRF and that appears ok. Any ideas are welcome. Cheers, Mark

2 2

BABEL Problem on DEBIAN9 FRR
by akÿfffffdn ak 25 Feb '19

25 Feb '19

In the same LAB App I applied BABEL configuration on 4 FRR Node. When I ping to other end of the network. But packets cannot sent to destination.When I delete and then add default route of DEBIAN after that ping become successful.I have to do this frequently. (When ping unsuccessful FRR learn destination address from BABEL after adding the default route ping successful) Why could it be. > I installed FRR on debian 9 on 4 VM. > I have 4 node FRR. > All of them have eigrp configuration. > When I start ping test to 2 hop away FRR Router. > Ping test successful. > But when I shutdown the interface of 2 hop away FRR Router. > Ping packets drop down. > With no shut comand in destination interface. > Ping successful again. > But sometimes eigrpd daemon kill itself on FRR and I can not pinging again. > I have to restart frr service on VM. > But normally it should not work like that. > Why this happen it in this scenario. > I have to deliver packets to destination continuously. Inan

1 0

ospf6d LSA's disappearing, probably stuck MaxAge LSA
by Leon Meßner 25 Feb '19

25 Feb '19

Hi, we recently moved two OSPFv3 routers from quagga 0.99.23 to frr-6.0.2 and are now having two (perhaps unrelated) issues. Issue one is that link-states from one FRR (R1) do only appear very briefly in the databases of other routers. This issue is the pressing one. The other issue is that E1 routes from some routers stay in the ospf6d route table although they have been flushed from the area already. What i observe about issue one: Every LSRefreshTime, when restarting R1 or when "clear ipv6 ospf6 interface INTERFACE" is run, i see R1's LSA's appear very briefly in neighbors databases. I also see routes related to R1 appear in the ospf6d table. After a few seconds these disappear again. Looking at R1's "show ipv6 ospf6 database self-originated" everything is there all the time. What i see in debugging on some other Router (R2): OSPF6: LSUpdate received on bond0.84 OSPF6: src: fe80::3efd:feff:fea2:145a <-R1 OSPF6: dst: ff02::5 OSPF6: OSPFv3 Type:4 Len:108 Router-ID:192.109.82.2 <-R1 OSPF6: Area-ID:0.0.0.0 Cksum:452b Instance-ID:0 OSPF6: Number of LSA: 1 OSPF6: [Router Id:0.0.0.0 Adv:192.109.82.2] OSPF6: Age: 1 SeqNum: 0x800002b4 Cksum: 2e43 Len: 88 OSPF6: ospf6_install_lsa Install LSA: [Router Id:0.0.0.0 Adv:192.109.82.2] age 1 seqnum 800002b4 in LSDB. ... flooding of that LSA ... OSPF6: LSUpdate received on tun0 OSPF6: src: fe80::f101:2 OSPF6: dst: fe80::f101:1 OSPF6: OSPFv3 Type:4 Len:108 Router-ID:192.109.82.24 OSPF6: Area-ID:0.0.0.0 Cksum:7bab Instance-ID:0 OSPF6: Number of LSA: 1 OSPF6: [Router Id:0.0.0.0 Adv:192.109.82.2] OSPF6: Age: 3600 SeqNum: 0x8000040c Cksum: 580c Len: 88 OSPF6: ospf6_install_lsa Install LSA: [Router Id:0.0.0.0 Adv:192.109.82.2] age 268139 3600 seqnum 8000040c in LSDB. OSPF6: LSA disappearing: [Router Id:0.0.0.0 Adv:192.109.82.2] OSPF6: Schedule SPF Calculation for 0.0.0.0 OSPF6: SPF: Scheduled in 0 msec OSPF6: LSA disappearing: [Router Id:0.0.0.0 Adv:192.109.82.2] ... flooding of that LSA ... So there is a MaxAge LSA that has a "higher" SequenceNumber. Probably from a prior boot. Should FRR on R1 raise its SequenceNumber for this LSA to 0x8000040d? Is this likely a problem on R1? I also noticed, that LSAcks for MaxAge LSAs are multicast to either ff02::6 or ff02::5 depending on DR status. Is this correct bahavior, or should they be unicast? I tried to reproduce issue one via FRRouting/topotests, but haven't succeeded until now. Probably because i didn't manage to get a stuck MaxAge LSA in my test instance. Any help would be really appreciated. If more information is needed, i'm happy to supply more logging and help with debugging. Regards, Leon

1 1

Frr init script 'reload' option
by Ron Hermsen 24 Feb '19

24 Feb '19

I'm using FRR 5.0.2 with Tinycorelinux (TCL-10.0) with the frr init script [1]. I have a question regarding the the 'reload' option. The usage message give its use as "reload applies only modifications from the running config to all daemons." not sure what to expect from this option. >From its behaviour I get it is a rollback from running config to startup config without a restart of the daemons. Is my understanding correct? [1] https://raw.githubusercontent.com/FRRouting/frr/frr-5.0.2/tools/frr

2 1

Hardware Requirements
by Steuer Heribert 23 Feb '19

23 Feb '19

Hello, for using FRR with VPP & underlying DPDK, is there any “working hardware” list which goes beyond “use Intel NICs”? I am aware of some white box lists provided by NOS vendors but was not able to find anything about native FRR. I´ve found some posts of cloudscale.ch where they mentioned appliances from a vendor named Lanner (which I never heard of before). Its not about advertising vendors but more kind of a “known-to-work-well” list. In addition it would be nice to chat on Slack, please invite 😊 Thanks, Heri

5 8

Re: [FROG] FRR eigrp daemon kill
by Donald Sharp 23 Feb '19

23 Feb '19

So EIGRP still needs some work to bring it up to a more acceptable level of performance. Having said that, I did fix a few EIGRP crashes on master a couple of weeks back that were directly related to interfaces going up/down. Please try latest master and see if this fixes the issues you are seeing. donald On Fri, Feb 22, 2019 at 3:17 AM akÿfffffdn ak via frog <frog(a)lists.frrouting.org> wrote: > > > > > ---------- Forwarded message ---------- > From: "akÿfffffdn ak" <akinengineer(a)yahoo.com> > To: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 22 Feb 2019 08:16:07 +0000 (UTC) > Subject: FRR eigrp daemon kill > I installed FRR on debian 9 on 4 VM. > I have 4 node FRR. > All of them have eigrp configuration. > When I start ping test to 2 hop away FRR Router. > Ping test successful. > But when I shutdown the interface of 2 hop away FRR Router. > Ping packets drop down. > With no shut comand in destination interface. > Ping successful again. > But sometimes eigrpd daemon kill itself on FRR and I can not pinging again. > I have to restart frr service on VM. > But normally it should not work like that. > Why this happen it in this scenario. > I have to deliver packets to destination continuously. > Please help! > > > > ---------- Forwarded message ---------- > From: "akÿfffffdn ak via frog" <frog(a)lists.frrouting.org> > To: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 22 Feb 2019 00:17:16 -0800 (PST) > Subject: [FROG] FRR eigrp daemon kill > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog

1 0

Using FRR in a product.
by Amod Mishra 22 Feb '19

22 Feb '19

Hello, I am evaluating if i would be able to productize FRR on a clusters of VM. Appreciate if can be provided with some pointers on how to complile FRR libs and make use of these libs. Regards Amod.

3 4