Bridging STP
Bridging STP
The idea behind our installation of STP enabled bridging is to increase stability of the network by preventing network loops and maximising shortest path route for packets within the network infrastructure.
The value-add of installing OpenBSD as redundant bridging nodes, is the added security services to be inserted to the infrastructure while maintaining service stability.
References (man pages):
Requirements
Preferred environment.
* Root STP
* STP enabled managed switches (_switch0_, _switch1_)
* STP enabled bridging nodes (OpenBSD boxes)
Although OpenBSD will bridge STP on non-STP switches, reports indicate that failover may be slightly longer (which may be circumvented by using a pfsync between the OpenBSD bridges.)
ROOT STP Node
First things first, decide which node is going to be your root node. Factors that may be involved in selecting the designated root node may include:
* high availability of the node
* cost of transport to and from this node to other nodes on the STP
* capacity of node to manage STP ROOT duties
Keep this box ON.
Bridging Nodes
Our installations will have two redundant bridges (fwbridge01, fwbridge02) between separate networks LAN A, and LAN B. LAN A is internally using switch01, while LAN B is internally using switch02. We want to redundantly bridge the two networks together.
Each box will be using network cards em0, and em1. Each box will wire em0 to fwbridge01, and em1 to fwbridge02.
Enable bridging on the OpenBSD box
Common configuration for both fwbridge0 and fwbridge1 boxes
# file: /etc/hostname.em0
up description "Link to Switch 1"
# file: /etc/hostname.em1
up description "Link to Switch 2"
# file: /etc/bridgename.bridge0
add em0
add em1
stp em0
stp em1
up
Unless you really know what you’re doing, just let OpenBSD use its sane default settings.
brconfig(8) priority num Set the spanning priority of this bridge to num. Defaults to 32768, minimum of 0, maximum of 61440.
For example, after setting the root STP switch0 to priority 10, then we can use priority 1000 for fwbridge0 and priority 2000 for fwbridge1.
Test
A more robust automated testing sequence would be helpful, but in the sad event that one doesn’t exist.
A visible test would be to run a continuous feed between the two networks, while visually inspecting the bridge behaviour.
client-on-B\> cat /dev/zero | nc client-on-A 2022
client-on-A\> sudo nc -l 2022 client-on-A\>sudo tcpdump -nettv -i eth0 port 2022
An audible test would be to stream an audio stream from one network while listening to it using and audio-player on the second network.
Gotchas
Random thoughts on what grabbed me while I was playing around with the STP configuraiton.
* STP Root. You really want the stp root to be something that is almost
always _ON_ and available.
* When the STP root goes offline, it can take more than a minute for
STP elections to finalise on the next root node.
* Bridge ID. Online documentation reference bridge id. In practise the
Bridge ID is a concatenation of the node _priority_ and ethernet address.
Make sure you take a look at the _priority_ of your bridge as you can do
little about the ethernet address.
* Linksys SRW2024P has a weird requirement for priority to be in
increments of 4096
Access to the Box
Access to the box is through a NIC connected to a live switch. For the redundancy of our above diagram each bridge connects to a different switch and grabs an IP through DHCP (we can manually configure DHCP and DNS to give a unique IP / DNS configuration.)
The above diagram design links switch1 with fwbridge1, switch2 with fwbridge2.
Firewall State
We are using pfsync to ensure firewall state is kept, for faster failover.