CARP VIP assignment causes kernel panic
-
Did you tried this way?
-
configure a sync interface
-
enable sync between firewalls
-
check replicaton between boxes
-
create a carp interface with a id that cound not conflict with any vrrp on your network
-
-
What type of NICs do you have on the box? Any unusual interface setup? Haven't heard of a CARP panic in a long time much less one so easily triggered.
-
{
•configure a sync interface
•enable sync between firewalls
•check replicaton between boxes
•create a carp interface with a id that cound not conflict with any vrrp on your network
}Yes, I can vouch for all of this and that it was done in this order as the online tutorial suggests in contrast to the book. I assume that by "check replication between boxes" you are referring to pfsync on the dedicated interfaces. I really thought you had nailed it with the last point because I had an older OpenBSD box configured for CARP acting as a temporary gateway while I set up pfSense, but alas, I shut it down and still got the same result when I clicked Apply Changes on the Firewall: Virtual IP Address: Edit page. There are no other redundancy protocols running anywhere on the network.
The NICs are all genuine Intel Pro/1000 MTs. The only thing unusual about the (eventual) setup is that I have two disjoint LANs. I want firewall A to be the master for LAN1 and slave for LAN2 and firewall B to be master for LAN2 and slave for LAN1. I don't think this is the issue for two reasons: (a) I set this up in OpenBSD/FreeBSD before and it worked, and (b) I haven't gotten that far in the configuration process with pfSense. I have configured the sync interfaces on both hosts and checked for state synchronization (which is working). I have not set up configuration synchronization since both firewalls are on equal footing as far as the master/slave relationship is concerned (and if this is the equivalent of the (no-sync) option in pf, then this is how I set it up before anyway). I have done no CARP configuration on firewall B yet, nor have I configured LAN2 on firewall A. All I have done past the sync stage is attempt to configure firewall A as the master on LAN1, and that's when things go haywire.
-
I did a clean install of 2.0.1 hoping in vain this would fix this issue. I left the default installation alone except I changed the LAN IP to 10.0.0.101/24. I then attempted to set a CARP VIP to 10.0.0.100/24 with all other settings to default and off we go to the races. This is about as basic of an installation as possible, and I'm still getting the same panic. I've also tried this with the pfsync interface enabled with and without the slave being active. It does not seem to matter what I do; the kernel panics. I have a hard time believing it's the NICs; I have the same model in the FreeBSD machines that have worked in this configuration. I stress again that there are no other machines transmitting redundancy protocols on this network. This happens so readily that I am flabbergasted that I'm evidently the only person experiencing this problem.
-
Do your hardware supports pfsense 64bits
Can you try to install it and see if you get same issue?
-
No, these are 32-bit boxes retasked for this purpose.
-
I tried something different hoping to gain some new insight. I booted the firewall with all interfaces unplugged save the private LAN I use for configuration/maintenance. I then configured CARP which did not immediately throw any errors. Then I plugged each interface in individually and, if no panic resulted, rebooted the machine checking for panic on boot before proceeding to the next interface. This worked until I got to the interface on which CARP was configured (no surprise there); as soon as I plugged it in–panic. The switch connected to this interface is also connected to its sister interface on the other firewall and the rest of the LAN. I tried (a) unplugging the other host, (b) unplugging the LAN, and (c) unplugging both. The machine panics even when it is the only device connected to the switch. I had hoped this would be an eye-opening experiment, but it seems all I have managed to determine is that when the troublesome interface is activated it spells trouble. Lest anyone suspect it's the NIC, I have tried this with three different cards with the same result. I can handle troubleshooting, but I have run out of ideas. Maybe this experiment will light a bulb in someone else.
-
can you email me a backup of your config? cmb at pfsense dot org
-
Your config works perfectly for me. So it is somehow hardware-specific, though I have no idea how. The couple boxes I tested with both have Intel Pro/1000 NICs which should behave exactly the same as yours.
-
This happens on the other host also, which has different onboard hardware (MB, chipset, etc.) and slightly different NICs (still Pro/1000, but GT, XT, and T). The only similarity, really, is that they're both Pentium IIIs. What is the likelihood I'd have the same issue on two heterogeneous machines?
-
So, I'm eating lunch at Subway pondering this latest news. I'm pretty sure it's not a hardware issue because both machines are affected. Still, the fact that you got it to work with no modification is quite the puzzle. So, I ask myself, how could my installation be different from Chris's? I mean, there are not that many options to choose from during installation. Then it dawns on me. I have been choosing the Developer's Kernel from the onset because these Pentium III systems aren't SMP, the uniprocessor option is gone in 2.0, I don't want to go headless, and I wasn't sure whether the DK was necessary for 2.1 (which I plan to install next). I just reinstalled using the SMP option and now CARP is working perfectly. I'm not sure this is what is supposed to happen, but the problem (on my end, at least) is solved. If you hadn't asked for the config file and tested it, I have no idea how long it may have taken to figure this out. Thank you!
-
All kernels (even Dev) are SMP on 2.0.
There is no longer any benefit to loading a uniprocessor kernel (Mentioned a little here but also in more detail by me around the forum).
I've had some issues with the dev kernel in certain setups as well but it does a lot more strict locking checking and reporting, which is what you appear to have hit here.
We have enough debug info in the stock kernel these days that the full dev kernel isn't quite as necessary on its own, but still useful in rare cases.
