It is completely acceptable to have multiple pools under the same subnet with the same smartconnect IP. The IP distribution will happen based on the zone name so clients will be connected to the correct IP pool. They do not need to have a separate subnet for each pool.
1. Client makes a request to mount to static.cifs.pool.isilon.com (for example) 2. Request is sent to DNS server for name resolution.
3. DNS sends the request to the SmartConnect IP with the zone name static.cifs.pool.isilon.com 4. SmartConnect checks for a pool with the matching zone name static.cifs.pool.isilon.com.
5. After finding a match, SmartConnect responds with an IP address in the pool static-cifs-pool. 6. DNS responds to the client with the IP address provided, and client is connected pending authentication services.
If the zone name is changed to one of the other pool's zone name, then SmartConnect will pull from corresponding pool's IP range.
I'm confused when you say that one pool has an IP address range outside of the subnet though. The cluster won't allow an IP range to be assigned outside of the pool. Based on the screenshot provided, all of those pools have to be in the 10.200.x.x range. I think some of the confusion may be that they aren't using the commonly used 255.255.255.0 netmask, but are instead using 255.255.0.0 (which is not a problem if that was their intention).
our DNS admin was complaining because the results he get back from running the dig command is not what he expects it to be. The DNS admin updated BIND from 9.9.9.8P3 to 9.9.9.9.P4_1 and all the Isilon clusters NS records seem to stop working. My understanding this may not be just linked to just Isilon NS records but I can confirm. Needless to say I wanted to verify that all of out SmartConnect and DNS configurations where correctly configured to make sure we are good on our side cause of course we are getting dragged through the mud as this being our fault.
Smartconnect is a pretty basic tool on the cluster side. From a troubleshooting perspective, if one piece changes and things stop working, it is typically an issue with the thing that changed. I don't know enough about the version changes that were made to definitively say though. If you test from the cluster side and things are working, than it is likely the DNS settings. Have you checked out this documentation?
This article is not customer facing. It is available for employees and partners. If you can't view it, I would recommend asking Support or a member of your account team to assist.
chjatwork
2 Intern
•
356 Posts
0
February 7th, 2017 05:00
sjones5,
Below is a link to the document I used to verify that SmartConnect and the DNS configuration was good.
https://emcservice--c.na16.visual.force.com/apex/KB_BreakFix_clone?id=kA2j0000000R2jC
sjones51
252 Posts
0
February 3rd, 2017 13:00
Hi chjatwork,
It is completely acceptable to have multiple pools under the same subnet with the same smartconnect IP. The IP distribution will happen based on the zone name so clients will be connected to the correct IP pool. They do not need to have a separate subnet for each pool.
1. Client makes a request to mount to static.cifs.pool.isilon.com (for example)
2. Request is sent to DNS server for name resolution.
3. DNS sends the request to the SmartConnect IP with the zone name static.cifs.pool.isilon.com
4. SmartConnect checks for a pool with the matching zone name static.cifs.pool.isilon.com.
5. After finding a match, SmartConnect responds with an IP address in the pool static-cifs-pool.
6. DNS responds to the client with the IP address provided, and client is connected pending authentication services.
If the zone name is changed to one of the other pool's zone name, then SmartConnect will pull from corresponding pool's IP range.
I'm confused when you say that one pool has an IP address range outside of the subnet though. The cluster won't allow an IP range to be assigned outside of the pool. Based on the screenshot provided, all of those pools have to be in the 10.200.x.x range. I think some of the confusion may be that they aren't using the commonly used 255.255.255.0 netmask, but are instead using 255.255.0.0 (which is not a problem if that was their intention).
Here is a best practice guide that may help:
External Network Best Practice Guide---Routing
https://support.emc.com/docu58740
chjatwork
2 Intern
•
356 Posts
0
February 7th, 2017 05:00
sjones5,
our DNS admin was complaining because the results he get back from running the dig command is not what he expects it to be. The DNS admin updated BIND from 9.9.9.8P3 to 9.9.9.9.P4_1 and all the Isilon clusters NS records seem to stop working. My understanding this may not be just linked to just Isilon NS records but I can confirm. Needless to say I wanted to verify that all of out SmartConnect and DNS configurations where correctly configured to make sure we are good on our side cause of course we are getting dragged through the mud as this being our fault.
sjones51
252 Posts
0
February 7th, 2017 07:00
Hi chjatwork,
Smartconnect is a pretty basic tool on the cluster side. From a troubleshooting perspective, if one piece changes and things stop working, it is typically an issue with the thing that changed. I don't know enough about the version changes that were made to definitively say though. If you test from the cluster side and things are working, than it is likely the DNS settings. Have you checked out this documentation?
Isilon OneFS: How to create a UNIX-based BIND DNS setup for use with SmartConnect https://support.emc.com/kb/468688
This article is not customer facing. It is available for employees and partners. If you can't view it, I would recommend asking Support or a member of your account team to assist.