UDP Broadcast Storm with Multi-WAN/-LAN + CARP-Failover
-
Hello folks!
We wanted to setup two pfsense nodes as an HA cluster to be prepared for automatic failover for just in case.
Automatic failover should be done by CARP. We are using the latest stable pfsense software.Our Internet connection is set up as follows:
1x static IPv4 fiber uplink (primary uplink)
1x static IPv4 DSL uplink (only used as automatic failover if fiber fails)(Both uplinks use different static IPv4 addresses as they are from different ISPs.)
Two LANs are also connected which serve different subnets. Every subnet should access the Internet via fiber and in case of failure via DSL.
One LAN should use pfsense as a router for reaching the other subnet. This LAN is also served by DHCP from pfsense (DHCP is not really necessary if disabling this service is the solution).
Network devices on the second LAN must only answer to connections from the other subnet (and access the Internet for updates … as already described above) and have static addresses.
Both subnets are NAT'ted.Nothing special I would say ... but it's not working as expected:
After having configured both appliances (built with Supermicro hardware) and having set up all the network connections, an massive uninterrupted UDP broadcast storms starts to happen after plugging in the last Ethernet cable for one of the LANs from the second pfsense initiated by the clients (the ones in the DHCP-subnet). After unplugging one of the pfsenses, the storm stopps immediately. After re-plugging the cable, the storm starts to happen again.
Before we started to use CARP to create our cluster, we tested our uplink failover setup with great success.
Routing worked also fine. But when we started using CARP, every new test fails and only created this massive UDP broadcast storm after a few seconds when having the last LAN cable plugged in.We can't really imagine WHY this happening and HOW to fix this.
But we really need this to work in the next days! -
that's likely:
http://redmine.pfsense.org/issues/2073Though if you have bridging configured, it's likely you're creating a layer 2 loop, HA+bridging isn't a good idea (though it can be done with some hacks).
-
Hi!
Thanks for your reply.
We don't use bridging at all.
But we have tried to block APIPA as mentioned in the bug tracker entry.We had no success with this workaround.
-
Try blocking broadcast traffic as well, for the IP subnet of the LAN subnet. If your LAN is 192.168.1.0/24, add a rule blocking anything to destination 192.168.1.255 on LAN. Don't think that would be it but it's worth a shot