We needed to move some of our subscribers from an old network to a new network. (In this case, the Publisher was/is on a different network.) Contrary to my belief that changing an IP address should be a trivial thing, it turned out to be a bit of an adventure to figure out exactly what order of events had to happen. I'm sharing that here so no one else struggles as I did. If you have a better way to do this, please reply to help your fellow wifi-er.
Failure #1:
We disconnected a subscriber, moved it, and plugged it into a new switchport that had the new network's vlan. Via console/CLI, I issued the "configure ip mgmt..." command, but to my surprise, it wasn't accepted. The reason for this is that it needs to communicate with the Publisher in order change its IP. This creates a catch22, as the old network was not available to the server any longer. We tried removing the subscriber from the publisher, but that got us in a worse state, as the subscriber still thought it was part of the cluster.
We ended up physically moving the server back and then had to "drop subscriber" on the subscriber so it became a standalone node. Only then, while on the old network, were we able to rejoin it to the cluster and get back to square 1.
Failure #2:
Via the Publisher, we changed the mgmt IP of the subscriber to the new network. We confirmed via console that the subscriber had the new IP on it. However, the Publisher's dashboard via still reflected the old IP. At this point, communication between Publisher and Subscriber was broken, however, since the subscriber's IP had changed.
Success:
We moved the server to the port with the new network so it would have IP connectivity. We then issued the "configure ip mgmt..." CLI command, which this time around succeeded, as the subscriber (on the new network) had IP connectivity and could reach the Publisher.
Summary:
When changing the IP, it's evident that ClearPass first changes the IP and THEN it tries to establish Publisher<->Subscriber communication. IMO, this is backwards, as changing the IP breaks the communication that's required to have each node inform the other of the change.
Going forward, when/if we need to change IPs, we will:
- Console/CLI to the subscriber and issue the "configure ip mgmt..." command. The IP will change but communication to the Publisher will fail. An error will be displayed
- (If applicable, shutdown and move server / recable as necessary)
- Verify IP connectivity on new IP/network
- Re-issue the "configure ip mgmt..." command, which should succeed so long as the Subscriber can communicate to the Publisher on the new IP/network.
I hope this helps someone!