Chapter 18. Service Insertion and Chaining

Starting in version 5.0, MidoNet has a Technical Preview API for inserting and chaining network service functions. The API is mostly provided by a single object, L2Insertion, whose fields are documented in the REST API documentation.

 Service Function Model

The L2Insertion assumes a Service Function has:

  • an addressable management interface (not managed or referenced from L2Insertion)

    • Assign a Floating IP to allow access from outside the cloud.
  • an unnumbered inspection interface

    • receives the traffic of inspected VMs
    • MidoNet can add a VLAN tag to signal policy, and PCP bits indicate direction (in-to/out-of VM)
security function 237x321

Note that MidoNet drops all non-insertion traffic on an inspection port of a network function.

 L2Insertion Object

The L2Insertion object has these fields (see the REST documentation for more detail):

  1. inspected VM port UUID
  2. inspected VM MAC
  3. service port UUID
  4. VLAN tag
  5. fail-open (true/false)
  6. position

The first 3 fields are the most important to consider. Imagine an L2Insertion configured as described by the following diagram.

The position is an absolute position in the list of insertions. If two insertions have the same position the order is undefined. When we load the insertions we basically sort by the position field. In many ways, it acts more like a weight.

l2insertion 1st 650x300

In such a scenario, MidoNet will set up redirect logic as shown in the diagram below. When VM2 sends a packet to VM1 (and specifically to VM1’s MAC), at the point labelled "redirect logic" (after port-level firewall, not shown) the packet is redirected to the service function (red arrow 1). If the service function allows the packet and therefore re-emits it, the redirect logic at the service function redirects the packet so that it completes its journey to VM1 (red arrow 2).

l2insertion 2nd 650x300

The next diagram shows how packets from the protected port (and MAC) are redirected.

l2insertion 3rd 650x300

The diagrams do now show how field number 4, the VLAN tag, is used. If the VLAN tag is set to a value above zero, then MidoNet will push a VLAN tag with that value onto packets redirected into the service function. MidoNet will also expect the VLAN tag to be left on the packet if it is re-emitted from the service function. MidoNet also uses the PCP bits in the VLAN header for its own purposes, these should not be modified by the service function.

The use of field number 5, fail-open, is illustrated in the diagram below. If fail-open is false, then when the service function fails all redirect traffic is essentially dropped. If fail-open is true, there are cases when MidoNet can detect failure of the service function link (link status only, we do not yet have active monitoring neither in-band or out-of band) and the redirection logic will automatically allow the traffic to skip the failed service function.

l2insertion 4th 650x300

Finally, the sixth field of L2Insertion, position, allows specifying the order in which service functions should be traversed if there are multiple L2Insertion objects with the same inspected port and mac but different service ports.


You can set L2Insertion’s "port" (inspected port) field to a non-Neutron port’s UUID, like that of a router port or a L2GW port. But remember that it’s not the device, but the endpoint connected to the device (router or bridge) that’s protected (and therefore whose MAC should be configured in the L2Insertion). If you want to protect a router port, you must put the L2Insertion object on the bridge port facing the router port. Therefore it’s not possible to protect the exterior ports of a router (like those of the Edge Router).

 L2Insertion in MidoNet CLI

The following example inserts two service functions (located on Bridge1’s port0 and port1) at Bridge0’s port0. Only traffic to/from MAC fa:16:3e:a4:dd:58 is protected. Different VLANs are used for the different service functions - this is not required by MidoNet, the example assumes that the VM is protected by different policies (or policies represented by different VLAN tag values) in the different service functions.

midonet> l2insertion add fail-open true mac fa:16:3e:a4:dd:58 port bridge0:port0 pos 0 srv-port bridge1:port0 vlan 10
midonet> l2insertion add fail-open true mac fa:16:3e:a4:dd:58 port bridge0:port0 pos 1 srv-port bridge1:port1 vlan 20
midonet> l2insertion list
l2insertion l2insertion0 port bridge0:port0 srv-port bridge1:port0 vlan 10 pos 0 fail-open true mac fa:16:3e:a4:dd:58
l2insertion l2insertion1 port bridge0:port0 srv-port bridge1:port1 vlan 20 pos 1 fail-open true mac fa:16:3e:a4:dd:58


These alternative mechanisms are often used in service-chaining use-cases:

With port mirroring the service function receives a copy of the traffic’s packets. Compared to L2Insertion:

  • Only L2Insertion supports VLAN tagging; port mirroring does not.
  • Only port mirroring supports classification; L2Insertion does not.
  • Both allow multiple service functions (but the term "chain" would only be accurate for L2Insertion because in the case of port mirroring each service function would receive a separate copy of the packets)
  • Both allow the service function to be inserted at any port in the logical topology.

You can find more information about port mirroring in the section called “Port mirroring”.

MidoNet also supports source routing (a flavor of policy routing). Source routes can be used to steer traffic through a router differently depending on where the traffic is coming from. MidoNet’s source routing matches on the source IP address of the packet headers, NOT the port at which the packet ingresses the router. Source routing is a traditional way (popular in physical networks) of inserting a network service function when traffic between two endpoints must traverse a router.

MidoNet also supports ECMP (Equal Cost MultiPath) routing. ECMP allows the forwarding table to contain multiple routes with identical source, destination and weight (but differing in their next hop). ECMP can therefore be used to load-balance flows to several service function instances.

MidoNet selects a route by:

  1. Find the matching routes whose destination prefix mask is longest (longest prefix match, LPM)
  2. Filter for routes whose source matches the packet.
  3. Filter for route(s) that has/have the highest weight.
  4. Perform ECMP calculation (hash mod N) to select 1 of the routes.

More information about routing in MidoNet can be found in Chapter 6, Routing.

The limitations of MidoNet’s ECMP load-balancing are further described in the section called “ECMP Limitations”.

Questions? Discuss on Mailing Lists or Chat.
Found an error? Report a bug.

loading table of contents...