Hello all:

We were given a /29 IP block by our provider. They gave us an Ethernet
link and we plugged it into the hub.

Today, we ran out of addresses, they gave us a new block /27. We would
have to change all the IP addresses of our servers but we put one IP
from
the new block into a server connected to the same hub. We were able to
surft
the net and we able to ping servers in the older /29 hub. How could
that be? can this hub handle two blocks at the same time? I thought
hubs can only one block at a time.

Thanks.

Is it safe to assume that the /29 is not contained within the /27? Are you
really using a hub? Are you using two different default gateway addresses
for members of the two subnets?

If the subnets are non-overlapping and you really are using a hub, then I
assume that the provided Ethernet line connects to the provider's router.
The router's Ethernet interface is configured with two addresses: one in
each subnet. Devices in one subnet are unaware that devices in the other
subnet are really on the same LAN segment. PINGs from one subnet to the
other are employing their default gateways. Only the provider's router
actually knows that the two subnets are on the same LAN segment.

Ron Bandes
CTT, CCNP, etc.

"John" <vo@eudoramail.com> wrote in message
news:184ae3db.0401081904.127dee64@posting.google.c om...

Yes, it is a hub.

The /29 is not contained within the /27, they are two different
separate blocks.

They are using two different default gateway addresses.

I don't know where I got it but I was under the impression that
you can only have one ethernet segment or subnet on one hub.

I guess I was wrong.




"Ron Bandes" <RunderscoreBandes @yah00.com> wrote in message news:<%opLb.96947$Cs3.14499181@news4.srv.hcvlny.cv .net>...

Yes, it is possible to run differnent subnets on the same hub. In general,
that is not good practice, but it may make sense in some situations. A hub
works at layer 2 and has no understanding of ip and subnets - so it doesn't
care.

Anyway, the hub will not route between them, the router does that.
Disconnect the gateway(s) from the hub and the pings should stop. That
said, devices can still communicate across the subnets through non-ip
protocols (netbeui/ipx).



"John" <vo@eudoramail.com> wrote in message
news:184ae3db.0401090848.f90eb8e@posting.google.co m...

On Fri, 09 Jan 2004 22:41:06 GMT, "Scooby"
<mmscooby1@removeme.earthlink.net> wrote:

Technically speaking two hosts could also talk to each other without a
router if their IP stack is designed to ARP for the destination
address (regardless of subnet) as opposed to the gateway address of
the local subnet. The destination host will happily reply to the ARP,
not knowing that the source isn't logically on its subnet.

However, I don't think MS does this in any of their products. It is
uncommon also because in a true routed network, this client behavior
requires support of Proxy ARP on the routers. But I have run across a
few devices that will still communicate to other hosts with no
problems and no routers even when in the wrong subnet. The first time
I saw that, I took me a while to figure out why.

--Bernie

In article <geruvvolj8or4k9emtoae4fuqgjh69ofns@4ax.com>,
Bernie <abuse@[127.0.0.1], see signature@[127.0.0.1]> wrote:
:Technically speaking two hosts could also talk to each other without a
:router if their IP stack is designed to ARP for the destination
:address (regardless of subnet) as opposed to the gateway address of
:the local subnet.

Not quite. That ARP still has to reach the destination in order
for the destination to reply. You can't address it directly to
the destination because if you knew the destination's IP you wouldn't
be ARPing to get that information. You therefore must broadcast
the ARP.

Normally ARP is broadcast by sending it to MAC address
ff:ff:ff:ff:ff:ff with the IP address set to the subnet broadcast
IP; if this is done, then although the destination ethernet hardware
will see the packet, it will quickly filter it out as not being
destined for that machine [often without generating an interrupt at all.]

There is an alternative, which is that the ARP can be broadcast to
MAC address ff:ff;ff:ff:ff:ff with the IP address set to 255.255.255.255;
if this is done, then the destination ethernet hardware will pass the
packet up the stack.

: The destination host will happily reply to the ARP,
:not knowing that the source isn't logically on its subnet.

Yes, if you can get the destination to pay attention to the packet
at all, then it may reply to the source MAC address it finds
in the packet, ignoring the fact that the source IP address is not
in the same subnet.

:However, I don't think MS does this in any of their products.

You haven't been reading my PIX postings ;-)

It turns out that MS Windows 2000 and XP (and possibly other MS
Windows version) *do* send to the all-nets broadcast address,
not to the IP subnet broadcast address. In the context of PIX,
this allows the odd situation of having multiple subnets behind
one PIX interface without having a router there.

I have taken advantage of this myself to push a public IP right through
the PIX [so that I could turn off NAT for the host because NAT broke some
VPN client software] even though the PIX inside interface was
a different subnet and I had no router there.
--
Preposterous!! Where would all the calculators go?!

Actually, a hub operates at layer 1. Hubs have no knowledge of MAC
addresses.

Ron Bandes
CTT, CCNP, etc.

"Scooby" <mmscooby1@removeme.earthlink.net> wrote in message
news:66GLb.767$i4.137@newsread1.news.atl.earthlink .net...

Scooby,

Microsoft Stacks work with two different subnets connected to the same wire
as you said but from memory event ID 8003 is repoteted when browser
announcements are advertised.

Regards,

Scott.
\|/
(o o)
---------------------oOOO--(_)--OOOo----------------------
Out the 100Base-T, off the firewall, through the router, down
the T1, over the leased line, off the bridge, nothing but Net.
(Use ROT13 to see my email address)
.oooO Oooo.
----------------------( )---( )-----------------------
\ ( ) /
\_) (_/


"Scooby" <mmscooby1@removeme.earthlink.net> wrote in message
news:66GLb.767$i4.137@newsread1.news.atl.earthlink .net...

Ah, yes, now that is different. Can two ip subnets operate on the same
physical media - absolutely. The problem with Microsoft comes when you have
a single machine that has two nic cards on separate subnets and those
subnets share the same wire. The reason is that the same machine will be
broadcasting the Netbios name with two separate ips. Actually what happens
is that the machine itself will recognize that and shut down the MS services
on that one nic - most likely that is the event ID 8003 you speak of. So,
both ips will still function properly, but only one nic will participate in
the MS network.


"scott enwright" <fpbgg_rajevtug@ovtcbaq.arg.nh> wrote in message
news:fX4Mb.5555$Wa.4247@news-server.bigpond.net.au...

Ooops, yea - my bad. Guess I've been in the switching world for too long
now <grin>.


"Ron Bandes" <RunderscoreBandes @yah00.com> wrote in message
news:1x3Mb.127535$Cs3.23937841@news4.srv.hcvlny.cv .net...

Scooby,

The event iD 8003 *definately* occurs on single NIC machines when the subnet
mask/network is different on two (or more) Windows Servers. It may occur as
well on dual homed servers but I haven't seen it.

Regards,

Scott.
\|/
(o o)
---------------------oOOO--(_)--OOOo----------------------
Out the 100Base-T, off the firewall, through the router, down
the T1, over the leased line, off the bridge, nothing but Net.
(Use ROT13 to see my email address)
.oooO Oooo.
----------------------( )---( )-----------------------
\ ( ) /
\_) (_/


"Scooby" <mmscooby1@removeme.earthlink.net> wrote in message
news:9wcMb.3391$i4.1634@newsread1.news.atl.earthli nk.net...

In article <btnua0$khs$1@canopus.cc.umanitoba.ca>, Walter Roberson
<roberson@ibd.nrc-cnrc.gc.ca> wrote:

No, it has to reach something that will reply to the ARP because it has
a route to the destination - it's called Proxy ARP.

ARPs are always broadcast.

Correct.

Incorrect - ARP is not carried in IP packets and the IP addresses are
contained in the packet data, not as source or destination addresses.

Correct, but not for that reason.

Nope - ARP does not use a destination IP address - see above.

If both hosts play the proxy ARP game this would work, but not for the
exact reason given - ARP packets don't have a "source IP address" in
that sense.

Using the all-ones broadcast IP address is sensible and entirely
correct (see RFC 1122 section 3.2.1.3 item (c), p30). It's defined NOT
as the all-nets address (a silly notion if ever there was one) but as
"every host on the connected physical network", i.e. all hosts on the
local subnet, the same as the local subnet broadcast. Using the
all-ones broadcast means that it's always correct and you don't need to
worry about working out what the correct subnet broadcast address is -
saves work and keeps things simple.

Hmmm. I guess it's moot whether a PIX should interfere with what
consenting adults do in private :-) but I think I might regard that as
a security hole. You didn't do it by routing ARP to a broadcast IP
address, though...


Sam Wilson
Network Development Team, Infrastructure Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK

Sam Wilson <Sam.Wilson@ed.ac.uk> wrote in message news:<120120041106007608%Sam.Wilson@ed.ac.uk>...
<snip>

I'm being a bit picky here, but I disagree with this. I have actually
captured ARP Request packets on an NAI Sniffer that had source and
destination MAC addresses, and source and destination IP addresses set
to non-broadcast values. The destination device also sent
corresponding ARP Replies.

I never found out why this was happening, but I can only imagine it
was used as some sort of confirmation by the initiating device that
its ARP table was still valid. Also, it was quite a long time ago, so
I can't remember for the life of me what devices were involved, or
even which site I was on at the time, but it definitely happened, and
I've seen it on more than one occasion.

Pete

In article <64d77c87.0401130158.1fdd62b8@posting.google.com>, Pete
Mainwaring <peter.mainwaring@virgin.net> wrote:

I'm sorry, you're right. Point-to-point ARP requests are specifically
mentioned in RFC 1122 as a method of confirming an ARP cache entry
(section 2.3.2.1, p.23) but I've never seen it happen in real life.
Obviously it does. It can also be used for less innocent purposes -
see
<http://cerberus.sourcefire.com/~jeff...at-2001/sonic_
boom.txt> for instance. Googling for "unicast ARP" is instructive.

Sam

On 10 Jan 2004 04:16:00 GMT, roberson@ibd.nrc-cnrc.gc.ca (Walter
Roberson) wrote:

You are thinking of name resolution which is a completely different
issue. If I ping w.x.y.z, my PC knows the destination address. The
ARP goes to the destination address, not the subnet in this case (keep
in mind I am describing a fairly unusual implementation of ARP but one
which the std allows for). The purpose of ARP is to resolve IP
addresses to MAC addresses, not to find IP addresses. It is assumed
that you already have dealt with the problem of finding the IP
address. See RFC 826 for the description of what ARP does:

"Presented here is a protocol that allows dynamic
distribution of the information needed to build tables to
translate an address A in protocol P's address space into a
48.bit Ethernet address."
http://www.ietf.org/rfc/rfc0826.txt?number=826

No mention of ARP being used to locate an IP address. That would be
the role of a name resolution protocol.

Wrong (the IP address part is wrong, the MAC address is correct).
Here is the example provided in the RFC:

"X knows that it wants to send to IPA(Y)....
.....creates an ADDRESS RESOLUTION
packet with
(ar$hrd) = ares_hrd$Ethernet
(ar$pro) = ET(IP)
(ar$hln) = length(EA(X))
(ar$pln) = length(IPA(X))
(ar$op) = ares_op$REQUEST
(ar$sha) = EA(X)
(ar$spa) = IPA(X)
(ar$tha) = don't care
(ar$tpa) = IPA(Y)
and broadcasts this packet to everybody on the cable."

Let me decode the one relevant part instead of providing the entire
key (which is listed earlier in the doc).

(ar$tpa) = Protocol address of target

So in effect, the actual destination IP field is the IP address of the
target. It is not the subnet address, directed subnet, broadcast IP,
or anything else.

Which is why ARPs are not sent to a subnet address. How would
non-target hosts know that they aren't the target?

Which would mean that all hosts would reply, which is not the desired
behavior. If you are looking for only one host MAC address, why would
you want all hosts to reply????

Along with every other host and their dog....

I don't know why the destination wouldn't pay attention. According to
RFC 826, the packet is addressed to the destination IP.

Not ARPs. Again, I think you are confusing ARP with something else.
ARPs are sent to only one of two possible IP addresses. It is always
sent to the target IP address being resolved, which means there are
only two possible targets when the destination host is off subnet.
The first is the destination host IP itself, the second is the gateway
IP address. Both are legitimate targets for the destination IP in an
ARP packet. Windows looks at the routing table and if the destination
is off subnet, it ARPs for the gateway. I have seen other devices
actually ARP for the destination host even when off subnet, so if the
router is not running Proxy ARP, ARP fails. But the other side effect
is that in multinetting environments, ARP works whether or not the
router is present.


--Bernie

On Mon, 12 Jan 2004 11:06:00 +0000, Sam Wilson <Sam.Wilson@ed.ac.uk>
wrote:

In the scenario I paint, there is no need for Proxy ARP as both hosts
are on the same broadcast domain though logically different subnets.
If the destination protocol address (inside the ARP packet) is the
actual target host as opposed to the gateway, the target machine will
receive it and reply without Proxy ARP running on the gateway.

I know this has already been addressed, but I will provide the exact
quote from RFC 826:

"It could set ar$tha to the broadcast address for the hardware (all
ones in the case of the 10Mbit Ethernet) if that makes it
convenient for some aspect of the implementation."

Technically you are right, not in the sense of an IP packet. The
destination IP address is in the ARP packet, but I think you know what
I mean.

What I am describing works without Proxy ARP.

I'm not sure how this relates to ARP.


--Bernie

In article <t3bc00lsjpktjf8kprutps7tt5lunliunm@4ax.com>, Bernie
<Bernie@weekend.com> wrote:

Your "in effect" phrasing may confuse. Just to be entirely clear there
is no "destination IP field" in an ARP packet in the sense that there
is in an IP packet. The (ar$tpa) field *in the packet data* is the IP
address that the sender is trying to find the MAC address for. The ARP
packet is NOT sent to that IP address, or indeed to any IP address, it
is sent to the layer 2 broadcast address (or exceptionally to a layer 2
unicast address).

Sam

In article <iidc00h52s0b0da22or1trtclmobtsi7s9@4ax.com>, Bernie
<Bernie@weekend.com> wrote:

In the first paragraph above you did not specify that the hosts be in
the same layer 2 broadcast domain, but even so I beg to differ. A host
will normally only ARP for an address which it knows to be on (one of)
its connected subnet(s); for all other addresses it will send packets
to the MAC address of a suitable gateway (which it will have found by
ARPing for the IP address of the gateway); if there's no gateway
address configured on a connected subnet the host cannot reach other
subnets.

Only a host which believes that proxy ARP would be supported by
adjacent gateways would ever try to ARP for other addresses. I don't
know of any implementations that take that approach.

No; ar$tha is the target hardware address field in the data packet. It
has nothing to do with how the packet is addressed in the MAC header.
Here is the quote in context:

... [the address resolution
module] does not set ar$tha to anything in particular,
because it is this value that it is trying to determine. It
could set ar$tha to the broadcast address for the hardware (all
ones in the case of the 10Mbit Ethernet) if that makes it
convenient for some aspect of the implementation. It then causes
this packet to be broadcast to all stations on the Ethernet cable
originally determined by the routing mechanism.

The last sentence tells you how the packet is addressed; the rest of
the quotation makes it clear that the content of ar$tha is irrelevant
to how the packet is sent.

I comment on this in my reply to your other message. It's prudent to
be precise in use of language.

Not so - see above. A host won't even try to use ARP like this unless
it's expecting proxy ARP to be available.

Sam

On Fri, 16 Jan 2004 13:35:40 +0000, Sam Wilson <Sam.Wilson@ed.ac.uk>
wrote:

That is because Walter snipped the context I was replying to. Here is
the statement from Scooby that stimulated my reply:

"Yes, it is possible to run different subnets on the same hub. In
general, that is not good practice, but it may make sense in some
situations. A hub works at layer 2 and has no understanding of ip and
subnets - so it doesn't care.

Anyway, the hub will not route between them, the router does that.
Disconnect the gateway(s) from the hub and the pings should stop. That
said, devices can still communicate across the subnets through non-ip
protocols (netbeui/ipx)."

The keyword is "normally." I agree that is the normal implementation.
I even said that. Every MS product I have used works the way you
describe. However, I have come across a device or two that will not
ARP for the gateway hardware address but rather the destination host
hardware address (obviously expecting Proxy ARP to be running on any
intermediate gateways).

I ran across this on a Sun box. I don't know if it was manually
configured to do this by someone else or if Sun does this by default.
Either way, I observed the Sun box doing this exact behavior.

Yes, you are right. I misread it.

Yes. I didn't realize we would be getting down to this level of
detail or I would have been more precise up front.

That is neither here nor there given the context. So if the device
expects Proxy ARP, then whether or not the router is actually present,
the two devices on the same broadcast domain will be able to
communicate whether they are in the same logical subnet or not. That
is the point. Saying that the device has to expect Proxy ARP is just
semantics, since it was built into my premise.

--Bernie

On Fri, 16 Jan 2004 13:03:36 +0000, Sam Wilson <Sam.Wilson@ed.ac.uk>
wrote:

Yes. Perhaps I should have chosen better wording.

--Bernie