Possible solution for bridging and carp (evolved to bridging and STP)
-
Hi all,
I'm searching a solution to have bridging and master/slave/vips with carp. Can someone "think" with me on this? At the moment I'm missing 2 switches to complete the tests. I can play with vlans to bypass this, but I prefer a theoretical approach first. I promise to write a tutorial when it works :)
The "trick" I thought off is placing a small/cheap switch on the uplink and split it to WAN and OPT2.
Take a good look at the scheme, it shouldSome facts you need to know:
- FW1 is master, FW2 slave
- UPLINK 1 is active, UPLINK2 isn't (the provider takes care of the failover for this)
- all servers on the LAN have a public ip and go to the default gateway (x.x.x.65)
- the BIG SWITCHES are managed, no STP in place right now. The connection between these 2 switches enables a server on BIG SWITCH2 to get to the internet if he has a failure on his first nic (which is connected to BIG SWITCH1)
- the SMALL SWITCHES are unmanaged
- OPT1 does the synchronisation of states, rules…
- WAN and LAN are bridged
- there is a VIP on OPT2 to enable vpn users to connect on a redundant ip
- if UPLINK1 is connected to FW1 directly, a failure on FW1 will activate UPLINK2. But when I place the SMALL SWITCHES between them, it will not work anymore. Therefore I'm connecting the 2 SMALL SWITCHES to allow traffic between FW2 and UPLINK1.
- the VIP can be dropped if causing to much troubles
The questions:
- most important: will the general concept work?
- when FW2 is slave, will BIG SWITCH2 be able to deliver traffic to it (which is not good)? Or will carp take care of this and place the whole FW2 in a slave state? Perhaps I need STP on the BIG SWITCHES to take care of this?
- will rules which allow traffic from OPT2 to LAN and back work? OPT2 is "carped", LAN is bridged. I think that everything sent to LAN will go to WAN, but it can go to OPT2 through the SMALL SWITCHES.
- what will happen if SMALL SWITCH1 goes down? UPLINK2 will be activated, but will the FW's follow? I think that carp on OPT2 will notice it and do a failover. Will STP on BIG SWITCH1 be able to tell the difference between a working bridge and broken bridge (when WAN is down)?
- do I need ip's on WAN? Don't think so.
- am I searching it too far? Can it be done more easily? f.i. 2 managed switches where the SMALL SWITCHES are and play wit STP?
-
Some updates about the previous. Being complicated, it isn't a good solution to start with. Furthermore, it doesn't work out as thought, it seems that the only easy way (always keep things easy :) ) is adding 2 managed switches and creating a root path and a non-root path with STP. I will keep you updated about my progress, it will be finished before januari 2007, have to comply to a deadline.
Another update. As it seems openbsd is able to do STP on a bridged interface itself, thus not requiring managed switches, I searched about this feature for freebsd. I've noted that it's only recently added to the 6.1 release.
From the if_bridge manpage (http://www.freebsd.org/cgi/man.cgi?query=if_bridge&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html)
The if_bridge driver implements the IEEE 802.1D Spanning Tree protocol (STP). Spanning Tree is used to detect and remove loops in a network topology.It should work with pfsense as the fbsd version is the same, I will give it a try before unscrewing 4 managed switches for the weekend.
-
STP is enabled by default on bridged interfaces in pfSense. Have a look at status>interfaces when creating an ethernet loop ;-)
-
Tomorrow already looks promising :)