local-proxy-arp and arp-populate

local-proxy-arp and arp-populate are two commands that are relevant only to IPoEv4 hosts.

The local-proxy-arp command ensures that the router answers ARP Requests with its own MAC address for any active IPv4 address under the subnet on which the ARP request arrived. The active IPv4 address is considered the one that is assigned to an already instantiated hosts or the default-gw (even auto-generated).

In absence of local-proxy-arp command, the only ARP Request that the router’s answer is the one for the statically configured IPv4 addresses of the subscriber-interface. In flexible IPv4 addressing, the IPv4 address of the default-gw does not necessarily match any of the configured subscriber-interface IPv4 addresses. The ARP Request for such default-gw IPv4 address would go unanswered. Consequently, the subscriber hosts would not be able to communicate with outside world. Therefore, the flexible IPv4 addressing requires that the local-proxy-arp command is configured.

The arp-populate command disables dynamic learning of ARP entries (IPv4<->MAC mapping) on an interface based on the ARP protocol. In this case, the ARP table is populated based on the DHCPv4 lease state table which contains IPv4<->MAC mappings obtained through DHCP processing during the host instantiation phase. Arp-populate functionality is highly desirable in case of flexible IPv4 addressing.

When the arp-populate command is disabled the ARP entries are dynamically learned based on the ARP protocol. This, in conjunction with flexible IPv4 addressing may cause issues. Consider the following example:

In this case, downstream traffic toward the subscriber host triggers the router to send ARP request for the subscriber host IPv4 address. The router must know the MAC address of the subscriber-host to forward traffic. Because the subscriber interface is unnumbered, the source IPv4 address of the ARP request is unknown and consequently, the ARP request are not sent. As a result, downstream traffic is dropped.

However, the above example is an unlikely scenario. If the subscriber host sends the ARP request for the default-gw first, the router would create an entry in the ARP table for it and the issue would be resolved. This is the most likely outcome because the subscriber host always tries to initiate communication with the outside and therefor ARP for the IPv4 address of the default-gw (which is a 7450 ESS and 7750 SR).