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'm just wondering if there are many GET-installations around? I am currently working on a GET-solution for a customer, including two different carriers. We haven't run into any problems yet, but..
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.
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?
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.
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?
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).
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.
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?
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:
Will GET VPN be supported on the ASA platform as well or is this going to be like DMVPN a Router only feature?
GET VPN will only be supported on IOS platforms like DMVPN. There are no plans of support on ASA as of right now.
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.
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.
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.
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.
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.
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?
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.
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.
How do you choose the correct key-server?
I have read that recomended KS is 3800 or 7200/7300 but it's still supported down to 1800...
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 (www.cisco.com/go/getvpn) 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.
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.
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.
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.