Support MTU as a first class primitive in networking

Bug #1391519 reported by James Troup on 2014-11-11
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
MAAS
High
Blake Rouse

Bug Description

Today, you need jumbo (or at least >> 1500) frames to:

 * run an OpenStack cloud using Neutron with GRE tunnels¹

 * get decent performance from 10Gb/s+ NICs (in most scenarios)

Also:

 * MAAS owns the initial network setup of machines it deploys

 * Debugging/diagnosing issues caused by undersized MTU is extremely
   painful

I think there's a few implications from this:

 * MAAS should allow MTU to be configured on a cluster/node basis

 * MAAS could test MTU for each node as part of commissioning
   (e.g. Can I send and receive back a large ping packet to/from the
   cluster controller with MTU set to 9K? No? Can I do it at 1.5K?
   No? Panic.) and use this information to help guide a user who's
   configuring MTU

--

¹ While its possible to get by by reducing the MTU on guests, this is
  not reliable (not all operating systems support reducing the MTU
  based on dhcp information) and the Canonical Server team strongly
  recommend running with a higher MTU on the neutron gateway nodes
  instead.

Graham Binns (gmb) wrote :

This can be part of the work on the new MAAS networking model for 1.8.

Changed in maas:
status: New → Triaged
importance: Undecided → High
milestone: none → next
Changed in maas:
milestone: next → 1.9.0
tags: added: networking
Changed in maas:
assignee: nobody → Blake Rouse (blake-rouse)
status: Triaged → Fix Committed
Changed in maas:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers