NOTE: Long email / question ... regarding ARP and Proxy ARP behavior with
different vendors OS.
A inquiry about ARP behavior, vendors, and differences.
Does the way a host machine behave during the ARP process differ amongst
different OS manufacturers, in relationship to when Proxy ARP can be
implement and when it can't be.
This inquiry should not be mistaken with "is proxy ARP a good idea or bad
idea" question. I just want to find some behavior facts out. Thanks.
Given the following situation:
ClientA ClientB
| |
|----------------|
|
|
X
{ROUTER}
Y
|
|
|-----------------|
|
ClientC
Settings:
ClientA: 192.168.12.5 /24
ClientB: 192.168.12.6 /24
ClientC: 192.168.20.101 /24
Interface X on Router: 192.168.12.1 /24
Interface Y on Router: 192.168.20.1 /24
Proxy ARP enabled on both router interfaces
None of the clients have been configured with a default gateway setting.
The operating systems are Windows 98. (Though if you prefer you can say it
is NT 4.0)
The basic statement that I have a question about:
According to Jeff Doyle's Routing TCP/IP vol. 1, book on page 69-70 in
quotes below -
"... For example, a host 192.168.12.5/24 needs to send a packet to
192.168.20.101/24, but is not configured with default gateway information
and therefore does no know how to reach a router. It may issue an ARP
request for 192.168.20.101; the local router, receiving the request and
knowing how to reach network 192.168.20.0, will issue an ARP reply with it's
own data link identifier in the hardware address field. In effect, the
router has tricked the local host into thinking that the router's interface
is the interface of 192.168.20.101. All packets destined for that address
will be send to the router. ..."
The question itself:
The question I have with this is that under a Windows environment at least
in my experience, The decision making process is as follows when trying to d
o an address resolution (ARP Request).
Sender looks at it's own IP address and Subnet Mask compares it to the
target machines IP address to determine if on the same subnetwork. If it is
so . an ARP request is issued. But if the Sender's IP address and the Target
's IP address are not part of the same subnetwork . the sending machine
looks for it's default gateway and does an ARP request for it.
Thus the problem is . if there is no default gateway setup for the sender .
It won't even attempt to do an ARP request . it will IMMEDIATELY say .
Destination host unreachable.
Demonstration 1:
ClientA: 192.168.12.5 /24 PINGS ClientC: 192.168.20.101 /24
Notice in the PING results below, where Client A pinging Client C, with the
start and end time there is only a 6/100ths of a second difference from the
start of the ping statement to it informing us no can do. Also note with a
sniffer on the line there are no packets generated either from the pinging
machine.
Current time is 4:25:34.81p <-- Start Time
Pinging 192.168.20.101 with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Ping statistics for 192.168.20.101:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Current time is 4:25:34.87p <-- End Time
--------------
Demonstration 2:
ClientA: 192.168.12.5 /24 PINGS 192.168.12.88 (non-existent client)
On the other hand if Client A attempts to ping a machine that it believes
has an IP address on the same subnet the following results would occur.
(Given the IP address being pinged is actually in the range of valid address
for that subnet ... but is not in use at the current moment).
You would get the message "Request timed out". By the way notice the start
and end time below. I can show a sniffer capture also .. but won't . there
are actual packets that left the pinging machines interface (ARP requests).
Current time is 4:28:11.41p <-- Start time
Pinging 192.168.12.88 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.12.88:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Current time is 4:28:29.09p <-- End Time
----
Demonstration 3:
ClientA: 192.168.12.5 /24 PINGS ClientB: 192.168.12.6 /24
A normal ping on the same subnet, works as expected.
Current time is 5:26:32.85p
Pinging 192.168.12.6 with 32 bytes of data:
Reply from 192.168.12.6: bytes=32 time=1ms TTL=128
Reply from 192.168.12.6: bytes=32 time<10ms TTL=128
Reply from 192.168.12.6: bytes=32 time<10ms TTL=128
Reply from 192.168.12.6: bytes=32 time<10ms TTL=128
Ping statistics for 192.168.12.6:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
Current time is 5:26:36.97p
---
Finally ... the question itself again:
Therefore . given Demonstration 1 and 2,
How will it ever find be able to generate an ARP that will find the router's
MAC address and send the packet to it?
Is this behavior ever different in other environments . or am I missing
something totally ?
Does the way a host machine behave during the ARP process differ amongst
different OS manufacturers, in relationship to when Proxy ARP can be
implement and when it can't be. According to the initial paragraph from
Doyle's book this should work. But as Demonstrations 1 and 2 showed it
didn't. It didn't. I assume in the line by Jeff Doyle ... "it may issue and
ARP request" ... he is implying this doesn't work with all hosts, and is
dependent on the host's machines behavior ?
This inquiry should not be mistaken with "is proxy ARP a good idea or bad
idea" question. I just want to find some behavior facts out.
Thanks.
- raj
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
