iSCSI initiator sends all packets to router even though the target is in local network.

Hi!

My test client has no disk and boots by iPXE using iSCSI protocol.
Windows boots well but Windows iSCSI initiator sends packets to router even though the target ip address is in local network.
My router sends a ‘redirection’ ping packet to have Windows to send packets to destination directly but it seems Windows does not listen.
The strange thing is that if DHCP response has no router ip then Windows iSCSI sends packets to the target directly!
(The iBFT passed from iPXE is wrong or Windows does not properly parse iBFT?)

This problem increases my router traffic and the latency between initiator and target.

Help me!

Network information…

  • Router : 192.168.0.1 / 24
  • Target IP : 192.168.0.101 / 24
  • Initiator IP : 192.168.0.171 / 24

your first step should be to capture a network trace. If possible, configure a port mirror on your switch and take the packet capture from there. You can use another Windows host or Linux or whatever, but make sure to capture in promiscuous mode. do not attempt to capture these frames on your router as it will provide misleading results.

if you already have a packet trace, then tell us the details of the DHCP and ARP sequences that you see. Pay particular attention to the destination physical addresses in the packets

I attached an wireshark packet capture file and one picture.
Windows iSCSI sends an ARP request packet for 192.168.0.1 (wrong!) not for 192.168.0.101 (correct!)

Network information

  • Router 192.168.0.1 - 64:e5:99:e5:01:f8
  • Target 192.168.0.101 - 70:85:c2:cd:4d:9c
  • Initiator 192.168.0.172 - 00:0c:29:fd:ff:d0

Boot process (192.168.0.172)

  1. Intel PXE
  • [Packet #1~#39] DHCP Request
  • [Packet #40~#41] ARP (192.168.0.101)
  • [Packet #42~#125] TFTP Download “undionly.kpxe”
    (run undionly.kpxe)
  1. iPXE
  • [Packet #126~#127] ARP (192.168.0.101)
  • [Packet #128~#131] HTTP Request (PXE text logo request. It’s not important packets.)
  • [Packet #132~#172] DHCP Request
  • [Packet #173~#277] iSCSI R/W (00:0c:29:fd:ff:d0 ↔ 70:85:c2:cd:4d:9c) (172 ↔ 101)
    (run mbr and load windows bootmgr and drivers)
    (iPXE’s iSCSI is not used anymore)
  1. Windows
  • [Packet #282~#284] ICMPv6
  • [Packet #285~#286] ARP (192.168.0.1) Why not 192.168.0.101???
  • [Packet #287~] iSCSI R/W (00:0c:29:fd:ff:d0 ↔ 64:e5:99:e5:01:f8) (172 ↔ 1) This is a problem!
  • [Packet #379, #600] Ping (192.168.0.1 sends redirection ping packet but no effect)

unfortunately, I don’t really have time to go through this trace, but you mention that there is IPv6 active at least on the Windows side. is it possible that IPv6 is being used?

I also see that VMWare is being used. does it make any difference if it is a bare metal configuration or a different hypervisor?

Unfortunately, without a deep dive into the trace, I have no particular insight. But I suspect something about the detected NIC capabilities or those first few packets after the boot loader starts will tell the answer

This bug occurs on bare metal configuration too!
Please take a look!

http://nsmaker.co.kr/1.png

P.S: Why cannot I find attach image files? File attachment feature is removed?

interesting

1 Like

Okay~ What should I do next?

Open a case with Microsoft?

Actually I don’t know any other communities except OSR and StackOverflow. Can you tell me the URL address to open a case?

when I say open a case with Microsoft, I’m not suggesting some other community. But that you should see paid support from Microsoft. I could find the URL but google will find it faster for you than I can. And if you have a partner agreement, your rep will find it much faster than that in my experience.

In my experience, the engineers at MSFT actually do care and will help. you juts have find you way to the right ones who can

1 Like

the engineers at MSFT actually do care and will help. you juts have find you way to the right ones who can

This.

Peter