>because sometimes removing the default
>gateway didn't cause a problem.
That's interesting. I've never run across an OS implementation like
that (that I know of :), but I've been pretty much limited to Windoze
and various Unices. Can you remember some specific examples.
Now that I think about it, though, I believe that I *do* vaguely
remember configuring some kind of network device that asked something
like "ARP for addresses?" -- and maybe it was "ARP for non-local
addresses?". I would guess that I said "No", not really knowing what
it was asking and always using a default route :)
I know that Windoze does *not* default to ARP for non-local, as RAJ just
also showed, but it *does* support the "route-to-self".
Linux behaves the same way.
-------------------------------------------------
Tks��� ��� | <mailto:[EMAIL PROTECTED]>
BV��� ���� | <mailto:[EMAIL PROTECTED]>
Sr. Technical�Consultant,� SBM, A Gates/Arrow Co.
Vox 770-623-3430�����������11455 Lakefield Dr.
Fax 770-623-3429���������� Duluth, GA 30097-1511
=================================================
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Priscilla Oppenheimer
Sent: Saturday, February 10, 2001 6:20 PM
To: [EMAIL PROTECTED]
Subject: Re: A inquiry about ARP behavior, vendors, and differences
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]
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
