Sorry about the delay, a couple of questions. You're not setting network_device_mtu, right?
Also, when you see the 1458 MTU, is that in the API response from neutron on a 'neutron net-show', Or is that just what you are seeing in the interfaces on the compute nodes? Setting the following in your server config (not agent), should be enough for VXLAN networks to use a jumbo MTU. [DEFAULT] global_physnet_mtu = 9000 [ml2] path_mtu = 9000 On Tue, Nov 8, 2016 at 8:31 AM, Jonathan Proulx <j...@csail.mit.edu> wrote: > On Mon, Nov 07, 2016 at 02:12:14PM -0800, Kevin Benton wrote: > :Which version of Neutron are you on now? Changing the config options had > no > :impact on existing networks in Mitaka. After updating the config, only new > :networks will be affected. You will need to use an SQL query to update the > :existing network MTUs. > > Mitaka > > I understand that old MTU's won't change, but new overlays are gettign > created with 1458 MTU despite the configs I thnk should tell it the > jumbo underlay size, so I'm probably missing something :) > > I did discover since neutron is now MTU aware I can simply drop the > dhcp-option=26,9000 and (after poking the DB for the existing jumbo > networks which had 'Null' MTUs) the old stuff and new stuff work just > new stuff has overly restrictive MTU. > > :This was changed in Newton (https://review.openstack.org/#/c/336805/) but > :we couldn't back-port it because of the behavior change. > > Neat I didn't know support form changing MTU was even planned, but I > gues it's here (well not quite *here* but...) > > -Jon > > : > : > :On Fri, Nov 4, 2016 at 10:34 AM, Jonathan Proulx <j...@csail.mit.edu> > wrote: > : > :> Hi All, > :> > :> > :> So long story short how do I get my ml2/ovs GRE tenant network to > default > :> to > :> MTU 9000 in Mitaka - or - get dhcp agents on on netork node to give > :> out different MTUs to different networks? > :> > :> > :> Seems between Kilo (my last release) and Mitaka (my current production > :> world) Neutron got a lot cleverer about MTUs and teh simple > :> workarounds I had to make by jumbo frames go are now causing some > :> issues for newly created project networks. > :> > :> Because I'm setting 'dhcp-option=26,9000' in /etc/neutron/dnsmasq.conf > :> everything get an MTU of 9000 inside the guest OS. I only *really* > :> care about this for our provider vlans, for project networks I only > :> care that they work. > :> > :> CUrrently when a new project network is created it get an MTU of 1458 > :> (1500 less GRE overhead) this is reflected in teh neutron DB and the > :> various virtual interfaces on the hypervisor and network node, but > :> DHCP configures inside the host to be 9000 and hilarity ensues. > :> > :> I tried setting DEFAULT/global_physnet_mtu=9134 in neutron.conf and > :> ml2/path_mtu=9134 in ml2.ini (which is the actual MTU of L2 links), > :> agent/veth_mtu=9134 was previously set. I thought this would result in > :> virtualdevices large enough to pass the 9000 traffic but seems to have > :> made no difference. > :> > :> I can kludge around by specifying MTU on network creation (or some > :> post facto DB hackery) but this isn't do able through my Horizon UI so > :> my users won't do it. > :> > :> Thanks, > :> -Jon > :> > :> > :> _______________________________________________ > :> OpenStack-operators mailing list > :> OpenStack-operators@lists.openstack.org > :> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > :> > > -- >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
