Jayapal, The FS seems to be updated with the feedback received on the forum, I guess you can start implementation.
-abhi On 18/01/13 4:33 PM, "Jayapal Reddy Uradi" <jayapalreddy.ur...@citrix.com> wrote: >Update the FS with the below discussions. > >Please find updated FS below. >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+address >+per+NIC > >Thanks, >Jayapal > >> -----Original Message----- >> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >> Sent: Thursday, January 17, 2013 12:51 PM >> To: CloudStack DeveloperList >> Subject: Re: Functional Specification for the multiple IPs per NIC >> >> I hope we consider the case when the ip is removed from the nic while >>there >> is a PF rule to that ip. >> >> On 1/16/13 9:10 PM, "Jayapal Reddy Uradi" >><jayapalreddy.ur...@citrix.com> >> wrote: >> >> >Hi Chiradeep, >> > >> >Now the VM NIC will have multiple IPs so for creating PF for secondary >> >ip address we will pass VM id and (optional argument) VM ip address to >> >the API. >> >When VM ip address is passed it checks the whether the ip belongs to >> >the VM or not and configures the PF for the VM IP address. >> > >> >When VM ip address argument is not passed to the API then it works in >> >older way. >> >When VM NIC has NO secondary ip address also we can pass VM id and VM >> >primary ip address to VM ipaddress argument to API to configure PF. >> > >> >Thanks, >> >Jayapal >> > >> > >> > >> >> -----Original Message----- >> >> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >> >> Sent: Thursday, January 17, 2013 1:45 AM >> >> To: CloudStack DeveloperList >> >> Subject: Re: Functional Specification for the multiple IPs per NIC >> >> >> >> Note also that the createPortForwardingRule API takes a vm id and >> >>network id, based on the assumption of a single ip per NIC. This may >> >>need an additional parameter of ip (or make the vm id optional). >> >> >> >> On 1/15/13 9:35 AM, "Anthony Xu" <xuefei...@citrix.com> wrote: >> >> >> >> >Thanks for bringing this up, >> >> > >> >> >For security group, we may need to handle following things, >> >> > >> >> >As you mentioned, >> >> >Anti-spoofing rules need to be updated, when secondary IP is >> >> >associate/dissociate to NIC. >> >> > >> >> >And >> >> >Security group rule can base on cidr and it can base on >> >> >account/security group, For example a security group rule can allow >> >> >all VMs in another account/security group to access VMs in this >> >> >security group. >> >> > >> >> >In this case, >> >> > >> >> >When secondary IP is associate/dissociate to NIC. The related >> >> >security group rule based on account/security group need to be >> >> >resent to reflect the IP change in this security group. >> >> > >> >> > >> >> > >> >> >Anthony >> >> > >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] >> >> >> Sent: Tuesday, January 15, 2013 5:17 AM >> >> >> To: cloudstack-dev@incubator.apache.org >> >> >> Subject: RE: Functional Specification for the multiple IPs per NIC >> >> >> >> >> >> Please find the updated FS in below link. >> >> >> >> >> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+IP+ad >> >> >> dr >> >> >> ess+per+NIC >> >> >> >> >> >> I want to discuss the MIPN case for shared networks. >> >> >> >> >> >> I observed VM specific security groups iptables rules in basic >> >> >> zone, in which we are allowing egress traffic from the guest VM >> >> >> primary >> >> >> (dhcp) address only. >> >> >> If we add another IP to the NIC we should update the security >> >> >> groups to allow the egress traffic from the new ip. >> >> >> >> >> >> Example Current rule: It allows traffic from the i-2-3 VM's >> >> >> 10.147.41.239 IP only. >> >> >> 0 0 i-2-3-TEST-eg all -- * * 10.147.41.239 >> >> >> 0.0.0.0/0 PHYSDEV match --physdev-in vif7.0 >>--physdev-is- >> >> >> bridged >> >> >> >> >> >> We should update security group rules each time we associate >> >> >> secondary IP to NIC. >> >> >> >> >> >> Please let me know if you have any comments or suggestion for the >> >> >> above . >> >> >> >> >> >> Thanks, >> >> >> Jayapal >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > -----Original Message----- >> >> >> > From: John Kinsella [mailto:j...@stratosec.co] >> >> >> > Sent: Wednesday, December 19, 2012 10:59 PM >> >> >> > To: cloudstack-dev@incubator.apache.org >> >> >> > Subject: Re: Functional Specification for the multiple IPs per >> >> >> > NIC >> >> >> > >> >> >> > 'morning Hari. I can think of at least one use case where >> >> >> > allowing >> >> >> the "user" >> >> >> > to specify the IP would be required - when migrating an IP from >> >> >> > one >> >> >> CAP to >> >> >> > ACS or from one VM to another. >> >> >> > >> >> >> > Anyways - I think what the real answer to your question is would >> >> >> > be >> >> >> to have >> >> >> > a granular security model around the API calls. At that point >> >> >> > you >> >> >> could specify >> >> >> > what users/groups have the ability to assign specific IPs to a >> >> >> specific instance. >> >> >> > So I'd vote to implement for now, and attack a granular api >> >> >> > security >> >> >> model >> >> >> > sooner rather than later. >> >> >> > >> >> >> > John >> >> >> > >> >> >> > On Dec 18, 2012, at 4:15 PM, Hari Kannan >> >> >> > <hari.kan...@citrix.com> >> >> >> > wrote: >> >> >> > >> >> >> > > Regarding " User can specify the IP address from the guest >> >> >> > > subnet >> >> >> if >> >> >> > > not CS picks the IP from the guest subnet " comment in the FS >> >> >> > > >> >> >> > > I don't see a need to do this - because, it is a shared >> >> >> > > network, >> >> >> how >> >> >> > > does he know what is used up and what is not? So, he could go >> >> >> through >> >> >> > > a sequence of steps only to get an error message back that it >> >> >> > > is >> >> >> not >> >> >> > > possible (and keep doing this until success) >> >> >> > > >> >> >> > > One possibility is telling him what is available - it may not >> >> >> > > be a >> >> >> big >> >> >> > > deal to reveal the used/unused IPs in isolated network >> >> >> > > (although it would be hard to show from a large CIDR what is >> >> >> > > used/available), >> >> >> but >> >> >> > > we wont even be able to tell him what is used/unused in a >> >> >> > > shared network - >> >> >> > > >> >> >> > > Any thoughts? >> >> >> > > >> >> >> > > Hari Kannan >> >> >> > > >> >> >> > > -----Original Message----- >> >> >> > > From: John Kinsella [mailto:j...@stratosec.co] >> >> >> > > Sent: Tuesday, December 18, 2012 10:36 AM >> >> >> > > To: cloudstack-dev@incubator.apache.org >> >> >> > > Subject: Re: Functional Specification for the multiple IPs per >> >> >> > > NIC >> >> >> > > >> >> >> > > Is there any logic behind 30? At some point, we're going to be >> >> >> asked, >> >> >> > > so I'd like to have a decent answer. :) >> >> >> > > >> >> >> > > On the rest of this, I'd like to get some level of consensus >> >> >> > > on the >> >> >> design. >> >> >> > What looks best to me: >> >> >> > > * Improve UserData/CloudInit support in CloudStack (I'm >> >> >> > > willing to work on this, consider it important) - allow >> >> >> > > expiration of data, >> >> >> wider >> >> >> > > variety of data supported >> >> >> > > * Create the multi-IPs-per-NIC code to get IPs via CloudInit >> >> >> > > (Need >> >> >> to >> >> >> > > think through Windows equivalent) >> >> >> > > * Update the password changing script to use CloudInit >> >> >> > > >> >> >> > > Thoughts? Or Jayapal have you already started work on the >> >> >> > > multi-IP >> >> >> > feature? >> >> >> > > >> >> >> > > On Dec 18, 2012, at 2:03 AM, Jayapal Reddy Uradi >> >> >> > <jayapalreddy.ur...@citrix.com> wrote: >> >> >> > > >> >> >> > >> Regarding IP limit, it can be made as configurable using >> >> >> > >> global >> >> >> settings and >> >> >> > default value will be 30. >> >> >> > >> >> >> >> > >> >> >> >> > >> Thanks, >> >> >> > >> Jayapal >> >> >> > >> >> >> >> > >>> -----Original Message----- >> >> >> > >>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >> >> >> > >>> Sent: Monday, December 17, 2012 12:59 PM >> >> >> > >>> To: CloudStack DeveloperList >> >> >> > >>> Subject: Re: Functional Specification for the multiple IPs >> >> >> > >>> per >> >> >> NIC >> >> >> > >>> >> >> >> > >>> In basic/shared networks the allocation is bounded by what >> >> >> > >>> is already >> >> >> > >>> "used- up". To prevent tenants from hogging all the >> >> >> > >>> available ips, there needs to be limits. >> >> >> > >>> >> >> >> > >>> On 12/15/12 8:38 AM, "John Kinsella" <j...@stratosec.co> >>wrote: >> >> >> > >>> >> >> >> > >>>> I'd remove the limitation of having 30 IPs per interface. >> >> >> > >>>> Modern OSes can support way more. >> >> >> > >>>> >> >> >> > >>>> Why no support for basic networking? I can see a small >> >> >> > >>>> hosting provider with a basic setup wanting to manage web >> servers... >> >> >> > >>>> >> >> >> > >>>> John >> >> >> > >>>> >> >> >> > >>>> On Dec 14, 2012, at 9:37 AM, Jayapal Reddy Uradi >> >> >> > >>>> <jayapalreddy.ur...@citrix.com> wrote: >> >> >> > >>>> >> >> >> > >>>>> Hi All, >> >> >> > >>>>> >> >> >> > >>>>> Current guest VM by default having one NIC and one IP >> >> >> > >>>>> address >> >> >> > assigned. >> >> >> > >>>>> If your wants extra IP for the guest VM, there no >> >> >> > >>>>> provision >> >> >> from >> >> >> > >>>>> the CS. >> >> >> > >>>>> >> >> >> > >>>>> Using multiple IP address per NIC feature CS can associate >> >> >> > >>>>> IP address for the NIC, user can take that IP and assign >> >> >> > >>>>> it to >> >> >> the VM. >> >> >> > >>>>> >> >> >> > >>>>> Please find the FS for the more details. >> >> >> > >>>>> >> >> >> > >>>>> >> >> >> > >>>>> >> >> >> > >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Multiple+ >> >> >> > IP >> >> >> > >>>>> + >> >> >> > >>>>> a >> >> >> > >>> dd >> >> >> > >>>>> res >> >> >> > >>>>> s+per+NIC >> >> >> > >>>>> >> >> >> > >>>>> Please provide your comments on the FS. >> >> >> > >>>>> >> >> >> > >>>>> >> >> >> > >>>>> Thanks, >> >> >> > >>>>> jayapal >> >> >> > >>>> >> >> >> > >>>> Stratosec - Secure Infrastructure as a Service >> >> >> > >>>> o: 415.315.9385 >> >> >> > >>>> @johnlkinsella >> >> >> > >>>> >> >> >> > >> >> >> >> > >> >> >> >> > > >> >> >> > > Stratosec - Secure Infrastructure as a Service >> >> >> > > o: 415.315.9385 >> >> >> > > @johnlkinsella >> >> >> > > >> >> >> > > >> >> >> > >> >> >> > Stratosec - Secure Infrastructure as a Service >> >> >> > o: 415.315.9385 >> >> >> > @johnlkinsella >> >> > >> > >
