two ip subnets in one hub possible?

Discussion in 'Cisco' started by John, Jan 9, 2004.

  1. John

    John Guest

    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.
     
    John, Jan 9, 2004
    #1
    1. Advertisements

  2. John

    Ron Bandes Guest

    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.
     
    Ron Bandes, Jan 9, 2004
    #2
    1. Advertisements

  3. John

    John Guest

    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.
     
    John, Jan 9, 2004
    #3
  4. John

    Scooby Guest

    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).
     
    Scooby, Jan 9, 2004
    #4
  5. John

    Bernie Guest

    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
     
    Bernie, Jan 10, 2004
    #5
  6. :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.
     
    Walter Roberson, Jan 10, 2004
    #6
  7. John

    Ron Bandes Guest

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

    Ron Bandes
    CTT, CCNP, etc.
     
    Ron Bandes, Jan 11, 2004
    #7
  8. 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.
    ----------------------( )---( )-----------------------
    \ ( ) /
    \_) (_/
     
    scott enwright, Jan 11, 2004
    #8
  9. John

    Scooby Guest

    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.
     
    Scooby, Jan 11, 2004
    #9
  10. John

    Scooby Guest

    Ooops, yea - my bad. Guess I've been in the switching world for too long
    now <grin>.
     
    Scooby, Jan 11, 2004
    #10
  11. 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.
    ----------------------( )---( )-----------------------
    \ ( ) /
    \_) (_/
     
    scott enwright, Jan 11, 2004
    #11
  12. John

    Sam Wilson Guest

    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.
    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, Jan 12, 2004
    #12
  13. 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
     
    Pete Mainwaring, Jan 13, 2004
    #13
  14. John

    Sam Wilson Guest

    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/presentations/blackhat-2001/sonic_
    boom.txt> for instance. Googling for "unicast ARP" is instructive.

    Sam
     
    Sam Wilson, Jan 13, 2004
    #14
  15. John

    Bernie Guest

    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
     
    Bernie, Jan 15, 2004
    #15
  16. John

    Bernie Guest

    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
     
    Bernie, Jan 15, 2004
    #16
  17. John

    Sam Wilson Guest

    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
     
    Sam Wilson, Jan 16, 2004
    #17
  18. John

    Sam Wilson Guest

    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
     
    Sam Wilson, Jan 16, 2004
    #18
  19. John

    Bernie Guest

    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
     
    Bernie, Jan 17, 2004
    #19
  20. John

    Bernie Guest

    Yes. Perhaps I should have chosen better wording.

    --Bernie
     
    Bernie, Jan 17, 2004
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.