[
https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Sorensen resolved CLOUDSTACK-4967.
-----------------------------------------
Resolution: Fixed
> 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: Yoshikazu Nojima
> 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.5#6160)
