Catalyst 3750 – Are they really that bad?

Over the past few years I have seen many comments in the blogosphere questioning the reliability of the Catalyst 3750 platform. I believe Ethan Banks (@ecbanks) has posted on this in the past and more recently Aaron Conaway (@aconaway). I thought I’d post my experiences over the past 4-5 years managing ~40x 3750 switch stacks composed of 2-5 switches without a single stack failure in production operation (we did have one stack member die due to lightning strike and the rest of the stack continued to function).

I will qualify that all of these stacks are in a relatively static physical installations but many of them have been subjected to temperature ranges of 22C to 30C (72f – 86f for the American folk). They aren’t configured with any advanced features, only routing/switching/access-lists and weren’t running bleeding edge IOS (mostly c3750-i5-mz.122-20.SE). Most of these stacks were at the edge delivering Ethernet services in a residential environment and not in the core or data center.

I will also add that I think both Ethan and Aaron are awesome engineers that I respect greatly and I’m and avid reader of their blogs, my experience with the 3750 just hasn’t been the same as they have described. Perhaps some of my anally retentive practices in deploying these switches has minimised the occurrence of failure.

PUT THE STACK CABLES IN PROPERLY

The stack cable is heavy with quite a relatively shallow connector; you should install this in the same way you would change a tire. I seat the connector and hand screw the cable in until it is firm and then use a flat head screwdriver a few turns on each side at a time until the cable is fully screwed in.

When provisioning a new stack I always screw all the stack cables in first and then power on the switches.

SYNCHRONISE YOUR IOS

Install the same IOS on a new stack member as the rest of the stack before installing using the archive command.

Switch#archive download-sw tftp://x.x.x.x/c3750-i5-mz.122-20.SE.tar

PROVISION NEW SWITCHES BEFORE HAND

Provision new switches on the stack before installing. I also configure the new switch with the appropriate switch number.

Switch(conf)#switch x renumber y

RIG THE ELECTION

Use the switch x priority command to rig the election on all switches. Highest priority wins the stack election.

I usually want switch 1 to be the master so give it a priority of 15 descending that number with each subsequent switch

Switch(conf)#switch 1 priority 15
SYNCHRONISE CONFIG

Manually drop the config of the switch onto new stack members before adding them too the stack. I know you don’t technically have to do this I just like removing all chances of error.

FINAL VERDICT

I think 3750’s are a great switch which in my experience have been rock solid performers. I would recommend them on the edge of anyone’s network, the ability to grow capacity as needed and distributed fault tolerance are big pluses. Would I use them in a data center? Probably not. I would also suggest that if you required a stack size of 4-5 switches off the bat then a 4500 would probably be a better option for cost vs features/performance.

Advertisements

Cisco IOS – Negating Terminal Commands

I always found it odd that I couldn’t negate terminal commands in IOS like other commands.

Eg;  no Terminal Monitor

I just assumed it wasn’t there, until I saw another engineer execute to disable term mon.

Router# terminal no monitor

It seems in IOS the terminal commands are special in that they require the terminal key word before the no keyword to negate sub-commands.

Perl Script – Turning Aironet Wireless Interface On/Off

I had a need to be able to quickly turn the wireless interface on/off  on a 1231G Access point.

I wrote this simple Perl Script to logon too the AP via telnet and issue a “No shutdown” on the interface. To Sutdown the interface I use an identical script to perform a “Shutdown”.

You could then have both scripts on your desktop to easily toggle the state of the wireless, or you could do what I do and put the scripts in the start menu and use Launchy to run the scripts.

The Script uses Net::Telnet::Cisco , which can be installed with Perl Package Manager using the following command:

ppm install Net-Telnet-Cisco


APWirelessOn.pl

##
# Filename – APWirelessOn.pl
# Version – 0.1
# Creator – reloadin10
# contact – reloadin10.wordpress.com
# Description – Performs a no shutdown on a specified Cisco AP Interface
##

use Net::Telnet::Cisco;

# Define your variables here
$host=’1.1.1.1′;
$user=’username’;
$pass=’password’;
$enable=”enablePassword”;

#CODE
my $session = Net::Telnet::Cisco->new(Host => $host);
$session->login($user,$pass);
if ($session->enable($enable) ) {
$session->cmd(‘config terminal’);
$session->cmd(‘interface dot11Radio0’);
$session->cmd(‘no shutdown’);
} else {
warn “Can’t enable: ” . $session->errmsg;
}
$session->close;

Cisco 3750 – 3rd Party SFP

It is possible to use 3rd party SFP’s in a Cisco 3750 with the following commands:

Switch(config)#service unsupported-transceiver

and

Switch(config)#no errdisable detect cause gbic-invalid

The first command will generate the following warning from cisco :

” Warning: When Cisco determines that a fault or defect can be traced to
the use of third-party transceivers installed by a customer or reseller,
then, at Cisco’s discretion, Cisco may withhold support under warranty or
a Cisco support program. In the course of providing support for a Cisco
networking product Cisco may require that the end user install Cisco
transceivers if Cisco determines that removing third-party parts will
assist Cisco in diagnosing the cause of a support issue.”

I wouldn’t recommend using non-Cisco SFP’s in production environments, but for a lab save the bucks and go for it.

IOS – Ping Sweep

I discovered a really cool feature of IOS that is probably common knowledge but I was never aware of.

You can perform a ping sweep of a directly connected network by pinging the broadcast or Network address.

Example:

Router#ping 192.168.1.255

The output is as follows :
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.255, timeout is 2 sec

Reply to request 0 from 192.168.1.19, 4 ms
Reply to request 0 from 192.168.1.59, 40 ms
Reply to request 0 from 192.168.1.57, 40 ms
Reply to request 0 from 192.168.1.56, 40 ms

This is incredibly useful for doing discovery and populating the routers ARP table after a reboot.