Changing incorrect subnet & default gateway on UCM servers

[Jan Gilhooley]

Hi,

A weird one - all our UCM servers actually have the wrong subnet and default gateway. Original the UCM servers were in a class C subnet which was subsequently subnetted to a /26 range but neither the subnet and gateway were changed to reflect the new /26 range. It all works because the core switch is doing proxy arp.

The question is - can we change just the subnet & gateways to the correct ones with no impact or risk to the UCM servers? We don't want to change the IP addresses themselves (they are just fine :-)).

I've heard various things about messing with the IP settings being a bad idea - usually for changing the IP address itself, but if we could sort this IP stuff out (safely) it would give us some more options for our migration to UCM 14.0 (we are on 11.0).

Thanks

[Jonathan Schulenberg]

The command to change platform details like this executes a Bash/shell script. There have been bugs with that over the years, thus the stories.

The risk, in your case, is that CUCM 11.0 is past end of support; you can’t call TAC if it goes sideways.

https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-communications-manager-callmanager/eos-eol-notice-c51-738520.html

If I had to do this, I would:

• Shutdown the VM down, create a snapshot, power it up, and wait for services to start.
• Set SELinux to permissive mode - a common cause of this failing historically.
• Make the change, one node at a time.
• Reboot the node
• Ensure DbReplication is good, the connectivity test command succeeds from other nodes, and that there are no alarms in RTMT after all services start.
• Shutdown the VM, delete the snapshot - IMPORTANT - and then start it back up.
• Verify that SELinux returned to enforce at next boot. If not, change it back to enforce.

[Elliot Dierksen]

If you change the subnet mask and/or the default gateway, that will change your license MAC. If you have a separate PLM/ELM, that isn't a big deal. If the PLM/ELM is on the same host, that would cause your licenses to get invalidated. See this forum post that talks about how the license MAC is generated.

https://community.cisco.com/t5/unified-communications-infrastructure/licensing-carification-re-license-mac/td-p/1834697 

[Jaime Valencia]

Nothing of what you posted is applicable, licensing MAC stopped being used on 9.x when ELM was introduced, and ELM/PLM are tied to the MAC from the server, the actual MAC that is defined when creating the VM, that's why the guides state you should use a static MAC and not a dynamic MAC. 

Select the Manual option and enter a unique MAC address.

For a standalone installation of Cisco Prime License Manager, only static MAC addresses are supported on the virtual machine.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/plm/11_5_1_SU2/userguide/cplm_b_user-guide-1151su2/cplm_b_user-guide-1151su2_chapter_01.html

[Jonathan Schulenberg]

Nice catch Jaime; thanks for chiming in!

[Jan Gilhooley]

Thanks for the replies - I think that does reinforce what our third party has been saying. The aim is to move to 14.0 and it was recommended to build new UCM hosts with new (correct) IP addressing to avoid the pain of changing the subnet/gateway on the current hosts.

I was hoping that it was simply a case of changing in the OSAdmin WebUI

Interesting that comment about the license - our PLM does currently run on the same host as our Publisher. So changing even the subnet/gateway would be a "bad thing" I guess.

[Jonathan Schulenberg]

The platform details (e.g. hostname, IP addressing, NTP, DNS, etc.) are hashed into a twelve character hexadecimal value that looks like a MAC address; touching any of them changes the hash. It was the least painful idea they had when migrating from bare metal to virtual. That no longer matters in 12.0+ because PLM is replaced by Smart Licensing.