Thanks for confirming my suspicions, though one question on the  part about
setting the default gateway on a host to point to it's own ip address ...
would it behave the same way if the default gateway was set to a loopback
address of 127.x.x.x also. Or did that change the behavior ?

Thanks again.

- raj

"Priscilla Oppenheimer" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 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]

Reply via email to