CCIE-itus Disorder: How to Identify and Treat

This condition affects both experienced and inexperienced network engineers who have obtained the coveted CCIE certification from Cisco.  This disorder is related to an identifiable source of over-confidence and "knowledge indignation" that causes significant behavioral symptoms. 

The first of the behavioral symptoms is the inability to work well with ones coworkers and customers post-CCIE number assignment, caused by the I-know-everything-there-is-to-know-about-everything-networking factor.  While the patient's breadth of knowledge may be significant, this symptom is often considered to be simply a delusion of grandeur.  It is often overlooked if the patient is a contributing member of the team, although talk of the patient's bad attitude behind his back is sure to occur.

Secondly, the CCIE-itus patient may exhibit signs of knowledge hoarding, refusing to assist others in their pursuit of the CCIE.  This fraternity mentality often leads those CCIE candidates to a feeling of resentment and disdain for the CCIE-itus patient who refused to help them on their journey, thus damaging relationships for no good reason.

Thirdly, the inability to be effectively managed is a symptom the CCIE-itus patient may suffer from.  This closely correlates to the first symptom listed, however is classified separately because it is possible to get along with ones peers splendidly, but be to ones boss as oil is to water.  Management's only course of action is to force this CCIE out of the organization for not being a "team player".  This could potentially lead to a situation where employment might be difficult to come by, if word gets out of the patient's condition. 

The first step in the treatment of CCIE-itus is recognizing that a problem exists.  Often, people who have CCIE-itus deny their problem and do not seek professional help for their symptoms.  Early screening tests can be done to identify mild to severe cases of CCIE-itus, sometimes even pre-CCIE number assignment.    The next step in treatment involves establishing a separate CCIE as pack leader who does not suffer from CCIE-itus.  The example set by the non-afflicted CCIE should disperse the majority of symptoms mentioned in this article.  Lastly, it is important to bring the patient "down a few notches" in order to instill a sense of humility.  This can be done any number of ways, for example, beating him to within an inch of his life with Wendell Odom's CCNA Exam Certification Guide.

UC Keep It Simple Stupid #2 - Naming Convention Phooey

Ever noticed that every configuration example from Cisco for UC Manager names elements with the element type abbreviated along with a "-" or "_" before or after the abbreviation.  For example, a device pool would be named SiteA_DP, along with Site A's CSS being SiteA_CSS, and maybe some Internal_PT and PSTN_PT to go along with it.  This annoys me to no end, ultimately because it is a "zero thought process required" approach, and one that's taken all too often.  Think about it.  There's no reason to include a _CSS or _PT on the end of these configuration elements, because you can't accidentally choose a CSS in a partition drop down menu!  I have a (semi-)short list of recommendations I follow when I design a UC Manager naming convention:

1. Don't include the type of the thing you are naming in its name (did you think this WOULDN'T be #1?)

2. Establish the goals of your naming convention ahead of time, then tweak the names to conform to your goals. 

3. Think about scalability.  If your CUCM is going to be scaling to a large number of sites, opt for a standard site naming convention that won't require you to re-do things a year or two down the road.  

Your first location in Georgia could be GA1.  This works until you have 10 sites in GA, then the formatting gets a bit hokey.  What happens when you need to add a Germany site?  You can see where this is going.  

4. Don't overcomplicate the naming.  At the same time, if you know for sure that your organization will never scale outside of 10 sites in GA, just call the sites by whatever common name you usually refer to them.  Don't bloat your naming and make things confusing if you don't have to.  While this may seem to conflict with #4, remember that it's your job we're trying to make easier here, and the job of the person that will replace you (because you're so awesome at this naming convention business, you got a promotion).

5. Be descriptive for the function of the element, and don't be afraid to include a space or two or three in the name.  Seriously, it won't hurt anything.  (There's a caveat for this in complex dial-plans, where there is a 512 character limit of the partitions in your individual CSS's.  See here: http://bit.ly/isXeDV) 

6. Try to match up the naming of the functions to commonly terminology used elsewhere in the platform.   I've been in a habit lately of calling my phones partition "All Directory Numbers".  I've seen this partition named anything from Internal_PT to Extensions_PT to Cluster_PT, none of which logically match up to what type of numbers are put in the partition.  DIRECTORY NUMBERS.  Make things fool proof and you might just save yourself from...yourself. 

7. For site specific elements, decide on how you want those elements listed, either by function or by site.  I generally name my individual site CSS for phones "Site Name - Phones". Typically though I will also have a CSS for gateways named similarly "Site Name - Gateways".  In the drop down this would look like:

SiteA - Gateways

SiteA - Phones

SiteB - Gateways

SiteB - Phones

SiteC - Gateways

SiteC - Phones

You might prefer to have all the CSS's grouped by function first, then site name, so my individual site CSS would become "Phones - Site Name".  

Gateways - SiteA

Gateways - SiteB

Gateways - SiteC

Phones - SiteA

Phones - SiteB

Phones - SiteC

This ties back to #2.

8. Don't be afraid of using numbers or "_" in front of names in order to influence ordering the lists.  If you want a particular group of partitions to always be last, include a "_" in front of the name.  If you want something to always be at the top, number your partitions starting with 0. 

Naming conventions are NOT an exact science, and are very subjective.  That's why it's important to establish your own naming guidelines before you set out to design or redesign your own infrastructure.  Now I'm going to go rename this blog UnifiedConfusion_BLOG.

Great read over at networkingnerd.net entitled "9.@ Must Die!" Yes! Agreed!

Tom Hollingsworth wrote an excellent post about ditching the 9.@ route pattern and the subsequent route filters.  Love it.  Cisco needs to remove this from the SRND and let it quietly fade from view. http://networkingnerd.net/2011/05/26/9-must-die/

UC Keep It Simple Stupid #1 - Dial-plan, smial-plan

Overcomplicating is a very common issue amongst engineers, in just about every discipline.  Unified Communications is no exception, with Cisco leading the vendor pack (wolfpack?) in the way of confusing their customers.  Yes, I know that complexity breeds flexibility, but for my customers it equals an insanely steep learning curve that can be difficult to surmount.  The first of my "Keep it Simple Stupid" posts will address one of the more complex elements of Cisco's Unified Communications Manager, the dial-plan. 

There's a very common occurrence whenever I start talking about partitions and calling search spaces with customers; eyes start to glaze over, beads of sweat start swelling up on foreheads, and the inevitable question: "What training classes are available for this??"  "Relax," I tell them, "we'll go over all this before I leave."  I spend a few hours slowly beating them to death with my powerpoint presentation on CUCM administration, and normally the situation doesn't get any better.  Nine times out of ten, their biggest lack of understanding is around the use of partitions and calling search spaces.

A long time ago, in elder versions of CUCM (read CallManager), You created a single set of route patterns, and single set of partitions, and single set of calling search spaces for each site.  This was easy to understand (relatively speaking), but it didn't scale well.  

Then Cisco started recommending the Line/Device calling search space model, which did greatly decrease the number of route patterns and partitions in use.  Since we decreased the number of things to configure, this made the dial-plan easier to understand, right?  Not so much.  The Line/Device method (to put it simply) uses calling search space concatenation to merge two layers of partitions together.  The top layer consists of the gates that a call must pass through in order to get to the bottom layer of partitions, which actually contain route patterns that will connect your call.  If the top layer contains a match for a particular type of call that isn't allowed, say an international pattern, the call is blocked.  Make sense?  Right.   Below is a visual representation of this concept.  In this particular example, the only allowed calls would be local, because international and long distance patterns are targeted for being blocked.

I'm writing to recommend a different approach, one that captures some of the glory of the ol' easily understood days.  There's a really handy feature that was introduced in 7.x called Local Route Group.  This feature allows you to dynamically assign a route group (gateway) to a shared route pattern based on whatever phone is dialing the pattern.  The Local Route Group is configured in the Device Pool of the phone.  If I have a gateway at my New York location, and the phones in the New York location dial the standard long distance route pattern (9.1[2-9]XX[2-9]XXXXXX is what I use), the logic in the Local Route Group will evaluate the phones' device pool setting for route group and choose the first gateway in that list.  Magic?  Almost.

So how do you get there from here?  First, create a new route list, called something like Standard Local Route List.  This list will have the same settings as your normal route list, but it's route group will be a special one in the drop down menu called Standard Local Route Group.  That's the secret sauce that marries any given route pattern to the phone's configured gateway.  The route pattern will point to whatever gateway (route group) is assigned to the device pool of the phone that dialed the pattern, thus leaving you with a common set of route patterns that will scale to all devices.  

Back to partitions and calling search spaces.  We will still use the concatenation of the line and device calling search spaces, but no more of this silly blocking business.  Your device calling search space will have all your internal partitions, plus something to stick your 911 route pattern in (we don't want to toss that one up to user error).  Create one calling search space per type of class of service.  I usually have International, Long Distance, and Local.  Your International CSS will include an international partition, a long distance partition, and a local partition.  Your Long Distance CSS will have a long distance partition and a local partition.  I'm sure you can see where I'm going with this.  These partitions should contain the route patterns for each respective type of number, all tied to the Standard Local Route List that will allow that dynamic allocation of gateway to dialing phone.  Here's what this might look like:

No more reverse logic, and fewer route patterns and partitions to boot.  This will NOT APPLY TO ALL SITUATIONS.  Your mileage may vary, and I definitely recommend the use of a lab to test this configuration out before you start making changes willy-nilly. Happy configuring!

Video for the Voice engineer

Having done Cisco voice over IP for the last 10 or so years, this video thing is really cramping my style.  First and foremost, change is difficult.  I was comfortable with voice, why go and add a whole new set of things to learn?  It's a CCIE Voice #forgoodnesssakes, not a CCIE Video.  Now who moved my cheese.

Secondly, the wave of new products added by the Tandberg acquisition are all VASTLY different than what we're use to.  Why is that you might ask?  Because these products are all easy to use, with very limited tweaking available for any type of complex solution.  In a nutshell, these products haven't been convoluted by Cisco just yet (you mean the licensing from Tandberg is easy? Yes, crazy talk.), and it's odd to login to an intuitive interface and actually accomplish what you set out to.

Obviously I'm being harsh (read bitter) here, but I see a lot of promise in the Tandberg products.  Over the next few months, I'll be learning lots more about the Video Communication Server (VCS), TelePresence Management Suite (TMS), Codian MCU's, and of course all the wonderful variety of endpoints.  In all seriousness, I'm excited about the direction that the collaboration engine is moving, and definitely look forward to being one of the guys riding this train.