Chapter 16. Overlay Tunnels

This chapter covers the following subjects:

Generic Routing Encapsulation (GRE) Tunnels: This section explains GRE and how to configure and verify GRE tunnels.

IPsec Fundamentals: This section explains IPsec fundamentals and how to configure and verify IPsec.

Cisco Location/ID Separation Protocol (LISP): This section describes the architecture, protocols, and operation of LISP.

Virtual Extensible Local Area Network (VXLAN): This section describes VXLAN as a data plane protocol that is open to operate with any control plane protocol.

An overlay network is a logical or virtual network built over a physical transport network referred to as an underlay network. Overlay networks are used to overcome shortcomings of traditional networks by enabling network virtualization, segmentation, and security to make traditional networks more manageable, flexible, secure (by means of encryption), and scalable. Examples of overlay tunneling technologies include the following:

  • Generic Routing Encapsulation (GRE)

  • IP Security (IPsec)

  • Locator ID/Separation Protocol (LISP)

  • Virtual Extensible LAN (VXLAN)

  • Multiprotocol Label Switching (MPLS)

A virtual private network (VPN) is an overlay network that allows private networks to communicate with each other across an untrusted network such as the Internet. VPN data sent across an unsecure network needs to be encrypted to ensure that the data is not viewed or tampered with by an attacker. The most common VPN encryption algorithm used is IP Security (IPsec).

Private networks typically use RFC 1918 address space (10.0.0.0/8,172.16.0.0/12, and 192.168.0.0/16), which is not routable across the Internet. To be able to create VPNs between private networks, a tunneling overlay technology is necessary, and the most commonly used one is GRE.

Note

MPLS tunneling is not supported across the Internet unless it is tunneled within another tunneling protocol, such as GRE, which can then be encrypted with IPsec (MPLS over GRE over IPsec). A key takeaway from this is that an overlay tunnel can be built over another overlay tunnel.

Different combinations of overlay tunneling and encryption technologies opened the door to next-generation overlay fabric networks such as:

  • Software-Defined WAN (SD-WAN)

  • Software-Defined Access (SD-Access)

  • Application Centric Infrastructure (ACI)

  • Cisco Virtual Topology System (VTS)

This chapter covers GRE, IPsec, LISP, and VXLAN. These technologies are essential to understanding the operation of SD-Access and SD-WAN, which are covered in Chapter 23, “Fabric Technologies.”

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read the entire chapter. If you miss no more than one of these self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section. Table 16-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so you can assess your knowledge of these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quiz Questions.”

Table 16-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

Foundation Topics Section

Questions

Generic Routing Encapsulation (GRE) Tunnels

1–3

IPsec Fundamentals

4–6

Cisco Location/ID Separation Protocol (LISP)

7–9

Virtual Extensible Local Area Network (VXLAN):

10–11

1. Which of the following commands are optional for GRE configuration? (Choose two.)

  1. tunnel source {ip-address | interface-id}

  2. tunnel destination ip-address

  3. tunnel mode gre {ip | ipv6}

  4. keepalive

2. True or false: GRE was originally created to provide transport for non-routable legacy protocols.

  1. True

  2. False

3. Which of the following should not be dynamically advertised via an IGP into a GRE tunnel?

  1. Loopback interfaces

  2. The GRE tunnel source interface or source IP address

  3. Connected interfaces

  4. The GRE tunnel IP address

4. Which of the following are modes of packet transport supported by IPsec? (Choose two.)

  1. Tunnel mode

  2. Transparent mode

  3. Transport mode

  4. Crypto mode

5. Which of the following are encryption protocols that should be avoided? (Choose two.)

  1. DES

  2. 3DES

  3. AES

  4. GCM

  5. GMAC

6. Which of the following is the message exchange mode used to establish an IKEv1 IPsec SA?

  1. Main mode

  2. Aggressive mode

  3. Quick mode

  4. CREATE_CHILD_SA

7. LISP separates IP addresses into which of the following? (Choose two.)

  1. RLOCs

  2. LISP entities

  3. Subnets and hosts

  4. EIDs

8. What is the destination UDP port used by the LISP data plane?

  1. 4341

  2. 4143

  3. 4342

  4. 4142

9. True or false: ETRs are the only devices responsible for responding to map requests originated by ITRs.

  1. True

  2. False

10. Which of the following UDP ports is the UDP port officially assigned by the IANA for VXLAN?

  1. 8947

  2. 4789

  3. 8472

  4. 4987

11. True or false: The VXLAN specification defines a data plane and a control plane for VXLAN.

  1. True

  2. False

Answers to the “Do I Know This Already?” quiz:

1 C, D

2 A

3 B

4 A, C

5 A, B

6 C

7 A, D

8 A

9 B

10 B

11 B

Foundation Topics

Generic Routing Encapsulation (GRE) Tunnels

GRE is a tunneling protocol that provides connectivity to a wide variety of network-layer protocols by encapsulating and forwarding packets over an IP-based network. GRE was originally created to provide transport for non-routable legacy protocols such as Internetwork Packet Exchange (IPX) across an IP network and is now more commonly used as an overlay for IPv4 and IPv6. GRE tunnels have many uses. For example, they can be used to tunnel traffic through a firewall or an ACL or to connect discontiguous networks, and they can even be used as networking duct tape for bad routing designs. Their most important application is that they can be used to create VPNs.

When a router encapsulates a packet for a GRE tunnel, it adds new header information (known as encapsulation) to the packet, which contains the remote endpoint IP address as the destination. The new IP header information allows the packet to be routed between the two tunnel endpoints without inspection of the packet’s payload. After the packet reaches the remote endpoint, the GRE headers are removed (known as de-encapsulation), and the original packet is forwarded out the remote router. Figure 16-1 illustrates an IP packet before and after GRE encapsulation.

A figure shows IP packets before and after GRE encapsulation.

Figure 16-1 IP Packet Before and After GRE Headers

Note

GRE tunnels support IPv4 or IPv6 addresses as an underlay or overlay network.

The following sections explain the fundamentals of a GRE tunnel as well as the process for configuring them.

GRE Tunnel Configuration

Figure 16-2 illustrates a topology where R1 and R2 are using their respective ISP routers as their default gateways to reach the Internet. This allows R1 and R2 to reach each other’s Internet-facing interfaces (g0/1 on both) to form a GRE tunnel over the Internet. For this case, the Internet, represented by 100.64.0.0/16, is the transport (underlay) network, and 192.168.100.0/24 is the GRE tunnel (overlay network).

A GRE tunnel topology is shown.

Figure 16-2 GRE Tunnel Topology

Example 16-1 shows the routing table of R1 before the GRE tunnel is created. Notice that there is a default route pointing to ISP1.

Example 16-1 R1’s Routing Table Without the GRE Tunnel

R1# show ip route
! Output omitted for brevity                                                                      
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
..
       ia - IS-IS inter area, * - candidate default, U - per-user static route

Gateway of last resort is 100.64.1.2 to network 0.0.0.0                                           

S*    0.0.0.0/0 [1/0] via 100.64.1.2                                                              
..                                                                                                
! A traceroute to R2's LAN interface is sent to the ISP1 router which blackholes it
! since it has no reachability into R2's LAN networks.                                

R1# trace 10.2.2.2
Tracing the route to 10.2.2.2
  1 100.64.1.2 2 msec 2 msec 3 msec                                                   
  2 100.64.1.2 !H  !H  *                                                              
! R2's Internet facing interface is reachable from R1's Internet facing interface.
! These Internet facing addresses will be used as endpoints for the GRE tunnels       

R1# ping 100.64.2.2 source 100.64.1.1
Sending 5, 100-byte ICMP Echos to 100.64.2.2, timeout is 2 seconds:                   
!!!!!                                                                                 
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/5 ms

The steps for configuring GRE tunnels are as follows:

Step 1. Create the tunnel interface by using the global configuration command interface tunnel tunnel-number.

Step 2. Identify the local source of the tunnel by using the interface parameter command tunnel source {ip-address | interface-id}. The tunnel source interface indicates the interface that will be used for encapsulation and de-encapsulation of the GRE tunnel. The tunnel source can be a physical interface or a loopback interface. A loopback interface can provide reachability if one of the transport interfaces fails.

Step 3. Identify the remote destination IP address by using the interface parameter command tunnel destination ip-address. The tunnel destination is the remote router’s underlay IP address toward which the local router sends GRE packets.

Step 4. Allocate an IP address to the tunnel interface to the interface by using the command ip address ip-address subnet-mask.

Step 5. (Optional) Define the tunnel bandwidth. Virtual interfaces do not have the concept of latency and need to have a reference bandwidth configured so that routing protocols that use bandwidth for best-path calculation can make an intelligent decision. Bandwidth is also used for quality of service (QoS) configuration on the interface. Bandwidth is defined with the interface parameter command bandwidth [1-10000000], which is measured in kilobits per second.

Step 6. (Optional) Specify a GRE tunnel keepalive. Tunnel interfaces are GRE point-to-point (P2P) by default, and the line protocol enters an up state when the router detects that a route to the tunnel destination exists in the routing table. If the tunnel destination is not in the routing table, the tunnel interface (line protocol) enters a down state.

Tunnel keepalives ensure that bidirectional communication exists between tunnel endpoints to keep the line protocol up. Otherwise, the router must rely on routing protocol timers to detect a dead remote endpoint.

Keepalives are configured with the interface parameter command keepalive [seconds [retries]]. The default timer is 10 seconds, with three retries.

Step 7. (Optional) Define the IP maximum transmission unit (MTU) for the tunnel interface. The GRE tunnel adds a minimum of 24 bytes to the packet size to accommodate the headers that are added to the packet. Specifying the IP MTU on the tunnel interface has the router perform the fragmentation in advance of the host having to detect and specify the packet MTU. IP MTU is configured with the interface parameter command ip mtu mtu.

Table 16-2 shows the encapsulation overhead for various tunnel techniques. The header size may change depending on the configuration options used. For all the examples in this chapter, the IP MTU is set to 1400.

Table 16-2 Encapsulation Overhead for Tunnels

Tunnel Type

Tunnel Header Size

GRE without IPsec

24 bytes

DES/3DES IPsec (transport mode)

18–25 bytes

DES/3DES IPsec (tunnel mode)

38–45 bytes

GRE + DES/3DES

42–49 bytes

GRE + AES + SHA-1

62–77 bytes

GRE Configuration Example

Example 16-2 provides a GRE tunnel configuration for R1 and R2, following the steps for GRE configuration listed earlier in this section. OSPF is enabled on the LAN (10.0.0.0/8) and GRE tunnel (192.168.100.0/24) networks. With this configuration, R1 and R2 become direct OSPF neighbors over the GRE tunnel and learn each other’s routes. The default static routes are pointing to their respective ISP routers.

Example 16-2 Configuring GRE

R1
interface Tunnel100                                                                               
 bandwidth 4000                                                                                   
 ip address 192.168.100.1 255.255.255.0                                                           
 ip mtu 1400                                                                                      
 keepalive 5 3                                                                                    
 tunnel source GigabitEthernet0/1                                                                 
 tunnel destination 100.64.2.2                                                                    
!
router ospf 1
 router-id 1.1.1.1
 network 10.1.1.1 0.0.0.0 area 1                                                                 
 network 192.168.100.1 0.0.0.0 area 0                                                            
!
ip route 0.0.0.0 0.0.0.0 100.64.1.2                                                              
R2
interface Tunnel100                                                                               
 bandwidth 4000                                                                                   
 ip address 192.168.100.2 255.255.255.0                                                           
 ip mtu 1400                                                                                      
 keepalive 5 3                                                                                    
 tunnel source GigabitEthernet0/1                                                                 
 tunnel destination 100.64.1.1                                                                    
!
router ospf 1
 router-id 2.2.2.2
 network 10.2.2.0 0.0.0.255 area 2                                                               
 network 192.168.100.2 0.0.0.0 area 0                                                            

ip route 0.0.0.0 0.0.0.0 100.64.2.1                                                               

Now that the GRE tunnel is configured, the state of the tunnel can be verified with the command show interface tunnel number. Example 16-3 shows output from this command. Notice that the output includes the tunnel source and destination addresses, keepalive values (if any), the tunnel line protocol state, and the fact that the tunnel is a GRE/IP tunnel.

Example 16-3 Displaying GRE Tunnel Parameters

R1# show interfaces tunnel 100 | include Tunnel.*is|Keepalive|Tunnel s|Tunnel p
Tunnel100 is up, line protocol is up                                                   
  Keepalive set (5 sec), retries 3                                                     
  Tunnel source 100.64.1.1 (GigabitEthernet0/1), destination 100.64.2.2                
  Tunnel protocol/transport GRE/IP                                                      

Example 16-4 shows the routing table of R1 after forming an OSPF adjacency with R2 over the GRE tunnel. Notice that R1 learns the 10.2.2.0/24 network directly from R2 via tunnel 100, and it is installed as an OSPF inter area (IA) route.

Example 16-4 R1 Routing Table with GRE

R1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

! Output omitted for brevity                                                                      

Gateway of last resort is 100.64.1.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 100.64.1.2
      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.1.1.0/24 is directly connected, GigabitEthernet0/3
L        10.1.1.1/32 is directly connected, GigabitEthernet0/3
O IA     10.2.2.0/24 [110/26] via 192.168.100.2, 00:17:37, Tunnel100                              
      100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        100.64.1.0/30 is directly connected, GigabitEthernet0/1
L        100.64.1.1/32 is directly connected, GigabitEthernet0/1
      192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.100.0/24 is directly connected, Tunnel100
L        192.168.100.1/32 is directly connected, Tunnel100

Example 16-5 verifies that traffic from 10.1.1.1 takes tunnel 100 (192.168.100.0/24) to reach the 10.2.2.2 network.

Example 16-5 Verifying the Tunnel

R1# traceroute 10.2.2.2 source 10.1.1.1
Tracing the route to 10.2.2.2                                                                     
  1 192.168.100.2 3 msec 5 msec *                                                                 

Notice that from R1’s perspective, the network is only one hop away. The traceroute does not display all the hops in the underlay. In the same fashion, the packet’s time-to-live (TTL) is encapsulated as part of the payload. The original TTL decreases by only one for the GRE tunnel, regardless of the number of hops in the transport network. During GRE encapsulation, the default GRE TTL value is 255. The interface parameter command tunnel ttl <1-255> is used to change the GRE TTL value.

Problems with Overlay Networks: Recursive Routing

Recursive routing and outbound interface selection are two common problems with tunnel or overlay networks. This section explains these problems and describes a solution.

Explicit care must be taken when using a routing protocol on a network tunnel. If a router tries to reach the remote router’s encapsulating interface (transport IP address) via the tunnel (overlay network), problems will occur. This is a common issue when the transport network is advertised into the same routing protocol that runs on the overlay network.

For example, say that a network administrator accidentally adds the 100.64.0.0/16 Internet-facing interfaces to OSPF on R1 and R2. The ISP routers are not running OSPF, so an adjacency does not form, but R1 and R2 advertise the Internet-facing IP addresses to each other over the GRE tunnel via OSPF, and since they would be more specific than the configured default static routes, they would be preferred and installed on the routing table. The routers would then try to use the tunnel to reach the tunnel endpoint address, which is not possible. This scenario is known as recursive routing.

A router detects recursive routing and generates a syslog message, as shown in Example 16-6. The tunnel is brought down, which terminates the OSPF adjacencies, and then R1 and R2 find each other by using the default route again. The tunnel is re-established, OSPF forms an adjacency, and the problem repeats over and over again.

Example 16-6 Recursive Routing Syslogs

! Internet interface added to OSPF on R1                                                          

R1(config)# router ospf 1
R1(config-router)# network 100.64.1.1 0.0.0.0 area 1
! Internet interface added to OSPF on R2                                             
R2(config)# router ospf 1
R2(config-router)# network 100.64.2.2 0.0.0.0 area 2

! Once the tunnel source interface or source IP address is advertised into OSPF, the 
! recursive routing issue starts and syslogs alerting on a recursive routing issue   
are
! generated                                                                          
01:56:24.808: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100, changed
              state to up
01:56:24.843: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel100 from LOADING
              to FULL, Loading Done

! The Midchain syslog indicates the tunnel destination was learnt through the tunnel 
! itself. This is resolved by learning the tunnel destination through an interface   
! other than the tunnel                                                              
01:56:34.829: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of
              Tunnel100 - looped chain attempting to stack

! The following syslog indicates a recursive routing issue is occurring on the tunnel
01:56:39.808: %TUN-5-RECURDOWN: Tunnel100 temporarily disabled due to recursive
              routing
01:56:39.808: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100, changed
              state to down
01:56:39.811: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel100 from FULL to
              DOWN, Neighbor Down: Interface down or detached
01:57:44.813: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100, changed
              state to up
01:57:44.849: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel100 from LOADING to
              FULL, Loading Done
! This condition will cycle over and over until the recursive routing issue is
resolved
01:57:54.834: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of
              Tunnel100 - looped chain attempting to stack
01:57:59.813: %TUN-5-RECURDOWN: Tunnel100 temporarily disabled due to recursive
              routing
01:57:59.813: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100, changed
              state to down
01:57:59.818: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel100 from FULL to
              DOWN, Neighbor Down: Interface down or detached

Recursive routing problems are remediated by preventing the tunnel endpoint address from being advertised across the tunnel network. For the issue shown in Example 16-6, removing the tunnel endpoint interfaces (Internet-facing interfaces) from OSPF would stabilize the topology.

IPsec Fundamentals

IPsec is a framework of open standards for creating highly secure virtual private networks (VPNs) using various protocols and technologies for secure communication across unsecure networks, such as the Internet. IPsec tunnels provide the security services listed in Table 16-3.

Table 16-3 IPsec Security Services

Security Service

Description

Methods Used

Peer authentication

Verifies the identity of the VPN peer through authentication.

  • Pre-Shared Key (PSK)

  • Digital certificates

Data confidentiality

Protects data from eavesdropping attacks through encryption algorithms. Changes plaintext into encrypted ciphertext.

  • Data Encryption Standard (DES)

  • Triple DES (3DES)

  • Advanced Encryption Standard (AES)

The use of DES and 3DES is not recommended.

Data integrity

Prevents man-in-the-middle (MitM) attacks by ensuring that data has not been tampered with during its transit across an unsecure network.

Hash Message Authentication Code (HMAC) functions:

  • Message Digest 5 (MD5) algorithm

  • Secure Hash Algorithm (SHA-1)

The use of MD5 is not recommended.

Replay detection

Prevents MitM attacks where an attacker captures VPN traffic and replays it back to a VPN peer with the intention of building an illegitimate VPN tunnel.

Every packet is marked with a unique sequence number. A VPN device keeps track of the sequence number and does not accept a packet with a sequence number it has already processed.

IPsec uses two different packet headers to deliver the security services mentioned in Table 16-3:

  • Authentication header

  • Encapsulating Security Payload (ESP)

Authentication Header

The IP authentication header provides data integrity, authentication, and protection from hackers replaying packets. The authentication header ensures that the original data packet (before encapsulation) has not been modified during transport on the public network. It creates a digital signature similar to a checksum to ensure that the packet has not been modified, using protocol number 51 located in the IP header. The authentication header does not support encryption (data confidentiality) and NAT traversal (NAT-T), and for this reason, its use is not recommended, unless authentication is all that is desired.

Encapsulating Security Payload

Encapsulating Security Payload (ESP) provides data confidentiality, authentication, and protection from hackers replaying packets. Typically, payload refers to the actual data minus any headers, but in the context of ESP, the payload is the portion of the original packet that is encapsulated within the IPsec headers. ESP ensures that the original payload (before encapsulation) maintains data confidentiality by encrypting the payload and adding a new set of headers during transport across a public network. ESP uses the protocol number 50, located in the IP header. Unlike the authentication header, ESP does provide data confidentiality and supports NAT-T.

Traditional IPsec provides two modes of packet transport:

  • Tunnel mode: Encrypts the entire original packet and adds a new set of IPsec headers. These new headers are used to route the packet and also provide overlay functions.

  • Transport mode: Encrypts and authenticates only the packet payload. This mode does not provide overlay functions and routes based on the original IP headers.

Figure 16-3 shows an original packet, an IPsec packet in transport mode, and an IPsec packet in tunnel mode.

A figure depicts IPsec transport and tunnel encapsulation.

Figure 16-3 IPsec Transport and Tunnel Encapsulation

IPsec supports the following encryption, hashing, and keying methods to provide security services:

  • Data Encryption Standard (DES): A 56-bit symmetric data encryption algorithm that can encrypt the data sent over a VPN. This algorithm is very weak and should be avoided.

  • Triple DES (3DES): A data encryption algorithm that runs the DES algorithm three times with three different 56-bit keys. Using this algorithm is no longer recommended. The more advanced and more efficient AES should be used instead.

  • Advanced Encryption Standard (AES): A symmetric encryption algorithm used for data encryption that was developed to replace DES and 3DES. AES supports key lengths of 128 bits, 192 bits, or 256 bits and is based on the Rijndael algorithm.

  • Message Digest 5 (MD5): A one-way, 128-bit hash algorithm used for data authentication. Cisco devices use MD5 HMAC, which provides an additional level of protection against MitM attacks. Using this algorithm is no longer recommended, and SHA should be used instead.

  • Secure Hash Algorithm (SHA): A one-way, 160-bit hash algorithm used for data authentication. Cisco devices use the SHA-1 HMAC, which provides additional protection against MitM attacks.

  • Diffie-Hellman (DH): An asymmetric key exchange protocol that enables two peers to establish a shared secret key used by encryption algorithms such as AES over an unsecure communications channel. A DH group refers to the length of the key (modulus size) to use for a DH key exchange. For example, group 1 uses 768 bits, group 2 uses 1024, and group 5 uses 1536, where the larger the modulus, the more secure it is. The purpose of DH is to generate shared secret symmetric keys that are used by the two VPN peers for symmetrical algorithms, such as AES. The DH exchange itself is asymmetrical and CPU intensive, and the resulting shared secret keys that are generated are symmetrical. Cisco recommends avoiding DH groups 1, 2, and 5 and instead use DH groups 14 and higher.

  • RSA signatures: A public-key (digital certificates) cryptographic system used to mutually authenticate the peers.

  • Pre-Shared Key: A security mechanism in which a locally configured key is used as a credential to mutually authenticate the peers.

Transform Sets

A transform set is a combination of security protocols and algorithms. During the IPsec SA negotiation, the peers agree to use a particular transform set for protecting a particular data flow. When such a transform set is found, it is selected and applied to the IPsec SAs on both peers. Table 16-4 shows the allowed transform set combinations.

Table 16-4 Allowed Transform Set Combinations

Transform Type

Transform

Description

Authentication header transform (only one allowed)

ah-md5-hmac

Authentication header with the MD5 authentication algorithm (not recommended)

 

ah-sha-hmac

Authentication header with the SHA authentication algorithm

 

ah-sha256-hmac

Authentication header with the 256-bit AES authentication algorithm

 

ah-sha384-hmac

Authentication header with the 384-bit AES authentication algorithm

 

ah-sha512-hmac

Authentication header with the 512-bit AES authentication algorithm

ESP encryption transform (only one allowed)

esp-aes

ESP with the 128-bit AES encryption algorithm

 

esp-gcm

esp-gmac

ESP with either a 128-bit (default) or a 256-bit encryption algorithm

 

esp-aes 192

ESP with the 192-bit AES encryption algorithm

 

esp-aes 256

ESP with the 256-bit AES encryption algorithm

 

esp-des

esp-3des

ESPs with 56-bit and 168-bit DES encryption (no longer recommended)

 

esp-null

Null encryption algorithm

 

esp-seal

ESP with the 160-bit SEAL encryption algorithm

ESP authentication transform (only one allowed)

esp-md5-hmac

ESP with the MD5 (HMAC variant) authentication algorithm (no longer recommended)

 

esp-sha-hmac

ESP with the SHA (HMAC variant) authentication algorithm

IP compression transform

comp-lzs

IP compression with the Lempel-Ziv-Stac (LZS) algorithm

Note

The authentication header and ESP algorithms cannot be specified on the same transform set in Cisco IOS XE releases.

Internet Key Exchange

Internet Key Exchange (IKE) is a protocol that performs authentication between two endpoints to establish security associations (SAs), also known as IKE tunnels. These security associations, or tunnels, are used to carry control plane and data plane traffic for IPsec. There are two versions of IKE: IKEv1 (specified in RFC 2409) and IKEv2 (specified in RFC 7296). IKEv2 was developed to overcome the limitations of IKEv1 and provides many improvements over IKEv1’s implementation. For example, it supports EAP (certificate-based authentication), has anti-DoS capabilities, and needs fewer messages to establish an IPsec SA. Understanding IKEv1 is still important because some legacy infrastructures have not yet migrated to IKEv2 or have devices or features that don’t support IKEv2.

IKEv1

Internet Security Association Key Management Protocol (ISAKMP) is a framework for authentication and key exchange between two peers to establish, modify, and tear down SAs. It is designed to support many different kinds of key exchanges. ISAKMP uses UDP port 500 for communication between peers.

IKE is the implementation of ISAKMP using the Oakley and Skeme key exchange techniques. Oakley provides perfect forward secrecy (PFS) for keys, identity protection, and authentication; Skeme provides anonymity, repudiability, and quick key refreshment. For Cisco platforms, IKE is analogous to ISAKMP, and the two terms are used interchangeably.

IKEv1 defines two phases of key negotiation for IKE and IPsec SA establishment:

  • Phase 1: Establishes a bidirectional SA between two IKE peers, known as an ISAKMP SA. Because the SA is bidirectional, once it is established, either peer may initiate negotiations for phase 2.

  • Phase 2: Establishes unidirectional IPsec SAs, leveraging the ISAKMP SA established in phase 1 for the negotiation.

Phase 1 negotiation can occur using main mode (MM) or aggressive mode (AM). The peer that initiates the SA negotiation process is known as the initiator, and the other peer is known as the responder.

Main mode consists of six message exchanges and tries to protect all information during the negotiation so that no information is exposed to eavesdropping:

  • MM1: This is the first message that the initiator sends to a responder. One or multiple SA proposals are offered, and the responder needs to match one of the them for this phase to succeed. The SA proposals include different combinations of the following:

    • Hash algorithm: MD5 or SHA

    • Encryption algorithm: DES (bad), 3DES (better but not recommended), or AES (best)

    • Authentication method: Pre-Shared Key or digital certificates

    • Diffie-Hellman (DH) group: Group 1, 2, 5, and so on

    • Lifetime: How long until this IKE Phase 1 tunnel should be torn down (default is 24 hours). This is the only parameter that does not have to exactly match with the other peer to be accepted. If the lifetime is different, the peers agree to use the smallest lifetime between them.

  • MM2: This message is sent from the responder to the initiator with the SA proposal that it matched.

  • MM3: In this message, the initiator starts the DH key exchange. This is based on the DH group the responder matches in the proposal.

  • MM4: The responder sends its own key to the initiator. At this point, encryption keys have been shared, and encryption is established for the ISAKMP SA.

  • MM5: The initiator starts authentication by sending the peer router its IP address.

  • MM6: The responder sends back a similar packet and authenticates the session. At this point, the ISAKMP SA is established.

When main mode is used, the identities of the two IKE peers are hidden. Although this mode of operation is very secure, it takes longer than aggressive mode to complete the negotiation.

Aggressive mode consists of a three-message exchange and takes less time to negotiate keys between peers; however, it doesn’t offer the same level of encryption security provided by main mode negotiation, and the identities of the two peers trying to establish a security association are exposed to eavesdropping. These are the three aggressive mode messages:

  • AM1: In this message, the initiator sends all the information contained in MM1 through MM3 and MM5.

  • AM2: This message sends all the same information contained in MM2, MM4, and MM6.

  • AM3: This message sends the authentication that is contained in MM5.

Main mode is slower than aggressive mode, but main mode is more secure and more flexible because it can offer an IKE peer more security proposals than aggressive mode. Aggressive mode is less flexible and not as secure, but it is much faster.

Phase 2 uses the existing bidirectional IKE SA to securely exchange messages to establish one or more IPsec SAs between the two peers. Unlike the IKE SA, which is a single bidirectional SA, a single IPsec SA negotiation results in two unidirectional IPsec SAs, one on each peer. The method used to establish the IPsec SA is known as quick mode. Quick mode uses a three-message exchange:

  • QM1: The initiator (which could be either peer) can start multiple IPsec SAs in a single exchange message. This message includes agreed-upon algorithms for encryption and integrity decided as part of phase 1, as well as what traffic is to be encrypted or secured.

  • QM2: This message from the responder has matching IPsec parameters.

  • QM3: After this message, there should be two unidirectional IPsec SAs between the two peers.

Perfect Forward Secrecy (PFS) is an additional function for phase 2 that is recommended but is optional because it requires additional DH exchanges that require additional CPU cycles. The goal of this function is to create greater resistance to crypto attacks and maintain the privacy of the IPsec tunnels by deriving session keys independently of any previous key. This way, a compromised key does not compromise future keys.

Based on the minimum number of messages that aggressive, main, and quick modes may produce for IPsec SAs to be established between two peers, the following can be derived:

  • Main mode uses six messages, and quick mode uses three, for a total of nine messages.

  • Aggressive mode uses three messages, and quick mode uses three, for a total of six messages.

IKEv2

IKEv2 is an evolution of IKEv1 that includes many changes and improvements that simplify it and make it more efficient. One of the major changes has to do with the way the SAs are established. In IKEv2, communications consist of request and response pairs called exchanges and sometimes just called request/response pairs.

The first exchange, IKE_SA_INIT, negotiates cryptographic algorithms, exchanges nonces, and performs a Diffie-Hellman exchange. This is the equivalent to IKEv1’s first two pairs of messages MM1 to MM4 but done as a single request/response pair.

The second exchange, IKE_AUTH, authenticates the previous messages and exchanges identities and certificates. Then it establishes an IKE SA and a child SA (the IPsec SA). This is equivalent to IKEv1’s MM5 to MM6 as well as QM1 and QM2 but done as a single request/response pair.

It takes a total of four messages to bring up the bidirectional IKE SA and the unidirectional IPsec SAs, as opposed to six with IKEv1 aggressive mode or nine with main mode.

If additional IPsec SAs are required in IKEv2, it uses just two messages (a request/response pair) with a CREATE_CHILD_SA exchange, whereas IKEv1 would require three messages with quick mode.

Since the IKEv2 SA exchanges are completely different from those of IKEv1, they are incompatible with each other.

Table 16-5 illustrates some of the major differences between IKEv1 and IKEv2.

Table 16-5 Major Differences Between IKEv1 and IKEv2

IKEv1

Exchange Modes

IKEv2

Main mode

IKE Security Association Initialization (SA_INIT)

Aggressive mode

IKE_Auth

Quick mode

CREATE_CHILD_SA

Minimum Number of Messages Needed to Establish IPsec SAs

Nine with main mode

Four

Six with aggressive mode

 

Supported Authentication Methods

Pre-Shared Key (PSK)

Pre-Shared Key

Digital RSA Certificate (RSA-SIG)

Digital RSA Certificate (RSA-SIG)

Public key

Elliptic Curve Digital Signature Certificate (ECDSA-SIG)

Both peers must use the same authentication method.

Extensible Authentication Protocol (EAP)

Asymmetric authentication is supported. Authentication method can be specified during the IKE_AUTH exchange.

Next Generation Encryption (NGE)

Not supported

AES-GCM (Galois/Counter Mode) mode

 

SHA-256

 

SHA-384

 

SHA-512

 

HMAC-SHA-256

 

Elliptic Curve Diffie-Hellman (ECDH) ECDH-384

 

ECDSA-384

Attack Protection

MitM protection

MitM protection

Eavesdropping protection

Eavesdropping protection

 

Anti-DoS protection

Note

For additional information on the differences between IKEv1 and IKEv2, consult RFC 7296.

Following are additional details about some of the new IKEv2 changes and improvements mentioned in Table 16-5:

  • Increased efficiency: The exchanges are restructured to be lighter, so fewer exchanges and less bandwidth are required to establish SAs as compared to using IKEv1.

  • Elliptic Curve Digital Signature Algorithm (ECDSA-SIG): This is a newer alternative to public keys that is more efficient. It was introduced to IKEv1 late, as part of RFC 4754, and has seen little acceptance there, but it is widely deployed with IKEv2. For this reason, it is not included in Table 16-5 as an authentication method for IKEv1.

  • Extensible Authentication Protocol (EAP): The addition of EAP made IKEv2 the perfect solution for remote-access VPNs.

  • Next generation encryption (NGE): Security threats as well as cryptography to counteract these threats are continuously evolving. Old cryptography algorithms and key sizes no longer provide adequate protection from modern security threats and should be replaced. Next generation encryption (NGE) algorithms offer the best technologies for future-proof cryptography that meets the security and scalability requirements of the next two decades.

  • Asymmetric authentication: IKEv2 removes the requirement to negotiate the authentication method and introduces the ability to specify the authentication method in the IKE_AUTH exchange. As a result, each peer is able to choose its method of authentication. This allows for asymmetric authentication to occur, so the peers can use different authentication methods.

  • Anti-DoS: IKEv2 detects whether an IPsec router is under attack and prevents consumption of resources.

Note

For more information on next generation encryption, see https://www.cisco.com/c/en/us/about/security-center/next-generation-cryptography.html.

IPsec VPNs

As mentioned earlier in this chapter, VPNs allow private networks to communicate with each other across an untrusted network such as the Internet; they should communicate in a secure manner. This section describes the different VPN security solutions available.

Table 16-6 includes the currently available IPsec VPN security solutions, each of which has benefits and is customized to meet specific deployment requirements.

Table 16-6 Cisco IPsec VPN Solutions

Features and Benefits

Site-to-Site IPsec VPN

Cisco DMVPN

Cisco GET-VPN

FlexVPN

Remote Access VPN

Product interoperability

Multivendor

Cisco only

Cisco only

Cisco only

Cisco only

Key exchange

IKEv1 and IKEv2

IKEv1 and IKEv2 (both optional)

IKEv1 and IKEv2

IKEv2 only

TLS/DTLS and IKEv2

Scale

Low

Thousands for hub-and-spoke; hundreds for partially meshed spoke- to-spoke connections

Thousands

Thousands

Thousands

Topology

Hub-and-spoke; small-scale meshing as manageability allows

Hub-and-spoke; on-demand spoke- to-spoke partial mesh; spoke-to-spoke connections automatically terminated when no traffic present

Hub-and-spoke; any-to-any

Hub-and-spoke; any-to-any, remote access

Remote access

Routing

Not supported

Supported

Supported

Supported

Not supported

QoS

Supported

Supported

Supported

Native support

Supported

Multicast

Not supported

Tunneled

Natively supported across MPLS and private IP networks

Tunneled

Not supported

Non-IP protocols

Not supported

Not supported

Not supported

Not supported

Not supported

Private IP addressing

Supported

Supported

Requires use of GRE or DMVPN with Cisco GET-VPN to support private addresses across the Internet

Supported

Supported

High availability

Stateless failover

Routing

Routing

Routing IKEv2-based dynamic route distribution and server clustering

Not supported

Encapsulation

Tunneled IPsec

Tunneled IPsec

Tunnel-less IPsec

Tunneled IPsec

Tunneled IPsec/TLS

Transport network

Any

Any

Private WAN/MPLS

Any

Any

Site-to-Site (LAN-to-LAN) IPsec VPNs

Site-to-site IPsec VPNs are the most versatile solution for site-to-site encryption because they allow for multivendor interoperability. However, they are very difficult to manage in large networks.

Cisco Dynamic Multipoint VPN (DMVPN)

Simplifies configuration for hub-and-spoke and spoke-to-spoke VPNs. It accomplishes this by combining multipoint GRE (mGRE) tunnels, IPsec, and Next Hop Resolution Protocol (NHRP).

Cisco Group Encrypted Transport VPN (GET VPN)

Developed specifically for enterprises to build any-to-any tunnel-less VPNs (where the original IP header is used) across service provider MPLS networks or private WANs. It does this without affecting any of the existing MPLS private WAN network services (such as multicast and QoS). Moreover, encryption over private networks addresses regulatory-compliance guidelines such as those in the Health Insurance Portability and Accountability Act (HIPAA), Sarbanes-Oxley Act, the Payment Card Industry Data Security Standard (PCI DSS), and the Gramm-Leach-Bliley Act (GLBA).

Cisco FlexVPN

FlexVPN is Cisco’s implementation of the IKEv2 standard, featuring a unified VPN solution that combines site-to-site, remote access, hub-and-spoke topologies and partial meshes (spoke-to-spoke direct). FlexVPN offers a simple but modular framework that extensively uses virtual access interfaces while remaining compatible with legacy VPN implementations using crypto maps.

Remote VPN Access

Remote VPN access allows remote users to securely VPN into a corporate network. It is supported on IOS with FlexVPN (IKEv2 only) and on ASA 5500-X and FirePOWER firewalls.

Site-to-Site IPsec Configuration

The GRE configuration example earlier in this chapter allowed for traffic between private sites to flow over the Internet. The problem with this solution is that GRE offers no encryption, authentication, or associated security services, so it is highly susceptible to attacks. One solution is to encrypt the traffic going over the GRE tunnel with IPsec. The following sections explore configuration and verification for the following site-to-site (also known as LAN-to-LAN) IPsec solutions:

  • Site-to-site GRE over IPsec with Pre-Shared Key

  • Site-to-site static virtual tunnel interfaces (VTIs) over IPsec with Pre-Shared Key

VTI over IPsec encapsulates IPv4 or IPv6 traffic without the need for an additional GRE header, while GRE over IPsec first encapsulates traffic within GRE and a new IP header before encapsulating the resulting GRE/IP packet in IPsec transport mode. Figure 16-4 illustrates a comparison of GRE packet encapsulation and IPsec tunnel mode with a VTI.

An illustration of the GRE packet encapsulation and IPsec tunnel mode is shown.

Figure 16-4 GRE over IPsec Versus IPsec Tunnel Mode

Site-to-Site GRE over IPsec

There are two different ways to encrypt traffic over a GRE tunnel:

  • Using crypto maps

  • Using tunnel IPsec profiles

Crypto maps should not be used for tunnel protection because they have many limitations that are resolved with IPsec profiles, including the following:

  • Crypto maps cannot natively support the use of MPLS.

  • Configuration can become overly complex.

  • Crypto ACLs are commonly misconfigured.

  • Crypto ACL entries can consume excessive amounts of TCAM space.

Even though crypto maps are no longer recommended for tunnels, they are still widely deployed and should be understood.

The steps to enable IPsec over GRE using crypto maps are as follows:

Step 1. Configure a crypto ACL to classify VPN traffic by using these commands:

ip access-list extended acl_name

permit gre host {tunnel-source IP} host {tunnel-destination IP}

This access list identifies traffic that needs to be protected by IPsec. It is used to match all traffic that passes through the GRE tunnel.

Step 2. Configure an ISAKMP policy for IKE SA by using the command crypto isakmp policy priority. Within the ISAKMP policy configuration mode, encryption, hash, authentication, and the DH group can be specified with the following commands:

encryption {des | 3des | aes | aes 192 | aes 256}

hash {sha | sha256 | sha384 | md5}

authentication {rsa-sig | rsa-encr | pre-share}

group {1 | 2 | 5 | 14 | 15 | 16 | 19 | 20 | 24}

The keyword priority uniquely identifies the IKE policy and assigns a priority to the policy, where 1 is the highest priority.

The DES and 3DES encryption algorithms are no longer recommended. DES is the default encryption used, so it is recommended to choose one of the AES encryption algorithms

The MD5 hash is no longer recommended. The default is SHA.

Authentication allows for public keys (rsa-encr), digital certificates (rsa-sig), or PSK (pre-share) to be used.

The group command indicates the DH group, where 1 is the default. It is recommended to choose one of the DH groups higher than 14. The following DH groups are available:

  • 1: 768-bit DH (no longer recommended)

  • 2: 1024-bit DH (no longer recommended)

  • 5: 1536-bit DH (no longer recommended)

  • 14: The 2048-bit DH group

  • 15: The 3072-bit DH group

  • 16: The 4096-bit DH group

  • 19: The 256-bit ECDH group

  • 20: The 384-bit ECDH group

  • 24: The 2048-bit DH/DSA group

Step 3. Configure PSK by using the command crypto isakmp key keystring address peer-address [mask]. The keystring should match on both peers. For peer-address [mask], the value 0.0.0.0 0.0.0.0 can be used to allow a match against any peer.

Step 4. Create a transform set and enter transform set configuration mode by using the command crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]. In transform set configuration mode, enter the command mode [tunnel | transport] to specify tunnel or transport modes. During the IPsec SA negotiation, the peers agree to use a particular transform set for protecting a particular data flow. mode indicates the IPsec tunnel mode to be either tunnel or transport.

Step 5. Configure a crypto map and enter crypto map configuration mode by using the command crypto map map-name seq-num [ipsec-isakmp]. In crypto map configuration mode, use the following commands to specify the crypto ACL to be matched, the IPsec peer, and the transform sets to be negotiated:

match address acl-name

set peer {hostname | ip-address}

set transform-set transform-set-name1 [transform-set-name2...transform-set-name6]

acl-name is the crypto ACL defined in step 1, which determines the traffic that should be protected by IPsec. The command set peer can be repeated for multiple remote peers. The command set transform-set specifies the transform sets to be negotiated. List multiple transform sets in priority order (highest priority first).

Step 6. Apply a crypto map to the outside interface by using the command crypto map map-name.

The steps to enable IPsec over GRE using IPsec profiles are as follows:

Step 1. Configure an ISAKMP policy for IKE SA by entering the command crypto isakmp policy priority. Within the ISAKMP policy configuration mode, encryption, hash, authentication, and the DH group can be specified with the following commands:

encryption {des | 3des | aes | aes 192 | aes 256}

hash {sha | sha256 | sha384 | md5}

authentication {rsa-sig | rsa-encr | pre-share}

group {1 | 2 | 5 | 14 | 15 | 16 | 19 | 20 | 24}

Step 2. Configure PSK by using the command crypto isakmp key keystring address peer-address [mask]. keystring should match on both peers.

Step 3. Create a transform set and enter transform set configuration mode by using the command crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]. In the transform set configuration mode, enter the command mode [tunnel | transport] to specify tunnel or transport modes. During the IPsec SA negotiation, the peers agree to use a particular transform set for protecting a particular data flow. mode indicates the IPsec tunnel mode to be either tunnel or transport. To avoid double encapsulation (from GRE and IPsec), transport mode should be chosen.

Step 4. Create an IPsec profile and enter IPsec profile configuration mode by entering the command crypto ipsec profile ipsec-profile-name. In IPsec profile configuration mode, specify the transform sets to be negotiated by using the command set transform-set transform-set-name [transform-set-name2...transform-set-name6]. List multiple transform sets in priority order (highest priority first).

Step 5. Apply the IPsec profile to a tunnel interface by using the command tunnel protection ipsec profile profile-name.

Example 16-7 shows a configuration example for a site-to-site IPsec tunnel using GRE over IPsec with Pre-Shared Key. R1 is configured for IPsec over GRE using crypto maps, and R2 is configured for IPsec over GRE using IPsec profiles, using the configuration steps outlined above. For easier identification of the differences between the configuration options, the configuration portions that remain exactly the same between the two are highlighted in gray.

Example 16-7 Configuring GRE over IPsec Site-to-Site Tunnel with Pre-Shared Key

R1
crypto isakmp policy 10                                                                           
authentication pre-share                                                                          
hash sha256                                                                                       
encryption aes                                                                                    
group 14                                                                                          
!                                                                                                 
crypto isakmp key CISCO123 address 100.64.2.2                                                     
!                                                                                                 
crypto ipsec transform-set AES_SHA esp-aes esp-sha-hmac                                           
mode transport                                                                                     
!
ip access-list extended GRE_IPSEC_VPN
permit gre host 100.64.1.1 host 100.64.2.2
!
crypto map VPN 10 ipsec-isakmp
match address GRE_IPSEC_VPN
set transform AES_SHA
set peer 100.64.2.2
!
interface GigabitEthernet0/1                                                                      
 ip address 100.64.1.1 255.255.255.252                                                            
crypto map VPN
!
interface Tunnel100                                                                               
 bandwidth 4000                                                                                   
 ip address 192.168.100.1 255.255.255.0                                                           
 ip mtu 1400                                                                                      
 tunnel source GigabitEthernet0/1                                                                 
 tunnel destination 100.64.2.2                                                                    

router ospf 1                                                                                     
 router-id 1.1.1.1                                                                                
 network 10.1.1.1 0.0.0.0 area 1                                                                  
 network 192.168.100.1 0.0.0.0 area 0                                                             
R2
crypto isakmp policy 10                                                                           
authentication pre-share                                                                          
hash sha256                                                                                       
encryption aes                                                                                    
group 14                                                                                          

crypto isakmp key CISCO123 address 100.64.1.1                                                     

crypto ipsec transform-set AES_SHA esp-aes esp-sha-hmac                                           
mode transport                                                                                    

crypto ipsec profile IPSEC_PROFILE
 set transform-set AES_SHA

interface GigabitEthernet0/1                                                                      
 ip address 100.64.2.2 255.255.255.252                                                            

interface Tunnel100                                                                               
 bandwidth 4000                                                                                   
 ip address 192.168.100.2 255.255.255.0                                                           
 ip mtu 1400                                                                                      

 tunnel source GigabitEthernet0/1                                                                 
 tunnel destination 100.64.1.1                                                                    
 tunnel protection ipsec profile IPSEC_PROFILE

router ospf 1                                                                                     
 router-id 2.2.2.2                                                                                
 network 10.2.2.0 0.0.0.255 area 2                                                                
 network 192.168.100.2 0.0.0.0 area 0                                                               

Example 16-8 shows the commands to verify that the GRE IPsec tunnel between R1 and R2 is operational and demonstrates how crypto maps and IPsec profile configuration options are compatible with each other.

Example 16-8 Verifying GRE over IPsec Site-to-Site Tunnel with Pre-Shared Key

! The following command shows the tunnel type is GRE                                              
R1# show interface tunnel100 | include Tunnel protocol
  Tunnel protocol/transport GRE/IP                                                                
R1#
! OSPF adjacency is established over the encrypted tunnel                                         
R1# show ip ospf neighbor


Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:38    192.168.100.2   Tunnel100                       
! OSPF routes from the IPsec peer are learnt over tunnel 100                                      
R1# show ip route ospf
! Output omitted for brevity                                                                      
Gateway of last resort is 100.64.1.2 to network 0.0.0.0


      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA     10.2.2.0/24 [110/26] via 192.168.100.2, 00:03:30, Tunnel100                              
! The following output shows the ISAKMP SA status is active and in a QM_IDLE state. 
QM_IDLE means the SA remains authenticated with its peer and may be used for subsequent
quick mode exchanges for additional IPsec SAs.
R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
100.64.1.1      100.64.2.2      QM_IDLE           1008 ACTIVE                          
! The following command displays information about the IPsec SA                     
R1# show crypto ipsec sa
! Output omitted for brevity                                                        

! pkts encaps shows the number of outgoing packets that have been encapsulated      
! pkts encrypt shows the number of outgoing packets that have been decrypted        
! pkts decaps shows the number of incoming packets that have been decapsulated      
! pkts decrypt shows the number of incoming packets that have been decrypted         

    #pkts encaps: 40, #pkts encrypt: 40, #pkts digest: 40                           
    #pkts decaps: 38, #pkts decrypt: 38, #pkts verify: 38                           
..                                                                                  
! The following output shows there is an IPsec SA established with 100.64.2.2       
     local crypto endpt.: 100.64.1.1, remote crypto endpt.: 100.64.2.2              
..                                                                                  
! The following output shows the IPsec SA is active as well as the transform set and
the transport mode negotiated for both IPsec SAs
     inbound esp sas:
      spi: 0x1A945CC1(445930689)
       transform: esp-aes esp-sha-hmac ,
        in use settings ={Transport, }
..
        Status: ACTIVE(ACTIVE)
     outbound esp sas:
      spi: 0xDBE8D78F(3689469839)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Transport, }
..
        Status: ACTIVE(ACTIVE)
Site-to-Site VTI over IPsec

The steps to enable a VTI over IPsec are very similar to those for GRE over IPsec configuration using IPsec profiles. The only difference is the addition of the command tunnel mode ipsec {ipv4 | ipv6} under the GRE tunnel interface to enable VTI on it and to change the packet transport mode to tunnel mode. To revert to GRE over IPsec, the command tunnel mode gre {ip | ipv6} is used.

Example 16-9 shows an example of the configuration changes that need to be made to the GRE over IPsec configuration to enable VTI over IPsec.

Example 16-9 Configuring VTI over IPsec Site-to-Site Tunnel with Pre-Shared Key

R1
!Remove crypto map from g0/1                                                                      

interface g0/1
no crypto map VPN

!Configure IPsec transform set                                                                    

crypto ipsec transform-set AES_SHA esp-aes esp-sha-hmac
mode transport

!Configure IPsec profile                                                                          

crypto ipsec profile IPSEC_PROFILE
 set transform-set AES_SHA
!
!Enable VTI on tunnel interface and apply IPSec profile                                           
interface Tunnel100
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC_PROFILE
R2
!Enable VTI on tunnel interface                                                                   

interface Tunnel100
tunnel mode ipsec ipv4

Example 16-10 shows the verification commands to make sure the VTI IPsec tunnel between R1 and R2 is operational.

Example 16-10 Verifying VTI over IPsec Site-to-Site Tunnel with Pre-Shared Key

! The following command shows the tunnel type is IPSEC                                            
R1# show interface tunnel100 | include Tunnel protocol
  Tunnel protocol/transport IPSEC/IP                                                              
! OSPF adjacency is established over the encrypted tunnel                                         
R1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:33    192.168.100.2   Tunnel100                       
! OSPF routes from the IPsec peer are learnt over tunnel 100                                      
R1# show ip route ospf
! Output omitted for brevity                                                                      
Gateway of last resort is 100.64.1.2 to network 0.0.0.0

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA     10.2.2.0/24 [110/26] via 192.168.100.2, 00:05:25, Tunnel100                              
! The following output shows the ISAKMP SA status is active and in a QM_IDLE state. 
QM_IDLE means the SA remains authenticated with its peer and may be used for subsequent
quick mode exchanges for additional IPsec SAs.
R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
100.64.1.1      100.64.2.2      QM_IDLE           1010 ACTIVE                          
! The following command displays information about the IPsec SA                     
R1# show crypto ipsec sa
! Output omitted for brevity                                                        

! pkts encaps shows the number of outgoing packets that have been encapsulated      
! pkts encrypt shows the number of outgoing packets that have been decrypted        
! pkts decaps shows the number of incoming packets that have been decapsulated       
! pkts decrypt shows the number of incoming packets that have been decrypted        

   #pkts encaps: 47, #pkts encrypt: 47, #pkts digest: 47                            
    #pkts decaps: 46, #pkts decrypt: 46, #pkts verify: 46                           
..                                                                                  
! The following output shows there is an IPsec SA established with 100.64.2.2       
     local crypto endpt.: 100.64.1.1, remote crypto endpt.: 100.64.2.2              
..                                                                                  
..                                                                                  
! The following output shows the IPsec SA is active as well as the transform set and
the transport mode negotiated for both IPsec SAs
     inbound esp sas:
      spi: 0x8F599A4(150313380)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
..
        Status: ACTIVE(ACTIVE)
     outbound esp sas:
      spi: 0x249F3CA2(614415522)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
..
        Status: ACTIVE(ACTIVE)

Cisco Location/ID Separation Protocol (LISP)

The rapid growth of the default-free zone (DFZ), also known as the Internet routing table, led to the development of the Cisco Location/ID Separation Protocol (LISP). LISP is a routing architecture and a data and control plane protocol that was created to address routing scalability problems on the Internet:

  • Aggregation issues: Many routes on the Internet routing table are provider-independent routes that are non-aggregable, and this is part of the reason the Internet routing table is so large and still growing.

  • Traffic engineering: A common practice for ingress traffic engineering into a site is to inject more specific routes into the Internet, which exacerbates the Internet routing table aggregation/scalability problems.

  • Multihoming: Proper multihoming to the Internet requires a full Internet routing table (785,000 IPv4 routes at the time of writing). If a small site requires multihoming, a powerful router is needed to be able to handle the full routing table (with large memory, powerful CPUs, more TCAM, more power, cooling, and so on), which can be cost-prohibitive for deployment across small sites.

  • Routing instability: Internet route instability (also known as route churn) causes intensive router CPU and memory consumption, which also requires powerful routers.

Even though LISP was created to address the routing scalability problems of the Internet, it is also being implemented in other types of environments, such as data centers, campus networks, branches, next-gen WANs, and service provider cores. In addition, it can also serve for applications or use cases such as mobility, network virtualization, Internet of Things (IoT), IPv4-to-IPv6 transition, and traffic engineering.

Figure 16-5 is used as a reference in this section for the definitions of basic LISP terminology.

LISP architecture reference topology is shown.

Figure 16-5 LISP Architecture Reference Topology

Following are the definitions for the LISP architecture components illustrated in Figure 16-5.

  • Endpoint identifier (EID): An EID is the IP address of an endpoint within a LISP site. EIDs are the same IP addresses in use today on endpoints (IPv4 or IPv6), and they operate in the same way.

  • LISP site: This is the name of a site where LISP routers and EIDs reside.

  • Ingress tunnel router (ITR): ITRs are LISP routers that LISP-encapsulate IP packets coming from EIDs that are destined outside the LISP site.

  • Egress tunnel router (ETR): ETRs are LISP routers that de-encapsulate LISP-encapsulated IP packets coming from sites outside the LISP site and destined to EIDs within the LISP site.

  • Tunnel router (xTR): xTR refers to routers that perform ITR and ETR functions (which is most routers).

  • Proxy ITR (PITR): PITRs are just like ITRs but for non-LISP sites that send traffic to EID destinations.

  • Proxy ETR (PETR): PETRs act just like ETRs but for EIDs that send traffic to destinations at non-LISP sites.

  • Proxy xTR (PxTR): PxTR refers to a router that performs PITR and PETR functions.

  • LISP router: A LISP router is a router that performs the functions of any or all of the following: ITR, ETR, PITR, and/or PETR.

  • Routing locator (RLOC): An RLOC is an IPv4 or IPv6 address of an ETR that is Internet facing or network core facing.

  • Map server (MS): This is a network device (typically a router) that learns EID-to-prefix mapping entries from an ETR and stores them in a local EID-to-RLOC mapping database.

  • Map resolver (MR): This is a network device (typically a router) that receives LISP-encapsulated map requests from an ITR and finds the appropriate ETR to answer those requests by consulting the map server.

  • Map server/map resolver (MS/MR): When MS and the MR functions are implemented on the same device, the device is referred to as an MS/MR.

LISP Architecture and Protocols

Now that the basic terminology has been described, the following three LISP main components are explained:

  • LISP routing architecture

  • LISP control plane protocol

  • LISP data plane protocol

LISP Routing Architecture

In traditional routing architectures, an endpoint IP address represents the endpoint’s identity and location. If the location of the endpoint changes, its IP address also changes. LISP separates IP addresses into endpoint identifiers (EIDs) and routing locators (RLOCs). This way, endpoints can roam from site to site, and the only thing that changes is their RLOC; the EID remains the same.

LISP Control Plane

The control plane operates in a very similar manner to the Domain Name System (DNS). Just as DNS can resolve a domain name into an IP address, LISP can resolve an EID into an RLOC by sending map requests to the MR, as illustrated in Figure 16-6. This makes it a very efficient and scalable on-demand routing protocol because it is based on a pull model, where only the routing information that is necessary is requested (as opposed to the push model of traditional routing protocols, such as BGP and OSPF, that push all the routes to the routers—including unnecessary ones).

A figure compares the operation of LISP with DNS.

Figure 16-6 LISP and DNS Comparison

LISP Data Plane

ITRs LISP-encapsulate IP packets received from EIDs in an outer IP UDP header with source and destination addresses in the RLOC space; in other words, they perform IP-in-IP/UDP encapsulation. The original IP header and data are preserved; this is referred to as the inner header. Between the outer UDP header and the inner header, a LISP shim header is included to encode information necessary to enable forwarding plane functionality, such as network virtualization. Figure 16-7 illustrates the LISP packet frame format.

LISP packet format is shown. LISP packet frame contains the following fields: outer Ethernet header, outer LISP IP header, outer LISP UDP header, LISP header, original IP header, and data. The LISP header fields contains the following sub fields: instance ID ad LSBs.

Figure 16-7 LISP Packet Format

The following are descriptions of some of most relevant header fields in Figure 16-7:

Note

For details on the remaining header fields, see RFC 6830.

  • Outer LISP IP header: This IP header is added by an ITR to encapsulate the EID IP addresses.

  • Outer LISP UDP header: The UDP header contains a source port that is tactically selected by an ITR to prevent traffic from one LISP site to another site from taking exactly the same path even if there are equal-cost multipath (ECMP) links to the destination; in other words, it improves load sharing by preventing polarization. The destination UDP port used by the LISP data plane is 4341.

  • Instance ID: This field is a 24-bit value that is used to provide device- and path-level network virtualization. In other words, it enables VRF and VPNs for virtualization and segmentation much as VPN IDs do for MPLS networks. This is useful in preventing IP address duplication within a LISP site or just as a secure boundary between multiple organizations.

  • Original IP header: This is the IP header as received by an EID.

Because EIDs and RLOCs can be either IPv4 or IPv6 addresses, the LISP data plane supports the following encapsulation combinations:

  • IPv4 RLOCs encapsulating IPv4 EIDs

  • IPv4 RLOCs encapsulating IPv6 EIDs

  • IPv6 RLOCs encapsulating IPv4 EIDs

  • IPv6 RLOCs encapsulating IPv6 EIDs

LISP Operation

This section describes the following LISP operational components:

  • Map registration and map notify

  • Map request and map reply

  • LISP data path

  • Proxy ETR

  • Proxy ITR

Map Registration and Notification

When setting up LISP, the ETR routers need to be configured with the EID prefixes within the LISP site that will be registered with the MS. Any subnets attached to the ETR that are not configured as EID prefixes will be forwarded natively using traditional routing. Figure 16-8 illustrates this process.

A figure demonstrates the map registration and notification operation of LISP.

Figure 16-8 Map Registration and Notification

The following steps describe the map registration process illustrated in Figure 16-8:

Step 1. The ETR sends a map register message to the MS to register its associated EID prefix 10.1.2.0/24. In addition to the EID prefix, the message includes the RLOC IP address 100.64.2.2 to be used by the MS when forwarding map requests (re-formatted as encapsulated map requests) received through the mapping database system.

An ETR by default responds to map request messages, but in a map register message it may request that the MS answer map requests on its behalf by setting the proxy map reply flag (P-bit) in the message.

Step 2. The MS sends a map notify message to the ETR to confirm that the map register has been received and processed. A map notify message uses UDP port 4342 for both source and destination.

Map Request and Reply

When an endpoint in a LISP site is trying to communicate to an endpoint outside the LISP site, the ITR needs to perform a series of steps to be able to route the traffic appropriately. Figure 16-9 illustrates this process.

A series of steps performed by the ITR and the map request and reply is represented using a network diagram.

Figure 16-9 Map Request and Reply

Traditional routing is used within a LISP site; for example, an IGP such as OSPF can be configured. For this reason, when the endpoint in LISP Site 1 wants to communicate with the endpoint on LISP Site 2, the typical routing steps to achieve this are followed until the ITR is reached. When the ITR is reached, LISP comes into play. The following steps outline the map request and reply process illustrated in Figure 16-9:

Step 1. The endpoint in LISP Site 1 (host1) sends a DNS request to resolve the IP address of the endpoint in LISP Site 2 (host2.cisco.com). The DNS server replies with the IP address 10.1.2.2, which is the destination EID. host1 sends IP packets with destination IP 10.1.2.2 to its default gateway, which for this example is the ITR router. If host1 was not directly connected to the ITR, the IP packets would be forwarded through the LISP site as normal IP packets, using traditional routing, until they reached the ITR.

Step 2. The ITR receives the packets from host1 destined to 10.1.2.2. It performs a FIB lookup and evaluates the following forwarding rules:

  • Did the packet match a default route because there was no route found for 10.1.2.2 in the routing table?

    • If yes, continue to next step.

    • If no, forward the packet natively using the matched route.

  • Is the source IP a registered EID prefix in the local map cache?

    • If yes, continue to next step.

    • If no, forward the packet natively.

Step 3. The ITR sends an encapsulated map request to the MR for 10.1.2.2. A map request message uses the UDP destination port 4342, and the source port is chosen by the ITR.

Step 4. Because the MR and MS functionality is configured on the same device, the MS mapping database system forwards the map request to the authoritative (source of truth) ETR. If the MR and MS functions were on different devices, the MR would forward the encapsulated map request packet to the MS as received from the ITR, and the MS would then forward the map request packet to the ETR.

Step 5. The ETR sends to the ITR a map reply message that includes an EID-to-RLOC mapping 10.1.2.2 → 100.64.2.2. The map reply message uses the UDP source port 4342, and the destination port is the one chosen by the ITR in the map request message. An ETR may also request that the MS answer map requests on its behalf by setting the proxy map reply flag (P-bit) in the map register message.

Step 6. The ITR installs the EID-to-RLOC mapping in its local map cache and programs the FIB; it is now ready to forward LISP traffic.

LISP Data Path

After the ITR receives the EID-to-RLOC mapping from the ETR (or MS, if the ETR requested a proxy map reply), it is ready to send data from host1 to host2. Figure 16-10 illustrates the data path for a packet originating on host1 as it traverses the RLOC space and arrives at the destination.

A network diagram represents the LISP data path for a packet from host 1 to its destination.

Figure 16-10 LISP Data Path

The following steps describe the encapsulation and de-encapsulation process illustrated in Figure 16-10:

Step 1. The ITR receives a packet from EID host1 (10.1.1.1) destined to host2 (10.2.2.2).

Step 2. The ITR performs a FIB lookup and finds a match. It encapsulates the EID packet and adds an outer header with the RLOC IP address from the ITR as the source IP address and the RLOC IP address of the ETR as the destination IP address. The packet is then forwarded using UDP destination port 4341 with a tactically selected source port in case ECMP load balancing is necessary.

Step 3. ETR receives the encapsulated packet and de-encapsulates it to forward it to host2.

Proxy ETR (PETR)

A proxy ETR (PETR) is a router connected to a non-LISP site (such as a data center or the Internet) that is used when a LISP site needs to communicate to a non-LISP site. Since the PETR is connected to non-LISP sites, a PETR does not register any EID addresses with the mapping database system. When an ITR sends a map request and the EID is not registered in the mapping database system, the mapping database system sends a negative map reply to the ITR. When the ITR receives a negative map reply, it forwards the LISP-encapsulated traffic to the PETR. For this to happen, the ITR must be configured to send traffic to the PETR’s RLOC for any destinations for which a negative map reply is received.

When the mapping database system receives a map request for a non-LISP destination, it calculates the shortest prefix that matches the requested destination but that does not match any LISP EIDs. The calculated non-LISP prefix is included in the negative map reply so that the ITR can add this prefix to its map cache and FIB. From that point forward, the ITR can send traffic that matches that non-LISP prefix directly to the PETR.

Figure 16-11 illustrates the proxy ETR process.

A network diagram shows the proxy ETR process.

Figure 16-11 Proxy ETR Process

The following steps describe the proxy ETR process illustrated in Figure 16-11:

Step 1. host1 perform a DNS lookup for www.cisco.com. It gets a response form the DNS server with IP address 100.64.254.254 and starts forwarding packets to the ITR with the destination IP address 100.64.254.254.

Step 2. The ITR sends a map request to the MR for 100.64.254.254

Step 3. The mapping database system responds with a negative map reply that includes a calculated non-LISP prefix for the ITR to add it to its mapping cache and FIB.

Step 4. The ITR can now start sending LISP-encapsulated packets to the PETR.

Step 5. The PETR de-encapsulates the traffic and sends it to www.cisco.com.

Proxy ITR (PITR)

PITRs receive traffic destined to LISP EIDs from non-LISP sites. PITRs behave in the same way as ITRs: They resolve the mapping for the destination EID and encapsulate and forward the traffic to the destination RLOC. PITRs send map request messages to the MR even when the source of the traffic is coming from a non-LISP site (that is, when the traffic is not originating on an EID). In this situation, an ITR behaves differently because an ITR checks whether the source is registered in the local map cache as an EID before sending a map request message to the MR. If the source isn’t registered as an EID, the traffic is not eligible for LISP encapsulation, and traditional forwarding rules apply.

Figure 16-12 illustrates the proxy ITR process.

A network diagram illustrates the steps involved in the proxy ITR process.

Figure 16-12 Proxy ITR Process

The following steps describe the proxy ITR process illustrated in Figure 16-12:

Step 1. Traffic from www.cisco.com is received by the PITR with the destination IP address 10.1.1.1 from host1.cisco.com.

Step 2. The PITR sends a map request to the MR for 10.1.1.1.

Step 3. The mapping database system forwards the map request to the ETR.

Step 4. The ETR sends a map reply to the PITR with the EID-to-RLOC mapping 10.1.1.1 → 100.64.1.1.

Step 5. The PITR LISP-encapsulates the packets and starts forwarding them to the ETR.

Step 6. The ETR receives the LISP-encapsulated packets, de-encapsulates them, and sends them to host1.

Virtual Extensible Local Area Network (VXLAN)

Server virtualization has placed increased demands on the legacy network infrastructure. A bare-metal server now has multiple virtual machines (VMs) and containers, each with its own MAC address. This has led to a number of problems with traditional Layer 2 networks, such as the following:

  • The 12-bit VLAN ID yields 4000 VLANs, which are insufficient for server virtualization.

  • Large MAC address tables are needed due to the hundreds of thousands of VMs and containers attached to the network.

  • STP blocks links to avoid loops, and this results in a large number of disabled links, which is unacceptable.

  • ECMP is not supported.

  • Host mobility is difficult to implement.

VXLAN is an overlay data plane encapsulation scheme that was developed to address the various issues seen in traditional Layer 2 networks. It extends Layer 2 and Layer 3 overlay networks over a Layer 3 underlay network, using MAC-in-IP/UDP tunneling. Each overlay is termed a VXLAN segment.

The Internet Assigned Numbers Authority (IANA) assigned to VXLAN the UDP destination port 4789; the default UDP destination port used by Linux is 8472. The reason for this discrepancy is that when VXLAN was first implemented in Linux, the VXLAN UDP destination port had not yet been officially assigned, and Linux decided to use port 8472 since many vendors at the time were using UDP destination port 8472. Later, IANA assigned port 4789 for VXLAN, and to avoid breaking existing deployments, Linux distributions decided to leave port 8472 as the default value. Figure 16-13 illustrates the VXLAN packet format.

The packet format of VXLAN is shown.

Figure 16-13 VXLAN Packet Format

Unlike the VLAN ID, which has only 12 bits and allows for 4000 VLANs, VXLAN has a 24-bit VXLAN network identifier (VNI), which allows for up to 16 million VXLAN segments (more commonly known as overlay networks) to coexist within the same infrastructure.

The VNI is located in the VXLAN shim header that encapsulates the original inner MAC frame originated by an endpoint. The VNI is used to provide segmentation for Layer 2 and Layer 3 traffic.

To facilitate the discovery of VNIs over the underlay Layer 3 network, virtual tunnel endpoints (VTEPs) are used. VTEPs are entities that originate or terminate VXLAN tunnels. They map Layer 2 and Layer 3 packets to the VNI to be used in the overlay network. Each VTEP has two interfaces:

  • Local LAN interfaces: These interfaces on the local LAN segment provide bridging between local hosts.

  • IP interface: This is a core-facing network interface for VXLAN. The IP interface’s IP address helps identify the VTEP in the network. It is also used for VXLAN traffic encapsulation and de-encapsulation.

Figure 16-14 illustrates the VXLAN VTEP with the IP interface and the local LAN interface.

A figure shows the topology of VXLAN VTEP. Two VTEPs are shown in the figure. The VTEPs are connected to a core network and consist of both the IP interface and the local LAN interface. Each VTEP is connected to a pair of endpoint devices.

Figure 16-14 VXLAN VTEP

Devices that are not capable of supporting VXLAN and need to use traditional VLAN segmentation can be connected to VXLAN segments by using a VXLAN gateway. A VXLAN gateway is a VTEP device that combines a VXLAN segment and a classic VLAN segment into one common Layer 2 domain.

The VXLAN standard defines VXLAN as a data plane protocol, but it does not define a VXLAN control plane; it was left open to be used with any control plane. Currently four different VXLAN control and data planes are supported by Cisco devices:

  • VXLAN with Multicast underlay

  • VXLAN with static unicast VXLAN tunnels

  • VXLAN with MP-BGP EVPN control plane

  • VXLAN with LISP control plane

MP-BGP EVPN and Multicast are the most popular control planes used for data center and private cloud environments. For campus environments, VXLAN with a LISP control plane is the preferred choice.

Cisco Software Defined Access (SD-Access) is an example of an implementation of VXLAN with the LISP control plane. An interesting fact is that the VXLAN specification originated from a Layer 2 LISP specification (draft-smith-lisp-layer2-00) that aimed to introduce Layer 2 segmentation support to LISP. The VXLAN specification introduced the term VXLAN in lieu of Layer 2 LISP and didn’t port over some of the fields from the Layer 2 LISP specification into the VXLAN specification. The minor differences between the Layer 2 LISP specification and the VXLAN specification headers are illustrated in Figure 16-15. Fields that were not ported over from Layer 2 LISP into VXLAN were reserved for future use.

The packet formats of LISP and VXLAN are shown.

Figure 16-15 LISP and VXLAN Packet Format Comparison

As illustrated in Figure 16-15, LISP encapsulation is only capable of performing IP-in-IP/UDP encapsulation, which allows it to support Layer 3 overlays only, while VXLAN encapsulation is capable of encapsulating the original Ethernet header to perform MAC-in-IP encapsulation, which allows it to support Layer 2 and Layer 3 overlays.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 30, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in the chapter, noted with the key topics icon in the outer margin of the page. Table 16-7 lists these key topics and the page number on which each is found.

Table 16-7 Key Topics for Chapter 16

Key Topic Element

Description

Page

Paragraph

Generic Routing Encapsulation (GRE) definition

439

List

GRE configuration

441

Paragraph

IPsec definition

445

Table 16-3

IPsec Security Services

446

Section

Authentication header

446

Section

Encapsulating Security Payload (ESP)

446

Figure 16-3

IPsec Tunnel and Transport Encapsulation

447

List

IPsec security services definitions

447

Section

Transform sets

448

Section

Internet Key Exchange (IKE)

449

Section

IKEv1

449

Section

IKEv2

452

Table 16-5

Major Differences Between IKEv1 and IKEv2

452

Table 16-6

Cisco IPsec VPN Solutions

454

Paragraph

Virtual tunnel interface (VTI)

456

List

GRE IPsec encryption methods

457

List

IPsec over GRE with crypto maps

457

List

IPsec over GRE with IPsec profiles

459

Section

Site-to-Site VTI over IPsec

462

Paragraph

LISP definition

464

Paragraph

LISP applications

464

List

LISP architecture components

465

Section

LISP routing architecture

466

Section

LISP control plane

466

Section

LISP data plane

467

List

LISP map registration and notification

468

List

LISP map request and reply

469

List

LISP data path

471

List

PETR process

472

List

PITR process

472

Paragraph

VXLAN definition

473

Paragraph

VNI definition

474

List

VTEP definition

474

List

VXLAN control plane

475

Paragraph

LISP and VXLAN packet format comparison

475

Complete Tables and Lists from Memory

Print a copy of Appendix B, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” also on the companion website, includes completed tables and lists you can use to check your work.

Define Key Terms

Define the following key terms from this chapter and check your answers in the Glossary:

egress tunnel router (ETR)

endpoint identifier (EID)

ingress tunnel router (ITR)

Internet Key Exchange (IKE)

Internet Protocol Security (IPsec)

Internet Security Association Key Management Protocol (ISAKMP)

LISP router

LISP site

map resolver (MR)

map server (MS)

map server/map resolver (MS/MR)

nonce

overlay network

proxy ETR (PETR)

proxy ITR (PITR)

proxy xTR (PxTR)

routing locator (RLOC)

segment

segmentation

tunnel router (xTR)

underlay network

virtual private network (VPN)

virtual tunnel endpoint (VTEP)

VXLAN Network Identifier (VNI)

Use the Command Reference to Check Your Memory

Table 16-8 lists the important commands from this chapter. To test your memory, cover the right side of the table with a piece of paper, read the description on the left side, and see how much of the command you can remember.

Table 16-8 Command Reference

Task

Command Syntax

Create a GRE tunnel interface

interface tunnel tunnel-number

Enable keepalives on a GRE tunnel interface

keepalive [seconds [retries]]

Create an ISAKMP policy

crypto isakmp policy priority

Create an IPsec transform set

crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]

Create a crypto map for IPsec

crypto map map-name seq-num [ipsec-isakmp]

Apply a crypto map to an outside interface

crypto map map-name

Create an IPsec profile for tunnel interfaces

crypto ipsec profile ipsec-profile-name

Apply an IPsec profile to a tunnel interface

tunnel protection ipsec profile profile-name

Turn a GRE tunnel into a VTI tunnel

tunnel mode ipsec {ipv4 | ipv6}

Turn a VTI tunnel into a GRE tunnel

tunnel mode gre {ip | ipv6}

Display information about ISAKMP SAs

show crypto isakmp sa

Display detailed information about IPsec SAs

show crypto ipsec sa

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
34.204.177.148