My ultimate aim is to configure AD authentication for the Admin SVM. I understand that I need to create a data SVM, join it to a domain and then configure the data SVM to be a gateway tunnel to allow AD authentication to the Admin SVM.
I'm going to have to create a new data SVM, does it have to be on a different subnet/VLAN to the admin SVM?
I'm not planning to overlap IP addresses between the admin and data SVM, each LIF IP will be unique, so do I need to go down the road of muliple IPspaces?
1. You don't *HAVE* to segregate your admin and data SVM LIFs onto separate VLANs; however, your network design and/or security posture may dictate that management networks be isolated from the rest of the network.
2. Based on the data in your inital post, I'd say that you would not need to worry about multiple IPSpaces. The default IPSpace should be fine.
The new data SVM will only exist to enable the admin SVM to join the management domain (via an authentication tunnel), so in effect the data SVM is a 'management' SVM hence the reason for both the admin and data SVM joining the same VLAN.
I wondered about the IPspaces as the documentation mentions that separate IPspaces are required if you have overlapping IP addresses. Obviously, being on the same VLAN, the admin and data SVM IPs will overlap.
The definition "overlap" isn't meant in the context of multiple SVM;s. You can have as many SVM's and LIF's on the same subnet. it also not there to address security in any way - it's just a technical mechanism. You can see that by default the NetApp own MGMT ports all configured on the default ipspace.
The idea of IPSpace is that if you are a service provider, and want to set the same IP for all the customers SVM's -as a "standardization" Then you can use this feature.
- Most customers don't need this feature at all - even not the ones with overlapping subnets as s long as they access their own dedicated SVM with its own default gateway (the article a bit misleading when it talks about static routes)
One more thing about ipacpaces. if for some reason you do choose to use it - it will require you to assign a dedicated set of ports/vlan to that ipspace.
I do encourage to:
* Put this interface on dedicated MGMT subnet.
* Secure the IP (and the other MGMT IP's) with external firewall/access-list to prevent users to access them.
* Put NetApp firewall rules on it as well, so a hacker or malware compromising one device on that MGMT subnet - cannot hop to these ports as well.