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.