incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <Abhinandan.Prat...@citrix.com>
Subject Re: Functional Specification for the multiple IPs per NIC
Date Fri, 18 Jan 2013 11:40:13 GMT
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.uradi@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.Vittal@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.uradi@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.Vittal@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.Xu@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.uradi@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:jlk@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.kannan@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:jlk@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.uradi@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.Vittal@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" <jlk@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.uradi@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
>> >> >
>> >
>


Mime
View raw message