UC upgrade 11.0 to 11.5 - cannot change subnet mask format as directed by documentation.

[Knowlesy14]

Hi!

I'm upgrading a UC environment from 11.0 to 11.5. One of the pre-upgrade tasks is to ensure the subnet mask is in the recommended format for /24.

"If you are using a 24-bit IP subnet mask, ensure that you use the following format:255.255.255.0. Do not use the format 255.255.255.000. Although 255.255.255.000 is a valid format, it may cause problems during the upgrade process. We recommend that you change the format before you begin an upgrade to avoid possible problems. You can change the subnet mask by executing the set network ip eth0 <server_IP_address> 255.255.255.0 command. Other formats are supported for subnet masks and this limitation applies to 24-bit subnet masks only."

I have entered the command as described above but am running into the following message...

admin:set network ip eth0 10.*.*.* 255.255.255.0
Required 3 mandatory parameter(s) but 2 parameter(s) were found

Executed command unsuccessfully
Error executing command

I also tried add the GW address to the command too and get this output of no change was made...

No modfication: --ipaddr 10.*.*.* --old_ipaddr 10.*.*.*

Trying to avoid any potential for problems during the upgrade process and this subnet mask issue appears to be a known one that can cause the upgrade to fail. Any advice is greatly appreciated.

Thanks,

Mark

[Jaime Valencia]

Do you actually use a /24 mask???

If not, that's not even applicable to you.

To clarify, that doesn't mean that you're forced to change whatever mask you're using to a /24 for this to work.

If you have a /24, and you entered the last octect as .000 that might cause issues and that's why you should change it to .0

[Knowlesy14]

Thanks Jaime.

Yes, I recently inherited this environment and it's currently configured for /24 mask with .000 format in the last octet. So I believe I do need to rectify this before proceeding with the upgrade.

When I enter the command set network ip eth0 <*.*.*.*> 255.255.255.0 as directed by the upgrade documentation, I get...

Required 3 mandatory parameter(s) but 2 parameter(s) were found

Executed command unsuccessfully
Error executing command

So I add the GW address to the command too but since the IP address is staying the same the change doesn't take...

admin:set network ip eth0 <*.*.*.*>  255.255.255.0 <GW IP>
*** W A R N I N G ***
This command will restart system services
=======================================================
Note: Please verify that the new ip address is unique
across the cluster and, if DNS services are
utilized, any DNS configuration is completed
before proceeding.
=======================================================

Continue (y/n)?y
No modfication: --ipaddr 10.19.121.61 --old_ipaddr 10.19.121.61

trying to restart network...

Unless there's a workaround to change just the subnet mask format, I'm thinking I'll change to IP address to something different temporarily to see if it accepts the mask format, before then changing it back to the original IP. 

Thanks,

Mark

[Knowlesy14]

I changed to a different IP and configured the subnet mask in the appropriate format (255.255.255.0) but it's still showing up incorrectly. 255.255.255.000 - annoying!

Guess I'm making a TAC.

[Jaime Valencia]

My best guess is that you actually need to change the /24 to something else, and then go back to the /24 with .0 for that to work.

That might cause some issues in the network, but TAC can confirm if that's the only way to do that change.

[Maren Mahoney]

It may help to set the status of the network to "down" before making the change.

set network status eth0 down

[RAustin70]

I'm experiencing this exact issue tonight as I prepare to do a Direct Standard Upgrade from 11.5(1) to 11.5(1)SU6

I built this system back in 2017 and I set the mask to 255.255.255.0, but tonight when I "show network eth0" it shows me 255.255.255.000

When I tried to change it, it gives me the same error as you.  What did you end up doing?  Did you just push through with the upgrade?

Rob

[Maren Mahoney]

I have done upgrades on a couple of systems with a /24 mask in this format and did not have a problem. Cisco's documentation says it "may" cause a problem, which means that it is not a hard pre-upgrade requirement.

I'd say "go" and remember that you can always roll-back to your pre-upgrade partition if needed. Good luck and let us know how it goes.

Maren

[RAustin70]

Thank you Maren!  Yes, I went for it.  Pub went great, then all 4 Subs failed.  2 Hours with Cisco TAC on the phone got me nowhere last night.  Did some research on my own and found out that somehow the IPSEC connections between my upgraded (but inactive) Publisher and the Subs and CUP servers all broke.  Yaay me lol.

Waiting on a Callback to work on a plan to either reboot the Pub with fingers crossed, drop the IPSEC policies, Plan C, etc.

The ONLY words on IPSEC in the Upgrade and Migration Guide are for moving up to 11.5(1)SU6 from Release 6.5(1) lol.  Some days I really dislike Cisco haha

As for the Subnet Mask, I found it pretty frustrating that the CLI shows 255.255.255.000 BUT the GUI on all the Nodes show 255.255.255.0 just like I built them back in ‘17

Rob

[Maren Mahoney]

Ouch! I'm sorry the upgrade went so poorly. I don't have advice with regards to IPSEC on your systems so I'll stay out of that part of the conversation. Hopefully one of the other smart folks on the forums may have some advice. Good luck and keep us posted if you do find a solution. (You might be surprised at how many folks read these threads when they are troubleshooting. Your answer might help someone else one day.)

Maren

[RAustin70]

Check this out.  Just got this from one of my Collab CCIE Buddies:

"There is a bug that started somewhere is 11.5 in which Red Hat stopped supporting OpenSwan (IPSec). Cisco didn’t catch this until 12.x and continued to use it after the support ended. This was fixed on 12.x with Libreswan. The bug ID is CSCvc16004. This was supposed the be back channeled into 11.5 to be fixed but I have not seen if this happened or not. The effects of this issue are intermittent, meaning we have customers on 11.5 with IPSec enable without issue, while others have some wonky things going on"