Kim,
Thanks for the in-depth answer. We've already made the iscsi disable interface tweak on our filers to ensure sysadmins don't inadvertently establish iSCSI sessions over the LAN links.
Going into the iSCSI control panel and trying to log-off the reconnecting target does nothing. It was the first thing I tried J
- Hadrian
From: Weller, Kim [mailto:Kim.Weller@netapp.com] Sent: Thursday, January 24, 2008 4:41 PM To: Klise, Steve; Hadrian Baron; Glenn Walker; toasters@mathworks.com Subject: RE: Cleaning up Messy SW iSCSI connections
Hi Hadrian,
I've encountered this issue before during testing of cable pulls...This would occur if you had multiple physical interfaces, some on your storage network, some on your public network, etc., and the server couldn't actually get to the storage device on one or more of them. Issue results because of how MS iSCSI Initiator handles reconnecting sessions after a service or network outage. Basically, it cycles through all the available IPs returned from a send targets command to the storage (which you can see in a packet trace if you go to the trouble). It hangs in a state of reconnecting if it gets to an interface that exists on the storage to which there is no path from the server. One way to prevent this behavior is to disable ISCSI on the filer interfaces that you don't actually use for ISCSI traffic.
(Usage: iscsi interface disable { -a | <interface> ... }
There is a way to get it to disconnect: Go into the 'details' of the 'reconnecting' target, checking the box next to the active session (which will probably not be reflected as active on the filer with iscsi session show), and click 'Log Off.' At that point you should be able to refresh the list of targets and log on as normal.
Hope this helps.
Kim Weller
Solution Architect, SAN and Virtualization
Office: 713.968.3621
Mobile: 713.818.4433
________________________________ From: Klise, Steve [mailto:klises@caminomedical.org] Sent: Thursday, January 24, 2008 5:26 PM To: Hadrian Baron; Glenn Walker; toasters@mathworks.com Subject: RE: Cleaning up Messy SW iSCSI connections Are you using MPIO? Also, do you have the advanced options setup properly (ISCSI is not set high in the priority list, and the networking services are not enabled). I would make sure the drivers are up to date, and the network is not having any issues..
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Hadrian Baron Sent: Thursday, January 24, 2008 2:49 PM To: 'Glenn Walker'; toasters@mathworks.com Subject: RE: Cleaning up Messy SW iSCSI connections
It's software based iSCSI, so the normal gigE NIC becomes the HBA. It sounds like a similar issue though.
- Hadrian
From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Thursday, January 24, 2008 2:46 PM To: Hadrian Baron; toasters@mathworks.com Subject: RE: Cleaning up Messy SW iSCSI connections
Not using an HBA are you? We had similar problems with the QLogic 4050C HBAs. The TCP session would drop on the HBA and a reset would be required to get it going again.
________________________________ From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Hadrian Baron Sent: Thursday, January 24, 2008 1:28 PM To: toasters@mathworks.com Subject: Cleaning up Messy SW iSCSI connections
Hello Toasters,
We have Snapdrive + MS iSCSI on a few boxes. I've noticed that once in awhile the iSCSI connection will become unavailable. If you browse the iSCSI front-end in Snapdrive, it will show unavailable where it would show the IP addresses for target & portal.
If you browse the iSCSI control panel, it shows a target that is "reconnecting", but you cannot disconnect it to properly re-establish the connection.
Does anyone have a way to properly clean up these connections? Typically disabling iSCSI / Snapdrive services, bouncing the box, and turning them up will let me re-establish, but this is painful.
If anyone is wondering, it's Snapdrive 4.2.1 + MS iSCSI 2.05.
Thanks all,
- Hadrian