Route Lost by CARP Change
I have the problem that one route is always lost. I use a HA system as shown below. The route (red) is permanently entered. The gateway is marked as always active. If I now move the CARP address from Firewall1 to Firewall2 then the route is in Firewall2 without problems. But on Firewall1 the route is already lost. When CARP moves back to Firewall1 the route is still gone. As soon as I click on save in the configuration and apply it again, the route works again.
Unfortunately, the transfer network from the provider is not big enough to accommodate all IP addresses in it, so I only have the virtual IP address in it.
Anybody knows this problem? or any solution suggestions
There is a lot of detail missing here, for example:
- What version of pfSense?
- How is the VIP configured?
- How is the route configured?
- How are you testing failover?
Oh Sorry so much info missing:
Version on Both: 2.4.3-RELEASE (amd64) built on Mon Mar 26 18:02:04 CDT 2018
- Save route = everything is fine
- Enter CARP maintenance mode on Firewall1 = route lost on FW1 but workung on FW2
- Disable maintenance mode = Route Complete lost
- Save route again on Master = everything is fine again.
And some OT: i found a new problem while test this, when i enter the maintenance on Firewall1 all VIPs go to the backup device but afer a couple of seconds later the initial master leaves the maintenance and become the Master again.
Before anything else, upgrade both nodes to the current release, 2.4.3-p1, and then run the tests again.
Ok, but that will take a while. Due to a high performance environment I have to register and approve a change. Maybe any other tips?
No other tips. Issue reports against outdated versions are not valid.
I'm not sure if you're the same person, but I think your issue might have been reported as a bug around 3 months ago, though it hasn't been assigned or triaged by anyone. It would be worth adding your issue if it is indeed the same problem:
The bug report specifies that it occurs in an environment where they are using a non-local gateway, which doesn't seem to apply to you. I'm trying to determine if it will affect me after an upgrade to 2.4.3-p1. We're not using a non-local gateway either.
Hello, Thanks for your reply and the Reminder :)
I'm not that person, but i found a solution that worked for me.
- Upgrade version
- The provider was able to change the /30 Network to a /28 Network so i can use Carp and VIP in one Subnet. After this we tested it with no further problems
Cool, that's enough to tell me it won't affect me. Thanks man.
The issue described in this bug report is still present in 2.4.3-p1.
I have a similar setup and i can reproduce excactly the same problem.
but it's not clear whether this issue is specific to using a non-local gateway or not.
In my case i use a non-local gateway as well.
If that issue occures, i have to go to system-routing edit my default gateway, save the setting without any modification and the connection comes up. Sometimes i have to go to interfaces-wan and save the interface again without modifications to bring the routing up and running again.
The real question is: Does it still happen on 2.4.4?
I can try. Let you know the result.
I used the integrated auto-update functionality to bring my first box from 2.4.3-p1 to 2.4.4.a.20180803.0952.
After the update i got this crash-log. 0_1533339152726_PHP_errors.zip.
I was able to delete the log and did not see any issues with the installation (after a quick look).
I upgraded the second box from the same version to the same dev-version.
After the second box did go down for a reboot, the CARP interfaces where failing over and my internet connection (inbound and outboud) was lost again - until i saved my default gateway again without any modifications to the settings, then the connection came back.
After i logged in to the updated second box, i got a crash-log as well 0_1533339758577_PHP_errors (1).zip .
After a few tests: Yes, the issue is still present also with 2.4.4.a.20180803.0952.
... and i can confirm this issue is specific to using a non-local gateway.
Did somebody see this already and can say something about it?
well we solved the problem by this way , first create a script to check if the default route is still exists or no then if does not just add it :)
I add a cronjob for this though
if ! [ $(route -n show 0.0.0.0 | grep gateway | cut -d ":" -f 2 | cut -d " " -f 2) == "10.10.10.1" ]; then route add -net 0.0.0.0/0 10.10.10.1 ; fi