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.
No comments:
Post a Comment