2.7. Creating Layer 2 Topologies¶
2.7.1. What it is¶
A topology is an entry point for network traffic into SSL Orchestrator. A layer 2 topology is created to enable “transparent” traffic to flow into SSL Orchestrator for decryption and service chain processing. In a layer 2 topology, the external VLANs of the F5 BIG-IP do not possess self-IPs, therefore the topology does not participate in routing. Both sides of F5 BIG-IP are in the same routing subnet, with the F5 BIG-P sitting in the physical path between them as a “bump-in-the-wire”. An inbound or outbound layer 2 topology is defined by which VLANs consume the incoming traffic, and by how SSL is handled. In an outbound scenario (internal clients to external resources), the SSL configuration re-issues (forges) server certificates. In an inbound scenario (external clients to internal resources), the SSL configuration contains end-entity server certificates and private keys. You must define inbound and outbound layer 2 topologies separately. There are also a few advantages and disadvantages of a layer 2 topology over layer 3 topologies.
Note
L2 topology modes are made possible by hardware chipsets only available on F5 BIG-IP i58x0 platforms and above, plus VIPRION B2250 and B4450 blades. L2 topologies are not supported in vCMP and VE platform environments.
- Advantages of a layer 2 topology
- Layer 2 topologies do not require routing changes to insert. Theys simply require a physical insertion in an existing layer 3 environment.
Disadvantages of a layer 2 topology
Layer 2 topologies do not generally benefit from sub-second failover. In a layer 3 environment, F5 BIG-IP high availability (HA) peers can fail over quickly through shared “floating” IP addresses. As a layer 2 topology has no IP addresses, it cannot directly notify the environment that a failover has happened, thus requires external forces to notice interface state. This is typically accomplished through routing protocol health checks (e.g. BGP, OSPF, CDP, STP, etc.), and failover time is dependent on the frequency of those health checks.
Note
While possible to deploy a layer 2 topology with third-party “fail-to-wire” devices, failing to wire would also bypass the security stack. It is always recommended practice to deploy SSL Orchestrator as an HA pair, in lieu of simply bypassing a failed security zone.
Layer 2 topologies do not support existing application or explicit proxy topologies, or any advanced routing features of the F5 BIG-IP.
Note
While layer 2 topologies are fundamentally easier to deploy, layer 3 topologies are more flexible and support more modes of operation. Layer 2 topologies also require additional considerations in the surrounding routing environment to support interface failure detection if SSL Orchestrator is configured as HA peers.
2.7.2. How to build it¶
Layer 2 topologies employ a “virtual-wire” configuration to forward layer 2 headers across an otherwise full-proxy SSL Orchestrator configuration. The topology workflow itself is the same as a corresponding layer 3 forward or reverse proxy topology, except without IP addresses and egress routing assignments. The virtual-wire configuration must be defined before deploying a layer 2 topology. For an HA mode SSL Orchestrator configuration, virtual-wire must be defined from the console.
| Virtual-Wire Configuration |
|---|
| The following commands will build a proper virtual-wire configuration: |
| Optional - Create trunk interfaces as required. Where “<int>” is specified, replace with the physical interface (ex. 1.1, 1.2, etc.). Enable LACP or other features as needed. |
tmsh create net trunk internal_trunk interfaces add { <int 1> <int 2> }
tmsh create net trunk external_trunk interfaces add { <int 3> <int 4> }
|
| Step 1 - Modify port-forwarding mode for interfaces that are part of the virtual-wire. Where “<int>” is specified, replace with the physical interface (ex. 1.1, 1.2, etc.), or trunk. |
tmsh modify net interface <int 1> port-fwd-mode virtual-wire
tmsh modify net interface <int 2> port-fwd-mode virtual-wire
|
| Step 2 - Configure “tag” VLANs on the virtual-wire interfaces with the tag 4096 (“any” VLAN). These VLANs promiscuously bridge all tagged traffic. Where “<int>” is specified, replace with the physical interface (ex. 1.1, 1.2, etc.), or trunk. |
These will create interfaces for tagged traffic tmsh create net vlan l2wire_vlan_4096_int tag 4096 interfaces add { <int 1> { tag-mode service tagged }}
tmsh create net vlan l2wire_vlan_4096_ext tag 4096 interfaces add { <int 2> { tag-mode service tagged }}
|
| Step 3 - Create “notag” VLANs using 4094 as the tag. These VLANs bridge untagged traffic (ex. STP BPDUs). Where “<int>” is specified, replace with the physical interface (ex. 1.1, 1.2, etc.), or trunk. |
tmsh create net vlan l2wire_vlan_4094_int tag 4094 interfaces add { <int 1> }
tmsh create net vlan l2wire_vlan_4094_ext tag 4094 interfaces add { <int 2> }
|
| Step 4 - Configure a VLAN group linking the virtual-wire interfaces |
tmsh create net vlan-group l2wire members add { l2wire_vlan_4096_int l2wire_vlan_4096_ext } mode virtual-wire
tmsh create net vlan-group notag members add { l2wire_vlan_4094_int l2wire_vlan_4094_ext } mode virtual-wire
|
Note
- Only two VLANs can be defined per virtual wire VLAN group, however, the VLAN itself can be built on top of a trunk interface which has multiple physical interfaces that support virtual-wire.
- You can have multiple L2 virtual wire configurations on a single F5 BIG-IP. However, L2 and L3 SSL Orchestrator topologies cannot be applied to the same VLANs.
- Once defined on a virtual-wire VLAN group, an interface and VLAN can no longer possess a self-IP.
- Not all interfaces are eligible to participate in a virtual-wire configuration. To determine which interfaces can be used on your platform, please review: K59323455 (https://support.f5.com/csp/article/K59323455).
| Topology Configuration | User Input |
|---|---|
| An SSL Orchestrator topology configuration follows the same workflow path as corresponding layer 3 forward and reverse proxy topologies, except for the following differences. | |
| Topology Properties | Select either L2 Inbound or L2 Outbound. |
| Interception Rules | VLAN selection is the only option here and must be either the client-facing virtual-wire VLAN, or server-facing virtual-wire VLAN, but not both. |
| Egress Settings | There are no egress settings for an L2 topology. |
| Refer to the corresponding layer 3 outbound and reverse proxy inbound topology workflows for additional detail on configuring this topology. | |
2.7.3. How it works¶
SSL Orchestrator layer 2 topologies employ a “virtual-wire” configuration to forward layer 2 headers across an otherwise full-proxy SSL Orchestrator configuration. This mechanism requires a hardware chipset only available on F5 BIG-IP i58x0 appliances and above, and not supported in vCMP an VE platforms environments. The virtual-wire performs two key functions.
It creates a layer 2 bridge across the defined interfaces. Any traffic that does not match a topology listener will pass across this bridge. In particular, devices on either side of the F5 BIG-IP will be in the same routing subnet and know each other by their layer 2 (MAC) addresses, as this traffic (ARP, BGP, STP, OSPF, etc.) will flow across this bridge.
An SSL Orchestrator topology will then define a specific traffic pattern, by protocol (TCP, UDP, or non-TCP/non-UDP). Any incoming traffic that matches this pattern will be consumed by the topology listener, which handles that traffic as a full proxy to support dynamic service chaining and access to layer 3 and above security services. Traffic entering the topology listener will have a destination IP address of the remote target resource, and a destination MAC address of its gateway routing device (that it learned via ARP or other routing protocol advertisement). After processing SSL and decrypted flows to the service chain, virtual-wire will then copy the client-side L2 headers to the server-side packets and forward to the next hop. This presents a “virtual” layer 2 mode that allows the SSL Orchestrator to be both a bump-in-the-wire, and still control dynamic traffic flows to layer 3 and above security products.