Manual Chapter :
Forwarding behavior and user actions
Applies To:
Show Versions
BIG-IP AAM
- 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP APM
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP Analytics
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP Link Controller
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP LTM
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP PEM
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP AFM
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP DNS
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP ASM
- 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
Forwarding behavior and user actions
When an interface in virtual wire mode receives traffic, it first tries to associate the
traffic with a VLAN defined on the virtual wire and then looks for a matching virtual server. If
a virtual server is found, the forwarding action is determined by the policies configured on the
virtual server.
This table describes how the BIG-IP® system handles certain conditions
when the relevant interfaces are configured to use a virtual wire. The table also shows what
actions you can take, if possible.
Condition | Default Behavior | User Action |
|---|---|---|
No VLAN for tagged traffic is found. | If the traffic is tagged but there is no VLAN for that traffic, the virtual wire
dynamically creates data-path objects that enable the system to engage the forwarding path.
| None. |
No VLAN for untagged traffic is found. | Unlike for tagged traffic, where a specific VLAN is not needed, a virtual wire needs a
specific VLAN to associated with untagged traffic. | Be sure to configure an untagged VLAN on the relevant virtual wire interface to enable
the system to correctly handle untagged traffic. Note that many Layer 2 protocols, such as
Spanning Tree Protocol (STP), employ untagged traffic in the form of BPDUs. |
An "any" VLAN group and a VLAN configured for specific traffic exist, but there is no
virtual server for the specific traffic. | A virtual wire object can include both an "any" VLAN group and a separate VLAN that's
configured to handle specific traffic. If the only virtual server you create is the one that
listens for the VLAN group traffic and not specific traffic, the virtual server configured to
listen for traffic on the VLAN group behaves like a wildcard virtual server. That is, the
virtual server accepts all traffic for the virtual wire, including the traffic intended for
the specific VLAN. | Although not a requirement, consider creating a separate virtual server to match
specific traffic being forwarded. |
No virtual server for tagged traffic is found. | If there is no matching vitual server for tagged traffic, a virtual wire forwards the
traffic at Layer 2, ignoring headers at Layer 3 and above. However, even in this case the
system keeps a "connection" state with a default age of 300 seconds. With a large number of
TCP connections, this can cause temporary spikes in memory use. The system eventually clears
these memory spikes through idle timeouts. | Create one or more virtual servers that match tagged TCP traffic on the virtual wire.
Or, if unsure of the traffic types, you can create a wildcard virtual server. By creating
matching or wildcard virtual servers, you can prevent such spikes in memory use. The type of
virtual servers you create should be either Forwarding (IP) or Performance (Layer 4). This
enables the system to close connections much faster and therefore improve system performance.
Alternatively, you can configure a lower idle timeout threshold using the tmsh command
sys db tm.l2forwardidletimeout <value> . |
Layer 2 BPDU traffic. | As long as the virtual wire is able to associate the Layer 2 BPDUs to a VLAN (tagged or
untagged), the system forwards all Layer 2 BPDU traffic to the peer interface. | Because many Layer 2 protocols employ untagged BPDUs, it's a good idea to make sure you
have both tagged and untagged VLANs on the virtual wire for forwarding BPDUs. |
