Getting intimate with some 6509 switches :)

Well it had to happen - I finally got my hands on some real expensive kit! Allow me to show you:


The kit arrived on pallates, lots of them! And blimey they're huge!





After we finally shifted through all of the boxes we were left with 4 beasts (3 pictured):





Once we had all of the components unwrapped we started to assemble the chassis. I didn't include any pics of the dual 6000W PSUs (Hot swappable, dual input, essentially made up of two 3000W PSU's internally) because they were quite boring. The box can be powered up from a single input on a single PSU. The below Sup720 with 10Gigabit Fiber however, is definitely not boring:

The Sup720 is made up of a a PFC and MSFC for both forwarding and routing engines. All intelligence of the chassis is run from here, and the box won't boot without it installed. The box also won't boot without a fan tray:

The Sup720 can only be installed in slots 5 or 6 of the 6509 switch. Notice from the pic below that the backplane for slots 5 and 6 is wider than all the others. Slots 1 and 2 buses are wider too (apparently for when Sup cards used to reside in these slots) however no advantage can be gained by installing any cards in these slots.

In the other two slots we installed some new 48port Gigabit line cards and 24port SFP Gigabit line cards. Each SFP card had 14 Fiber SFP's installed in it. We had both cards set up with a DSFC which means that they are able to make their own decisions (instead of using the PFC on the Sup720). Which ultimately means less pressure on the Sup card.

Fully loaded baby! Time to play!

ISDN (wierd) problem

Well today I discovered an odd issue with a new customer network. For some reason, if the External phone number mask on a phone was anything else than what was deemed "valid" such as when (example numbers used):

Trunk number: 01234 115115
DDI number: 01234 115200
Valid EPNM to send is "200"
Invalid number such as 01234 115200 results in CLI presented to called party as 01234 115115.

...then the call would not complete. IE, if I sent 01234 115200 to the PSTN then the following symptoms would occur:

• IP Phone gets busy tone
• My mobile phone would ring out for half a ring, presenting 01234 115115 before hanging up. Odd!
• What's more is the debug isdn q931 from the Cisco router:

*Jan 26 09:01:29.606: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x0, Calling num 01234115200*Jan 26 09:01:29.610: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x0, Called num 07989163892*Jan 26 09:01:29.610: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0117 Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98399 Exclusive, Channel 25 Progress Ind i = 0x8183 - Origination address is non-ISDN Calling Party Number i = 0x0081, '01234115200' Plan:Unknown, Type:Unknown Called Party Number i = 0x80, '07989163892' Plan:Unknown, Type:Unknown*Jan 26 09:01:29.822: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8117 Channel ID i = 0xA98399 Exclusive, Channel 25 Notification Ind i = 0xE8*Jan 26 09:01:33.614: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x8117*Jan 26 09:01:33.654: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x0117 Cause i = 0x80AC - Requested circuit/channel not available*Jan 26 09:01:33.830: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x8117*Jan 26 09:01:33.834: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0117

Yes that's right! The call completes, yet the Q.931 debug says the bearer isn't available! It did make me wonder whether i'd configured too many bearers than the customer had paid for, but by a stroke of luck I determined that sending the correct CLI to the PSTN allowed the call to proceed:

*Jan 26 09:04:53.326: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x0, Calling num 200*Jan 26 09:04:53.330: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x0, Called num 07989163892*Jan 26 09:04:53.330: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x011A Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98399 Exclusive, Channel 25 Progress Ind i = 0x8183 - Origination address is non-ISDN Calling Party Number i = 0x0081, '200' Plan:Unknown, Type:Unknown Called Party Number i = 0x80, '07989163892' Plan:Unknown, Type:Unknown*Jan 26 09:04:53.534: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x811A Channel ID i = 0xA98399 Exclusive, Channel 25 Notification Ind i = 0xE8*Jan 26 09:04:56.770: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x811A*Jan 26 09:04:58.538: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x011A Cause i = 0x8090 - Normal call clearing*Jan 26 09:04:58.706: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x811A*Jan 26 09:04:58.710: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x011A

Advice on CallManager 6 BAT tool

I hate BAT. I truly think that Cisco have actually made the BAT tool more unusable this time round and it sucks!

My advice to you is to start BATting earlier in your implementation process as it's likely to take you a longer amount of time (and leave you with bald patches with all the head scratching).

Oddities include:

• All sorts of odd fields crop up when you export Device Profiles (most of which are blank) such as Device Pool! When I exported a Device Profile i'd configured and then deleted it from the system I found that (without editing) I couldn't use that exact file to import the same record because I got a "Audible Message Waiting" field was not a valid field. Stupid thing...
• The User export now contains a "PKID" field which looks to be the CallManager's Primary Key field for users in the system. Attempts to import users while leaving this field blank failed due to a "Duplicate value in index field" error. To fix it I had to generate 250 hex strings and stick them into the spreadsheet.
• Both the Phones import and the Device Profiles import failed to recognise that I had configured a Service and Service URL buttons. Every attempt to get this to work failed and I ended up manually adding Extension Mobility Service to 250 phones and 250 Device Profiles. I hope I never have to do a 1000 phone system using CM6 - it would just be a nightmare...

Fun!

Back from Paris!

I'm on the umpc in bed (As you do) and need sleep - So i'll keep this one brief!

• The HTC Touch has been awesome over the holiday with extra long battery life and connections! I was really surprised at how great the camera was and i'll figure out somewhere to upload the pictures and provide some examples. There were a few grievances though which ill cover soon.
• I passed my CVoice exam! Only 4 more exams to go...
• I get company car soon!

Beware users of UK Numbering Plan 27.0 !

If you're using UKNP 27.0 with CallManager 4.X then beware that this may give strange behaviour...

This Dial Plan was released primarily to add 075xx mobile numbers to the list of supported E.164 numbers of the dial plan; but has unfortunately exhibited strange issues with dialling out.

If you experience issues with ISDN Q.931 messages being returned on the gateway with either "No bearer channel available" or "Number not obtainable" then you may find that the dial plan is causing the gateway to send out incorrectly formatted Plan and Type fields. This can be remedied in two ways:

1) Change the "Called Party IE Number Type", "Calling Party IE Number Type" and both Plans under the Outbound Calls settings section of Gateway configuration page of CallManager to "Unknown" instead of "Cisco CallManager".

2) Add the following line to the serial0/0/0:15 interface:

isdn map .* plan unknown type unknown

As far as i'm aware, this patch has now been recalled and Cisco are working on a replacement.

Upgrading from Cisco CallManager 5.x to 6.x

Due to the fact that I have to roll out CallManager 6.0 for a customer in the UK before December this year we have now taken the plunge in the office!

Upgrading was a fairly simple matter - however (as usual) wasn't the same as the documentation described. Basically we were supplied with an upgrade disc and license PAK, with which you use to move to the new platform by way of a tar.gz file on the upgrade disc. Nicely, this had the big advantage of upgrading the CallManager server through the 5.1 GUI (in the same manner that you would any CM 5.x upgrade patch) and then simply rebooting into the new partition. All phones upgraded themselves - Robert's your father's brother. It wasn't quite as smooth as that though because our PAK code didn't work so we had to raise it on Cisco TAC.

So first impressions for me? Well the interface is a nice blue colour and the two great things about the 6.x GUI are the fact that the drop down box on the top right of the page now fits into a 1024x768 screen; and thankfully Cisco haven't moved things around too much - yay.

I think the first impressions were good as i'm used to the 5.x interface though those upgrading from 4.1 will find it quite tricky to navigate through for the first time.

The phones (when rebooting) now show the new Cisco logo as part of the device pack!

After the upgrade we did have a few niggles - the CM service stopped working and the service needed a kick; our MPE integration stopped answering calls because for some reason it had changed the Route List to something other than the MPE trunk; and Presence status stopped working in Cisco Unified Presence Server 6.0 and the server needed a reboot.

The only thing we haven't been able to fix is a service URL that's on everyone's Extension Mobility device profile to unlock the front door; which bizzarely has been replaced with the Extension Mobility service. In CallManager, the device profile shows the correct service URL applied to the speed dial but the phone shows otherwise. Removing the service URL and re-adding it before logging in/out of EM also does not solve the issue.

Update: None of the help pages work! They all give 404 errors - odd.

So that's the bad stuff. The good stuff is:

• We now have syncronization between the Publisher and the Subscriber so that if the Pub goes down we don't lose functionality such as CallForward status, Extension Mobility, and others
• We have mobility and single number reach built in! Also comes with new 'mobility' softkey
• Improved SRST support
• An intercom feature has cropped up in the list (woo!)
• Directed Call Park has turned up
• VERY IMPORTANT: Pickup Group Notification is back! It was missing from all CallManager 5 versions and in alot of instances this is a must have for customers!
• Slightly improved BAT tool

I'll be configuring Mobility and Single Number Reach soon! More to come!

Cisco and their amusing marketing

I have to say that Cisco have done some rather marvelous (Though slightly woolly) marketing in terms of the "Human Network". The latest campaign shows how people in the movie industry use mobility to continue working efficiently.

Interestingly enough they use rebranded OQO2's in the video ;) See, I told everyone UMPC's are the way forward!

But that aside, it looks like Cisco will be pushing their Mobile products (for Blackberry at least for the moment) and I can't wait to get this software onto my Microsoft Smartphone. For some reason (When i've asked Cisco about this in the past) they seem to be very quiet on the Microsoft front; but what i'd eventually like to do is run SCCP/SIP software on my smartphone so that when I walk into the office my phone automatically associates with the wireless and I get dual-mode operation. We're already using this on Nokia E60 and E61 phones in the office and it works great :) But at least I can get Personal Communicator functionality on my Smartphone soon enough.

I can't wait!

Catch up post!

Wow it’s been ages since I posted up as there’s been lots going on - more info on that to follow! The main reason for posting up is as a few notes about my thoughts on UMPC’s, mobile phones and devices/technology in general that would help me to stay productive. I’ll divide these into multiple posts. I’m guessing largely at the moment i’ll be posting this to just myself - but hopefully someone will read this and comment!

Just as a quick point to note all is well at work and the workload is ever increasing! I’m taking a 20 minute break away from revising for CVoice to write this post!

Busy Busy Busy!

Time to try and study for CCDA as quickly as possible so that when my new books arrive for CCVP I can get on and study. Had a chat with Simon in the office who felt that CCDP was a complete waste of time (This coming from an ex-Cisco employee) so CCNP is still something to seriously look at after doing CCVP! Argh - lots of studying to do.

Other stuff:
- Finally got tickets to Download!!!
- I appear to have become addicted to Facebook
- It’s my birthday soon, and I feel old…
- Off to Brighton, Altrincham, London and Scarborough for work - gah.

When the CallManager went Pete Tong...

ARGH.

Well i’m on a customer site and the most bizarre things are happening. Essentially three different engineers have looked at the problem, and spent hours on it, to find that it’s still broken. We found that the Callmanager service was only running on the Subscriber so we kick started this off - but to no avail. Finally after a Publisher restart did the problem go away. However the other site that we added before this one in London is exhibiting the same problem, and wasn’t fixed by the reboot. Very strange…

Essentially it’s a dialling problem to do with picking the right route pattern. Whoever installed the original design in this centralised Callmanager cluster is just an idiot - where logged off phones have the Unrestricted Call search space on them so you can call anywhere from any logged off phone (Toll fraud anyone?), whereas when you log on, that’s where the restrictions come on…

Basically it’s a failed attempt to get the route pattern design correct so that employees can move sites and use the local gateway instead of their own gateway back at ‘home base’ ergo getting cheaper local calls. It’s all a very woolly subject that needs a darn good article writing about it. Watch this space.

Oh and i’m tired of travelling - in London at mo, Scotland Friday. Eurgh.