Jump to content
Welcome to our new Citrix community!

RPC node password update


Recommended Posts

GSLB is different as the ADC's participating are not in a synchronized config like an HA pair (or at least not an automatically synced config).  And rpcnode settings are not pushed as part of a gslb sync (which is a manual command anyway).

 

In an HA pair, with the way command propagation works, changing the rpcnode password for NodeA's NSIP address WILL result in in NodeA and NodeB's rpcdnode (for NSIPA) being updated BECAUSE propagation pushes the the command to the secondary first, acknowledges if it works, and then applies to primary (self).  If propagation failed, then a prop fail/triggerring sync event is noted. The command is then in place on Node A, but might need to be manually applied to Node B (but usually not a n issue). Then you can update the NSIPB rpcnode password from NodeA and rely on propagation to update both copies of the NSIPB rpcnode password on Node B and Node A.

 

However, when you change the rpcnode password or secure flag settings on rpcnodes participating in a GSLB config, command propagation isn't automatic in the GSLB Site partners (so location 1 (nodes A/B) and location 2 (nodes C/D)).  And if the location 1 pair is out of sync with location 2 pair, then the gslb sync command won't work anyway.

So assume in a GSLB config you will need to manually update the appropriate rpcNodes (gslb site IPs) in each HA pair separately.  Update location 1 (node A/B) and then location 2 (node c/d) seperately.

 

Then verify The HA pairs are happy A to B/B to A and C-to-D/D-to-C; and then verify GSLB to GSLB MEP is working between the ha pairs.

 

 

 

  • Like 1
Link to comment
Share on other sites

On 3/20/2020 at 8:01 AM, Rhonda Rowland1709152125 said:

GSLB is different as the ADC's participating are not in a synchronized config like an HA pair (or at least not an automatically synced config).  And rpcnode settings are not pushed as part of a gslb sync (which is a manual command anyway).

 

In an HA pair, with the way command propagation works, changing the rpcnode password for NodeA's NSIP address WILL result in in NodeA and NodeB's rpcdnode (for NSIPA) being updated BECAUSE propagation pushes the the command to the secondary first, acknowledges if it works, and then applies to primary (self).  If propagation failed, then a prop fail/triggerring sync event is noted. The command is then in place on Node A, but might need to be manually applied to Node B (but usually not a n issue). Then you can update the NSIPB rpcnode password from NodeA and rely on propagation to update both copies of the NSIPB rpcnode password on Node B and Node A.

 

However, when you change the rpcnode password or secure flag settings on rpcnodes participating in a GSLB config, command propagation isn't automatic in the GSLB Site partners (so location 1 (nodes A/B) and location 2 (nodes C/D)).  And if the location 1 pair is out of sync with location 2 pair, then the gslb sync command won't work anyway.

So assume in a GSLB config you will need to manually update the appropriate rpcNodes (gslb site IPs) in each HA pair separately.  Update location 1 (node A/B) and then location 2 (node c/d) seperately.

 

Then verify The HA pairs are happy A to B/B to A and C-to-D/D-to-C; and then verify GSLB to GSLB MEP is working between the ha pairs.

 

I was testing this recently with standalone GSLB nodes, but even if I changed the RPC node password on just one node, the GSLB status never went down. Found it a bit odd.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...