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. They 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 path discovery 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.


    • Use the following table to explore the primary differences between the layer 2 and layer 3 topology modes:


    Feature

    Layer 3

    Layer 2

    Transparent forward proxy

    Yes

    Yes

    Explicit forward proxy

    Yes

    No

    Reverse proxy

    Yes

    Yes

    Inline layer 2 security services

    Yes

    Yes

    Inline layer 3 security services

    Yes

    Yes

    Inline HTTP security services

    Yes

    Yes

    ICAP security services

    Yes

    Yes

    TAP security services

    Yes

    Yes

    WAF security service (inbound)

    Yes

    Yes

    SWG security service (outbound)

    Yes

    Yes

    High availability

    Yes

    Yes

    802.3ad LACP

    Yes

    Yes

    802.1q VLAN trunking

    Yes

    Yes

    802.1d Spanning tree

    Yes

    Yes

    IPv6

    Yes

    Yes

    vCMP

    Yes

    No

    Native sub-second HA failover

    Yes

    No


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.

Before starting the configuration, ensure the following system DB variables are set appropriately. SSL Orchestrator automatically sets many of these variables for an L2 topology configuration, but in the event of failure it might be useful to verify.

Name

Default

Required

Comments

bcm56xxd.vwire.4kvlans

disable

enable

Allows dynamic creation of VLANs under the virtual wire

l2.virtualwire.standby.bridging

disable

disable

Enable/disable L2 virtual wire bridging for standby box

tm.rstcause.pkt

disable

enable

Only for debugging purposes, logs the reset reason from RST packet

tm.rstcause.log

disable

enable

Only for debugging purposes, sends the reset reason to the LTM log

vlangroup.forwarding.override

enable

disable

If enabled, VLAN group listeners are given priority over the wildcard forwarding listener 0.0.0.0/0. This must be disabled for vwire mode.

connection.vlankeyed

enable

enable

If enabled, asymmetrically-routed connections will fail.

l2.virtualwire.multicast.bridging

enable

enable

Enable/disable L2 virtual wire multicast bridging.

l2.virtualwire.multicast.stats

enable

enable

Enable/disable collection of L2 virtual wire multicast statistics.

tm.rejectunmatched

true

false

If set to true, BIG-IP will send a RST on unmatched TCP connections.


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. To enable LACP, add ‘lacp enabled’ to the end of the following commands.

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

Step 5 - Save the configuration

tmsh save sys config partitions all

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).

  • You should not define non-TCP and non-UDP protocol listeners when configuring virtual-wire. Non-TCP and non-UDP traffic (like ARP) must flow through the virtual-wire VLAN group bridge. This includes any L2 path discovery protocols (ex. STP, CDP). BIG-IP HA failover in virtual-wire mode requires the upstream/downstream nexthop devices to pass path discovery traffic through the BIG-IP. The path discovery traffic will be blocked at the VLAN group bridge on the standby BIG-IP device.

  • Not all interfaces on a virtual wire compatible platform (iSeries i5000+) can be used with virtual wire. L2 transparency requires that interfaces supporting L2-wire be mapped to logical ports 0-31 due to the destination port of the HiGig header being 5 bits. To understand which interfaces are mapped to logical ports 0-31, run the following command from the BIG-IP console shell:

    guishell -c "select name,PHYSPORT from interface order by PHYSPORT"
    

    Also note that the management port may be assigned to logical port 0, so only ports 1-31 can support virtual wire.


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 and 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.

For additional information on configuring and troubleshooting an L2 vwire deployment, please see the following resource:

https://community.f5.com/t5/technical-articles/virtual-wire-configuration-and-troubleshooting/ta-p/291263


2.7.4. Additional Information

If Border Gateway Protocol (BGP) must flow through your SSL Orchestrator virtual-wire configuration, note that BGP is a TCP protocol. In some cases, attempting to pass BGP through a service chain can cause issues. The best way to avoid this is to manually create a separate forwarding virtual server to catch the BGP.

BGP Forwarding Virtual Server

User Input

Type

FastL4

Source

Enter 0.0.0.0/0 here to allow all BGP traffic to pass through, or filter as required.

Destination Address/Mask

Enter 0.0.0.0/0.

Port

Enter port 179 for BGP.

Protocol

Select TCP.

VLANs

Select the appropriate VLAN(s).

Address Translation

Set to disabled.

Port Translation

Set to disabled.

Either set a system route or define a gateway pool and apply to the above virtual server.



If Open Shortest Path First (OSPF) must flow through your SSL Orchestrator virtual-wire configuration, you may be required to create a separate forwarding virtual server to specifically handle OSPF. OSPF packets have a TTL value of 1. When traffic through any virtual server (apart for default virtual server _vlangroup) the TTL value will be decremented by 1 (as expected) which makes the TTL change to 0. This results in OSPF packets being dropped in the network. The solution here is to create a virtual server with FastL4 for OSPF and use the option to preserve the TTL. The default for a fastL4 profile is to decrement.

# tmsh list ltm profile fastl4 ospf
ltm profile fastl4 ospf {
   app-service none
   defaults-from fastL4
   ip-ttl-mode preserve
}

# tmsh list ltm virtual
ltm virtual ospf_fastl4 {
   creation-time 2021-02-05:20:33:15
   destination 0.0.0.0:any
   ip-protocol ospf
   last-modified-time 2021-02-05:20:37:35
   mask 255.255.255.255
   profiles {
      ospf { }
   }
   serverssl-use-sni disabled
   source 0.0.0.0/0
   translate-address disabled
   translate-port disabled
   vs-index 3
}