Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1137057

Summary: Custom MTU is not set for bridge and tap devices on compute node while using linuxbridge-agent
Product: Red Hat OpenStack Reporter: YONGKI, KIM <ykim>
Component: openstack-neutronAssignee: Miguel Angel Ajo <majopela>
Status: CLOSED ERRATA QA Contact: Toni Freger <tfreger>
Severity: high Docs Contact:
Priority: high    
Version: 7.0 (Kilo)CC: amuller, chrisw, ihrachys, jschwarz, majopela, nyechiel, ohochman, sputhenp, tfreger, tiswanso, yeylon, ykim
Target Milestone: z2Keywords: Triaged, ZStream
Target Release: 7.0 (Kilo)Flags: majopela: needinfo-
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: openstack-neutron-2015.1.1-5.el7ost Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-08 12:07:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1212944    
Attachments:
Description Flags
patched version none

Description YONGKI, KIM 2014-09-04 01:13:52 UTC
Created attachment 934239 [details]
patched version

Description of problem:
  - bridge and tap device's MTU value can't be changed, specially in compute node
  - so I made a patch for it
  *condition) 
    - neutron service and compute service are on the same node
    - they are using linuxbridge-agent(Not OVS)
Version-Release number of selected component (if applicable):
  - OST5 on RHEL5

How reproducible:
  - see below
Steps to Reproduce:
1. change physical devices'mtu and add "network_device_mtu" in /etc/neutron/neutron.conf on a network node and all compute nodes
2. neutron service restart(openstack-service restart) on a network node and all compute nodes
4. create new instance
3. check bridge device's mtu and tap devices mtp 

Actual results:
  - maybe mtu adjustment will work on network node but not on compute node.

Expected results:
  - detect the physical device' MTU and modify the MTU of bridge and tap device with following the same MTU value. 

Additional info:
I made some changes in linuxbridge_neutron_agent.py
this file located in /usr/lib/python2.6/site-packages/neutron/plugins/linuxbridge/agent
you can check the diff searching "ykim"
- modified line no.: 87-103 , 402-409
I hope that anybody check and review it.

Comment 14 Ihar Hrachyshka 2014-10-21 14:00:18 UTC
There is no big reason to modify MTU for bridges: they use the lowest common MTU among all the devices plugged into them.

What we may be interested is setting MTU for

- tunnels on all nodes;
- interfaces inside instances;
- veth pairs inside network service namespaces (routers, dhcp, ...).

Tunnels should be covered by setting network_device_mtu in neutron.conf. Same for veth pairs for services.

The only thing that is left is MTU for instance interfaces. Instead of setting MTU for tap devices, we may pass the desired MTU via special DHCP option.

On DHCP agent node:

echo dnsmasq_config_file=/etc/neutron/dnsmasq-neutron.conf >> /etc/neutron/dhcp_agent.ini
echo dhcp-option-force=26,<MTU> >> /etc/neutron/dnsmasq-neutron.conf

Once done, new instances that acquire info via DHCP should set their interfaces from inside themselves as per the option value.

Note: This approach won't work for IPv6, and instances that are deployed without DHCP client.

There is also a spec to accommodate additional tunnelling needs in u/s: https://review.openstack.org/#/c/105989/

Comment 15 Ihar Hrachyshka 2014-10-21 15:11:50 UTC
YONGKI, to move forward, we need to understand what's the rationale of the customer to change MTU as per the patch. Do they use VLAN or VXLAN with Linux Bridge? Do they use DHCP? Why not passing MTU inside instances via a DHCP option?

Comment 16 YONGKI, KIM 2014-10-22 00:32:06 UTC
Ihar, my customers are testing NFV on open stack and they must use their own MTU value.
And they are using VLAN and their concern is about bridge's MTU.
as your comment if bridge device uses the lowest value, then there is no need to change the code. but when I check the bridge's MTU with 'ifconfig', the value was default(1500) even though I changed the physical device's MTU. so I though that the difference between physical device' MTU and bridge device' MTU could cause transport corruption. 

dose the value of MTU which showing in ifconfig's output is not correct? if then, how can I find correct MTU?

Could you answer my questions? I hope your good advice.

Comment 17 Ihar Hrachyshka 2014-10-22 10:32:35 UTC
YONGKI,

could you please attach output for the following commands:

- ip a;
- brctl show.

I suspect 1500 is MTU used for TAP devices plugged into your bridge.

What's the intended value for MTU for physical network that your customers would like to use?

Comment 18 YONGKI, KIM 2014-10-22 11:45:42 UTC
I'm sorry that I can't show you the output.
Already I withdraw from there so I can't perform your request.

but I remember the mtu like below.

- physical devices' mtu = 1700
- tap' mtu = 1500
- bridge's mtu = 1500 

also they want to fix 1700 as mtu value.

Comment 19 Ihar Hrachyshka 2014-10-29 15:25:09 UTC
OK, for now, I stop looking at the bug. We'll have MTU discussion on Openstack Summit the next week after which - I hope - I'll be able to come up with better short- and long-term solution.

Comment 20 Ihar Hrachyshka 2014-11-11 10:35:31 UTC
John, I've heard you're going to heavy-lift ttl blueprints in upstream. Please take care of the bug too.

Brief story: customer would like to raise mtu on all his tap devices on compute nodes, and he does not use tunnelling. This does not strictly belong to neutron, but I think it's better to track it in the component for now.

Comment 21 Timothy Swanson 2015-07-29 18:32:12 UTC
This looks to be the same problem as described in this launchpad bug:  https://bugs.launchpad.net/networking-cisco/+bug/1443607

This issue has been fixed in neutron master (pre-liberty) via: 
  https://git.openstack.org/cgit/openstack/neutron/commit/?id=6cf92011143eb55adda180ffac91886566fc7826

  review:  https://review.openstack.org/#/c/174558/

This upstream fix should be backported to OSP7.

Comment 26 Toni Freger 2015-09-21 05:47:56 UTC
The code is available within the openstack-neutron-openvswitch-2015.1.1-5.el7ost.noarch
Tested on rhel7.1

Comment 28 errata-xmlrpc 2015-10-08 12:07:24 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2015:1866