Chapter 4. Configure and Deploy OpenDaylight with Red Hat OpenStack Platform 10

You can configure the OpenDaylight API Service by editing opendaylight-api.yaml, located in the /usr/share/openstack-tripleo-heat-templates/puppet/services/ directory.

Configure the OpenDaylight OVS Service by changing the values in opendaylight-ovs.yaml, located in /usr/share/openstack-tripleo-heat-templates/puppet/services/.

The OpenStack Compute service allows virtual machines to query metadata associated with them by making a web request to a special address, 169.254.169.254. The OpenStack Networking proxies such requests to the nova-api, even when the requests come from isolated or multiple networks with overlapping IP addresses.

The Metadata service uses either the neutron L3 agent router to serve the metadata requests or the DHCP agent instance. Deploying OpenDaylight with the Layer 3 routing plug-in enabled disables the neutron L3 agent. Therefore Metadata must be configured to flow through the DHCP instance, even when a router exists in a tenant network. To configure this, set the NeutronEnableForceMetadata to true.

VM instances will have a static host route installed, using the DHCP option 121, for 169.254.169.254/32. With this static route in place, Metadata requests to 169.254.169.254:80 will go to the Metadata nameserver proxy in the DHCP network namespace. The namespace proxy then adds the HTTP headers with the instance’s IP to the request, and connects it to the Metadata agent through the Unix domain socket. The Metadata agent queries neutron for the instance ID that corresponds to the source IP and the network ID and proxies it to the nova Metadata service. The additional HTTP headers are required to maintain isolation between tenants and allow overlapping IP support.

In Red Hat OpenStack Platform director, the physical neutron network data center is mapped to an OVS bridge called br-ex by default. It is consistently the same with the OpenDaylight integration. If you use the default OpenDaylightProviderMappings and plan to create a flat or VLAN _External network, you have to configure the OVS br-ex bridge in the NIC template for Compute nodes. Since the Layer 3 plug-in uses distributed routing to these nodes, it is not necessary to configure br-ex on the controller role NIC template any more.

The br-ex bridge can be mapped to any network in network isolation, but it is typically mapped to the External network as you can see in the example.

type: ovs_bridge
  name: {get_input: bridge_name}
  use_dhcp: false
  members:
    -
      type: interface
      name: nic3
      # force the MAC address of the bridge to this interface
      primary: true
  dns_servers: {get_param: DnsServers}
  addresses:
    -
      ip_netmask: {get_param: ExternalIpSubnet}
  routes:
    -
      default: true
      ip_netmask: 0.0.0.0/0
      next_hop: {get_param: ExternalInterfaceDefaultRoute}

Alternatively, it is possible to configure external network access without using the br-ex bridge at all. To use the method, you must know the interface name of the overcloud Compute node in advance. For example, if eth3 is the deterministic name of the third interface on the Compute node, then will specify an interface in the NIC template for the Compute node:

-
  type: interface
  name: eth3
  use_dhcp: false

Having configured the NIC template, you must override the OpenDaylightProviderMappings parameter to map the interface to the physical neutron network: datacentre:eth3. This will cause OpenDaylight to move the eth3 interface onto the br-int bridge.

The OVS br-int bridge is used to carry the tenant traffic. OpenDaylight supports VXLAN and VLAN type tenant networks. Red Hat OpenStack Platform director will automatically configure the OVS to use the correct IP interface for VXLAN tenant traffic when VXLAN tenant network types are used.

You do not need to create the br-int bridge in the NIC template files. OpenDaylight will create the bridge automatically. However, if you use VLAN tenant networks, you may wish to configure one more physical neutron network and include that interface mapping in the OpenDaylightProviderMappings.

OpenDaylight will then move that interface to the br-int bridge. Regarding such behavior, you must use different interfaces to use both the VXLAN and VLAN tenant networks. Another way is to use an extra bridge within the OpenDaylightProviderMappings for tenant networks.