Tag: Collaboration

Revisiting Cisco Jabber SRV Records

From time to time I like to revisit previously discussed topics, today is the day for Cisco Jabber SRV records. Previously I had written a post talking about internal Jabber SRV records and how to configure and use them. That post is located here for your viewing pleasure.

The truth is that internal SRV records, when it comes to Cisco Jabber, are only half of the story. To tell the whole story, you need to have at least a partial understanding (and hopefully a working knowledge) of Cisco’s Collaboration Edge. If you do not, this will be a bit out of context for you, but the theory is easy enough to understand.

So you have an on premise Cisco IM & Presence installation and you have users on your internal network that are using Cisco Jabber. It is a very powerful business tool; instant messaging, screen sharing/control, and desktop video/voice all from one convenient and surprisingly well built application. What happens when your users leave your internal network? Do they VPN? Do they use WebEx? Or perhaps something less IT friendly? What if they could use Cisco Jabber wherever they are, without the hassle of VPN and securely from any device? The truth is, they can!

In comes Collaboration Edge, it goes by a few other names, but this post isn’t about Collaboration Edge…directly, its about a very handy SRV record that sits on your external DNS server(s) to make the Collaboration Edge integration possible. For a 1000ft view, Collaboration Edge includes two appliances, one on the LAN and one on the Internet or DMZ. These two appliances talk together using magic, pixie dust, tiger blood and SSL certificates (those are the ones that really scare me, but that is for a different post). With these two appliances talking, they are also linked to CUCM and voila’ we have extended CUCM’s capabilities to the information super-highway known as the Internet. It’s certainly not that simple, but you get the idea.

We know from my previous post that Cisco Jabber can discover it’s  network services via DNS SRV records. Internally it can discover both CUCM (for directory services and service profiles) and IM&P (for login and instant messaging, etc.). The process for discovering services outside of the network is very similar, but the differences are worth noting.

Cisco Jabber always searches for the same services i.e. SRV records no matter what network it is on. Whether it is on your internal network or just sitting on the Internet i.e. a home network the discovery is the same.

When you put in your Jabber ID (JID) i.e. someone@somewhere.com Jabber queries the following records based on the domain of your JID.

  • Jabber looks for WebEx Connect (Cloud instant messaging services).
  • Jabber looks for Internal SRV records i.e. cuplogin and cisco-uds (as shown below).

_cisco-uds._tcp.example.com

_cuplogin._tcp.example.com

  • If Jabber does not get a response from either of these records it looks for collab-edge which is pointing at the Collaboration Edge – Internet side appliance from earlier (as show below).

 

_collab-edge._tls.example.com

The collab-edge record configuration looks like this…

_collab-edge._tls.example.com   SRV service location:
          priority       = 3
          weight         = 7
          port           = 8443
          svr hostname   = vcse1.example.com

 

Assuming that no other records above the collab-edge record answer, Jabber sends its login request to the device attached to SRV record and logs into internal IM & Presence server as well as CUCM and any other services configured in the service profile.

A couple of import things to remember when talking about external DNS. First, some well-meaning DNS administrators will put a catch-all in their external DNS configuration so that anything destined for *.somewhere.com goes to their website. This is fine, but it will break your external Jabber connectivity. This break occurs because even though it doesn’t exist cuplogin.somewhere.com will still be caught by the catch-all. Second, collab-edge goes in the external DNS environment only. Just like cisco-uds and cuplogin are only internl, collab-edge is only external. Forgetting or disregarding this will surely make your troubleshooting much more interesting to say the least…

I hope this has been helpful to someone. Cisco Jabber is a power tool and when paired with Collaboration Edge the possibilities are endless. Hopefully some day soon I’ll be able to write a series about Collaboration Edge and its many facets but until then, thanks for reading.

-Justin

Advertisement

The Aftermath of My First CCIE Collaboration Attempt

A few days ago I wrote about attempting my first CCIE Collaboration Lab.

Its the night following my attempt and I’ll be honest, it did not go well. I was confident going in and I was confident for the first 3 or so hours. When we broke for our “speed lunch” I knew I was behind and as the hours,minutes and seconds ticked down in the afternoon I realized without much resistance that I was screwed.

That being said, my expectations were probably not properly metered. It was my first attempt and according to the most “recent” Cisco numbers that I have read, first time passing attempts are not common.

I also think that there are lessons to be learned, even in failure. I’ll list a few of them below.

  1. I was worried, going in, about things like the IOS and UCM Dial Plans, I’m pretty sure I nailed those.
  2. Unity Connection in either form i.e. SCCP or SIP is a relatively mindless process and I think I owned both of those sections as well.
  3. I do not know IOS switch QoS as well as I thought I did, that will have to change.
  4. Cisco Unity Express (CUE) is a bastard in any form and things that I assumed would work because they always have in my practices kicked my ass.
  5. Mobile Voice Access: This little gem was on my lab and none of the studying that I have done covered it in any way shape or form. I implemented it 5 or 6 years ago in a production environment but those brain cells were not present today. I guess I’ll be learning MVA.
  6. I didn’t read or see anything in the lab that honestly had me confused, I did however run out of time. I need to be faster, I must be faster.

Where does this leave me?

It leaves me with no CCIE number, it resets my written countdown clock but my goal is my CCIE number and without that this, even though I learned a lot, was a failure.

Tomorrow morning I’ll hop on a flight and head back to Denver. I’ll continue to study and work towards my goal.

I’ll be back Cisco, I’ll definitely be back.

-Justin

 

 

 

Prepping for My First Crack at the CCIE Collaboration Lab Exam

Well its finally here… On 4/26 I’ll sit for my first crack at the CCIE Collaboration Lab Exam in RTP.

I am excited and nervous but more than anything ready to get in there and do it!

After last week’s final (so far) demise of IP Expert, which I had rack rental tokens with, I was forced to shell out some cash for time on the INE racks. I don’t mind the INE racks but I seriously believe that had they stayed in business, the ProctorLabs (IP Expert rack rentals) would have been much better.

My home lab setup while better than some was not nearly verbose enough to allow to me study and prepare the way I wanted to. I could have probably built something at work to do the job, but I’ve been fortunate enough to have been given this week for nothing but prepping and going into the office just sounded like a bad idea. INE allows for a L2VPN connection to their equipment which allows me to use my own phones and thus get the “touchy feely” prep for the lab as well as the technical practice.

20160422_124014

With regards to the technical practice, I found a supposed lab scrape on a forum (don’t ask I don’t remember which one) and I have materials from when I attended an IP Expert CCIE Collaboration Lab 10 day boot camp last December. The IPs are different but the technology is the same.

As an engineer that’s been working in the Cisco AVVID space for 12+ years now, I’ve developed some bad habits and while it has been painful, I think my lab prep and study have helped me break at least some of them. For those in the same position, my best advice is below…

  1. Read. Don’t assume you know because you’ve seen it all before, just read.
  2. Think on your feet. Because you may have seen it all before (see point 1) you probably can figure out what just about anything the exam throws at you.
  3. Do you play the points vs. finishing game?  No idea. I’ll let you know after 4/26.

I guess I’m not truly sure how long 8 hours is, but I hope I can at least make a decent showing. My confidence right now after a week of prep is high but we’ll see what stepping into the exam room on Tuesday does to me.

Wish me luck!

-Justin

 

 

 

Cisco Jabber SRV Records: Being a Knowledgeable & Helpful Collaboration Engineer

If you’ve deployed Cisco’s IM & Presence (formerly Cisco Unified Presence or CUPS) and its associated Jabber product line, you know all about DNS SRV records, or at least you should.
If you don’t know about them or if you are a little rusty, Cisco has a good document (link below) that you should get to know intimately…
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide.html

SRV records allow servers to advertise service locations within the core of the DNS architecture. For example: _cuplogin._tcp.example.com is an SRV record the Jabber looks for during service discovery and sign-in. The record above points at the IM & Presence service across port 8443 which happens to be what Jabber/IM&P uses for authentication. There are SRV records that Jabber looks for for directory services as well as Collaboration Edge (Cisco Expressway) which is its own animal.

Without SRV records flexible Jabber deployment becomes difficult and Collaboration Edge integration becomes next to impossible.

So we know that SRV records are important, but are they really our problem as Collaboration Engineers? I guess that depends on how broad your IT shop or your customer’s IT shop is. You may have, at your disposal, wonderful Server Engineers who know DNS like you know Call Manager, but not every situation is that clean.

I realize that not every enterprise uses Windows for internal DNS, but since the majority seem to, we’ll cover Windows DNS. My system is a 2008 Server Standard instance.

– What SRV records do we need to add? Cisco gives us a good run down in the document referenced above, I copied the below passage from that document.

The following is an example of the _cisco-uds SRV record:
_cisco-uds._tcp.example.com 
priority       = 1
weight         = 5
port           = 8443
svr hostname   = cucm1.example.com

The following is an example of the _cuplogin SRV record:
_cuplogin._tcp.example.com
priority       = 5
weight         = 100
port           = 8443
svr hostname   = cup1.example.com

**There are additional records required for Collaboration Edge**

In the outputs above, you’ll see the SRV record and its priority, weight, port  and host the has the service. You’ll notice in the SRV record itself that TCP is called out. If these were UDP SRV records you would of course see UDP in the SRV.

– How does this translate to Windows DNS? Pretty easily actually…

Below is the DNS Manager screen from my server.

                      DNS Management

You’ll see that under my domain’s Forward Lookup Zones there are several folder entries including _tcp, _udp, and others.

If you right click on the domain (image below)  you’ll able to add Other New Records and from here you can select SRV records

New Other RecordsSelect SRV Record Type

Once you select your SRV record type you can begin configuring the SRV record (shown below)

SRV Record Config

Once you fill in the particulars and click OK, you’ll see your record(s) under the _tcp organizational folder (shown below)

Show SRV Records

From there, repeat the process to add the other records that you need.

We haven’t really talked about priority and weight and they do exactly what you might expect them to do. Multiple systems can respond to the same SRV record within the same DNS domain. Like anything else, someone has to be first. Assigning a priority and a weight allows you to both build redundancy and load balance across multiple hosts. For instance if you have a CUCM PUB and a SUB, you may be want the SUB to respond first and thus would give it a higher priority for its _cisco-uds record.

In closing, you may never need to know how to add SRV records but if you do, hopefully you’ll remember this post and be successful in your deployment.

-Justin