[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808481#comment-13808481
 ] 

ASF subversion and git services commented on CLOUDSTACK-4967:
-------------------------------------------------------------

Commit 4a9f05bda075d03c4a5a015e081c70b3d8b72267 in branch refs/heads/master 
from [~mlsorensen]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4a9f05b ]

CLOUDSTACK-4967
1) vxlan will use bridge scheme 'brvx-<vni>'. Multiple physical networks can 
host guest
traffic type with vxlan isolation, so long as they don't use the same VNI range.

2) Guest traffic labels can be physical interface if bridge by given name is 
not found.
Normally we take traffic label name, find the matching bridge, then resolve 
that to a
physical interface. Then we create guest bridges on that interface. Now we can 
just
specify the interface.


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

Reply via email to