The ILS - Intercluster Lookup Service feature enables different CUCM Cluster to exchange directory URI with other clusters in an ILS network. URI Replication provides support for intercluster URI dialing. ILS runs as a service on the Publisher node of a cluster.
We can call ILS - Intercluster Lookup Service as Voice Routing Protocol because it behaves like dynamic routing protocol. Just like advertising the local route from one router to another, ILS will advertise the URIs between different CUCM cluster.
Each CUCM cluster node advertises its URIs and “SIP route string” to its neighbor’s (or Hubs). CUCM cluster later creates a table with URIs and associated SIP route string. Finally, SIP route strings are routed through SIP route patterns.
Contents
1. ILS Configuration using Password Authentication
2. ILS Configuration using TLS Certificate Authentication
3. ILS Configuration using TLS Certificate Authentication - Common CA Signed
There are two types of clusters in ILS.
Hub Cluster:
- Each ILS network must have at least one hub cluster and they are the backbone of an ILS network.
- Hub clusters exchange ILS updates with the other hub clusters in the ILS network and then relay that information to and from their spoke clusters.
- You can connect a hub cluster to multiple other hub clusters, or you might configure a hub cluster as the only hub cluster in the network.
- In addition, you can connect a hub cluster to multiple spoke clusters, or you might configure the hub cluster with no spokes clusters.
Spoke Cluster
- A spoke cluster in an ILS network relies on the hub cluster that it is connected to in order to relay ILS updates to and from the rest of the ILS network.
- A spoke cluster can have only one hub cluster.
In this document, we are going to see the step by step configurations for ILS - Intercluster Lookup Service with password authentication as well as TLS (Certificate) authentication.
Topology
I have 2 CUCM clusters here in the ILS network.
- 10.106.79.71 - HQ Cluster
- 10.106.79.83 - BR Cluster
1. ILS Configurations Using Password Authentication
- ILS password authentication configuration is pretty easy and straightforward. The HUB and SPOKE clusters will exchange some unique password to establish ILS connection.
Let's have a look at the configuration window.
Step 1.1: Activate Intercluster Lookup Service on all the CUCM Publisher
Go to Service Ability > Tools > Service Activation > Select 'Intercluster Lookup Service' and save.
Step1.2: Set Cluster ID for the CUCM Clusters
Cluster ID is a unique identifier for the cluster.
Go to CUCM Administration Page > System > Enterprise Parameter > Cluster ID
Note: Make sure you configure unique cluster ID for all the nodes in the ILS network.Moreover, we need to restart all services for the parameter change to take effect.
Step 1.3: HUB Cluster ILS Configuration
I'm planning 10.102.79.71 as my ILS HUB Cluster.
Go to Advanced Features > ILS Configuration > and configure as follows.
> Save
Route String: This will be a unique string that will be advertised to the other clusters. Other ILS peers use Route String to route the call.
Above configuration uses 'Password' based ILS authentication and synchronize the clusters every 1 minute.
Note: When you configure the Advertise Route String, make sure it is less complex. Sometimes the URI Call fails if we have more "-" and "Letters" in the Route String. Bug: CSCtz63687
The moment you click Save, it will ask for ILS Registrar Server. Since I do not have any other HUB cluster, we can leave blank and click OK
Step 1.4: Spoke Cluster ILS Configuration
10.106.79.83 is our SPOKE cluster.
Go to Advanced Features > ILS Configuration > and configure as follows.
When you click Save, enter the Registrar server as the HUB cluster 10.106.79.71.
Step 1.5: Refresh the ILS Configuration
Now refresh the ILS configuration to see the updated status.
Step 1.6: Configure URIs for the End Users
Go to User Management > End User > and select the user you want to enable URI.
For LDAP user, make sure the URI is synced from LDAP server. For the local users, you can set a URI as shown below.
Now go to the Controlled Devices section in the same page and assign the user's desk phone as the controlled device. Also, configure the primary extension.
Note: Primary extension maps the URI with the Directory number, hence it is mandatory to configure primary extension on the user page. Also, note that all the URIs will be in the 'Directory URI' partition by default.
Now go ahead and check the Directory number (e.g. 1002), you will be able to see the URI field.
Similarly, you configure another URI for a test user in another cluster.
Step 1.7: Verify the Learned Directory URIs
Go to Call Routing > Global Dial Plan Replication > Learned Directory URIs
Note: Any of the URI learned via ILS will be having 2 unique values. One is the Route String and another one is Cluster ID. Route String is used to route the call back to the respective cluster via a separate SIP trunk.
ILS will only take care of advertising the URIs between clusters. They do not participate in call routing. For dialing the URI from one cluster to another, we need to have a separate SIP trunk.
Step 1.8: Create a SIP Trunk in Hub & Spoke Cluster and Point each other
- Create a SIP Trunk in Hub Cluster CUCM and point the destinations to the Subscriber servers (CUCM Nodes which runs CCM Service) of the Spoke cluster.
- Create a SIP Trunk in Spoke Cluster CUCM and point the destinations to the Subscriber servers (CUCM Nodes which runs CCM Service) of the Hub cluster.
- Since configuring SIP Trunk is out the scope of this article, I have just provided above screenshot. Feel free to comment here any queries regarding the SIP trunk.
Note: By default, all the URIs will be assigned with 'Directory URI' partition. Hence you must have a CSS with Directory URI partition that is assigned as Inbound CSS at the SIP Trunks.
Step 1.9: Configure SIP Route Pattern
- The Advertise String of other ILS node will be the SIP Route Pattern. We need to create SIP Pattern at the HQ cluster as well as BR Cluster.
Go to Call Routing > SIP Route Pattern > Add New and Point the SIP Trunk.
Step 1.10: LAB Testing
- I have configured a speed dial as a URI which points to the other cluster. Calls are working fine in both directions.
Warning: The above method is the simplest way of getting the ILS up and running. In order to read further on this article (other ways of configuring ILS), you need to have a better understanding of CUCM Certificates and Multi SAN Certificates
2. ILS Configurations Using TLS (Certificate) Authentication (Certificate Cross Import Method)
- To use Transport Layer Security (TLS) authentication between clusters, you must exchange Tomcat certificates between the publisher node of each cluster in the ILS network.
- From HUB Cluster Cisco Unified Operating System Administration, download the Cisco Tomcat Certificate.
- Upload the same as Tomcat Trust in the SPOKE cluster.
- Similarly, download Cisco Tomcat certificate from SPOKE cluster and upload to HUB as Tomcat Trust.
- Service activation (Step 1.1) and Cluster ID configuration (Step 1.2) are same in this section as well. Hence I haven't added those screenshots.
Step 2.1: Downloading Tomcat Certificate from HUB Cluster
- Go to OS Administration Page of HUB Cluster Publisher Server.
Security > Certificate Management > and the search for 'Tomcat'
Note: In my example, I have a CA-signed Certificate, but the procedure is pretty same for Self Signed certificate as well.
- Click on the certificate and Download it (Save in a proper place).
Step 2.2: Upload the HUB Certificate to the SOPKE as Tomcat-Trust
Login to SPOKE cluster publisher OS Administration > Security > Certificate Management > Upload Certificate/Certificate chain.
- Now browse the certificate downloaded in Step 2.1 and then click 'Upload' button.
Note: The system will tell you to restart Cisco Tomcat Service but it is actually not required! :)
Step 2.3 & 2.4: Upload SPOKE Certificate as Trust in HUB
Follow the same process and get the certificate from Spoke cluster and upload to HUB as Tomcat Trust.
Step 2.5: Configure ILS on the HUB & SPOKE Clusters with TLS Certificate Authentication
Go to Advanced Features > ILS Configuration > and configure as follows.
Note: When we click Save on the HUB, it will ask for the registrar server, please Skip that. But when you click Save on the SPOKE, please provide HUB IP address to the registrar server.
- Also, note that we have selected 'Use TLS Certificates' as the ILS authentication mechanism.
- Refresh the configuration after few minutes.
- ILS connection has been established. The remaining configurations like adding URIs, creating SIP Route Pattern, SIP Trunk and Speed dials (Step 1.6 to Step 1.10) is same as discussed above.
3. ILS Configurations Using TLS (Certificate) Authentication (Common CA-signed Method)
- In the multi-cluster environment (more than 20+ clusters for example), exchanging (cross importing) certificate between all the clusters are not practical (or time-consuming).
- When the certificate expires, you will have to cross import the certificates again.
- In that scenario, we can use the Common CA-signed certificates to on every cluster.
- Once we have HUB and SPOKE tomcat certificates are signed by same CA, we do not need to cross import the certificates each other.
- But in this case, we need to use Password Authentication first and once it establishes the ILS connection, switch back to TLS.
Note: In CUCM Version 10.5, you can either select Password Authentication or TLS Authentication but not both. Whereas in CUCM Version 11.5, we can select both.
Summary:
- Use common CA to sign the tomcat certificate of HUB and SPOKE
- Establish ILS with Password authentication only
- Switch the ILS authentication to TLS only.
Step 3.1: Download HUB and SPOKE Tomcat Certificates
There are different methods to check the Tomcat certificate. The easiest way would be opening the HUB CUCM-PUB URL on Internet Explorer and click the Security Report lock button > View Certificate.
Go to the Details tab and click Copy to File....
Click Next from the Certificate export wizard window.
Select DER encoded binary X.509 (.CER)
Enter the directory path to Save the CUCM certificate and proceed.
Click Finish button to complete the certificate download process. You will be getting Export Successful message.
Repeat the same steps for downloading SPOKE CUCM-PUB tomcat certificate.
Step 3.2: Verify the HUB and SPOKE Tomcat Certificates
Once you have the HUB and SPOKE certificates downloaded, open those in side by side and compare the following. We have to perform a number of checks.
Check 1: Issued by
Go to the General tab of the Certificate and check the 'Issues by' field. This should be same in the HUB and SPOKE certificates. For this example, the certificate is issued by 'UCCOLLAB-CA'
Check 2: Enhanced Key Usage
Go to the Details tab of the certificate and check the 'Enhanced Key Usage' field. There should be 'Server Authentication' and 'Client Authentication'
Check 3: Certification Path
Go to 'Certification Path' and check the hierarchy. It should be similar on HUB and SPOKE.
Note: if there is an intermediate CA, you can see that is on the path. Make sure both HUB and SPOKE follows same certification path.
Step 3.3: Check the HUB Hostname & Certificate Common Name
Check 4: Server name and Common Name of HUB
Login to the HUB cluster Publisher CLI and check the Common name of the Publisher using 'show network cluster' command.
- Here the Publisher name is 01-01-CUCM01-PUB.uccollab1.com
- You have to see the same name on the HUB Publisher certificate Subject Name field CN.
- Open the Certificate and go to Details tab > Subject and check the CN - Common Name.
- In our case, it is matching to the above CLI output 01-01-CUCM01-PUB.uccollab1.com
Check 5: Server name and Common Name of SPOKE
Login to the SPOKE cluster Publisher CLI and check the Common name of the Publisher using 'show network cluster' command.
- Here the SPOKE Publisher name is 01-13-CUCM01-PUB
- Open the Certificate and go to Details tab > Subject and check the CN - Common Name.
- In our case, it is matching to the above CLI output, that is 01-13-CUCM01-PUB
Note: I do not have DSN server configured for SPOKE cluster. Hence we have only the hostname in the 'show network cluster' and in the 'Certificate'. If I would have configured DNS, this could have been an FQDN (refer the HUB certificate where I have DNS configured).
Step 3.4: Establish ILS Connection with Password Only and Populate the Peer-vector
Go to Advanced Features > ILS Configuration > and establish the ILS connection between HUB and SPOKE using password authentication method (already explained in Step 1.3, Step 1.4)
Once we have the ILS connection established, the Peer-vector table will populate automatically. Log in to the CLI of each publisher and issue 'utils ils showpeerinfo'. Make sure you have all the ILS peers in the output.
Step 3.5: Compare Peer-Vector Table with Subject Common Name
- Basically, we establish ILS initially with Password Authentication and then switch back to TLS only.
- Behind the scene, when we use the password to establish the ILS connection, the ILS node will update the peer-vector table, which is a DB Table that contains all the ILS peers information.
- Use 'utils ils showpeerinfo' CLI command to see the ILS peer table.
- Once we switch to TLS only (after establishing the ILS with password), the HUB will check the Common name of the Publisher in the Certificate to matches with peer-vector table Clustername.
- The peer-vector table was already populated with all peers when we used password authentication.
Check 6: Peer-vector Vs Common Name
Go to HUB cluster Publisher CLI and issue this command 'utils ils showpeerinfo' and check the 'Clustername' of SPOKE. This should match the Subject CN of SOPKE's certificate.
Go to SPOKE cluster Publisher CLI and issue this command 'utils ils showpeerinfo' and check the 'Clustername' of HUB. This should match the Subject CN of HUB's certificate.
Step 3.6: Switch Back to TLS Authentication
Once the peer-vector table is updated, we can remove the password authentication and use TLS authentication only.
Go to Advanced Features > ILS Configuration > Change the authentication back to 'Use TLS Certificate'
- We noticed that the ILS connection is remains established even after removing the Password Authentication.
- The 6 number of Checks are mandatory to have a successful ILS connection
- The remaining configurations like adding URIs, creating SIP Route Pattern, SIP Trunk and Speed dials (Step 1.6 to Step 1.10) is same as discussed above.
Note: Any time if the ILS connection is broken and if you want to re-establish, we need to do the same process again (first password and then TLS)
Comments to the Readers:
We have successfully done all possible ways of configuring ILS. If you are able to follow all the process explained above, there won't be any issues while configuring and troubleshooting ILS. I will be publishing a detailed ILS troubleshooting (with ILS traces and logs) article soon. Please rate this article if helped. Feel free to ask doubts.
Few of my other Support forum Documents:
You may also interested to take a look at my other articles in the support forum.
- Extension Mobility Cross Cluster (EMCC) - The Complete Configuration Guide
- Device Pool Selection in EMCC based on Geo Location
Regards,
Abdul Jaseem
8 Comments
