Catalyst 5000
Dan Minick (SA)
design. I would like to know from anyone that has some time on the 5000. I
have not seen any test reports on the performance, latency, and manageability
of this product yet.
Daniel P. Minick
Network Architect
Knight-Ridder Information
min...@dnt.dialog.com
Charles Hedrick
>I am seriously considering using the new Cat 5000 in a new Data Center upgrade
>design. I would like to know from anyone that has some time on the 5000. I
>have not seen any test reports on the performance, latency, and manageability
>of this product yet.
The Rutgers computer science dept. network is in the process of
migrating to a pair of these (one in each building). We've got 24
ports in use on one. We'll be moving to 96 ports spread across both
of them on Monday. Most of our networks are going through the 24
ports now -- it's just that in the current configuration all the hubs
are cascaded from one port instead of hanging off their own.
Pinging from our router to machines on a conventional network and
machines on the 5000, I see maybe 1 msec difference, like min/avg/max
is 4/7/8 rather than 4/6/8 for a 1460 byte packet. After we first
installed it I thought I saw a couple of msec increase, but I'm no
longer so sure. It's hard to get a good comparison, since the
conventional network is more heavily loaded (surprise!). I haven't
noticed any performance issues in actual production.
Note that the switch does not have "cut-through" switching. That is,
it has to fully receive the packet before it switches it. From the
internal data I've seen, the actual switching is VERY fast, but the
fact that it has to receive the packet adds latency, which is of
course proportional to the packet size. This is likely to cause it to
lose in latency benchmarks where it's being compared against
cut-through switching, and measurements are being done between when
the first bit comes in and when the first bit comes out. I'm inclined
to think that no one will notice it outside such a benchmark.
Cut-through switching would be sort of complex to do in a product like
this, with multiple cards and varying interface speeds.
Our networks don't come close to loading it, so I wouldn't expect to
see any capacity limits.
For some reason we haven't started using network management tools: we
manage our routers primarily by telnetting to them rather than using
SNMP. Thus I can only talk about using it from the console or telnet.
The general syntax of the interactive commands is similar to Cisco
routers, but not the same. (One surprise is that response to console
commands is incredibly slow. This does *not* indicate slowness in
switching packets.) When you make changes, they are non-volatile.
(I.e. you don't have to explicitly save them in NVRAM. You set
something and it stays set across a reboot.) There's no separate
configure command: you just use "set" commands to change settings.
(Yes, you can write the configuration to a server or load it from a
server using TFTP.) As far as I can tell the first software release
has no ACL's or anything else fancy. You can control full or half
duplex, turn interfaces off and on, control which virtual LAN they're
part of, create trunks between units and assign different virtual LANs
to the various trunks, and set up all sorts of parameters for the
spanning tree. There are statistics commands to show traffic on each
port, including separate multicast and broadcast counts, and all the
sorts of error counts I'd expect to see. TCP facilities available
from the console are sort of primitive: You can set an ip address, a
few things like the netmask, and do ping. (But as far as I can tell,
you can't type a hostname for the ping. At least I haven't found any
way to get it to use DNS.) That's about it. You can telnet in, but
not out.
In summary, the console software is not very fancy, but it does what
is needed to manage the box. Given that two departments (computer
science and math) might as well shut down if this thing doesn't work,
I'm just as happy to see a first release that's pretty
straight-forward, but works reliably.
The early announcements talked about hybrid layer 2/layer 3
functionality. That is not implemented yet. Currently it's a pure
MAC-layer switch. So if you've got several virtual LAN's on it (as we
do), you need a separate router to route between them. As far as I
can tell, the fancier things are still planned, and we'd love to make
use of them. While I'd like to have them all now, I'd rather see a
solid MAC-layer switch in the first release than all sorts of features
that haven't been fully tested.