Support for CRC Checks for VirtualWire Mode
A switch running in VirtualWire Mode currently interpret the CRC header of the packets passing through. This achieves perfect transparency of the switch. Howeve rNetvisor places limitations on the types of vFlows created on the switch, as any vFlow that modifies the packet renders the CRC on that packet invalid without updating it.
With this Netvisor One release, the CRC regeneration is a configurable option per port, so the you can decide on a per-port basis whether the switch should, or should not perform CRC regeneration.
Figure 1 - Example Virtual Wire Mode Topology
On the virtual-wire switch, if you want to convert traffic on port 43 tagged with VLAN 101 to be tagged with VLAN 102 so Host1 and Host2 can communicate as if the two hosts are on the same VLAN, then you configure the following two vFlows:
CLI (network-admin@Leaf1) > vflow-create name vlan_map_101_102 scope local table L1-Virtual-Wire-1-0 vlan 101 in-port 43 precedence 15 action setvlan action-value 102 action-to-ports-value 39
CLI (network-admin@Leaf1) > vflow-create name vlan_map_102_101 scope local table L1-Virtual-Wire-1-0 vlan 102 in-port 39 precedence 15 action setvlan action-value 101 action-to-ports-value 43
However, the packets with a different VLAN now have an incorrect CRC value unless the CRC is updated when egressing the port.
The following command is now available in Netvisor One:
CLI (network-admin@Leaf1) > port-config-modify port 39,43 crc-check-enable
After this configuration, any packets egressing from ports 39 and 43 are updated with the CRC check.
Note: The parameter, crc-check-enable is only available on switches in Virtual Wire mode. Furthermore, when the switch mode changes to VirtualWire mode, Netvisor configures all ports as crc-check-disable by default.