cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Sorensen (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
Date Tue, 29 Oct 2013 10:28:30 GMT


Marcus Sorensen commented on CLOUDSTACK-4967:

It used to check for overlapping Vlan ids when registering Vlan range, it shouldn't be too
hard to add a check, if you guys both agree that limiting specific vni numbers to be used
only once per zone is less restrictive than disallowing the many interface/vni combinations
that reach >15 chars.

I think the vast majority will only deploy a single physical interface for guest traffic anyway.
If a user needs more bandwidth they may split the VNIs among multiple interfaces or use bonding,
they just can't reuse VNIs between interfaces.

> vxlan doesn't scale
> -------------------
>                 Key: CLOUDSTACK-4967
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: KVM
>    Affects Versions: 4.3.0
>            Reporter: Marcus Sorensen
>            Assignee: Yoshikazu Nojima
>             Fix For: 4.3.0
> Failed to create vnet 987529:     inet
brd scope global cloudbr0Error: an inet prefix is expected rather than "239.15.3857.137".Error
> It looks like the vxlan implementation doesn't scale correctly with vxlan's capabilities.
The VNI is supposed to be up to 24 bits (16777216), it should be possible to use high VNI
numbers. The script '' seems to do this:
> local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 )).$((
$vxlanId % 256 ))"
> $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256
> On a less important note, I should point out that the bridge naming convention will break
in certain rare situations. The max size of a bridge device name is 15 characters. For bond
devices, a VNI above 10 million will not fit, e.g. "brbond0-16000000", or ethernet devices
above 10 "breth10-16000000".  However, these may be quite rare, and changing the naming convention
as we found in 4.2 is a bit painful if it can't be done in a backward compatible way. My first
thought was to have vxlan and vxlan only use hex for it's VNI, that might be ok since it's
never been released yet.

This message was sent by Atlassian JIRA

View raw message