A.4.1 Application VIP Failover Options

Within an OpenStack cloud environment, there are several options for allowing applications to manage their own virtual IP (VIP) addresses as traditionally done in telecommunications applications. This document describes two of those options:

• Allowed address pairs
• Disable port security

Each of these options is covered in the major sub-sections that follow. The last major sub-section discusses onutilizing application managed virtual IP addresses within an OpenStack VM instance.

Both options effectively work around the default OpenStack Networking (Neutron) service anti-spoofing rules that ensure that a VM instance cannot send packets out a network interface with a source IP address different from the IP address Neutron has associated with the interface. In the Neutron data model, the logical notion of networks, sub-networks and network interfaces are realized as networks, subnets, and ports as shown in the following figure.

Figure A-1 Neutron High-Level Data Model

A port in the Neutron data model maps to at most one VM instance where internal to the VM instance, the port is represented as an available network device such as eth0. VM instances can have multiple network interfaces in which case there are multiple Neutron ports associated with the VM instance, each with different MAC and IP addresses.

Each Neutron port by default has one MAC Address and one IPv4 or IPv6 address associated with it. The IP address associated with a port can be assigned in two ways:

• Automatically by Neutron when creating a port to fulfill an OpenStack Compute (Nova) service request to associate a network interface with a VM instance to be instantiated.
• Manually by a cloud administrator when creating or updating a Neutron port.

The anti-spoofing rules are enforced at the Neutron port level by ensuring that the source IP address of outgoing packets matches the IP address Neutron has associated with the corresponding port assigned to the VM instance. By default, if the source IP address in the outgoing packet does not match the IP address associated with the corresponding Neutron port, then the packet is dropped.

These anti-spoofing rules clearly create a complication for the use of application managed virtual IP addresses. This is since Neutron is not aware of the VIPs being applied by the application to VM instance network interfaces without an interaction between the application (or a higher-level management element) and Neutron. Hence, the two options in this document either fully disable the port security measures within Neutron, including the anti-spoofing rules, or expand the set of allowable source IP addresses to include the VIPs that may be used by the application running within a VM instance.

For both of the options described in the following sub-sections, there is a particular Neutron service extension or feature that must be enabled for the option to work. For one option (allowed address pairs) the required Neutron extension is enabled in most default deployments whereas for the other option (allow port security to be disabled) it is not.

Within this document when describing how to use either of these two options, there is example command line operations that interact with the OpenStack Neutron service using its command line utility, named neutron. However, be aware that all of the operations performed using the neutron command line utility can be performed through the Neutron REST APIs, see the Networking v2.0 API documentation for more information.