Middlebox redundancy

[mjsteckel]

We have multiple routers and switches at our data center data center for redundancy.

As it stands now, the middlebox uses one interface for the uplink and the other for the downlink. This means the middle box can not have redundant up & down links.

Ideally I would like to see the middle box support multiple up and down links. In effect, have the middlebox connect to separate switches for both the upload and download links.

Middlebox Upload link-A => Switch A Middlebox Upload link-B => Switch B Middlebox Download link-A => Switch A Middlebox Download link-B => Switch B

For extra bonus points, it would be nice if the upload and download links could operate over bonded ports. Yeah, lots of ports on the middle box, but lots of redundancy. :-)

[dtaht]

Our configuration at equinix is setup like this, also, but we broke that in order to have 25Gbits for other traffic. I have thought about asking them for a dedicated box so that we could do 100Gbit going forward, or for an additional network card or cards. I worry about the new bridge. Another approach might be to slam a few network cards into one cheap box somewhere and test with that. Even at a gbit, we'd find problems there, if they existed.

[thebracket]

Right now, this would be troublesome because the Python side expects one interface (or one VLAN) in each direction. The new bifrost bridge theoretically supports multiple interface and complex VLAN mappings, but it's largely untested.

So on the Bifrost side, you could have:

[bridge]
use_xdp_bridge = true
interface_mapping = [
        { name = "eth1", redirect_to = "eth2", scan_vlans = false },
        { name = "eth2", redirect_to = "eth1", scan_vlans = false },
        { name = "eth3", redirect_to = "eth4", scan_vlans = false },
        { name = "eth4", redirect_to = "eth3", scan_vlans = false }
]
vlan_mapping = [
]

That part should work, but there currently won't be any traffic shaping on the second bridge. That would require that LibreQoS.py be extended to treat the interfaces as an array (e.g. interfaceA = [ "eth1", "eth3" ]) rather than a single value, and the same queues be rebuilt on both eth1 and eth4 (and their reciprocal).

You should at least get a really fast bypass on the second set of interfaces right now... You could hack it by making a second libreqos folder, with ispConfig.py setup for the other interfaces and run that immediately after the other one. It would be messy, but it should work.