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.

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:

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.

STP Network Sample

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.

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.