CARP w/Bridge, Switch Issue? [solved]

jimp

I've recently taken a liking to pfSense and I have used it at several customer sites, and convinced a few friends to start using it as well. I got the idea to expand what used to a single pfSense box in front of a small LAN of private servers into a much larger part of our network.

I now have a CARP failover set of two pfSense boxes, and for design reasons (which could be revisited), each box has 4 NICs:

WAN (fxp) - On VLAN10 - Plugged into Switch #1 (Cisco 2950)
LAN (fxp) - On VLAN30 - Plugged into Switch #2 (Cisco 2924XL)
DMZ (fxp) - On VLAN20 - Plugged into Switch #2, filtered bridge to WAN interface.
sync - Crossover Cable

My problem mainly seems to arise from having the DMZ interface bridged to the WAN.

I am seeing two issues, and I don't think either of them are due to pfSense, but I am hoping someone else here has some insight into the problem. I do not have pfSense setup to use VLANs at all, I'm relying on the switches to keep things segregated. I have read the sticky post on a similar topic, but these issues aren't quite the same.

#1 - Traffic is flowing normally, and failover worked during my tests, but for whatever reason, the switch has decided to keep sending the DMZ traffic to the backup firewall instead of the master. Given that the servers with the heaviest traffic are on the DMZ, it is bearing the brunt of the traffic even though it is supposed to be the backup.

I'm hoping there is a way to configure those ports to give the first one priority in such an instance, but I have not had any successful tests yet tinkering with STP settings. Suggestions would be greatly appreciated.

#2 - My switch logs are filling up with lots of:
Jul 18 14:12:49.325 EDT: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/2 (20), with switch1 FastEthernet0/7 (10).
Jul 18 14:12:49.341 EDT: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/1 (20), with switch1 FastEthernet0/23 (10).

Of course this is true, because the pfSense box is bridging between the two, but it is more of an annoyance than anything. Is there some way to either suppress these spurious messages, or perhaps some traffic that could be blocked in pfSense to prevent this from being detected?

After business hours tonight I can try to completely power off the backup firewall to see if that forces the traffic back to the master, but that wouldn't help with issue #2.

Any ideas? Thoughts? Suggestions?
Thanks!

jimp

As usual, it only takes posting to a forum for me to find a solution a short while later… For one issue anyhow.

I fixed the log messages by disabling cdp on those switch ports (no cdp enable) but I'm still not having any luck with the fact that my switches apparently really like the path to the backup system better.

On the DMZ switch, I lowered the master's STP port priority, shut down the backup's port, and it was running fine. Once I re-enabled the backup's port, the switch started blocking the first port again. For kicks, I tried giving it a higher priority and it did the exact same thing.

jimp

And now I seem to have successfully trained the switch to properly prioritize the ports, I had to change not only the port priority, but the path cost.

For the record, my DMZ port configuration on switch #2 look like this:

interface FastEthernet0/1
 description Firewall - Master - DMZ Port
 switchport access vlan 20
 spanning-tree vlan 20 port-priority 64
 no cdp enable

interface FastEthernet0/2
 description Firewall - Slave - DMZ Port
 switchport access vlan 20
 spanning-tree vlan 20 cost 500
 no cdp enable

Sorry for the noise!

Keep up the good work, everybody.