It should be just the plan without assigning any ip
> On 15 Dec 2014, at 21:17, Matthew Midgett
> <[email protected]> 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:[email protected]]
> Sent: Monday, December 15, 2014 2:45 PM
> To: [email protected]
> 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
> <[email protected]> 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:[email protected]]
>> Sent: Monday, December 15, 2014 12:37 PM
>> To: [email protected]
>> 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
>> <[email protected]> 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:[email protected]]
>>> Sent: Monday, December 15, 2014 8:47 AM
>>> To: [email protected]
>>> 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
>>>
>>>
>>
>>
>
>
