Tuesday, August 16, 2016

Hi Guys

If my complete lack of posts has got you down, there is loads of good info over at my good Friend Paul Tursans blog, you can find it here:
http://chilli-net.blogspot.com/

Sunday, October 18, 2015

Easily test an FXO Port:

To change on-off hook status
#test voice port 0/3/1 relay loop on

this will force the port to answer.

Monday, September 7, 2015

The growing importance of DNS in your CUCM configs

Hi Guys!

It used to be that DNS was an afterthought for most CUCM deployments, many engineers advocated at one point or another just using an IP address rather than dealing with the system team who could either be extremely cooperative or extremely slow.

Those days are GONE, my friends. 

Every bit of UC software you use should be properly configured with DNS.

 Infact, anywhere you CAN use DNS, you should be using it.

The main driver for this is definitely Jabber, I can't count the number of things that can go wrong with Jabber if you do not have your DNS configured correctly.

If you absolutely must get a system up very rapidly and the sysadmin team have been very slow to get there side finished, you can use a router as a temporary DNS server:

The config for this is shown below:

conf t
 ip domain-name
ip  dns server
ip name-server 8.8.8.8 4.4.2.2

ip host _cisco-uds._tcp.ccierants.com srv 0 10 8443 cucm01.ccierants.com
ip host cucm01 192.168.1.10
ip host unity 192.168.1.20

ip host imp 192.168.1.30
ip host _cuplogin._tcp.ccierants.com srv 0 10 8443 imp.ccierants.com



As you can see from the example above, you can use the host command to specify manual DNS entries, you can even do SRV records etc, the only records i can't seem to see are CNAME records, but for our purposes this does not matter.

You can then point your UC servers to this router as there DNS server as a temporary workaround while you wait for the system administration team.

Tuesday, July 28, 2015

How to easily tell if a calling name is being sent

show call active voice  | inc CallerName

Tuesday, April 28, 2015

Converting Wav for unity connection with audacity

Found this blog post and thought it was pretty useful:

http://snafder.blogspot.com/2011/01/saving-wav-files-in-ccitt-u-law-format.html

Sunday, April 26, 2015

Cisco Data Center Product Line Update (UCS M-Series)

Hey Guys!

There has been lots of new Cisco Data Center products released in the past 6-12 months that due to moving country I haven't had the chance to talk about!

Hopefully the next upcoming blogposts will change some of that. I have been doing a lot of UC blogposts recently, so here's hopefully a catchup for you on some of the things in Data Center World!

First of all, let's talk about the UCS M-Series of servers. When first reading about the M-Series, your initial reaction may be one of confusion, it certainly was for me. Read on for more information...

The UCS M-Series server is kind of like a chassis-based rack server, you have a 2RU unit that can take up to 8 "Compute cartridges." These cartridges consist of CPU and memory, they don't have any HDD's or Adapters! Each compute cartridge is actually giving you TWO servers! So this 2 RU unit is providing 16 servers (when fully populated.)

 Supported count for these blades is 2, 4, 6 or 8. You can't have an uneven number for some reason.

A closer look at the specs of these servers reveals an interesting constraint:




The Intel CPU's available to you are not exactly going to set the world on fire, the E3 only has 4 cores for example.  This is by design: these servers are meant to use the minimum amount of power and cooling. The memory fully populates out at 32 gig (I believe 64 gig is coming.)

Here's the kicker that made me realise the purpose of these servers: they're not intended to run VMWare!

These servers are intended for custom applications where you need lots of easily accessible compute resources, where the application itself provides it's own fail-over capabilities.


For custom, bespoke applications like this, the ability to add more compute resources, as well as easily replace failed components is paramount. Cisco UCS M-Series enables this!

Imagine a world without VMware for a second: imagine how incredibly powerful Cisco UCS Service Profiles would be in a non-VM world, suddenly the statelessness of servers doesn't just make it easier to replace ESX-Hosts after failure. It would have been an absolute game changer.

For those companies with bespoke, custom applications that already have their own failover and scaling methods, the UCS M-Series provides the hardware piece of the puzzle, allowing them to easily provision new servers and replace failed servers.

To quote Todd Brannon of Cisco -  “We just see the increasing use of distributed computing, which is very different from heavy enterprise workloads, where you put many applications in virtual machines on a server node, This is about one application spanning dozens, hundreds, or thousands of nodes.”

For distributed computing or enterprise workloads, all that cooling and power costs money and takes up valuable space. The M-Series allows you to reach a density you simply couldn't reach even with a blade-chassis!

Hopefully I have done a decent job of explaining the real-world application for Cisco M-Series servers. It's all about high density for bespoke, single applications that use many servers (think online gaming, ecommerce, webhosting, etc.)

To make this possible, A few technologies where developed.

The first problem to be solved: All we want in the blade cartridges is CPU and RAM, no local disk and no adapters.


Instead of boot from SAN, each M-Series chassis has a collection of local disks, shared amongst the Compute-catridges. This is done in a similar fashion to the virtualization of adapters we see in VM-FEX by doing some nifty things with the PCI-E bus and the Virtual Interface Controller:


I am not sure why Cisco did not consider the use of boot-from-SAN to resolve this problem, perhaps they don't want the applications to rely on boot from SAN? Can I even configure boot from SAN on the M-Series? I intend to find the answers to these questions and will let you guys know ASAP!

In the back of the chassis you will find a slot for 4 local HDD's that will be shared amongst the blades (more detail on exactly how you configure that will be given in a later blogpost)






The table above gives you an idea of some of the options available.

From a network-out perspective, the chassis has 2 x QSFP 40 Gig connectors, providing tons of bandwidth out to your fabric interconnects, obviously you would cable from one port to FI-A and the other port to FI-B.

What's that I hear you say? But Pete! These are uplinked to an FI and the 6248 series is currently 10 gig SFP compatible only!


No problem here, simply use the QSFP 40 gig to 4 x 10 Gig SFP+ cable:



When you go into the UCS-Manager for these M-series, you will even see that the fabric interconnect shows 4 links per fabric interconnect (8 in total) even though their are only 2 physical interfaces:



Let's take a look at one of these chassis's so you can see all the uplinks:




You can see the slots for the disks (4 per chassis), the Management interfaces, console access, and of course the power supplies and 2 x 40 Gig QSFP+ uplinks.

Here's a look at the front of the chassis:





Finally, a logical diagram provides an overview of these connections:











I hope this gives you a deeper understanding and appreciation of the real-world problem the M-Series is trying to solve!

Friday, April 24, 2015

Cisco Jabber Directory options.

Hi Guys!

It's been a while since I posted my Cisco Jabber huge improvements blog! I even promised you I would explain the new directory options available in jabber!

Moving country etc got in the way and their has been a delay but better late than never right? I am also finding more and more customers are asking for jabber, It's no longer the joke compared to Microsoft Lync that it used to be. With collaboration edge and other improvements, it's a great program.

OK, on to directory options.

Cisco Jabber has three directory options:

Enhanced Directory Integration (EDI)
  • Windows devices only
  • Easiest to setup/No real setup required
  • The way I often hear this described is that it uses the outlook address book, this isn't actually what happens, the way EDI works is that the client uses DNS to find the local AD global catalog and binds to this using the login credentials of the user. A lot of Windows Applications use this Windows Directory API in a similar fashion. 
  • Other than making sure the client is a Windows PC and is actually on the domain, and that the user who is logging in is part of the domain, you should not have to perform much configuration here. 
  • This of course assumes your Windows Domain has been setup correctly, but you as the network engineer should not have to do anything to get this going.
  • When you go to "Show connection status" in your jabber client, you will not see any mention of trying to connect to the EDI directory, it will not show up in your jabber client as connected/not connected as it's all part of the Windows API. So keep this in mind!

Basic Directory Integration (BDI)
  • This is the "Traditional" method of LDAP integration with jabber where by you must specify the LDAP server and directory information as part of the service profile for that user. 
  • You can create a user who is able to bind to LDAP for this OR you can support an anonymous bind. You can provide this information via the service profile (which is downloaded by the client) or the client configuration file.
Universal Directory Service (UDS)
    • UDS will use the users that are part of the CUCM end user webpage as the directory entries
    • This is designed for when users are outside your network, on the collab-edge
    • It prevents you from having to expose your LDAP server to the internet for jabber for iphone etc.
    • you CAN force both internal and external clients to use UDS if for example, your an all-mac shop who do not use LDAP, or your cluster covers multiple AD domains, or any other reason you can think where you would rather use the CUCM database than the AD database to retrieve contacts.
    • You MUST have DNS setup properly for this to work, _cisco-uds must exist and must point to the hostname of the CUCM, the actual hostname of the CUCM (for example, perpub.cucm.com) must be fully resolvable, best bet is to point the _cisco-uds.cucm.com to perpub.cucm.com, which in turn will point to the IP address of your CUCM server.
    • Your jabber client WILL cache these entries, separately from your operating system cache of these entries meaning if at first you forget to setup the _cisco-uds record and then add it later. it still may not work. if you suspect this is the issue your having, be sure to completely uninstall the application from your device and clear out any appropriate folders such as the Application Data folder in Windows for your jabber application.
    Check out what the deployment guide has to say about the DNS entries:






    Make sure all the above is correct! UDS simply won't work without all the above being true.


    Let's see how to configure each of them shall we?

    Login to CUCM and navigate to User Management -> User Settings -> Service profile


    You will see something like the below:


    As you can see, a directory server hasn't been selected and most of the config is missing, this is perfectly fine if your using EDI, the "Use UDS for Contact Resolution" means that external users who don't have access to the Windows Directory API since they are outside your firewall will automatically use UDS when connecting externally.

    The features labelled "Only used for Advance Directory" can be used to set filters for the Windows Directory API. This allows you to narrow down the results returned by the Windows Directory Api to just users enabled for Jabber. You could safely leave this alone if you preferred however.

    So for those of you planning to use  a combination of EDI and UDS, your job is complete, so long as your windows domain is setup correctly, for those planning to use BDI, read on!

    For BDI, you will need to define the LDAP Directory servers, this can be done under User Management -> User Settings -> UC Service.

    Create a directory profile and add in the appropriate details:


    An important note about the protocol, according to the deployment guide, you need to use a particular protocol for each type of device:
    • Protocol Type — From the drop-down list, select:
      • TCP or UDP for Cisco Jabber for Windows 
      • TLS for Cisco Jabber for iPhone or iPad 
      • TCP for Cisco Jabber for Android


    Once this is done, go back to your service profile and select the LDAP directory server you just created.


    As you can see, in my example above I have created a separate user and assigned that user to be able to read the LDAP directory (must be able to bind to it), the format must be the username@domain format. You can also use the users logged in credentials if you prefer, the search bases (which unfortunately their are only 3 of) should be in the standard LDAP format.

    My advice if your having trouble getting this going is to use jxplorer (http://jxplorer.org/downloads/) to test connectivity.

    Finally, for some people it may make sense to do away with LDAP completely and strictly use the CUCM directory for contacts. This is done by strictly using UDS. The method to do this requires you make a modification to the client configuration file to force the use of UDS.

    (Important note: Whatever you place into the client configuration settings will be overwritten if their UC service profile has a directory listed, so keep that in mind!)

    The modifications you will need to make to the jabber-config.xml file are shown below:


            UDS
      11.22.33.444
            http://server-name/%%uid%%.jpg


    However, you might find using the config generator a heck of a lot easier:

    https://supportforums.cisco.com/document/106926/jabber-config-file-generator
     
    You can generate a nice config from this, simply unzip the html files and run them in a local web browser, then upload the file to your tftp servers, don't forget to upload it for ALL your tftp servers that your jabber client might use.

    All of the material for the above blogpost was obtained through a bit of trial and error as well as reading a lot of material from the Jabber Deployment Guide for Version 10.5

    I cannot stress enough how good this deployment guide is, it has all the information you could ever need. It is quite long but goes down to what version of office you need, failover and just about any other jabber setting you can think of.