Bug 1348116 - MTU setup on qr router legs sometimes does not take effect
Summary: MTU setup on qr router legs sometimes does not take effect
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: async
: 8.0 (Liberty)
Assignee: Ihar Hrachyshka
QA Contact: Eran Kuris
URL:
Whiteboard:
: 1359951 (view as bug list)
Depends On: 1348115 1365622
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-20 08:19 UTC by Ihar Hrachyshka
Modified: 2017-01-11 19:26 UTC (History)
7 users (show)

Fixed In Version: openstack-neutron-7.2.0-1.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1348115
Environment:
Last Closed: 2017-01-11 19:26:12 UTC
Target Upstream Version:


Attachments (Terms of Use)

Comment 2 Ihar Hrachyshka 2016-06-20 08:20:30 UTC
Note: this bug assumes network_device_mtu is not set on Nova or Neutron.

Comment 4 Ihar Hrachyshka 2016-12-21 13:53:13 UTC
Was shipped as part of 7.2.0 rebase.

Comment 5 Ihar Hrachyshka 2016-12-21 14:14:04 UTC
*** Bug 1359951 has been marked as a duplicate of this bug. ***

Comment 6 Jon Schlueter 2017-01-03 13:15:34 UTC
According to our records, this should be resolved by openstack-neutron-7.2.0-5.el7ost.  This build is available now.

Comment 7 Eran Kuris 2017-01-08 09:00:33 UTC
According to the with those steps to reproduce the issue happens sometimes 
I would like to know what is the exactly steps that reproduce the issue so I can verify it ?

Comment 8 Eran Kuris 2017-01-08 12:10:15 UTC
During my check its looks like there is no mtu calculation according to tenant network type . 
on rhos-8 
[root@controller-0 ~]# rpm -qa |grep openstack-neutron
openstack-neutron-bigswitch-agent-2015.3.8-1.el7ost.noarch
openstack-neutron-metering-agent-7.2.0-5.el7ost.noarch
openstack-neutron-common-7.2.0-5.el7ost.noarch
openstack-neutron-bigswitch-lldp-2015.3.8-1.el7ost.noarch
openstack-neutron-ml2-7.2.0-5.el7ost.noarch
openstack-neutron-7.2.0-5.el7ost.noarch
openstack-neutron-openvswitch-7.2.0-5.el7ost.noarch
openstack-neutron-lbaas-7.2.0-1.el7ost.noarch

[root@controller-0 ~]# ip net exec qrouter-5d600579-be8e-436b-97c3-9372ccc954b0 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 65  bytes 7280 (7.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 65  bytes 7280 (7.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

qg-7eede1bc-89: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1400
        inet 10.0.0.210  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::f816:3eff:feb2:dc6d  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:b2:dc:6d  txqueuelen 1000  (Ethernet)
        RX packets 257543  bytes 1200729492 (1.1 GiB)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 135410  bytes 2296647603 (2.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

qr-472db56c-ea: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1400
        inet 10.0.5.1  netmask 255.255.255.0  broadcast 10.0.5.255
        inet6 fe80::f816:3eff:fee9:304c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e9:30:4c  txqueuelen 1000  (Ethernet)
        RX packets 137621  bytes 2295022550 (2.1 GiB)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 258581  bytes 1204438626 (1.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

qr-4819ee8d-3a: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1400
        inet6 fe80::f816:3eff:fe62:7f7c  prefixlen 64  scopeid 0x20<link>
        inet6 2005::1  prefixlen 64  scopeid 0x0<global>
        ether fa:16:3e:62:7f:7c  txqueuelen 1000  (Ethernet)
        RX packets 198  bytes 14630 (14.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1376  bytes 151040 (147.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

qr-778968e8-7e: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1400
        inet 10.0.8.1  netmask 255.255.255.0  broadcast 10.0.8.255
        inet6 fe80::f816:3eff:fe93:3821  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:93:38:21  txqueuelen 1000  (Ethernet)
        RX packets 2  bytes 192 (192.0 B)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 10  bytes 864 (864.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@controller-0 ~]# grep mtu /etc/neutron/*
/etc/neutron/neutron.conf:advertise_mtu = True
/etc/neutron/neutron.conf:network_device_mtu=1400
/etc/neutron/plugin.ini:path_mtu = 0

Comment 9 Ihar Hrachyshka 2017-01-10 20:01:08 UTC
When network_device_mtu is used, then new MTU calculation mechanism is not utilized, and hence all devices indeed use network_device_mtu values.

To validate the bug, you should opt in the new MTU mechanism by unsetting network_device_mtu, and instead setting segment_mtu in plugin.ini (this is the same option as global_physnet_mtu in OSP9+).

After you set segment_mtu, unset network_device_mtu, and restart neutron-server, you should see new router legs getting MTUs as calculated by the new mechanism.

That being said, one may suggest that the new mechanism should be used in all installations. If you think that's worth pursuing for OSP8 that is released a while ago, then please report a bug against tripleo.

Comment 10 Eran Kuris 2017-01-11 14:54:10 UTC
validate according to Ihar steps to reproduce in comment 9 
OSP8 
[root@controller-0 ~]# rpm -qa |grep openstack-neutron-
openstack-neutron-bigswitch-agent-2015.3.8-1.el7ost.noarch
openstack-neutron-metering-agent-7.2.0-5.el7ost.noarch
openstack-neutron-common-7.2.0-5.el7ost.noarch
openstack-neutron-bigswitch-lldp-2015.3.8-1.el7ost.noarch
openstack-neutron-ml2-7.2.0-5.el7ost.noarch
openstack-neutron-7.2.0-5.el7ost.noarch
openstack-neutron-openvswitch-7.2.0-5.el7ost.noarch
openstack-neutron-lbaas-7.2.0-1.el7ost.noarch


Note You need to log in before you can comment on or make changes to this bug.