CCIE Collaboration Lab: My Return Trip

If you follow this blog regularly (it says a lot about you, but that is for a different post) you know that last year, 2016, I took my first crack at the CCIE Collaboration practical lab exam. I took it in RTP (North Carolina) and it royally kicked my ass.

It is now nearly 12 months later and I am preparing for my second attempt. This year I have built my own lab instead of renting rack space from INE (who I believe I still owe money to from last year, but so far they haven’t come to collect). I am taking the exam on April 25 in RTP once again and while I am going to give it my very best shot, I am taking it because I honestly have no desire to attempt the written again and if I wait more than 12 months to attempt the lab my current written will be invalidated.

I’ll probably have more posts as the weeks draw closer, but the most important thing to note so far is that it is getting cheaper to purchase your own lab hardware. With Cisco coming out with the 44xx and 43xx ISR G3 routers the 29xx ISR G2 routers, which are still the hardware of choice for the current lab iteration, have become cheaper in the secondary market. I’m not saying that building a lab is cheap, by any means, but at least more folks now have that option. In my case,  my lab contains the following…

  1. 3825 – PSTN/BB Router. This is running CME for PSTN emulation. I am running PRIs to all 3 of the site routers; T1 PRIs the US sites and an E1 to the international site, I am using fractional PRIs to save on DSP resources.
  2. Dell Server 72GB Ram, Dual Xeon, SSD USB Drives (new addition) – This started life as a very weird CS-24TY but has now been revamped and runs all of my lab VMs easily.
  3. 2921 for HQ (2) PVDM-3 16 DSPs (this is actually enough for homogeneous video conferencing).
  4. 2821 for Site-B PVDM-2 64 DSP (good for voice only) (Generally Site-B is H.323 and possibly CUBE, a 2821 will run 15.1.x code which is not perfect but is close enough for that location). If I am asked switch/conference video at Site-B, I am S.O.L.
  5. 2811 for Site-C (CME)… I actually just ordered a 2911 and ISM-SRE-300 module to replace the 2811 as there are some serious differences between 15.1.x CME and 15.2.x and later CME i.e. CME 9/10.5/etc. I have a CUE module in the 2811 but I made the decision to spend money and get something closer to actual.
  6. 9971 phones as required (cheap enough used) and 7962 phones instead of 7965s as the differences between the two SCCP options are not that great and it saves some money.

In the back-end of the lab I also have a 3750 switch that I am using as a layer 3 WAN cloud instead of Frame Relay (which only matters in the QoS sections) and a 2960G PoE switch which I am using for phone power. I know the syntax is different but I cannot yet justify spending money or effort to aquire PoE  EHWICs.

I also have another Dell Server which hosts my “production” 11.5 CRS infrastructure which I can use for BB SIP calls as needed.

My setup is not perfect but perfect honestly costs to much. The fact that I can come down to my basement and practice whenever I want without having to reserve pricey rack space makes my setup perfect for me.

How about you? Do you have a lab? What are you running? Any suggestions? Comments? Questions? Leave them below!

-Justin

 

 

Advertisements

Configuration Example: Cisco CUBE with FlowRoute

So you’ve decided to step-up and get a “Big Boy” phone system. You’re done with CME and you’ve moved to Call Manager (Cisco can call it whatever it wants, but to many of us it will always be Call Manager). But wait, there is a problem… Call Manager won’t natively peer to your ITSP, so what do you do? While there may be many solutions, the best one that I have found involves using Cisco’s Unified Border Element or CUBE. CUBE, for those of you new to Cisco voice technology is a fancy term for a SIP proxy. The CUBE pairs with your ITSP and routes calls to and from your Call Manager via SIP or H.323 .  Below is the topology that I am working with. Yours may look a little different and we’ll get into these differences as we progress.

 

 

ITSP Logical ConnectivityI mentioned topology differences and the biggest one is probably the firewall (ASA 5505) sitting between my CUBE and my ITSP. In an ideal world I’d give my CUBE router a public address and let it talk directly to the internet, this is not an ideal world. My ISP is small and stingy with their public IP addresses. It took a few fights and some extra cash to get one dedicated public IP on my ASA and getting a second is simply not worth the trouble. I’ve read all of the stories regarding trying to pass SIP through a firewall and while there are some caveats, I’ve made it work.

Connectivity is Everything…

It seems like a simple enough statement, but in terms of building and maintaining voice network connectivity really is everything. I prefer to keep it simple and the simplest way to build my topology was to keep the same protocol throughout. With the exception of the SCCP Phone (Call Manager does just fine translating SCCP to SIP and vice versa) every other connection is SIP.

  • Call Manager to CUBE & CUBE to Call Manager – SIP
  • CUBE to ITSP & ITSP to CUBE – SIP

By keeping the majority of my transactions SIP, I take away at least one point of failure. I mentioned earlier that you could configure the CUBE router connection to CM via H.323 and while I know that configuration can work just fine, why make it more complicated than it needs to be? The biggest thing to keep in mind when deciding on connectivity is “Can I troubleshoot it easily when it does not work?” Its a lot easier to look at a straight SIP trace.

Bring on the configs…

We’ll start with the CUBE first (This CUBE is running archaic 12.4 code).

The voice service commands are pretty standard. In the allow-connections section sip to sip is the key portion. Remember to configure your sip registrar settings here as well.

VoipServiceSnip

The next piece we’ll look at, are the voice translation rules. The first rule points my DID (I only have one in this scenario) to an extension on my CM. The second rule puts my DID as the number mask for all outgoing calls. Without this second translation, I’d have to do additional configurations in CM, the translation rule is easier.

TranslationRuleSnip

Now, we’ll look at the dial-peers. I’ve got one for the incoming calls (from the ITSP) (Dial-peer 2) One for outgoing calls (I’m just dealing with LD calls right now) (Dial-peer 10) and one for communication with CM (Dial-Peer 100). Note where I applied my translation rules.

DialPeerSnip

Finally, we’ll look at the SIP-UA (SIP User Agent) configuration. This is the actual heart & soul of CUBE. This is the connection and authentication to the ITSP. You may find that your ITSP we’ll peer with your specific public IP address rather than give you a user-id and/or password. Peering with an IP is in theory much more secure as spoofing an IP end to end is much more difficult. Notice the credentials and authentication sections. They both include a username and password. The credentials line identifies your CUBE to the ITSP and the authentication line gets you through door.

SipUASnip

Next, we’ll take a look at the CM trunk configuration (My CM is 9.x)

First the initial configuration of the trunk. You’ll assign your device pool, media resources and things of that nature here…

CMSIPTrunkSnip1

Now, we’ll look at the incoming calls section of the trunk config. You’ll want to make sure that you direct inbound calls to the Calling Search Space that includes the Directory Numbers that you intend to answer the calls. You can also adjust things like significant digits. Generally speaking, I always want the CUBE/router to send me everything and then I’ll configure CM to pick and choose what it wants.

CMSIPTrunkSnip2

Finally, we’ll look at the connectivity section of the SIP trunk config. Here you’ll specify the address of your CUBE and your SIP and SIP Security profiles. These are standard profiles from Cisco and no tweaking is required to make this work.

CMSIPTrunkSnip3

Like most other things that Cisco creates, there are far more options in the trunk configuration than most configurations will require.

Finally, lets take a look at the ASA (This ASA is running 8.4(7) code)

First, we’ll take a look at my network and service objects. For this scenario, I defined the RTP range and SIP protocols. While not necessary, I defined SIP with both UDP and TCP entries.

ASAObjectSnip

Next, we’ll take a look at the NAT statements. While the CUBE is not a NAT aware SIP Proxy, the ASA provides some assistance in maintaining the end to end SIP headers required for successful peering and usage.

ASANATSnip

Finally, we’ll take a look at the access-list portion of the configuration. These are pretty straight forward…

ASAACLSnip

Additional Notes…

The phone & route pattern configurations for this example are not impressive. The phone (7961) is configured with a Directory Number and pointed at a CSS with access to PSTN calling features. The basic route pattern is configured as 9.1XXXXXXXXXX and pointed at the SIP trunk created above. I discard the 9 (pre-dot) and send 11 digits to my ITSP. You don’t need the 9 but it keeps the scenario in line with most business systems.

I’ve struggled to find an ITSP that supports a true integration with the CUBE. There are several ITSPs that work with Asterisk and other open-source IP PBX platforms but CUBE is its own animal and as such these “Asterisk ITSPs” usually don’t work properly or in many cases don’t work at all. When I came across FlowRoute http://www.flowroute.com I was initially skeptical but as I’ve used their service more and more, I’ve become a bigger and bigger fan. The first thing that you’ll notice about FlowRoute is that anyone can try it out. Simply sign up and you’ll get some free time (minutes to place test calls) to peer with them and try your system out. If your system doesn’t work and/or you aren’t happy with the performance, go another direction. If (and this is much more likely) you really enjoy the service. Deposit some money, purchase a DID and keep on going.

Final Thoughts…

I hope this example configuration has helped someone. What I’ve shown is not difficult and is actually quite simple when compared to other voice configurations. That being said, we all need to learn somewhere and hopefully I’ve helped someone do that.

**DISCLAIMER** All information posted in this article was accurate as of the date/time it was posted. Images posted in this article follow the same copyright guidelines as the article itself. Plagiarism is not a gray-area issue, it is wrong and in some cases illegal. If you like this article link to it, do not copy it.

© Wednesday, September 24, 2014 – justinvoip.com – All rights implied & reserved