Code: Select all
PS C:\Users\User> StarNVMeoF_Ctrl.exe discovery 10.224.128.1:4420 10.224.128.2
StarNVMeoF Controller Application v 2.0.0.672
Our Miniport #9 (ver 2.0 build 672)
Discovering of RDMA addr 10.224.128.1:4420 from 10.224.128.2...
Adapter Addr '10.224.128.2' not found!
Invalid local network adapter's addr 10.224.128.2!
Discovery() failed!
I guess the CLI tool is using the first IP returned by Windows to identify interfaces, in this case 10.224.2.0, as only that IP is listed in the Windows iSCSI initiator GUI when I choose the StarWind NVMe-oF controller.
There is a workaround for me though: I can remove the offending IP, initiate the session, then add the IP back. I currently have a batch script for this, but I think it might be better if the initiator CLI tool could enumerate all IPs on interfaces instead so the workaround is not needed. Plus I could use the Windows GUI to manage the sessions.
Both NICs are ConnectX-5, but that's probably irrelevant here.
(Before you ask about my network configuration: this is kind of needed for me to use RDMA if I want to use PFC on the Windows side. I don't have a PFC capable switch, so I have to directly connect two machines together. The target machine is also a router, so I have to bridge the RDMA NIC with another link, so the IPv4 network is shared with other devices. However, with PFC and the VLAN 0 Ethernet header, the target machine cannot identify any IB packet, as it's expecting packets without the 1Q header (this probably needs to be fixed instead, but I cannot find a way to fix it). I then have to add a new VLAN for both machines to make IB actually usable, and that's why the second IPv4 network is needed if I don't want to further screw with the routing. It's messed up, but that's what I have to work with for now.)