Solved: GET VPN key server

anasubra_2 · ‎09-19-2007

Hi All,

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.

Thanking You

Regards

Anantha Subramanian Natarajan

gjstem · ‎09-23-2007

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,

Greg

View solution in original post

gjstem · ‎09-23-2007

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,

Greg

anasubra_2 · ‎09-23-2007

Hi Greg,

Thank you very much for the clarification.

Regards

Anantha Subramanian Natarajan

Gopi krishnan · ‎09-19-2012

I am also facing the above mentioned issue with GETVP. The following things are happening with our GETVPN configuration.

When the primary goes down, the group members will join to secondary and it will download ACL for the matching traffics from the secondary KS. When the primary comes back, all the group members will again download the ACL from the primary, but the GDOI status shows tha it is still registered to the secondary itself.

So the issue that we are facing is that even the group members are downloading the ACL from the primary KS after a failover, in the GDOI status it is still showing that the group members are registered to the secondary KS.