At 10:21 AM 2/11/01, Bob Vance wrote:
> >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.
I think it was Windows 3.1 with NetManage's TCP/IP stack. And it was only
certain versions of NetManage.
Priscilla
>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]
________________________
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]
