Why cannot VRRP traffic be forwarded after MFF is enabled for S series switches

1

If MFF is enabled on an S series switch for Layer 2 isolation, an MFF entry is generated after a DHCP user goes online. The Gateway IP field in the MFF entry is the real gateway address.

VRRP has been enabled on the switch, so the Layer 3 gateway is a virtual VRRP gateway.

The destination MAC address and gateway IP address of the outgoing user packet are the virtual MAC address and virtual gateway address, which are different from those in the MFF entry. Therefore, VRRP traffic cannot be forwarded.

To solve this problem, change the gateway list of the DHCP server to the VRRP virtual gateway address. After a DHCP user re-logs in, its MFF entry is updated. The gateway IP address and MAC address in the MFF entry are the virtual gateway address and virtual MAC address, so VRRP traffic can be forwarded.

Other related questions:
Why cannot VRRP traffic be forwarded after MFF is enabled
If MFF is enabled on a device for Layer 2 isolation, an MFF entry is generated after a DHCP user gets online. The Gateway IP field in the MFF entry is the real gateway address. VRRP has been enabled on the device, so the Layer 3 gateway is a virtual VRRP gateway address. The destination MAC address and gateway IP address of the outgoing user packet are the virtual MAC address and virtual gateway address, which are different from those in the MFF entry. Therefore, VRRP traffic cannot be forwarded. To solve this problem, change the gateway list of the DHCP server as the VRRP virtual gateway address. After a DHCP user re-logs in, its MFF entry is updated. The gateway IP address and MAC address in the MFF entry are the virtual gateway address and virtual MAC address, so VRRP traffic can be forwarded.

Why cannot a DAI-enabled S series switch forward valid ARP packets at line rate
For S series switches, in versions earlier than V200R001, a DAI-enabled switch checks ARP packets based on ACL rules delivered to the chip. Therefore, packets are directly forwarded at line rate. In V200R001 and later versions, a DAI-enabled switch checks ARP packets and forwards valid ARP packets using software. The forwarding rate depends on factors such as the CPCAR value of the ARP packet and CPU usage. For E series switches, a DAI-enabled switch checks ARP packets and forwards valid ARP packets using software. The forwarding rate depends on factors such as the CPCAR value of the ARP packet and CPU usage.

Why cannot an S series switches learn ARP entries after Layer 3 forwarding is enabled on the switch's sub-interfaces
Q: Why cannot a switch learn ARP entries when connected to other devices after Layer 3 forwarding is enabled on the switch's sub-interfaces? A: In V100R002 and later versions, sub-interfaces of S series switches do not respond to ARP requests by default when Layer 3 forwarding is enabled on the sub-interfaces. The sub-interfaces respond to ARP requests only after the arp-proxy enable command is executed.

Some services are interrupted after IPSG is configured on an S series switch. Why
If some services are interrupted after IPSG is configured on an S series switch (except the S1700), possible causes include the following: 1. DHCP snooping is not enabled on a DHCP terminal or the DHCP terminal does not obtain an IP address again after DHCP snooping is enabled. As a result, the dynamic binding table does not contain correct information about the terminal. IP packets sent by the terminal are discarded, and the terminal cannot communicate with the network. Solution: Enable DHCP snooping on the terminal and make the terminal obtain an IP address again to generate a dynamic binding entry in the binding table. 2. No static binding entry corresponding to a static user is generated. As a result, the user cannot go online. Solution: Create a static binding entry for each authorized user connected to the switch. Note: After the ip source check user-bind enable command is configured on an interface or in a VLAN. The interface or VLAN matches all received IP packets against a binding table and discards those not matching the binding table.

Downlink traffic fails to be forwarded after an active/standby switchover of the uplink devices of S series switches
For an S series switch (except the S1700 switch�?, when an active/standby switchover is performed on its uplink devices, the IP address of the uplink device does not change, but the MAC address of the uplink device changes. The switch cannot detect this change in traffic, and does not update the ARP entry. Therefore, the downlink traffic fails to be forwarded. On the switch, the default aging time of ARP entries is 20 minutes. After ARP entries age, the switch relearns the ARP entry of the uplink devices, and the traffic path is restored. You can set a shorter ARP aging time to shorten the traffic interruption time. In V100R006 or later versions, you can run the mac-address update arp command to rapidly associate MAC address entries with ARP entries. (This function is not supported by S1720, S2720, S275x, or S5700LI fixed switches.) After the configuration, APR entries are updated when MAC address entries change, shortening traffic interruption time within seconds.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top