Coprocessing with a passive loopback cable

This rather ugly, but dramatically lit little fellow is a passive loopback cable (I connected only two pairs, so it can do only 100MB).

Here it is installed in port 11 on this OpenFlow switch.

But why? What possible use is this beyond testing that the physical interface works?

Some OpenFlow switch implementations are based on hardware that predates the SDN era. In other words, some of that hardware just isn’t very programmable. There are limits on what actions some hardware can perform, and in some cases even the number of actions. If you need more than that – well – tough luck, it can’t be done (or it can only be done in software).

What if you can spare a port though?

That’s what we’re doing here. We’re using a coprocessing port to send packets out the loopback. As they come back, they hit a FAUCET ACL which allows further processing. The round trip buys us a bigger action budget – we can spend actions on the way out, and on the way in again.

acls:
  pushit:
  - rule:
      actions:
        output:
          vlan_vid: 999
          port: 24
dps:
  mydp:
    interfaces:
      11:
        description: loopback
        coprocessor:
            strategy: vlan_vid
        acls_in: [pushit]
        mirror:
          - 13
      13:
        native_vlan: trusted
      24:
        tagged_vlans:
        - trusted
        - untrusted

Port 13 is a simple port with one native VLAN. Traffic to and from this port is mirrored to port 11 (the mirror operation consumes our hardware action budget). Those packets leave on port 11, are looped back to port 11, where they hit the pushit ACL. This ACL pushes a new VLAN, 999 and outputs to 24. That ACL also consumes the hardware action budget (so without the loopback we would not have have had the hardware resources to complete the entire operation).

A perfect beautiful solution? No. But, an interesting way to make less capable hardware somewhat more programmable by adding more (completely passive) hardware.