Cisco Expressway Bug CSCuo83458

In a recent Cisco Expressway deployment I ran into a bug that is worth mentioning to the community.

I usually recommend naming the Expressway-E server with the enterprise’s standard naming convention. Then for the _collab-edge SRV record, create a generic name on the public Internet to point to the Expressway-E server. Normally this is not a problem, however the bug CSCuo83458 complicates this.

The official conditions of the bug is “The Expressway-E server is configured with a hostname and/or domain name which does not exactly match what is present in the _collab-edge SRV record.” The symptom is “Clients unable to register via Mobile and Remote access via XMPP or SIP. Jabber clients may show an error message of ‘Unable to connect to server’.”

What is comes down to is that the Expressway-E name, internal DNS records, and the _collab-edge SRV must be exactly the same. If they are not, Jabber will not be able to connect.

There is no fix for this bug as of this writing. The workaround is to name the Expressway-E the same as the SRV record. Until this is fixed, my recommendation to my clients is to name the Expressway-E the generic name on the public Internet. Then once this bug is fixed, the hostname of the Expressway-E can be changed.

Bug ID:

Cisco CLI Alias Tricks

I have used the alias command on both the Cisco IOS and Nexus platforms to shorten long commands. For example, I use the alias ‘sisi’ for the command “show interface status | include”.

NX-OS deprecated many of the legacy commands that IOS still contains. One of these deprecated commands is the “write terminal” command. I have worked on Cisco routers for a while and originally learned to use ‘wri’ (I use three letters to avoid mistakes between ‘show’ and ‘shutdown’) to save my configurations instead of “copy run start”. On the Nexus platform the ‘write terminal’ command is one of those deprecated commands. However, with an alias you can put this legacy command back in the CLI. In fact, this is one of the first commands I put in any Nexus that I work on. Use the alias ‘cli alias name wri copy run start’.

NX-OS allows you to issue show or ping commands while you are in configuration mode. This is extremely help when you need to verify if that the command you just issued fixed the problem. On the IOS platforms you have to use the ‘do’ command in order to execute any exec level commands while in configuration mode. It’s a little annoying that you have to use ‘do’, IMHO. If you create the IOS alias ‘alias configure sho do show’, you will be able to issue show commands within configuration mode. Of course you can substitute the ‘sho’ in that command with whatever your preference of the three variations (sh, sho, show) to issue show commands.

You can do this with more of the exec level commands. Here are a few of the IOS alias that I use:

alias configure sho do show
alias configure ping do ping
alias interface sho do show
alias interface ping do ping

Cable color coding

I like things neat and orderly. Everything should have it’s place. I like standards and sticking to them.

My preferred cable coloring method is blue for general data. Yellow would be for important or critical systems. Cross over cables or an unsecured network area, such as the Internet edge, would use red. Management connections would be green. This is great for helping to identify what the cables function is or assist in tracing a cable through a bundle of wires. When the cables are first installed in a brand new installation, it looks good.

Everything is neat and orderly. How long does that last? A week? A month? Eventually someone who doesn’t care about how the cabling looks or where you connect that cable into the network will come in and disrupt all order and organization. Next thing you know, your cabling turns into something like this.bad_cabling

In a recent project we had to build two brand new Data Centers in a very short time. We didn’t want to have to worry about having enough of the correct color cables at the correct lengths. So we decided to just go with black cables. The racks/cabinets are black, the patch panels are black, the cable management is black, everything except the equipment was black. Using black cables would help to hide any poor cabling that was done. When we were done, it looked good, neat, and clean. However we didn’t have any of our coloring cues. I got to thinking about how we could use black cables and still have those coloring cues.

Electrical tape! It comes in a variety of colors. Just cut off a small piece and wrap around each end of the cable near your label. Yes you wouldn’t have the visual color as you traced a cable, but it would make you double check before you unplug that blue tagged cable you thought was going into the DMZ and should be red. This could even open up more colors than were possible before.

This method has great benefits. You keep the color coding standard, all of the same colored patch cables look neat and clean, the black cables in black rack/cabinets and cable management look uniform and clean, and you don’t have to worry about keeping on hand so many different colors and lengths of cables. It’s like some kind of intergalactic hyper-hearse, correct?

If you have a color coding standard, keep it posted somewhere in the DC or network closet with the colored tape so everyone can easily reference it.

My parting comment is not to move any cabling on someone who is OCD about it. It is very annoying. That means you Terry.


Disclaimer: I can’t post pictures of client’s environments, so I borrowed pictures I found online. Below are those credits.
Neat cabling
Bad cabling
Colored electrical tape

Labeling patch cables, patch panels, and wall jacks

Many network administrators are worried about the colors of the patch cables and assigning them to a certain function. For example, red patch cables could mean crossover or outside the firewall, where blue are servers or desktops, or purple connect to APs, etc. However, the actual labeling of cables, and wall jacks, get severely overlooked. Have you ever unplugged a cable from a switch or patch panel to test something and then when you went to plug it back in you couldn’t remember where it was supposed to go? This article is my recommendation for labeling cables.

Patch Cable

A patch cable typically gets connected to a patch panel on one end and a device on the other. When the cable is labeled, the label needs to clearly indicate what it is connected to on both ends. Let’s say your patch panel is in rack 4.01 (row 4, rack 1) and the top of the patch panel (for multiple rack unit patch panels) is on U34. Then you are going to connect the cable to port 15 on that patch panel. Your description for the patch panel port should be R4.01/U34/P15. Now let’s say you are connecting it to a chassis based switch named Access1 on blade 6, port 29. Your description of the switchport connection should be A1/S6/P29, where A1 is the abbreviation for the switch, S is for slot, and P is for port. Both the description of the patch panel port and the switchport should be on each label at both ends of the cable. When you disconnect the cable on either side, you know exactly where to connect it back from the label and the label tells you where the other end goes. Labels be identical on both ends of every patch cable. You type it once and print it twice.

Patch Panel

Patch panels should be label with what is on the other end. In a Data Center where you have infrastructure cabling going from one rack to another, the patch panels should be labeled with the rack and U of the other patch panel. If it is the same port for port, then you don’t have to label the individual ports. However, if one patch panel is split between two patch panels on the other end, then the ports on all three patch panels should be labeled. When it is clearly defined, then it avoids confusion and mistakes.

When the patch panel is used for drops to user workstations, then each patch panel port should be labeled with the unique ID of the drop on the floor. This should be done by your cabling vendor and part of their standard scope of work. In addition, your cabling vendor should provide you with a digital copy of your floor plan and the unique IDs on the drawing where they are located on the floor plan. This may cost you a little more for them to do this, but it’s worth it’s weight in virtual gold when you are trying to locate where that device is in the building.

Wall Jacks

The drop at the wall jacket, or biscuit, should be labeled too. This label should include the drop ID from the floor plan and the patch panel ID. The patch panel ID should be in the format of IDF identifier, rack, patch panel, and port. For example, let’s use IDF 02, rack 03, patch panel 34, and port 48. The label should look something like I02/R03/PP34/P48. That’s a lot to put on a label going into a small space, so if you have a standard format you can shorten it. A shorter version could be 02/03/34/48, or, non-zero filled, 2/3/34/48. I would encourage you to not drop the IDF or rack identifiers, because while you are told they will never expand or grow the site, it will happen. Develop a standard, stick with it, and be consistent.

For the floor plan drop ID, you should use something that will help you locate the drop on the floor. Something that includes room numbers is always good. Avoid labels that could easily change, like MARK-1 for Mark’s office. When you have both the drop ID and the patch panel port labeled on the jack, it will help reduce time to locate and troubleshoot workstation connectivity issues.
Labeling is only as good as you make it…keep up with it. Make a standard for your labeling, document that standard, and stick to it.

Networking Field Day 9 in review

Networking Field Day 9 (NFD9) is over and it was exhausting. The week was packed full of presentations, demos, and food. It’s been about a month now and I have time to reflect on the event.

I work for a Cisco partner and therefore I primarily work on Cisco gear and hear only about things Cisco is doing. I rarely get to hear from vendors outside of the Cisco ecosystem (marketing buzzword). I throughly enjoyed hearing from other vendors. I will go into each of them in more detail later. There was one vendor I did have mixed feelings about going into the event due to some things that happened in my previous $dayjob, but in the end I was impressed with their presentation and off camera discussions.

The presenters from each of the vendors did an excellent job. While there was some marketing in the presentations, we had an opportunity to get into the weeds. Each presenter was able to answer technical questions or had the appropriate staff right there to answer those technical questions. Carly (@_vCarly) did an excellent white board session. I have never seen drawings on a whiteboard so perfect.

Of course the staff of Tech Field Day (TFD) did an excellent job of running the event. Stephen (@sfoskett) and Tom (@networkingnerd) had everything well planned out, so much that I only had to make sure I was waiting in the hotel lobby when I was supposed to be there. While Claire was not at NFD9 in person, she had taken care of all the details behind the scenes.

All of the delegates were very professional and welcomed me to the group. The delegates came from several different professional areas; enterprises, vendor partners/integrators, self-employed consultants, and educational institutions. This provided a good variety of different perspectives of the vendor presentations. There were four of us that were brand new to NFD, while the rest either partially or fully attended a previous TFD event.

All of the vendors did give the delegates some sort of swag. With that being the case, no tweet, article, or comment that any of the delegates were provided for us. Well, there was one exception…the suggested tweet. Brocade provided Lindsey Hill a suggested tweet as an inside joke from a previous event. Brocade also provides the best swag of all to everyone involved and that is a free 1 year trial of their virtual Vyatta controller and router. While most of the vendors gave us a t-shirt, I have to make a recommendation to all vendors about shirt swag. If you give me a t-shirt, it will only really be worn around the house and you will not get any advertisement from it. If you give out polos instead, those could be worn to work and there would be public display of the shirt. Also, expand beyond the color black.

In all it was a great event and I was honored to be able to attend. I learned a lot and met many great people. If I get another chance to attend another TFD event, I will be there (my crazy schedule permitting).

Cisco Internal VLAN Usage

About a month ago I worked on an old CatOS switch. Working on this switch reminded me about some of the differences between CatOS and IOS. One of the big differences is how a Layer 3 routed interface is configured between the two OS versions. On a Catalyst running IOS, it is almost identical as […] Read More