Subject: RE: pinging problem

From: CARDOSO Jorge Miguel <[email-masked]>
Date: Sat, 9 Jun 2001 17:35:08 +0100

Mind buG Patch to my case 3 explanation: A and B could never be on the same
network (192.168.0.x/24) obviously! A could be 192.168.1.1/24 and B could be
192.168.2.2/24 - under a normal consistent condition.

-----Original Message-----
From: CARDOSO Jorge Miguel
To: 'Vijayendra Sharma '; [email-masked] '
Sent: 09-06-2001 17:26
Subject: RE: pinging problem

|o|

rotfl

vIjaYenDra is this problem a little gamE? |o|

i think its the third email i receive with same question!!
congratulations, your persistence gives you the answers:

Comments to your choosen addressing scheeme: 
- network addressing 192.168.0.x/ 24 should not be used under normal
conditions and it would not be possible to configure it with some
routers because its a subnetzero. Has an example, for use it with Cisco
routers, you need to use the ios  command 'ip subnet-zero'.

case 1)
-------
A and B can ping eachother.

case 2)
-------
The answer is variable concerning the switch type and configuration.
Is it a multilayer switch?
Have you configured Vlans on this switch?

The answer is: A and B will ping eachother if they are on the same
broadcast domain (on the same lan segment/ on the same vlan).

case 3)
-------
A will not reach B unless the router is configured with bridging.
Look: under this scenario A thinks that will find layer 2 address
(MAC-address) of B and it will ask for it with an arpRequest but will
never get any ArpReply from B because they are on different broadcast
domains.

Under a normal circunstance with choosen mask A 192.168.0.x/24, the
process would be like this:

- host A guess that 192.168.0.2 its not on the same broadcast domain
using the mask /24, so it would ask the layer 2 address of the gateway
and not the layer 2 address of B;
- host A would receive the MAC address of the router, and it would
deliver all the packets to the router;
- the router would look to layer 3 address of the packets, search the
outgoing interface and obtain the layer 2 address of B;
- the router would change destination layer 2 address of the packets to
B mac-address and then send it to the lan segment were B is located.

* NoW it's weekend time, forget for a while the insipid network concepts
and enjoy the sun with your girlfriend! have a nice weekend full of bits
and moon and sea and peace and love.

j0rge card0s0

-----Original Message-----
From: Vijayendra Sharma
To: [email-masked]
Sent: 09-06-2001 13:30
Subject: pinging problem

Hello sir,
   Can you help me with this problem,
 Will machines A and B able to ping eachother,

      A                                B
1)192.168.0.1/16-----Hub------192.168.0.2/24

2)192.168.0.1/16-----Switch------192.168.0.2/24

3)192.168.0.1/16-----Router------192.168.0.2/24

 i will be helpful to you, if you can help me in anyway.
regards,
    Vijayendra.

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

---

From: [email-masked]
Date: Sun, 10 Jun 2001 02:54:31 -0400

> 3)192.168.0.1/16-----Router------192.168.0.2/24

Doesn't it bother anybody else that in cases 1 and 2, the netmask widths
are inconsistent?  That's probably very bad network design, unless you
*really* understand what you're doing.  Yes, we've done things like
that ourselves (for instance, we played *all* sorts of games when we
were subnetting our first /16 into /22's back in '89 - amazing how much
stuff then got upset at a /22 subnet mask on a 'class B' address block ;)

The addresses 192.168.0.1 and 192.168.0.2 should have the same netmask
width - even if you're using a /32 for case (3) as per the recent RFC
regarding the numbering of point-to-point lenghts.

The problem is that if there is a *third* host (for instance 192.168.1.1),
host A will say "this is on the local subnet along with host B, because
it's inside my /16", but host B will say "Host A is inside my /24,
but the host C is off the local subnet because it's outside the /24".
This *will* break things.

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech