@derelict Thank you!

I had a hunch about that, but as I also saw this "NSSA Totally Stub Area" and I'm like what the ff—is that one or two things? "Not-So-Stubby-Area Totally Stub Area"

You were right one time because about to configure the virtual link, I realized it's at the other side of an ABR. The ABR already would know about it.

I tried setting up the edge router as a type shortcut ABR, but it would form no adjacencies at all. This was only just now though, I haven't had time to explore; inadvertently I enabled DHCP snooping on two switchports to a hypervisor which it's statically multi-homed itself, but the DHCP had migrated there at some point and it was only a matter of time before leases expired and created chaos.

DHCP issues look a lot like multicast issues. 🤔 "OSPF uses multicast…" of course I went with the worst possible choice.

Thanks again — I can sleep now. *sleeping-standing-up-emoji…-or-something*

@lurick I ended up solving this. It looks like at some point firehol pfBlockerNG list was set to block outbound (which applies to the LAN) and then it recently it was updated to block 224.0.0.0/3 or I did something wrong, either way, blocking the entire multicast address range of course would block OSPF neighbors coming up but not OSPFv3 which is using IPv6 multicast.

Final update: on another firewall (also on 23.01), even after going into each neighbor and selecting none for the map, then deleting the map, I get the same error.

I am leaving one map and that seems to keep the error from appearing.

@jcook-atlas I don't know if you've moved on from this to BGP like someone else suggested, but I think your issue may just be a typo. You have 172.18.2. on one side and 178.18.2. on the other.

@mystique_ OSPF is pretty simple to set up.

Enable it and add the interfaces to area 0 and you're done.

One generally sets interfaces that are to be in the OSPF database that are not intended to communicate with other OSPF routers to passive.

That's generally all that HAS to be done to get the IGP working and exchanging routes.

@wblanton FRR does not currently by default do any asic offload of BFD. 50 BFD peers should be ok on modern cpu's I would think though

@jamiegb said in Publish 2 Identical Routes with Different Metric:

te twice but with a different metric so my peer will pre

Its common to adjust either local-pref or as-path prepend attributes. In your case, if you want your peer to use one path for a destination vs another then as-path prepend that route out a few times[using your local-as of course].

@rebelboy1988 I would remove the route-map from the neighbor command so you have no filter applied and then see if you are getting routes. If not then the problem is with the AWS peer.

@ersany If you wish to look at the FRR config file when using the GUI to configure it (not raw config), Go to Status > FRR, Configuration.

As explained above, using the raw configuration disables the GUI config. You have assumed responsibility for the FRR configuration in that case and changes must be made to the raw configuration instead.

@pete35 I grabbed a Plus lab license and changed a CE 2.6.0 install to 22.5 and saw that FRR is unchanged in that version, and the underlying FRR version is still only 7.5.1 at this point in time. Not sure where Netgate's priorities are here, as solid/dependable routing is absolutely key for corporate customers - the ones most likely to pay for the upper tier support contacts. IMHO FRR should be a top priority. FTIW pfSense CE 2.7.0 is still only on FRRR 7.5.1 but granted that is still early beta, but would be a shame if it too was still only 7.5.1 when final and not on a more recent FRR 8.x release.

Summarising the initial 6 things I raised:

1. #1. SPF algorithm firing causes OSPF "redistribute connected" routes to flush.
This was raised in #11835.
I can see that no one has worked on this critical bug. I have tested and this is still an issue (!!)

#2. OSPF protocol filtering (FRR GUI - Global Settings / Route Handling) causes FRR to do strange things (and make OSPF routes invalid / crash FRR etc)
I avoid the "FRR GUI - Global Settings / 'Route Handling'" way of filtering as I found that too unstable so haven't tested it since finding it a problem. I have done filtering elsewhere on my Mikrotik routers instead.

I did raise 11836 for a related issue, and some things improved there, but not sure if this actual issue is fixed or not. Since I don't use the "route handling" features I stopped looking at this issue.

#3. ACL's no-longer have an implicit deny at the end.
I did raise 11841 but I am not looking at this issue as I found that prefix-lists weren't affected so I swapped over from access-lists (ACLs) to prefix lists for my needs (for the redistributing of specific connected routes into OSPF).

#4. OpenVPN links re-establishing can cause "onlink" routes to become inactive
@mdomnis How did you end up going with this? I didn't actually raise a ticket for this but you've been working with pfSense on it I see. I'm not seeing it in pfSense 2.6, but my test lab might be different to when I had it last. Solved?

Issues #5 and #6 - ACCEPTFILTER prefix list entries to be duplicated, and Interface descriptions cumulative
These got fixed - am not seeing these issues in pfSense 2.6. They would have been pretty trivial to sort out.

======
so in short, #5 and #6 are fixed. #4 seems to be fixed (to be confirmed).. #2 and #3 - I have worked around (have avoided those features, thus I'm not affected).

The only thing that that I am affected by right now (and cannot avoid) is issue #1. And it's still really bad. Here's one of my connected routes dropping the moment a backup link comes back up:
O>* 10.24.194.0/24 [110/20] via 10.255.195.2, ovpns2 onlink, weight 1, 01:07:33
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
O>* 10.24.194.0/24 [110/20] via 10.255.195.2, ovpns2 onlink, weight 1, 01:07:35
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
O>* 10.24.194.0/24 [110/20] via 10.255.195.2, ovpns2 onlink, weight 1, 01:07:37
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
O>* 10.24.194.0/24 [110/20] via 10.255.195.2, ovpns2 onlink, weight 1, 01:07:38
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
O>* 10.24.194.0/24 [110/20] via 10.255.195.2, ovpns2 onlink, weight 1, 01:07:40
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
O>* 10.24.194.0/24 [110/20] via 10.255.195.2, ovpns2 onlink, weight 1, 00:00:01
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
O>* 10.24.194.0/24 [110/20] via 10.255.195.2, ovpns2 onlink, weight 1, 00:00:03
pfsense01.it.somecompany.com.au# show ip route | include 10.24.1
O>* 10.24.194.0/24 [110/20] via 10.255.195.2, ovpns2 onlink, weight 1, 00:00:04
pfsense01.it.somecompany.com.au#

10.255.195.2 is the far end of the primary link (p2p). The backup p2p link re-establishing should not cause this route learned over the primary link to flush and relearn. I'm testing pfSense 2.6.0-RELEASE which is built on FreeBSD 12.3-STABLE and has FRR version 7.5.1

update: I cloned my lab and updated pfSense to 2.7.0
2.7.0-DEVELOPMENT (amd64)
built on Mon Oct 17 06:04:34 UTC 2022
FreeBSD 14.0-CURRENT

It is still happening on there. The FRR on 2.7 is still only 7.5.1. Why so old? https://frrouting.org/release/ That's from March 7 2021. FRR is up to 8.3.1 now - 5 releases on from that. Really would like to see what happens in a later version of FRR and hoping the devs can update the FRR package to the latest release soon.