Public bug reported:
In my environment, vlan and vxlan are both exist, and their mtu is 1500 and
1450.
I use vlan network to create a instance-A, and use vxlan network to create a
instance-B, the instance-A and instance-B are in the same compute nodes.
Then I found the mtu of br-int is 1450, this will cause instance-A'iperf
result is 0 in , because instance-A's mtu 1500 is large than 1450.
I did some investigation, found that the ovs bridge's mtu is decided by
the minimum mtu tap device which belong to ovs bridge, for example, the
instance-A's tap mtu is 1500, the instance-B's mtu is 1450, then br-
int's mtu will be set to 1450 automatically.
Seems the neutron doesn't support this scenario which vlan and vxlan
both exist in ovs environment, I'm not sure if it's a bug.
I have a workaround to solve this problem, use command "ovs-vsctl set
int br-int mtu_request=1500", then the br-int will be always 1500, the
instance-A's iperf program worked fine.
** Affects: neutron
Importance: Undecided
Status: New
** Summary changed:
- multiple networks with different mtu cause network connectivity problem
+ multiple type networks with different mtu cause vm connectivity problem
** Description changed:
In my environment, vlan and vxlan are both exist, and their mtu is 1500 and
1450.
- I use vxlan network to create a instance-A, and use vlan network to create a
instance-B, the instance-A and instance-B are in the same compute nodes.
+ I use vlan network to create a instance-A, and use vxlan network to create a
instance-B, the instance-A and instance-B are in the same compute nodes.
Then I found the mtu of br-int is 1450, this will cause instance-A'iperf
result is 0 in , because instance-A's mtu 1500 is large than 1450.
I did some investigation, found that the ovs bridge's mtu is decided by
the minimum mtu tap device which belong to ovs bridge, for example, the
instance-A's tap mtu is 1500, the instance-B's mtu is 1450, then br-
int's mtu will be set to 1450 automatically.
Seems the neutron doesn't support this scenario which vlan and vxlan
both exist, I'm not sure if it's a bug.
I have a workaround to solve this problem, use command "ovs-vsctl set
int br-int mtu_request=1500", then the br-int will be always 1500, the
instance-A's iperf program worked fine.
** Description changed:
In my environment, vlan and vxlan are both exist, and their mtu is 1500 and
1450.
I use vlan network to create a instance-A, and use vxlan network to create a
instance-B, the instance-A and instance-B are in the same compute nodes.
Then I found the mtu of br-int is 1450, this will cause instance-A'iperf
result is 0 in , because instance-A's mtu 1500 is large than 1450.
I did some investigation, found that the ovs bridge's mtu is decided by
the minimum mtu tap device which belong to ovs bridge, for example, the
instance-A's tap mtu is 1500, the instance-B's mtu is 1450, then br-
int's mtu will be set to 1450 automatically.
Seems the neutron doesn't support this scenario which vlan and vxlan
- both exist, I'm not sure if it's a bug.
+ both exist in ovs environment, I'm not sure if it's a bug.
I have a workaround to solve this problem, use command "ovs-vsctl set
int br-int mtu_request=1500", then the br-int will be always 1500, the
instance-A's iperf program worked fine.
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1845603
Title:
multiple type networks with different mtu cause vm connectivity
problem
Status in neutron:
New
Bug description:
In my environment, vlan and vxlan are both exist, and their mtu is 1500 and
1450.
I use vlan network to create a instance-A, and use vxlan network to create a
instance-B, the instance-A and instance-B are in the same compute nodes.
Then I found the mtu of br-int is 1450, this will cause
instance-A'iperf result is 0 in , because instance-A's mtu 1500 is
large than 1450.
I did some investigation, found that the ovs bridge's mtu is decided
by the minimum mtu tap device which belong to ovs bridge, for example,
the instance-A's tap mtu is 1500, the instance-B's mtu is 1450, then
br-int's mtu will be set to 1450 automatically.
Seems the neutron doesn't support this scenario which vlan and vxlan
both exist in ovs environment, I'm not sure if it's a bug.
I have a workaround to solve this problem, use command "ovs-vsctl set
int br-int mtu_request=1500", then the br-int will be always 1500, the
instance-A's iperf program worked fine.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1845603/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
