[
https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807711#comment-13807711
]
Marcus Sorensen commented on CLOUDSTACK-4967:
---------------------------------------------
Hmm, I'm wishing I hadn't found the problem now :-) I don't really like the
option where we limit to 4 or less characters, it's severely limiting. I think
the odds of people wanting to use 'bond' adapters are much higher than the odds
of someone using VNI 10,000,000. Worse, I think the odds of someone wanting to
use 'eth0.1000' as you mention are also much higher, but 'breth0.1000-' only
leaves three characters for VNI.
There might be another solution: To have vxlan use it's own bridge naming
scheme. All bridges in cloudstack used to be 'cloudVirBrX', where X was the
vlan id. This was changed to include the eth device, so that vlan ids could be
reused in situations where they were on different physical networks (e.g.
eth0.300 and eth1.300 could both be used). I'm suggesting that vxlan use
'brvx-<VNI>'. The only drawback is that there can then only be one
vxlan-isolated guest network per zone (as it was with cloudVirBrX). I don't
think that's a very big drawback, considering the scalability of vxlan,
combined with the likelihood of people even using multiple physical networks
for guest traffic.
I'm testing a patch right now, it does two things. 1) allows traffic label for
guest networks to be the actual eth/bond device if desired, and 2) changes
bridge name for vxlan to be brvx- as mentioned. What do you guys think?
> 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#6144)
