Virtual-wire Configuration and Troubleshooting

A virtual wire(vWire) logically connects two interfaces or trunks, in any combination, to each other, enabling the BIG-IP system to forward traffic from one interface to the other, in either direction. This type of configuration is typically used for security monitoring, where the BIG-IP system inspects ingress packets without modifying them in any way.

To deploy a BIG-IP system without making changes to other devices on your network, you can configure the system to operate strictly at Layer 2. By deploying a virtual wire configuration, you transparently add the device to the network without having to create self IP addresses or change the configuration of other network devices that the BIG-IP device is connected to.

Topology

Before vWire Deployment

After vWire Deployment

Few points about virtual wire configurations in general:

vWire works in transparent mode,which means there is no packet modification
The system bridges both tagged and untagged packets
Neither VLANs nor MAC addresses change in Symmetry mode
propagate virtual wire link: When enabled, the BIG-IP system changes the peer port state to down when the corresponding interface is disabled or down. If disabled, the BIG-IPsystem does not change the peer port state

Configuring vWire in UI BIG-IP

Navigate to Network>>Virtual Wire
Select Create (upper right)
Enter the values for interfaces added to the virtual wire
Enter VLAN information and click on Add for every VLAN object created
Recommended- Enable propagate virtual wire link status for detecting link failure

Once all the selections are made and you are ready to implement, click on "Commit Changes to System":

The resulting screen will look like the following:

The resulting VLAN configuration will look as follows:

Note: 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.

Configuring vWire in cli mode

Configure interfaces to support virtual wire:

tmsh modify net interface 1.1 port-fwd-mode virtual-wire
tmsh modify net interface 1.2 port-fwd-mode virtual-wire

Create all VLAN tag VLAN objects:

tmsh create net vlan Direct_all_vlan_4096_1 tag 4096 interfaces add { 1.1 { tagged } }
tmsh create net vlan Direct_all_vlan_4096_2 tag 4096 interfaces add { 1.2 { tagged } }

Create specific (802.1Q tag 512) VLAN objects:

tmsh create net vlan Direct_vlan_512_1 tag 512 interfaces add { 1.1 { tagged } }
tmsh create net vlan Direct_vlan_512_2 tag 512 interfaces add { 1.2 { tagged } }

Create VLAN Groups:

tmsh create net vlan-group Direct_all_vlan members add { Direct_all_vlan_4096_1 Direct_all_vlan_4096_2 } mode virtual-wire
tmsh create net vlan-group Direct_vlan_512 members add { Direct_vlan_512_1 Direct_vlan_512_2 } mode virtual-wire

config save:

tmsh save sys config partitions all

vWire config with trunk with LACP and LACP Pass Through

LACP Pass through feature tunnels LACP packets through trunks between switches. Configure an untagged VLAN on the virtual wire interface to tunnel LACP packets.

Note: Propagate virtual wire link status should be enabled for LACP pass through mode.LACP Pass through and Propagate virtual wire link status is supported from 16.1.x

Configuring LACP Pass Through

Configuring interface to support in vwire mode:

tmsh modify net interface 1.1 port-fwd-mode virtual-wire
tmsh modify net interface 2.1 port-fwd-mode virtual-wire
tmsh modify net interface 1.2 port-fwd-mode virtual-wire
tmsh modify net interface 2.2 port-fwd-mode virtual-wire

Configure trunk :

tmsh create net trunk left_trunk_1 interfaces add { 1.1 2.1 } qinq-ethertype 0x8100 link-select-policy auto
tmsh create net trunk right_trunk_1 interfaces add { 1.2 2.2 } qinq-ethertype 0x8100 link-select-policy auto

Configure VLAN tagged and untagged interface:

tmsh create net vlan left_vlan_1_4k tag 4096 interfaces add {left_trunk_1 {tagged}} 
tmsh create net vlan left_vlan_1 tag 31 interfaces add {left_trunk_1 {tagged}}
tmsh create net vlan left_vlan_333 tag 333 interfaces add {left_trunk_1 {untagged}}
tmsh create net vlan right_vlan_1_4k tag 4096 interfaces add {right_trunk_1 {tagged}}
tmsh create net vlan right_vlan_1 tag 31 interfaces add {right_trunk_1 {tagged}}
tmsh create net vlan right_vlan_333 tag 333 interfaces add {right_trunk_1 {untagged}}

Create VLAN Group and enabled propagate-linkstatus:

tmsh create net vlan-group vg_1_4k bridge-traffic enabled mode virtual-wire members add { left_vlan_1_4k right_vlan_1_4k } vwire-propagate-linkstatus enabled 
tmsh create net vlan-group vg_untagged bridge-traffic enabled mode virtual-wire members add { left_vlan_333 right_vlan_333 } vwire-propagate-linkstatus enabled
tmsh create net vlan-group vg_1 bridge-traffic enabled mode virtual-wire members add { left_vlan_1 right_vlan_1 } vwire-propagate-linkstatus enabled

configuring LACP(Active-Active) mode

Configuring interface to support in vwire mode:

tmsh modify net interface 1.1 port-fwd-mode virtual-wire
tmsh modify net interface 1.2 port-fwd-mode virtual-wire
tmsh modify net interface 2.1 port-fwd-mode virtual-wire
tmsh modify net interface 2.2 port-fwd-mode virtual-wire

Configure trunk in LACP Active mode :

tmsh create net trunk left_trunk_1 interfaces add { 1.1 1.2 } qinq-ethertype 0x8100 link-select-policy auto lacp enabled lacp-mode active
tmsh create net trunk right_trunk_1 interfaces add { 2.1 2.2 } qinq-ethertype 0x8100 link-select-policy auto lacp enabled lacp-mode active

Configure VLAN tagged interface:

tmsh create net vlan left_vlan_1_4k tag 4096 interfaces add {left_trunk_1 {tagged}}
tmsh create net vlan left_vlan_1 tag 31 interfaces add {left_trunk_1 {tagged}}
tmsh create net vlan right_vlan_1_4k tag 4096 interfaces add {right_trunk_1 {tagged}}
tmsh create net vlan right_vlan_1 tag 31 interfaces add {right_trunk_1 {tagged}}

Create VLAN Group and enabled propagate-linkstatus:

tmsh create net vlan-group vg_1_4k bridge-traffic enabled mode virtual-wire members add { left_vlan_1_4k right_vlan_1_4k } vwire-propagate-linkstatus enabled 
tmsh create net vlan-group vg_1 bridge-traffic enabled mode virtual-wire members add { left_vlan_1 right_vlan_1 } vwire-propagate-linkstatus enabled

DB variables for vWire:

Trouble shooting vWire :

1 . Verify that traffic flowing through default Virtual Server(_vlangroup)

Tcpdump cmd: tcpdump -nne -s0 -i 0.0:nnn
22:00:53.398116 00:00:00:00:01:31 > 33:33:00:00:00:05, ethertype 802.1Q (0x8100), length 139: vlan 31, p 0, ethertype IPv6, fe80::200:ff:fe00:131 > ff02::5: OSPFv3, Hello, length 40 out slot1/tmm9 lis=_vlangroup
22:00:53.481645 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype 802.1Q (0x8100), length 91: vlan 31, p 0, ethertype IPv4, 10.31.0.3 > 224.0.0.18: VRRPv3, Advertisement, vrid 1, prio 150, intvl 100cs, length 12 out slot1/tmm4 lis=_vlangroup

2. Now create Virtual Server based on requirements like TCP, UDP and ICMP with Virtual Server name as test.Verify traffic is hitting Virtual Server

Tcpdump cmd: tcpdump -nne -s0 -i 0.0:nnn
22:04:54.161197 3c:41:0e:9b:01:31 > 00:00:00:00:03:31, ethertype 802.1Q (0x8100), length 145: vlan 31, p 0, ethertype IPv4, 10.20.0.10 > 10.13.0.10: ICMP echo request, id 30442, seq 2, length 64 out slot4/tmm2 lis=/Common/test
22:05:14.126544 3c:41:0e:9b:01:31 > 00:00:00:00:03:31, ethertype 802.1Q (0x8100), length 121: vlan 31, p 0, ethertype IPv4, 10.20.0.10.41692 > 10.13.0.10.80: Flags [S], seq 2716535389, win 64240, options [mss 1460,sackOK,TS val 685348731 ecr 0,nop,wscale 7], length 0 out slot3/tmm8 lis=/Common/test
22:05:14.126945 3c:41:0e:9b:03:31 > 00:00:00:00:01:31, ethertype 802.1Q (0x8100), length 121: vlan 31, p 0, ethertype IPv4, 10.13.0.10.80 > 10.20.0.10.41692: Flags [S.], seq 1173350299, ack 2716535390, win 65160, options [mss 1460,sackOK,TS val 4074187325 ecr 685348731,nop,wscale 7], length 0 in slot3/tmm8 lis=/Common/test

3 . Trouble Shooting steps

Get the tcpdump and check the traffic hitting Virtual Server or not
If traffic is dropped, enable “tmsh modify sys db vlangroup.forwarding.override value enable” with destination as catch all and check whether traffic is hitting _vlangroup and going out or not. If traffic is going without any issue, then there is an issue with created virtual server.
Even after enabling vlangroup.forwarding.override db variable, then take the output of below commands
tmctl ifc_stats - displays interface traffic statistics
tmctl ip_stat - displays ip traffic statistics
tmctl ip6_stat - displays ipv6 traffic statistics

vWire Behavior

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

Notable Effects-Caveats

When deploying a pair of BIG-IP’s in HA mode, the virtual wire configuration will create objects with different names on each BIG-IP. So for example, the creation of vwire_lab01 will result in the creation of VLAN objects vwire_lab01_1_567 and vwire_lab01_2_567 on one BIG-IP, while the other BIG-IP will have vwire_lab01_1_000 and vwire_lab01_2_000 in its configuration. For modules like SSL Orchestrator, or in cases where a Virtual Server needs to be associated with a specific VLAN, the numbering is problematic. The administrator will not be able to associate the topology or Virtual Server to one VLAN object (vwire_lab01_2_567) on the first BIG-IP and the other VLAN object (vwire_lab01_2_000) on the peer BIG-IP. (this is not possible for a number of reasons, one of which is the way configurations are synchronized between BIG-IP devices)
Q-in-Q is not supported in a virtual wire configuration
Virtual wire feature is not supported on Virtual Clustered Multiprocessing (vCMP)
Active/Active deployment is not supported
vWire is not supported on virtual edition(VE)

Conclusion

BIG-IP in Virtual Wire can be deployed in any network without any network design or configuration changes, as it works in L2 transparent mode.

L2Transparency Caveats

There are few caveats with respect to L2 Transparency

OSPF neighborship struck in exstart state.
BGP neighborship won’t come with MD5 authentication

OSPF neighborship struck in exstart state

In transparent mode when standard Virtual server is configured, the VS will process the DBD packet with this the TTL value become zero and the OSPF neighborship will struck at Exstart state.

To solve the above problem, we need to configure a profile to preserve the TTL value and attach the profile to the virtual server.

Below are the steps to configure the profile and the virtual server. Same steps can be configured for both vwire and vlangroup

Create a profile to preserve TTL

Click on create and enter the profile name as TTL and select to preserve

Now attach the profile under ipother

After attaching the profile the OSPF neighborship will come up.

BGP neighborship won’t come with MD5 authentication

In transparent mode when standard Virtual server is configured, the VS will process the BGP packet and will reply back to the tcp connection without MD5 with BGP wont come up between two devices

To solve the above problem, we need to configure a profile to support Md5 authentication and attach the profile to the virtual server.

Below are the steps to configure the profile and the virtual server. Same steps can be configured for both Vwire and Vlan-group