Ask Your Question

[fuel] HA control plane setup, ODL and neutron L3 HA

asked 2016-06-09 05:44:14 -0700

dbalsige gravatar image

Hi there,

As far as I understood neutron L3 HA is done by having scheduled more than one L3 agent per virtual router. When ODL is used to manage L3 traffic, I still can check the option neutron L3 HA, but as far as I know there are no L3 agents anymore (only DHCP and metadata agents).

Now to my questions:

  1. Has checking the neutron L3 HA option in fuel gui network setup any effect when using ODL to manage L3 traffic ? Does ODL have something like L3 HA, and if so is it enabled when checking the L3 HA setup ?

  2. ODL is only deployed on one controller node. so for the ODL part this setup is not HA. What are the effects when this particular controller node is down and some requests hit the neutron API northbound of ODL? does ODL sync with the actual neutron database state when coming back online, and setup ovs bridges accordingly ?

  3. IP consumption in the public network: I understand each node needs access to public network physically in ODL (or also in DVR) setups. However I dont understand why compute nodes are needing an IP address on this link. In my former DVR based setups this was not the case. Has anybody an explanation for this? In my understanding every controller node needs an IP in the public network plus the VIP for HAproxy. (publicvip) In my deplyoment I see another IP allocated in the public network: (publicvroutervip) What is this IP (publicvrouter_vip) used for ?

Thanks in advance. D

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2016-06-13 04:35:30 -0700

mskalski gravatar image


  1. As you mentioned neutron l3 agents are not in use when L3 traffic is managed by ODL, and options dedicated for them should not impact this type of deployments.

  2. This commit will introduce possibility of deploying cluster of ODL controllers. However it simply does not work for now, a lot of errors on ODL side prevents from merging this change. can be a better place to ask this question.

  3. Plugin utilize existing functionality "Assign public network to all nodes". Its ensure that on compute nodes public network will be available and it does not require from user to use custom network template. Side effect of that is IP from public pool assigned to bridge on compute.

Public vrouter is used inside vrouter namespace:

ip netns exec vrouter ip a

vrouter namespace provide connectivity between outside network and nodes which are not directly connected to public network.

edit flag offensive delete link more


Thank you for this reply. You seem to have competent answers on all my questions. It is very appreciated. To 3. Since all my nodes (ctrl and compute) are on the public network, I don't get why the vrouter namespace is still needed. Also I don't get why the compute nodes have an IP address in public.

dbalsige ( 2016-06-13 05:52:17 -0700 )edit

Public IPs on computes are effect of using "Assign public network to all nodes". I think it can be done in the way which will not require using this option, you can create bug/request on and I will try to rewrite this part.

mskalski ( 2016-06-13 07:36:40 -0700 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Question Tools

1 follower


Asked: 2016-06-09 05:44:14 -0700

Seen: 6,686 times

Last updated: Jun 13 '16