iSCSI won't listen on 2nd interface ts-451+

iSCSI related applications
Post Reply
phxazcraig
Starting out
Posts: 10
Joined: Sat Sep 12, 2020 6:09 am

iSCSI won't listen on 2nd interface ts-451+

Post by phxazcraig »

I have two TS-451+ NAS's, each configured with 16GB of RAM and four HDD's.

Within each, I have created a 5TB iSCSI target to be used by my ESXi 6.7 cluster. One of the TS-451's works perfectly. The other one doesn't show up as a path, but only on one of the two interfaces. Naturally not the interface I want (#2).

I have tried with and without service binding, but I am currently using it to try to make sure only the desired IP address is active, but nothing connects to it.

Here's the config: TS-451+ #1 (working): interface 1: 192.168.101.97, interface 2: 192.168.201.87. 5TB iSCSI LUN created and is in use by three ESXi 6.7 servers. iSCSI IP address on my ESXi servers are 192.168.201.5, 201.7 and 201.8, so in same subnet as iSCSI target and hooked up to same switch.

OK, if I leave QNAP #1 at defaults, when I connect to the .201.97 address, I get paths to the target via both interfaces, unless I enable service binding. All three ESXi servers connect and use this iSCSI target with no issues.

Now we come to QNAP #2, also a TS-451+, also with 16B RAM, and on the latest (as of yesterday) firmware. Both QNAPs at the same firmware. QNAP#2 is set up at 192.168.101.99 and 192.168.201.99. Without service binding, one of my ESXi servers will see the target on 101.99, but never on 201.99. (When I got something to connect, I never saw a path that involved the 201.99 address). Thinking I might have some ARP cache or duplicate IP issue, I tried changing interface 2 to 201.253, but that resulted in no change on the initiator side. I have enabled service binding and enabled iSCSI only on interface 2, and that has resulted in none of the ESXi servers seeing any kind of iSCSI target.

I should note that before I upgraded firmware (and before I noticed iSCSI connections to the 101.99 address), I did have two of my three ESXi servers seeing the LUN, and I was able to create a VMFS datastore on it, and I even copied several hundred GB from the 'good' (QNAP1) datastore to the problem one. B

I also tried going to the good QNAP and setting up an iSCSI remote disk, pointing to 192.168.201.253 (or .99 when that was active) - I get nothing after a lengthy timeout.

Is there a diagnostic tool available within QNAP (even if command line) where I can view the listening port numbers on all IP addresses on the unit?
Is this possibly some kind of known bug with a resolution I can apply?

Craig
phxazcraig
Starting out
Posts: 10
Joined: Sat Sep 12, 2020 6:09 am

Re: iSCSI won't listen on 2nd interface ts-451+

Post by phxazcraig »

More information. It looks more and more like a bug. I finally got systems with nmap diagnostics running on each subnet, and I can see that port 3260 is indeed not open on the second interface. I tried enabling service binding and playing around with bindings, and after some misc. trials I suddenly saw port 3260 showing up as open on the second interface! Now at the same time, the port was NOT open on the first interface, even though I have service binding enabled and iscsi is enabled on BOTH interfaces.

Sure enough, once i saw the port open on the second interface, all three of my ESXi servers could connect to the proper IP address and see the datastore there. At the same time, there are no other paths showing up for the target listening on another IP address.

It's not working the way the menu shows it should be, but it's working enough for me to use.

I had other clues that there were issues possibly related to firmware upgrades. (Two years worth now). I tried to swap IP addresses on the QNAP (which would probably have worked too) with the idea of swapping cables, but I stupidly changed the management one first and lost connection. I used the 3-second reset button procedure to recover from this, and I noticed the QNAP was starting up EXTREMELY slowly. Logged in, couldn't even bring up the network switch menu for several minutes. And then I got a message that some sort of error was fixed in the configuration after the reboot, and I think the error mentioned something about not coming out of the latest firmware update correctly.

Once that error message came up, the system seems to have recovered and feels like it is working ok, outside of the listening port issue.
phxazcraig
Starting out
Posts: 10
Joined: Sat Sep 12, 2020 6:09 am

Re: iSCSI won't listen on 2nd interface ts-451+

Post by phxazcraig »

And even more information. This morning I woke up to major issues with my other TS-451+ losing iSCSI connections constantly. So far there seems no reason nor fix. The above ts-451+ has also got other issues - I can't change the admin password for one thing, and the network services menu doesn't want to come up. I had to hit the 3-second reset again to get in, and at this point I'm backrevving the Sept 07 firmware update and going back to the August version on both systems.
justsomeguy
New here
Posts: 5
Joined: Fri Jul 28, 2017 10:24 pm

Re: iSCSI won't listen on 2nd interface ts-451+

Post by justsomeguy »

I have had problems with all firmware releases this year with the port not being open when the virtual switch topology is anything other than dead simple. I found this incredibly annoying, as it was not deterministic and I eventually gave up and had to use a dumber and less secure separate management configuration. Because of this I was not able to use a spare 10Gbe port on the NAS to handle layer 2 traffic for an extra device with an extra 10Gb NIC. It would switch the traffic properly but it always broke iSCSI listening to have the configuration allow this.

Maybe QNAP could spend less time on an avalanche of crapware "apps" that are hard to kill or uninstall and more time on QC.
phxazcraig
Starting out
Posts: 10
Joined: Sat Sep 12, 2020 6:09 am

Re: iSCSI won't listen on 2nd interface ts-451+

Post by phxazcraig »

I never found the answer to the iscsi listening issue, but after it went away, I had no need to either. I did a lot of simplification trying to isolate the issue, and perhaps I inadvertently put the device into a condition it could handle.

I did find the answer to the more serious problem of iSCSI disconnects, and I'll start a new post about it. In short, RAID scrubbing causes problems.
Post Reply

Return to “iSCSI – Target & Virtual Disk”