You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Matthew Midgett <cl...@trick-solutions.com.INVALID> on 2014/12/15 21:17:13 UTC
Proper way to make shared network
I just created the following Network service
Description SharedRoutedNetwork
State Enabled
Guest Type Shared
label.persistent No
Egress Default Policy Allow
Availability Optional
Created by system No
Specify VLAN Yes
Specify IP ranges Yes
Conserve mode Yes
Network Rate (Mb/s) 1024 Mb/s
Traffic Type Guest
Supports Streched L2 Subnet No
Supported Services UserData, Firewall, Dhcp, PortForwarding, SourceNat,
StaticNat, Lb, Dns
I now went to Infrastructure >zones > networking > cloud-public > added a
/24
And then went to Infrastructure > zones > networking > cloud-guest and
removed the dynamic vlan range of 600-799
Now I went to networking on main page and added a guest network that uses a
10.0.1.0/24 on vlan 600 and uses the network offering that I created first.
The cloud-guest switch ports are trunked so I went to the router and created
vlan600 and put 10.0.1.1 for its ip.
Is this the correct way to make a shared guest network?
Should I have created the network on the router with no ip but just the
vlan? Would this make the cloudstack VR 10.0.1.1? and that would be used for
the default route?
Just thinking about this I should remove the IP from the routers vlan
interface and then make the network have a gateway of 1 and start the range
at 1. This would make the VR the default gateway since it's going to be
natting the public ip's anyway.
Any help
-----Original Message-----
From: Paul Omamogho [mailto:omamogho@icloud.com]
Sent: Monday, December 15, 2014 2:45 PM
To: users@cloudstack.apache.org
Subject: Re: Virtual Router - Strange issue - Cloud-init
Have you checked to ensure the entire VLAN Guest traffic ranges e.g. 500 -
550 specified in CS are subsequently tagged?
> On 15 Dec 2014, at 18:52, Matthew Midgett
<cl...@trick-solutions.com.INVALID> wrote:
>
> Correct that is the way that I have it setup. CS creates a tagged
> network as shown in this example
> http://mirror.charlottecolo.com/cloudstack/xennetwork.jpg
>
> All the VM's can ping its gateway on the router. All the VM can ping
> any public address. The VM's can only ping the VM's on their
> hypervisor where the VR is.
>
>
>
> -----Original Message-----
> From: Paul Omamogho [mailto:omamogho@icloud.com]
> Sent: Monday, December 15, 2014 12:37 PM
> To: users@cloudstack.apache.org
> Subject: Re: Virtual Router - Strange issue - Cloud-init
>
> Hi Matthew,
>
> To my understanding your guest Nic in XenServer and CS should remain
> untagged while the associated VLAN ports in your Switch should be tagged.
>
> Cheers,
>
> Paul
>
>> On 15 Dec 2014, at 16:44, Matthew Midgett
> <cl...@trick-solutions.com.INVALID> wrote:
>>
>> I have advanced shared networking with a public address being
>> assigned to each VM. The VR doesn't show having a public IP this way
>> but the guest IP is a public one. Should I change the Vlans and
>> trunks to having a private address and let the VR setup the default
>> networking with a private range and let it do NAT the way that ACS was
designed?
>>
>> Just tried to ping the VR again from a VM on another host and I can't.
>> I can ping the gateway which means the Vlans and trunking and cabling
>> are fine. Can ping the VR from the public IP all the time. Also can
>> ping the VR from both hypervisors using it's public.
>>
>> If 2 VM and VR are on the same host then pings work between them.
>>
>> Just logged into the VR and I can ping the address of the VM's that
>> are on the same host but not the one on the other host.
>>
>>
>> -----Original Message-----
>> From: Matthew Midgett [mailto:cloudstck@trick-solutions.com.INVALID]
>> Sent: Monday, December 15, 2014 8:47 AM
>> To: users@cloudstack.apache.org
>> Subject: Virtual Router - Strange issue - Cloud-init
>>
>> ACS 4.4.2 and Xenserver 6.2
>>
>>
>>
>> When I try to deploy a template that is using cloud-ini and the VR is
>> on the other the VM can't connect to the meta data. When the VR and
>> VM is on the same host it works with no issue and now that I have
>> migrated the VR back a forth a few times it not an issue until the VM
>> reboots and then it can't connect to the VR unless it's on the same
>> host. DHCP is working fine no matter what host the VR is on. What
>> could be causing this? Even when I can't get the meta data I can ping
>> the VR so I don't think it's a physical network issue.
>>
>>
>>
>> Tested getting meta data like this curl
>> http://VR-IP/latest/meta-data/
>>
>>
>>
>> Matthew Midgett
>>
>>
>
>
RE: Proper way to make shared network
Posted by Matthew Midgett <cl...@trick-solutions.com.INVALID>.
I want the virtual router to do this so the customer can control the rules themselves inside of CloudStack. My router has to be configured by me.
-----Original Message-----
From: Erik Weber [mailto:terbolous@gmail.com]
Sent: Monday, December 15, 2014 3:25 PM
To: users@cloudstack.apache.org
Subject: Re: Proper way to make shared network
On Mon, Dec 15, 2014 at 9:17 PM, Matthew Midgett < cloudstck@trick-solutions.com.invalid> wrote:
>
> I just created the following Network service
>
> Description SharedRoutedNetwork
> State Enabled
> Guest Type Shared
> label.persistent No
> Egress Default Policy Allow
> Availability Optional
> Created by system No
> Specify VLAN Yes
> Specify IP ranges Yes
> Conserve mode Yes
> Network Rate (Mb/s) 1024 Mb/s
> Traffic Type Guest
> Supports Streched L2 Subnet No
> Supported Services UserData, Firewall, Dhcp, PortForwarding,
> SourceNat,
> StaticNat, Lb, Dns
>
>
Not sure, but most likely your offering should only have UserData, DHCP and DNS. Atleast that's what the default one has.
Your actual router will provide NAT/FW/PF
--
Erik
Re: Proper way to make shared network
Posted by Erik Weber <te...@gmail.com>.
On Mon, Dec 15, 2014 at 9:17 PM, Matthew Midgett <
cloudstck@trick-solutions.com.invalid> wrote:
>
> I just created the following Network service
>
> Description SharedRoutedNetwork
> State Enabled
> Guest Type Shared
> label.persistent No
> Egress Default Policy Allow
> Availability Optional
> Created by system No
> Specify VLAN Yes
> Specify IP ranges Yes
> Conserve mode Yes
> Network Rate (Mb/s) 1024 Mb/s
> Traffic Type Guest
> Supports Streched L2 Subnet No
> Supported Services UserData, Firewall, Dhcp, PortForwarding,
> SourceNat,
> StaticNat, Lb, Dns
>
>
Not sure, but most likely your offering should only have UserData, DHCP and
DNS. Atleast that's what the default one has.
Your actual router will provide NAT/FW/PF
--
Erik
RE: Proper way to make shared network
Posted by Matthew Midgett <cl...@trick-solutions.com.INVALID>.
I should make the GW 10.0.1.1 and set the range from .1 to .254 so when the
VR spawns it will take the .1?
-----Original Message-----
From: Paul Omamogho [mailto:omamogho@icloud.com]
Sent: Monday, December 15, 2014 3:30 PM
To: users@cloudstack.apache.org
Subject: Re: Proper way to make shared network
It should be just the plan without assigning any ip
> On 15 Dec 2014, at 21:17, Matthew Midgett
<cl...@trick-solutions.com.INVALID> wrote:
>
> I just created the following Network service
>
> Description SharedRoutedNetwork
> State Enabled
> Guest Type Shared
> label.persistent No
> Egress Default Policy Allow
> Availability Optional
> Created by system No
> Specify VLAN Yes
> Specify IP ranges Yes
> Conserve mode Yes
> Network Rate (Mb/s) 1024 Mb/s
> Traffic Type Guest
> Supports Streched L2 Subnet No
> Supported Services UserData, Firewall, Dhcp, PortForwarding, SourceNat,
> StaticNat, Lb, Dns
>
>
> I now went to Infrastructure >zones > networking > cloud-public >
> added a
> /24
> And then went to Infrastructure > zones > networking > cloud-guest and
> removed the dynamic vlan range of 600-799
>
> Now I went to networking on main page and added a guest network that
> uses a
> 10.0.1.0/24 on vlan 600 and uses the network offering that I created
first.
>
> The cloud-guest switch ports are trunked so I went to the router and
> created
> vlan600 and put 10.0.1.1 for its ip.
>
> Is this the correct way to make a shared guest network?
>
> Should I have created the network on the router with no ip but just
> the vlan? Would this make the cloudstack VR 10.0.1.1? and that would
> be used for the default route?
>
> Just thinking about this I should remove the IP from the routers vlan
> interface and then make the network have a gateway of 1 and start the
> range at 1. This would make the VR the default gateway since it's
> going to be natting the public ip's anyway.
>
> Any help
>
>
> -----Original Message-----
> From: Paul Omamogho [mailto:omamogho@icloud.com]
> Sent: Monday, December 15, 2014 2:45 PM
> To: users@cloudstack.apache.org
> Subject: Re: Virtual Router - Strange issue - Cloud-init
>
> Have you checked to ensure the entire VLAN Guest traffic ranges e.g.
> 500 -
> 550 specified in CS are subsequently tagged?
>
>
>> On 15 Dec 2014, at 18:52, Matthew Midgett
> <cl...@trick-solutions.com.INVALID> wrote:
>>
>> Correct that is the way that I have it setup. CS creates a tagged
>> network as shown in this example
>> http://mirror.charlottecolo.com/cloudstack/xennetwork.jpg
>>
>> All the VM's can ping its gateway on the router. All the VM can ping
>> any public address. The VM's can only ping the VM's on their
>> hypervisor where the VR is.
>>
>>
>>
>> -----Original Message-----
>> From: Paul Omamogho [mailto:omamogho@icloud.com]
>> Sent: Monday, December 15, 2014 12:37 PM
>> To: users@cloudstack.apache.org
>> Subject: Re: Virtual Router - Strange issue - Cloud-init
>>
>> Hi Matthew,
>>
>> To my understanding your guest Nic in XenServer and CS should remain
>> untagged while the associated VLAN ports in your Switch should be tagged.
>>
>> Cheers,
>>
>> Paul
>>
>>> On 15 Dec 2014, at 16:44, Matthew Midgett
>> <cl...@trick-solutions.com.INVALID> wrote:
>>>
>>> I have advanced shared networking with a public address being
>>> assigned to each VM. The VR doesn't show having a public IP this way
>>> but the guest IP is a public one. Should I change the Vlans and
>>> trunks to having a private address and let the VR setup the default
>>> networking with a private range and let it do NAT the way that ACS
>>> was
> designed?
>>>
>>> Just tried to ping the VR again from a VM on another host and I can't.
>>> I can ping the gateway which means the Vlans and trunking and
>>> cabling are fine. Can ping the VR from the public IP all the time.
>>> Also can ping the VR from both hypervisors using it's public.
>>>
>>> If 2 VM and VR are on the same host then pings work between them.
>>>
>>> Just logged into the VR and I can ping the address of the VM's that
>>> are on the same host but not the one on the other host.
>>>
>>>
>>> -----Original Message-----
>>> From: Matthew Midgett [mailto:cloudstck@trick-solutions.com.INVALID]
>>> Sent: Monday, December 15, 2014 8:47 AM
>>> To: users@cloudstack.apache.org
>>> Subject: Virtual Router - Strange issue - Cloud-init
>>>
>>> ACS 4.4.2 and Xenserver 6.2
>>>
>>>
>>>
>>> When I try to deploy a template that is using cloud-ini and the VR
>>> is on the other the VM can't connect to the meta data. When the VR
>>> and VM is on the same host it works with no issue and now that I
>>> have migrated the VR back a forth a few times it not an issue until
>>> the VM reboots and then it can't connect to the VR unless it's on
>>> the same host. DHCP is working fine no matter what host the VR is
>>> on. What could be causing this? Even when I can't get the meta data
>>> I can ping the VR so I don't think it's a physical network issue.
>>>
>>>
>>>
>>> Tested getting meta data like this curl
>>> http://VR-IP/latest/meta-data/
>>>
>>>
>>>
>>> Matthew Midgett
>>>
>>>
>>
>>
>
>
Re: Proper way to make shared network
Posted by Paul Omamogho <om...@icloud.com>.
It should be just the plan without assigning any ip
> On 15 Dec 2014, at 21:17, Matthew Midgett <cl...@trick-solutions.com.INVALID> wrote:
>
> I just created the following Network service
>
> Description SharedRoutedNetwork
> State Enabled
> Guest Type Shared
> label.persistent No
> Egress Default Policy Allow
> Availability Optional
> Created by system No
> Specify VLAN Yes
> Specify IP ranges Yes
> Conserve mode Yes
> Network Rate (Mb/s) 1024 Mb/s
> Traffic Type Guest
> Supports Streched L2 Subnet No
> Supported Services UserData, Firewall, Dhcp, PortForwarding, SourceNat,
> StaticNat, Lb, Dns
>
>
> I now went to Infrastructure >zones > networking > cloud-public > added a
> /24
> And then went to Infrastructure > zones > networking > cloud-guest and
> removed the dynamic vlan range of 600-799
>
> Now I went to networking on main page and added a guest network that uses a
> 10.0.1.0/24 on vlan 600 and uses the network offering that I created first.
>
> The cloud-guest switch ports are trunked so I went to the router and created
> vlan600 and put 10.0.1.1 for its ip.
>
> Is this the correct way to make a shared guest network?
>
> Should I have created the network on the router with no ip but just the
> vlan? Would this make the cloudstack VR 10.0.1.1? and that would be used for
> the default route?
>
> Just thinking about this I should remove the IP from the routers vlan
> interface and then make the network have a gateway of 1 and start the range
> at 1. This would make the VR the default gateway since it's going to be
> natting the public ip's anyway.
>
> Any help
>
>
> -----Original Message-----
> From: Paul Omamogho [mailto:omamogho@icloud.com]
> Sent: Monday, December 15, 2014 2:45 PM
> To: users@cloudstack.apache.org
> Subject: Re: Virtual Router - Strange issue - Cloud-init
>
> Have you checked to ensure the entire VLAN Guest traffic ranges e.g. 500 -
> 550 specified in CS are subsequently tagged?
>
>
>> On 15 Dec 2014, at 18:52, Matthew Midgett
> <cl...@trick-solutions.com.INVALID> wrote:
>>
>> Correct that is the way that I have it setup. CS creates a tagged
>> network as shown in this example
>> http://mirror.charlottecolo.com/cloudstack/xennetwork.jpg
>>
>> All the VM's can ping its gateway on the router. All the VM can ping
>> any public address. The VM's can only ping the VM's on their
>> hypervisor where the VR is.
>>
>>
>>
>> -----Original Message-----
>> From: Paul Omamogho [mailto:omamogho@icloud.com]
>> Sent: Monday, December 15, 2014 12:37 PM
>> To: users@cloudstack.apache.org
>> Subject: Re: Virtual Router - Strange issue - Cloud-init
>>
>> Hi Matthew,
>>
>> To my understanding your guest Nic in XenServer and CS should remain
>> untagged while the associated VLAN ports in your Switch should be tagged.
>>
>> Cheers,
>>
>> Paul
>>
>>> On 15 Dec 2014, at 16:44, Matthew Midgett
>> <cl...@trick-solutions.com.INVALID> wrote:
>>>
>>> I have advanced shared networking with a public address being
>>> assigned to each VM. The VR doesn't show having a public IP this way
>>> but the guest IP is a public one. Should I change the Vlans and
>>> trunks to having a private address and let the VR setup the default
>>> networking with a private range and let it do NAT the way that ACS was
> designed?
>>>
>>> Just tried to ping the VR again from a VM on another host and I can't.
>>> I can ping the gateway which means the Vlans and trunking and cabling
>>> are fine. Can ping the VR from the public IP all the time. Also can
>>> ping the VR from both hypervisors using it's public.
>>>
>>> If 2 VM and VR are on the same host then pings work between them.
>>>
>>> Just logged into the VR and I can ping the address of the VM's that
>>> are on the same host but not the one on the other host.
>>>
>>>
>>> -----Original Message-----
>>> From: Matthew Midgett [mailto:cloudstck@trick-solutions.com.INVALID]
>>> Sent: Monday, December 15, 2014 8:47 AM
>>> To: users@cloudstack.apache.org
>>> Subject: Virtual Router - Strange issue - Cloud-init
>>>
>>> ACS 4.4.2 and Xenserver 6.2
>>>
>>>
>>>
>>> When I try to deploy a template that is using cloud-ini and the VR is
>>> on the other the VM can't connect to the meta data. When the VR and
>>> VM is on the same host it works with no issue and now that I have
>>> migrated the VR back a forth a few times it not an issue until the VM
>>> reboots and then it can't connect to the VR unless it's on the same
>>> host. DHCP is working fine no matter what host the VR is on. What
>>> could be causing this? Even when I can't get the meta data I can ping
>>> the VR so I don't think it's a physical network issue.
>>>
>>>
>>>
>>> Tested getting meta data like this curl
>>> http://VR-IP/latest/meta-data/
>>>
>>>
>>>
>>> Matthew Midgett
>>>
>>>
>>
>>
>
>