Contributed by rueda on from the help you step over trolls dept.
David Gwynne (dlg@) has committed to -current another new network driver -
an 802.1Q Two-Port MAC Relay driver,
tpmr(4).
The
main commit message
explains the raison d'être:
CVSROOT: /cvs Module name: src Changes by: dlg@cvs.openbsd.org 2019/07/31 21:05:46 Added files: sys/net : if_tpmr.c Log message: add tpmr(4), a quick and dirty 802.1Q Two-Port MAC Relay implementation a TPMR is a simplified bridge (as supported by bridge(4)). it only supports two ports, and unconditionally forwards frames between them. this is unlike a real bridge which can support an arbitrary number of ports and implements a learning algorithm.
i needed this to tunnel LACP between switches in a couple of data centers separated by an IP network. because bridge(4) implements an actual 802.1Q bridge, it eats packets that are supposed to be sent between bridges, such as spanning tree and LACP. TPMR according to the spec does a lot less of this, and is in fact documented in the spec as being able to support transport of LACP frames. tpmr(4) is actually a lot dumber and current does no filtering (except what you can do with BPF). because the forwarding path in tpmr(4) is so short and simple, it is relatively fast and can be used to isolate and help improve the relative performance of some parts of the system. i also have plans to use this for monitoring traffic without processing it. tpmr(4) implements the trunk(4) ioctls for managing configuration. the ifconfig output for trunk interfaces is a bit shorter and needs a lot less stuff faked to be useful. inside the kernel it appears as an IFT_BRIDGE interface (like bridge(4)). it generally just drops stuff unless it's between the ports it's managing. this has been in production at my work for a few days between some physical nics and etherip(4), and so far it has been really solid. hrvoje popovski has kicked the tyres too, but more from a performance point of view. ok claudio@ deraadt@
(Comments are closed)