This post is more than 5 years old
89 Posts
0
427334
Error: Initiator tried to bypass the security phase but we cannot
Hi,
I started working on new company and tonight we lost storage for about an hour and errors came:
ERROR event from storage array SAN1
subsystem: MgmtExec
event: 7.4.3
time: Sun Apr 21 00:58:18 2013
iSCSI login to target '10.10.10.21:3260, iqn.2001-05.com.equallogic:4-52aed6-cb0bdf198-eee0000000c50212-vss-control' from initiator '10.10.10.22:53396, iqn.1991-05.com.microsoft:sp2-vm-sql2.company.local' failed for the following reason:
Initiator tried to bypass the security phase but we cannot.
On windows this night first errors started:
EventID: 4025
Source: EqualLogic
iSCSI login error 0xefff0009 when connecting to vss-control volume for group 10.10.10.41
EventID: 10
Source: iScsiPrt
Login request failed. The login response packet is given in the dump data.
These errors I see repeating from the past in Windows event log.
This is hyper-v virtual SQL cluster with iSCI Dell storage connection.
How to solve this?
thanks
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
1
April 21st, 2013 10:00
Hello,
On the vss-control volume, which is used my MS Volume Shadow service to access Hardware snapshots, there is a CHAP username configured. however, the initiator is not sending a CHAP username/password..
If you are using the EQL HIT kit, then you should allow those servers access to that volume. Or change the ACL on that volume to allow only those servers that need it, to access it.
You can also remove it from the favorites tab, so that it won't attempt to log in the next time the server boots up.
Finally, you can enable the Discovery filter to prevnet this from re-occuring.
Here's a KB from the Equallogic Website.
Solution Title Error: "Initiator wanted to skip security phase but we cannot." or "Initiator tried to bypass the security phase but we cannot."
Solution Details Symptom: Event log on the PS Array web interface shows a login error for a volume that says, "Initiator wanted to skip security phase but we cannot." This error may be repeated every few seconds continuously.
Issue: By default, volumes that have CHAP authentication enabled will be shown during the iSCSI discovery process even if the initiator doesn't have the CHAP credentials. Discovery is controlled by IP address ACLs, so if a machine matches an ACL's IP address field, we will see the volume. Note that many initiators such as ones that are unix based like the Cisco software initiator that VMWare uses will continue to attempt to login to that target (often, every two seconds) even though every login attempt fails. This can fill up the log, and can impact server performance.
Solution: Restrict the discovery of CHAP-authenticated volumes by IP address, and make sure that only the servers with the appropriate CHAP credentials can see the volume at all.
The most common volume to see this error on is the special volume named "vss-control." This volume is for communication with the Microsoft VSS service, using the EqualLogic Host Integration Tools. If it is configured for unrestricted access, or is configured for CHAP-only, then every initiator on the SAN will be able to discover it, and may attempt to use it. Set the "vss-admin" ACL to include an IP address for every machine that needs to access it, to ensure that no others do.
For firmware version 2.2.3 and before, go to the volume named "vss-control", select the Access tab, and change the entries there appropriately.
For firmware version 2.3.2 and later (including all 3.X releases), go to the Group Configuration area, and select the VSS/VDS tab. This is the ACL for the vss-control volume, which you should modify appropriately.
It may be necessary to reboot the servers that are trying to access this volume after changing the ACL, however. Some initiators do not release a target once they have discovered it, even if the array says that the target does not exist. One example of this are ESX servers using the software initiator.
A second scenario can be a volume which is setup to be seen from within a VMWare server Windows VM using CHAP credentials and also setup on the array to use a CHAP only login. Even though the CHAP credentials may be setup properly from each side if the ESX server is using the software initiator ESX will attempt to login to the volume continuously every so many minutes or seconds depending on various factors. With multiple volumes setup in this manner it can be a performance drain on ESX.
To solve this scenario make sure to enable the iSCSI Discovery Filter from within the PS Array GUI. This is done from the Group Configuration/iSCSI tab. Check the box off and save the configuration using the green disk icon in the upper right corner of the GUI. Once this is done only servers with initiators that are properly setup to see a volume with CHAP will see and attempt to login to those volumes. Note: Once an ESX server has seen a volume it will keep trying to login with the software initiator until the ESX server is restarted after this option is enabled.
Note that, starting with firmware version 3.0.5 and later, you can require authentication for CHAP-enabled volumes during discovery, by issuing the command from the CLI:
GroupName> grpparams discovery-use-chap enable
Regards,
natip
89 Posts
0
April 22nd, 2013 09:00
From windows node I checked "iSCI Initiator Properties" selected one of discovered targets and in the properties I see that - Authentication: None Specified.
So do I understand it right, that on the DELL storage access to LUN or disk is controlled by IP address ACLs and CHAP authentication enabled by default on the volume. If my Windows server has the correct IP that is configured on ACL's in the storage, but does not have CHAP authentication it will be able to discover connect and work with the volume, just CHAP authentication errors will be generated?
If this is correct, what would be the simplest way to fix this without downtime?
Not sure what is EQL HIT? And how to find if we are using it?
thanks
natip
89 Posts
0
April 22nd, 2013 09:00
could you please guide me a little, is it possible to check from windows side and will it require any down time if configuration will be changed?
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
April 22nd, 2013 11:00
Hello,
There are no default ACLs set on volumes. It's up to the storage administrator. If the array was configured using the Remote Setup Wizard, it will create a CHAP account on the vss-control volume. Or if you run Remote Setup Wizard later on and use the "configure access to group" option.
You don't have to use CHAP, you can use IP address, or the iSCSI initiator name of the host that needs access.
Re: Errors. Yes, if a volume only has a CHAP ACL, then any initator can discover the volume, but requires the CHAP username/password in order to allow login. If the initiator tries to login anyways, you get the error you are seeing.
Re: HIT. The Host Integration Toolkit, is a series of applications that improves performance and enhances the quality of snapshots and replication by quieting the filesystem before such operations. You will have a program group "Equallogic" if you have installed the HIT kit. If the HIT kit is installed on the nodes reporting the errors, then allowing them access to the vss-control volume will resolve the errorrs. Depending on the version of HIT installed, you will also have a tab in the MS iSCSI initiator control utility that says "Dell MPIO".
So once we have determined if you have HIT installed or not, we can proceed to figure out what the best way to resolve it is. If will not require any downtime.
On the server(s) trying to connect to the vss-control, there will be an entry for that volume in the Favorites tab in the MS iSCSI initiator control utility. If you remove that favorite it won't try logging into that volume on start up.
Regards,
natip
89 Posts
0
April 22nd, 2013 12:00
"Re: Errors. Yes, if a volume only has a CHAP ACL, then any initator can discover the volume, but requires the CHAP username/password in order to allow login. If the initiator tries to login anyways, you get the error you are seeing."
But in this situation our CHAP ACL is not working from server side and we still can use volumes. Does that mean CHAP is just recommended storage security enhancement in this case?
Yes, we have "Dell EqualLogic MPIO" tab in MS initiator control utility.
"On the server(s) trying to connect to the vss-control, there will be an entry for that volume in the Favorites tab in the MS iSCSI initiator control utility. If you remove that favorite it won't try logging into that volume on start up."
If I remove the favorites I wont be able to connect automatically to storage after server reboot?
And is it any simple way to fix this without downtime?
thanks
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
April 22nd, 2013 12:00
re: Favorites. I was only referring to the entry corresponding to the vss-control volume. All the other favorites should remain.
Since you do have the HIT kit installed, the easiest solution, that will require no downtime is to add the initiator name
iqn.1991-05.com.microsoft:sp2-vm-sql2.company.local as an ACL entry for the vss-control volume.
Group Configuration->VDS/VSS tab->Add-->Select Checkbox next to: Limit ACcess to iSCSI initiator name Then past in iqn.1991-05.com.microsoft:sp2-vm-sql2.company.local
Regards,
natip
89 Posts
0
April 22nd, 2013 13:00
and where exactly "Group Configuration" is? thanks
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
April 22nd, 2013 13:00
In the EQL GUI, Right under the Group Name is the "Group Configuration" menu.
natip
89 Posts
0
April 23rd, 2013 06:00
As I understand EQL GUI is not installed on the windows platform (if it is, then what is the file location to run it). All I could found is IP address on Target Portals section in Discovery tab on iSCI initiators properties. I tried to browse to that IP and it asked me credentials witch I don't have. Is there any other way to solve this problem?
thanks,
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
April 23rd, 2013 07:00
The GUI is a Java applet, so any browser with Java installed will work.
However, you will need the grpadmin password to log in and correct this.
If you have lost the password, then please open a support case and they can assist you with getting the password changed.
Regards,
natip
89 Posts
0
April 23rd, 2013 09:00
Thank you, and how this will solve the problem? don't I have to disable CHAP ACL on storage instead of adding iSCSI initiators name?
Group Configuration->VDS/VSS tab->Add-->Select Checkbox next to: Limit ACcess to iSCSI initiator name Then past in iqn.1991-05.com.microsoft:sp2-vm-sql2.company.local
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
April 23rd, 2013 10:00
If you don't have the grpadmin password how are you going to make the change on the storage array?
You don't have to remove the CHAP ACL, you can add an additional one for this server having the problem. I don't want to remove it out of hand, since another server might be configured to use it.
natip
89 Posts
0
April 23rd, 2013 13:00
I am still trying to get password from another team.
But the situation with CHAP ACL is still not clear to me. If I add additional constraint, how it will solve CHAP ACL problem? Storage will still require CHAP and will display the error if windows iSCSI initiator won't be configured with CHAP password?
thanks
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
April 23rd, 2013 14:00
If you add an ACL, they are OR'd together, not AND'd. So either authentication will allow the login to occur.
natip
89 Posts
0
April 24th, 2013 03:00
Oh, so login by name will be enough in this case and CHAP authentication wont be required or it won't log the error.
Do I have to enter names of both cluster servers to "Limit ACcess to iSCSI initiator name"?
And how could I test it without the down time?
thanks