iSCSI won't listen on 2nd interface ts-451+
Posted: Sat Sep 12, 2020 6:30 am
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
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