#276 Legacy logic error - Servers on PEPs rather than Nets

[John A. Sullivan III]

We have a very serious logic error where we have associated Servers with PEPs rather than with networks. This requires a major rewriting of several parts of the code and major database changes. This has been described in the PEPFunctions document under both Delete Protected Network and The Internal Scenario. Here is an excerpt from Delete Protected Network:

For example, let's assume there are three protected networks on a PEP, specifically, 10.1.1.0/26, 10.1.1.0/25 and 10.1.1.0/24. Let's also assume there are three servers at 10.1.1.10, 10.1.1.120, and 10.1.1.254. Let's now assume we choose to delete 10.1.1.0/26 and 10.1.1.0/24. With no culling, we would think we should orphan the 10.1.1.10 and 10.1.1.254 servers. In reality, we will not orphan 10.1.1.10 because it will still find a home within 10.1.1.0/25. Our challenge is to not seek orphans on deleted networks which have a non-deleted SuperNet. This must be distinguished from deleted networks which have a SuperNet which is also being deleted. We have a complication if the SuperNet resides on a different PEP; then we must move the Resources and Accessors to the new PEP. We should prompt the user to confirm they approve of moving them to the new PEP rather than deleting them. We must also address the issue where there are SubNets which are not being deleted. We should do nothing at all to those Resources and Accessors as they remain unchanged in their current SubNet and on the SubNet's PEP.
Uh-oh. We have a serious and fundamental logic error. Servers should be associated with networks and not PEPs. We already realized this in our outline for changing ISCS to allow multiple PEPs to connect to the same network but there is a serious implication for this particular logic. In two ways. First, remapping orphaned Resources into SubRanges and SuperRanges may make mathematical sense but it does not necessarily make physical sense even on the same PEP, e.g., the rare configuration with multiple PEPs connected to the same network where one PEP is connected only to 10.1.1.0/26 (to use the above example) and another is connected to all three networks - well there it doesn't make mathematical sense either but the point is that the server may or may not be physically moving to the SuperRange even if it is mathematically possible. We must ask the user. SubRanges are also problematic because we currently allow the creation of Resources with sub-optimal routing, e.g., one can create a 10.1.1.5 Resource on the 10.1.1.0/24 network using the example above even though the best match routing is 10.1.1.0/26. We warn the user but do not prevent it in case there is a legitimate reason such as the above example where not all PEPs attach to all the networks. Since we allow this, it is impossible to know if the 10.1.1.10 server (using the above example) lives on the 10.1.1.0/26, /25, or /24 network as long as Servers are associated with PEPs. As an interim step, we will disallow the creation of suboptimal addresses but this is a serious disability. We will need to re-enable it as soon as we release the version of ISCS which corrects the Server association logic error.

[John A. Sullivan III]

I have temporarily disabled suboptimally routed IP addresses in IPPairManager::protectedCheck()