Reset Search



KB44735 - Changing the network subnet on Services Director prevents it starting after a later reboot

« Go Back


Last Modified Date3/9/2021 8:16 AM
Changing the network subnet (e.g. to expand it) on Services Director with these commands
> en
# conf t
# configuration jump-start

appears to be successful but then later the service will not start up after a reboot, causing an outage.
Problem or Goal
After changing the subnet, then after a reboot (including after an upgrade), the ssc service is not running and there are these log messages in /var/log/messages:
Mar  3 17:42:25 <hostname> pm[2714]: [pm.WARNING]: TIP is not raised correctly,
Mar  3 17:42:25 <hostname> pm[2714]: [pm.NOTICE]: Not starting disallowed process ssc.

Note that in this state, existing vTMs go into the 6 week grade period and remain licensed for that time.
The cause of this is an incorrect internal configuration within SD.  When initially configured by the customer, SD configures and raises the Service Endpoint Address (SEA, which is a Traffic IP handled by an instance of vTM within SD) inside an unnecessary TrafficIP Network.  This TrafficIP Network is not updated when the subnet of the SD is changed.  Because the subnet of this TrafficIP Network no longer matches the SD machine's subnet, SD then incorrectly thinks the TIP isn't raised, when it is, and requires the TIP to be raised before starting up the ssc process.
The solution is to erase the incorrect configuration of the TrafficIP Network, which works because the default behaviour without TIP Networks is to raise the TIP in the same subnet as the machine's subnet.  To do this, login via ssh and run these commands:
> en
# _shell
[root@<hostname> ~]# ip a 
(this is to check the current networking, and to verify the SEA's subnet doesn't match the base IP's subnet)
[root@<hostname> ~]# /var/opt/zeus-17.2r1/zxtm/bin/zcli  <<< TrafficIPGroups.deleteSubnetMappings
[root@<hostname> ~]# ip a 
(this should show the SEA/TIPs subnet now matches the base IP's.)

This workaround can be done before or after changing the SD's subnet with the configuration jump-start command, and before the next reboot.

If you are in the situation where you have rebooted and it's not starting up, then after running the above, also run these cli commands to force the ssc process to restart:
> en
# pm process ssc terminate
# pm process ssc restart

SD-14154 has been raised for this issue, if you hit this issue and use this article to solve it, then please raise a support case or talk to your account manager to register your interest in having this fixed.
Related Links
Attachment 1 
Created ByLaurence Darby



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255