You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Marcus Sorensen (JIRA)" <ji...@apache.org> on 2013/10/27 16:32:33 UTC
[jira] [Updated] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcus Sorensen updated CLOUDSTACK-4967:
----------------------------------------
Description:
com.cloud.exception.InternalErrorException: Failed to create vnet 987529: inet 172.17.10.10/24 brd 172.17.10.255 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 'modifyvxlan.sh' 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.
was:
com.cloud.exception.InternalErrorException: Failed to create vnet 987529: inet 172.17.10.10/24 brd 172.17.10.255 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 'modifyvxlan.sh' 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
> vxlan doesn't scale
> -------------------
>
> Key: CLOUDSTACK-4967
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 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: Toshiaki Hatano
> Fix For: 4.3.0
>
>
> com.cloud.exception.InternalErrorException: Failed to create vnet 987529: inet 172.17.10.10/24 brd 172.17.10.255 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 'modifyvxlan.sh' 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
(v6.1#6144)