In this NetApp training tutorial, I will explain the NetApp IPspaces, the fourth post in our NetApp networking video tutorial series. Links for the other videos in the series are at the bottom of the page. Scroll down for the video and also text tutorial.
NetApp IPspaces Networking Video Tutorial
I have been in a couple of classroom Netapp Bootcamp trainings but this course is much better and in-depth. It takes you from the core to the nitty gritty.
What are NetApp IPspaces?
NetApp IPspaces allow Storage Virtual Machines (SVMs) which are in the same cluster to have the same (overlapping) subnets and IP addresses. The IPspaces feature became available in NetApp Custered ONTAP version 8.3. In previous versions of the operating system, Data Logical Interfaces (LIFs) in the same cluster had to have unique IP addresses. Now, with the IPspace functionality, LIFs in different SVMs can have the same IP address as each other.
NetApp IPspace uses
Let’s clear a possible misconception up first: IPspaces are not required for secure multi-tenancy, SVMs provide that functionality. The secure multi-tenancy capability was already available prior to Clustered ONTAP v8.3. The purpose of IPspaces is simply to allow the use of the same IP address on multiple SVMs in the cluster.
Hopefully right now you’re thinking ‘wait – why would I ever want to have duplicate IP addresses on my SVMs?! I’d have to have some kind of weird network to need that.’ You’re right, it’s not a commonly used feature. In the vast majority of deployments you can just leave everything in the Default IPspace and forget that the feature even exists.
Cases where the feature could be required though include:
- Service provider environments (different clients may use the same subnets)
- Mergers (merging companies may have overlapping IP subnets)
- Migration from 7-Mode Multi-store environments
7-Mode already supported similar functionality through VFilers, also known as the Multistore feature. This was the 7-Mode equivalent of SVMs and already supported duplicate IP addresses.
NetApp IPspace and SVMs
Multiple SVMs can be in the same IPspace. All LIFs, by default, are members of the default IPspace. If you don't need to support overlapping addresses, the default configuration can be left as is. In many cases, you will not need to configure any IPspaces so you can just forget about them. The default IPspace will still exist and everything will be in it. As long as we don't have overlapping addresses, we don't need to configure any duplicate IP addresses on our LIFs.
Similarity with VRF’s
With IPspaces, each SVM maintains its own routing table. IPspaces are the NetApp equivalent of Virtual Routing and Forwarding tables (VRFs), which is a technology that allows multiple instances of a routing table to coexist on the same router. If you come from a networking background, you'll already know what VRFs are. If you don't have networking experience and you haven't heard of VRFs before, there’s no need to worry about it. I’m just including it here as a useful comparison for the network engineers out there.
NetApp IPspace usage example
Here's an example of when we would need to implement IPspaces:
Here we have three SVMs split over two IPspaces:
- IPspace A – There are two SVM’s (we’ll call them SVM-A and SVM-B). SVM-A has clients on the 10.1.1.x subnet and the LIF is using the IP address 10.1.1.10. SVM-B (middle) has clients on the 10.1.2.x subnet and the LIF is using the IP address 10.1.2.10. Given the two SVM’s are using different subnets, they can remain in the same IPspace.
- IPspace B – The third SVM (SVM-C) is using the 10.1.1.x subnet, which is also being used by SVM-A. Once again, the LIF is configured to use 10.1.1.10 and its clients have 10.1.1.x addresses. In this case SVM-A and SVM-C have overlapping IP addresses. This means they would have to be put into different IPspaces as shown.
Check out the rest of our NetApp networking tutorial series:
And more coming soon...
Text by Alex Papas, Technical Writer at www.flackbox.com
Alex has been working with Data Center technologies for over 20 years. Currently he is the Network Lead for Costa, one of the largest agricultural companies in Australia. When he’s not knee deep in technology you can find Alex performing with his band 2am