[
https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807245#comment-13807245
]
Yoshikazu Nojima commented on CLOUDSTACK-4967:
----------------------------------------------
{quote}
The max size of a bridge device name is 15 characters.
{quote}
Thank you for let me know the length limitation.
If we use hex for vxlan, I think we need to append the prefix "0x" not to be
mistaken to decimal, because we keep using decimal for vlan, but it consumes 2
more length.
Moreover, user may use vlan interface like "eth0.1000" for underlay network,
and the bridge name will be "breth0.1000-<VNI>". It's too long even if we use
hex.
I think raising error when the physical nic's name is longer than 6 is better
workaround.
How do you think, Marcus?
> 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)
