Low Cost Hub With Read-Only Ports?

Does anyone make a low cost four to eight port 10/100 hub that has a way to
designate one of the ports as "readonly"? I want to have a notebook act as
a sniffer behind an infected computer without exposing the notebook to any
attack. I've seen what true network TAPs cost, and it seems silly to
spend $600 to $2K for fairly trivial functionality like this. Portability
is a key requirement so having a smaller desktop hub that is also
programmable would be desirable. Any candidates?

--
Will

Re: Low Cost Hub With Read-Only Ports?

In article ,
Will wrote:
>Does anyone make a low cost four to eight port 10/100 hub that has a way to
>designate one of the ports as "readonly"? I want to have a notebook act as
>a sniffer behind an infected computer without exposing the notebook to any
>attack. I've seen what true network TAPs cost, and it seems silly to
>spend $600 to $2K for fairly trivial functionality like this. Portability
>is a key requirement so having a smaller desktop hub that is also
>programmable would be desirable. Any candidates?
>
>--
>Will


If you run your sniffer laptop from a CD-bootable OS (knoppix and many
others) if it *does* gete infected, a reboot will fix it.




--
a d y k e s @ p a n i x . c o m
Don't blame me. I voted for Gore. A Proud signature since 2001

Re: Low Cost Hub With Read-Only Ports?

Will wrote:

> Does anyone make a low cost four to eight port 10/100 hub that has a way to
> designate one of the ports as "readonly"?


Ehm... what about simply cutting one of the wires, trivially creating a
Rx-only ethernet cable?

Re: Low Cost Hub With Read-Only Ports?

"Sebastian G." wrote in message
news:5bkhv3F2tquhaU1@mid.dfncis.de...
> Will wrote:
>
>> Does anyone make a low cost four to eight port 10/100 hub that has a way
>> to designate one of the ports as "readonly"?
>
> Ehm... what about simply cutting one of the wires, trivially creating a
> Rx-only ethernet cable?

Clever idea...which wire do I cut, and perhaps some vendor sells such a
cable to avoid the hassle?

--
Will

Re: Low Cost Hub With Read-Only Ports?

Hello,

Sebastian G. a écrit :
> Will wrote:
>
>> Does anyone make a low cost four to eight port 10/100 hub that has a
>> way to designate one of the ports as "readonly"?
>
> Ehm... what about simply cutting one of the wires, trivially creating a
> Rx-only ethernet cable?

I guess you mean one of the pairs.
Wouldn't it break the link beat detection and speed auto-negotiation ?

Re: Low Cost Hub With Read-Only Ports?

"Sebastian G." writes:

>Will wrote:

>> Does anyone make a low cost four to eight port 10/100 hub that has a way to
>> designate one of the ports as "readonly"?


>Ehm... what about simply cutting one of the wires, trivially creating a
>Rx-only ethernet cable?

I don't think that works nicely except if the Hub doesn't do link detection
and neither does your laptop.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Re: Low Cost Hub With Read-Only Ports?

Will wrote:


>> Ehm... what about simply cutting one of the wires, trivially creating a
>> Rx-only ethernet cable?
>
> Clever idea...which wire do I cut, and perhaps some vendor sells such a
> cable to avoid the hassle?

http://en.wikipedia.org/wiki/Ethernet_cable#Ethernet_over_tw isted-pair_cable

Dunno if a vendor sells it, in any large companies the admins do all the
cabling themselves.

Re: Low Cost Hub With Read-Only Ports?

Pascal Hambourg wrote:


>> Ehm... what about simply cutting one of the wires, trivially creating a
>> Rx-only ethernet cable?
>
> I guess you mean one of the pairs.
> Wouldn't it break the link beat detection and speed auto-negotiation ?


Sure it does.

Re: Low Cost Hub With Read-Only Ports?

Casper H.S. Dik wrote:


>> Ehm... what about simply cutting one of the wires, trivially creating a
>> Rx-only ethernet cable?
>
> I don't think that works nicely except if the Hub doesn't do link detection
> and neither does your laptop.

If your setup doesn't require it, the failure of link detection won't break
anything. The only real problem is the OS, thus you have to deactivate DHCP
media sensing (e.g. the OS reports a non-existent network connection through
the DHCP negoiation state in the TCP/IP stack and then invalidates the
routes) and setup the routing table manually.

Re: Low Cost Hub With Read-Only Ports?

In article <5blstoF2tq84fU1@mid.dfncis.de>,
Sebastian G. wrote:

>>> Ehm... what about simply cutting one of the wires, trivially creating a
>>> Rx-only ethernet cable?
>>
>> Clever idea...which wire do I cut, and perhaps some vendor sells such a
>> cable to avoid the hassle?
>
>http://en.wikipedia.org/wiki/Ethernet_cable#Ethernet_over_t wisted-pair_cable

Perhaps the point of that URL is to suggest doing what seems obvious
to me. That is to buy a jumper cable at a local retail store, strip
the out jacket, and cut one wire of the right pair. Or buy several
cables, and cut different wires in each.

But as others have said, the result is unlikely to work. One reason
is that modern Ethernet hardware tends to want to chatter in both
directions before passing packets.

Another problem is that many boxes now sold as "Ethernet hubs" are
really learning bridges instead of Ethernet repeaters and so do not
forward all packets to all ports. They must be bridges instead of
repeaters if they are "10/100" hubs or able to connect 10 MHz hosts to
100 MHz hosts. If they are cheap, they lack the knobs and switches to
configure a port to receive all packets, and so no port will see all
packets.


>Dunno if a vendor sells it, in any large companies the admins do all the
>cabling themselves.

On the contrary, that it seems that everyone has the tools and parts
needed to build a few cables does not imply that they are used except
in special cases. In many large U.S. companies, contractors do most
"cable pulling," and jumpers and other impermanent cables are built by
outsider vendors. It's too expensive to build your own short cables,
unless you are getting Third World wages.


Vernon Schryver vjs@rhyolite.com

Re: Low Cost Hub With Read-Only Ports?

Vernon Schryver wrote:


> But as others have said, the result is unlikely to work.


Well, they do work quite well. Not to mention that this is the preferred
setup for master-slave keep-alive communication for redundant firewalls on
OpenBSD.

> One reason is that modern Ethernet hardware tends to want to chatter in both
> directions before passing packets.


and doesn't break if it can't do so.

> Another problem is that many boxes now sold as "Ethernet hubs" are
> really learning bridges instead of Ethernet repeaters and so do not
> forward all packets to all ports. They must be bridges instead of
> repeaters if they are "10/100" hubs or able to connect 10 MHz hosts to
> 100 MHz hosts. If they are cheap, they lack the knobs and switches to
> configure a port to receive all packets, and so no port will see all
> packets.


Then you have to add some MAC flooding. This is exactly why I prefer some
good old classical that you can put in between the line.

> In many large U.S. companies, contractors do most
> "cable pulling," and jumpers and other impermanent cables are built by
> outsider vendors. It's too expensive to build your own short cables,
> unless you are getting Third World wages.


What do you think these vendors are doing? Right: Ethernet cable is so damn
cheap, it's like a natural resource for them. You just pull of some 100
meters, cut them as required, add the plugs and there you go.

Re: Low Cost Hub With Read-Only Ports?

In article <5blur5F2tj148U1@mid.dfncis.de>,
Sebastian G. wrote:

>> But as others have said, the result is unlikely to work.
>
>Well, they do work quite well.

Let's wait to see if the other person can make them work. That people
who know about such things can make them work does not imply that they
are likely to work for people with less experience.


> Not to mention that this is the preferred
>setup for master-slave keep-alive communication for redundant firewalls on
>OpenBSD.

I'm sure that's all very nice, although I don't understand why one would
use Ethernet cables with one pair cut with redundant firewalls.

It is somewhat surprising to see mention of a UNIX-like operating system
from someone who elsewhere seems to think that DHCP is part of the the
"OS" and the "TCP stack" and talks about Microsoft's registry switches
that control whether the system should pay attention to Ethernet carrier
sense. In the UNIX world, DHCP is just another application, albeit one
that hammers on network interfaces. BSD style network interfaces or
drivers decide whether to pay attention to carrier, including transmitting
when there is none--that is, if the MAC chip doesn't decide the issue
itself.


>> One reason is that modern Ethernet hardware tends to want to chatter in both
>> directions before passing packets.
>
>and doesn't break if it can't do so.

"Doesn't necessarily break" and "works in some cases" are not the
same as "doesn't break." The problem is not only in the host but
also in the hub. What does your cheap hub do when it sees no carrier
on either pair? What if it is smart enough to automagically switch
the TX and RX pairs in all sockets instead of having a single extra
"uplink" socket, as is now common?

Another trouble is that HDX Ethernet is CSMA/CD. The hub cannot
do much carrier sensing (CD) if its RX pair (or the host's TX pair)
is cut.


>> Another problem is that many boxes now sold as "Ethernet hubs" are
>> really learning bridges instead of Ethernet repeaters and so do not
>> forward all packets to all ports.

>Then you have to add some MAC flooding. This is exactly why I prefer some
>good old classical that you can put in between the line.

How does one "add some MAC flooding" on a cheap hub with no management
facilities? Cheap hubs do whatever they are wired to do at the factory.
The only controls you have on them are in how you choose to connect
them to cables (including power).
As I wrote, whatever the other person finds today as a "cheap hub" is
likely to be 10/100 bridge, and so likely to be a pain for passive
packet snooping.


>> In many large U.S. companies, contractors do most
>> "cable pulling," and jumpers and other impermanent cables are built by
>> outsider vendors. It's too expensive to build your own short cables,
>> unless you are getting Third World wages.
>
>What do you think these vendors are doing? Right: Ethernet cable is so damn
>cheap, it's like a natural resource for them. You just pull of some 100
>meters, cut them as required, add the plugs and there you go.

Yes, and that cutting and plug crimping is part of the job of "cable
pulling" done by outside contractors. I'm sure that there are large
companies that do it all themselves, but I _know_ that many large
companies outsource cable pulling and buy tons of pre-built cables
in lengths ranging from short jumpers to 100 meters.


Vernon Schryver vjs@rhyolite.com

Re: Low Cost Hub With Read-Only Ports?

Vernon Schryver wrote:


>> Not to mention that this is the preferred
>> setup for master-slave keep-alive communication for redundant firewalls on
>> OpenBSD.
>
> I'm sure that's all very nice, although I don't understand why one would
> use Ethernet cables with one pair cut with redundant firewalls.


It's about a master firewall server continually advertising its presence to
a slave server without the latter being able to accidentially invoke any
malicious behaviour on the master server. State table changes are usually
transferred on a second line, which also can be Rx-only and made Rx+Tx on
demand (when a master server has to recover the state table from the slave
server).

> It is somewhat surprising to see mention of a UNIX-like operating system
> from someone who elsewhere seems to think that DHCP is part of the the
> "OS" and the "TCP stack"


Why that?

> and talks about Microsoft's registry switches
> that control whether the system should pay attention to Ethernet carrier
> sense.


Nonsense. DHCP media sensing is a well-known mechanism/protocol that exists
on Unix as well.

> BSD style network interfaces or drivers decide whether to pay attention

> to carrier, including transmitting when there is none--that is, if the
> MAC chip doesn't decide the issue itself.

And the network drivers signal such issues to which component? Exactly the
TCP/IP stack. DHCP media sensing just is a portable way for how the TCP/IP
forwards these signals to the application (e.g. by intentionally creating a
DHCP message from a non-existent DHCP server).

>>> One reason is that modern Ethernet hardware tends to want to chatter in both
>>> directions before passing packets.
>> and doesn't break if it can't do so.
>
> "Doesn't necessarily break" and "works in some cases" are not the
> same as "doesn't break."


No, totally wrong. The sensing is supposed to "fix" problems that don't
occur on a correct setup. Use the right cabling? No need to negotiate Rx/Tx
wries. Manually setup the right speed? No speed negotiation needed.

> The problem is not only in the host but
> also in the hub. What does your cheap hub do when it sees no carrier
> on either pair? What if it is smart enough to automagically switch
> the TX and RX pairs in all sockets instead of having a single extra
> "uplink" socket, as is now common?


And as this fails as well, it bogs down to leaving it like it is.
And yes, my cheap hub doesn't try any such stupid stuff. That's exactly why
it works so well.

> Another trouble is that HDX Ethernet is CSMA/CD. The hub cannot
> do much carrier sensing (CD) if its RX pair (or the host's TX pair)
> is cut.


That's not even a problem, that's an intended feature.

>>> Another problem is that many boxes now sold as "Ethernet hubs" are
>>> really learning bridges instead of Ethernet repeaters and so do not
>>> forward all packets to all ports.
>
>> Then you have to add some MAC flooding. This is exactly why I prefer some
>> good old classical that you can put in between the line.
>
> How does one "add some MAC flooding" on a cheap hub with no management
> facilities?


Simply attach another computer that does the flooding. It could even be the
compromised machine itself, since the sniffer can verify the existence of a
stream of bogus ARP requests.

Re: Low Cost Hub With Read-Only Ports?

In article , vjs@calcite.rhyolite.com (Vernon Schryver) writes:
| In article <5blstoF2tq84fU1@mid.dfncis.de>,
| Sebastian G. wrote:
|
| >>> Ehm... what about simply cutting one of the wires, trivially creating a
| >>> Rx-only ethernet cable?
| >>
| >> Clever idea...which wire do I cut, and perhaps some vendor sells such a
| >> cable to avoid the hassle?
| >
| >http://en.wikipedia.org/wiki/Ethernet_cable#Ethernet_over_t wisted-pair_cable
|
| Perhaps the point of that URL is to suggest doing what seems obvious
| to me. That is to buy a jumper cable at a local retail store, strip
| the out jacket, and cut one wire of the right pair. Or buy several
| cables, and cut different wires in each.
|
| But as others have said, the result is unlikely to work. One reason
| is that modern Ethernet hardware tends to want to chatter in both
| directions before passing packets.

If necessary you can always use another cheap hub to supply link pulses
to the TX pair. That is, don't just cut a pair; split it out to a separate
plug. It might be best to disable auto-negotiation, though that probably
requires something more than a cheap hub...

Dan Lanciani
ddl@danlan.*com

Re: Low Cost Hub With Read-Only Ports?

In article <5bman7F2stdchU1@mid.dfncis.de>,
Sebastian G. wrote:

>It's about a master firewall server continually advertising its presence to
>a slave server without the latter being able to accidentially invoke any
>malicious behaviour on the master server. State table changes are usually
>transferred on a second line, which also can be Rx-only and made Rx+Tx on
>demand (when a master server has to recover the state table from the slave
>server).

"Rx-only and made Rx+Tx on demand" is nonsense in this context.
You cannot un-cut a wire "on demand," and so that stuff cannot be
using Ethernet cables with one pair cut as proposed in this thread.
Turning off Ethernet input or output or output in software does not
meet the other person's design goal of a permanent, unalterable
block on one direction.

Personally, I don't think much of the goal. If you can't trust your
host software to honor your command to be passive while snooping on an
Ethernet, then I don't think you can trust its monitoring.


>> and talks about Microsoft's registry switches
>> that control whether the system should pay attention to Ethernet carrier
>> sense.
>
>Nonsense. DHCP media sensing is a well-known mechanism/protocol that exists
>on Unix as well.

Where among the DHCP RFCs or elsewhere is that protocol documented?

Micrsooft's description at
http://support.microsoft.com/kb/239924
seems to say that it has nothing to do with DHCP except to trigger a
DHCP negotiation. That's consistent with RFC 3927.

Perhaps I should mention that I wrote the `routed` daemon that is
in a bunch of versions of UNIX-like systems including FreeBSD and
Solaris. It uses network interface state changes to trigger various
RIP, RIPv2, and router discovery protocol events. In at least some
drivers (e.g. those I've written), those IFF_RUNNING bit changes can
reflect Ethernet MAC carrier sense problems, persistent FDDI beaconing
or claiming, etc.
I guess a control on that mechanism might be called "RIP/RDISC media
sensing", but it would not be part of what I call a "TCP/IP stack."
I also doubt it would be a "well-known mechanism/protocol."



>> BSD style network interfaces or drivers decide whether to pay attention
>
> > to carrier, including transmitting when there is none--that is, if the
> > MAC chip doesn't decide the issue itself.
>
>And the network drivers signal such issues to which component? Exactly the
>TCP/IP stack.

That's not really right for my notion "TCP/IP stack." It does make sense
for how many Microsoft system administrators see TCP/IP based on old
WINSOCK libraries and other TCP/IP before before Windows NT.

> DHCP media sensing just is a portable way for how the TCP/IP
>forwards these signals to the application (e.g. by intentionally creating a
>DHCP message from a non-existent DHCP server).

It's not "portable" in a protocol sense unless your definition is
limited to what is said in Redmond as demonstrated by the lack of
hits for this URL:
http://www.google.com/search?q=dhcp+%22media+sense%22+site%3 Aisc.org


>>>> One reason is that modern Ethernet hardware tends to want to chatter in both
>>>> directions before passing packets.
>>> and doesn't break if it can't do so.
>>
>> "Doesn't necessarily break" and "works in some cases" are not the
>> same as "doesn't break."
>
>No, totally wrong. The sensing is supposed to "fix" problems that don't
>occur on a correct setup. Use the right cabling? No need to negotiate Rx/Tx
>wries. Manually setup the right speed? No speed negotiation needed.

That is an (cough) unusual description of Ethernet auto-sense.


>> The problem is not only in the host but
>> also in the hub. What does your cheap hub do when it sees no carrier
>> on either pair? What if it is smart enough to automagically switch
>> the TX and RX pairs in all sockets instead of having a single extra
>> "uplink" socket, as is now common?
>
>And as this fails as well, it bogs down to leaving it like it is.
>And yes, my cheap hub doesn't try any such stupid stuff. That's exactly why
>it works so well.

What is the "this" that "fails as well"?
What bogs down and what is left "like it is"?
Eactly what is working so well?
Are you saying that you use cat-5 or cat-6 cables with only one
working pair to monitor an Ethernet? If so what are the brand and
model of your cheap hub, and what host hardware and software
(e.g. laptop) do you use?


>> Another trouble is that HDX Ethernet is CSMA/CD. The hub cannot
>> do much carrier sensing (CD) if its RX pair (or the host's TX pair)
>> is cut.
>
>That's not even a problem, that's an intended feature.

Is that an odd way of saying that a single-pair Ethernet TP cable
will not work at all on an HDX hub?
If so, what does that imply for the other person's design goal?
If a cheap hub that cannot auto-negotiate FDX because one pair is cut
falls back to HDX, and if HDX transmissions from the hub to the laptop
do not work without sensing carrier, what does that tell us?

(To be honest, I don't recall if the IEEE standard says a CSMA/CD
twisted pair, HDX hub should stop transmitting on the TX pair if
it does not sense carrier on the RX pair, and I'm too lazy to drag
out my copy or some other book such as Rich Seifert's to check.)


>>> Then you have to add some MAC flooding. This is exactly why I prefer some
>>> good old classical that you can put in between the line.
>>
>> How does one "add some MAC flooding" on a cheap hub with no management
>> facilities?
>
>Simply attach another computer that does the flooding. It could even be the
>compromised machine itself, since the sniffer can verify the existence of a
>stream of bogus ARP requests.

Oh, I thought a different notion was intended by "MAC flooding."
Doesn't this notion require that the hub not defend against that
attack by shutting down the port? Granted, that might be less
likely in a cheap hub.


Vernon Schryver vjs@rhyolite.com

Re: Low Cost Hub With Read-Only Ports?

Vernon Schryver wrote:

> In article <5bman7F2stdchU1@mid.dfncis.de>,
> Sebastian G. wrote:
>
>> It's about a master firewall server continually advertising its presence to
>> a slave server without the latter being able to accidentially invoke any
>> malicious behaviour on the master server. State table changes are usually
>> transferred on a second line, which also can be Rx-only and made Rx+Tx on
>> demand (when a master server has to recover the state table from the slave
>> server).
>
> "Rx-only and made Rx+Tx on demand" is nonsense in this context.
> You cannot un-cut a wire "on demand," and so that stuff cannot be
> using Ethernet cables with one pair cut as proposed in this thread.


What about *replacing* the cable with another one? That's exactly the point.
You have replaced the defective master server, you exchange the cable with a
normal one, you have the master server recover its state from the slave
server, then you put the Rx-only cable back in place.

> Personally, I don't think much of the goal. If you can't trust your
> host software to honor your command to be passive while snooping on an
> Ethernet, then I don't think you can trust its monitoring.


So that's why they added an optional Rx-only patch to Linux... honestly,
this is not about trust, this is about reliability. Most systems simply are
not designed to fully deal with Rx-only network traffic, neither are easily
configurable in that way.

> It's not "portable" in a protocol sense unless your definition is
> limited to what is said in Redmond as demonstrated by the lack of
> hits for this URL:
> http://www.google.com/search?q=dhcp+%22media+sense%22+site%3 Aisc.org


WTF? As I already said, the implementation is a matter of the TCP/IP stack
of the operating system, and as you already mentioned there are multiple way
to trigger RIP or DHCP events.

Why exactly should ISC care?

(BTW, without a &safe=off&hl=en you might run into Google's censorship...)


>>> The problem is not only in the host but
>>> also in the hub. What does your cheap hub do when it sees no carrier
>>> on either pair? What if it is smart enough to automagically switch
>>> the TX and RX pairs in all sockets instead of having a single extra
>>> "uplink" socket, as is now common?
>> And as this fails as well, it bogs down to leaving it like it is.
>> And yes, my cheap hub doesn't try any such stupid stuff. That's exactly why
>> it works so well.
>
> What is the "this" that "fails as well"?


The negoitation with Tx and Rx switched. It it fails as well, the hub
assumes the normal order it has started the negotiation with.

> Are you saying that you use cat-5 or cat-6 cables with only one
> working pair to monitor an Ethernet?


Yes.

> If so what are the brand and model of your cheap hub,


Old no-name thing, model number seems to be HB-101. You know, very very old,
10TX-only and heating up very fast.

> and what host hardware and software (e.g. laptop) do you use?


FreeBSD and Wireshark. Now that's no mystery.

> If a cheap hub that cannot auto-negotiate FDX because one pair is cut
> falls back to HDX, and if HDX transmissions from the hub to the laptop
> do not work without sensing carrier, what does that tell us?


That you're wrong, it does work with HDX. Why shouldn't it? CSMA/CD doesn't
even get a share in this process.

> Oh, I thought a different notion was intended by "MAC flooding."
> Doesn't this notion require that the hub not defend against that
> attack by shutting down the port? Granted, that might be less
> likely in a cheap hub.

At any rate, what about simply placing a classical hub directly between the
other hub/switch/router/whatever and the machine?

Re: Low Cost Hub With Read-Only Ports?

In article <5bml2bF2t5vupU1@mid.dfncis.de>,
Sebastian G. wrote:

>> It's not "portable" in a protocol sense unless your definition is
>> limited to what is said in Redmond as demonstrated by the lack of
>> hits for this URL:
>> http://www.google.com/search?q=dhcp+%22media+sense%22+site%3 Aisc.org
>
>WTF? As I already said, the implementation is a matter of the TCP/IP stack
>of the operating system, and as you already mentioned there are multiple way
>to trigger RIP or DHCP events.
>
>Why exactly should ISC care?

Where is the primary place to look for documentation for the by far
most popular UNIX implementation of DHCP client and server?
If the documentation for dhcpd doesn't know about this "DHCP media sense
protocol," then it is probably neither very well known nor very portable.


>> Are you saying that you use cat-5 or cat-6 cables with only one
>> working pair to monitor an Ethernet?
>
>Yes.
>
>> If so what are the brand and model of your cheap hub,
>
>Old no-name thing, model number seems to be HB-101. You know, very very old,
>10TX-only and heating up very fast.
>
>> and what host hardware and software (e.g. laptop) do you use?
>
>FreeBSD and Wireshark. Now that's no mystery.

That simple report of personal experience, without the posturing
and efforts to show expertise that in fact suggested the opposite,
might do the other person some good. Ironically, it would also
have made the reporter appear more expert.

I doubt that report will do the other person any good for a bunch
of reasons. One is the modern difficulty of finding 10TX-only hubs.
(Yes, I have my own piles of junk old 10TX-only hubs, store-bought
cables, bulk cable, crimping tools, cat-5 RJ-45 plugs and sockets, old
computers with various Ethernnet interfaces including yellow hose, etc.
From the other person's questions, I doubt the availability of equivalent
resources there.)


>> If a cheap hub that cannot auto-negotiate FDX because one pair is cut
>> falls back to HDX, and if HDX transmissions from the hub to the laptop
>> do not work without sensing carrier, what does that tell us?
>
>That you're wrong, it does work with HDX. Why shouldn't it? CSMA/CD doesn't
>even get a share in this process.

Doesn't that depend on whether the hub demands carrier sense to transmit?
I agree that Dan Lanciani's suggestion of a Y cable and yet another
hub or just another port on the original hub to fake carrier should work.


>At any rate, what about simply placing a classical hub directly between the
>other hub/switch/router/whatever and the machine?

If the network to be monitored is running at more than about 9.8 Mbit/sec,
then the classical hub and host uisng 10BASE-T will miss packets.


Vernon Schryver vjs@rhyolite.com

Re: Low Cost Hub With Read-Only Ports?

On Thu, 24 May 2007 22:56:22 +0000, Vernon Schryver wrote:

> Is that an odd way of saying that a single-pair Ethernet TP cable will
> not work at all on an HDX hub?
> If so, what does that imply for the other person's design goal? If a
> cheap hub that cannot auto-negotiate FDX because one pair is cut falls
> back to HDX, and if HDX transmissions from the hub to the laptop do not
> work without sensing carrier, what does that tell us?

I thought all hubs where HDX by definition. Does something like a FDX hub
really exist?

A hub forwards a frame to all it's ports, except the one it is receiving
the frame on. What to do with a frame that comes in from one of those
other ports? It cannot send that to all the other ports as they are
already busy transmitting the original frame.

This can only work in the case of a store and forward architecture, but
that is also HDX by definition because of exactly the same problem, so
why bother?

Where do I go wrong in this picture? As you usually know what you're
talking about I assume I'm making a mistake somewhere here.

M4

Re: Low Cost Hub With Read-Only Ports?

Martijn Lievaart wrote:


> A hub forwards a frame to all it's ports, except the one it is receiving
> the frame on. What to do with a frame that comes in from one of those
> other ports? It cannot send that to all the other ports as they are
> already busy transmitting the original frame.


It can. It will create an interference, the frame gets corrupted, CSMA/CD
resolves the issue.

Re: Low Cost Hub With Read-Only Ports?

On Tue, 29 May 2007 14:13:11 +0200, Sebastian G. wrote:

> Martijn Lievaart wrote:
>
>
>> A hub forwards a frame to all it's ports, except the one it is
>> receiving the frame on. What to do with a frame that comes in from one
>> of those other ports? It cannot send that to all the other ports as
>> they are already busy transmitting the original frame.
>
>
> It can. It will create an interference, the frame gets corrupted,
> CSMA/CD resolves the issue.

That is not very useful is it? Besides, in practice that is HDX.

I'm not completely sure what happens then. On a coax cable someone will
send a jam signal, but on a hub?

If the intended receiver sends back a frame to the sender, and that
sender gets that frame FDX, while all other clients see a collision, and
that has no further consequences, yes, that might work. But somehow I
doubt if it really works that way. Someone who knows?

M4

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...

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

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

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

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

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...

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

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

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=decnet+ethernet+broadcast+sto rm


>> 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/10-100_hub_12_24.htm#ques tion9
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/hw/hubcont/ps209/product s_data_sheet09186a0080091e3b.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/hw/hubcont/ps209/index.h tml


> 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

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/hw/hubcont/ps209/index.h tml

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

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.

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.

Re: Low Cost Hub With Read-Only Ports?

In article ,
Martijn Lievaart wrote:

>> 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

>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. :-)

When I say I know of a company, I mean I could names that can still
make me growl for many reasons unrelated to Kalpana. That Kalpana soon
made their products more idiot proof suggests that the case I know about
was not unique, but it is the only case I know of.


>> 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.

Again, "switch" means "buy my wonderful bridge", including for many of
us the conntations of "wanna buy a bridge?"
http://www.google.com/search?q=%22wanna+buy+a+bridge%22

Is there a significant difference between a 2-port and a multi-port
bridge? I don't really think so, but if you insist ...


>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.

All Ethernet bridges have been "switches" for more than 10 years; just
ask their salescritters. More than that, most IP routers and even many
application gateways are also "switches" as those marketoons have been
spending lots of money to tell you.

>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 is wrong. See
http://www.google.com/search?q=%22network+bridge%22
http://www.google.com/search?q=%22network+bridge%22+switch
http://en.wikipedia.org/wiki/Network_bridge
A network bridge connects multiple network segments at the data
link layer (layer 2) of the OSI model. Bridges are similar to
repeaters or network hubs, devices that connect network segments
at the physical layer, however a bridge works by using bridging
where traffic from one network is managed rather than simply
rebroadcast to adjacent network segments. In Ethernet networks,
the term "bridge" formally means a device that behaves according
to the IEEE 802.1D standard - this is most often referred to
as a network switch in marketing literature.



>> 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.

That's not what I call compelling evidence.



>So all multi-port bridges are switches? What is wrong with the term
>switch? I don't think it's marketoid speak.

It is marketoon blather because of its history. It was first applied
to some multi-port Ethernet-to-Ethernet bridges that were faster than
other Ethernet-to-Ethernet bridges. After the suckers that read only
trade rags and believe everthing they are told by the nice salescritters
that buy them lunch were convinced that "switch" meant "superduper
fast," other vendors applied "switch" to their own CSMA/CD bridges and
then to any box that forwards data.

> 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.

You are reasoning backwards from the non-technical connotations of words
to what you think they should have always meant. You are still assuming,
I think incorrectly, that the first network "bridges" connected dissimilar
media instead of only 10BASE-5 networks.

>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.

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. You
should not be inventive like the marketoons, as you are when you claim
"bridge" and "(layer 2) switch" differ.


Vernon Schryver vjs@rhyolite.com

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

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

Re: Low Cost Hub With Read-Only Ports?

On Thu, 31 May 2007 15:02:16 +0000, Vernon Schryver wrote:

> In article , Martijn Lievaart
> wrote:
>
>>> 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
>
>>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. :-)
>
> When I say I know of a company, I mean I could names that can still make
> me growl for many reasons unrelated to Kalpana. That Kalpana soon made
> their products more idiot proof suggests that the case I know about was
> not unique, but it is the only case I know of.

Noted. My horror experiences with Avaya gear are likewise, though much
more recent.

> Again, "switch" means "buy my wonderful bridge", including for many of
> us the conntations of "wanna buy a bridge?"
> http://www.google.com/search?q=%22wanna+buy+a+bridge%22
>
> Is there a significant difference between a 2-port and a multi-port
> bridge? I don't really think so, but if you insist ...

Robert made this clear to me. I asked the question and the answer is a
simple no.

>>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.
>
> All Ethernet bridges have been "switches" for more than 10 years; just
> ask their salescritters. More than that, most IP routers and even many
> application gateways are also "switches" as those marketoons have been
> spending lots of money to tell you.

Lol. See also my reply to Robert. You are both correct that Ethernet
switch is somewhat a misnomer, bridge is a better term technically. You
both also made me shift my assumptions on what a switch or a bridge
means. Yet I still maintain that "a switch" is jargon with a pretty well
defined meaning, never mind what meaning marketroids try to give it.

>>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 is wrong. See
> http://www.google.com/search?q=%22network+bridge%22
> http://www.google.com/search?q=%22network+bridge%22+switch
> http://en.wikipedia.org/wiki/Network_bridge
> A network bridge connects multiple network segments at the data link
> layer (layer 2) of the OSI model. Bridges are similar to repeaters
> or network hubs, devices that connect network segments at the
> physical layer, however a bridge works by using bridging where
> traffic from one network is managed rather than simply rebroadcast
> to adjacent network segments. In Ethernet networks, the term
> "bridge" formally means a device that behaves according to the IEEE
> 802.1D standard - this is most often referred to as a network switch
> in marketing literature.

I fail to see how it is wrong. A bridge can also be a device that "hubs"
between dissimilar media, or "hubs" over another medium.

(snip)

> That's not what I call compelling evidence.

Well, we just have to disagree on that one.

>>So all multi-port bridges are switches? What is wrong with the term
>>switch? I don't think it's marketoid speak.
>
> It is marketoon blather because of its history. It was first applied to
> some multi-port Ethernet-to-Ethernet bridges that were faster than other
> Ethernet-to-Ethernet bridges. After the suckers that read only trade
> rags and believe everthing they are told by the nice salescritters that
> buy them lunch were convinced that "switch" meant "superduper fast,"
> other vendors applied "switch" to their own CSMA/CD bridges and then to
> any box that forwards data.

This is wrong. It is correct in the context of Ethernet, and in the
context of marketroids, but not in the bigger picture. So a SAN switch
should not be called a switch because?

>
>> 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.
>
> You are reasoning backwards from the non-technical connotations of words
> to what you think they should have always meant. You are still
> assuming, I think incorrectly, that the first network "bridges"
> connected dissimilar media instead of only 10BASE-5 networks.

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.

>>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.
>
> 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. You
> should not be inventive like the marketoons, as you are when you claim
> "bridge" and "(layer 2) switch" differ.

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. Also note that you're opinion differs
from Roberts here.

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.

I'm willing to shift perceptions, and don't be mistaken, learned a *lot*
from this thread. Yet your arguments just don't add up.

However, lets reiterate where this all started:

You wrote:
>> If so, what does that imply for the other person's design goal? If a
>> cheap hub that cannot auto-negotiate FDX because one pair is cut falls

I asked:
> I thought all hubs where HDX by definition. Does something like a FDX
> hub really exist?

I now know the answer is no.

M4

Re: Low Cost Hub With Read-Only Ports?

In article ,
Martijn Lievaart wrote:

>>>So all multi-port bridges are switches? What is wrong with the term
>>>switch? I don't think it's marketoid speak.
>>
>> It is marketoon blather because of its history. It was first applied to
>> some multi-port Ethernet-to-Ethernet bridges that were faster than other
>> Ethernet-to-Ethernet bridges. After the suckers that read only trade

>This is wrong. It is correct in the context of Ethernet, and in the
>context of marketroids, but not in the bigger picture. So a SAN switch
>should not be called a switch because?

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.

http://www.google.com/search?q=Kalpana++ethernet+history
http://en.wikipedia.org/wiki/Ethernet#Bridging_and_switching
... In 1989 the networking company Kalpana introduced their
EtherSwitch, the first Ethernet switch. An Ethernet switch does
bridging in hardware, allowing it to forward packets at full wire
speed. It is important to remember that the term switch was invented
by device manufacturers and does not appear in the 802.3 standard.
Functionally, the two terms are interchangeable. ...

That all sounds right to my fading recollections (and never mind the
ancient marketing and trade rag expert nonsense about hardware being
required for wire speed). In 1989 I was working in the south San
Fransicso Bay area as a senior UNIX kernel networking hack with almost
20 years of preceding networking and operating system design and
development experience. (The hardware wire speed baloney is a pet peeve
of mine because of my largely software TCP/IP/FDDI wire speed results
soon after 1989.)


>> You are reasoning backwards from the non-technical connotations of words
>> to what you think they should have always meant. You are still
>> assuming, I think incorrectly, that the first network "bridges"
>> connected dissimilar media instead of only 10BASE-5 networks.
>
>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
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
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
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.")

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."


>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."


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

Not that I noticed.

>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."


Vernon Schryver vjs@rhyolite.com

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.

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

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.