You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Andrija Panic (JIRA)" <ji...@apache.org> on 2014/10/26 17:39:34 UTC

[jira] [Updated] (CLOUDSTACK-7790) VXLAN interface MTU change from 1450 to 1500 and JUMBRO frames

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-7790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrija Panic updated CLOUDSTACK-7790:
--------------------------------------
    Description: 
By default, when using vxlan as isolation method for Guest traffic - cloudstack created vxlan vbidge and interface, and set's MTU for those to 1450 bytes.  Problem is that default OS MTU for any VM is 1500 and all packets get droped (except maybe DHCP and ping which uses smaller packets).

1) Current proposed solution is to change MTU inside VM/template to 1450 - which is absolutely NOT user friendly and degrades performance

2) Better approach - set MTU on vxlan interface and bridge to a default value of 1500, and ask ADMIN to increase MTU to 1600 bytes on physical interface ethX or cloudbrX and enable at least 1600 frames on physical network

3) Even better - add GUI component to CloudStack for a MTU value, so the ADMIN can deploy JUMBRO frames accross whole Guest network - this should be probably enabled per network offering, or similar.

Current setup, require MTU change inside VM is not a good solution, and does not enable user to use JUMBRO frames at all...

  was:
By default, when using vxlan as isolation method for Guest traffic - cloudstack created vxlan vbidge and interface, and set's MTU for those to 1450 bytes.  Problem is that default OS MTU for any VM is 1500 and all packets get droped (except maybe DHCP and ping which uses smaller packets).

1) Current proposed solution is to change MTU inside VM/template to 1450 - which is absolutely NOT user friendly and degrades performance

2) Better approach - set MTU on vxlan interface and bridge to a default value of 1500, and ask ADMIN to increase MTU to 1600 bytes on physical interface ethX or cloudbrX and enable at least 1600 frames on physical network

3) Even better - add GUI component to CloudStack for a MTU value, so the ADMIN can deploy JUMBRO frames accross whole Guest network - this should be probably enabled per network offering, or similar.

Current setup, requiring MTU change inside VM is not a good solution, and does not enable user to use JUMBRO frames at all...


> VXLAN interface MTU change from 1450 to 1500 and JUMBRO frames
> --------------------------------------------------------------
>
>                 Key: CLOUDSTACK-7790
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7790
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Network Controller
>    Affects Versions: 4.4.1
>         Environment: NOT important - CentOS 6.5, elrepo kernel 3.10 - 
>            Reporter: Andrija Panic
>            Priority: Critical
>              Labels: frames, jumbo, vxlan
>
> By default, when using vxlan as isolation method for Guest traffic - cloudstack created vxlan vbidge and interface, and set's MTU for those to 1450 bytes.  Problem is that default OS MTU for any VM is 1500 and all packets get droped (except maybe DHCP and ping which uses smaller packets).
> 1) Current proposed solution is to change MTU inside VM/template to 1450 - which is absolutely NOT user friendly and degrades performance
> 2) Better approach - set MTU on vxlan interface and bridge to a default value of 1500, and ask ADMIN to increase MTU to 1600 bytes on physical interface ethX or cloudbrX and enable at least 1600 frames on physical network
> 3) Even better - add GUI component to CloudStack for a MTU value, so the ADMIN can deploy JUMBRO frames accross whole Guest network - this should be probably enabled per network offering, or similar.
> Current setup, require MTU change inside VM is not a good solution, and does not enable user to use JUMBRO frames at all...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)