This feature is being implemented within a lab environment, so the address space that is being used is private. It could easily use a public address space such as 193.25.25.0/24 if you like, the results in the lab will be the same.
In order to apply this to a real world environment, you can simply replace the network in the diagram that has the 192.168.1.0/24 network with any IP address space that is provided to you by your ISP for routing over the Internet.
Hello,
I did the laboratory (just like the example) and according to what I observed that the GMs lose communication with the KS once GETVPN is implemented. Did I do something wrong or can something additional be done to achieve communication with the KS?
Can the KS also participate in the communication?
I have other questions:
In a DMVPN environment, could the KS be the HUB or does it have to be another device? Could you give me an example or a reference link?
Why is a transform-set created in the GM if they download the transform from the KS?
In order to determine what went wrong you will have to do some troubleshooting. Follow the lesson as you did, but see what error messages you get, and also check the syslogs to see events that take place, especially at the moment you lose communication. Take a look at the following documentation to help you in your troubleshooting process:
DMVPN and GETVPN are two different approaches to deploying multisite communication. They are mutually exclusive in the sense that you can deploy either one or the other. Take a look at this Cisco documentation that describes both of these technologies in detail, compares them, and also gives you principles to use in selecting which technology to use, and how to use it for particular use cases:
The KS is responsible for group registration and authentication of GMs. As stated in the lesson:
When a GM tries to register with the KS, the KS checks a group ID and IKE credentials. When this checks out, the KS sends the following items to the GM:
The security policy that we use for the group.
Two keys:
KEK (Key Encryption Key): this is used to encrypt rekey messages. GMs use this key to decrypt rekey messages from the KS.
TEK (Traffic Encryption Key): this becomes the IPSec SA that all GMs use to encrypt traffic between each other.
The transform set is not downloaded from the KS, so it must be configured as shown in the lesson.
How can I configure OSPF on the GM routers? how would I simulate the MPLS network if I am building this network using hardware. I implementing this network for my masterâs thesis from hardware using cisco routers
As stated in the lesson, GETVPN is primarily intended for private networks such as MPLS VPN. In this sense, the MPLS VPN network operates as an âunderlayâ network on top of which the GETVPN mechanism operate. In order to achieve this, you will have to create an MPLS VPN topology. To find out how to do that (with either real equipment or emulation), take a look at the MPLS course found here:
In particular, you will find the MPLS VPN lessons quite useful for this particular implementation.
Now once you have a GETVPN scenario up and running, you can then implement OSPF on the participating routers without any special configuration. You just do it as you would on a normal network topology. Indeed you can run any routing protocol you like between the routers. This is because GETVPN works at the IP layer and provides end-to-end encryption, which means it doesnât interfere with the IP packet header.
This is an advantage of GETVPN over some other VPN technologies, which encapsulate the original packet into a new packet for transport (IPSec Tunnel mode, for instance), potentially interfering with the operation of routing protocols.
So in a GETVPN deployment, your routers can establish OSPF neighbor relationships and exchange route information as if they were directly connected, even though their traffic is actually being encrypted by GETVPN.