Neutron doesn't update floatingip with multiple L3 agent Icehouse

asked 2014-07-03 07:38:50 -0600

visualne gravatar image

Hello,

I recently created a five node OpenStack cloud using Packstack. I am using the neutrons OVS agent with GRE tunnels. My goal is to setup two floating ip address pools. In order to accomplish this, we followed this documentation here http://docs.openstack.org/admin-guide-cloud/content/adv_cfg_l3_agent_multi_extnet.html (http://docs.openstack.org/admin-guide...) .

The problem: Whenever I associate a floating ip address from the pool associated with this 'new' layer3 agent, the nat rule is not created. I confirmed this by issuing this command in the associated namespace ip netns exec qrouter-NAMESPACEID iptables -L -t nat. The only nat rule I see in place is the generic one associated with vms on the network attached to the router in the namespace. ex) SNAT all -- 192.168.1.0/24 anywhere to:192.168.90.41

Here is my layer3 agent.ini file (The one that is the old one that works) http://paste.openstack.org/show/85402/

Here is my second layer3 agent.ini file (The one that is not handling the nat correctly) http://paste.openstack.org/show/85404/

edit retag flag offensive close merge delete

Comments

So you have two different l3 agents running on the same host ? Could you paste both l3 agent logs ?

Cheers Heiko

foexle ( 2014-07-04 02:04:40 -0600 )edit

it probably is because the subnet is not associated with the router. Did you figure this out or are you still blocked ? If not how did you create the floating IP pool ?

dachary ( 2014-07-05 05:26:15 -0600 )edit

We still have the problem. I can't give you the logs because we decided to go with another option. I created the floating ip pool with the appropriate neutron command - neutron net-create networkName --router:external=True

visualne ( 2014-07-06 13:47:08 -0600 )edit

Alright so I am back to this again. This time after creating a second external bridge, I now can't associate a floating ip from either subnet to any vms. However, it looks like vms that are attached to routers that exist on separate external networks are able to get out.

visualne ( 2014-08-14 06:14:39 -0600 )edit

Here's the first l3-agent.ini file: http://pastebin.com/ieHcjxFM Here's the second l3-agent.ini file: http://pastebin.com/eZEeMURT Here is the log for the first layer3 agent: http://pastebin.com/thp85bCP Here is the log for the second layer3 agent: http://pastebin.com/UziE3jsz

visualne ( 2014-08-14 06:54:36 -0600 )edit