Arp broadcast for cross vlan/subset destination when iSCSI target 3.3 used
One Windows server 2008 R2 with iSCSI target 3.3 installed and set static ip with 192.168.1.22/24, Gateway = 192.168.1.254 One Windows XP workstation set static ip with 192.168.0.231/24, Gateway = 192.168.0.254 Switch, configure two Vlan, and two vlan ip interface 192.168.0.254 and 192.168.1.254 with forwarding. 1. Then on 192.168.1.22, ping 192.168.0.231, OK, check arp cache, no arp entry 192.168.0.231 found, only Gateway 192.168.1.254 found 2. Use one iSCSI initiator on 192.168.0.231, LUN scan iSCSI target 192.168.1.22, check arp cache by "arp -a", 192.168.0.231 entry found.Which means "local proxy arp" feature is used on the switch. I want to whether this is the normal behavior for iSCSI target 3.3. Is there any way to turn off this kind of arp on iSCSI target server? And "local proxy arp" feature on switch will never be used. Thanks.
December 12th, 2011 12:51am

I have not fully understood what you would like to achieve and why. (IMHO ARP is important central part of network communication...) Regard Milos
Free Windows Admin Tool Kit Click here and download it now
December 12th, 2011 10:01am

I understand ARP is important in network. What I mean is the host should NOT have the arp entry for the cross vlan/subnet destination. The host only has the Gateway arp entry which is enough for host to find the destination. Here when I used iSCSI target 3.3, cross vlan/subnet destination arp broardcast will happen. So I have to open the local proxy arp feature on switch to response this special request. As compared, If I just ping or remote-desktop to the cross vlan/subnet destination, the arp broadcast will not happen.
December 12th, 2011 9:09pm

One Windows server 2008 R2 with iSCSI target 3.3 installed and set static ip with 192.168.1.22/24, Gateway = 192.168.1.254 One Windows XP workstation set static ip with 192.168.0.231/24, Gateway = 192.168.0.254 Switch, configure two Vlan, and two vlan ip interface 192.168.0.254 and 192.168.1.254 with forwarding. 1. Then on 192.168.1.22, ping 192.168.0.231, OK, check arp cache, no arp entry 192.168.0.231 found, only Gateway 192.168.1.254 found 2. Use one iSCSI initiator on 192.168.0.231, LUN scan iSCSI target 192.168.1.22, check arp cache by "arp -a", 192.168.0.231 entry found.Which means "local proxy arp" feature is used on the switch. I want to whether this is the normal behavior for iSCSI target 3.3. Is there any way to turn off this kind of arp on iSCSI target server? And "local proxy arp" feature on switch will never be used. What I mean is the host should NOT have the arp entry for the cross vlan/subnet destination. The host only has the Gateway arp entry which is enough for host to find the destination. Here when I used iSCSI target 3.3, cross vlan/subnet destination arp broardcast will happen. So I have to open the local proxy arp feature on switch to response this special request. As compared, If I just ping or remote-desktop to the cross vlan/subnet destination, the arp broadcast will not happen. Thanks.
Free Windows Admin Tool Kit Click here and download it now
December 12th, 2011 9:14pm

Hi binbin1980, Thanks for posting here. > Then on 192.168.1.22, ping 192.168.0.231, OK, check arp cache, no arp entry 192.168.0.231 found, only Gateway 192.168.1.254 found >The host only has the Gateway arp entry which is enough for host to find the destination. This is expected since the destination address is in another subnet and according to how ARP works ,it will only resolve the IP address of the router to its MAC address and this is why only router/gateway was been cached but not the destination host . Please just take look the explications about ARP in the article below: Based on the destination IPv4 address and the route determination process, IPv4 determines the next-hop IPv4 address and interface for forwarding the packet. IPv4 then hands the IPv4 packet, the next-hop IPv4 address, and the next-hop interface to ARP. If the IPv4 address of the packet’s next hop is the same as the IPv4 address of the packet’s destination, ARP performs a direct delivery to the destination. In a direct delivery, ARP must resolve the IPv4 address of the packet’s destination to its MAC address. If the IPv4 address of the packet’s next hop is not the same as the IPv4 address of the packet’s destination, ARP performs an indirect delivery to a router. In an indirect delivery, ARP must resolve the IPv4 address of the router to its MAC address To resolve the IPv4 address of a packet’s next hop to its MAC address, ARP uses the broadcasting facility on shared access networking technologies (such as Ethernet or 802.11) to send out a broadcast ARP Request frame. In response, the sender receives an ARP Reply frame, which contains the MAC address that corresponds to the IPv4 address of the packet’s next hop. ARP http://technet.microsoft.com/en-us/library/bb726993.aspx#EIAA Thanks. Tiger LiPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
December 14th, 2011 1:07am

I would like to understand which version of windows has this proxy ARP behavior as a default behavior. I cannot reproduce this either in windows 7 or in windows 2008. Under what circumstances would a windows 7 use Proxy ARP. By default for out of subnet hosts windows 7 or a 2008 or a 2008 R2 will always send an ARP for the gateway and not for the host. I would like to understand when will windows 7 failback if there is such a scenario. The documentation provided here is not current to be honest. I am not sure which version is being referred to in the docs. The original post is correct windows should not send an ARP for a host whose IP is outside the subnet unless there is a failover mechanism enabled in XP days where we failover to proxy ARP scenario and send a broadcast for a host which is not in the same broadcast domain. The switch or router in-turn forwards the ARP to the second Vlan, proxy the ARP broadcast request as well as response. This behavior is not exhibited in windows 7 atleast on a vanilla build in a lab.
Free Windows Admin Tool Kit Click here and download it now
March 26th, 2012 1:40pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics