[ 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)