On Mon, Sep 16, 2024 at 12:25:35PM -0700, Bryan Vyhmeister wrote:
> I am attempting to build a proof of concept of how to use vxlan(4) on OpenBSD
> in a fully meshed OSPF network with [wireless] links between sites under my
> full control so mtu is not an issue (mtu 1550 for vxlan0 and mtu 1600 or higher for hardware interfaces). The goal is to bridge a group of VLANs between sites A, B, and C.
>
> In my example I have sites A, B, and C. The details aren't very important on
> how the OSPF mesh is setup but it works perfectly and the router-id for OSPF
> is a loopback on each router. What I am having trouble with is the parent
> interface of the vxlan(4) interface. The idea is to have vxlan0 in learning mode which shows up at site A, B, and C and can be bridged to a VLAN-capable switch there.
>
> Let's say site A router's em1 interface is connected to site B router's ix1. Site A router's em2 interface is connected to site C router's bnxt1.
>
> The vxlan0 interface on site A's router is configured with:
> ifconfig vxlan0 parent em1 tunnel 10.10.0.1 239.0.0.1
>
> The vxlan0 interface on site B's router is configured with:
> ifconfig vxlan0 parent ix1 tunnel 10.10.0.2 239.0.0.1
>
> With this configuration, the vxlan0 interface passes traffic perfectly between site A and B but not site C. If I change the parent interface of vxlan0 to the interface pointing to site C, the vxlan(4) link from site A to C works fine but not A to B.
>
> I figured setting the parent of vxlan0 to a loopback interface would work since that would be more typical of other environments but that does not work at all and no link is formed between loopback IP addresses even though they are fully reachable via OSPF.
>
> I then tried creating a pair of pair(4) interface in another rdomain(4) to see if that would work my making the vxlan(4) interface's parent the pair(4) in a different rdomain but it did not work.
>
> I do have net.inet.ip.forwarding=1, net.inet.ip.mforwarding=1, and multicast=YES as well as mrouted turned on for all routers in this setup.
vxlan(4) in learning mode relies on a single multicast capable
underlay network between all sites/points. if you are using separate
interfaces on A to talk to B and C, then this requirement isn't
satisfied.
i dont know enough about multicast routing to know if or how i
should support vxlan in learning mode with routes to multiple
interfaces.
> The other possibility that I have not configured is to have a fully meshed set of routers and then have another router that is separate from each of the three doing the vxlan(4) interface but I have not tried that setup since I believe all of this should be able to be accomplished in one router and I would rather not have to double the number of routers.
>
> I also tried using a WireGuard overlay on top of this network. With wg0 as the parent but that does not seem to work either in vxlan(4) learning mode unless I am missing something.
wireguard as an underlay for vxlan in learning mode doesn't work
because wg isn't multicast capable. the cryptokey routing thing
doesnt support sending a packet destined to a single address (eg,
239.0.0.1) to multiple peers (ie, B and C).
> The other possible solution that I believe I tested and works is to have a vxlan0 between sites A and B and then a vxlan1 between sites A and C and then use veb(4) to bridge vxlan0, vxlan1, and whatever the hardware interface is together. This seems to defeat the purpose of using vxlan(4) to begin with and is not ideal for traffic between sites B and C unless I missed something.
>
> Any ideas?
this last one is pretty good,
veb and vxlan in learning mode actually use the same "etherbridge" code
internally, the main difference between them is what endpoints they
learn and associate with Ethernet addresses. veb associates Ethernet
addresses with the interfaces added as ports to the bridge, while vxlan
associates Ethernet addresses with the IP addresses of peers.
with veb bridging tunnels together, the tunnel interfaces basically act
as proxies for the ip tunnel enpoints in the bridge.
i would just add ethernet tunnels between B and C so they can talk
directly too. you will probably have to add them to the same protected
bridge domain to avoid loops, which is discussed a bit in the mpw
manpage examples a bit.
dlg
No comments:
Post a Comment