4.2.2. Networking Issues¶

Ports synchronization problems¶

Symptoms

Hints

If you are dealing with physical NIC: Check that your NIC is detected, using show state network-port.
Check that your fast path has been configured successfully.

Symptoms

show fast-path statistics shows no (or low) input/output_packets/bytes stats for your interface.
show interface statistics name <interface> shows no (or low) rx/tx.packets stats for the given interface.

Hints

Check whether configurations between Linux and the fast path are consistent:
- Check IP addresses and interfaces configured in the kernel are up and running, using show interface and show fast-path ports.
- Check that your bridges are up using show interface type bridge or show interface type bridge-slave.
Check IP addresses and routes known to the fast path, using show ipv4-routes.
Check that the fast-path-dropped statistics are not too high using show fast-path statistics global. A high fast-path-dropped stat suggests that packets are somehow not acceptable for the fast path. The ideal case is when forwarding stats are evenly spread throughout cores (when each core forwards almost the same number of packets as the others). See Fast Path statistics section for an example of stats.
Check that show fast-path statistics exception statistics are not too high. Basic exceptions indicate how many packets could not be processed by the fast path, and have thus been injected in the linux stack for slow path processing. If the value is high, it is a good indicator that IP addresses/routes/tunnels in the fast path are badly configured. See Fast Path statistics section for an example of stats.

Symptoms

VRRP reports master state on all members but no member receives packets intended for the VRRP virtual IP

Cause

The VMware VSwitch drops frames to MAC addresses that are unknown from the network card properties of the VM.

VRRP gives the ability to define a virtual IP that can move between machines. By design, the virtual IP is associated to a virtual MAC address - different from the real network card’s MAC address. Using a virtual MAC address instead of a real MAC address makes the switchover quicker as no update of ARP tables is needed. However, a Virtual MAC address is not supported by the VMware VSwitch. Unlike physical switches, the VSwitch has no MAC learning mechanism capability. The network section of the VM properties defines virtual network cards and one MAC address per card. The VSwitch only knows those addresses to determine on what port to send a frame. Frames to any unknown addresses, including virtual VRRP MAC addresses, are dropped.
VRRP uses multicast packets to send VRRP protocol messages between its members. Multicast packets use typical multicast MAC addresses that are also not known by the VSwitch.

Hints

One of the following solutions should be applied:

Warning: this solution may impact the performance on VMware hypervisor. Enable promiscuous mode on all VSwitches associated with the VLAN you want VRRP to run on. Basically, the VM will receive all traffic within the VSwitch VLAN. Refer to https://kb.vmware.com/s/article/1002934 for more information.
Set up the VRRP instance to disable the usage of a virtual MAC address “vmac” and to use manual unicast peers to exchange VRRP protocol data unit instead of using multicast. This solution is only applicable to VMware and should not be applied on any other context without an explicit request from support. In this mode, the virtual IP address is associated to the real NIC MAC address of the active member. Upon member switchover, a gratuitous ARP is sent to advertise other machines to update their ARP table with the new MAC. You must ensure and test that gratuitous ARP are treated correctly by all machines. If not, some machines would lose connectivity until the ARP cache timeout expires.