Flow rules for VLAN networks

In the following example, VLANs 40 and 42 represent two networks in the data center. Both VLANs have been trunked down to the controller and compute nodes, and Neutron networks have been configured that utilize those VLAN IDs.

On the physical switch, the necessary configuration to facilitate the networking described here will resemble the following:

vlan 40
name VLAN_40
vlan 42
name VLAN_42

interface Ethernet1/4
description Provider_Interface_eth2
switchport
switchport mode trunk
switchport trunk allowed vlan add 40,42
no shutdown

When configured as a trunk port, the provider interface can support multiple VLAN networks. Traffic that enters physical interface eth2 is processed by the flow rules on the br-eth2 bridge it is connected to. Flow rules are processed in order of priority from highest to lowest. By default, ovs-ofctl returns flow entries in the same order that the virtual switch sends them. Using --rsort, it is possible to return the results in order of priority, from highest to lowest, to match the order in which packets are processed:

For readability, both the duration and cookie fields have been removed.

The first three rules specify a particular inbound port:

in_port="phy-br-eth2" 

According to the diagram in Figure 5.3, traffic entering the bridge br-eth2 from physical interface eth2 does so through port 1, not the port named phy-br-eth2, so the first three rules do not apply. As a result, traffic is forwarded to the integration bridge via the fourth rule, where no particular port is specified:

Flows with an action of NORMAL instructs Open vSwitch to act as a learning switch, which means traffic will be forwarded out of all of the ports, other than the one where traffic was received, until the switch learns and updates its forwarding database. Traffic is forwarded out of the port that's connected to the integration bridge.

The forwarding database, or FDB table, is the equivalent of a CAM or MAC address table on a physical switch. This learning behavior is similar to that of a hardware switch that floods traffic out of all ports until it learns the proper path.

As traffic exits the provider bridge br-eth2 and enters port 1 of the integration bridge br-int, it is evaluated by the flow rules on br-int, as shown here:

Of immediate importance are the flow rules inspecting traffic sourced from the int-br-eth2 interface, as that is where traffic enters the integration bridge from the provider bridge. The first rule shown here performs the action of modifying the VLAN ID of a packet from its original VLAN to a VLAN that is local to the integration bridge on the compute node when the original VLAN ID, as identified by the dl_vlan value, is 42:

When traffic tagged as VLAN 42 on the physical network is sent to an instance and forwarded through the provider bridge to the integration bridge, the VLAN tag is modified from 42 to local VLAN 1. The frame is then forwarded to Table 60 for additional processing, where the default action is NORMAL. As a result, the frame is forwarded to a port on br-int, which is connected to the instance that matches the destination MAC address.

The next rule performs a similar action when the data link VLAN is 40 by replacing it with local VLAN 2. If traffic matches the drop rule, it means that no other rules of a higher priority entering int-br-eth2 and traffic will be dropped:

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset