incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jayapal Reddy Uradi <jayapalreddy.ur...@citrix.com>
Subject RE: Functional Specification for the multiple IPs per NIC
Date Thu, 14 Feb 2013 14:43:27 GMT
Anthony,

What is the best way to work  on  xenserver "vmops".
 I am writing  new methods in vmops file for security groups rules for the vm secondary ips.
If I add a new method how to call this method from the host.
I am not able to call 'vmops <methodname>  <args>' on the host.

Security groups iptables changes for MIPN:
---------------------------------------------------
In security groups in order to allow VM secondary IPs to reach out  changing the iptables
rules as below.

The current rules are comparing the source/destination of the VM ip and allowing only the
traffic to/from the VM with VM IP.
With MIPN feature VM nic can have multiple IPs. So the iptables rules source/destination ip
option is changed to  IPSET match.
VM ip addresses (primary and secondary) are added to the ipset.

Ex:
-A i-2-61-def -s 10.147.41.238 -m physdev  --physdev-in vif12.0 --physdev-is-bridged -j i-2-61-VM-eg

With ipset:
-A i-2-61-def -m set --set  i-2-61 src   -m physdev  --physdev-in vif12.0 --physdev-is-bridged
-j i-2-61-VM-eg

Also arptables rules for secondary ip addresses are added.

Please let me know if you have any comments.

Thanks,
Jayapal


> -----Original Message-----
> From: Abhinandan Prateek [mailto:Abhinandan.Prateek@citrix.com]
> Sent: Wednesday, January 30, 2013 9:52 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Functional Specification for the multiple IPs per NIC
>
> Jayapal,
>   We should not create multiple APIs for diff outputs, when a param can give
> you control over output from an existing API.
>
> -abhi
>
> On 30/01/13 12:58 AM, "Chiradeep Vittal" <Chiradeep.Vittal@citrix.com>
> wrote:
>
> >
> >
> >On 1/29/13 8:23 AM, "Jayapal Reddy Uradi"
> ><jayapalreddy.uradi@citrix.com>
> >wrote:
> >
> >>
> >>listNicIps/listNicSecondaryIps API  lists  the only the secondary ip
> >>addresses .
> >>do we need to list the both primary and secondary ip addresses in the
> >>list API ?
> >
> >Yes. Why do we need a listNicSecondaryIps API? Why not just enhance
> >listNics?
> >
> >>
> >>The current load balancing  'assignToLoadBalancerRule' API takes list
> >>virtualmachineids  argument and configures the LB for primary IP
> >>addresses.
> >>
> >>To configure the LB for secondary ip addresses adding an optional
> >>argument to API.
> >>The optional argument vmIpaddrs takes the list of  ip addresses of the
> >>corresponding virtualmachineids   vm list parameter.
> >>When vmipaddrs is not passed LB is configured for the VMs primary ip
> >>addreses.
> >
> >I think this can be handled with an enhancement separate from this
> >feature. Let us leave the API as is.
> >
> >>
> >>
> >>Thanks,
> >>Jayapal
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jayapal Reddy Uradi [mailto:jayapalreddy.uradi@citrix.com]
> >>> Sent: Monday, January 28, 2013 9:15 PM
> >>> To: cloudstack-dev@incubator.apache.org
> >>> Subject: RE: Functional Specification for the multiple IPs per NIC
> >>>
> >>> Hi Chiradeep.
> >>>
> >>> Thanks for the review comments.
> >>>
> >>> I will change  API names to 'addIpToNic' and 'removeIpToNic' ,
> >>>update the FS  with API names.
> >>> I will also look into the  meta data  for secondary ip and include
> >>>this section in  the FS.
> >>>
> >>> Regards,
> >>> Jayapal
> >>>
> >>>
> >>>
> >>> > -----Original Message-----
> >>> > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> >>> > Sent: Monday, January 28, 2013 1:05 PM
> >>> > To: cloudstack-dev@incubator.apache.org
> >>> > Subject: Re: Functional Specification for the multiple IPs per NIC
> >>> >
> >>> > I didn't notice the API specification before in the FS.
> >>> > The verb 'associate' is used with the public ip (for static nat),
> >>> > so it will introduce confusion. I prefer "add" or "assign"
> >>> > Similarly, 'unassociate' doesn't make any sense
> >>> >
> >>> > Also, why insist on 'secondary' in the API? A nic cannot be
> >>> > created without any ip addresses (at least currently), so I would
> >>> > leave out the 'secondary' part in the API as well.
> >>> >
> >>> > Last, the instance meta-data makes available the primary ip, the
> >>> > secondary ips should be made available as well.
> >>> > See
> >>> > http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-
> chapter-
> >>> > instanceda
> >>> > ta.html#instancedata-data-categories
> >>> >
> >>> > On 1/18/13 3:40 AM, "Abhinandan Prateek"
> >>> > <Abhinandan.Prateek@citrix.com>
> >>> > wrote:
> >>> >
> >>> > >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
> >>> >>+a
> >>> > dd
> >>> > >>res
> >>> > >>s
> >>> > >>+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
> >>> > +a
> >>> > >>> d
> >>> > >>> >> >> 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/Multipl
> >>> > >>> e+
> >>> > >>> >> >> > 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