We are testing the GET VPN scenario over the MPLS infrastructure by using 2 key servers. In the one of the key server, we defined the local priority greater than the other key server. The key servers among themselves choosed the higher priority defined key server as the primary.
In the group member configuration, we defined the key server addresses in the order of primary and secondary.
When we unplug the primary key server and all the members of that group registers with the secondary key server and when the primary key server came back, the member registration shows with the secondary key server. Is there a way like in HSRP to preempt to the primary key server.
Second thing is, when we unplug the secondary key server, the members who were registered to secondary key server still shows registration with that key server irrespective that key server goes down. Is that a normal thing ?
Kindly assist us.
Anantha Subramanian Natarajan
Registration typically only occurs when the router first joins the GET VPN domain. If you are running cooperative Key Servers, they are stateful and share all of their keys, members list, and policies. This allows them to failover dynamically so that the secondary key server resumes control until the primary restores without requiring another registration. A registration is used to secure the initial GDOI exhange and allow the remotes to received their intitial policy and encryption keys. All future communiction is done through either a unicast or multicast rekey message that makes refreshing the IPsec SAs a much more efficient process. In a failure scenario the secondary key server will detect a failure of the primary and send out rekey messages to maintain the IPsec SAs until the primary is restored. Once the primary is restored, the primary key server will resume control of sending the rekey messages. The registration process is much more process intensive, so when running cooperative key servers, the architecture is designed to avoid it from occuring. Who a group member last registered with does not impact the daily load on the key server given the infrequent time frames that it should be occuring. Secondly, the rekey messages themselves to preempt back to the primary key server.
hope this helps,