On Fri, Sep 20, 2024 at 09:27:03AM +0200, Luca Di Gregorio wrote:
> 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
ah, sorry, i didnt realise you were running VMs and wanted them on the
same network. youll definitely need veb and vport in this situation.
>
>
> 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?
yes, but there are more useful optimisations that are a higher priority
for me to do first. ecmp for vxlan in our stack isnt going to give you a
speed increase today.
>
>
> Il giorno ven 20 set 2024 alle ore 03:32 David Gwynne <da...@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.
> >
