I know what I think the difference should be, though I don't know that anyone else has the same definition.
I would say a layer 3 switch should have more special purpose hardware, such as would be expected in a layer 2 switch.
A router is usually mostly software, with more or less conventional NICs and a COTS processor.
I understand that one can run Linux on a Linksys WRT54G, for example.
Similar to the way a layer 2 switch might have a processor to handle tasks other than packet forwarding, a layer 3 switch might have a similar processing function. Packet forwarding should be done without the involvement of the processor, or with minimal involvement, other than to update routing tables.
I was asked the same question in a job intervew at a large datacom equipment company, interestingly enough.
Philosophically there is no difference. At the time "switches" were first marketed (and I bought one of the first Alantec switches sold in northern Illinois), routers typically had fewer, lower speed interfaces but were capable of handling many input types (I won't even attempt layers) - routers typically had a card for anything a telco could put out, plus Ethernet, Token Ring, FDDI, Arcnet, etc.
Switches in contrast were usually Ethernet only (10 Mb), but they had multiple ports (say 12, 24, or even !36!) and a backplane which could route some significant fraction of the load created by (24 ports x 10 Mb).
Today, with switches having every feature under the sun and routers available at Best Buy with 10 Gb backplanes, the distinction is fading fast.
As with the old saying, form follows function. If you can do it with cheap hardware there is no point in using expensive custom hardware. As processors get faster, the dividing line will move.
Probably. The last time I opened a Cisco router (a lower end model, about 10 years ago.) I was surprised to see ordinary hardware.
How about the core router mentioned above?
Maybe. Though the people that buy them probably don't care what they are called as long as they work up to their specifications.
:) Since there are probably GP "service CPUs" in those things I'd bet they could - they might even be running Linux there already.
I've always chalked it up to the salescritters calling something a switch to make it sound newer and sexier and perhaps easier to manage, whether it was really easier to manage being an open question.
Of course, at times I think that a switch should _really_ be called a multi-port bridge :)
a single port layer 3 switch (one that routes) between tagged vlans could be usefull. You could use it to add routing capability between the vlans on a layer 2 switch...
Hmmm.... perhaps someone should make a small box like that and market it.
No reason it cannot be a multi port switch and dont bother to connect some?
I have done a varient on this several times with a router on the side of a layer 3 switch.
i used it to add extra routing functions to a layer 3 switch that only supports IPv4 - Appletalk, OSI and SNA.... usually the switches GigE, but a router is often limited to 100M and VLANs.
the underlying assumption is that the IP needs to be fast but that the minority protocols still need to work....
it actually makes a good tool to get people to actually move to IP.
"of course you can use xxx - but if you go to IP then you have access to much more bandwidth....."
I would have thought it was "less and less these days" rather than "more and more". You can't do cut-through between different port rates, broadcasts and multicasts are increasing, increasing port densities make it more likely that one or more of the destination ports will be temporarily busy at the time, you can't do rate policing well with cut-through, you can't do packet inspection security functions with cut-through, you can't abort transmission of a packet that is detected as having the wrong CRC, and you can't easily do port-level authentication such as 802.1X with cut-through. All of these factors argue for a continuance or increased reliance upon the queued-packet asynch transmission model rather than the increased cut-through.
I didn't mean that the cut-through model applied to more and more of today's Ethernet traffic.
I meant that while not *all* switches support the cut-through model, that support for it is more common than it was, say, 10 years ago.
The reason for my post was to assert that there *is* a distinction between a bridge (which by definition does not support cut-through) and a switch (which may support it). The text you snipped implied that bridges and switches are the same thing. They're not. I have no opinion on whether cut-through forwarding is a useful feature given the requirements of your network.
15 posts into this thread, it's starting to look like the OP has gotten his answer: Nobody knows of a pocket-sized layer 3 switch.
...We'd just rather argue the semantics of what it means to "switch", whether a one-armed switch might be useful, and whether the it's better to store-and-forward because it allows you to do tricks that are impossible otherwise.
"(more and more these days)" implies that the number of such switches is still increasing.
The last time I saw a general-purpose cut-through switch being advertised was... I dunno. 7 years ago, maybe longer. I might have heard of a special-purpose cut-through switch 5 years ago. I can't think of a single one on the market now, but there are thousands and thousands of switch manufacturers and I don't pretend to know them all.
It seems probable to me that if there are more cut-through switches deployed now than 10 years ago, that it would be due to ones bought
8-9 years ago that haven't been retired yet. It is my -belief- that the percentage of cut-through switches is shrinking quickly. I can't say, though, that I have chased any industry numbers.
It is my suspicion that outside of some possible mil or niche industrial deployment, that buying a cut-through switch these days would be about like trying to buy a hub these days -- barely being made, and manufacturers "creatively mis-stating" properties because it's cheaper for them to quietly re-label a mass-production device than to continue to produce small market technology.
"pocket-sized" wasn't one of the requirements, but "low-end" was, along with "fast" (since speed was the reason given for preferring not to use a router.)
There are too many small-run and rebranded switches to keep track of, let alone to decently survey to know how well they work.
I make it a practice to recommend against *any* "low-end" unmanaged switches in any situation in which "fast" is even a hint of a requirement, as it is my experience that if one wants "fast" then one needs to be able to probe packet error rates and to be able to monitor the switch to investigate throughput bottlenecks, whether caused by the switch quality or just a function of the topology and traffic patterns.
To put it in other words, it is my belief that "fast" and "unmanaged" are thoroughly incompatible.
That being the case, although I do know of some consumer-level "name-brand" unmanaged layer-3 switches, I won't list any of them, as I would have to recommend against using any of them.
Not from me. "very low-end" implies unmanaged, and I do not recommend any unmanaged switches for environments in which "fast" is important.
If you give up one of the properties, "very low-end", "layer 3", or "fast", then there might be some recs for equipment that you wouldn't take a sledge-hammer to... at least not the -first- day.
My fault for not being more precise. I need this so that we can run a lab simulating our WAN, which has four locations/netblocks, for about 10 weeks. By "fast" I mean 100 Mb (or even 10 Mb) rather than the 2 or 3 Mb total backplane capacity of an old router. It doesn't have to last long and sledgehammering it at the end of that time is fine.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.