Project Networks

Project networks are logical networking entities visible to project users, and around which working network topologies are built.

Project networks need support from the physical layers to work as intended. This means that the access L2 switches, data networks, and data interface definitions on the compute nodes, must all be properly configured. In particular, careful StarlingX OpenStack project network management planning is required to achieve the proper configuration when using data networks of the VLAN or VXLAN type.

For data networks of the VLAN type, consider the following guidelines:

  • All ports on the access L2 switches must be statically configured to support all the VLANs defined on the data networks they provide access to. The dynamic nature of the cloud might force the set of VLANs in use by a particular L2 switch to change at any moment.

  • Configuring a project network to have access to external networks (not just providing local networking) requires the following elements:

    • A physical router, and the data network’s access L2 switch, must be part of the same Layer-2 network. Because this Layer 2 network uses a unique VLAN ID, this means also that the router’s port used in the connection must be statically configured to support the corresponding VLAN ID.

    • The router must be configured to be part of the same IP subnet that the project network is intending to use.

    • When configuring the IP subnet, the project must use the router’s port IP address as its external gateway.

    • The project network must have the external flag set. Only the admin user can set this flag when the project network is created.

For data networks of the VXLAN type, consider the following guidelines:

  • Layer 3 routers used to interconnect compute nodes must be multicast-enabled, as required by the VXLAN protocol.

  • To minimize flooding of multicast packets, IGMP and MLD snooping is recommended on all Layer 2 switches.

  • To support IGMP and MLD snooping, Layer 3 routers must be configured for IGMP and MLD querying.

  • To accommodate VXLAN encapsulation, the MTU values for Layer 2 switches and compute node data interfaces must allow for additional headers. For more information, see The Ethernet MTU.

  • To participate in a VXLAN network, the data interfaces on the compute nodes must be configured with IP addresses, and with route table entries for the destination subnets or the local gateway. For more information, see Manage Data Interface Static IP Addresses Using the CLI, and Add and Maintain Routes for a VXLAN Network.

In some circumstances, project networks can be configured to use VLAN Transparent mode, in which VLAN tagged packets from the guest are encapsulated within a data network segment (VLAN) without removing or modifying the guest VLAN tag.

Alternatively, guest VLAN-tagged traffic can be implemented using StarlingX OpenStack support for OpenStack VLAN Aware VMs.

For more information about VLAN Aware VMs, see VLAN Aware VMs or consult the public OpenStack documentation at, http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html.