tcpdump Output with Workaround

Oct 13, 2025 by pynkocean.com 31 views

VRRP - ARP Requests for the Virtual IP are Answered with the MAC of the Physical Interface

VRRP (Virtual Router Redundancy Protocol) is a protocol used to provide high availability and redundancy in network environments. It allows multiple routers to share the same IP address, ensuring that traffic is always routed through the active router. However, in some cases, the master router may respond to ARP (Address Resolution Protocol) requests for the virtual IP with the MAC (Media Access Control) address of the physical interface, rather than the MAC address of the virtual interface. This article will explore the reasons behind this behavior and provide a solution to the problem.

The master router is a Debian 12 VM running on Virtualbox with NAT networks and promiscuous mode enabled. The FRR (FRRouting) version is 8.4.4. The configuration includes two interfaces: eth2 and macvlan6_1. The eth2 interface has an IP address of 172.16.200.61, while the macvlan6_1 interface has an IP address of 172.16.200.66. The VRRP configuration is set up on the eth2 interface, with the virtual IP address 172.16.200.66.

When a ping is sent to the virtual IP 172.16.200.66, the ARP request is sent to the broadcast address ff:ff:ff:ff:ff:ff. However, the response is sent with the MAC address of the physical interface 08:00:27:64:c5:20, rather than the MAC address of the virtual interface 00:00:5e:00:01:01.

tcpdump Output

The tcpdump output shows the ARP request and response:

listening on eth2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:18:15.745326 08:00:27:54:59:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.200.66 tell 172.16.200.40, length 46
17:18:15.745352 08:00:27:64:c5:20 > 08:00:27:54:59:80, ethertype ARP (0x0806), length 42: Reply 172.16.200.66 is-at 08:00:27:64:c5:20, length 28

To resolve the issue, a routing rule was created to force packets originated from the virtual IP to be routed through the macvlan6_1 interface. A new table 555 was created with the entry 172.16.200.0/24 dev macvlan6_1 scope link. Additionally, promiscuous mode was enabled on the macvlan6_1 interface. With this configuration, the master responds correctly to ARP requests.

tcpdump Output with Workaround

The tcpdump output with the workaround shows the correct ARP response:

listening on eth2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:28:18.529071 08:00:27:54:59:80 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.200.66 tell 172.16.200.40, length 46
17:28:18.529120 00:00:5e:00:01:01 > 08:00:27:54:59:80, ethertype ARP (0x0806), length 42: Reply 172.16.200.66 is-at 00:00:5e:00:01:01, length 28

In conclusion, the issue of ARP requests for the virtual IP being responded with the MAC address of the physical interface is due to the way the VRRP protocol handles ARP requests. The workaround solution involves creating a routing rule to force packets originated from the virtual IP to be routed through the virtual interface. By enabling promiscuous mode on the virtual interface, the master responds correctly to ARP requests.

Verify that the VRRP configuration is set up correctly on the master router.
Ensure that the virtual interface is configured with the correct MAC address.
Create a routing rule to force packets originated from the virtual IP to be routed through the virtual interface.
Enable promiscuous mode on the virtual interface.

By following these recommendations, network administrators can resolve the issue of ARP requests for the virtual IP being responded with the MAC address of the physical interface.
VRRP - ARP Requests for the Virtual IP are Answered with the MAC of the Physical Interface: Q&A

Q: What is the cause of the issue where ARP requests for the virtual IP are responded with the MAC address of the physical interface?

A: The issue is caused by the way the VRRP protocol handles ARP requests. When a VRRP master responds to an ARP request for the virtual IP, it uses the MAC address of the physical interface instead of the MAC address of the virtual interface.

Q: Why does the VRRP master use the MAC address of the physical interface instead of the virtual interface?

A: The VRRP master uses the MAC address of the physical interface because it is the default behavior of the VRRP protocol. The virtual interface is not used by default, and the MAC address of the physical interface is used instead.

Q: How can I resolve the issue and get the VRRP master to respond with the MAC address of the virtual interface?

A: To resolve the issue, you need to create a routing rule to force packets originated from the virtual IP to be routed through the virtual interface. You also need to enable promiscuous mode on the virtual interface.

Q: What is promiscuous mode, and why is it needed?

A: Promiscuous mode is a feature of network interfaces that allows them to receive and process all packets on the network, not just those addressed to the interface itself. In this case, promiscuous mode is needed to allow the virtual interface to receive and process ARP requests for the virtual IP.

Q: How do I enable promiscuous mode on the virtual interface?

A: To enable promiscuous mode on the virtual interface, you need to add the promiscuous option to the interface configuration. For example, if you are using the ip command to configure the interface, you can add the promiscuous option like this:

ip link set macvlan6_1 promiscuous on

Q: What are the benefits of using the virtual interface instead of the physical interface?

A: Using the virtual interface instead of the physical interface has several benefits, including:

Improved security: By using the virtual interface, you can isolate the virtual IP from the physical interface and prevent unauthorized access.
Improved performance: By using the virtual interface, you can improve the performance of the network by reducing the amount of traffic that needs to be processed by the physical interface.
Improved flexibility: By using the virtual interface, you can easily move the virtual IP to a different physical interface or network without having to reconfigure the network.

Q: Are there any other issues that I should be aware of when using VRRP?

A: Yes, there are several other issues that you should be aware of when using VRRP, including:

ARP cache poisoning: This is a type of attack where an attacker sends fake ARP responses to the network, causing the ARP cache to be poisoned and leading to network instability.
VRRP packet loss: This is a type of issue where VRRP packets are lost or corrupted, leading to network instability and potential data loss.
VRRP configuration errors: This is a type of issue where the VRRP configuration is incorrect or incomplete, leading to network instability and potential data loss.

By being aware of these issues and taking steps to prevent them, you can ensure that your VRRP implementation is stable and secure.