Got what I needed. As below called from xenserver, a method 'default_network_rules' in vmops plugin xe host-call-plugin host-uuid=3231a0d3-1e9f-4fea-8c56-a8c3a02ed1b0 plugin=vmops fn=default_network_rules args:vmName=i-2-18-VM args:vmIP=10.147.41.241 args:vmMAC=06:7a:e4:00:00:09 args:vmID=18
Thanks, Jayapal > -----Original Message----- > From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] > Sent: Friday, February 15, 2013 9:12 AM > To: cloudstack-dev@incubator.apache.org > Cc: Anthony Xu > Subject: Re: Functional Specification for the multiple IPs per NIC > > Jayapal, > Vmops is a plugin that get instrumented into the xenserver host. You need > to invoke the plugin from CirtixResourceBase. Usually the vmops plugin will > invoke one of the script that is on that particular host Again copied by > cloudstack when that host was added. > > Anthony, > It will be good if you can review the changes Jayapal is going to make to > security groups for additional ips. > > -abhi > > On 14/02/13 8:13 PM, "Jayapal Reddy Uradi" > <jayapalreddy.ur...@citrix.com> > wrote: > > >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.prat...@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.vit...@citrix.com> > >> wrote: > >> > >> > > >> > > >> >On 1/29/13 8:23 AM, "Jayapal Reddy Uradi" > >> ><jayapalreddy.ur...@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.ur...@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.vit...@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.prat...@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.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 > >> >>> >>+a > >> >>> > dd > >> >>> > >>res > >> >>> > >>s > >> >>> > >>+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 > >> >>> > +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: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/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 > >> >>> > >>> >> > > >> >>> > >>> > > >> >>> > >> > >> >>> > > > >> >> > >> > > >
