Date: Mon, 2 Apr 2018 12:51:48 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Hauke Fath <hf@spg.tu-darmstadt.de> Cc: freebsd-net@freebsd.org Subject: Re: Bridging a vlan trunk with a gif tunnel? Message-ID: <5AC1C4F4.90301@grosbein.net> In-Reply-To: <20180401231022184335.e841ceaf@spg.tu-darmstadt.de> References: <20180401164209528151.6f554119@spg.tu-darmstadt.de> <5AC101AC.60906@grosbein.net> <20180401231022184335.e841ceaf@spg.tu-darmstadt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
02.04.2018 4:10, Hauke Fath wrote: >> or switch to newer vxlan(4). > > That wouldn't work with the switches, would it, like vlans? vxlan is not instead of vlans, it is instead of gifs vxlan is designed to pass trunks over routed network forming its own tunnel. Just read its manual page. >>> and I figured just bridging the exclave with the main site would >>> save me routing issues, >> >> And bring in bridging issues that are more severe. > Like what, besides the shortcomings of if_bridge(4)? Loops, broadcast storms spreading too far over long and slower links, applications and kernels not adopting automatically for "not LAN" conditions like they do in case of separate IP networks, extra overhead and timing issues, poor manageability of if_bridge (unable to show/manage its forwarding tables as opposed to newer vxlan) comparing to rich set of methods developed for routing tables etc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5AC1C4F4.90301>