cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrija Panic <andrija.pa...@gmail.com>
Subject Re: vxlan - mtu inside VM problem
Date Sun, 26 Oct 2014 15:57:53 GMT
Marcus, I understand that what you just said is possible and better
solution - but you should have to do this kind of changes on EVERY vxlan
interface/bridge, for every of your guest networks - so not a problem for
existing bridges - but a problem for new bridges that are going to be
deployed when new guest network is created, right ?
 You need to change mtu on vnet, on brvx-xxx, on vxlan-xxx and finally on
ethX/cloudX..

Do you see my problem, for every new guest network on singel KVM host, you
need to adjust MTU...

Or am I wrong ?


On 26 October 2014 16:52, Marcus <shadowsor@gmail.com> wrote:

> Just want to clarify, with our 9216 MTU we easily run 9000 on our VMS. You
> may want to set MTU to 1550 or greater on your KVM host interface used for
> vxlan, and adjust the network accordingly. Most vxlan documentation for
> network equipment should mention the 50 byte overhead and how to adjust for
> it (if necessary).
> On Oct 26, 2014 9:45 AM, "Marcus" <shadowsor@gmail.com> wrote:
>
> > You should instead increase MTU on the host interface to accommodate. For
> > example, we used jumbo frames with an MTU of 9216 for the host
> interface. I
> > think it wasn't mentioned because its largely assumed in CS documentation
> > that the admin understands the network design they are using, i.e. you'd
> > run into the same issue even without cloudstack handling orchestration if
> > you were manually adding VMs to a vxlan-uplinked bridge.
> >
> > There is not much network documentation aside from the cloudstack
> > tunables.  I agree though that there would be no harm in putting a note
> > somewhere reminding the admin of vxlan encapsulation requirements. You
> can
> > submit a patch for the docs to reviewboard.
> > On Oct 26, 2014 7:39 AM, "Andrija Panic" <andrija.panic@gmail.com>
> wrote:
> >
> >> Hi folks,
> >>
> >> I'm trying to figure out - why is there no documentation on the NEED to
> >> configure MTU inside VM, when using vxlan as guest isolation method ?
> >>
> >>
> >> Right now, by defaut/design, traffic/MTU goes like this:
> >>
> >> eth0 inside VM is by default 1500 bytes --> vnetY mtu1450 --> virbrX
> >> mtu1450--> vxlan mtu1450--> ethX mtu1500--> physical network (in this
> case
> >> I use ethX as traffic label instead of bridge, vxlan interface is
> created
> >> on top of ethX interface)
> >>
> >> Inside VM, I can get IP address via DHCP, use ping, because those
> generate
> >> packet less than 1500 bytes.
> >> From within VM - i.e. SSH/SCP login works, but SCP data transfer fails,
> >> yum
> >> update fails, etc -
> >>
> >> Any other traffic from VM to outside does not work and no other
> >> connectivity, until I configure MTU inside VM to be less than 1500...
> >>
> >> What is the recommended way to configure vxlan - documentation is just
> >> asking for supported kernel and iproute2 versions, use ethX or bridgeX
> as
> >> traffic label, give it IP - and that's it.
> >>
> >> There must be some clear decision on how to make this works:
> >>
> >> 1) eather - don't bother client configuring MTU inside VM/template, and
> >> make MTU on vxlan and vnet interfaces 1500 bytes - but ask Administrator
> >> to
> >> increase mtu to 1600 on physical interface ethX or bridgeX
> >>
> >> 2) as it currently is the case, use 1450 MTU on vnet,vxlan, and make
> >> trouble for user to configure MTU for each of his VMs/templates.
> >>
> >>
> >> Am I missing something here perhaps ?
> >> Is there any more complete documentation on this ?
> >>
> >> Best
> >> --
> >>
> >> Andrija Panić
> >>
> >
>



-- 

Andrija Panić
--------------------------------------
  http://admintweets.com
--------------------------------------

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message