I think it should be fine. Conceptually, 169.254/16 is not supposed
to be routed. The standard protocol is that you can randomly assign
yourself an IP as long as nobody responds to ARP. So the definition
of the subnet is that it's your local subnet. EC2 is funky though.
If you launch an amazon
Hmm. Windows may not work then? Needs testing
On 10/24/13 5:04 PM, "Darren Shepherd" 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 assi
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 n
e-
> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
> Sent: Thursday, October 24, 2013 2:52 PM
> To: dev@cloudstack.apache.org
> Cc: klindg...@godaddy.com
> Subject: Re: Metadata URL location
>
> Alex,
>
> I don't think that's correct. The inst
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 res
> -Original Message-
>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>> Sent: Thursday, October 24, 2013 8:13 AM
>> To: dev@cloudstack.apache.org
>> Cc: klindg...@godaddy.com
>> Subject: Re: Metadata URL location
>>
>> My guess, I
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
On 24-Oct-2013, at 9:21 pm, Darren Shepherd wrote:
> So additionally you need to do
>
> ip addr add dev eth0 169.254.169.254/0
Thanks Kris and Darren. Thats very useful information.
The reason I ask is currently there is a bit of heuristics involved
in obtaining the meta data server IP from the
--Alex
> -Original Message-
> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
> Sent: Thursday, October 24, 2013 8:13 AM
> To: dev@cloudstack.apache.org
> Cc: klindg...@godaddy.com
> Subject: Re: Metadata URL location
>
> My guess, I don't really k
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 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 serve
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, substit
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=CLOUDSTACK&toolti
12 matches
Mail list logo
