Congratulations to the Cisco Designated VIPs - 2014

Cisco recently announced the new Designated VIPs for 2014. The Cisco Designated VIP program recognizes the top external individual contributors in Cisco's online communities, including the Cisco Learning Network (CLN), the Cisco Support Community (CSC), and the Cisco Developers Network (CDN). You can read all about the VIP program and discover the Cisco Support Community (CSC) here.

This is the fourth year for this program and I am happy to see the Cisco team running the program keeping it alive an well. The CSC is, without a doubt, the best online resource for getting support and information on Cisco technologies. The Cisco team that works behind the scenes of the CSC are an outstanding group of individuals who really care about establishing a robust and sustainable collaboration environment. 

The best news (from my point of view anyway) is that I was selected as a Cisco Designated VIP for 2014. I didn't make the cut for 2013 (I'd like to use my pursuit of the CCIE as an excuse, if you'll allow!) and it feels good to be back in that circle of outstanding talent. There are 36 VIPs this year! That is amazing and definitely demonstrates that the community is alive and well.

I'd also like to take a moment to congratulate the other designated VIPs. I am in great company and you all make me look good, keep it up because I need all the help I can get! I'd also like to thank a few of the VIPs for taking the time to help me out of a few jams. Thanks to Aaron, Anthony, Huff, Jonathan, Martin, Chris D., and of course my brother, David Hailey. 

While I am at it, hats off to my fellow Chesapeake NetCraftsmen colleagues Rick Burts and David Hailey for also making the cut. 

---

Thanks for reading. If you have time, post a comment!

Unity Connection Design Guide Drops 90ms from Latency Budget

This is just a quick note concerning a documentation change in the Unity Connection Design Guides. A few days ago one of my teammates was working on a Unity Connection design for a customer and came across a change in the network requirements for clustering Unity Connection over the WAN. Apparently, Cisco modified the clustering requirements section in the Unity Connection Release 8x and Release 9x design guides. 

The bandwidth requirements remain the same as they were when 8x was released. However, the round trip time (RTT) requirements have changed from 150 ms to 60 ms. Which is quite a big jump. It looks like this change was made on August 29, 2013.

This is more than a little disconcerting because I was looking at the design guide in July and made design recommendations based on the previous RTT requirement. Fortunately, my customer's network can still accommodate the updated budget. But what if that wasn't the case and I had to make a major design change in the middle of the project? Or worse, what if I didn't go back to re-read the design guide and the customer ran into an issue? 

Basically, I would have been screwed. Again, I am fortunate that we are still within budget and that I generally pick the lowest common denominator for clustering over the WAN designs. Which, prior to August 29, 2013, was 80 ms RTT for CUCM clustering. Interestingly enough, UCCX clustering also has a 80 ms RTT budget. It is odd (to me) that Unity would drop below the 80 ms threshold. 

Last point of interest. The UC 9x SRND still states that the maximum Round Trip Time (RTT) budget is 150 ms. That is probably still there to keep things interesting for the operators in the field! Obviously, it is best to err on the side of caution and assume the SRND recommendation is no longer valid.

I tried to find more information to see why the sudden drop in RTT budget. I suspect there may be a defect or some other revelation. If anyone has more information please post a comment. I am genuinely curious.

---

Thanks for reading. If you have time, post a comment!

Provisioning Synology NAS to Support Multiple VLANs/Subnets

A few weeks ago, I decided to purchase the Synology DS1513+ as my home office NAS solution. Even before receiving the gear, I was sketching out how I would integrate the solution with my existing home network. I had a clear need to support multiple subnets/VLANs. 

Synology is supposed to support 802.1q vlan tagging but I found out that the implementation is somewhat limited and I had to come up with a workaround. I was able to gracefully solve the problem and I figured I would share the information with others. I didn't invent either solution presented in this article. I pieced it together by putting in a few hours of research.

I found a lot of inspiration from the Synology forums: http://forum.synology.com/enu/

Checking Peer Firmware Sharing using SQL

For this installment of the SQL Query Series I am going to keep it short and sweet. I was recently doing implementation planning for a project where we need to update the firmware on a few thousand phones. One of the things we like to do is leverage Peer Firmware Sharing to shorten the time needed to push out firmware upgrades. 

One of the pre-requisites to leverage Peer Firmware Sharing is to actually verify it is enabled. This is the perfect job for SQL.

Finding Orphaned User Device Profiles for EM

This installment of the SQL query series is a response to a question posed by a reader. The reader posted a comment on the blog entry: Using SQL to Validate CUCM Extension Mobility. The reader asked if it was possible to find "orphaned" extension mobility profiles using SQL? 

This is definitely possible and is actually pretty straightforward. 

Enabling Local IP Address Dialing on a Cisco VCS Control

I recently fielded a question about IP address dialing and the Cisco Video Communications Server (VCS). It reminded me of a video design I put together a while ago and I have been meaning to put some more video / telepresence content on the blog. To that end, I figured I would share my approach to enabling IP address dialing with the Cisco VCS. 

CUCM 9.1(2) and the Jump Upgrade

As we move further down the road with Cisco UCM releases we are gifted with more and more "upgrade" variants. First came the Bridge Upgrade, followed by the Refresh Upgrade and it's counterpart the L2 Upgrade. Now we have the Jump Upgrade. These "Upgrades" are breeding like crazy but I guess variety is the spice of life. 

All of these upgrade methods serve a function and while I think Cisco's upgrade methodologies are overly clunky, the Jump Upgrade is a step (not a leap) in the right direction.