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 > >> > > >