cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Sorensen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-2008) guest network vlan tag chain issue
Date Fri, 12 Apr 2013 16:00:17 GMT

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

Marcus Sorensen commented on CLOUDSTACK-2008:
---------------------------------------------

Ok, I'll see if I can duplicate that, might not be today.

 One thing I would mention is that if you are starting out with your own
tagged interface you want to avoid telling cloudstack about that tag since
it isn't in control of it. Generally you want to also create a bridge for
it as well and provide a traffic label. This way, you don't provide a vlan
tag when filling out management details, you just tell cloudstack which
bridge to tap into.

 So what might help is to create your bond0.60, then create brbond0.60 (or
whatever you want to call your management bridge, cloudbr0 or whatever),
then when you get to the physical network setup with the icons, provide
"brbond0.60" as the traffic label for management. If you do this, when you
get to the IP details, do not enter a vlan number for the pod/management
info, leave it blank.

If you want, you can do this for 50 and 70 as well, and cloudstack will
only be in charge of creating the dynamic networks (ones provisioned via
cloudstack).




                
> guest network vlan tag chain issue
> ----------------------------------
>
>                 Key: CLOUDSTACK-2008
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2008
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Network Controller
>    Affects Versions: 4.0.1
>         Environment: centos 6.4
> HP BL460 G1 
>            Reporter: danny webb
>            Priority: Minor
>
> Hi,
> I have setup a cloudstack instance where my "root" eth device is a vlan tagged bond0.60
(as the network I am on has a different default VLAN id than my test vlans).  
> so I am setup like this:
>     bond0.60 / cloudbr0 == management network / ip of box (bond0 == nothing)
>      
>     bond0.60  Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C  
>               inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
>               UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
>               RX packets:37189 errors:0 dropped:0 overruns:0 frame:0
>               TX packets:34030 errors:0 dropped:0 overruns:0 carrier:0
>               collisions:0 txqueuelen:0
>               RX bytes:4476334 (4.2 MiB)  TX bytes:31055747 (29.6 MiB)
>     cloudbr0  Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C  
>               inet addr:172.18.102.8  Bcast:172.18.102.255  Mask:255.255.255.0
>               inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
>               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>               RX packets:36531 errors:0 dropped:0 overruns:0 frame:0
>               TX packets:32606 errors:0 dropped:0 overruns:0 carrier:0
>               collisions:0 txqueuelen:0
>               RX bytes:4435824 (4.2 MiB)  TX bytes:30976056 (29.5 MiB)
>      
> when it went to setup a new guest network (with a vlan id of 80) it created it ontop
of the bond0.60 like:
>      
>     bond0.60.80 Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C  
>               inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
>               UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
>               RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>               TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
>               collisions:0 txqueuelen:0
>               RX bytes:0 (0.0 b)  TX bytes:13777 (13.4 KiB)
>      
>     [root@slo-cnkvm004 ~]# brctl show
>     bridge name     bridge id               STP enabled     interfaces
>     cloud0          8000.000000000000       no             
>     cloudVirBr80            8000.0017a477483c       no              bond0.60.80
>      
> which doesn't seem to work and I am pretty sure is syntactically wrong.  I can't ping
any guests that come up on that network.  When creating new devices it should I believe be
creating them off of the base eth device (ie eth0, or bond0).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message