#11 Better ARP conflict resolution

[John A. Sullivan III]

We need better handling of ARP conflicts in the case where multiple PEPs share the same public network. This is an issue for NAT since only one of the PEPs can claim an IP address. For example, if the public network is 1.1.1.0/24 and I have a web server behind PEP1 which wants to NAT to 1.1.1.5 and I have an FTP server behind PEP2 which wants to NAT to 1.1.1.5, I cannot do that even though they are different services as the ARP request contains no service information but only IP address information.

In the current logic, we disallow any conflicting ARPs including supernet/subnet relationships. To use the above example, let's suppose the web server NATS to 1.1.1.3 - 1.1.1.10, we would still disallow the FTP server at 1.1.1.5 on a different PEP. A better scenario would be to offer the user a choice to exclude 1.1.1.5 from the web server (and any other conflicting NAT ranges, e.g., a mail server at 1.1.1.4 - 1.1.1.6) or cancel the NAT for the FTP server. This is very similar to the NAT Postures logic but we cannot use NAT postures because they are service specific. We would need another database table, something like arp_postures, which would track IP level conflicts.

[Anonymous]

This requires revisiting how we check for other conflicts, e.g., when creating a new IP Resource, readdressing a network, creating a new public IP address on a PEP. The current routines assume all conflicts are with addresses on the same PEP because the ARP conflict check would eliminate any conflicts with addresses on other PEPs. That assumption may be invalidated with this change.