{"id":630,"date":"2016-01-10T22:42:29","date_gmt":"2016-01-10T21:42:29","guid":{"rendered":"http:\/\/www.opencloudblog.com\/?p=630"},"modified":"2021-01-17T14:35:23","modified_gmt":"2021-01-17T13:35:23","slug":"openstack-juno-neutron-deployment-part-3-neutron-config","status":"publish","type":"post","link":"https:\/\/www.opencloudblog.com\/?p=630","title":{"rendered":"OpenStack Liberty Neutron Deployment (Part 3 Neutron Config)"},"content":{"rendered":"<p>When a distributed setup of Neutron is used, many Neutron configuration files must be synchronized to all nodes running neutron components. Linux network namespaces must be enabled.<\/p>\n<h1>neutron.conf<\/h1>\n<p>The base configuration file on the Control node contains many options. Some of these (not all!) are shown below in this deployment:<\/p>\n<pre class=\"lang:ini decode:true\" title=\"neutron.conf on the control node\">#\n# does not contain all options !\n#\n[DEFAULT]\nmax_l3_agents_per_router = 2\nl3_ha = False\nallow_automatic_l3agent_failover = True\nallow_overlapping_ips = true\n#\ncore_plugin = ml2\nservice_plugins = router,lbaas,vpnaas,metering,qos\n#\nforce_gateway_on_subnet = true\ndhcp_options_enabled = False\ndhcp_agents_per_network = 1\n#\nrouter_distributed = False\nrouter_delete_namespaces = True\ncheck_child_processes = True\n\n[securitygroup]\nfirewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\nenable_ipset = True\nenable_security_group = True\n\n[agent]\nenable_distributed_routing = False\ndont_fragment = True\narp_responder = False\n\n[fwaas]\nenabled = true\ndriver = neutron.services.firewall.drivers.linux.iptables_fwaas.IptablesFwaasDriver\n\n[service_providers]\nservice_provider=LOADBALANCER:Haproxy:neutron_lbaas.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default\nservice_provider=VPN:openswan:neutron_vpnaas.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default\n<\/pre>\n<h2>ml2_conf.ini<\/h2>\n<p>The ml2 config file can be deployed on all Network, Compute and Control Nodes. The only difference is, that &#8222;local_ip&#8220; must be set on Network and Compute Nodes to the IP address of the local &#8222;l3vxlan&#8220; interface (see part 2).<\/p>\n<pre class=\"lang:ini decode:true \" title=\"ml2_conf.ini\">[ml2]\ntype_drivers = vxlan,local,vlan,flat,geneve\ntenant_network_types = vxlan\nmechanism_drivers = openvswitch\nextension_drivers = port_security\n\n[ml2_type_vxlan]\nvni_ranges = 65537:69999\n\n[ml2_type_vlan]\nnetwork_vlan_ranges = vlannet:100:299\n\n[ml2_type_flat]\nflat_networks = *\n\n# the ovs section is only needed on compute and network nodes\n# where the openvswitch and the L2 agent are running\n# but it does not hurt, if it is also included on the control node\n[ovs]\nbridge_mappings = vlannet:br-vlan\ntunnel_type = vxlan\ntunnel_bridge = br-tun\nintegration_bridge = br-int\ntunnel_id_ranges = 65537:69999\nenable_tunneling = True\ntenant_network_type = vxlan\n###&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; local_ip is only used on compute and network nodes ### \n# local_ip = &lt;ip address of the l3vxlan interface&gt;\n\n[agent]\ntunnel_types = vxlan\nl2_population = False\n<\/pre>\n<p>The vxlan vni range is set to 65537:69999, which is not the default value. I prefer this setting, because it is easy to distinguish vxlan vni values\u00a0 from vlan values, which are in the range 0 &#8211; 4095. This avoids any confusion when an error occurs and Openflow entries must be debugged.<\/p>\n<p>The vlan type driver requires only one configuration line [<a title=\"(Type driver vlan)\" href=\"http:\/\/www.opencloudblog.com\/?p=460\" target=\"_blank\" rel=\"noopener\">see also<\/a>].<\/p>\n<ul>\n<li>vlannet is the internal Openstack name of the vlan range used also in the Openstack API<\/li>\n<li>the vlan range in this deployment is 100:299<\/li>\n<\/ul>\n<p>To keep the configuration simple, we do not create two configuration lines here. We are only using the vlans 100-101 and 200-201, therefore we should have two mappings.<\/p>\n<p>In the ovs section for the openvswitch mechanism driver, the internal Openstack name vlannet is mapped to a Openvswitch bridge using one configuration item<\/p>\n<ul>\n<li>vlannet (the Openstack name) is mapped to br-vlan (by the mechanism driver Openvswitch)<\/li>\n<\/ul>\n<p>The mechanism driver l2population is not used, the benefit using it is too low compared to the risk of breaking the network.<\/p>\n<h1>l3_agent.ini<\/h1>\n<p>The L3 agent on the network nodes requires two entries, which must be set to an empty string.<\/p>\n<pre class=\"lang:ini decode:true\" title=\"L3_agent.ini\">#\n# does not show all necessary options\n#\n[DEFAULT]\n#\n# very important - set the two following entries to an empty string\n# do not leave the default values\ngateway_external_network_id =  \nexternal_network_bridge =  \n#\n# we use the legacy mode - HA and DVR are broken in Juno and should not used in production environments\nagent_mode = legacy\n# \n# nova metadata is deployed only on the network node(s) and listens on 127.0.0.1\nmetadata_port = 8775\nmetadata_ip = 127.0.0.1\nenable_metadata_proxy = True\n#\nhandle_internal_only_routers = true\nrouter_delete_namespaces = True\n#\n# veths should be avoided\novs_use_veth = false\n#\ninterface_driver = neutron.agent.linux.interface.OVSInterfaceDriver\nuse_namespaces = true<\/pre>\n<p>By setting <strong>gateway_external_network_id<\/strong> and <strong>external_network_bridge<\/strong> to an <strong>empty<\/strong> <strong>string<\/strong>, the L3 agent starts searching for networks being defined as &#8222;external&#8220; by the admin and vlans can be used to connect the routers to. No extra bridges are needed.<\/p>\n<p>As we deploy nova_metadata on the network node, the metadata_ip is set to 127.0.0.1.<\/p>\n<h1>dhcp_agent.ini<\/h1>\n<p>The dhcp agent on the network node requires at least:<\/p>\n<pre class=\"lang:ini decode:true \" title=\"dhcp_agent.ini\">#\n# does not show all necessary options\n#\n[DEFAULT]\ndhcp_delete_namespaces = True\nenable_metadata_network = false\nenable_isolated_metadata = true\nuse_namespaces = true\ndhcp_driver = neutron.agent.linux.dhcp.Dnsmasq\novs_use_veth = false\ninterface_driver = neutron.agent.linux.interface.OVSInterfaceDriver\ndhcp_agent_manager = neutron.agent.dhcp_agent.DhcpAgentWithStateReport\n<\/pre>\n<h1>metadadata_agent.ini<\/h1>\n<p>The neutron metadata agent on the network node requires at least:<\/p>\n<pre class=\"lang:ini decode:true\" title=\"metadata_agent.ini\"># \n# does not show all necessary options\n#\n[DEFAULT]\nmetadata_proxy_shared_secret = METADATAsecret\nnova_metadata_ip = 127.0.0.1\nverbose = true\n<\/pre>\n<p>As we install nova metadata on the network node, the listener is on the same node and we find nova_metadata on 127.0.0.1<\/p>\n<h1>nova-metadata.conf<\/h1>\n<p>For nova-metadata we enable only the metadata service and we listen only to 127.0.0.1<\/p>\n<pre class=\"lang:ini decode:true\" title=\"nova-metadata.conf\">#\n# does not show all necessary options\n#\n[DEFAULT]\nmetadata_host = 127.0.0.1\nmetadata_listen = 127.0.0.1\nuse_forwarded_for = true\n#\nmetadata_workers = 4\nmetadata_listen_port = 8775\nservice_neutron_metadata_proxy = true\nneutron_metadata_proxy_shared_secret = METADATAsecret\n#\nneutron_ovs_bridge = br-int\nneutron_use_dhcp = True\nlinuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver\nsecurity_group_api = neutron\nnetwork_api_class = nova.network.neutronv2.api.API\n#\n# enable only the metadata service\n#\nenabled_apis = metadata\n<\/pre>\n<p><a title=\"Part 4\" href=\"http:\/\/www.opencloudblog.com\/?p=654\">Continue reading (part 4)<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>When a distributed setup of Neutron is used, many Neutron configuration files must be synchronized to all nodes running neutron components. Linux network namespaces must be enabled. neutron.conf The base configuration file on the Control node contains many options. Some of these (not all!) are shown below in this deployment: # # does not contain [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14],"tags":[],"_links":{"self":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts\/630"}],"collection":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=630"}],"version-history":[{"count":23,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts\/630\/revisions"}],"predecessor-version":[{"id":939,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts\/630\/revisions\/939"}],"wp:attachment":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=630"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=630"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=630"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}