Example of using IPspaces
A common application for using IPspaces is when a Storage Service Provider (SSP) needs to connect customers of companies A and B to an ONTAP cluster on the SSP’s premises and both companies are using the same private IP address ranges.
The SSP creates SVMs on the cluster for each customer and provides a dedicated network path from two SVMs to company A’s network and from the other two SVMs to company B’s network.
This type of deployment is shown in the following illustration, and it works if both companies use non-private IP address ranges. However, the illustration shows both companies using the same private IP address ranges, which causes problems.
Both companies use the private IP address subnet 10.0.0.0, causing the following problems:
The SVMs in the cluster at the SSP location have conflicting IP addresses if both companies decide to use the same IP address for their respective SVMs.
Even if the two companies agree on using different IP addresses for their SVMs, problems can arise.
For example, if any client in A’s network has the same IP address as a client in B’s network, packets destined for a client in A’s address space might get routed to a client in B’s address space, and vice versa.
If the two companies decide to use mutually exclusive address spaces (for example, A uses 10.0.0.0 with a network mask of 255.128.0.0 and B uses 10.128.0.0 with a network mask of 255.128.0.0), the SSP needs to configure static routes on the cluster to route traffic appropriately to A’s and B’s networks.
This solution is neither scalable (because of static routes) nor secure (broadcast traffic is sent to all interfaces of the cluster).To overcome these problems, the SSP defines two IPspaces on the cluster—one for each company. Because no cross-IPspace traffic is routed, the data for each company is securely routed to its respective network even if all of the SVMs are configured in the 10.0.0.0 address space, as shown in the following illustration:
Additionally, the IP addresses referred to by the various configuration files, such as the
/etc/ hosts file, the
/etc/hosts.equiv file, and
the /etc/rc file, are relative to that IPspace. Therefore, the IPspaces enable the SSP to configure the same IP address for the configuration and authentication data for multiple SVMs, without conflict.