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.

CUCM 7.X – Rewrite Outbound CLI Presentation with Calling Party Transformation Masks

Problem :

You want your MGCP controlled E1/T1 to present a single outbound CLI for a group of DN’s that is different from their individual DID’s. You also want all other DN’s to present as normal.

  • You could hardset the Caller ID DN field on the E1 under “Call Routing Information – Outbound Calls” – This will overwrite all DN’s not just the ones you want
  • You could adjust the “External Phone Number Mask” on the DN. – This works but it will also change the phone display and can have AAR Implications
  • You could duplicate your dialplan in a seperate partition with new CSS’s and Route lists. Overwrite the CLI at the Route List – This is just yuck and doesn’t scale

Solution:
Transformation Patterns to the Rescue! A Transformation Pattern will allow you to adjust the Calling Party number when it hits the gateway conditionally based on the original internal calling party number.

  • Create a Partition called CLIRewrite
  • Create a CSS called CLIRewrite that looks at Partition CLIRewrite
  • Configure your MGCP Gateway:
  1. Device > Gateway
  2. Select your Gateway
  3. Select your E1/T1 Interface
  4. Under “Call Routing Information – Outbound Calls Uncheck “Use Device Pool Calling Party Transformation CSS”
  5. Choose “CLIRewrite” in Calling Party Transformation CSS Combo Box
  • Create your Transformation Mask:
  1. Call Routing > Transformation Pattern > Calling Party Transformation Pattern
  2. Click Add New
  3. Under Pattern enter the internal DN you wish to rewrite (Pattern matches like 28XX also work for matching multiple DN’s)
  4. Under Calling Party Transformation Mask enter the full number you wish to present out your E1
  • Reset your MGCP gateway under Devices>Gateways
  • I also had to do a “no mgcp” and then “mgcp” on the gateway itself
  • Make a test call to your mobile phone to see the re-written number