Date: Sat, 12 Oct 2019 12:24:05 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: BulkMailForRudy <crapsh@monkeybrains.net> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, freebsd-net@freebsd.org Subject: Re: FRR on FreeBSD 12 - problems with OSPFv3 Message-ID: <201910121924.x9CJO6mA096554@gndrsh.dnsmgr.net> In-Reply-To: <e17ad0a5-93bd-611c-4e7b-7de7e23c6d4c@monkeybrains.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Thanks for the questions, good for me to think about it some more.? > Short response: > > ?I don't think it is the FRR config, but the routes received that are > crashing it or ospf6d has some other issue. > > > On 10/11/19 2:12 PM, Rodney W. Grimes wrote: > >> I just upgraded from FreeBSD 11 to 12 and upgrade from quagga to FRR at > >> the same time. I've tried frr6 and frr7 and get the same errors. > >> > >> bgpd and ospfd work fine, but ospf6 doesn't work.? Not sure what I'm > >> going wrong. > >> > >> If I commend out all the interfaces EXCEPT lo0, ospf6d does not crash. > > What if you comment out just lo0? Running OSPF on a loopback > > interface makes no since, your not going to be able to establish > > a DR/BDR pair so OSPF can never really come up on that interface, > > and if it did injecting any route from 127/8 into the OSPF lsdb > > would be very bad! > > > > Though I doubt this is the source of the illegal instuction trap > > it is none the less a configuration issue. > > > Personally, I always put a 172.17.x.x IP on my lo0 and then advertise > that into my network.? I don't make it part of the router config, but I > wanted a 'test device' to boot ospf6d and see it crash.? Also, the docs > on FRR have an lo0. Putting an IP on lo0 and injecting it into OSPF via a redistribution is quiet normal, but actually RUNNING ospf on lo0 is not needed, nor even functional as you have no peer to speak to on that interface and ospf can never form an adjacency. I'll ask the FRR folks about why they are showing ospf on lo0, unless I am missing some this makes no since to me at all. > I do advertise my 172.17.x.x IP on the loobpback:? This is how I verify > OSPF is up -- the IPwill ping from other devices on the network when > OSPF is up.? For IPv6, I put a whole /64 on the lo0. So many IPs in v6.? :) Again, valid, but that does not require the ospf link layer protocol to actually be running on lo0, just a redistribute of a static into ospf as an Type 1 or 2 ASE route. > >> *** LOGS *** > >> > >> 2019/10/10 23:19:31 OSPF6: Scheduling cxl1 for sso > >> 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 0 msec > >> 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 5 usec, Reason: L+ > >> > >> 2019/10/10 23:19:31 OSPF6: Scheduling cxl2 for sso > >> 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 50 msec > >> 2019/10/10 23:19:31 OSPF6: Scheduling cxl3 for sso > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [Down]->[Init] (HelloReceived) > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [Init]->[ExStart] (2-WayReceived) > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [ExStart]->[ExChange] (NegotiationDone) > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [ExChange]->[Loading] (ExchangeDone) > >> 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 109 usec, Reason: R+, R-, L+ > >> > >> 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 83 msec > >> 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 116 usec, Reason: R+, N+, L+ > >> > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [Down]->[Init] (HelloReceived) > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [Init]->[ExStart] (2-WayReceived) > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [ExStart]->[ExChange] (NegotiationDone) > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [ExChange]->[Loading] (ExchangeDone) > >> 2019/10/10 23:19:33 OSPF6: SPF: Scheduled in 0 msec > >> 2019/10/10 23:19:33 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 99 usec, Reason: R+, R- > >> > >> 2019/10/10 23:19:36 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [Loading]->[Full] (LoadingDone) > >> 2019/10/10 23:19:36 OSPF6: SPF: Scheduled in 0 msec > >> 2019/10/10 23:19:31 ZEBRA: client 32 says hello and bids fair to > >> announce only ospf6 routes vrf=0 > >> 2019/10/10 23:19:38 ZEBRA: [EC 4043309117] Client 'ospf6' encountered an > >> error and is shutting down. > >> 2019/10/10 23:19:38 ZEBRA: release_daemon_table_chunks: Released 0 table > >> chunks > >> 2019/10/10 23:19:38 ZEBRA: release_daemon_label_chunks: Released 0 label > >> chunks > >> 2019/10/10 23:19:39 ZEBRA: client 32 disconnected. 100 ospf6 routes > >> removed from the rib > >> > >> *** CRASH *** > > Zebra process crashes after the ospf6 process has encountered some error > > and shut down or are you indicatong that the OSPF6D process has crashed? > OSPF6d crashes, zebra just notes the client #32, the ospf6 process, > saying hello and goodbye. Ok, thanks for clarifing that. > >> If I run on the command line and don't background, it bombs after 7 > >> seconds: > >> # ospf6d > >> Illegal instruction > ... > >> What happens if you remove this lo0 section? > > > Still crashes, usually don't have lo0 in an a > > > > Does ospf6 come up and run if you remove all the > > route-map stuff your trying to do? > > > Sure, I can try a minimal setup.? This config crashes in the same way: > > ! Zebra configuration saved from vty > !?? 2019/10/10 23:58:21 > ! > frr version 7.1 > ! > hostname orange-ospf6 > password sluggo > service advanced-vty > ! > ! > ! > interface cxl1 > ?ipv6 ospf6 cost 1 > ?ipv6 ospf6 network point-to-point > ! > router ospf6 > ?ospf6 router-id 208.69.43.198 > ?interface cxl1 area 0.0.0.0 > ?auto-cost reference-bandwidth 10000 > ! > line vty > ?exec-timeout 0 0 Thanks for that, this defanitly makes it easier for someone to try and duplicate. A few more details, what is the pear on cxl1? You mentioned you think it might be the routes received, can you dump the lsdb from the cxl1 peer? -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201910121924.x9CJO6mA096554>