Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss with Cisco expert Siva Mandalam how to provide scalable, efficient, secure data encryption over MPLS networks with this new solution. Siva is the product manager for the IPSec solutions, including Group Encrypted Transport (GET) VPN and DMVPN, Cisco's multipoint encryption solutions for both private and IP-based WANs.
Remember to use the rating system to let Siva know if you have received an adequate response.
Siva 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 February 9, 2007. Visit this forum often to view responses to your questions and the questions of other community members.
Does layer 3 Switches use IP based lookup and forwarding??? if so then do they have a network table along with mac table?????????
Do switshes have Mac address assigned to them needed in case of selection of Root Bridge????
I have two basic questions:
1) Is GET designed only to provide an additional layer of security for MPLS, or can it be used to replace IPSec/GRE tunnels?
2) Which ISRs support GET, and what is the minimum IOS version for each?
1) YEs, GET is designed to provide an additional laye rof security for MPLS. IT can be used to replace Ipsec/gre tunnels over private networks as well. GET doesn't deploy tunneling technology, as it is it seemlessly integrates with underlying network.
2) ALL ISR starting from 870-3800 support GET. Minimum version is 12.4 (11) T
will you please give me some overview of GET or any good fundamental link to get the overview...?
You say "over private networks as well". I take it that GET is not for public networks, such as site-to-site VPNs over Internet connections?
Is there another methodology instead of using preshared keys between the gorup members and key servers?
I see that GETVPN is not compatible with Switches. Is it compatible with the ASA. It is on the roadmap to include GETVPN into the ASA.
From data plane perspective, GET packet is exactly the same size as the IPsec packet. So dwe don't anticipate any overhead with GET VPN
How is GET as compare to other IPSEC/Tunnel based? It's new protocols/technologies? Wondering how to design and implement in MPLS based services. Appreciate link, whitepaper and etc.
thanks in advance.
A critical challenge for any solution in environments such as distribution of enterprise audio, video, and other media is efficiency. Another challenge in protecting "native" multicast packets requires taking advantage of and interoperating with the existing multicast infrastructure. Native multicast implements several protocols for distributing the group information and the IPsec mechanism to distribute cryptographic keys in larger WAN deployments must work in concert with those protocols.
Finally, our experience with IPsec suggests that ongoing management of this infrastructure in the real enterprise is another critical challenge. Cryptographic keys have to be passed onto the authenticated hosts, and mechanisms must be put in place for eliminating rogue elements in these authenticated groups.
The solution Group Encrypted Transport offers a new standards-based security model that is based on the concept of ?trusted? group members. Trusted member routers use a common security methodology that is independent of any point-to-point IPsec tunnel relationship. By using trusted groups instead of point-to-point tunnels, any-to-any networks are able to scale higher while maintaining network-intelligence features?such as QoS, routing, and multicast--critical to voice and video quality. The security model based on the existing routing infrastructure (rather than an ?overlay? on top of this infrastructure) improves the reliability and convergence, with the added benefit that the group nature of the security model facilitates optimal efficiency for any-to-any transactions.
Group Encrypted Transport VPN is built on a robust key distribution mechanism, security model based on the existing routing infrastructure, and data plane protection for both Unicast and Multicast
I am planning to implement the DMVPN in our global network, but after reading GETVPN on DMVPN, it looks good.
So we were planning to have multiple GET key server`s in our network, but I got little doubt in this setup.
Should the multiple GETVPN key server`s should be be one place only like 4-5 server`s in H.O only?
Is it not possible to put the KEY server`s line 2-3 in H.O and 3-4 in different parts of our B.O like different continents.
Why I am worried is if again the "digital tsunami" happens and if we put the 2-3 GETVPN key server in our H.O only and if the "digital tsunami" occurs then the whole communication between our B.O will be down, is it correct?
Can you please suggest a good solution how to implement the key server in this scenario?
GET VPN key servers can be geographically dispersed. The only requirement is that each of the key servers need to be able to reach others.
A design guide is coming up on CCO pretty soon.
CAn you reach out to your nearest account team, and engage us for a more broader discussion on your specific design?
Thank you very much for the inputs.
So if the key server?s in different parts of world can communicate with global IP address and these communications will be thru encrypted packets?
Also all the B.O routers need to know all the key server details around the world?
Dose the B.O router config has got master key server and slave key server?s setup, so if the master goes down and also the some of the slave goes down, the B.O router will automatically check the available key server and do the authentications and setups?
Please put the documents outside the CCO.
Any updates on the bug CSCek54628 DGVPN:Multipeer feature broken ? I'm not seeing any attempt to failover at all in my test environment - even using the default IPSec & Group rekey timers and issuing the "clear crypto gdoi" command.
We have MPLS setup with multiple service providers. We were considering TED for any-to-any connectivity but it seems Cisco has stopped development on the same.
Compared to TED, what are the advantages in GET. Also, I would like to have a tunnel interface to my Central site but spoke-to-spoke should use GET. Is this scenario possible with GET.
Three main differences. TED
o Doesn?t support multicast
o Doesn?t support instantaneous communications
o Doesn?t support a group communication concept
GET VPN does all three.
"Also, I would like to have a tunnel interface to my Central site but spoke-to-spoke should use GET. Is this scenario possible with GET. "
This exact scenario is in fact possible, and we have a guide on CCO which explains how to set this up. please look http://www.cisco.com/en/US/products/ps6660/products_white_paper0900aecd804c363f.shtml
for more information