Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Understanding Support for OpenFlow on Devices Running Junos OS

OpenFlow Overview

OpenFlow is an open standard that enables you to control traffic and run experimental protocols in an existing network by using a remote controller. The OpenFlow components consist of a controller, an OpenFlow or OpenFlow-enabled switch, and the OpenFlow protocol. The OpenFlow protocol is a Layer 2 protocol that permits an OpenFlow controller access to the data plane of an OpenFlow-enabled switch over an SSL or TCP/IP connection.

Using OpenFlow, you can control traffic paths in a network by creating, deleting, and modifying flows in each device along a path. Flow entries specify match conditions against which packets are compared, and a set of actions (OpenFlow v1.0) or instructions (OpenFlow v1.3.1) that are applied to matching packets.

You can configure certain devices running Juniper Networks Junos operating system (Junos OS) as OpenFlow-enabled switches. The Junos OS process, openflowd (ofd), handles OpenFlow functionality on these devices. When implementing OpenFlow in an existing network, you must isolate experimental flows from production flows so that normal network traffic is not impacted. On devices running Junos OS, you isolate OpenFlow traffic by configuring one or more virtual switches that act as logically separate flood domains. The virtual switch and controller communicate by exchanging OpenFlow protocol messages, which the controller uses to add, delete, and modify flows on the switch.

OpenFlow Virtual Switches

To isolate and control OpenFlow traffic on devices running Junos OS, you configure virtual switches. Each virtual switch configuration contains the controller connection information, the set of logical interfaces participating in OpenFlow, and the default action executed when a packet does not match any existing flow entry. You configure the OpenFlow protocol and OpenFlow virtual switches at the [edit protocols openflow] hierarchy level.

Depending on the platform, a default VLAN or bridge domain is assigned to each virtual switch. This VLAN or bridge domain acts as a logically separate flood domain, which isolates OpenFlow traffic from normal traffic. On certain platforms, you must also configure a separate virtual switch routing instance at the [edit routing-instances] hierarchy level.

You can configure a single OpenFlow virtual switch on devices running Junos OS that support OpenFlow, and you can configure one controller connection per virtual switch. By default, if you configure a virtual switch with a single controller, the controller is in active mode. If a controller is in active mode, the switch automatically initiates a connection to the controller.

OpenFlow Interfaces

When you configure an OpenFlow virtual switch on a device running Junos OS, you must specify the logical interfaces that are participating in OpenFlow for that virtual switch instance. OpenFlow traffic can only either enter or exit OpenFlow-enabled interfaces. MAC address learning is disabled on these interfaces.

Interfaces participating in OpenFlow must be configured as Layer 2 interfaces. To configure an interface as OpenFlow-enabled, you add the logical interface to the OpenFlow virtual switch configuration at the [edit protocols openflow switch switch-name interfaces] hierarchy level. An OpenFlow interface can be configured only under a single virtual switch. On platforms that require a separate virtual switch routing instance for OpenFlow traffic, you must also configure the OpenFlow interfaces under the OpenFlow virtual switch routing instance.

On certain platforms that support OpenFlow, you can configure only a single logical unit by using logical unit number 0 on an OpenFlow interface. However, on certain platforms that support OpenFlow, a single physical interface can be configured as a hybrid interface that supports both OpenFlow and non-OpenFlow logical interfaces—for example, you can configure interface ge-1/0/1 to have two logical interfaces ge-1/0/1.0 and ge-1/0/1.1, where ge-1/0/1.0 does not participate in OpenFlow, and ge-1/0/1.1 is an OpenFlow-enabled interface.