As you learned in the previous blog that introduced the GET VPN solution, a major facet of this exciting technology is the Group Domain of Interpretation (GDOI) as outlined in RFC 3547. This technology is such a pivotal component of GET VPN because it serves as the mechanisms to provide the cryptographic keys to a group of VPN gateways.

GDOI relies on none other than Internet Key Exchange (IKE) Phase 1 to protect the distribution of the keys. Just as with “traditional” IPSec VPNs, you can utilize such methods as Pre-shared Keys (PSK) or the Public Key Infrastructure (PKI) for authentication with IKE Phase 1.

GDOI actually implements two different encryption keys. The Key Encryption Key (KEK) is used to secure the control plane, while the key used for data encryption is the Traffic Encryption Key (TEK).

Another critical element for the GET VPN is the Key Server (KS). This is the IOS device responsible for creating the GET VPN control plane. The KS is where you actually define the encryption policy (interesting traffic, encryption protocol, etc.) that is pushed to all group members.

Group members in GET VPN are the IOS routers responsible for the actual encryption and decryption of data traffic.

Another excellent aspect of GET VPN is the rekey process built into GDOI. GDOI periodically refreshes cryptographic keying information and distributes it to group members. GDIO has the ability to send rekey messages as unicast or multicast in the network infrastructure.

Obviously, if the Key Server fails, the GET VPN implementation is in big trouble. To help ensure availability of the solution, cooperative Key Servers (COOP KSs) provide redundancy. Under COOP, one of your KSs serves as the primary Key Server, while other KSs are the secondary devices. Messaging between the KSs ensure a failover election occurs if a downing of the primary device is detected through the lack of primary device messages.

Stay tuned to the blog for more information on the GET VPN, including basic configurations.

You can leave a response, or trackback from your own site.

10 Responses to “Exploring GET VPN Technologies”

  1. Gazzaz says:


    You are helping me a lot with my studies.

    Thank you and keep up the good work.

  2. Lessons says:

    Is there a way to locate someone locally to try this?

  3. Aleksandr Okonnikov says:


    Key Server cannot be Group Member simultaneously. Dedicated router have to exist for the enabling GET VPN and this router cannot make encryption/decryption of data traffic. Is it true?

    • Yeah, the KS plays dedicated role in GET VPN implementation and it should be a standalone router. It is possible to use a certain hack to implement GET VPN using just two routers, but this not a recommended design.

  4. Darren Collinson says:

    Hi Petr,

    Not sure if you’re still monitoring this post, but I am very intrigued about how to implement the hack to have GETVPN working with just 2 routers.

    I fully appreciate this isn’t in any way recommended, but I would appreciate it if you could let me know how to achieve this hack.

    Hope you can help.



  5. @Darren,

    have the configs somewhere around, can’t find them quick; here is the idea: you run the two routers in COOP mode and configure every as server. Every router registers to another configured as a key server, which is perfectly legal. The COOP mode allows the routers to synchronize keying information. In effect, there is no need for a standalone KS, but rather two routers work as a single COOP KS, registering to each other.

  6. Darren Collinson says:

    Thnaks Petr,

    Think I get the idea. So each KS is a GM of the other KS, and the KSs act in COOP mode. Or am I on the wrong path thinking of making a KS the GM of the other COOP KS?

    The only change required, that I can see, is to create and apply the crypto map to the external interface. Would this work with just one KS – i.e. the crypto map points to itself using ‘server local’ in the cypto gdoi group?

    I suppose the best way to find out is to give it a try.

    If you do come across the configs I’d appreciate it if you could show me the relevant sections that got it to work.



  7. Jay says:

    Hi all,

    I have configured the GETVPN using three routers. But I am having a problem. My GMs are unable to ping the KS. Both the GMs are going through the KS and accessing each other but are unable to access or PING the KS. Is it normal or did I miss something or did some configuration error?

    Any help is appreciated.

    - Jay

  8. Ganesh Palav says:


    I have created GETVPN but i am able to ping KS from all GM but not able to ping GM to GM LAN n/w.

    Kindly suggest the way forward.

    Ganesh Palav

  9. kasun says:


    I have tested coop servers using 2901 router, and 1941 router, i configured primary as 2901 router. But all the group members are register with secondary KS. (check by using #show crypto isakmp sa, command)

    Is there a command to clear all group members gdoi setting from KS globaly. (From group member issue #clear crypto gdoi, Need command from KS, global for all group members) .

    Hope you can help in this two issues.

    Thanks & Regards,


Leave a Reply


CCIE Bloggers