Why cannot VRRP traffic be forwarded after MFF is enabled

4

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.

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 VRRP traffic be forwarded after MFF is enabled for S series switches
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.

After the ARP gateway conflict function is enabled, why cannot traffic be forwarded based on the MAC address that is used to send ARP gateway conflict packets
After the ARP gateway conflict function detects the conflict ARP packets, the function will forbid all packets containing this source MAC address. The limit will be cancelled three minutes later.

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.

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