- frog - lists.frrouting.org

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 24 Feb '19

24 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

FRR eigrp daemon kill
by akÿfffffdn ak 22 Feb '19

22 Feb '19

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!

1 0

Re: [FROG] FRR Installation on Debian9
by Tim Bray 21 Feb '19

21 Feb '19

On 21/02/2019 12:33, akÿfffffdn ak via frog wrote: > I have a problem for instaling FRR on Debian 9 that installed on VM. I > need to install FRR installation steps on Debian9 What are you doing at the moment? https://github.com/FRRouting/frr/releases/download/frr-6.0.2/frr_6.0.2-0.de… download and dpkg -i should work **** Your other option is to install or upgrde to debian 10 (buster), because this includes an frr package. Either re-install. Or add buster lines in /etc/apt/sources.list Then: # apt install frr Info here, https://packages.debian.org/buster/frr I'm not sure using debian 10 would be great for production, no security support. But would be an easy way to test. -- Tim Bray Technology Director, ProVu Communications Ltd, Huddersfield, UK. http://www.provu.co.uk/ Phone: +44 1484 840048 IP Telephones, Drop shipping, pre-configuration, XML orders ***** If it is important, just phone *****

1 0

FRR Installation on Debian9
by akÿfffffdn ak 21 Feb '19

21 Feb '19

I have a problem for instaling FRR on Debian 9 that installed on VM. I need to install FRR installation steps on Debian9.

1 0

interface shutdown question
by Oguzhan Kayhan 18 Feb '19

18 Feb '19

Hello I created two virtual servers with FRR 6.0.2 installed on it.. Both has 3 interfaces 1st interafce is wan interafce 2nd and third interfaces are for test of eigrp.. 1st server has this config interface eth1 ip address 192.168.100.1/24 ! router eigrp 100 network 192.168.100.0/24 network 192.168.200.0/24 redistribute kernel redistribute connected 2nd server has; interface eth1 ip address 192.168.100.2/24 ! interface eth3 ip address 192.168.200.2/24 shutdown ! router eigrp 100 network 192.168.100.0/24 network 192.168.200.0/24 redistribute kernel redistribute connected ! I can see the 192.168.200.0/24 routing on server1 via eigrp.. which is nice.. The problem is, if i shutdown the interface 2 on server2.. nothing happens.. centos1# conf t centos1(config)# interface eth3 centos1(config-if)# shutdown centos1(config-if)# end and on sh run i have; interface eth3 ip address 192.168.200.2/24 shutdown but i can still ping this intrface from server1. and on server2 ip addr output as follows; 6: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 62:9c:df:28:36:4a brd ff:ff:ff:ff:ff:ff inet 192.168.200.2/24 brd 192.168.200.255 scope global eth3 valid_lft forever preferred_lft forever It is really strange. It seems shutdown command does not work.

1 0