ubtkvm2:~$ *netstat -gn* IPv6/IPv4 Group Memberships
Interface RefCnt Group --------------- ------ --------------------- lo 1 224.0.0.1 eth0 1 224.0.0.1 *eth1 1 239.0.7.227* *eth1 1 239.0.7.220* eth1 1 224.0.0.1 eth0.1001 1 224.0.0.1 cloudbr0 1 224.0.0.1 eth1.1003 1 224.0.0.1 cloudbr2 1 224.0.0.1 eth0.1002 1 224.0.0.1 cloudbr1 1 224.0.0.1 cloud0 1 224.0.0.1 vxlan2012 1 224.0.0.1 brvx-2012 1 224.0.0.1 vxlan2019 1 224.0.0.1 brvx-2019 1 224.0.0.1 vnet0 1 224.0.0.1 vnet1 1 224.0.0.1 vnet2 1 224.0.0.1 vnet3 1 224.0.0.1 vnet4 1 224.0.0.1 On Thu, Mar 19, 2020 at 10:50 PM Mr Jazze <mrja...@gmail.com> wrote: > Hi @li jerry, > > There is no physical switch involved as the whole setup is configured in a > nested Hyper-V environment where yes the virtual switch is configured with > MTU 9000 and Trunk VLANs > > Here is overview: > > External vSwitch = CloudStack (MTU 9000) > All ethX interfaces are vlan ports off of the vswitch > > auto eth0.1001 > iface eth0.1001 inet manual > mtu 9000 > > auto eth0.1002 > iface eth0.1002 inet manual > mtu 9000 > > auto eth1.1003 > iface eth1.1003 inet manual > mtu 9000 > > # MANAGEMENT BRIDGE > auto cloudbr0 > iface cloudbr0 inet static > address 192.168.101.11 > netmask 255.255.255.0 > gateway 192.168.101.1 > dns-nameservers 192.168.101.1 > bridge_ports eth0.1001 > bridge_fd 5 > bridge_stp off > bridge_maxwait 1 > > # PUBLIC BRIDGE > auto cloudbr1 > iface cloudbr1 inet manual > bridge_ports eth0.1002 > bridge_fd 5 > bridge_stp off > bridge_maxwait 1 > > # GUEST (PRIVATE) BRIDGE > auto cloudbr2 > iface cloudbr2 inet static > address 192.168.254.11 > netmask 255.255.255.0 > bridge_ports eth1.1003 > bridge_fd 5 > bridge_stp off > bridge_maxwait 1 > > cloudbr0, cloudbr1 and cloudbr2 = were assigned to their appropriate > traffic labels > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode > DEFAULT group default qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode > DEFAULT group default qlen 1000 > link/ether 00:15:5d:0a:0d:7e brd ff:ff:ff:ff:ff:ff > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode > DEFAULT group default qlen 1000 > link/ether 00:15:5d:0a:0d:80 brd ff:ff:ff:ff:ff:ff > 4: eth1.1003@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc > noqueue master cloudbr2 state UP mode DEFAULT group default qlen 1000 > link/ether 00:15:5d:0a:0d:80 brd ff:ff:ff:ff:ff:ff > 5: eth0.1001@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc > noqueue master cloudbr0 state UP mode DEFAULT group default qlen 1000 > link/ether 00:15:5d:0a:0d:7e brd ff:ff:ff:ff:ff:ff > 6: cloudbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue > state UP mode DEFAULT group default qlen 1000 > link/ether 00:15:5d:0a:0d:7e brd ff:ff:ff:ff:ff:ff > 7: cloudbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue > state UP mode DEFAULT group default qlen 1000 > link/ether 00:15:5d:0a:0d:80 brd ff:ff:ff:ff:ff:ff > 8: eth0.1002@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc > noqueue master cloudbr1 state UP mode DEFAULT group default qlen 1000 > link/ether 00:15:5d:0a:0d:7e brd ff:ff:ff:ff:ff:ff > 9: cloudbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue > state UP mode DEFAULT group default qlen 1000 > link/ether 00:15:5d:0a:0d:7e brd ff:ff:ff:ff:ff:ff > 10: cloud0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state > UP mode DEFAULT group default qlen 1000 > link/ether fe:00:a9:fe:44:96 brd ff:ff:ff:ff:ff:ff > 11: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > master cloud0 state UNKNOWN mode DEFAULT group default qlen 1000 > link/ether fe:00:a9:fe:44:96 brd ff:ff:ff:ff:ff:ff > 13: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast > master cloudbr0 state UNKNOWN mode DEFAULT group default qlen 1000 > link/ether fe:00:0e:00:00:1c brd ff:ff:ff:ff:ff:ff > 15: vnet4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast > master cloudbr1 state UNKNOWN mode DEFAULT group default qlen 1000 > link/ether fe:00:87:00:00:84 brd ff:ff:ff:ff:ff:ff > 17: vnet6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > master cloud0 state UNKNOWN mode DEFAULT group default qlen 1000 > link/ether fe:00:a9:fe:62:dc brd ff:ff:ff:ff:ff:ff > 18: vnet7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc htb master > cloudbr1 state UNKNOWN mode DEFAULT group default qlen 1000 > link/ether fe:00:ee:00:00:86 brd ff:ff:ff:ff:ff:ff > 19: vxlan2005: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue > master brvx-2005 state UNKNOWN mode DEFAULT group default qlen 1000 > link/ether 2e:08:0e:8f:da:2b brd ff:ff:ff:ff:ff:ff > 20: brvx-2005: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue > state UP mode DEFAULT group default qlen 1000 > link/ether 2e:08:0e:8f:da:2b brd ff:ff:ff:ff:ff:ff > 21: vnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc htb master > brvx-2005 state UNKNOWN mode DEFAULT group default qlen 1000 > link/ether fe:00:1c:e9:00:06 brd ff:ff:ff:ff:ff:ff > > QUESTION: I understand the requirement of the MTU and as you can see from > above output its being set. But does this same requirement apply to router? > > > On Tue, Mar 17, 2020 at 8:15 PM li jerry <div...@hotmail.com> wrote: > >> Please check your switch port MTU value (9000), the default is 1500 >> >> Vxlan needs to modify the package header. The default MTU value will not >> be able to transfer data. >> >> -----邮件原件----- >> 发件人: Mr Jazze <mrja...@gmail.com> >> 发送时间: 2020年3月18日 6:31 >> 收件人: CloudStack Mailing-List <users@cloudstack.apache.org> >> 主题: VXLAN Connectivity >> >> Hello Again, >> >> I've reconfigured my test environment to use VXLAN instead of OVS which >> went no where. I've of course deployed Advance Mode and put all the pieces >> in place which yielded a somewhat functional cloud. I was able to deploy >> Windows Server 2016 virtual machine. Initially, this VM didn't acquire it's >> DHCP address from VPC router. I noticed VM was running on 2nd host and >> router was running on 1st host, so I migrated VM to the same host as >> router; then it was able to acquire DHCP address and ping 1.1.1.1. Then, >> while trying to troubleshoot why there was no connectivity across hosts the >> router took a dump and I had to destroy it to get another router deployed, >> now VM is unable to get IP address regardless of which host. >> >> Does anyone have any experience with similar issue with VXLAN >> connectivity and/or advice on how to resolve? >> >> -- >> >> ====================== >> >> My Search to Build a Private Cloud! >> > > > -- > > ====================== > > My Search to Build a Private Cloud! > -- ====================== My Search to Build a Private Cloud!
