cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pranav Saxena <>
Subject RE: Networking question
Date Wed, 08 Aug 2012 17:31:16 GMT
Hi Alena , 

when you mentioned this -"  Start/EndIp addresses in createNetwork define the first vlan range
for the network. These parameters are not required, as the range can be added later with createVlanIpRange
command. We can make it required in the UI though to force the admin to configure first ip
range along with the network creation. "

Just to be clear , does this mean -   If we have  an Isolated network with source NAT service
enabled, then start/endIp are being ignored in createNetwork command. So essentially , the
StartIp and endIP are respected by Shared networks only ?  So those fields have to be mandatory
 when creating the shared network from the UI and hidden if we are creating an isolated network
with source NAT enabled ?


-----Original Message-----
From: Alena Prokharchyk [] 
Sent: Wednesday, August 08, 2012 10:44 PM
Subject: Re: Networking question

On 8/7/12 11:54 PM, "Hugo Trippaers" <> wrote:

>Hey Alena,
>Why would we want to explicitly add a vlan for "isolated" networks 
>without source nat service? The guest IP allocator works for that 
>scenario and the network is not supposed to be shared.

Guest IP allocator works only for Isolated networks with Source Nat service enabled. If source
nat service is disabled for Isolated network, it uses the same ip address allocation mechanism
as Shared network

>I'm actively working with this part of the code as currently the some 
>of the create code explicitly checks for vlan tags before deciding if 
>the IP networks overlap. However with the SDN code there is no such 
>thing as a vlan, but the network is still "private". I'm trying to see 
>which parts of the code should be changed to allow it to work with the SDN code.
>Next to that there is an inconsistency in the permissions, it is 
>possible for a domain-admin to create an isolated network without 
>SourceNat. The network is actually created, but the ip addresses are 
>not added to the vlan and user_ip_address tables.

Start/EndIp addresses in createNetwork define the first vlan range for the network. These
parameters are not required, as the range can be added later with createVlanIpRange command.
We can make it required in the UI though to force the admin to configure first ip range along
with the network creation. You can file a bug against the UI component.

>This would cause an exception when creating a VM in this network as 
>there are no IP addresses allocated. I think domain admins should be 
>able to create these types of networks.
>Am I making any sense at all?

Sure, everything you said, makes sense. I understand that the fact that the same createNetwork
API call is used for creating diff kinds of networks, and some parameters might be required
only for certain types of networks, leads to confusion. We might split this call in the future
2 separate calls - one available to the ROOT admin only, allowing creating Shared and Isolated
non-source nat networks where IP/Vlan parameters are required; and another one - available
to the regular user for Guest Isolated source nat enabled network creation where cidr and
vlan are optional parameters.

>-----Original Message-----
>From: Alena Prokharchyk []
>Sent: Tuesday, August 07, 2012 10:51 PM
>Subject: Re: Networking question
>Sorry, completely missed this scenario. When I referred to ip 
>allocation in Isolated network in my email, I meant Isolated network 
>with Source Nat service.
>IP allocation for Isolated network with no source Nat falls under the 
>same rules Shared network follows. Both these networks used to be 
>called "Direct" in previous releases; and for both networks the Vlan 
>has to be added explicitly.
>"Virtual" network is always an equivalent to Isolated Network with 
>Source Nat service enabled.
>On 8/7/12 1:38 PM, "Hugo Trippaers" <> wrote:
>>Hey Alena,
>>Thanks for the explanation, but in my case the network that I'm 
>>creating is an isolated network without a SourceNat offering.
>>So it should not need have an ip allocated from the public ip table as 
>>it is isolated. It is also not a VLAN but a 'direct' network as it is 
>>provisioned by the Nicira stack.
>>I have a work around now that checks if there is a vlan defined on 
>>this network using the vlanDao and if there is not the guest allocator 
>>is used.
>>Sent from my iPhone
>>On 7 aug. 2012, at 20:14, "Alena Prokharchyk"
>><> wrote:
>>> On 8/7/12 6:14 AM, "Hugo Trippaers" <>
>>>> Heya,
>>>> I'm trying to get my head around something and would welcome some 
>>>> feedback.
>>>> The use case I'm currently working with is related to internal 
>>>> I have serveral use cases that call for internal networks that have 
>>>>no  connection to the outside world. Say I have a couple of 
>>>>webservers with  one nic in a sourcenat-ted network and one nic in a 
>>>>dedicated DB network.
>>>> And a couple of DB servers that are only located in the DB network.
>>>>(A  similar scenario is where the VMs exist in an already existing 
>>>>VLAN or  bridged network using a Nicira Nvp Gateway)
>>>> As admin I have created a networkoffering with just DHCP, DNS and 
>>>>UserData enabled and no other services. As a domain-admin I can 
>>>>create a  network based on that offering via the API and give it an 
>>>>ip range that I  want. When creating a VM in that network I get a 
>>>>message saying that I  can allocate an address.
>>>> If I create this network as a domain-admin the last step in
>>>> createNetwork(CreateNetworkCmd) in NetworkManagerImpl, the call to 
>>>>createVlanAndPublicIpRange(), is skipped. This is OK as it is an 
>>>>internal  network for domain. When creating the VM the 
>>>>GuestNetworkGuru (line
>>>> assumes that it should get an IP using the allocateDirectIp call.
>>>>This  goes wrong as there are no IP's in the "public" pool for this 
>>>> I would like to change this piece in GuestNetworkGuru to check if 
>>>> the public range is in the public ip table and if it's not use the 
>>>> acquireGuestIpAddress call to reserve an IP.
>>> Hugo, there is a difference in how we maintain ip addresses for 
>>> Isolated networks and Shared networks.
>>> 1) For Isolated networks, any IP address from the CIDR defined on 
>>> the network level, can be used for vm deployment. So whenever 
>>> acquireGuestIpAddress is called, we:
>>> * get the network cidr
>>> * figure out all ip addresses used from this cidr by existing vms -  
>>>this info it taken from Nics table. Put these ip addresses to avoid 
>>> * randomly pick up any free ip address (considering the avoid set)  
>>>from the cidr space.
>>> 2) For Shared networks, the IP ranges are kept in user_ip_address 
>>> There can be non-contiguous ip ranges - you can add every range 
>>>using  createVlanIpRange admin API. And the ip allocation algorithm 
>>>is quite  different here, as we can't just rely on the cidr and 
>>>assume that all  ip addresses from the cidr can be used as we do in 
>>>Isolated network case.
>>> Every time we have to allocate ip address from the Shared range for 
>>>the  vm, we look at the user_ip_address table and pick up any FREE ip 
>>>address  from the network. If there are no free ip addresses left, 
>>>admin has to add  more using createVlanIpRange API.
>>> So we can't use acquireGuestIpAddress call for Shared networks.
>>> Let me know if the explanation is clear enough, or more details are 
>>> -Alena.
>>>> But as I'm not completely sure about the reasoning behind this I 
>>>> would like some feedback on my reasoning before I break stuff in 
>>>> other places
>>>> :-)
>>>> Cheers,
>>>> Hugo

View raw message