SD-WAN vManage change IP on vpn0

[hawaii]

Hi, Im trying to change my architecture of controlers, and I need to change IP address of vpn0. Its on-premise deployment.
I tried do it from few perspectives, and it ends it always same way.

I have ony only one vmange, so aint have cluster. Didnt find any way do change it from gui, so changing from cli, ends with this state. 192.168.252.170 its old IP. 

Request nms application-server diagnostics

NMS application server
Checking cluster connectivity...
Pinging server 0 on 192.168.252.170:8443,8080...
Starting Nping 0.6.47 ( http://nmap.org/nping ) at 2019-03-26 15:23 CET
libnsock mksock_bind_addr(): Bind to 192.168.252.170:0 failed (IOD #1): Cannot assign requested address (99)
SENT (0.0013s) Starting TCP Handshake > 192.168.252.170:8080
libnsock mksock_bind_addr(): Bind to 192.168.252.170:0 failed (IOD #2): Cannot assign requested address (99)
SENT (1.0029s) Starting TCP Handshake > 192.168.252.170:8443
libnsock mksock_bind_addr(): Bind to 192.168.252.170:0 failed (IOD #3): Cannot assign requested address (99)
SENT (2.0043s) Starting TCP Handshake > 192.168.252.170:8080
libnsock mksock_bind_addr(): Bind to 192.168.252.170:0 failed (IOD #4): Cannot assign requested address (99)
SENT (3.0064s) Starting TCP Handshake > 192.168.252.170:8443
libnsock mksock_bind_addr(): Bind to 192.168.252.170:0 failed (IOD #5): Cannot assign requested address (99)
libnsock mksock_bind_addr(): Bind to 192.168.252.170:0 failed (IOD #6): Cannot assign requested address (99)
SENT (4.0075s) Starting TCP Handshake > 192.168.252.170:8080
SENT (5.0083s) Starting TCP Handshake > 192.168.252.170:8443

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
TCP connection attempts: 6 | Successful connections: 0 | Failed: 6 (100.00%)
Nping done: 1 IP address pinged in 6.01 seconds

Disk I/O statistics for vManage storage
---------------------------------------
avg-cpu: %user %nice %system %iowait %steal %idle
9.21 0.00 1.67 0.33 0.00 88.78

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
hdb 5.99 136.36 104.32 470530 359944

So it looks like he didnt change it in some configuration files. 

[hawaii]

Im confussed. I have done request reset configuration and after auto reboot, configuration file are empty, but when I ran again request nms application-server diagnostics it refer to this 192.168.252.170 IP address again. 

Oh and I didnt mention that cpu processor hits 100% all the time after changing IP from CLI. So is there any solution for this issue different than new deployment? vManage 18.4.1

[Egista Hadi Putranto]

Hi,

I was have same problem, vManage high CPU after i change the whole configuration without delete the Cluster member, here is the diagnostic

libnsock mksock_bind_addr(): Bind to 192.168.100.13:0 failed (IOD #1): Cannot assign requested address (99)
RCVD (0.0013s) Possible TCP RST received from 192.168.100.14:8080 --> Network is unreachable
SENT (0.0013s) Starting TCP Handshake > 192.168.100.14:8080
libnsock mksock_bind_addr(): Bind to 192.168.100.13:0 failed (IOD #2): Cannot assign requested address (99)
RCVD (1.0028s) Possible TCP RST received from 192.168.100.14:8443 --> Network is unreachable
SENT (1.0028s) Starting TCP Handshake > 192.168.100.14:8443
libnsock mksock_bind_addr(): Bind to 192.168.100.13:0 failed (IOD #3): Cannot assign requested address (99)
RCVD (2.0039s) Possible TCP RST received from 192.168.100.14:8080 --> Network is unreachable
SENT (2.0039s) Starting TCP Handshake > 192.168.100.14:8080
libnsock mksock_bind_addr(): Bind to 192.168.100.13:0 failed (IOD #4): Cannot assign requested address (99)
RCVD (3.0049s) Possible TCP RST received from 192.168.100.14:8443 --> Network is unreachable
libnsock mksock_bind_addr(): Bind to 192.168.100.13:0 failed (IOD #5): Cannot assign requested address (99)
SENT (3.0050s) Starting TCP Handshake > 192.168.100.14:8443
RCVD (4.0060s) Possible TCP RST received from 192.168.100.14:8080 --> Network is unreachable
SENT (4.0061s) Starting TCP Handshake > 192.168.100.14:8080

Same like you i've tried request reset configuration, but the problem still persist.

But the problem solved after i did request software reset

maybe this link will usefull for operational https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/operational-cmd.html#wp3917326730

Hope the solution will work in your case

~egista

[pgasparovic]

Hi folks,
being one of latest in world to tackle this issue like you did before (no high CPU load), I wanted to avoid risk of losing certificate (though it's much more direct today than was in the past) and got vendor's concept a bit why the sole CLI change can't be that straightforward and is GUI driven, by reading their fast-to-grab (besides any CiscoLive/whichever_tech_session) content at Configure the Cluster IP Address of a Cisco vManage Server. My assumption is that whole infra was built with clustering in mind, "all the processes" coded around it, so yes, VPN0 is the pillar of it and 100% sensitive to any change. In their doc there was notion of "out-of-band" role, which just confuses the understanding why it's not VPN 512 instead...

My task was to change VLAN/IP address for tunnel interface, moving that oob "cluster" address to real VPN512, however doing any CLI change just brought down the vManage access (covered by application server). So:

1) you need to have at least 2 ifaces in VPN0, if not, power down vManage VM, add new vNIC and power up.

2) I changed in CLI that tunnel address to new one, only this.

3) I changed the cluster IP address in GUI to it, as per vendor's doc --> approved to reboot (some part of of vManage as it was quick)

4) issued that "request ... diag" command to prove it works

5) finished overall change in CLI by moving my oob interface to VPN512 (host-side ESXI too), re-made that VPN0 critical interface both in guest and host, commit - and all done, without VM restart!

6) Formal VM reboot - worked. Though GUI let's you wait pretty long like usual.

HTH, BR

Peter