CCNP ROUTE 2.0 Exam Blueprint: VPN Technologies
- Configure and verify GRE
- Describe DMVPN
- Describe Easy Virtual Networking (EVN)
Configure and Verify GRE
- Generic Routing Encapsulation (GRE) was designed to carry multiprotocol and IP multicast traffic between sites
- Encapsulated protocols included IP, Appletalk, DECnet or IPX
- GRE encapsulates an inside IP address within an outside IP address
- Is NOT encrypted by default
- GRE tunnels can run through IPSec tunnels. When running GRE tunnel over IPSec, a packet is first encapsulated in a GRE packet and then GRE is encrypted by IPSec
- Multicast traffic GRE tunnels do support transporting IP multicast and broadcast packets to the other end of the GRE tunnel
- GRE tunnels add an additional 20 byte IP header and a 4 byte GRE tunnel header. 24 byte overhead in total
GRE can be configured as either point-to-point or point-to-multipoint tunnels.
Point-to-Point – simple configuration between 2 peers, does not require NHRP
Point-to-Multipoint – only one tunnel configured on a router to support multiple GRE peers (great for scalability), requires NHRP to build dynamic tunnels (allows peers with DHCP assigned public IP addresses).
Configure a Point-to-Point and Point-to-Multipoint GRE Tunnel
R1 (config)# interface tunnel 0
R1 (config-if)# ip address 192.168.0.1 255.255.255.0
R1 (config-if)# tunnel source fastethernet 0/0
R1 (config-if)# tunnel destination 18.104.22.168
R1 (config-if)# tunnel mode gre ip
R2 (config)# interface tunnel 0
R2 (config-if)# ip address 192.168.0.2 255.255.255.0
R2 (config-if)# tunnel source fastethernet 0/0
R2 (config-if)# tunnel destination 22.214.171.124
R2 (config-if)# tunnel mode gre ip
On a Point-to-Point Tunnel the command “tunnel mode gre ip” does not need to be specified as it is actually enabled as default. On a Point-to-Multipoint tunnel the command “tunnel mode gre multipoint” is configured. NO destination “tunnel destination <IPADDRESS>” is configured because mGRE tunnels do have a tunnel destination defined. mGRE relies on NHRP NHS to direct traffic accordingly.
With a normal Full Mesh VPN each spoke router would require a VPN to every other spoke router, also the VPN would be established and continue to stay up even if no traffic going across the tunnel. This requires a lot time in configuring a VPN on each of the routers in the first place, as well as router resources and bandwidth in maintain the tunnels.
DMVPN is much more efficient and allows a spoke router to dynamically create a VPN to another spoke router when required and then drop the VPN after a configured period when no longer required. The actual configuration is minimal compared to other types of VPNs.
Allows direct spoke-to-spoke VPNs with traffic not routed through the hub.
DMVPN consists of:
mGRE (Multipoint GRE) allows an interface to support multiple GRE tunnels as required, as well as simplify the configuration. GRE tunnels provide support for IP Multicast and non-IP protocols to traverse the interface. Support for multicast enables the use of dynamic routing protocols such as EIGRP/OSPF.
GRE uses IP Protocol 47
NHRP (Next Hop Resolution Protocol) dynamically learns the IP address of other routers and allows them to directly communicate. NHRP uses client-server model with the Hub as the NHRP Server and the Spokes as the NHRP Client. When establishing a tunnel the client sends 2 IP addresses to the server (the Public IP address and the tunnel IP address). These IP addresses are stored in the NHRP database on the Hub. When a spoke router needs to create a tunnel to another spoke router it queries the hub router’s database, then the spoke can establish a direct tunnel to the other spoke router.
IPSec provides transmission protection for GRE tunnels which is unencrypted. IPSec on its own is unable to protect multicast packets. GRE can encapsulate multicast packets which is why a combination of GRE over IPSec
Not required as part of the CCNP R&S ROUTE 2.0 exam but this post describes how to configure DMVPN.
- Easy Virtual Network (EVN) is designed to provide an easier method to provide traffic separation and path isolation
- EVN has separate routing and forwarding tables
- It leverages existing technologies such as VRF/VRF Lite and dot1q encapsulation
- VRF-Lite can create up to 32 routing contexts
- VRF Connectivity between L3 devices is via Virtual Network trunks (VNET), these are regular dot1q trunks.
- The dot1q subinterfaces are automatically created and hidden
- Routing between VRFs is allowed without a requirement of BGP, therefore no need to specify a Route Distinguisher