Low-end Layer 3 switch?

I need a very low-end Layer 3 switch (or router, but would prefer the faster speed). 4 ports would be sufficient; 8 or 16 would be great.

10/100 is also sufficient; no need for Gigabit. Does anyone know of such a device, either new or a model I should look for on the used market?

Thanks.

sPh

Reply to
sphealey
Loading thread data ...

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.

-- glen

Reply to
glen herrmannsfeldt

Just what is the difference between a "switch" doing things at the network layer and a "router" doing things at the network layer?

I've always been of the understanding that stuff done at layer 3 is "routing" regardless of what the marketroids call the box.

rick jones

Reply to
Rick Jones

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.

sPh

Reply to
sphealey

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.

-- glen

Reply to
glen herrmannsfeldt

So, implementation detail is more important than function?

My understanding is that those big honking "core routers" from the likes of Cisco, Juniper, Foundry et al are very much special purpose hardware.

It seems that one can run some variant of Linux on just about anything with a clock pulse :)

By that definition then the really high-end (and probably not quite so really high end) routers from the vendors would be switches.

rick jones

Reply to
Rick Jones

If you do, Rich will remind you of the lack of usefulness for single port bridges.

-- glen

Reply to
glen herrmannsfeldt

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

rick jones

Reply to
Rick Jones

If it's Cisco it would probably be running some variant of IOS. But it might very well have some rather remarkably mundane innards.

Reply to
J. Clarke

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.

Reply to
snertking

Bridges cannot perform cut-through forwarding. Switches (more and more these days) can.

Aside from that, I agree that the major difference seems to be port density.

/chris

Reply to
googlegroups

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

Reply to
Stephen

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.

Reply to
Walter Roberson

Agreed. Also the fact that speeds have increased - the serialization delay at gigabit speeds is negligible for normal packet sizes.

I can't remember *any* switch vendor which boasts about cut-through forwarding these days.

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

Reply to
Steinar Haug

Allow me to clarify :-)

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.

:-)

/chris

Reply to
googlegroups

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

Reply to
Walter Roberson

Hey guys: great trip down memory lane; thanks!

Now: any rec'os on the question ;-)

sPh

Reply to
sphealey

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.

Reply to
Walter Roberson

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.

sPh

Reply to
sPh

What are you going to do to simulate the WAN latencies and perhaps bandwidth constraints?

rick jones

Reply to
Rick Jones

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.