Re: vxlan(4) Between Three Sites

It seems it's not working for me.

I got rid off veb3 and vport3

I added the ip address to vxlan3

# ifconfig vxlan3
vxlan3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1450
        lladdr fe:e1:ba:d1:2b:00
        index 6 llprio 3
        encap: vnetid 13133 parent gif0 txprio 0 rxprio outer
        groups: vxlan
        tunnel: inet PublicIP:4789 --> 239.13.13.3 ttl 255 nodf
        Addresses (max cache: 100, timeout: 240):
        inet 192.168.3.11 netmask 0xffffff00 broadcast 192.168.3.255

I modified /etc/vm.conf in this way, setting vxlan3 as "my_switch":

# cat /etc/vm.conf

switch "my_switch" {
        # interface veb3
        interface vxlan3
}

vm "vm11_1" {
        memory 1024M
        disable
        disk /home/vms/vm11_1.qcow2
        interface { switch "my_switch" }
        boot device disk
}

I see:

# vmd -n
vmd: /etc/vm.conf:5: invalid switch interface: vxlan3

You mentioned that you modified VXLAN interface.

I think that it could be optimized even better.

RFC7348 says (Linux does this way):

-  Source Port:  It is recommended that the UDP source port number
         be calculated using a hash of fields from the inner packet --
         one example being a hash of the inner Ethernet frame's headers.
         This is to enable a level of entropy for the ECMP/load-
         balancing of the VM-to-VM traffic across the VXLAN overlay.
         When calculating the UDP source port number in this manner, it
         is RECOMMENDED that the value be in the dynamic/private port
         range 49152-65535 [RFC6335].

I see that OpenBSD set the same port as the Destination Port,

that is, 4789 for every outcoming packets.

Do you think it's possible to optimize in this way?

Il giorno ven 20 set 2024 alle ore 03:32 David Gwynne <david@gwynne.id.au> ha scritto:

On Thu, Sep 19, 2024 at 10:05:37PM +0200, Luca Di Gregorio wrote:
> PublicIP1
> -----------
> # cat /etc/hostname.vxlan3
> tunnel PublicIP1:4789 239.13.13.3
> parent gif0
> vnetid 13133
> tunnelttl 255
> mtu 1450
> up
>
> # cat /etc/hostname.gif0
> mtu 1480
> 10.13.11.2 10.13.11.1 netmask 255.255.255.252
> tunnel PublicIP1 PublicIP3
> up
>
> # cat /etc/hostname.vport3
> mtu 1450
> inet 192.168.3.11 0xffffff00
> up
>
> # cat /etc/hostname.veb3
> add vxlan3
> add vport3
> up
>
>
>
> PublicIP2
> ------------
> # cat /etc/hostname.vxlan3
> tunnel PublicIP2:4789 239.13.13.3
> parent gif1
> vnetid 13133
> tunnelttl 255
> mtu 1450
> up
>
> # cat /etc/hostname.gif1
> mtu 1480
> 10.13.12.2 10.13.12.1 netmask 0xfffffffc
> tunnel PublicIP2 PublicIP3
> up
>
> # cat /etc/hostname.vport3
> mtu 1450
> inet 192.168.3.12 0xffffff00
> up
>
> # cat /etc/hostname.veb3
> add vxlan3
> add vport3
> up

a veb with a single port (vxlan in this case) and a single vport
is unecessary. you can move the IP config to the vxlan interface and get
the same functionality without the overhead of having to switch the
packets through the veb to the vport.

historically a vxlan had to be part of a bridge to support dynamic
endpoint learning, but i rewrote vxlan to be able to do that itself.