The Silo Chronicles
The not so exciting adventures of a Network Engineer

As anyone who has ever applied an access-list to an interface knows you must specify the direction in which you wish to apply the access-list.  This direction is used to determine which side is to be used as the source or destination.  While this sounds fairly straight forward it remains a black magic area for many engineers.  Today we are going to demystify this directionality and make it simple and straight forward.

Background
The first thing we must acknowledge is that unicast communications is always between two parties.  As such there is always a direction that communications is flowing.  For the purpose of this post we are going to define those directions as local and remote.  The local side is the interface that has the access-list on it and the remote side is whoever is on the other end of that interface.

Since all unicast communications is between two parties there is always a source and a destination.  These are the terms used within the access-list creation process.  The question is which side local or remote is the source and which side local or remote is the destination.  This is where the direction statement you specify on the interface comes into play.

Which Direction Am I Going?
If you apply the direction IN on an interface’s access-list the interface (local side) considers the source address to be the remote side.  If you apply the direction OUT on an interface’s access-list the interface (local) considers the destination access to be the remote side.  Thus the packet is flowing IN from the remote side or OUT to the remote side.

Why is this important?
Directionality is very critical into the effectiveness of access-lists.  If you do not understand which side is the source or destination your access-lists might result in being more open than originally intended or even worse longer than necessary.

Recently I was provided a challenge.  A customer has a call center with a large number of DIDs that all point to a single script and all calls are handled by a single group of agents.  The unusual part is that they did not want to determine the queue based off which number however they wanted the prompts to change depending on the DID that it came in on.

Obviously one could add a trigger for every number but this customer wanted to be able to determine all the prompts to play based off a database table and the number in that table is the DID not a trigger.  While I could simply extend the table I wanted to enable them to add new numbers without having to make changes to UCCX.  This ended up actually being fairly straight forward.

The first thing you need to do is ensure the number hits CUCM un-altered.  This means no translating on an H323 gateway.  Doing this means you would traditionally have a translation pattern for that number going to the UCCX Trigger.  Instead of doing that add a CTI Route Point and have that CTI Route Point forward all call to the trigger.  What this does is populate the “Last Redirected Number” field of Call Contact Info.  As a result you can now problematically access what originally dialed number even though all calls hit the single trigger.

This is related to yesterday’s post about Cisco changing the phone firmware signatures in 8.5.2(SR1).  To quickly recap the underlying issue is that a phone with firmware prior to 8.5.1 trying to connect to a system with firmware 8.5.2(SR1) or later will fail it’s upgrade due to “Auth Fail”.  This is because Cisco changed the firmware package signature in 8.5.2(SR1) and only firmware 8.5.1 and 8.5.2 have the new signature as well as the old signature.  This means you must upgrade to 8.5.2 before you can upgrade to 8.5.2(SR1) or later.

This trickles down to a factory defaulted phone that runs a firmware prior to 8.5.1.  The way factory defaulting works is once you default the phone it knows to request a specific file from the TFTP server to figure out what versions of what to load.  This file is named “termXX.default.loads”.  The XX is the two digit model number in question. The problem is created when a device pack or service pack is installed on the server that includes firmware 8.5.2(SR1) or newer.  Along with all the firmware files the termXX.default.loads files are overwritten automatically by the latest version installed.

This means if you install 8.5.4 but go to Device Defaults and specify the 8.5.2 version it won’t matter for a factory defaulted phone because the termXX.default.loads file is from 8.5.4 pack.  The reverse is also true.  If you are running 8.5.4 but due to this issue go and install 8.5.2 your termXX.default.loads will now reflect 8.5.2 so all defaulted phones will also go to 8.5.2 and then have to upgrade again to 8.5.4 even if they were already at 8.5.4 previously.  This means if you install a downgraded version of firmware you need to make sure to go back and re-upload the currently installed versions of the termXX.default.loads files.

Checking Your Default Loads Files
This is actually pretty straight forward since the file is in plain text.  Simply use a TFTP client and request the “termXX.default.loads” file for the model of phone you are curious about.  Open it in a text editor and you should see the filenames it will instruct the phone to request.  From those filenames you should see the version number.

Downloading A Different Version of Default Loads Files
If you were like me when you first discovered you found that you needed an 8.5.2 file but the file reference 8.5.4 and the 8.5.2 was already installed.  This isn’t an issue since you can get the correct file from CCO.  If you haven’t installed the 8.5.2 simply backup (Via TFTP) the current version of the file, install the old version and then re-upload the backed up version of the file to restore it to the original state.  If you don’t need the firmware just the file simply go to CCO and find the phone in question.  There should be three files in each model’s area.  One is a .sgn which is for CUCM 5+, One is a .exe for CCM 4.x and the last is a .zip which says firmware files only.  You want to download the .zip firmware files only one.  Once you download it unzip it and you will find copies of your default loads files.

Replacing the Default Loads File
You need to log into the OS Administration section and then go to Software Updates/TFTP File Management.  If you search for termXX you can find the existing file there.  Simply upload the new version and it will automatically over-write the existing version of the file.

NOTE: Make sure you backup the existing one first so you can restore it later.

NOTE: You must restart the TFTP server after uploading the file for the new version to be offered.

You’re Done
At this point the phones that won’t boot should request the new termXX.default.loads file and download the 8.5.2 version of firmware.  Once that is done they should request the latest version assuming the device defaults references a newer version.

One of my current joys I keep getting subjected to is the upgrade Auth Fail messages on brand new phones from Cisco. It seems that with the introduction of 8.5.2(SR1) Cisco requires that you know the new signature in order to load the firmware. The only problem is that brand new phones from Cisco are still shipping with 8.3.1 which doesn’t know the new signature. What does this mean? This means if you are running a current version of Communications Manager you are going to have to manually upgrade the firmware to version 8.5.2 and then let it upgrade to the current version on your system otherwise it will be stuck at the original version.

The Fix

NOTE: You have to run a back-leveled version of firmware on the phone first. Installing this version for the first time will override the default device loads for ALL phones. As such make sure to go to “Devices\Device Settings\Device Defaults” and find the model in question taking note of what the load it currently is set to.  We need this so after we install the back-leveled version of firmware we can change back the default load to the more recent version already installed.

The first thing you will need to do is go download version 8.5.2 from CCO.  Do NOT download the SR1 version as the SR1 version uses the new signature.  Once it is download install it on your Communication Manager Cluster and restart the TFTP Service on all your servers that offer TFTP.  If you don’t restart the TFTP server the system won’t recognize and offer up the new file we just installed.  Once it is installed the default device load for that model will be changed to that version, something liek “SCCP42.8-5-2S”.  You will change to change this back to the latest version you have installed on your system otherwise you risk downgrading all of your phones.

Once you have 8.5.2 install on your system and your default device load changed back to the current version simply find the phone in question under “Device\Phones”.  Inside the phone configuration is a variable called Phone Load Name.  Put the 8.5.2 load name, the value the default device load was automatically changed to, click save and then reset the phone.  Once the phone resets it will upgrade to 8.5.2 and re-register with the system.  Once it is upgraded to 8.5.2 simply remove the value from Phone Load Name, save and reset the phone again.  This time the phone will go ahead and upgrade to the current version.

Long story short, pretty much all Communication Manager systems will need to have 8.5.2 firmware installed for all their phone models and be prepared to manually upgrade to 8.5.2 all new phones on the system.