Hmm. Windows may not work then? Needs testing

On 10/24/13 5:04 PM, "Darren Shepherd" <darren.s.sheph...@gmail.com> wrote:

>Chiradeep,
>
>Linux distros set 169.254/16 route on the primary interface.  It's just
>there now.  I'm not sure if that's because of ec2 or if it's always been
>that way, but all modern distros will assign it if you have a standard
>base install.
>
>In the VPC case I think we would have to use network namespaces to bind
>the same IP to multiple NICs.  You could bind the IP to loopback, but
>then it won't ARP.  So since linux distros already have the route, they
>won't send to the gateway.
>
>Yes systemvm will need to be allowed to talk over 169.254, so that's
>needs to change.
>
>Again, I said the reason I thought this wasn't done is because it's hard.
> But still doable.  I'd like to see us do this change.  At least in the
>KVM case, it would be real nice to be able to pickup the standard ubuntu
>(or fedora) cloud qcow and have it run in CloudStack.
>
>Darren
>
>> On Oct 24, 2013, at 3:57 PM, Chiradeep Vittal
>><chiradeep.vit...@citrix.com> wrote:
>> 
>> For the VPC virtual router case this would this have to be done on all
>> guest interfaces?
>> Could we alias localhost on the VR to 169.254.169.254?
>> For shared networks, basic zone and networks where the VR is not the
>> default gateway, we would have to send another (169.254.0.0/16) route in
>> the DHCP response to point to the VR.
>> 
>> Additionally in basic zone the anti-spoof filters in dom0 would have to
>>be
>> adjusted to let 169.254.169.254 addresses
>> 
>>> On 10/24/13 8:51 AM, "Darren Shepherd" <darren.s.sheph...@gmail.com>
>>>wrote:
>>> 
>>> So additionally you need to do
>>> 
>>> ip addr add dev eth0 169.254.169.254/0
>>> 
>>> On Thu, Oct 24, 2013 at 8:29 AM, Kris G. Lindgren
>>><klindg...@godaddy.com>
>>> wrote:
>>>> You would also need to supernet 169.254.169.254 on the virtual router
>>>> (assigning it as 169.254.169.254 netmask 0.0.0.0 on eth0) that way it
>>>> will
>>>> still arp to servers that are calling it that have real ip addresses.
>>>> 
>>>> Additionally we had some other iptables rules in there that would
>>>>change
>>>> the the ip address of the incoming request to metadata based upon the
>>>> mac
>>>> address that was hitting it.  This was to prevent spoofing of another
>>>> vm's
>>>> IP and getting someone else's metadata (at least in our metadata
>>>> implementation we keyed off of the VM IP calling into metadata).  This
>>>> also allowed a user to set whatever ipaddress they wanted, but as long
>>>> as
>>>> the mac address was the same and they still had a zeroconfig route on
>>>> the
>>>> VM, they still got only their metadata.
>>>> ____________________________________________
>>>> 
>>>> Kris Lindgren
>>>> Senior Linux Systems Engineer
>>>> GoDaddy, LLC.
>>>> 
>>>> 
>>>> This email message and any attachment(s) hereto are intended for use
>>>> only
>>>> by its intended recipient(s) and may contain confidential information.
>>>> If
>>>> you have received this email in error, please immediately notify the
>>>> sender and permanently delete the original and any copy of this
>>>>message
>>>> and its attachments.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 10/24/13 9:12 AM, "Darren Shepherd" <darren.s.sheph...@gmail.com>
>>>> wrote:
>>>> 
>>>>> My guess, I don't really know, would be because its hard.  The VR
>>>>>uses
>>>>> link local for the control network so 169.254/16 is bound to the
>>>>>wrong
>>>>> nic.  To fix this you just need some ip routing magic in linux
>>>>>(credit
>>>>> goes to Kris Lindgren who showed me how to do this).  Add the below
>>>>>to
>>>>> a file, substitute eth0 for the guest network nic, run "ip -b <FILE>"
>>>>> The below effectively creates a routing table dedicated to the IP
>>>>> 169.254.169.254 that sets it default route to go out the guest
>>>>>network
>>>>> nic.
>>>>> 
>>>>> rule add from 169.254.169.254 table 70
>>>>> rule add to 169.254.169.254 dev eth0 table 70
>>>>> route flush table 70
>>>>> route add default dev eth0 src 169.254.169.254 table 70
>>>>> route flush cache
>>>>> 
>>>>> Darren
>>>>> 
>>>>> On Thu, Oct 24, 2013 at 6:10 AM, Shanker Balan
>>>>> <shanker.ba...@shapeblue.com> wrote:
>>>>>> Hi Guys,
>>>>>> 
>>>>>> CloudStack metadata services are on the default gateway while on
>>>>>>EC2,
>>>>>> its at 169.254.169.254. Am curious to know why CloudStack does not
>>>>>> use a link local address for meta data services.
>>>>>> 
>>>>>> A search of the Wiki
>>>>>> 
>>>>>>(https://cwiki.apache.org/confluence/dosearchsite.action?where=CLOUDS
>>>>>>TA
>>>>>> CK
>>>>>> 
>>>>>>&tooltip=Type+ALL%3A+in+your+query+to+search+all+of+Confluence&spaceS
>>>>>>ea
>>>>>> rc
>>>>>> h=true&queryString=metadata) didn¹t seem to list any doc related to
>>>>>>the
>>>>>> design of this service.
>>>>>> 
>>>>>> TIA.
>>>>>> 
>>>>>> --
>>>>>> @shankerbalan
>>>>>> 
>>>>>> M: +91 98860 60539 | O: +91 (80) 67935867
>>>>>> shanker.ba...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue
>>>>>> ShapeBlue Services India LLP, 22nd floor, Unit 2201A, World Trade
>>>>>> Centre, Bangalore - 560 055
>>>>>> 
>>>>>> CloudStack Bootcamp Training on 27/28 November, Bangalore
>>>>>> http://www.shapeblue.com/cloudstack-training/
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> This email and any attachments to it may be confidential and are
>>>>>> intended solely for the use of the individual to whom it is
>>>>>>addressed.
>>>>>> Any views or opinions expressed are solely those of the author and
>>>>>>do
>>>>>> not necessarily represent those of Shape Blue Ltd or related
>>>>>>companies.
>>>>>> If you are not the intended recipient of this email, you must
>>>>>>neither
>>>>>> take any action based upon its contents, nor copy or show it to
>>>>>>anyone.
>>>>>> Please contact the sender if you believe you have received this
>>>>>>email
>>>>>> in
>>>>>> error. Shape Blue Ltd is a company incorporated in England & Wales.
>>>>>> ShapeBlue Services India LLP is a company incorporated in India and
>>>>>>is
>>>>>> operated under license from Shape Blue Ltd. Shape Blue Brasil
>>>>>> Consultoria Ltda is a company incorporated in Brasil and is operated
>>>>>> under license from Shape Blue Ltd. ShapeBlue is a registered
>>>>>>trademark.
>> 

Reply via email to