So far that is working like expected. ROUTER 1 is responding with it’s ether1 MAC to all arp-requests for hosts in NET-B(198.51.100.176/28).
But actually i have also ROUTER 2 which is connecting those networks. on both routers i have also a vrrp interface on top of ether1 and ether2. unfortunately if i put 198.51.100.128/26 on the vrrp with proxy-arp switched on it’s not responding to arp-requests as in the non-vrrp setup.
i have one vrrp setup (without arp-proxy) and the vrrp interface uses a /32 address
the vrrp interface learns ARP without problem but looks like from the router perspective the outbound traffic its going from the corresponding vlan (or physical) interface and address, and inbound traffic its going towards vrrp interface.
Maybe you need to enable proxy arp on the corresponding vlan (or physical) interface.
sure that works. as long as you have an non /32 ip from the net on the physical/vlan interface. The outbound traffic is than leaving on the physical interface as you have the connected route there.
learning is not the problem. responding to the requests is the part which isn’t working. usually the inbound traffic is towards the vrrp interface because your router has responded to the arp request with the virtual mac addr of the vrrp interface.
if i turn on proxy-arp on the physical interface the router response with the mac addr of the physical interface regardless of the status of the vrrp interface. In my case both routers would send a response with their own mac address instead of using the virtual mac addr of the vrrp interface.
It would be unpredictable towards which router the traffic would flow. That’s not even a real problem as both routers are able to forward the traffic to NET-B. But if one router fails traffic would stop working for all hosts/routers which had learned the mac address of the failing router.
Hi guys, I am facing the same issues and doubts. I am using a vrrp structure (two routers) where i need proxy-arp to reach a remote network also in my LAN address block.
I really do not understand why it is necessary to use a /32 virtual IP address for vrrp interface. I read the rfc and nothing like that is mencioned.
Even with my vrrp ip mask doubt (setting it with /32 and also with /24), the vrrp interface with arp=proxy-arp just not work. It only works if the real interface is set with proxy-arp.
I can’t face exactly what kind of issues could occur leeting the proxy-arp on the real interface.
Please, can someone clarify that, or confirm that’s a bug?
This may be very difficult. I know you necro’d an older post so I’ll start off with some basics.
Proxy-ARP means it will reply to ARP requests on a segment for any IP in it’s routing table.
VRRP means it will manage which router in a group of routers will reply to ARP requests for a particular IP address. The reason these are /32 addresses instead of a subnet mask of the underlying subnet comes back to duplicate IPs. If you have 2 routers with the same IP within a subnet that would be a problem, you can however have the same IP with a mask of /32. This is called anycast.
The desired state seems to be that the router which replies to ARP requests for the smaller subnet within a larger subnet is managed in a way that a router can be preferred over the other. Naturally, if you set Proxy-ARP on both larger subnet interfaces you’ll get an ARP reply from both routers. This has the knock-on effect of possibly popping duplicate IP warnings because 2 IP addresses claim to have the same MAC address.
A solution based on the original networks on the post (198.51.100.128/26 and 198.51.100.176/28):
Add each IP individually as a /32 to the VRRP interface which is a master interface has ether1 set (the larger network)
Disable Proxy-ARP
Do something with pre-routing mangle rules to forward the packet out of ether2 (apply a routing mark anything sourced in the larger network destined to the smaller network)
Add a /32 route for each IP in the routing table of both routers with a routing mark that is referenced in the mangle.
Sadly this solves the problem at layer 2 but at layer 3 the packets will all get routed to the VRRP interface. This is because the dst IP is actually presented on the device. You may be able to overcome this with some pre-routing mangle rules. I’ve hinted at a solution but I’m not in a position to test it.
A solution that’s more likely to work:
Manage the state of Proxy-ARP through scripting. By default enable it on Rtr1 with normal commands. Move to Rtr2 and enable Proxy-ARP only if Rtr1 cannot be reached. This can be done with a script local to Rtr2 or a node on the network via the API.