1 Rookie
•
9 Posts
0
1323
January 8th, 2020 14:00
MPIO Sessions Not Following Exclusion
Hello, I am having an issue configuring a new iSCSI connection on a new Win2016 server. Standard procedure is to install Auto Snapshot Manager and then configure the VSS Chap and grab the servers Initiator Name and add it to the new volume on the SAN, limiting access to only that Initiator. We then limit the MPIO access to only the subnets used for SAN traffic and make sure the connections are building out over the SAN ports instead of the business LAN. My server is building out the connection over 10.20 subnet not following the settings I have set in Auto Snapshot Manager.
Has anyone seen this before? I have attempted a couple uninstall reinstalls of ASM. I have several other servers configured the same way and operating properly, none of them connecting over the company LAN
dwilliam62
4 Operator
•
1.5K Posts
1
January 13th, 2020 10:00
Hello,
Make sure there is a trunk (or stacked) on the iSCSI switches.
Also from the EQL Group CLI you want to ping out from each network port.
GrpName>ping "-I
It is a capital I
GrpName>ping "-I 192.168.1.20 192.168.1.1"
The quote marks must be included.
Do this for every EQL network interface.
You want to ping all the server iSCSI NICs.
Regards,
Don
dwilliam62
4 Operator
•
1.5K Posts
0
January 9th, 2020 07:00
Hello,
I've not seen this specific issue before. Best option is open a support case so they can review the logs and configuration.
From the array I would make sure you can ping the iSCSI subnet network adapters. Since the 10.x can reach the 192.x subnet that would suggest you have routing between them.
My guess is that the server can't reach the array directly but the software was able to via the 10.x IP subnet.
Regards,
Don
kenny nitch
1 Rookie
•
9 Posts
0
January 13th, 2020 08:00
I reached out to support, we are out of contract so they suggest I post on the forums.
I will test from the array to the server. All connections to the SAN run over 2 redundant switches and the ports being used by the server were open ports from a past server that was decommissioned who accessed the SAN.
I agree there has to be a routing issue regarding the 10.20 accessing the 192.168.249, that should not be possible at all since I want to make sure the SAN data all stays on .249.
Thank you for your suggestions, any more would be appreciated, was hoping to avoid paying for support since this looks to be setup right.
Thank you
Kenny
kenny nitch
1 Rookie
•
9 Posts
0
January 14th, 2020 11:00
Pings are failing, I will pull the switch config and check that they are setup correctly.
dwilliam62
4 Operator
•
1.5K Posts
0
January 14th, 2020 12:00
Hello,
Well that's "sort of" good news. At least you have something to check.
Please let me know how you resolve this.
Regards,
Don
kenny nitch
1 Rookie
•
9 Posts
0
January 14th, 2020 14:00
Welp that is what I get for assuming, looks like the ports were not provisioned for the SAN and the last device connected to them must not have actually been using them.
It seems if there is no other route Windows will still build out the connections over the ports on the exclusion list and there isn't much you can do about it.
Thank you Don!
Thank you
Kenny
dwilliam62
4 Operator
•
1.5K Posts
0
January 15th, 2020 06:00
Hello,
Glad you found the problem!
It's not actually Windows finding a new route it's the HIT/ME software. The connection manager will by default connect to the SAN using all NICs that have a route to the SAN. You exclude them to prevent that. However, if there are NO routes to the SAN, it will revert to that behavior in order to maintain an iSCSI connection. So in the event of NIC or switch failure, or a switch configuration change bringing down the primary subnet the connection manager will check for other routes to the SAN. It's pretty cool software IMHO.
Regards,
Don