At 05:35 PM 2/10/01, Raj Singh wrote:
>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.
Yes. You would have to do some testing to determine which ones ARP for
non-local stations and which don't. (It sounds like you already did some
testing.) When I used to teach the CIT class, one of the "bugs" we inserted
was to remove the default gateway in the PC. The goal was to make it
impossible for the PC to reach non-local stations. We also had to insert
"no proxy arp" in the router config, because sometimes removing the default
gateway didn't cause a problem. We were at the mercy of whatever TCP/IP
implementation happened to be on the PC. Different vendors, different OSs,
different versions worked differently.
One other trick is to set the default gateway to the station's own address.
For some strange reason, on some OSs this causes the station to ARP for
non-local addresses.
Priscilla
>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]
________________________
Priscilla Oppenheimer
http://www.priscilla.com
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
