INFO - Reset SSH Public Keys to factory defaults INFO - Subscriber node entry added in publisherĮRROR - Setting up subscriber failed - attempting to recover and leave the node in a consistent state At the beginning it looked promising but now I ended up with this: I reverted the settings and dropped the Subscriber from the cluster to re-add it after the IP change. This also changed the IP on the Subscriber but kept the old one on my Publisher o_O After this I tried to do it the other way around and changed settings from the Publisher. The Publisher although remained stubborn and kept the old address of my Subscriber. This worked fine and I could reach the Publisher from the new IP address. Adjust configuration on the infrastructure I tried to follow the steps described in this Thread: Move two subscribers in two different branch offices to new subnets.
Going forward, when/if we need to change IPs, we will: IMO, this is backwards, as changing the IP breaks the communication that's required to have each node inform the other of the change. When changing the IP, it's evident that ClearPass first changes the IP and THEN it tries to establish PublisherSubscriber communication. 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. We moved the server to the port with the new network so it would have IP connectivity. At this point, communication between Publisher and Subscriber was broken, however, since the subscriber's IP had changed. However, the Publisher's dashboard via still reflected the old IP. We confirmed via console that the subscriber had the new IP on it. Via the Publisher, we changed the mgmt IP of the subscriber to the new network. Only then, while on the old network, were we able to rejoin it to the cluster and get back to square 1. We ended up physically moving the server back and then had to "drop subscriber" on the subscriber so it became a standalone node. 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.
This creates a catch22, as the old network was not available to the server any longer. The reason for this is that it needs to communicate with the Publisher in order change its IP. Via console/CLI, I issued the "configure ip mgmt." command, but to my surprise, it wasn't accepted. We disconnected a subscriber, moved it, and plugged it into a new switchport that had the new network's vlan. If you have a better way to do this, please reply to help your fellow wifi-er. I'm sharing that here so no one else struggles as I did. (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. We needed to move some of our subscribers from an old network to a new network.
0 kommentar(er)
