That's part of why it's still just a patch and not in the code. It helps some situations, but not others. That said, you can't really have it both ways. It can either restart the packages or not restart the packages.

The reason it has to restart is typically what you have seen -- FRR needs to restart to latch back onto an interface which has changed (or probably deleted and recreated).

IPsec may fare better because of the changes I made in https://redmine.pfsense.org/issues/9668 which cycles the interface in FRR live without restarting the package. I'm not sure if a similar change for OpenVPN would be viable.

Thank you ... and yes i was laughing at that point ..... feel ashamed 😁

I tried it again, but no success. OVPN routes and static routes are classified as external routes (AS External Link States) into the OSPF database,
so according to this: https://github.com/FRRouting/frr/issues/5290 they are not summarized. Only local LAN addresses have a chance to get summarized.

@0daymaster said in FRR OSPF Ext 1 Default Route With Unexpected Cost.:

default-information originate metric 50 metric-type 1

You can try to change metric-type 1 to metric-type 2 which is the default. It shouldnt change the costs then... as far as i understand that metric-type ...

Got it figured with some basic reading. What i was missing was the policy based routing via firewall rules as described here:

https://docs.netgate.com/pfsense/en/latest/routing/directing-traffic-with-policy-routing.html

Hi Jim,
Thanks for your advice. I checked and our upstream gateway routers are indeed configured to block bogons at that point, so there is no issue with leaving this removed from the WAN interface.

Regards,
Erik

Great! Thank you on both accounts. I disabled the gateway, and we're still operational. :-)
And I didn't realize you could just start typing names in the network box.... From the GUI, it sure looks like it wants a network address.
But now the alias is in use.

Thanks again, and Happy New Year!

@barryboden

You can get all that info from the GUI too

70e24528-fe0c-45b8-af6e-9ddbb82c980d-image.png

cdd7c3a4-5ab5-494f-98dc-8d053a3cebf9-image.png

I'm sure it is. We'll pick up the update eventually. 2.5.0 snapshots are already on 7.1.

It's unlikely that we'll bring FRR 7.x back to 2.4.4-p3 at this point, though.

@gdi2k
We deployed VTI+FRR (2.4.4p3) and that was a disaster. We're thinking about trying OpenVPN+FRR. Do you know if this issue is resolved in the newer (v0.6.3_1) versions of FRR?

That is its own complete router distribution (like pfSense), not something that could be added to pfSense.

Yes, the ring setup is to simplify and to test any possible solutions. The real system has 8 nodes, so 28 tunnels according to your equation - so some connections will go over double hops, especially those which do not see a lot of traffic. Obviously, finding a cost distribution which fixes the issue is not that easy either with 8 nodes.

If it were possible to have ACK traffic be forced to go the same way SYN traffic came, problem solved. Jimp hinted at something in the other thread, with a solution in 2.5.0, but it doesn't seem to work yet. (See here).

Yes, it sounds like the problem others had where the patches on 9668 helped.

Update: If I put the 1:1 NATs on the IPsec interface and the VIPs as IP Aliases on Localhost I can get UDP and ICMP working. No TCP.

@Napsterbater , Good morning, how are you?

This is also my understanding, but my question is "how to configure this" in FRR. I didn't find where to make these settings through the graphical interface. Can you help me?

@jimp Thanks Jim, I'll get started on the process of designing a PR soon.

Not currently. The script where it's called does not have any information which would allow it to make that kind of decision.

The reason for my IPv6 OSPFv3 neighbours not coming up was because I had configured gateway. I was staring right at the answer yet I had overlooked it numerous times...

"If this interface has a gateway, rules on this interface will have reply-to by default. This will interfere with the operation of OSPFv3 on the interface. Add a rule at the top of the ruleset for this interface to pass IPv6 OSPF traffic with Disable reply-to checked in Advanced Options."

Also works well with the gateway removed. (Was using the gateway for failover static routes)

Not strictly the topic of why this thread was opened in the first place but nevertheless thought best to come back and update on my experience.