Question on the Service-module IP address

Answered Question
May 29th, 2012

I have what I hope is a simple question. I am in the process of configuring a UC560 and a UC540 for a 2-site company. Most of the administration will be done from site 1, which means I'll have to connect to site 2 using a VPN.

My question is, in order for CCA to work, does the service-module IP address have to be changed from its default on both units? I was planning on making site 1 and site 2

Does this fit in with best practice, or is this just over complicating things?

Correct Answer by Scott Martin about 4 years 8 months ago

Changing the service-module IP is not supported apparently, as it requires CLI, so you will find that Cisco will pull the pin on any support entitlement.

Sent from Cisco Technical Support iPad App

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
David Trad Tue, 05/29/2012 - 21:06

Hi Jared,

Simple answer for a simple question

Your assumption is correct, changing it to is perfectly fine, it is consistent too

Just on a side note, please make sure that CCA correctly modifies the loopback address as well, I have seen it miss this from time-to-time so just have a quick peek on the UC-540 that it does this.... Although you don't have to worry about this on the UC-560 as it uses VLAN-90 instead of a loopback



Jared Wesley Wed, 05/30/2012 - 11:48

Thank you for your help. Not to complicate things, but where in CCA Would I go to change this? I see that there are some "web sites" that are hosted in the UC on on the IP address of the service module (, as well as some ACL entries. Is there a clean way to change this in CCA without going through and making the changes with CLI?

David Trad Wed, 05/30/2012 - 16:42

Hi Jared,

Good question

Well my memory is getting bad in my old age (Or so my kids tell me ) but I believe this to be in the routing section, if you look in the navigation menu you should see it there (On the left hand side) and on the UC-560 you will see 3 VLAN's that are configurable, VLAN-1, VLAN-90 & VLAN-100 assuming they all remained as default, however on the UC-540 you will only see 2, VLAN-1 and VLAN-100 as the UC-540 uses loopbacks for the CUE module.

ON the UC-540 you will be changing VLAN-100 to the 10.1.20.X subnet, on the UC-560 it would be VLAN-90 (Well at least I think that's how it goes from memory ) Anyways once you see it, it should be self explanatory I hope



Scott Martin Sat, 06/02/2012 - 04:14

Oh and VLAN100 is the voice VLAN, not the service-module (CUE) IP address on UC540. You can change VLAN100 to your heart's content, however as I said, changing the module IP is not supported (although accomplished easily with some CLI and CUE config changes).

You will need the UC Express certification to get CLI support, which is being retired, not to be replaced, so frankly not sure where a partner is to turn for CLI support now.

Sent from Cisco Technical Support iPad App

David Trad Sat, 06/02/2012 - 05:07

Hi Scott,

On a UC-560 you should be able to change the service module IP using CCA,

but not on a UC-540/520bas they do not use VLAN-90 they use the loop back

method and direct IP on the module.

However SBSC should be able to assist with the module change even when you

don't have UCX certification, if they don't initially then ask for it to be

escalated, and don't stop until it does get escalated to a manager who will

make the right decision.


David Trad

"Sent from my Acer Iconia A500"

On Jun 2, 2012 9:14 PM, "smproductions" <

Scott Martin Sat, 06/02/2012 - 05:23

Hi David,

You are right, i was mistakenly referring to the UC540, not the UC560.

The support parameters are very cut and dry now, I'm not sure when you last called on them, however there is no escalation path for any CLI, and the new stance is that if the feature does not exist in CCA, you should consider the feature doesn't exist on the platform. I have had this direct from the product and support teams. Also if you make CLI changes, your configuration is unsupported in its entirety.

I am very disappointed with this specifically, as we have been doing this for a long time, since UC520 was launched, and had clients on TAC support without these issues. We often need to use CLI for some of the most basic of features which are lacking in CCA.

What is truly upsetting is that they haven't put key features in CCA, then leave you out in the cold when you return to CLI in desperation. We are now looking at dropping the product entirely.

Sent from Cisco Technical Support iPad App

David Trad Sat, 06/02/2012 - 05:34

Hi Scott,

Mate I hear your frustration, it was actually a driving factor for me to

move on and try other challenges in my career, absolutely love the product,

but simply can't stand the decisions that have been made since August of

last year.

But I will continue to help people out on these forums because I hate

seeing people struggle with the product, especially when you can do so much

with it.

"History has proven time and time again, the path you chose must be

reinforced by sound decisions, enforcing a particular policy must be backed

up by something that is either equal to or better than what you are


this forms part of any management decisions I make and what I tend to look

for with companies I work with.


David Trad

"Sent from my Acer Iconia A500"

On Jun 2, 2012 10:23 PM, "smproductions" <

Scott Martin Sat, 06/02/2012 - 05:59

Hi David,

Couldn't agree more, and glad that it's not just me. You and I both know how powerful this product is, such a shame it is restricted by a weak GUI tool and a sub-standard support structure.

I was told "this is because so many of our partners had problems and lacked the skills required", so it looks like the sales people have won in this instance, and it is now UC for dummies. It used to be you needed some skills to implement and maintain these systems, but it's clear Cisco just want to move more units.



Sent from Cisco Technical Support iPad App

Correct Answer
Scott Martin Sat, 06/02/2012 - 03:43

Changing the service-module IP is not supported apparently, as it requires CLI, so you will find that Cisco will pull the pin on any support entitlement.

Sent from Cisco Technical Support iPad App

danplacek Sat, 06/02/2012 - 12:46

I ran into this problem as well.

We had a new customer that had existing subnets that overlapped with CUE's.

Cisco told us there was absolutely no way they could support a change to the service module IP.

Their recommendation was to tell the customer to re-address their whole network.

We ended up doing some wierd stuff to work around this, but have since gotten UCX certified to bypass all this nonsense.

Honestly if you are pretty experienced, I'd recommend going for the cert -- it's not too difficult. (Compared to many of the other Cisco certs anyway.)

Scott Martin Sun, 06/03/2012 - 16:37

Hi Daniel,

I would happily, however it is being retired and I have a month before the cert is no longer attainable. Not sure I have the time to study up on the 'Cisco way' to do the exams in a month, only to then find the cert will be retired in the short term, not to be replaced by anything.



Jared Wesley Mon, 06/04/2012 - 05:58

Thank you everybody for the info. Cisco ended up telling me the same thing. I am curious though, how people manage to get around the situation I am in.

As I've said, there are 2 locations each with a UC500 device. We are going to be doing the majority of the UC administration from one location, so things like going to to upload a prompt, or even creating a user in CCA (Which interacts with CUE) will be challenging for the remote location (since all requests to will go to the local UC).

How would I get around this?

rowseyba1 Mon, 06/04/2012 - 06:20


Unfortunately, you would probably need to set up some sort of remote desktop connection to the other site.  From there you would be able to get to the local CUE from that computer. 

David Trad Mon, 06/04/2012 - 06:30

Hi Jared,

Well I guess you are going to have to bite the bullet, if the silly support

policy is not going to be flexible then you need to take matters in your

own hand.

The steps are as follows if you are willing to do CLI:

  • Session into the CUE module and change the IP address of the module, this

must be done first otherwise you will lock yourself out

  • Exit out of the session and get back to the CME command line, and proceed

to change the service module IP address

  • Make sure you change the Looback addresses as well, do not leave these as

the original ones

  • Go to your ACL and modify all CUE related entries to suit the new address

Do not write the memory on either the CUE or the CME until you know the

changes are completed and working.

Don't feel confident doing this yourself? Please engage a local partner and

get them to assist it will be much easier for you.


David Trad

"Sent from my Acer Iconia A500"

On Jun 4, 2012 10:58 PM, "jarednwesley" <

Scott Martin Mon, 06/04/2012 - 06:52

Pays to refresh your browser. What David said

Sent from Cisco Technical Support iPad App

Scott Martin Mon, 06/04/2012 - 06:57

Although David, I'm not sure you can 'lock yourself out', you can always access the service-module from the IOS using the service-module command which doesn't use IP as it functions like an internal interface.

Sent from Cisco Technical Support iPad App

David Trad Mon, 06/04/2012 - 07:02

Hi Scott,

Your actually right... its late at night and I'm a little sleep deprived at

the moment I probably should reserved my response until the morning.

And I forgot to also mention that you should also power cycle the unit in

order to make it stick properly, but that's just based on past experience.


David Trad

"Sent from my Acer Iconia A500"

On Jun 4, 2012 11:57 PM, "smproductions" <

Scott Martin Mon, 06/04/2012 - 07:19

I rarely power cycle, but fully rebooting the service-module after saving the config seems to do the trick for me.



P.S. sleep depravation is the cornerstone of the ICT industry

Sent from Cisco Technical Support iPad App

Scott Martin Mon, 06/04/2012 - 06:51

You could consider doing what I'm doing - change the CUE module IP (a few CME CLI changes plus a few changes in the CUE module config), then change it back if you need support.

There are some good articles on here about it, although the last one I looked at overlooked the CUE side of the configuration which is a critical component, so make sure you do both sides - CME & CUE config changes. I believe there is a good Cisco article on it.

I find the following process works pretty well:

1. Identify and update dial-peer config (order of this item doesn't matter)

2. Configure the loopback (UC540) or VLAN90 (UC560) interface ip address settings

3. Configure the service-module ip address and default gateway

4. Reboot the CUE service-module (after the ip change it will prompt you to do so in the CUE CLI)

5. Configure the CUE module to point to the new CME IP address (I like to use the CUE web interface for this part, but you can do it in CUE CLI also)

6. Synchronize your config in the CUE web interface

In case you miss something, dump out your CLI config into a text editor and do a find on the old IP address, sometimes one slips past the keeper. Update that and everything should work.

I could flesh this out with config, but where would be the fun in that?

Also after this config change, CCA continues to work happily, in fact you can now practically administer multiple UCs in the one CCA site once you do this. Don't tell Cisco.