Security

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:

1. 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
2. (If applicable, shutdown and move server / recable as necessary)
3. Verify IP connectivity on new IP/network
4. 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!

Ouch, sounds like a bit of a pain.

Can't you just run drop subcriber, change the IP of the dropped sub, move to new location, run make subscriber, profit?

Probably, but what you outlined is 4 steps vs the 3 I outlined (if you exclude "verify" as a step). IMO, dropping/adding subscribers is a longer wait than running the IP reconfig a couple times.

In any case, probably multiple ways to do it, but changing an IP address isn't supposed to be so difficult. I figured I'd help others out with this post.

We will have to do this to the publisher, too, and for that, I anticipate having to first promote a subscriber as a temporary publisher before executing the same process, followed by repromoting the old publisher.

This may works if you have physical box. But what if you have VM. I have hard time to change mgmt ip address. Not sure how to approach this. Yes, there are may be ways to reconfigure ESXi but it MUST be way to change mgmt IP address via console access.

Actually there is a way to change mgmt ip address from the console. I reset something. Some parameter. Do not know exactly what.

I am very knew to Clear Pass. Baby steps.

So, then reboot. After this did this command. It did not produce any errors (finally!).

configure ip mgmt 10.10.0.104 netmask 255.255.255.0 gateway 10.10.0.1

Then system ran via reset itself and BINGO! Here IP i need.

So, all in all, if you know what you doing then the task is fast and trivial.

Migrated my subscriber then publisher to a new network using this method. Thanks!

Cli to Subsciber, Changed Mgmt IP, Changed switchport vlan, Verify in Publisher it updated and synced. 

Cli to Publisher, Changed Mgmt IP, Changed switchport vlan, Verify in Publisher it updated and synced. 

You will need to remove any VIPs before doing and rebuild once migrated.

Hey guys,

I had to do today exactly the same. Move two subscribers in two different branch offices to new subnets.

I tried to follow the steps described in this Thread:

- Change IP settings on the Subscriber

- Adjust configuration on the infrastructure

- Change IP again on the Subscriber. 

This worked fine and I could reach the Publisher from the new IP address. The Publisher although remained stubborn and kept the old address of my Subscriber. After this I tried to do it the other way around and changed settings from the Publisher. This also changed the IP on the Subscriber but kept the old one on my Publisher o_O

I reverted the settings and dropped the Subscriber from the cluster to re-add it after the IP change. At the beginning it looked promising but now I ended up with this:

INFO - Subscriber node entry added in publisher
ERROR - Setting up subscriber failed - attempting to recover and leave the node in a consistent state
INFO - Stopping all services
INFO - Force reset database. This may take a while...
INFO - Reset SSH Public Keys to factory defaults
INFO - Starting all services
INFO - Reset database complete
INFO - Restarting Policy Manager admin server
ERROR - Setting up subscriber failed. The local database has been reset
ERROR - The node may have been added to the publisher database - manually drop the node from publisher
ERROR - Please fix the problems and retry this operation
ERROR - Setting up subscriber failed

On publisher side i get this in the Event Viewer:

Any suggestions? My next steps would be:

- Drop the Subscriber one more time. 

- Reset the database

- Re-add it one more time

I'm running CP on 6.7.9.109195. The publisher is a C2000, the subscriber a C1000 appliance.

Cheers
Arthur