Unanswered Question
Jun 15th, 2007

Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss with Cisco expert Haseeb Niazi about Cisco GET which is a revolutionary WAN security technology that defines a new category of VPN, one that does not use tunnels. Haseeb is a solutions engineer at Cisco Systems Inc. with over seven years of experience with various security related solutions including Network Based Security Services, DMVPN and GET VPN. He holds a masters degree in computer engineering. He has presented to both internal and external audiences at various conferences and has represented Cisco in a number of customer events.

Remember to use the rating system to let Haseeb know if you have received an adequate response.

Haseeb might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through June 29, 2007. Visit this forum often to view responses to your questions and the questions of other community members.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.6 (6 ratings)
hniazi Mon, 06/18/2007 - 17:30

Short answer: customers have started deploying GET VPN.

To provide some more detail, various GET VPN deployments are in three different phases right now:

a) customers are evaluating GET, talking to account teams and polling various technical resources

b) customers have finished their evaluation and are verifying functionality in the lab

c) customer have successfully deployed GET VPN pilot projects and are expanding their install base.

While most of the customers are in phases a) and b), there are quite a few customers who have certified the technology and are in process of deploying GET VPN on a larger scale.

joe-vieira Tue, 06/19/2007 - 07:16

Presently we have a secure MPLS network encrypted with another vendor's firewall connecting between our network and the provider's MPLS network. While it hasn't worked out too bad it could be better and I am wondering if GET VPN is a replacement for this. Do you have transition documents available and white papers?


hniazi Tue, 06/19/2007 - 15:16

You are thinking on the right lines. GET VPN is the solution to encrypt traffic over MPLS networks without losing the ability to support QoS, traffic engineering and replicate multicast in the core without overloaying a VPN on your existing infrastructure. You can evaluate the solution by looking at the documentation:

If the solution seems to fit your needs and you have further questions after going through the documentation, please let me know.



fmeetz Mon, 06/18/2007 - 20:45

Haseeb- Thanks for being available to answer our questions.

I'm wondering. Can you explain why Cisco decided to move to a time based anti-replay instead of the traditional counter based anti-replay?


hniazi Tue, 06/19/2007 - 09:09


Unlike traditional IPsec solutions, we do not create pair-wise IPsec SAs between two spokes. This limits our ability to track counters on per-sender basis. If we only had a single sender and multiple receivers, we could use the counter bases anti-replay just fine. Since GET VPN supports multiple senders we needed some other mechanism to track whether a packet was replayed. This is the reason time based anti-replay was introduces. All the group members (and key server) maintain a pseudo time and there is no requirement for traditional router time synchronization (NTP).



nedian123 Mon, 06/18/2007 - 23:05

Dear Haseeb,

Could you please let me know Hardware/IOS requirement for GET VPN to be deployed.



hniazi Tue, 06/19/2007 - 09:02

GET VPN can be deployed on all the ISR platforms (871-3800s) and 7200/7301 (VAM2+). Support for 7200 G2/VSA is chalked out for near future.

You need atleast 12.4(11)T on the routers. 12.4(11)T2 is preferred.



JHaynes4 Tue, 06/19/2007 - 10:36

Hi Haseeb,

I have read about Cisco GET VPN in the new features section of release 12.4(11)T. I don't see in the examples any use of EIGRP in an MPLS situation. Does you know if this is supported? I am specifically looking to see if there can be any to any connectivity amongst our remote sites using EIGRP to dynamically learn routes with GET enabled. If it is supported does it require all neighbors to be defined, or will the neighbors be learned automatically as they would on the same LAN segment?

hniazi Tue, 06/19/2007 - 15:34

One of the biggest advantages of the GET VPN solution is the fact that there is no need to define ipsec peers. Lets take an example:


MPLS network already provides you routing capability to route traffic from NET_A to NET_B. In your case, this connectivity is provided by EIGRP. In some other cases, the routing protocol used could be OSPF or BGP.

In case of GET VPN, CE1 and CE2 are group members which download encryption material and policies (same keys) from the key server. The encryption policies on the KS will be defined something as follows:

do not encrypt EIGRP

do not encrypt ISAKMP

do not encrypt

ENCRYPT everything else

When traffic needs to go from NET_A to NET_B, CE1 encrypts it (policy stated encrypt e'thing) and MPLS routing forwards the packet to CE2. CE2 decrypts the traffic and forwards it to NET_B. Since both CE1 and CE2 share the same keys and policies, decryption is not a problem.

As you see, there was no need to define peers and there wass no need to overlay another routing protocol. We can use any routing protocols we want.

For further info:



JHaynes4 Wed, 06/20/2007 - 04:39

Thank you Haseeb. This was the information I was looknig for.

bob.bartlett Tue, 06/19/2007 - 10:53

Will GET VPN be supported on the ASA platform as well or is this going to be like DMVPN a Router only feature?

hniazi Tue, 06/19/2007 - 15:36

GET VPN will only be supported on IOS platforms like DMVPN. There are no plans of support on ASA as of right now.



hniazi Wed, 06/20/2007 - 05:44

Good news is there are plans to support GET VPN on 6500. Not so good news is the support will not be available till end of 08 or beginning of 09.

On a related note, 7200 G2/VSA support will be avaiable towards the end of this year (1st T release of 12.5). VSA does not perform as good as 6500 but provides much better throughput than a VAM2+. This can be an option for customers requiring high throughput.



dondongamo Wed, 06/20/2007 - 02:43


We have already suggested this technology to one our client but I have some clarifications.

a) If we will deploy a redundant key server, will this require a license?

b) For a redundant group-member router, will the traffic be interrupted assuming the standby router will take over? Does the gdoi sa has to be rekeyed?

Appreciate your input on this. TIA.

hniazi Wed, 06/20/2007 - 05:54

a) Key Server is just another IOS crypto box (ISRs or 7200/7301). As long as you have the right image loaded, you do not need a separate license.

b) GDOI does not support HSRP virtual IP (like traditional IPsec) to register to the KS. What this means is that primary and secondary GMs will have to register to the key server individually and we can not run HSRP on the WAN (MPLS) side. Once both the GMs get the IPsec keys, the keys will automatically be refreshed and kept up to date by the KS. HSRP will have to run on the inside interfaces (towards the internal network). If primary GM fails, secondary will take over the HSRP address (inside network) and traffic will flow w/o disruption.

Please let me know if you need further explanation.



dondongamo Wed, 06/20/2007 - 23:44

We have a requirement were downtime has to be minimized or better if we can achieved zero downtime at all (real-time application 24X7), why we have suggested a redundant GMs & a redundant KS on DR. There's a redundant link on the WAN side and runs on dynamic routing, presently we are thinking of OSPF over GRE, HSRP will be on the LAN side only. The environment is a hub & 15 spoke sites and the traffic should be bet hub & spoke but NOT bet spoke sites.

For redundant KS, does the RSA key has to be generated on both KS. Pls clarify this.

Further suggestions/recommendations are highly appreciated. Thanks.

hniazi Thu, 06/21/2007 - 08:13

Is this right picture of your branch?



If I understand correctly, you are saying if WAN1 or WAN2 goes down, HSRP will failover to other box and we will not lose connectivity. Right?

Are you using the GRE because you want to restrict the traffic between hub and spokes?

If the network does not need to grow beyond these 15 sites, a part of me says why even go with GET VPN? why not use DMVPN OR plain old IPSec+GRE tunnels? You will not need redundant KSs in that case. If the network needs to grow in future, then yes GET can be a good option.

In redundant KSs (COOP), we need to generate the keys on one of the KSs and make them exportable. We then need to import these keys to the other KS. Both KSs must have the exact same keys for failover scenario to work correctly.

dondongamo Sat, 06/23/2007 - 23:55

That's right GM1->WAN1 & GM2->WAN2. We're using GRE as part of security solutions apart from restricting traffic.

This is an upgrade of their existing IPSec infra and administrative overhead is our main concern. Eventually each of these business partners (spokes) will have their own DR, so we can say it will be doubled. This is a complete private network not through internet and based on this requirements we recommended GET.

Though we have tried in a test bed environment but not the KSs (COOP) scenario. Since the trick is to have the same keys for both KSs, this complete our implementation plan.

In case we will face any further issues during the deployment, if you won't mind, can we have your email id?

Thanks again...

dondongamo Wed, 06/27/2007 - 01:30

Hi Haseeb,

I have another query from one of our client since we have an issue of having a single ISP.

Is it possible to have this scenario in GET?

GM1 -> WAN1 (through private network)

GM2 -> WAN2 (through Internet)

Having single media for both GMs is a dilemma here.

Any comment? TIA.

hniazi Wed, 06/27/2007 - 13:24

We thought about this scenario. Since one of the GMs is connected to the Internet, it can not run GET. You will have to use one of the other traditional IPsec technologies say DMVPN on that router and then manipulate the routing.

hniazi Wed, 06/20/2007 - 08:45

KS functionality is supported on all the routers down to 1841. We test 7200 G2, 7200 G1, 3845, 3825, 2851, 2821 and 1841 as key servers.

KS sizing depends on the number of GMs in your network. We are targeting 1841 for deployments upto 50 GMs, 2800s and 3800s for deployments in few 100s and 7200s for deployment of 1000+ GMs.

The exact support numbers for various platforms will be available on the GET VPN website ( as soon as we compile and publish our results.

If you have a specific deployment in mind (i.e. before we publish the numbers), please do no hesitate to let me know and I can point you to the appropriate KS.



JHaynes4 Wed, 06/20/2007 - 08:59


Can the key server be located on one of the group members, or does it require a physically seperate router? This is an expense some customers may not want to incurr. Thanks.

hniazi Wed, 06/20/2007 - 10:02

KS and GM currently can not be on the same box. This is a high priority feature on the development's plate but it wont be available within this year.

Cisco definitly understand the expense part and that is the reason we support KS functionality on small ISR platforms as well. Depending on the scale, you can choose a smaller platform to act as a KS. From my personal preference, I would like to keep the KS out of the data path i.e. on the separate box because KS is the brain of the network doing all the work.

hniazi Thu, 06/21/2007 - 08:17

Even though we have not tested 2811 specifically, we have tested 2821 and 2851. We should be able to support these many GMs. One thing I must point out is that in our testing, we used AIM-VPN/SSL modules on all ISRs.



bvandromme Fri, 06/22/2007 - 01:17


I'd like to know more about using OSPF through a GETVPN. Is a GETVPN considered as a NBMA network? Are there design guidelines or recommendations?

hniazi Fri, 06/22/2007 - 15:32

GET VPN actually does not care how your IP network is laid out. All GET VPN cares about is end to end connectivity (even for "private networks" behind routers). If you have an ATM network OR a frame-relay network OR MPLS network (just to name a few) and all the devices are talking to each other today, you can deploy GET VPN. Routing protocl at this point is irrelevant.

This is the reason, GET VPN is also known as tunnel-less VPN - it will not create an IPsec or GRE overlay.

Depending on what you want to encrypt, you will define your policies and CE/Routers will start encrypting packets and forward them on the regular routing path.

You can learn more about the concept from some of the presenation here:

Plz let me know if there are any further questions.



v.srsen Fri, 06/22/2007 - 06:23

Hi, we have a following situation. We have an MPLS core with one HQ site, we want to enable several different customers who all have their own different vrfs in the MPLS core (because of the overlapping addressing) to access the HQ, and we accomplished that with having vrf-lite and vrf-aware NAT on the HQ WAN router pair (hsrp). However, we would like to implement get vpn into this environment for encryption.

My question is about the key servers. Only one of our GMs (the HQ WAN routers) is a vrf aware CE, and the KSs would be connected somewhere in the MPLS cloud. In the documentation it is stated that the KSs are not vrf aware, and that for a solution like ours, we would need to have separate pair of KSs for each customer/vrf. Is this still true? A detailed explanation why it is so would be very much appreciated.


hniazi Fri, 06/22/2007 - 15:51

VRF aware KS is still not supported but is one of high priority items on developer's plate. Let me share some of the details as you requested.

If you have multi-vrf CE, you will have interface/sub-interfaces connected to PE and each interface will be in separate VRF. You will apply a crypto map on each of these sub-interfaces. One of the IOS restrictions is that GM should receive the keying material and IPsec SAs for a particular VRF from the interface in the same VRF. What that means is:

C--F0/0.101 (VRF blue; crypto map blue)

E--F0/0.102 (VRF green; crypto map green)

Suppose CE (as shown above) has two sub-intf in different VRFs with crypto maps applied.

In order to properly install the ipsec SA in VRF blue, registration should take place in vrf blue i.e over interface F0/0.101. Second limitation is that crypto map blue and green can not map to same group on the KS. this probably is not a problem in your case. GMs will talk within a VRF i.e. blue GMs will only talk to other blue GMs and green Gms will talk to green GMs

For this reason we either need a KS in the same VRF (KS per VRF) OR a VRF aware KS which is part of both VRF blue and green.

You potentially could use a KS (non-vrf) and connect it to PE in both VRFs. Something like:

K (global)--subint-VRF blue--P

S (global)--subint-VRF green-E

There are two links on the KS but both of them are in global but same interfaces on the PE side are in VRFs. You can then define two gdoi groups on the KS for VRFs blue and green Gms to register. This would work if there are no ovelapping addresses for various GMs.

There is another possibility where you can use VRF-aware NAT in front of KS so that you can uniquely translate (statically) GM in blue and green. This option is not a tested option but *might* work and will support overlapping addresses.

Essentially if we had VRF aware KS, we would not have these issues.



v.srsen Mon, 06/25/2007 - 05:09

Thanks for your detailed answer!

However, just to clarify one more thing to be sure, when you talk about overlapping addresses restriction you mean GM addresses overlapping in different vrfs or general overlapping between any address ranges in the vrfs?

Because we won't have overlapping between GM WAN addresses in different vrfs (GM addresses from different vrfs seen from the KS would be unique), however some LAN subnets in different vrfs could overlap.

Thanks again.

hniazi Mon, 06/25/2007 - 07:59

Good question. I should have clarified in the earlier post. From KS point of view (registration and rekey), I was talking about overlapping WAN addresses because WAN addresses are used to register to the KS and should be reachable from the KS.

Once the ipsec SAs are created on the GM/vrfs, data traffic should work fine from GM to GM in a particular VPN.

v.srsen Mon, 06/25/2007 - 08:02

That simplifies things. We will be testing this solution for the next 2-3 weeks so I needed a couple of details.

Thanks again.

hniazi Sun, 06/24/2007 - 11:01

If you do not have MPLS network OR a network that provides end to end connectivity, GET VPN is not the right solutions since it can not be used w/o the help of an overlay model. We can combine GET VPN with DMVPN (w/o using tunnel protection hence traditional ipsec) - DMVPN will overlay a GRE network and GET VPN will be used to encrypt the GRE traffic. The advantage is since DMVPN supports dynamic spoke to spoke tunnels, we will not need to setup ipsec everytime a spoke to spoke tunnel comes up. In future, GET VPN functionality will be tied to tunnel protection and you will not need to use "crypto maps" like you do today. This solution supports multicast but only from hub to spoke. The biggest issue I have found with supporting multicast over Internet is that multicast forwarding is not supported by most providers and hence we have to revert back to an overlay model which makes things point to point.

There are talks of ipv6 with GET VPN but there is nothing committed.



shajith123 Mon, 06/25/2007 - 05:05

We are having a 1841 router and 2 mbps adsl line here we want to filter all packets from 1841 router and send smtp through a dedicated 128 kpbs leased line and Citrix and all other web traffic through 2 mbps ADSL .. How it possible?? Policy based Routing ?? what Commands i want to give????

daleschultz Mon, 06/25/2007 - 11:09


I'm interested in the router sizing differences between DMVPN and GETVPN. Router sizing seems to be driven by the number of tunnels and packet rate/size in DMVPN, since GETVPN is tunnel-less are we sizing purely on packet rate/size for throughput? I?ve played with an application of 10Mbps of multicast in a GDIO configuration on a 2811 (no AIM) and it ran at 80% CPU.

I'm presently looking at a 300 node VPN over DSL and to me it would seem easier to implement as a GETVPN solution rather than a DMVPN solution.

Thanks in advance for your comments.


hniazi Mon, 06/25/2007 - 19:57

Your findings are correct. In case of DMVPN, there are multiple factors that determine the throughput:

a) Number of routing protocol neighbors (in case of hub)

b) Number of IPsec tunnels i.e. IPsec SAs

c) CPU usage due to NHRP and routing

d) packet size

e) In case of multicast with DMVPN, hub has to do all the replication as well.

In case of GET things are a little simpler - SAs are limited and multicast replicaiton is not handled by a GM; your multicast core replicates the packets.

But ofcrs GET can not be used in all scenarios. If you can use GET and have multicast traffic, you probably should go for it.

In case of GET, one of the major factors determining throughput will be packet size and that is no different than regular IPsec.

kapilakarunarathna Tue, 06/26/2007 - 00:20

We have cisco 3550 switches peforming a vpn.I want to analyze traffic.

So that I configure a span port and monitor session.Following commands were issued.

monitor session 1 source {interface interface-id } [, | -] [both ]

monitor session 1 destination {interface interface-id , [encapsulation dot1q]}

But Encapsulation does not happens.With a sniffer stiil could not see vlan ID's.

Please tell me a way to see vlanID with their traffic.


hniazi Tue, 06/26/2007 - 14:46

GET VPN is not supported on switches.

For the monitoring session commands, I am not sure about VLANs. You might want to try the switching discussions for this question.



sorper Wed, 06/27/2007 - 23:53


I'm working with a customer to evaluate GET. The customer uses Cat6500 as WAN aggregation with WS-SVC-IPSEC-1, and we are looking at both GET and DMVPN. At this point I have one question regarding GET. I have undeerstood that it is not possible today to use GET on Cat6500. Is there any plans to support GET on the Cat6500 platform.

Per Arne

hniazi Thu, 06/28/2007 - 06:23

GET VPN will be supported on 6500 but not anytime soon. The current target date is end of 2008 (but is subject to change).

jbluciani Mon, 01/18/2010 - 09:04

Hello Haseeb,

I would like to use GET VPN upon a non-MPLS-based private IP network (20 CE sites) with a few constraints:
- Each CE site has 2 x WAN links with load-sharing. Each link bandwidth is at most 30 Mbps, except for the 'DC' site which has 2 x 250 Mbps links
- Each CE site has 2 x router-based CPEs (max. C3825 used), except the 'DC' site which uses 2 x 6503-E Catalyst switches
- 2 VRFs (blue and green) are implemented on all the CPEs but only 1 VRF (blue) needs GET VPN

It seems to me there are too many constraints to work.

Do you agree?



matevz.mesojedn... Tue, 03/09/2010 - 23:09


We want to use Get-VPN connecting customer's branches and provide ISP redundancy for GMs at the same time. We are looking into the following scenario at the branch site:

                    WAN1 (primary, MPLS)


                    WAN2 (redundant, 3G)

WAN1 are WAN2 seperate network, each being capable of routing to the branch's LAN segment.

Are there any limitations in applying crypto map to 2 physical interfaces. What would you recommend in order to assure redundant tunnel (across WAN2) gets established in case of primary link failure.


rpeasah Wed, 03/10/2010 - 06:33

Well it depends and I can only speak to personal experience in our environment. What we've run into with regard to GETVPN in an MPLS environment is that in a situation where PE routers are involved, we've had to deploy the GETVPN router behind the PE router to make it work. In other words we've not succeeded in making GETVPN work on a router that has multiple vrfs. I'm hoping cisco will solve issue pretty soon because it's quite an expensive proposition when you've tons of sites upwards of 400-500.


This Discussion