On 8/8/12 10:31 AM, "Pranav Saxena" <pranav.sax...@citrix.com> wrote:
>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. Correct. >So essentially , the StartIp and endIP are respected by Shared networks >only ? Shared and Isolated with NO source nat service. >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 ? Yes, we should make them mandatory in the UI. > >Thanks, >Pranav > >-----Original Message----- >From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] >Sent: Wednesday, August 08, 2012 10:44 PM >To: cloudstack-dev@incubator.apache.org >Subject: Re: Networking question > >On 8/7/12 11:54 PM, "Hugo Trippaers" <htrippa...@schubergphilis.com> >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 >(acquireDirectIpAddress) > > >>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 into >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. > >> >> >>Hugo >> >>-----Original Message----- >>From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] >>Sent: Tuesday, August 07, 2012 10:51 PM >>To: cloudstack-dev@incubator.apache.org >>Subject: Re: Networking question >> >>Hugo, >> >>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. >> >>-Alena. >> >>On 8/7/12 1:38 PM, "Hugo Trippaers" <htrippa...@schubergphilis.com> >>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. >>> >>>Cheers, >>> >>>Hugo >>> >>>Sent from my iPhone >>> >>>On 7 aug. 2012, at 20:14, "Alena Prokharchyk" >>><alena.prokharc...@citrix.com> wrote: >>> >>>> On 8/7/12 6:14 AM, "Hugo Trippaers" <htrippa...@schubergphilis.com> >>>>wrote: >>>> >>>>> 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 >>>>>networks. >>>>> 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 >>>>>402) >>>>> 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 >>>>>lan. >>>>> >>>>> 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 >>>>set. >>>> * 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 >>>>table. >>>> 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 >>>>needed. >>>> >>>> -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 >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> > > >
