Re: [Openstack] nova/quantum/ovs configuration conundrum

[Choe, Cheng-Dae]

currently.
l3_agent designed as serve all tenant's traffic or
per router per l3_agent by specify router_id in l3_agent.ini

so in current architecture. if you want deploy as production scale.
I think l3_agent must be dedicated to one router 

or the another solution is needed(nvp, midonet, cisco ...) 

2012. 11. 9., 오후 3:04, Sina Sadeghi  작성:

> "I followed the instructions to add a route from 
> http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html
>  but I don't immediately see how the route add helped here - but it has 
> raised an eyebrow."
> 
> Tell me about it!
> 
> We wanted to use Quantum mostly so we could avoid being forced to upgrade 
> from nova-network later on. Once again the difference between trunk (dev) and 
> stable (ops) kills new OpenStack features for early production adopters. 
> There is no way we can offer this to our customers. Are we expected to add a 
> new route for every subnet our customers create, across every compute node, 
> on the fly (including esoteric quantum port-list commands)?
> 
> As for the idea of having one quantum-l3-agent that NATs traffic for many 
> compute nodes, I wasn't aware the concept of retro chic applied to network 
> topologies :(
> 
> I shudder to think how this would operate at scale, so it looks like we will 
> be sticking to our nova-network VLAN configuration.
> 
> 
> --
> Sina Sadeghi
> Lead Cloud Engineer
> 
> Aptira Pty Ltd
> 1800 APTIRA
> aptira.com
> Follow @aptira
> 
> On 08/11/12 22:54, Kevin Jackson wrote:
>> Hi Stephen, 
>> This is what I get... (note change of namespace etc as this machine is a VM 
>> that was recreated).
>> 
>> root@openstack:~# ip netns list
>> qdhcp-3f0a3d53-f3a4-4da8-a5e0-1a97b6e51424
>> qrouter-f26858db-3ae8-431b-86a7-edab80834586
>> 
>> root@openstack:~# ip netns exec qrouter-f26858db-3ae8-431b-86a7-edab80834586 
>> wget http://172.16.0.210:8775/
>> --2012-11-08 10:52:11--  http://172.16.0.210:8775/
>> Connecting to 172.16.0.210:8775... failed: No route to host.
>> 
>> root@openstack:~# ip netns exec qrouter-f26858db-3ae8-431b-86a7-edab80834586 
>> ip r  
>> default via 172.16.1.254 dev qg-c396e75e-38 
>> 10.5.5.0/24 dev qr-031aafac-19  proto kernel  scope link  src 10.5.5.1 
>> 172.16.1.0/24 dev qg-c396e75e-38  proto kernel  scope link  src 172.16.1.10 
>> 
>> So it is a problem between my router and the physical network... That 
>> 172.16.1.0/24 is an "ext-net" network created with an external router.  When 
>> I spin my instances up I use the 10.5.5.0/24 "int-net" network.
>> 
>> I followed the instructions to add a route from 
>> http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html
>>  but I don't immediately see how the route add helped here - but it has 
>> raised an eyebrow.
>> 
>> The output of the port-list gave me 172.16.1.10 to use as the $ROUTER_GW_IP 
>> - which is odd as that IP was set as my external floating range start IP.  
>> Doing a traceroute to the 172.16.0.201 address from the router namespace 
>> went via 172.16.1.10... so I've some things to play with for the time 
>> being...
>> 
>> Thanks for your help so far.  Is the Guardian looking at OpenStack for any 
>> projects (I'm from TMG)?
>> 
>> Cheers,
>> Kev
>> 
>> 
>> On 8 November 2012 10:49, Stephen Gran  wrote:
>> Hi,
>> 
>> 
>> On Thu, 2012-11-08 at 10:02 +, Kevin Jackson wrote:
>>> Thanks for that - the namspace thing is starting to make sense.
>>> So I see this rule in there now:
>>> 
>>> Chain quantum-l3-agent-PREROUTING (1 references)
>>>  pkts bytes target prot opt in out source   
>>> destination 
>>>62  3720 DNAT   tcp  --  *  *   0.0.0.0/0
>>> 169.254.169.254  tcp dpt:80 to:172.16.0.201:8775
>>> 
>>> But I never see a connection being made when I spin up an instance.  The 
>>> instance reports no route to host.
>> 
>> It's unclear at this point if the problem is that your instance can't reach 
>> it's gateway (the quantum router), or if the quantum router can't reach the 
>> metadata server.
>> 
>> try:
>> ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 wget 
>> http://172.16.0.201:8775/
>> 
>> To rule out the latter so you know where to concentrate your efforts.
>> 
>> -- 
>> Stephen Gran
>> Senior Systems Integrator - guardian.co.uk
>> Please consider the environment before printing this email.
>> --
>> Visit guardian.co.uk - website of the year
>>  
>> www.guardian.co.ukwww.observer.co.uk www.guardiannews.com 
>>  
>> On your mobile, visit m.guardian.co.uk or download the Guardian
>> iPhone app www.guardian.co.uk/iphone and iPad edition 
>> www.guardian.co.uk/iPad 
>>  
>> Save up to 37% by subscribing to the Guardian and Observer - choose the 
>> papers you want and get full digital access. 
>> Visit guardian.co.uk/subscribe
>>  
>> -

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Sina Sadeghi]

  
  
"I followed the instructions to add a
  route from http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html
  but I don't immediately see how the route add helped here - but it
  has raised an eyebrow."
  
  Tell me about it!
  
  We wanted to use Quantum mostly so we could avoid being forced to
  upgrade from nova-network later on. Once again the difference
  between trunk (dev) and stable (ops) kills new OpenStack features
  for early production adopters. There is no way we can offer this
  to our customers. Are we expected to add a new route for every
  subnet our customers create, across every compute node, on the fly
  (including esoteric quantum port-list commands)?
  
  As for the idea of having one quantum-l3-agent that NATs traffic
  for many compute nodes, I wasn't aware the concept of retro chic
  applied to network topologies :(
  
  I shudder to think how this would operate at scale, so it looks
  like we will be sticking to our nova-network VLAN configuration.
  
  
  --
  Sina Sadeghi
  Lead Cloud Engineer
  
  Aptira Pty Ltd
  1800 APTIRA
  aptira.com
  Follow @aptira

  
  On 08/11/12 22:54, Kevin Jackson wrote:

Hi Stephen, 
  This is what I get... (note change of namespace etc as this
  machine is a VM that was recreated).
  
  root@openstack:~# ip netns list
  qdhcp-3f0a3d53-f3a4-4da8-a5e0-1a97b6e51424
  qrouter-f26858db-3ae8-431b-86a7-edab80834586
  
  root@openstack:~# ip netns exec
  qrouter-f26858db-3ae8-431b-86a7-edab80834586 wget http://172.16.0.210:8775/
  --2012-11-08 10:52:11--  http://172.16.0.210:8775/
  Connecting to 172.16.0.210:8775... failed: No route to host.
  
  root@openstack:~# ip netns exec
  qrouter-f26858db-3ae8-431b-86a7-edab80834586 ip
  r  
  default via 172.16.1.254 dev qg-c396e75e-38 
  10.5.5.0/24 dev qr-031aafac-19  proto
  kernel  scope link  src 10.5.5.1 
  172.16.1.0/24 dev qg-c396e75e-38  proto
  kernel  scope link  src 172.16.1.10 
  
  So it is a problem between my router and the physical network...
  That 172.16.1.0/24 is an "ext-net" network
  created with an external router.  When I spin my instances up I
  use the 10.5.5.0/24 "int-net" network.
  
  I followed the instructions to add a route from http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html
  but I don't immediately see how the route add helped here - but it
  has raised an eyebrow.
  
  The output of the port-list gave me 172.16.1.10 to use as the
  $ROUTER_GW_IP - which is odd as that IP was set as my external
  floating range start IP.  Doing a traceroute to the 172.16.0.201
  address from the router namespace went via 172.16.1.10... so I've
  some things to play with for the time being...
  
  Thanks for your help so far.  Is the Guardian looking at OpenStack
  for any projects (I'm from TMG)?
  
  Cheers,
  Kev
  

On 8 November 2012 10:49, Stephen Gran
  
  wrote:
  

  Hi,
  

On Thu, 2012-11-08 at 10:02 +, Kevin Jackson wrote:
 Thanks for that - the namspace
  thing is starting to make sense.
  So I see this rule in there now:
  
  Chain quantum-l3-agent-PREROUTING (1 references)
   pkts bytes target prot opt in out
  source   destination 
     62  3720 DNAT   tcp  --  *  *   0.0.0.0/0   
  169.254.169.254  tcp dpt:80 to:172.16.0.201:8775
  
  But I never see a connection being made when I spin up
  an instance.  The instance reports no route to host.


  
  It's unclear at this point if the problem is that your
  instance can't reach it's gateway (the quantum router), or
  if the quantum router can't reach the metadata server.
  
  try:
  ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6
  wget http://172.16.0.201:8775/
  
  To rule out the latter so you know where to concentrate
  your efforts.
  

  

  

  -- 
Stephen Gran
Senior Systems Integrator - guardian.co.uk


  

 

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Kevin Jackson]

Hi Stephen,
This is what I get... (note change of namespace etc as this machine is a VM
that was recreated).

root@openstack:~# ip netns list
qdhcp-3f0a3d53-f3a4-4da8-a5e0-1a97b6e51424
qrouter-f26858db-3ae8-431b-86a7-edab80834586

root@openstack:~# ip netns exec
qrouter-f26858db-3ae8-431b-86a7-edab80834586 wget http://172.16.0.210:8775/
--2012-11-08 10:52:11--  http://172.16.0.210:8775/
Connecting to 172.16.0.210:8775... failed: No route to host.

root@openstack:~# ip netns exec
qrouter-f26858db-3ae8-431b-86a7-edab80834586 ip r
default via 172.16.1.254 dev qg-c396e75e-38
10.5.5.0/24 dev qr-031aafac-19  proto kernel  scope link  src 10.5.5.1
172.16.1.0/24 dev qg-c396e75e-38  proto kernel  scope link  src 172.16.1.10

So it is a problem between my router and the physical network... That
172.16.1.0/24 is an "ext-net" network created with an external router.
When I spin my instances up I use the 10.5.5.0/24 "int-net" network.

I followed the instructions to add a route from
http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_metadata.htmlbut
I don't immediately see how the route add helped here - but it has
raised an eyebrow.

The output of the port-list gave me 172.16.1.10 to use as the $ROUTER_GW_IP
- which is odd as that IP was set as my external floating range start IP.
Doing a traceroute to the 172.16.0.201 address from the router namespace
went via 172.16.1.10... so I've some things to play with for the time
being...

Thanks for your help so far.  Is the Guardian looking at OpenStack for any
projects (I'm from TMG)?

Cheers,
Kev


On 8 November 2012 10:49, Stephen Gran  wrote:

> **
> Hi,
>
>
> On Thu, 2012-11-08 at 10:02 +, Kevin Jackson wrote:
>
> Thanks for that - the namspace thing is starting to make sense.
> So I see this rule in there now:
>
> Chain quantum-l3-agent-PREROUTING (1 references)
>  pkts bytes target prot opt in out source
> destination
>62  3720 DNAT   tcp  --  *  *   0.0.0.0/0
> 169.254.169.254  tcp dpt:80 to:172.16.0.201:8775
>
> But I never see a connection being made when I spin up an instance.  The
> instance reports no route to host.
>
>
> It's unclear at this point if the problem is that your instance can't
> reach it's gateway (the quantum router), or if the quantum router can't
> reach the metadata server.
>
> try:
> ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 wget
> http://172.16.0.201:8775/
>
> To rule out the latter so you know where to concentrate your efforts.
>
>   --
> Stephen Gran
> Senior Systems Integrator - guardian.co.uk
>
>   Please consider the environment before printing this email.
> --
> Visit guardian.co.uk - website of the year
>  www.guardian.co.ukwww.observer.co.uk www.guardiannews.com
>
> On your mobile, visit m.guardian.co.uk or download the Guardian
> iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad
>
> Save up to 37% by subscribing to the Guardian and Observer - choose the 
> papers you want and get full digital access.
> Visit guardian.co.uk/subscribe
>
> -
> This e-mail and all attachments are confidential and may also
> be privileged. If you are not the named recipient, please notify
> the sender and delete the e-mail and all attachments immediately.
> Do not disclose the contents to another person. You may not use
> the information for any purpose, or store, or copy, it in any way.
>
> Guardian News & Media Limited is not liable for any computer
> viruses or other material transmitted with or as part of this
> e-mail. You should employ virus checking software.
>
> Guardian News & Media Limited
>
> A member of Guardian Media Group plc
> Registered Office
> PO Box 68164
> Kings Place
> 90 York Way
> London
> N1P 2AP
>
> Registered in England Number 908396
>
>


-- 
Kevin Jackson
@itarchitectkev
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Stephen Gran]

Hi,

On Thu, 2012-11-08 at 10:02 +, Kevin Jackson wrote:

> Thanks for that - the namspace thing is starting to make sense.
> So I see this rule in there now:
> 
> Chain quantum-l3-agent-PREROUTING (1 references)
>  pkts bytes target prot opt in out source
> destination 
>62  3720 DNAT   tcp  --  *  *   0.0.0.0/0
> 169.254.169.254  tcp dpt:80 to:172.16.0.201:8775
> 
> But I never see a connection being made when I spin up an instance.
> The instance reports no route to host.


It's unclear at this point if the problem is that your instance can't
reach it's gateway (the quantum router), or if the quantum router can't
reach the metadata server.

try:
 ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 wget
http://172.16.0.201:8775/

To rule out the latter so you know where to concentrate your efforts.
-- 
Stephen Gran
Senior Systems Integrator - guardian.co.uk

Please consider the environment before printing this email.
--
Visit guardian.co.uk - website of the year
 
www.guardian.co.ukwww.observer.co.uk www.guardiannews.com 
 
On your mobile, visit m.guardian.co.uk or download the Guardian
iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad 
 
Save up to 37% by subscribing to the Guardian and Observer - choose the papers 
you want and get full digital access. 
Visit guardian.co.uk/subscribe
 
-
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
 
Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.
 
Guardian News & Media Limited
 
A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP
 
Registered in England Number 908396
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Kevin Jackson]

Thanks for that - the namspace thing is starting to make sense.
So I see this rule in there now:

Chain quantum-l3-agent-PREROUTING (1 references)
 pkts bytes target prot opt in out source
destination
   62  3720 DNAT   tcp  --  *  *   0.0.0.0/0
169.254.169.254  tcp dpt:80 to:172.16.0.201:8775

But I never see a connection being made when I spin up an instance.  The
instance reports no route to host.


My environment is a single server (its a VM under VirtualBox) - am I
complicating things by having this as an all in one box - is the
use_namespace option adding to my woes and is this just a scenario that
doesn't make sense (although for someone investigating/learning OpenStack
these single instance environments have been valuable).

Cheers,
Kev


On 7 November 2012 18:21, Salvatore Orlando  wrote:

> Kevin is correct; as your're running IP namespaces, you'll need to look
> for iptables in that namespace.
> The metadata settings however are visible in the log extract you posted.
> It seems your metadata server is sitting at 172.16.0.201:8775
> I guess you've already ensured that endpoint is reachable from the router
> (a wget execute in the router namespace will prove that).
>
> Also, metadata is one of those (few) features which in Quantum come with
> strings attached. You can find more info on this in the admin guide [1].
> The link to the page where metadata are discussed reported below, just in
> case you haven't already seen it.
>
> Salvatore
>
>
> [1]
> http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html
>
> On 7 November 2012 19:00, Stephen Gran wrote:
>
>> **
>> On Wed, 2012-11-07 at 16:02 +, Kevin Jackson wrote:
>>
>> Heyup good folk of OpenStack,
>> I'm having the same issue as Sina.  My configuration seems to look OK (I
>> have an instance, with IP that can ping its default route to on an internal
>> network) but I get the failure to contact the metadata server with the
>> explanation that Sina gave.
>>
>> In my /var/log/quantum/l3_agent.log I have the following:
>> http://paste.openstack.org/show/24801/
>> There's also a paste of an iptables output that I would've expected to
>> see the DNAT rules in.
>>
>> What am I missing?
>>
>>
>> You're not looking in the correct network namespace:
>>
>> ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 iptables -L -v
>> -t nat
>> ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 ip r
>>
>> Cheers,
>>
>> --
>> Stephen Gran
>> Senior Systems Integrator - guardian.co.uk
>>
>>   Please consider the environment before printing this email.
>> --
>> Visit guardian.co.uk - website of the year
>>  www.guardian.co.ukwww.observer.co.uk www.guardiannews.com
>>
>> On your mobile, visit m.guardian.co.uk or download the Guardian
>> iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad
>>
>> Save up to 37% by subscribing to the Guardian and Observer - choose the 
>> papers you want and get full digital access.
>> Visit guardian.co.uk/subscribe
>>
>> -
>> This e-mail and all attachments are confidential and may also
>> be privileged. If you are not the named recipient, please notify
>> the sender and delete the e-mail and all attachments immediately.
>> Do not disclose the contents to another person. You may not use
>> the information for any purpose, or store, or copy, it in any way.
>>
>> Guardian News & Media Limited is not liable for any computer
>> viruses or other material transmitted with or as part of this
>> e-mail. You should employ virus checking software.
>>
>> Guardian News & Media Limited
>>
>> A member of Guardian Media Group plc
>> Registered Office
>> PO Box 68164
>> Kings Place
>> 90 York Way
>> London
>> N1P 2AP
>>
>> Registered in England Number 908396
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Kevin Jackson
@itarchitectkev
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Salvatore Orlando]

Kevin is correct; as your're running IP namespaces, you'll need to look for
iptables in that namespace.
The metadata settings however are visible in the log extract you posted.
It seems your metadata server is sitting at 172.16.0.201:8775
I guess you've already ensured that endpoint is reachable from the router
(a wget execute in the router namespace will prove that).

Also, metadata is one of those (few) features which in Quantum come with
strings attached. You can find more info on this in the admin guide [1].
The link to the page where metadata are discussed reported below, just in
case you haven't already seen it.

Salvatore


[1]
http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent_metadata.html

On 7 November 2012 19:00, Stephen Gran  wrote:

> **
> On Wed, 2012-11-07 at 16:02 +, Kevin Jackson wrote:
>
> Heyup good folk of OpenStack,
> I'm having the same issue as Sina.  My configuration seems to look OK (I
> have an instance, with IP that can ping its default route to on an internal
> network) but I get the failure to contact the metadata server with the
> explanation that Sina gave.
>
> In my /var/log/quantum/l3_agent.log I have the following:
> http://paste.openstack.org/show/24801/
> There's also a paste of an iptables output that I would've expected to see
> the DNAT rules in.
>
> What am I missing?
>
>
> You're not looking in the correct network namespace:
>
> ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 iptables -L -v
> -t nat
> ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 ip r
>
> Cheers,
>
> --
> Stephen Gran
> Senior Systems Integrator - guardian.co.uk
>
>   Please consider the environment before printing this email.
> --
> Visit guardian.co.uk - website of the year
>  www.guardian.co.ukwww.observer.co.uk www.guardiannews.com
>
> On your mobile, visit m.guardian.co.uk or download the Guardian
> iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad
>
> Save up to 37% by subscribing to the Guardian and Observer - choose the 
> papers you want and get full digital access.
> Visit guardian.co.uk/subscribe
>
> -
> This e-mail and all attachments are confidential and may also
> be privileged. If you are not the named recipient, please notify
> the sender and delete the e-mail and all attachments immediately.
> Do not disclose the contents to another person. You may not use
> the information for any purpose, or store, or copy, it in any way.
>
> Guardian News & Media Limited is not liable for any computer
> viruses or other material transmitted with or as part of this
> e-mail. You should employ virus checking software.
>
> Guardian News & Media Limited
>
> A member of Guardian Media Group plc
> Registered Office
> PO Box 68164
> Kings Place
> 90 York Way
> London
> N1P 2AP
>
> Registered in England Number 908396
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Stephen Gran]

On Wed, 2012-11-07 at 16:02 +, Kevin Jackson wrote:

> Heyup good folk of OpenStack,
> I'm having the same issue as Sina.  My configuration seems to look OK
> (I have an instance, with IP that can ping its default route to on an
> internal network) but I get the failure to contact the metadata server
> with the explanation that Sina gave.
> 
> In my /var/log/quantum/l3_agent.log I have the following:
> http://paste.openstack.org/show/24801/
> There's also a paste of an iptables output that I would've expected to
> see the DNAT rules in.
> 
> What am I missing?


You're not looking in the correct network namespace:

ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 iptables -L
-v -t nat
ip netns exec qrouter-61245d6f-1195-4ca0-ba08-f0636f7d44c6 ip r

Cheers,
-- 
Stephen Gran
Senior Systems Integrator - guardian.co.uk

Please consider the environment before printing this email.
--
Visit guardian.co.uk - website of the year
 
www.guardian.co.ukwww.observer.co.uk www.guardiannews.com 
 
On your mobile, visit m.guardian.co.uk or download the Guardian
iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad 
 
Save up to 37% by subscribing to the Guardian and Observer - choose the papers 
you want and get full digital access. 
Visit guardian.co.uk/subscribe
 
-
This e-mail and all attachments are confidential and may also
be privileged. If you are not the named recipient, please notify
the sender and delete the e-mail and all attachments immediately.
Do not disclose the contents to another person. You may not use
the information for any purpose, or store, or copy, it in any way.
 
Guardian News & Media Limited is not liable for any computer
viruses or other material transmitted with or as part of this
e-mail. You should employ virus checking software.
 
Guardian News & Media Limited
 
A member of Guardian Media Group plc
Registered Office
PO Box 68164
Kings Place
90 York Way
London
N1P 2AP
 
Registered in England Number 908396
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Kevin Jackson]

Heyup good folk of OpenStack,
I'm having the same issue as Sina.  My configuration seems to look OK (I
have an instance, with IP that can ping its default route to on an internal
network) but I get the failure to contact the metadata server with the
explanation that Sina gave.

In my /var/log/quantum/l3_agent.log I have the following:
http://paste.openstack.org/show/24801/
There's also a paste of an iptables output that I would've expected to see
the DNAT rules in.

What am I missing?

Cheers,
Kev


On 7 November 2012 14:35, Choe, Cheng-Dae  wrote:

> - DNAT rule to metadata server is done by l3_agent. but your node
> configuration has no l3_agent
> - and metadata_ip configuration can find l3_agent.ini.
>
> 2012. 11. 7., 오후 9:15, Sina Sadeghi  작성:
>
>  Hello all,
>
> I thought I would giv
> e quantum a shot and I've got a 50-60% working configuration, but having
> trouble understanding where to go from here as the docs are pretty sparse.
>
>
> Ubuntu 12.04.1 + "ubuntu cloud archive" folsom repo
>
> node A: nova-api, nova-scheduler, quantum-server, quantum-plug
> in-openvswitch
> node B: nova-compute, nova-api-metadata, quantum-dhcp-agent, quantum-plug
> in-openvswitch-agent
> node C: nova-compute,
> nova-api-metadata, quantum-dhcp-agent, quantum-plugin-openvswitch-agent
>
> configured as follows:
>
> quantum.conf:
> ...
> core_plugin =
> quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
> ...
>
> ovs_quantum_plugin.ini:
> ...
> tenant_network_type=vlan
> network_vlan_ranges = default:2000:3999
> integration_bridge = br-int
> bridge_mappings = default:br-eth3
> ...
>
> node B,C `ovs-vstl list-br`:
> br-eth3
> br-int
>
> node B,C `ovs-vsctl list-ports br-int`:
> int-br-eth3 (created by quantum?)
>
> node B,C `ovs-vsctl list-ports br-eth3`:
> eth3 (added by me)
> phy-br-eth3 (created by quantum?)
>
> eth3 is a NIC which is connected to a switchport accepting VLAN
> 2000:3999. It has no IP assigned currently.
>
> When I start the 12.04 ubuntu "cloud-image" in the dashboard, it
> successfully boots and obtains an IP address as seen in the co
> nsole output:
> cloud-init-nonet waiting 120 seconds for a network device.
>
> ci-info: lo: 1 127.0.0.1   255.0.0.0   .
> ci-info: eth0  : 1 192.168.253.5   255.255.255.0   fa:16:3e:80:33:71
> ci-info: route-0: 0.0.0.0 192.168.253.1   0.0.0.0 eth0   UG
> ci-info: route-1: 192.168.253.0   0.0.0.0 255.255.255.0   eth0   U
>
> However, immediately after that output I see this
>
> 2012-11-07 11:27:29,598 - util.py[WARNING]: '
> http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]:
> url error [[Errno 113] No route to host]
>
> which runs until it times out.
>
> In older versions of
> OpenStack, when I ran 'iptables-save | grep 169.254.169.254' on a 
> metadataserver I was used to seeing a rule show up
> which translated that 169 address to the variable assigned by metadata_host
> in nova.conf, but I note that rule doesn't show up in this version of
> nova? I added the old rule in (to see what would happen) but the result
> was the same, still no route to host.
>
>
> What steps do I need to take here to allow my instance to retrieve its
> metadata? Is my quantum misconfigured somehow? Perhaps
> I need to go back and reconfigure my switch port (for example, there is
> no real 192.168.253.1 gw, but does there need to be for the instance to
> simply fetch metdata)? After that, what steps do I need to take to get
> the VM connected to the rest of the world? Is the quantum-l3-agent the only
> real choice right now?
>
> Thx.
>
> --
>
> --
> *Sina Sadeghi*
> Lead Cloud Engineer
> 
>
> *Aptira Pty Ltd*
> 1800 APTIRA
> aptira.com 
> Follow @aptira 
>
>  ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Kevin Jackson
@itarchitectkev
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] nova/quantum/ovs configuration conundrum

[Choe, Cheng-Dae]

- DNAT rule to metadata server is done by l3_agent. but your node configuration 
has no l3_agent
- and metadata_ip configuration can find l3_agent.ini.

2012. 11. 7., 오후 9:15, Sina Sadeghi  작성:

> Hello all,
> 
> I thought I would give quantum a shot and I've got a 50-60% working 
> configuration, but having trouble understanding where to go from here as the 
> docs are pretty sparse.
> 
> Ubuntu 12.04.1 + "ubuntu cloud archive" folsom repo
> 
> node A: nova-api, nova-scheduler, quantum-server, quantum-plugin-openvswitch
> node B: nova-compute, nova-api-metadata, quantum-dhcp-agent, 
> quantum-plugin-openvswitch-agent
> node C: nova-compute, nova-api-metadata, quantum-dhcp-agent, 
> quantum-plugin-openvswitch-agent
> 
> configured as follows:
> 
> quantum.conf:
> ...
> core_plugin = 
> quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
> ...
> 
> ovs_quantum_plugin.ini:
> ...
> tenant_network_type=vlan
> network_vlan_ranges = default:2000:3999
> integration_bridge = br-int
> bridge_mappings = default:br-eth3
> ...
> 
> node B,C `ovs-vstl list-br`:
> br-eth3
> br-int
> 
> node B,C `ovs-vsctl list-ports br-int`:
> int-br-eth3 (created by quantum?)
> 
> node B,C `ovs-vsctl list-ports br-eth3`:
> eth3 (added by me)
> phy-br-eth3 (created by quantum?)
> 
> eth3 is a NIC which is connected to a switchport accepting VLAN 2000:3999. It 
> has no IP assigned currently.
> 
> When I start the 12.04 ubuntu "cloud-image" in the dashboard, it successfully 
> boots and obtains an IP address as seen in the console output:
> cloud-init-nonet waiting 120 seconds for a network device.
> 
> ci-info: lo: 1 127.0.0.1   255.0.0.0   .
> ci-info: eth0  : 1 192.168.253.5   255.255.255.0   fa:16:3e:80:33:71
> ci-info: route-0: 0.0.0.0 192.168.253.1   0.0.0.0 eth0   UG
> ci-info: route-1: 192.168.253.0   0.0.0.0 255.255.255.0   eth0   U
> 
> However, immediately after that output I see this
> 
> 2012-11-07 11:27:29,598 - util.py[WARNING]: 
> 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]: 
> url   error [[Errno 
> 113] No route to host]
> 
> which runs until it times out.
> 
> In older versions of OpenStack, when I ran 'iptables-save | grep 
> 169.254.169.254' on a metadata server I was used to seeing a rule show up 
> which translated that 169 address to the variable assigned by metadata_host 
> in nova.conf, but I note that rule doesn't show up in this version of nova? I 
> added the old rule in (to see what would happen) but the result was the same, 
> still no route to host.
> 
> What steps do I need to take here to allow my instance to retrieve its 
> metadata? Is my quantum misconfigured somehow? Perhaps I need to go back and 
> reconfigure my switch port (for example, there is no real 192.168.253.1 gw, 
> but does there need to be for the instance to simply fetch metdata)? After 
> that, what steps do I need to take to get the VM connected to the rest of the 
> world? Is the quantum-l3-agent the only real choice right now?
> 
> Thx.
> 
> -- 
> 
> --
> Sina Sadeghi
> Lead Cloud Engineer
> 
> Aptira Pty Ltd
> 1800 APTIRA
> aptira.com
> Follow @aptira
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] nova/quantum/ovs configuration conundrum

[Sina Sadeghi]

  
  
Hello all,
  
  I thought I would give quantum a
  shot and I've got a 50-60% working configuration, but having
trouble understanding where to go from here as the docs
are pretty sparse.
  
  Ubuntu 12.04.1 + "ubuntu cloud
archive" folsom repo
  
  node A: nova-api, nova-scheduler,
quantum-server, quantum-plugin-openvswitch
  node B: nova-compute,
nova-api-metadata, quantum-dhcp-agent, quantum-plugin-openvswitch-agent
node C: nova-compute, nova-api-metadata,
quantum-dhcp-agent,
quantum-plugin-openvswitch-agent
  
  configured as
  follows:
  
  quantum.conf:
...
  core_plugin =
quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
  ...
  
  ovs_quantum_plugin.ini:
  ...
  tenant_network_type=vlan
  network_vlan_ranges
  =
  default:2000:3999
  integration_bridge
  = br-int
  bridge_mappings
  =
  default:br-eth3
  ...
  
  node
  B,C `ovs-vstl
  list-br`:
  br-eth3
  br-int
  
  node
  B,C
  `ovs-vsctl
  list-ports
  br-int`:
  int-br-eth3
  (created by
  quantum?)
  
node
  B,C
  `ovs-vsctl
  list-ports
  br-eth3`:
  eth3
  (added by me)
  phy-br-eth3
  (created by
  quantum?)
  
  eth3
  is a
  NIC which is
  connected to a
  switchport
  accepting
  VLAN
  2000:3999. It
  has no IP
  assigned
  currently.
  
  When I start the
 

Re: [Openstack] Nova + Quantum + OVS

[Trinath Somanchi]

Hi-

Thanks a lot for the reply..

Its working now...
On Jul 18, 2012 6:35 PM, "Nirbhay Tomar" 
wrote:

> Hi Trinath,
>
> Have you checked that your quantum is making related gw and tap
> interfaces when your vm goes up.
> When you create a network and create first vm associated with it,
> there should be a gw and tap interface created and
> first ip of your new network is assigned to that gw interface.
>
> if you getting further problems, elaborate whole scenario of your
> controller.
>
> // Nirbhay
>
> On Wed, Jul 18, 2012 at 4:29 PM, Trinath Somanchi
>  wrote:
> > Hi-
> >
> > I have set up a controller- node setup with openstack, quantum and
> > OpenVswitch.
> >
> > I'm able to create the virtual machines in the node.
> >
> > The eth1 interface of controller and node are attached to the OVS br-int.
> >
> > In the node, 'ovs-vsctl show'  show the port and interface binding of the
> > newly created VM.
> >
> > IP 192.168.3.1, 192.168.3.2 are assigned to the br-int interface of the
> > controller and node.
> >
> > Using 'nova-manage network' I have created a network IPv4 192.168.4.0/24
> .
> >
> > VM is assigned with IP, 192.168.4.2.
> >
> > from my controller machine I'm unable to ping VM having ip 192.168.4.2
> >
> >
> > Please help me troubleshoot this issue.
> >
> > Thanking you all..
> >
> > --
> > Regards,
> > --
> > Trinath Somanchi,
> > +91 9866 235 130
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Nova + Quantum + OVS

[Nirbhay Tomar]

Hi Trinath,

Have you checked that your quantum is making related gw and tap
interfaces when your vm goes up.
When you create a network and create first vm associated with it,
there should be a gw and tap interface created and
first ip of your new network is assigned to that gw interface.

if you getting further problems, elaborate whole scenario of your controller.

// Nirbhay

On Wed, Jul 18, 2012 at 4:29 PM, Trinath Somanchi
 wrote:
> Hi-
>
> I have set up a controller- node setup with openstack, quantum and
> OpenVswitch.
>
> I'm able to create the virtual machines in the node.
>
> The eth1 interface of controller and node are attached to the OVS br-int.
>
> In the node, 'ovs-vsctl show'  show the port and interface binding of the
> newly created VM.
>
> IP 192.168.3.1, 192.168.3.2 are assigned to the br-int interface of the
> controller and node.
>
> Using 'nova-manage network' I have created a network IPv4 192.168.4.0/24.
>
> VM is assigned with IP, 192.168.4.2.
>
> from my controller machine I'm unable to ping VM having ip 192.168.4.2
>
>
> Please help me troubleshoot this issue.
>
> Thanking you all..
>
> --
> Regards,
> --
> Trinath Somanchi,
> +91 9866 235 130
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Nova + Quantum + OVS

[Trinath Somanchi]

Hi-

I have set up a controller- node setup with openstack, quantum and
OpenVswitch.

I'm able to create the virtual machines in the node.

The eth1 interface of controller and node are attached to the OVS br-int.

In the node, 'ovs-vsctl show'  show the port and interface binding of the
newly created VM.

IP 192.168.3.1, 192.168.3.2 are assigned to the br-int interface of the
controller and node.

Using 'nova-manage network' I have created a network IPv4 192.168.4.0/24.

VM is assigned with IP, 192.168.4.2.

from my controller machine I'm unable to ping VM having ip 192.168.4.2


Please help me troubleshoot this issue.

Thanking you all..

-- 
Regards,
--
Trinath Somanchi,
+91 9866 235 130
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp