• Neutron is responsible for providing networking to running instances within OpenStack

• Provides an API for defining, configuring, and using networks

• Relies on a plugin architecture for implementation of networks, examples include-

• Open vSwitch (default in Red Hat’s distribution)

• Cisco, PLUMgrid, VMware NSX, Arista, Mellanox, Brocade, etc.

OpenStack Networking (Neutron)

• Neutron provides an API for defining networks and relies on drivers/plugins for

implementation

• Allows definition of networks, subnets, IP addresses, ports, virtual routers, via self-service

• Two major networking models implemented or consumed by OpenStack:

• Tenant Networks

• Private overlay networks configured and consumed by the users within tenant

• Isolated using either VLANs or tunnels

• Provider Networks

• Existing datacenter networks configured by admins, consumed by tenants

Neutron: Deeper Dive

• Users/tenants have full control over networking topology

• Can create virtual routers between networks, including external networks

• Neutron provides self-service subnet, DHCP, DNS, L3 routing, and firewall

modification

Neutron: Tenant Networks

Tenant Network

Running InstancesNeutron L3 & DHCP

External Network

• Tenant networks aren’t typically routable from the outside

• Floating IP addresses are used to access instances on isolated tenant networks

• Neutron L3-agent has the responsibility of NAT’ing traffic between networks

• e.g. logical mapping between “172.16.0.1” and “10.0.0.1”

Neutron: Tenant Networks

Tenant Network

Running InstancesNeutron L3

External Network

172.16.0.1

10.0.0.1

• Administrators configure the networks and who has permission to use them

• Users don’t have the same level of control as they would in tenant networks

• External networks can be flat, or VLAN tagged.

• DHCP is optional, but external services for routing and DNS are common.

Neutron: Provider Networks

External Network

Instances from multiple tenantsNeutron DHCPExternal Services

• Security groups are OpenStack’s IP filtering mechanisms

• Supports filtering of traffic both ingress and egress on UDP, TCP, and ICMP

• Security groups are user-customisable and available via self-service

Neutron: Security Groups

• How does it actually work?

• Neutron stores the logical representation of networks

• Plugins actually translate the logical representation, e.g. Open vSwitch

• Agents on each host/hypervisor make necessary modifications to implement

networking

• Various plugins differ in their implementation, but-

• Typically use a message bus for communication and scale out

• Some use a specific SDN/Network Controller

• Remaining examples in this training focus specifically on Open vSwitch

Neutron: Deeper Dive

Neutron: Deeper Dive

Neutron Server

Message Bus

Neutron L2 Agent

Nova Compute

Neutron L2 Agent

Nova Compute

• Open vSwitch provides networking access to instances

• Tenant networks are implemented by flows received from the Neutron server

• vSwitches are linked together via dedicated interfaces for instance communication across hypervisors

• Tenant network traffic is isolated over these channels using VLANs, or tunnels

Neutron: Deeper Dive

Neutron L2 Agent

Nova Compute

Neutron L2 Agent

Nova Compute

Neutron: Deeper Dive

Neutron L2 Agent

Nova Compute

Neutron L2 Agent

Nova Compute

Tenant Network A

Tenant Network B

Neutron: Deeper Dive

• Open vSwitch uses virtual switches/bridges to form the networks on each host

• br-int - Integration Bridge

• All local ports interconnect here, e.g. vNICs or Neutron services (DHCP, L3…)

• br-tun - Tunnel Bridge

• If tunnels are enabled, this bridge is used to link other vSwitches together for tenant traffic

• br-ex - External Bridge

• Used to route external traffic to/from tenant networks; requires a physical ethernet adapter

• br-<custom> - Custom Bridge

• Used to link virtual switches and physical networks, e.g. for provider networks

Neutron: Deeper Dive