[vxxzy]

You may consider VoIP phones. When a phone boots up on a network segment the DHCP process comes into play. This process is a Layer 2 process. The DHCP packet could contain a boot server field (this is typical) so the VoIP phone can grab configuration. One may want the boot server info "isolated" from other network segments. Utilizing VLANs is one way to do this. Additionally, it is typical that QoS is applied at Layer 2 (something necessary for real-time protocols like VoIP).

[candiddevmike]

I hope you're not trying to run VoIP phones via vxlan over wireguard because you don't want to setup a local DHCP server

[vxxzy]

Over VXLAN yeah... You won't believe how many small-medium companies are moving from on-prem to small managed private clouds. VXLAN allows them to maintain their existing network configuration. "You hope" ha! I suppose by this you mean that the wireguard + vxlan may not be a "mature" combination for something as mission-critical as voice traffic? VXLAN implementations by mature companies (Netgate, Fortinet, etc...) those work. Maybe this wireguard+vxlan would work too.. who knows!?

Edit: I see you changed your comment to consider remote DHCP which causes my comment above to be irrelevant. Oh well. The fact still holds that VXLAN is meant to handle Layer 2 so saying BGP is an alternative is like putting a square peg in a round hole.

[gorkish]

I appreciate that you are trying to give examples of "L2 things" but none of this is really good advice.

For QoS, what do you think double-encapsulating all of the QoS bits inside of two tunnels is going to do for you? If you pay your carrier to respect QoS, you have to actually give them the bits! QoS goes on the OUTSIDE of the onion.

DHCP for VLANs should be handled by snooping for it on the switch and forwarding over L3 (ip helper-address), not by running vxlan over a VPN tunnel. And really it shouldn't ever be done over a potentially unreliable WAN link either; you should have a local agent for DDI at each site.

The only story here is that L2-over-L3 VPN have their very specific niches, and VXLAN+Wireguard is an alternative to L2TP+IPSec that is (IMO) both easier to configure and more reliable when such a thing is needed.

[SoftTalker]

> VXLAN+Wireguard is an alternative to L2TP+IPSec that is (IMO) both easier to configure and more reliable

I'm sorry to ask but which alternative do you find easier and more reliable? I seem to be able to parse that either way, maybe it's just me.

[gorkish]

Sorry for the dangling preposition. "That" refers to VXLAN+Wireguard being easier and more reliable. It has the drawback though of having very high overhead at 130 bytes/packet, and it can be very tricky to use over the public Internet without paying lots of special attention to tuning the MTU of all devices on the bridged segment. I'm glad to know that there are geeks who have not been exposed to the horrors of IPSec, though. And yeah, you should pretty much never do L2VPN. It is perilous in the extreme.

[justsomehnguy]

>maybe it's just me.

Nope, here with the same problem and I don't treat L2TP/IPSec as an easier to configure and reliable.

[iso1631]

Or dhcp relay to a central dhcp server

[chungy]

Maybe he'll write a blog post about it :)

[lormayna]

As someone that has fight for years with L2 in the WAN, I will not advice that at all. Just installa a DHCP server and transport the traffic over L3. You have lot more control both on routing both on QoS

[crest]

I've found that they work just fine. In my case all that was required was setting a DHCP option pointing them at their controller. The QoS to make it work well under load would've been the same for a L2 tunnel.