3.1. Creating an Inline Layer 2 Service

3.1.1. What it is

An inline layer 2 service is defined by the following primary characteristics:

  • Layer 2: It does not contain external IP addresses in the data path and thus does not participate in traffic routing.

  • Inline: It has physically or logically separate inbound (to-device) and outbound (from-device) interfaces.


    Figure 31: Inline Layer 2 service

Many modern security products fit into this category, including products by FireEye, Gigamon, Ixia, Cisco and Palo Alto. Inline layer 2 devices transparently pass traffic, but unlike passive TAP devices, they can modify or break (i.e. reset, drop) that traffic in real time.

3.1.2. How to build it


F5 BIG-IP rSeries and VELOS platforms introduce a new tenant-based architecture. By default, the BIG-IP tenants are afforded a small set of internal MAC addresses. However, inline layer 2 inspection services require additional MAC addresses. To deploy layer 2 services on these platforms, you must first assign an adequate number of MAC addresses to a “MAC pool”. Note that a single inline layer 2 inspection device requires a unique pair of MAC addresses. You must therefore define the MAC pool block based on the required number of layer 2 devices (2 MACs per device).

Please see the following articles for additional information on creating MAC pools on a BIG-IP rSeries or VELOS platform:

Support for SSL Orchestrator inline layer 2 inspection services is included in the following F5OS and BIG-IP version combinations:


rSeries 5K and 10K

rSeries 2K and 4K

F5OS Version

F5OS-C 1.6.0

F5OS-A 1.3.1

F5OS-A 1.4.0

BIG-IP Versions


15.1.8, 17.1.0


To create an inline layer 2 inspection service, either from a topology workflow or directly under the Services tab in the SSL Orchestrator user interface, click the Add button to create a new inline layer 2 service.

Inline Layer 2 Service

User Input

Service Properties

Choose an inline layer 2 service from the catalog or select the “Generic Inline Layer 2” service and click the Add button.


Provide a name for this service.


Optionally provide a description.

Network Configuration

Click the Add button. This setting defines how traffic flows to the inline layer 2 service on the From BIGIP VLAN, and how traffic returns from the service on the To BIGIP VLAN.

  • If VLANs have already been created for this service, select Use Existing under each heading and select the appropriate to-service and from-service VLANs.

  • If VLANs do not exist, select the Create New options, provide each side a unique name, and specify a connected interface.

  • A Tag is only required if the inline layer 2 service supports and requires 802.1Q VLAN tagging.

  • The Ratio setting applies if multiple devices are configured for this service, and each requires a different ratio-based load balancing score. Otherwise for equal distribution leave the number at 1.

    Click the Done button to create this connection. Click the Add button again if multiple devices will be load balanced for this inline layer 2 service.

Device Monitor

Optionally define an alternate monitor. In most cases the default gateway_icmp monitor is preferable for inline layer 2 services.

Service Down Action

Optionally select an alternate service down action. This setting defines what happens if all devices in a service pool are down and will either ignore (skip this service in the chain), reset, or drop the traffic.

Enable Port Remap

Enable port remapping for detected HTTPS traffic. This will remap any decrypted HTTPS traffic to the chosen port.


Optionally insert additional iRule processing. No additional iRules are required.

Click Save & Next to proceed.

The workflow will proceed to the Service Chains page to allow adding of this new service to a service chain. Once complete here, if in a topology workflow click Save & Next to continue. If adding the service directly, click the Deploy button.

3.1.3. How it works

An inline layer 2 service passively passes traffic through physically or logically separate interfaces. Unlike a layer 3 device, layer 2 devices do not expose IP addresses and do not participate in routing. And unlike passive TAP devices, layer 2 devices are able to affect the traffic in real time. They may, for example, drop/reset a traffic flow, rewrite/scrub content, or generate blocking page actions. The SSL Orchestrator dynamic service chain mechanism freely allows all of these actions to work as expected. If an inline service resets the traffic, that reset action will cascade out to the client and server. If the inline service generates a blocking page, that page will be sent to the client.

  • Service Properties - the Service Properties page represents a Service Catalog of validated product integrations and represents each of the five security product types. If your security product is not listed, there are also “generic” service icons at the bottom of the catalog.

  • Network Configuration - network configuration defines how traffic flows to an inline service, and how that traffic returns back to the F5 BIG-IP. In the case of inline layer 2 service, as the service presents no IP addressing, the only configuration required here is the set of interfaces, to-service and from-service, that will connect to the device. Under the hood, SSL Orchestrator builds a layer 3 path across this device, which allows it to natively load balance and monitor layer 2 devices easily. The From BIGIP VLAN setting defines the interface that carries traffic to the inline layer 2 service, and the To BIGIP VLAN setting defines the interface that accepts traffic returning from the service. If multiple devices are defined for this service, a Ratio can be set for each to affect load balancing distribution. A Tag is only required on each interface if the inline service supports and requires 802.1Q VLAN tagging. It is unusual for layer 2 services to support 802.1Q tagging, however this setting is most useful when a single layer 2 service is shared between non-HA SSL Orchestrator appliances. The setting would apply a set of unique VLAN tags to communicate with an intermediary switch, which would then send untagged traffic to the shared layer 2 device.

  • Device Monitor - as stated, the service configuration builds a layer 3 path across an inline layer 2 device. Thus, a typical monitor for this type of device sends a health check across the device to a listener on the other side. If the layer 2 device fails closed, the monitor fails. And in this case a simple gateway_icmp monitor is sufficient. However, if the layer 2 service fails open, an icmp monitor would not fail. This setting provides an opportunity to adjust monitoring for such situations. For example, a monitor can be defined that sends a health check to an alternate interface on the layer 2 service.

  • Service Down Action - a security service defines a pool of one or more load balanced and monitored devices. Depending on the state of the monitor, a different action may be taken. It may be most appropriate, for example, to simply bypass a failed service (i.e. all of the members are down) in order to maintain availability.

  • Enable Port Remap - most modern security products will define a set of “default” actions for traffic arriving on different known ports. For example, traffic arriving on port 80 will be assumed to be unencrypted HTTP and inspectable. However, port 443 will normally be encrypted HTTPS, so will not be inspected. Should the SSL Orchestrator decrypt HTTPS and continue to send that unencrypted traffic on port 443 to the inline service, that service may continue to ignore it. Or worse, a policy change would be needed to allow it to inspect 443, and any other possible port that HTTPS traffic may be on. The Enable Port Remap option provides a mechanism to simply and temporarily remap the destination port of decrypted HTTPS traffic passing across this service. For example, you might set this to remap HTTPS to port 8080 to allow the service to see this as inspectable HTTP.

  • iRules - iRule logic can be defined at multiple strategic points within an SSL Orchestrator configuration. An iRule attached at the service level specifically targets traffic flowing across this service. iRules are an extremely powerful tool for manipulation and observation of real time traffic flows. You could, for example, insert an iRule to produce additional logging, insert or remove headers, or to inspect and/or act on some values in the request or response. Keep in mind here that an iRule inserted at a service is interacting with the flow at that service and should not be used to control flow, though it could be used to generate a reset or blocking page. iRules used here are intended to work primarily at the application layer (ex. HTTP).

3.1.4. Additional Information

For traffic to traverse an inline layer 2 service in a manner that provides full and native load balancing and active health monitoring, the SSL Orchestrator configuration defines a routing path across the layer 2 service. Packets are routed from one VLAN, out of the F5 BIG-IP and across the layer 2 service, and back to a VLAN on the other side. Both F5 BIG-IP VLANs are in the same subnet but separated by a route domain. Internal RFC2544 addressing is assigned to each VLAN, and address translation is disabled across the listener virtual servers to allow traffic to flow without manipulation of source and destination addressing (no SNAT or NAT). Destination port translation is enabled or disabled for decrypted HTTPS via the Port Remap option, otherwise destination ports also do not change. Source ports are only changed if the inline service is behind an explicit forward proxy topology. For multiple devices in an inline layer 2 service, each is assigned a separate set of VLANs, internal addressing and route domain.

3.1.5. Video