Low Cost Hub With Read-Only Ports? - TCP-IP

This is a discussion on Low Cost Hub With Read-Only Ports? - TCP-IP ; Ethernet "hubs" - or in olderspeak multiport repeaters - are simply physical layer devices and are by definition half duplex. An attempt to transmit simultaneously by any two or more stations connected to the hub will result in a collision ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 37 of 37

Thread: Low Cost Hub With Read-Only Ports?

  1. Re: Low Cost Hub With Read-Only Ports?

    Ethernet "hubs" - or in olderspeak multiport repeaters - are simply
    physical layer devices and are by definition half duplex. An attempt
    to transmit simultaneously by any two or more stations connected to
    the hub will result in a collision and the rest of the normal CSMA/CD
    behaviour.

    Ethernet "switches" - or in olderspeak multiport bridges - are
    data-link layer devices and can operate their ports either half-duplex
    or full duplex. If two stations connected to a switch both attempt to
    transmit to the same third station the and everyone is full duplex,
    the switch will generally have some buffering to hold the traffic
    which would have otherwise "collided" If that buffering is exhausted,
    then the switch will simply discard the frame. (Well, before the IEEE
    started adding flow-control to Ethernet, in part I suspect because the
    natural flow-control of CSMA/CD was lost when everythign went
    full-duplex

    If you see a name where the two terms are combined, it is usually the
    result of marketroid interference and is otherwise a misnomer.

    rick jones
    --
    firebug n, the idiot who tosses a lit cigarette out his car window
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  2. Re: Low Cost Hub With Read-Only Ports?

    On Tue, 29 May 2007 18:37:20 +0000, Rick Jones wrote:

    > Ethernet "hubs" - or in olderspeak multiport repeaters - are simply
    > physical layer devices and are by definition half duplex. An attempt to
    > transmit simultaneously by any two or more stations connected to the hub
    > will result in a collision and the rest of the normal CSMA/CD behaviour.


    That is what I thought as well.

    (snip)

    >
    > If you see a name where the two terms are combined, it is usually the
    > result of marketroid interference and is otherwise a misnomer.


    Well, I don't think Vernon enjoys being accused of marketroid
    interference :-), he was the one to bring up FDX hubs and he usually
    knows what he is talking about.

    Guess it's all a red herring and a hub is HDX. Period.

    M4

  3. Re: Low Cost Hub With Read-Only Ports?

    In article ,
    Martijn Lievaart wrote:

    >> If you see a name where the two terms are combined, it is usually the
    >> result of marketroid interference and is otherwise a misnomer.


    The language for Ethernet has been hopelessly corrputed by marketroids.
    Even the IEEE has joined the dark side by applying "Ethernet" to link
    layers that have nothing to do with CSMA/CD.


    >Well, I don't think Vernon enjoys being accused of marketroid
    >interference :-), he was the one to bring up FDX hubs and he usually
    >knows what he is talking about.
    >
    >Guess it's all a red herring and a hub is HDX. Period.


    When writing for netnews, you can nod to the old, correct terms,
    but if you want to be understood by (or helpful to) most readers,
    you must use the words they encounter in the trade rags and stores
    and from their friends.

    If you try to byy an "Ethernet hub" at a retail store, you will probably
    leave with a device that automatically handles connections to hosts and
    at least one other "hub" and at mixture of 10 and 100 MHz. It might
    even lack a special "uplink" socket with the TX and RX pairs swapped
    but instead switch pairs on any socket automagically. Only if you shop
    at a used equipment dealer can you hope to find a real 10-BASE T hub.

    We recognize "10/100 hubs" as multi-port bridges, but if you try to buy
    any sort of "bridge" at the retail store, you are likely to be disappointed.

    If you try to buy an "Ethernet repeater," you might get some flavor of
    802.11 device that acts like a 2 port Ethernet bridge and is neither
    what the radio people used to call "repeaters" nor what the IEEE 802.3
    standards called "repeaters."


    Vernon Schryver vjs@rhyolite.com

  4. Re: Low Cost Hub With Read-Only Ports?

    On Tue, 29 May 2007 19:11:45 +0000, Vernon Schryver wrote:

    >>Guess it's all a red herring and a hub is HDX. Period.

    >
    > When writing for netnews, you can nod to the old, correct terms, but if
    > you want to be understood by (or helpful to) most readers, you must use
    > the words they encounter in the trade rags and stores and from their
    > friends.


    True, but can an 10/100 multiport bridge be FDX or is it always HDX? That
    was my question. I still fail to see how it can be FDX except in very
    specific circumstances (which may still make sense). (I do see how a 2
    port bridge can be FDX).

    Even if it is theoretically possible, are/were those really made?

    (Note that this is not an entirely academic question, I do encounter
    "hubs" on our network on an almost daily basis. These are always
    connected to switchports that are set to 10/HDX on one end and devices
    that are set to auto/auto on the other end. We never encountered any
    problems, but I want to be prepared).

    >
    > If you try to byy an "Ethernet hub" at a retail store, you will probably
    > leave with a device that automatically handles connections to hosts and
    > at least one other "hub" and at mixture of 10 and 100 MHz. It might
    > even lack a special "uplink" socket with the TX and RX pairs swapped but
    > instead switch pairs on any socket automagically. Only if you shop at a
    > used equipment dealer can you hope to find a real 10-BASE T hub.


    I still have several, especially for sniffing (but I never tried a rx-
    only cable). As I have several 10/100 bridges.

    > We recognize "10/100 hubs" as multi-port bridges, but if you try to buy
    > any sort of "bridge" at the retail store, you are likely to be
    > disappointed.


    Yes, these are generally not on sale anymore :-)

    > If you try to buy an "Ethernet repeater," you might get some flavor of
    > 802.11 device that acts like a 2 port Ethernet bridge and is neither
    > what the radio people used to call "repeaters" nor what the IEEE 802.3
    > standards called "repeaters."


    Interesting. Yes, IIRC the original repeaters were plain amplifiers. IIRC
    (again) thick and thin ethernet both could do a certain length (1,5Km?
    900mtrs?) based on the RTT of the frame, but needed amplification to
    achieve those lengths.

    Nowadays one can buy ethernet 10base-whatever repeaters (I DON'T mean
    802.11 repeaters, I work with those daily and if I never see another one
    it's way too late). I guess those repeaters are really just 2 port
    bridges/switches. Is this correct?

    TIA,
    M4

  5. Re: Low Cost Hub With Read-Only Ports?

    In article ,
    Martijn Lievaart wrote:

    >True, but can an 10/100 multiport bridge be FDX or is it always HDX? That
    >was my question. I still fail to see how it can be FDX except in very
    >specific circumstances (which may still make sense). (I do see how a 2
    >port bridge can be FDX).


    Why can't a bridge be full duplex readily as a host? A major purpose
    of the original bridges was to break up a collision domain, so that two
    hosts could transmit at the same time without colliding. To make that
    possible, a bridge has buffers for packets and generally acts like an
    IP router but at the link layer. Instead of looking at IP addresses
    and using static routes, RIP or some other IP routing protocol, an
    Ethernet bridge looks at 48-bit Ethernet MAC addresses and uses static
    routes, "learning," or Spanning Tree as the routing protocol.

    >Even if it is theoretically possible, are/were those really made?


    I think all of the boxes you find with
    http://www.google.com/search?q=10%2F100+hub
    are (or can be used as) FDX.

    The fundamental CSMA/CD limits are specified in bits even at 100 MHz.
    A 10 MHz Ethernet required all stations to be within 500 meters of each
    other. At 100 MHz, the size of a collision domain shrinks to 50 meters.
    That shrink to such a physically tiny network is why everyone was willing
    to pay the costs of having 100 MHz hubs be vastly more complex multi-port
    bridges that could be full duplex (FDX) instead classic repeaters.
    10 MHz 10BASE-T hubs were merely multi-port repeaters. As bits came
    in on one twisted pair cable, they were pumped out on all other cables.


    >(again) thick and thin ethernet both could do a certain length (1,5Km?
    >900mtrs?) based on the RTT of the frame, but needed amplification to
    >achieve those lengths.


    The CSMA/CD distance limit is that no two stations can be separated by
    more than one slot time or the time required to send 64 bytes. When
    two stations start transmitting at about the same time, both must hear
    the other and so know about their collision during the first 64 bytes or
    512 bits of the frame.


    Vernon Schryver vjs@rhyolite.com

  6. Re: Low Cost Hub With Read-Only Ports?

    > True, but can an 10/100 multiport bridge be FDX or is it always HDX?

    A 10/100 multiport bridge can be FDX. It is, afterall, not a "hub"
    Not likely to do FDX at 10 since little legacy 10 mbit/s kit groked
    FDX.

    rick jones
    --
    a wide gulf separates "what if" from "if only"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  7. Re: Low Cost Hub With Read-Only Ports?

    On Wed, 30 May 2007 14:35:00 +0000, Vernon Schryver wrote:

    > In article , Martijn Lievaart
    > wrote:
    >
    >>True, but can an 10/100 multiport bridge be FDX or is it always HDX?
    >>That was my question. I still fail to see how it can be FDX except in
    >>very specific circumstances (which may still make sense). (I do see how
    >>a 2 port bridge can be FDX).

    >
    > Why can't a bridge be full duplex readily as a host? A major purpose of
    > the original bridges was to break up a collision domain, so that two
    > hosts could transmit at the same time without colliding. To make that


    That's news to me. When I did (postgraduate) classes on networking
    (admittedly a looong time ago), there was only talk about bridging
    different topologies together.

    > possible, a bridge has buffers for packets and generally acts like an IP
    > router but at the link layer. Instead of looking at IP addresses and
    > using static routes, RIP or some other IP routing protocol, an Ethernet
    > bridge looks at 48-bit Ethernet MAC addresses and uses static routes,
    > "learning," or Spanning Tree as the routing protocol.


    That description describes indeed a possible 10/100 ethernet bridge.
    However, I would call that a switch.

    So my question was maybe improperly phrased. Let me rephrase. Can any
    10/100 ethernet "hub" (which really is a bridge, but is sold as a hub) be
    FDX?

    >
    >>Even if it is theoretically possible, are/were those really made?

    >
    > I think all of the boxes you find with
    > http://www.google.com/search?q=10%2F100+hub are (or can be used as) FDX.


    Actually they cannot. The better brands (f.i. Cisco) do note that. Even
    if it is only implicit (Intel) where it is noted that the stack-link *is*
    full duplex. The cheaper brands do not talk about duplex at all. The only
    exceptions are some switches which are improperly labeled as a hub.

    For even more interesting reading, try http://www.google.com/search?q=10%
    2F100+hub+duplex

    That leads to a.o. http://wiki.wireshark.org/HubReference that cleared up
    a lot for me:

    ] Dual-speed hub warning
    ]
    ] Note that "dual-speed" hubs that support both 10MBit and 100MBit ports
    ] might not send all unicast traffic between 10MBit and 100MBit ports; if
    ] so, you can only capture all traffic between hosts whose Ethernet
    ] interfaces are both running at the same speed as the Ethernet interface
    ] on the machine capturing traffic.
    ]
    ] This means that if you have two hosts communicating at 100MBit/s, you
    ] will only be able to capture the traffic between them if the Ethernet
    ] interface of the machine capturing traffic is configured for 100MBit/s.
    ] Similarly, if you have two hosts communicating at 10MBit/s, you will
    ] only be able to capture the traffic between them if the Ethernet
    ] interface of the machine capturing traffic is configured for 10MBit/s,
    ] which is probably not the default configuration.
    ]
    ] Some dual-speed hubs don't connect the 10MBit and 100MBit ports at all;
    ] with those hubs, two hosts whose Ethernet interfaces are running at
    ] different speeds will not be able to communicate, so there's no traffic
    ] between hosts of different speeds, and thus no traffic between them to
    ] capture.

    ] Other dual-speed hubs have an internal switch connecting the 10MBit and
    ] 100 Mbit ports, so that only broadcast and multicast traffic, and
    ] unicast traffic to the host on a particular port, will be sent to that
    ] port if the traffic comes from a port with a different speed; with
    ] those hubs, two hosts whose Ethernet interfaces are running at
    ] different speeds will be able to communicate.
    ]
    ] If you have a dual-speed hub with an internal switch, it means that if
    ] you have a 10MBit host communicating with a 100MBit host, you will only
    ] be able to see one direction of that traffic; you will only see the
    ] traffic from the 10MBit host if the interface of the machine capturing
    ] traffic is configured for 10Mbit/s, and you will only see the traffic
    ] from the 100 Mbit host if the interface of the machine capturing
    ] traffic is configured for 100MBit/s.

    So although theoretically one could device a multiport 10/100 bridge that
    is not a switch, it seems that in practice most (all?) models are
    implemented as two collision domains connected by a switch/bridge (and
    some magic to connect the correct port to the correct collision domain).
    Which means they are HDX by definition on either collision domain.

    It probably would be theoretically possible to "speak" full duplex
    between a host on the 10Mb segment and one on the 100 Mb segment.
    However, all devices I looked at did autosensing, not autonegotiation, so
    only implement HDX.

    > The fundamental CSMA/CD limits are specified in bits even at 100 MHz. A
    > 10 MHz Ethernet required all stations to be within 500 meters of each


    Not completely correct. With 10base5, the maximum segment length is 500
    meters. I could not find what the maximum collision domain length is,
    although 802.3 allows for a maximum of 4 repeaters (which would mean 2Km,
    which seems a bit much to me, but does somewhat coincide with my
    recollection of 1,5Km)

    With 10base2, the maximum length is 185 meters for a segment which can be
    expanded to around 900 meters with repeaters. For 10base-T, the maximum
    length is unspecified, but is expected to be around 100 meters on average
    cabling, up to 150 meters on good cabling. Again, this can be extended
    with up to 4 repeaters.

    > other. At 100 MHz, the size of a collision domain shrinks to 50 meters.


    100base-T has a maximum segment length of 100 meters, and I think a
    maximum collision domain of 500 meters.

    > That shrink to such a physically tiny network is why everyone was
    > willing to pay the costs of having 100 MHz hubs be vastly more complex
    > multi-port bridges that could be full duplex (FDX) instead classic


    You lost me here. You are talking about switches, not?

    > repeaters. 10 MHz 10BASE-T hubs were merely multi-port repeaters. As
    > bits came in on one twisted pair cable, they were pumped out on all
    > other cables.
    >
    >
    >>(again) thick and thin ethernet both could do a certain length (1,5Km?
    >>900mtrs?) based on the RTT of the frame, but needed amplification to
    >>achieve those lengths.

    >
    > The CSMA/CD distance limit is that no two stations can be separated by
    > more than one slot time or the time required to send 64 bytes. When two
    > stations start transmitting at about the same time, both must hear the
    > other and so know about their collision during the first 64 bytes or 512
    > bits of the frame.


    Yes that was it. However, that limits the collision domain, not the
    maximum segment limit, which is determined by electrical limitations.
    Hence the use of repeaters.

    M4

  8. Re: Low Cost Hub With Read-Only Ports?

    On Wed, 30 May 2007 17:18:00 +0000, Rick Jones wrote:

    >> True, but can an 10/100 multiport bridge be FDX or is it always HDX?

    >
    > A 10/100 multiport bridge can be FDX. It is, afterall, not a "hub"
    > Not likely to do FDX at 10 since little legacy 10 mbit/s kit groked FDX.


    See my answer to Vernon. I now think that in practice, any 10/100
    multiport bridge, which is not a switch, is HDX. There may have been
    other implementations, but I have been unable to find them.

    M4

  9. Re: Low Cost Hub With Read-Only Ports?

    In article ,
    Martijn Lievaart wrote:

    >> Why can't a bridge be full duplex readily as a host? A major purpose of
    >> the original bridges was to break up a collision domain, so that two
    >> hosts could transmit at the same time without colliding. To make that

    >
    >That's news to me. When I did (postgraduate) classes on networking
    >(admittedly a looong time ago), there was only talk about bridging
    >different topologies together.


    I'm not absolutely certain, but I think Digital, Bridge, and 3Com
    Ethernet bridges predated bridging token rings and Ethernets. See
    http://www.google.com/search?q=3com+history
    http://www.google.com/search?q=decnet+collision+domain
    http://www.google.com/search?q=decne...roadcast+storm


    >> possible, a bridge has buffers for packets and generally acts like an IP
    >> router but at the link layer. Instead of looking at IP addresses and
    >> using static routes, RIP or some other IP routing protocol, an Ethernet
    >> bridge looks at 48-bit Ethernet MAC addresses and uses static routes,
    >> "learning," or Spanning Tree as the routing protocol.

    >
    >That description describes indeed a possible 10/100 ethernet bridge.
    >However, I would call that a switch.


    Old timers who are not marketoons and did not learn everything they
    "know" from salescritters and the trade rags know that "switch" was
    marketspeak first used to describe a brand of dumb multi-port bridges
    with cut-through routing. They were so dumb that they were dangerous,
    because they did not do spanning tree. The instructions cautioned
    against using them in topologies with redundant links because that would
    create loops in which packets would circulate forever and (virtually)
    melt networks. I know of a company whose know-everything-because-they-read-
    the-trade-rags-and-had-friends-who-where-sales-people network experts
    bought a bunch of the first "switches," ignored that caution, created
    loops, (virtually) melted networks, and then threw out Kalpana as an
    evil vendor instead of admitting that they didn't know or understand
    as much as they told to their bosses.

    Cut-through routing is starting to transmit a packet before it has
    finished arriving. If you do that between CSMA/CD networks before the
    end of the first slot time, you forward collision fragments and waste
    bandwidth. If you delay 64 byte-times until after the first slot time,
    you waste some but less bandwidth by forwarding packets with bad
    checksums. Cut-through routing can help benchmark throughput numbers
    for hosts and/or protocols too little buffering (e.g. TCP window too
    small), which is why trade-rag-educated experts leaped to buy Kalpana
    "switches" when they first appeared.


    >So my question was maybe improperly phrased. Let me rephrase. Can any
    >10/100 ethernet "hub" (which really is a bridge, but is sold as a hub) be
    >FDX?


    I don't see a significant difference in phrasing. Judging from
    http://www.hp.com/rnd/support/faqs/1....htm#question9
    I am wrong and some 10/100 hubs could not do 100 FDX.

    >> I think all of the boxes you find with
    >> http://www.google.com/search?q=10%2F100+hub are (or can be used as) FDX.

    >
    >Actually they cannot. The better brands (f.i. Cisco) do note that.


    Where in the first hit for that URL,
    http://www.cisco.com/en/US/products/...080091e3b.html
    is the mention of not handling full duplex? It does say
    Eight 10BaseT/100BaseTX autosensing ports with internal bridging

    The Linksys 10/100 hub at my elbow with the CiscoSystems logo has
    autonegotiated 100 MHz full duplex (FDX) with some of my boxes. True,
    it does say it is a "10/100 8-port Workgroup Switch Model EZXS88W"
    instead of "hub," but I bought it years ago in the "hub" aisle of a
    retail electronics store for next to nothing. The current street price
    is less than $29 or less than the price of 8 jumper cables. The 5 port
    EZXS55W is selling for less than $20. That is almost literally dirt
    cheap or not much more than the bags of potting soil I bought this spring.


    > Even
    >if it is only implicit (Intel) where it is noted that the stack-link *is*
    >full duplex. The cheaper brands do not talk about duplex at all.


    Are you sure that's not because no one buys true hubs any more, because
    the difference in cost between silicon that is a multi-port bridge
    ("switch") and silicon that is a classic 802.3 repeater ("hub") is too
    low to justify making the repeater? Looking at
    http://www.cisco.com/en/US/products/index.html
    I see "switches" but no "hubs" among the links. Searching for "10/100
    hub" I found only ancient products that have been "end of lifed" such as
    http://www.cisco.com/en/US/products/...209/index.html


    > The cheaper brands do not talk about duplex at all. The only
    >exceptions are some switches which are improperly labeled as a hub.


    I'm having trouble understanding that. I've been saying that essentially
    all current 10/100 "hubs" are really multi-port bridges. That they may
    be improperly labelled does not seem exciting, particularly in a
    conversation where the bogus term "switch" is used heavily.


    >That leads to a.o. http://wiki.wireshark.org/HubReference that cleared up


    >] Some dual-speed hubs don't connect the 10MBit and 100MBit ports at all;
    >] with those hubs, two hosts whose Ethernet interfaces are running at
    >] different speeds will not be able to communicate, so there's no traffic
    >] between hosts of different speeds, and thus no traffic between them to
    >] capture.


    Given any sort of incredibly mis-designed junk you can imagine, if you
    look hard enough you can probably find both vendors and buyers. However,
    would you buy a 10/100 connecting box that did not connect the 10 and
    100 MHz networks?

    >So although theoretically one could device a multiport 10/100 bridge that
    >is not a switch, it seems that in practice most (all?) models are
    >implemented as two collision domains connected by a switch/bridge (and
    >some magic to connect the correct port to the correct collision domain).
    >Which means they are HDX by definition on either collision domain.


    How do you get "in practice most" from that wireshark.org article? I
    would agree with "some at one time" and perhaps even "many long ago,"
    but not "most today" without some marketshare numbers. That $30 8-port
    Cisco box at my elbow would keep me from agreeing with "all" regardless.


    >It probably would be theoretically possible to "speak" full duplex
    >between a host on the 10Mb segment and one on the 100 Mb segment.
    >However, all devices I looked at did autosensing, not autonegotiation, so
    >only implement HDX.


    What if you look at boxes that do autonegotiation? What if you look
    at boxes that have not been end-of-lifed?


    >> The fundamental CSMA/CD limits are specified in bits even at 100 MHz. A
    >> 10 MHz Ethernet required all stations to be within 500 meters of each

    >
    >Not completely correct. With 10base5, the maximum segment length is 500
    >meters. I could not find what the maximum collision domain length is,
    >although 802.3 allows for a maximum of 4 repeaters (which would mean 2Km,
    >which seems a bit much to me, but does somewhat coincide with my
    >recollection of 1,5Km)


    Yes, I'm wrong about that too. I was "thinking" about a purely bogus speed
    of light. As 4.1.2.2 of IEEE Std 802.3-1985 says:

    ... A given station can experience a collision during the initial
    part of its transmission (the collision window) before its transmitted
    signal has had time to propagate to all stations on the CSMA/CDA
    medium. One the collision window has passed, a transmitting statio
    is said to have aquaired the medium; subsequent collisios are avoided
    since all other (properly function) staitons can be assumed to ahve
    noticed the signal (by way of carrier sense) and to be derring to it.

    Section 8.6.1 assumes a sped of light of 0.77 c and a maximum end-to-end
    propagation deay of 2570 ns. So a round trip is 5.14 microseconds or
    about what you'd expect with a slot time of 512 bits and the frame preamble.
    Figure 8-10 shows a "Maximum Transmission Path" involving 5 segments
    of coax, each presumably the maximum of 500 meters given in section 8.6.1.
    That's a total of 2500 meters.

    >> other. At 100 MHz, the size of a collision domain shrinks to 50 meters.

    >
    >100base-T has a maximum segment length of 100 meters, and I think a
    >maximum collision domain of 500 meters.


    We're both wrong. At 10 times the bit rate, the slot time has 10% as
    many microseconds, and so the speed of light limits a 100 MHz collision
    domain to 250 meters.


    >> That shrink to such a physically tiny network is why everyone was
    >> willing to pay the costs of having 100 MHz hubs be vastly more complex
    >> multi-port bridges that could be full duplex (FDX) instead classic

    >
    >You lost me here. You are talking about switches, not?


    Again, "switch" is old market-speak for "you must buy my fast multi-port
    bridge."


    Vernon Schryver vjs@rhyolite.com

  10. Re: Low Cost Hub With Read-Only Ports?

    On Wed, 30 May 2007 22:47:08 +0000, Vernon Schryver wrote:

    > In article , Martijn Lievaart
    > wrote:
    >
    >>> possible, a bridge has buffers for packets and generally acts like an
    >>> IP router but at the link layer. Instead of looking at IP addresses
    >>> and using static routes, RIP or some other IP routing protocol, an
    >>> Ethernet bridge looks at 48-bit Ethernet MAC addresses and uses static
    >>> routes, "learning," or Spanning Tree as the routing protocol.

    >>
    >>That description describes indeed a possible 10/100 ethernet bridge.
    >>However, I would call that a switch.

    >
    > Old timers who are not marketoons and did not learn everything they
    > "know" from salescritters and the trade rags know that "switch" was
    > marketspeak first used to describe a brand of dumb multi-port bridges
    > with cut-through routing. They were so dumb that they were dangerous,
    > because they did not do spanning tree. The instructions cautioned
    > against using them in topologies with redundant links because that would
    > create loops in which packets would circulate forever and (virtually)
    > melt networks. I know of a company whose
    > know-everything-because-they-read-
    > the-trade-rags-and-had-friends-who-where-sales-people network experts
    > bought a bunch of the first "switches," ignored that caution, created
    > loops, (virtually) melted networks, and then threw out Kalpana as an
    > evil vendor instead of admitting that they didn't know or understand as
    > much as they told to their bosses.


    Yes, that is a well known story. I wonder if this did actually happen to
    a number of companies, as the story is rather to well known. :-)

    >
    > Cut-through routing is starting to transmit a packet before it has
    > finished arriving. If you do that between CSMA/CD networks before the
    > end of the first slot time, you forward collision fragments and waste
    > bandwidth. If you delay 64 byte-times until after the first slot time,
    > you waste some but less bandwidth by forwarding packets with bad
    > checksums. Cut-through routing can help benchmark throughput numbers
    > for hosts and/or protocols too little buffering (e.g. TCP window too
    > small), which is why trade-rag-educated experts leaped to buy Kalpana
    > "switches" when they first appeared.


    Learn something every day. Thx.

    >>> I think all of the boxes you find with
    >>> http://www.google.com/search?q=10%2F100+hub are (or can be used as)
    >>> FDX.

    >>
    >>Actually they cannot. The better brands (f.i. Cisco) do note that.

    >
    > Where in the first hit for that URL,
    > http://www.cisco.com/en/US/products/hw/hubcont/ps209/

    products_data_sheet09186a0080091e3b.html
    > is the mention of not handling full duplex? It does say
    > Eight 10BaseT/100BaseTX autosensing ports with internal bridging


    I get a different first hit, and got yet another one yesterday. However,
    in the manual it is mentioned (although for this model implicitely). I
    did not say every page found on this search mentions this.

    >
    > The Linksys 10/100 hub at my elbow with the CiscoSystems logo has
    > autonegotiated 100 MHz full duplex (FDX) with some of my boxes. True,
    > it does say it is a "10/100 8-port Workgroup Switch Model EZXS88W"
    > instead of "hub," but I bought it years ago in the "hub" aisle of a
    > retail electronics store for next to nothing. The current street price
    > is less than $29 or less than the price of 8 jumper cables. The 5 port
    > EZXS55W is selling for less than $20. That is almost literally dirt
    > cheap or not much more than the bags of potting soil I bought this
    > spring.


    OK. That one is found through that search, however, it IS a switch, even
    if it is branded as a hub.

    >> Even
    >>if it is only implicit (Intel) where it is noted that the stack-link
    >>*is* full duplex. The cheaper brands do not talk about duplex at all.

    >
    > Are you sure that's not because no one buys true hubs any more, because
    > the difference in cost between silicon that is a multi-port bridge
    > ("switch") and silicon that is a classic 802.3 repeater ("hub") is too
    > low to justify making the repeater? Looking at
    > http://www.cisco.com/en/US/products/index.html I see "switches" but no
    > "hubs" among the links. Searching for "10/100 hub" I found only ancient
    > products that have been "end of lifed" such as
    > http://www.cisco.com/en/US/products/...209/index.html


    That may be part of it, but I looked at the specs of the first 5 or so
    hubs (all of them discontinued) I could find through Google.

    >
    >
    >> The cheaper brands do not talk about duplex at all. The
    >> only
    >>exceptions are some switches which are improperly labeled as a hub.

    >
    > I'm having trouble understanding that. I've been saying that
    > essentially all current 10/100 "hubs" are really multi-port bridges.


    No, I don't agree. Most 10/100 hubs are two hubs with a two port switch
    or bridge between them (is there a difference between a switch and a
    bridge when there are only two ports?). That is not what I would call a
    multiport bridge in the technical sense, even if you can call it a
    bridge. Just not a multiport bridge.

    A true multiport bridge bridges between all ports, so a 10/100 switch is
    a multiport bridge.

    > That they may be improperly labelled does not seem exciting,
    > particularly in a conversation where the bogus term "switch" is used
    > heavily.


    What is bogus about the term switch? It's pretty well defined I think.
    Depending on your definition of bridge (which is much less well defined
    in my eyes) a switch can be a bridge, but doesn't have to be.

    But even if you define bridge in such a way that all switches are
    bridges, the term switch defines a certain subset of bridges. See below.

    >
    >>That leads to a.o. http://wiki.wireshark.org/HubReference that cleared
    >>up

    >
    >>] Some dual-speed hubs don't connect the 10MBit and 100MBit ports at
    >>all; ] with those hubs, two hosts whose Ethernet interfaces are running
    >>at ] different speeds will not be able to communicate, so there's no
    >>traffic ] between hosts of different speeds, and thus no traffic between
    >>them to ] capture.

    >
    > Given any sort of incredibly mis-designed junk you can imagine, if you
    > look hard enough you can probably find both vendors and buyers.
    > However, would you buy a 10/100 connecting box that did not connect the
    > 10 and 100 MHz networks?


    Apparently some people did, and I'm not in the least surprised. People
    also run unpatched qmails, and still rave about barracudas. Shrug,
    whatever, I'll combat such stupidity at current $ORK first before
    worrying about that.

    >
    >>So although theoretically one could device a multiport 10/100 bridge
    >>that is not a switch, it seems that in practice most (all?) models are
    >>implemented as two collision domains connected by a switch/bridge (and
    >>some magic to connect the correct port to the correct collision domain).
    >>Which means they are HDX by definition on either collision domain.

    >
    > How do you get "in practice most" from that wireshark.org article? I


    From all the above, not just that article.

    > would agree with "some at one time" and perhaps even "many long ago,"
    > but not "most today" without some marketshare numbers. That $30 8-port


    For starters, empirical evidence. How many 10/100 hubs did you see in the
    past year? How many of those were not two collision domains switched/
    bridges together? (Yes I looked up several 10/100 hubs I have handy here
    on Google (and no, these are not all soho hubs, in fact most aren't)).

    Then there is the evidence by searching Google for 10/100 hubs.

    Lastly, searching Google seems to imply that these kind of 10/100 hubs
    were the cheapest to make at the time these devices were popular, which
    ties in with all the other evidence.

    No, not statistical evidence. Yet my initial question is mostly answered
    by now.

    > Cisco box at my elbow would keep me from agreeing with "all" regardless.


    Which Cisco box? That Linksys switch which is only labeled hub, but
    really is a switch?

    >>It probably would be theoretically possible to "speak" full duplex
    >>between a host on the 10Mb segment and one on the 100 Mb segment.
    >>However, all devices I looked at did autosensing, not autonegotiation,
    >>so only implement HDX.

    >
    > What if you look at boxes that do autonegotiation? What if you look at
    > boxes that have not been end-of-lifed?


    Do you have any examples of that? I could not find any. Note the context,
    two collision domains that are bridged/switched.

    > Section 8.6.1 assumes a sped of light of 0.77 c and a maximum end-to-end
    > propagation deay of 2570 ns. So a round trip is 5.14 microseconds or
    > about what you'd expect with a slot time of 512 bits and the frame
    > preamble. Figure 8-10 shows a "Maximum Transmission Path" involving 5
    > segments of coax, each presumably the maximum of 500 meters given in
    > section 8.6.1. That's a total of 2500 meters.


    Raagh, Martijn think before you type. 500 meter times 4 repeaters is
    indeed 2500 meters, not 2000. Thanks for the correction.

    >
    >>> other. At 100 MHz, the size of a collision domain shrinks to 50
    >>> meters.

    >>
    >>100base-T has a maximum segment length of 100 meters, and I think a
    >>maximum collision domain of 500 meters.

    >
    > We're both wrong. At 10 times the bit rate, the slot time has 10% as
    > many microseconds, and so the speed of light limits a 100 MHz collision
    > domain to 250 meters.


    Check. Should have figured that out myself.

    >
    >
    >>> That shrink to such a physically tiny network is why everyone was
    >>> willing to pay the costs of having 100 MHz hubs be vastly more complex
    >>> multi-port bridges that could be full duplex (FDX) instead classic

    >>
    >>You lost me here. You are talking about switches, not?

    >
    > Again, "switch" is old market-speak for "you must buy my fast multi-port
    > bridge."


    So all multi-port bridges are switches? What is wrong with the term
    switch? I don't think it's marketoid speak. It's a classification of a
    certain category of devices which can be bridges (bridging between
    dissimilar media), but don't have to be. The main characteristic of
    switches is that they forward frames only to the intended destination
    instead of to all ports when the port the destination is on is known.

    I'ld be interested to know why you dislike the term switch. The fact that
    marketroids have labeled devices as switches that really aren't, does not
    take away the well established technical meaning of the word switch.
    Which is different from the technical meaning of the word bridge. And
    yes, those two overlap.

    M4

  11. Re: Low Cost Hub With Read-Only Ports?

    On May 31, 3:40 am, Martijn Lievaart wrote:
    > No, I don't agree. Most 10/100 hubs are two hubs with a two port switch
    > or bridge between them (is there a difference between a switch and a
    > bridge when there are only two ports?). That is not what I would call a
    > multiport bridge in the technical sense, even if you can call it a
    > bridge. Just not a multiport bridge.
    >
    > A true multiport bridge bridges between all ports, so a 10/100 switch is
    > a multiport bridge.



    The distinction you're making between simple and multi-port bridges is
    artificial and meaningless. Ignoring some prehistoric stuff that does
    not implement 802.1 spanning tree, bridges are bridges, no matter how
    many ports they have.


    > What is bogus about the term switch? It's pretty well defined I think.
    > Depending on your definition of bridge (which is much less well defined
    > in my eyes) a switch can be a bridge, but doesn't have to be.
    >
    > But even if you define bridge in such a way that all switches are
    > bridges, the term switch defines a certain subset of bridges. See below.



    Sorry, bridge is the well defined term, switch is the invented
    marketing term.

    Again except for some oddball and ignorable junk, a layer 2 switch is
    a bridge. It's defined as such. It implements the MAC layer bridging
    protocols. There are no standards for "switches" (but plenty for
    bridges). In fact there are a dozen or so standardization/definition
    efforts for new *bridge* functionality *currently* underway under the
    auspices of 802.1. You can attach a brand new switch to a 15 year old
    bridge, and they'll both happily negotiate a spanning tree for packet
    forwarding (modulo bugs, of course).

    A marginally distinguishing feature of *some* switches has been cut-
    through forwarding, which arguably doesn't change their function at
    all, except to reduce latency in some cases, and increase the
    propagation of bad frames a bit.

    And I added the layer 2 prefix just because some people have sold
    "layer 3" switches, which oddly enough implement routing protocols
    like OSPF, and interoperate transparently with bog standard routers.
    At the height of the marketing craze for the term "switch" people were
    selling "application layer switches." (!!) Some of these did things
    like forward email (IOW they were mail servers).

    If there's a distinguishing characteristic of switches, it's perhaps
    that they're more-or-less intended to have one bridge port be attached
    device. That's at best an intention, I have never seen a switch that
    wouldn't let you hang an ordinary hub ("repeater") off a port and
    attach multiple device that way.

    The full duplex issue doesn't impact the definitions either. FDX is
    simply not supported on shared media links, which means that it only
    works between two full MAC devices. That can be a pair of FDX capable
    NICs in two computers (with a crossover cable), or an appropriately
    constructed bridge/switch port attached to a NIC or another switch/
    bridge port.

    And of course hubs/repeaters are no longer possible with GigE.

    The low-end 10/100 hubs/switches were indeed built with a 10Mb and a
    100Mb hub with a bridge between them. The autosensing ones could
    actually switch a port from one hub to the other. I even came across
    some that didn't implement spanning tree and just blindly forwarded
    unrecognized packets between the two sides.



  12. Re: Low Cost Hub With Read-Only Ports?

    On Thu, 31 May 2007 02:34:12 -0700, robertwessel2@yahoo.com wrote:

    > On May 31, 3:40 am, Martijn Lievaart wrote:
    >> No, I don't agree. Most 10/100 hubs are two hubs with a two port switch
    >> or bridge between them (is there a difference between a switch and a
    >> bridge when there are only two ports?). That is not what I would call a
    >> multiport bridge in the technical sense, even if you can call it a
    >> bridge. Just not a multiport bridge.
    >>
    >> A true multiport bridge bridges between all ports, so a 10/100 switch
    >> is a multiport bridge.

    >
    >
    > The distinction you're making between simple and multi-port bridges is
    > artificial and meaningless. Ignoring some prehistoric stuff that does


    Agreed.

    > not implement 802.1 spanning tree, bridges are bridges, no matter how
    > many ports they have.


    I don't agree with this.
    - Some bridges don't implement 802.1D (bridging VPNs f.i) which are
    certainly not prehistoric.
    - A bridge does not have to implement 802.1D to be called a bridge. It's
    simply not a 802.1D conforming bridge (see Std 802.1D-2004 chapter 5).

    But more to the point. Does a 10/100 hub that bridges together two
    collision domains really implement spanning tree? It's possible, but
    somehow I doubt this.

    >> What is bogus about the term switch? It's pretty well defined I think.
    >> Depending on your definition of bridge (which is much less well defined
    >> in my eyes) a switch can be a bridge, but doesn't have to be.
    >>
    >> But even if you define bridge in such a way that all switches are
    >> bridges, the term switch defines a certain subset of bridges. See
    >> below.

    >
    >
    > Sorry, bridge is the well defined term, switch is the invented marketing
    > term.


    Not in my book. A switch is jargon, not marketing speak. Also, bridge is
    not well defined. A 802.1D conforming bridge is well defined, but others
    exist.

    Point in case are those 10/100 hubs. How many claim conformance with
    802.1D? (Apart from stackable models, which normally do talk 802.1D, as
    they should). A short Google search turned up zilch, but maybe I didn't
    search hard enough.

    >
    > Again except for some oddball and ignorable junk, a layer 2 switch is a
    > bridge. It's defined as such. It implements the MAC layer bridging


    Agreed.

    (snip)

    > And I added the layer 2 prefix just because some people have sold "layer
    > 3" switches, which oddly enough implement routing protocols like OSPF,
    > and interoperate transparently with bog standard routers. At the height


    A layer 3 switch is a marketing term, agreed. However, Cisco Layer 3
    switches are pretty well defined and do have advantages. These are
    routers and switches (oops, bridges) at the same time where layer 3
    functionality is partly implemented in hardware, giving a noticeable
    speed increase.

    And of course that talks OSPF. It's a router as well as a switch. All
    this is well documented by Cisco. It's a certain implementation of the
    802.whatever and other standards.

    I'm not aware of other brands. If they have something similar it will be
    labeled something similar I expect. This is one case where I really don't
    object to marketing speak. It's easier to speak of a layer-3 switch then
    to talk about a "brouter with routing capabilities in hardware". Apart
    from the marketing value of both terms, in my eyes (but I work mostly in
    Cisco centric environments) a layer-3 switch is just a jargon term for
    the latter definition.

    Not withstanding that, I don't doubt there were at one time devices sold
    as "layer-3" switches which did not conform to the above and probably
    just did all kind of crazy thing creating all kinds of breakage. Having
    standards rigidly defining terms does have advantages. (Although, leave
    it to the marketroids to completely ignore that.)

    > of the marketing craze for the term "switch" people were selling
    > "application layer switches." (!!) Some of these did things like
    > forward email (IOW they were mail servers).


    Marketroids are crazy. Many so-called engineers also don't care for
    accuracy[1].

    I can imagine a layer 7 switch. Something that senses the protocol coming
    in on a tcp session and connects that to the correct backend application.
    If at all possible -- I think it can be done with severe limitations --
    this could be very handy for people with only one IPA on the Internet.

    In fact, that would probably be a good name to describe such a
    contraption. But I'll also settle for any other.

    >
    > If there's a distinguishing characteristic of switches, it's perhaps
    > that they're more-or-less intended to have one bridge port be attached
    > device. That's at best an intention, I have never seen a switch that
    > wouldn't let you hang an ordinary hub ("repeater") off a port and attach
    > multiple device that way.


    As I learned it, many years ago, a bridge is something which bridges
    between, probably dissimilar, media (OK define bridging, I'll leave that
    up to the interested reader). That, at that time, common definition has
    probably changed some. Nowadays, it is often used for anything that
    connects stuff on layer 2. A switch was something that did intelligent
    layer-2 frame forwarding. That definition has not changed.

    These are not terms defined by standards, but were/are the common usage
    and were taught as such in all networking classes.

    It is not surprising that some of these bridges needed standardization.
    Early tokenring to ethernet bridges could not agree on the order of the
    bits in the MAC field and would not interoperate. (In hindsight, there is
    a correct and an incorrect interpretation, but such was not so clearcut
    then.) Let alone all other problems like framesizes and timing problems.

    It's not surprising that only bridges between compatible media survived
    AND where standardized. Everything else was so troublesome, it deserved
    to die, and it did.

    But the term switch is jargon and pretty well defined. Take for instance
    a SAN-fiber switch. (By now also pretty well defined by standards. I only
    know such standards exist, I've never read them, so I don't know if these
    standards speak about switches.) These devices are, at least commonly,
    called switches because they forward frames in an intelligent way.

    > The full duplex issue doesn't impact the definitions either. FDX is
    > simply not supported on shared media links, which means that it only
    > works between two full MAC devices. That can be a pair of FDX capable
    > NICs in two computers (with a crossover cable), or an appropriately
    > constructed bridge/switch port attached to a NIC or another switch/
    > bridge port.


    So you agree with me that a so called 10/100 hub cannot be FDX, ignoring
    those that are really bridges but marketed as hubs?

    >
    > And of course hubs/repeaters are no longer possible with GigE.
    >
    > The low-end 10/100 hubs/switches were indeed built with a 10Mb and a
    > 100Mb hub with a bridge between them. The autosensing ones could
    > actually switch a port from one hub to the other. I even came across


    Do you have examples of high end ones that do things differently (apart
    from those stackable models)? I still am finding my way around this and
    would like to be prepared if I ever encounter one of those. Which is
    pretty likely actually.

    > some that didn't implement spanning tree and just blindly forwarded
    > unrecognized packets between the two sides.


    I fail to see a problem with that. It would be nice if they did, but
    which 10/100 hub does claim compliance with 802.1D?

    Besides, who in his right mind creates layer-2 network loops over a hub
    like device? Oh, yes, never mind. :-)

    M4

    [1]

    Hell, 5 years ago I had the distinct displeasure of working with a new
    model switch/brouter from a certain company. This was not some
    experimental model, but their standard high-end switch. Turns out that
    beside all other bugs, it did not implement autonegotiation correctly. It
    simply did not work, you had to fix both ends to make it work. I cannot
    imagine that the engineers did not know this, but the model was sold
    anyhow, claiming it did work.

    Which reminds me of another "switch" they had running. It had a
    staggering price tag, somewhere around a few 100K. That one did
    firewalling in hardware at gigabyte speeds, which was pretty impressive
    when it first came out. Well, sort of. As long as it was TCP. Everything
    else was just passed along. And as long as there were not to many
    connections. And to top it of, it's controller ran on NT4, although I
    admittedly never saw that crash.

  13. Re: Low Cost Hub With Read-Only Ports?

    In article ,
    Martijn Lievaart wrote:

    >- Some bridges don't implement 802.1D (bridging VPNs f.i) which are
    >certainly not prehistoric.


    My recollections suggest that the first "switches" predated 802.1D.
    That is cosistent with the 1993 date in
    http://www.ieee802.org/1/pages/802.1D.html
    and the 1990 date in
    http://en.wikipedia.org/wiki/Kalpana_(company)


    >As I learned it, many years ago, a bridge is something which bridges


    I suspect your "many years ago" is what seems to me like just
    yesterday and and that you are trying to correct my first hand
    recollections of preceding eras that I consider "not very long ago."


    Vernon Schryver vjs@rhyolite.com

  14. Re: Low Cost Hub With Read-Only Ports?

    On Thu, 31 May 2007 15:18:37 +0000, Vernon Schryver wrote:

    >>As I learned it, many years ago, a bridge is something which bridges

    >
    > I suspect your "many years ago" is what seems to me like just yesterday
    > and and that you are trying to correct my first hand recollections of
    > preceding eras that I consider "not very long ago."


    Grin! I'm talking over twenty years ago, but I'll hand you that most of
    my practical networking experience is in the last decade. So you may be
    correct on this one.

    M4

  15. Re: Low Cost Hub With Read-Only Ports?

    On May 31, 7:20 am, Martijn Lievaart wrote:
    > But the term switch is jargon and pretty well defined. Take for instance
    > a SAN-fiber switch. (By now also pretty well defined by standards. I only
    > know such standards exist, I've never read them, so I don't know if these
    > standards speak about switches.) These devices are, at least commonly,
    > called switches because they forward frames in an intelligent way.



    Most SAN switches are closer to (virtual) circuit switching devices
    than they are packet forwarding devices that we see in most
    networking. The term "switch" for that sort of device has a very long
    history, both in the telecoms area and I/O area. You would never, for
    example, refer to an ATM switch as a bridge. FC does blur that
    distinction somewhat, but communications between endpoints on an FC
    SAN are still based on long lived circuits (virtual or otherwise).

    And while you can run IP over a FC SAN, you're end up treating the SAN
    more like a collection of fairly flexible (end)point-to-(end)point
    links, more like ATM without LANE rather than a shared media link like
    Ethernet.




  16. Re: Low Cost Hub With Read-Only Ports?

    On Thu, 31 May 2007 16:47:13 -0700, robertwessel2@yahoo.com wrote:

    > On May 31, 7:20 am, Martijn Lievaart wrote:
    >> But the term switch is jargon and pretty well defined. Take for
    >> instance a SAN-fiber switch. (By now also pretty well defined by
    >> standards. I only know such standards exist, I've never read them, so I
    >> don't know if these standards speak about switches.) These devices are,
    >> at least commonly, called switches because they forward frames in an
    >> intelligent way.

    >
    >
    > Most SAN switches are closer to (virtual) circuit switching devices than
    > they are packet forwarding devices that we see in most networking. The
    > term "switch" for that sort of device has a very long history, both in
    > the telecoms area and I/O area. You would never, for example, refer to
    > an ATM switch as a bridge. FC does blur that distinction somewhat, but
    > communications between endpoints on an FC SAN are still based on long
    > lived circuits (virtual or otherwise).
    >
    > And while you can run IP over a FC SAN, you're end up treating the SAN
    > more like a collection of fairly flexible (end)point-to-(end)point
    > links, more like ATM without LANE rather than a shared media link like
    > Ethernet.


    Yes, I see the light now. I understand why you and Vernon take objection
    to the term Ethernet switch, and I agree.

    Thanks, I learned a lot!
    M4

  17. Re: Low Cost Hub With Read-Only Ports?

    On Thu, 31 May 2007 22:02:11 +0000, Vernon Schryver wrote:

    > Of course "switch" is an ancient word. You don't talk about "cross-bar
    > bridges," "central office bridges," or "Strowger bridges." None of that
    > changes what I think is the fact that "switch" was first applied to
    > boxes connecting local area computer networks by Kalpana to distinguish
    > their fast multi-port 10 MHz 802.3 CSMA/CD bridges.


    See my reply to Robert, you are correct.

    >>This may be true. It may very well be the case that my classes focused
    >>on dissimilar media because that is where the interesting problems were
    >>to be found. Yet token-ring to Ethernet bridges did exist and others did
    >>also exist.

    >
    > Are you claiming that that TR-Ethernet bridges existed before
    > Ethernet-Ethernet bridges? Perhaps that is true, but I think not. For


    No, I'm not.

    > most of the history of IBM token ring networks, they mixed with Ethernet
    > about as well as COBOL and Fortran. People would use one or the other


    Actually COBOL and Fortran mixed quite well in most environments,
    although there was no standard way to do it. It's a 15 years ago I last
    did this, so maybe it is standardized by now, who knows.

    > but not both. People who bought IBM Token Ring gear heard the endless
    > lies of IBM salescritters about Ethernet performance and so were
    > innoculated against using Ethernets. People who bought Ethernets either


    Absolutely. And it was partly true as well, it just conveniently ignored
    the problems of token-ring. Especially token loss, which did occur, so
    I'm told.

    > had no opportunity for experience with IBM hardware, software, or sales
    > force, or they heard enough of the IBM salescritter lies about CSMA/CD
    > to be innoculated against using IBM Token Rings. (The IBM salescritter
    > lie about CSMA/CD was that Ethernet performance is limited to about 60%
    > of wire speed by the nature of the protocol and supposedly worse, was
    > something they misleadingly labeled "non-deterministic.")


    It's not only token-ring. The same was used to sell token-bus. Now there
    is a technology that was fairly often used in those days (in hardware
    automation). Is it still used today?

    >
    > Were your classes taught in American English by a native English speaker
    > or in Dutch? If in Dutch, might people have tried to make sense of the
    > Boston and San Francisco Bay Area jargon when they translated it into
    > Dutch? I agree that if you ignore history, "switch" fits better than
    > "bridge." That's probably much of why everything is now sold as a
    > "switch" and nothing is sold as a "bridge."


    Dutch jargon just uses the English terms for the most part. Around that
    same time there was a movement to use dutch words, but those words were
    often horrible, inaccurate and had no value to offer over the English
    terms.

    The same is true today. We still talk about a floppy disk, instead of a
    fladderschijf. A computer is a computer in Dutch, while the Germans
    (also) use Rechner and the french use ordinateur.

    Some things are translated, a network card is a netwerk kaart. But
    bridges, switches, congestion, duplex and all other network terms remain
    in English.

    Dutch ICT people in general speak a fair amount of English and although
    those particular classes were thought in Dutch, they might just as well
    have been thought in English.

    >>I've yet to see evidence that, although there is a large overlap,
    >>especially when talking about Ethernet, and notwithstanding marketroid
    >>blather, these really are the same.

    >
    > Did you follow the URLs I offered? All of the relevant hits of
    > http://www.google.com/search?q=bridge+switch+network either say things
    > like
    > Switches are the same thing as Bridges, but usually have multiple
    > ports with the same "flavor" connection
    > or try distinguish their super duper wonderful fast cheap chrome plated
    > "switches" from everyone else's "bridges."


    So? The fact that most bridges are switches leads to a lot of hits. I
    recently dismanteled an Ethernet bridge between two 100Mb Ethernet
    segments. The fact that this device was actually sold as a bridge, not a
    switch should tell you something.

    If only it had been a switch! (As in a 802.1D compliant bridge). I cannot
    get the details now of this horrible contraption, but getting rid of it
    sure made all the difference in performance and user experience.

    (Although that network was such a mess that we cleaned up a lot more and
    I cannot claim that that bridge was the only problem. It's now a nicely
    switched (oops, 802.1D bridged) only network with VLANs getting the
    departments out of each others hair. It now works perfectly getting a lot
    of managers of our backs. Managers that were responsible for that mess in
    the first place!)

    >
    >
    >> Also note that you're opinion
    >> differs
    >>from Roberts here.

    >
    > Not that I noticed.


    Sorry, upon rereading I mostly agree with you.

    >
    >>I especially find it difficult to accept that you claim that the term
    >>switch was invented by marketroids and does not have a well defined
    >>meaning, yet you are now claiming they are one and the same.

    >
    > As I said:
    >
    > ] You can't have it both ways. Either you do as I suggested long ago in
    > ] this thread and accept the words and definitions that most consumers ]
    > understand or you are punctilious about the words and meanings.
    >
    > Either go along with almost all consumers and trade rag experts and
    > accept the unintended results of the efforts of the marketoons or be
    > picky. Either use "switch" for "multi-port bridge" and a lot of other
    > things including IP routers or stick to using "bridge."


    I still maintain that there are other bridges than 802.1D compliant
    bridges. I recently encountered one. An Ethernet switch, whoever invented
    that term, is a 802.1D compliant switch (according to Robert there is no
    difference between a two port and a multiport bridge. Now what would be
    the use of a single port bridge? :-)

    And I would never use the term switch to mean a router, except for
    layer-3 switches where the term really does have some meaning. Yes, it is
    realy just a fast brouter (or is it? or is it just a combined switch
    router, not in the way brouter is supposed to be used? I'm not sure),
    however the term has meaning now. A marketroid/salesscritter meaning
    maybe, but a meaning non the less.

    I do give you that the term is mostly wrongly used. We have a couple of
    routers on locations which are Cisco 37XXs. (Whoever thought we needed a
    layer-3 switch was on drugs, there is virtually no inter-segment traffic,
    the only traffic goes to a leased line, which is 2Mb at most. Almost any
    routing device would have sufficed).

    As this is a layer-3 switch many colleagues refer to it as a switch. No
    dammit, it's a router! Although the term layer-3 switch does add meaning,
    the marketroids where very good at instilling into people that it is
    something different than a router. Well OK, it is, it's a brouter. OK, it
    does bridge traffic. However, in this situation that is not the point, we
    could just as well have added another switch to every segment. People
    don't realize the difference, resulting in endless confusion.

    So i'll stick to using bridge for anything that bridges traffic, even if
    it is not 802.1D compliant. I'll call an 802.1D compliant bridge a
    switch. I'll call a layer-3 switch a layer-3 switch in appropriate
    contexts, as in "router latency is killing this app[1], let's replace the
    router by a layer-3 switch". And I'll never call an email forwarder or a
    load balancer a switch.

    I think I'm pretty compliant with common usage if I do it that way.

    M4

    [1] Better to fix the app, however sadly that is often not an option.
    OracleForms 6.x comes to mind, try running an app written in OF6 over any
    network with latencies in milliseconds. Killing.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2