Ejemplo de Configuración de EIGRP en SVTI, DVTI e IKEv2 FlexVPN con el Comando "IP[v6] Unnumbered"

Introducción

Este documento describe cómo configurar el protocolo de routing de gateway interior mejorado (EIGRP) en una serie de escenarios más comunes en Cisco IOS^®. Para aceptar una adyacencia de vecino EIGRP, Cisco IOS debe obtener el paquete HELLO EIGRP de una dirección IP dentro de la misma subred. Es posible inhabilitar esa verificación con el comando ip unnumbered.

La primera parte del artículo presenta una falla de EIGRP cuando recibe un paquete que no está en la misma subred.

Otro ejemplo demuestra el uso del comando ip unnumbered que inhabilita esa verificación y permite que EIGRP forme una adyacencia entre peers que pertenecen a diferentes subredes.

En este artículo también se presenta una implementación de FlexVPN Hub y Spoke con una dirección IP enviada desde el servidor. Para este escenario, la verificación de subredes se inhabilita para el comando ip address negotiated y también para el comando ip unnumbered. El comando ip unnumbered se utiliza principalmente para las interfaces de tipo punto a punto (P2P), lo que hace que FlexVPN sea un ajuste perfecto ya que se basa en una arquitectura P2P.

Por último, se presenta un escenario IPv6 junto con las diferencias tanto para las interfaces de túnel virtual estáticas (SVTI) como para las interfaces de túnel virtual dinámico (DVTI). Hay ligeros cambios en el comportamiento al comparar los escenarios de IPv6 con IPv4.

Además, se presentan los cambios entre las versiones 15.1 y 15.3 del IOS de Cisco (Id. de bug Cisco CSCtx45062).

El comando ip unnumbered siempre es necesario para DVTI. Esto se debe a que las direcciones IP configuradas estáticamente en una interfaz de plantilla virtual nunca se clonan en una interfaz de acceso virtual. Además, una interfaz sin una dirección IP configurada no puede establecer ninguna adyacencia de protocolo de ruteo dinámico. El comando ip unnumbered no es necesario para SVTI, pero sin esa subred, la verificación se realiza cuando se establece la adyacencia del protocolo de ruteo dinámico. Además, el comando ipv6 unnumbered no es necesario para los escenarios IPV6 debido a las direcciones locales de link que se utilizan para generar adyacencias EIGRP.

Prerequisites

Requirements

Cisco recomienda que tenga conocimientos básicos sobre estos temas:

• Configuración de VPN en Cisco IOS
• Configuración de FlexVPN en Cisco IOS

Componentes Utilizados

La información de este documento se basa en la versión 15.3T del IOS de Cisco.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

EIGRP en un segmento Ethernet con diferentes subredes

Topología: Router 1 (R1) (e0/0: 10.0.0.1/24)—(e0/1: 10.0.1.2/24) Router 2 (R2)

R1:
interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.0

router eigrp 100
 network 10.0.0.1 0.0.0.0

R2:
interface Ethernet0/0
 ip address 10.0.1.2 255.255.255.0

router eigrp 100
 network 10.0.1.2 0.0.0.0

R1 muestra:

*Mar 3 16:39:34.873: EIGRP: Received HELLO on Ethernet0/0 nbr 10.0.1.2
*Mar 3 16:39:34.873:   AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0
*Mar 3 16:39:34.873: EIGRP-IPv4(100): Neighbor 10.0.1.2 not on common subnet 
for Ethernet0/0

Cisco IOS no forma una adyacencia, lo que se espera. Para obtener más información sobre esto, refiérase a ¿Qué Significan los Mensajes EIGRP "No en una Subred Común"? artículo.

EIGRP en segmento SVTI con diferentes subredes

La misma situación ocurre cuando se utilizan interfaces de túnel virtual (VTI) (túnel de encapsulación de routing genérico (GRE)).

Topología: R1(Tun1: 172.16.0.1/24)—(Tun1: 172.17.0.2/24) R2

R1:
interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.0
 
interface Tunnel1
 ip address 172.16.0.1 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 10.0.0.2

router eigrp 100
 network 172.16.0.1 0.0.0.0
 passive-interface default
 no passive-interface Tunnel1

R2:
interface Ethernet0/0
 ip address 10.0.0.2 255.255.255.0
 
interface Tunnel1
 ip address 172.17.0.2 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 10.0.0.1

router eigrp 100
 network 172.17.0.2 0.0.0.0
 passive-interface default
 no passive-interface Tunnel1

R1 muestra:

*Mar  3 16:41:52.167: EIGRP: Received HELLO on Tunnel1 nbr 172.17.0.2
*Mar  3 16:41:52.167:   AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0
*Mar  3 16:41:52.167: EIGRP-IPv4(100): Neighbor 172.17.0.2 not on common subnet
for Tunnel1

Debe ocurrir lo siguiente.

Utilice el comando IP Unnumbered

Este ejemplo muestra cómo utilizar el comando ip unnumbered que inhabilita la verificación y permite el establecimiento de una sesión EIGRP entre peers en diferentes subredes.

La topología es similar al ejemplo anterior, pero las direcciones de los túneles se definen ahora a través del comando ip unnumbered que señala a los loopbacks:

Topología: R1(Tun1: 172.16.0.1/24)—(Tun1: 172.17.0.2/24) R2

R1:
interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.0
 
interface Loopback0
 ip address 172.16.0.1 255.255.255.0

interface Tunnel1
 ip unnumbered Loopback0
 tunnel source Ethernet0/0
 tunnel destination 10.0.0.2

router eigrp 100
 network 172.16.0.1 0.0.0.0
 passive-interface default
 no passive-interface Tunnel1

R2:
interface Ethernet0/0
 ip address 10.0.0.2 255.255.255.0

interface Loopback0
 ip address 172.17.0.2 255.255.255.0

interface Tunnel1
 ip unnumbered Loopback0
 tunnel source Ethernet0/0
 tunnel destination 10.0.0.1

router eigrp 100
 network 172.17.0.2 0.0.0.0
 passive-interface default
 no passive-interface Tunnel1

R1 muestra:

*Mar  3 16:50:39.046: EIGRP: Received HELLO on Tunnel1 nbr 172.17.0.2
*Mar  3 16:50:39.046:   AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0
*Mar  3 16:50:39.046: EIGRP: New peer 172.17.0.2
*Mar  3 16:50:39.046: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.17.0.2 
(Tunnel1) is up: new adjacency

R1#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.17.0.2              Tu1               12 00:00:07    7  1434  0  13

R1#show ip route eigrp 
      172.17.0.0/24 is subnetted, 1 subnets
D        172.17.0.0 [90/27008000] via 172.17.0.2, 00:00:05, Tunnel1

R1#show ip int brief 
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                10.0.0.1         YES manual up                    up       
Loopback0                  172.16.0.1       YES manual up                    up      
Tunnel1                    172.16.0.1       YES TFTP   up                    up  

R2 es similar a esto.

Después de cambiar el comando ip unnumbered en una configuración de dirección IP específica, no se forma una adyacencia EIGRP.

EIGRP en SVTI para el segmento DVTI con diferentes subredes 

Este ejemplo también utiliza el comando ip unnumbered. Las reglas mencionadas anteriormente también se aplican a DVTI.

Topología: R1(Tun1: 172.16.0.1/24)—(Virtual-template: 172.17.0.2/24) R2

El ejemplo anterior se modifica aquí para utilizar DVTI en lugar de SVTI. Además, en este ejemplo se agrega protección de túnel.

R1:
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set TS esp-des esp-md5-hmac 
!
crypto ipsec profile prof
 set transform-set TS 
!
interface Loopback0
 ip address 172.16.0.1 255.255.255.0
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel source Ethernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 10.0.0.2
 tunnel protection ipsec profile prof
!
router eigrp 100
 network 172.16.0.1 0.0.0.0
 passive-interface default
 no passive-interface Tunnel1

R2:
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto isakmp profile profLAN
   keyring default
   match identity address 10.0.0.1 255.255.255.255 
   virtual-template 1
!
crypto ipsec transform-set TS esp-des esp-md5-hmac 
!
crypto ipsec profile profLAN
 set transform-set TS 
 set isakmp-profile profLAN
 
interface Loopback0
 ip address 172.17.0.2 255.255.255.0
!
interface Ethernet0/0
 ip address 10.0.0.2 255.255.255.0
!
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 tunnel source Ethernet0/0
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile profLAN
!
!
router eigrp 100
 network 172.17.0.2 0.0.0.0
 passive-interface default
 no passive-interface Virtual-Template1

Todo funciona como se espera:

R1#show crypto session 
Crypto session current status
Interface: Tunnel1
Session status: UP-ACTIVE     
Peer: 10.0.0.2 port 500 
  IKEv1 SA: local 10.0.0.1/500 remote 10.0.0.2/500 Active 
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 2, origin: crypto map


R1#show crypto ipsec sa 
interface: Tunnel1
    Crypto map tag: Tunnel1-head-0, local addr 10.0.0.1
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 10.0.0.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 89, #pkts encrypt: 89, #pkts digest: 89
    #pkts decaps: 91, #pkts decrypt: 91, #pkts verify: 91

   
R1#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
0   172.17.0.2              Tu1               13 00:06:31    7  1434  0  19

R1#show ip route eigrp 
      172.17.0.0/24 is subnetted, 1 subnets
D        172.17.0.0 [90/27008000] via 172.17.0.2, 00:06:35, Tunnel1




R2#show crypto session 
Crypto session current status
Interface: Virtual-Access1
Profile: profLAN
Session status: UP-ACTIVE     
Peer: 10.0.0.1 port 500 
  IKEv1 SA: local 10.0.0.2/500 remote 10.0.0.1/500 Active 
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 2, origin: crypto map


R2#show crypto ipsec sa
interface: Virtual-Access1
    Crypto map tag: Virtual-Access1-head-0, local addr 10.0.0.2
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 10.0.0.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 107, #pkts encrypt: 107, #pkts digest: 107
    #pkts decaps: 105, #pkts decrypt: 105, #pkts verify: 105
 
  
R2#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
0   172.16.0.1              Vi1               13 00:07:41   11   200  0  16


R2#show ip route eigrp 
      172.16.0.0/24 is subnetted, 1 subnets
D        172.16.0.0 [90/1433600] via 172.16.0.1, 00:07:44, Virtual-Access1

Como en los ejemplos anteriores, cuando intenta configurar 172.16.0.1 y 172.17.0.2 directamente bajo las interfaces de túnel, EIGRP falla con exactamente el mismo error que antes.

EIGRP en IKEv2 Flex VPN con diferentes subredes

Este es el ejemplo de la configuración de FlexVPN Hub y Spoke. El servidor envía la dirección IP a través del modo de configuración para el cliente.

Topología: R1(e0/0: 172.16.0.1/24)—(e0/1: 172.16.0.2/24) R2

Configuración del concentrador (R1):

aaa new-model
aaa authorization network LOCALIKEv2 local 

crypto ikev2 authorization policy AUTHOR-POLICY 
 pool POOL
!
crypto ikev2 keyring KEYRING
 peer R2
  address 172.16.0.2
  pre-shared-key CISCO
 !        

crypto ikev2 profile default
 match identity remote key-id FLEX
 authentication remote pre-share
 authentication local pre-share
 keyring local KEYRING
 aaa authorization group psk list LOCALIKEv2 AUTHOR-POLICY
 virtual-template 1

interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!
interface Ethernet0/0
 ip address 172.16.0.1 255.255.255.0

interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 tunnel source Ethernet0/0
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile default
!         
!
router eigrp 1
 network 1.1.1.1 0.0.0.0
 passive-interface default
 no passive-interface Virtual-Template1
!
ip local pool POOL 192.168.0.1 192.168.0.10

Configuración de radio:

aaa new-model
aaa authorization network FLEX local

crypto ikev2 authorization policy FLEX 
 route set interface
!
!
!
crypto ikev2 keyring KEYRING
 peer R1
  address 172.16.0.1
  pre-shared-key CISCO
 !        
!
!
crypto ikev2 profile default
 match identity remote address 172.16.0.1 255.255.255.255 
 identity local key-id FLEX
 authentication remote pre-share
 authentication local pre-share
 keyring local KEYRING
 aaa authorization group psk list FLEX FLEX

interface Loopback0
 ip address 2.2.2.2 255.255.255.0
!
interface Ethernet0/0
 ip address 172.16.0.2 255.255.255.0

interface Tunnel0
 ip address negotiated
 tunnel source Ethernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 172.16.0.1
 tunnel protection ipsec profile default

router eigrp 1
 network 0.0.0.0
 passive-interface default
 no passive-interface Tunnel0

El Spoke utiliza SVTI para conectarse al Hub que utiliza DVTI para todos los radios. Debido a que EIGRP no es tan flexible como Open Shortest Path First (OSPF) y no es posible configurarlo en la interfaz (SVTI o DVTI), la red 0.0.0.0 se utiliza en Spoke para asegurarse de que EIGRP esté habilitado en la interfaz Tun0. Se utiliza una interfaz pasiva para asegurar que la adyacencia se forme solamente en la interfaz Tun0.

Para esta implementación, también es necesario configurar ip unnumbered en el Hub. Cuando configura manualmente una dirección IP bajo la interfaz de plantilla virtual, no se clona en la interfaz de acceso virtual. A continuación, la interfaz de acceso virtual no tiene asignada una dirección IP y la adyacencia EIGRP no se forma. Esta es la razón por la que el comando ip unnumbered siempre se requiere para las interfaces DVTI para formar una adyacencia EIGRP.

En este ejemplo, se genera una adyacencia EIGRP entre 1.1.1.1 y 192.168.0.9.

Prueba en el concentrador:

R1#show ip int brief 
Interface              IP-Address      OK? Method Status                Protocol
Ethernet0/0            172.16.0.1      YES NVRAM  up                    up      
Ethernet0/1            unassigned      YES NVRAM  administratively down down    
Ethernet0/2            unassigned      YES NVRAM  administratively down down    
Ethernet0/3            unassigned      YES NVRAM  administratively down down    
Loopback0              1.1.1.1         YES manual up                    up         
Virtual-Access1        1.1.1.1         YES unset  up                    up      
Virtual-Template1      1.1.1.1         YES manual up                    down 

R1#show crypto session 
Crypto session current status

Interface: Virtual-Access1
Session status: UP-ACTIVE     
Peer: 172.16.0.2 port 500 
  IKEv2 SA: local 172.16.0.1/500 remote 172.16.0.2/500 Active 
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 2, origin: crypto map

R1#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(1)
H   Address             Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                               (sec)         (ms)       Cnt Num
0   192.168.0.9          Vi1                      10 01:28:49   12  1494  0  13

R1#show ip route eigrp 
....
Gateway of last resort is not set

      2.0.0.0/24 is subnetted, 1 subnets
D        2.2.2.0 [90/27008000] via 192.168.0.9, 01:28:52, Virtual-Access1

Desde la perspectiva Spoke, el comando ip address negotiated funciona igual que el comando ip address unnumbered, y la verificación de la subred está inhabilitada. 

Probando en Spoke:

R2#show ip int brief 
Interface              IP-Address      OK? Method Status                Protocol
Ethernet0/0            172.16.0.2      YES NVRAM  up                    up      
Ethernet0/1            unassigned      YES NVRAM  administratively down down    
Ethernet0/2            unassigned      YES NVRAM  administratively down down    
Ethernet0/3            unassigned      YES NVRAM  administratively down down    
Loopback0              2.2.2.2         YES NVRAM  up                    up      
Tunnel0                192.168.0.9     YES NVRAM  up                    up 

R2#show crypto session 
Crypto session current status

Interface: Tunnel0
Session status: UP-ACTIVE     
Peer: 172.16.0.1 port 500 
  IKEv2 SA: local 172.16.0.2/500 remote 172.16.0.1/500 Active 
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 2, origin: crypto map

R2#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(1)
H   Address             Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                               (sec)         (ms)       Cnt Num
0   1.1.1.1             Tu0                     14 01:30:18   15   1434  0  14

R2#show ip route eigrp 
....
      1.0.0.0/24 is subnetted, 1 subnets
D        1.1.1.0 [90/27008000] via 1.1.1.1, 01:30:21

Modo de configuración para routing

Internet Key Exchange versión 2 (IKEv2) es otra opción. Es posible utilizar el modo de configuración para enviar rutas. En este escenario, no se necesitan EIGRP y el comando ip unnumbered.

Puede modificar el ejemplo anterior para configurar el Hub para que envíe esa ruta a través del modo de configuración:

crypto ikev2 authorization policy AUTHOR-POLICY 
 pool POOL
 route set access-list SPLIT

ip access-list standard SPLIT
 permit 1.1.1.0 0.0.0.255

El Spoke ve 1.1.1.1 como estático, no como EIGRP:

R2#show ip route
....
      1.0.0.0/24 is subnetted, 1 subnets
S        1.1.1.0 is directly connected, Tunnel0

El mismo proceso funciona en la dirección opuesta. El radio envía una ruta al concentrador:

crypto ikev2 authorization policy FLEX 
 route set access-list SPLIT

ip access-list standard SPLIT
 permit 2.2.2.0 0.0.0.255

El concentrador lo ve como estático (no EIGRP):

R1#show ip route 
....
      2.0.0.0/24 is subnetted, 1 subnets
S        2.2.2.0 is directly connected, Virtual-Access1

Para este escenario, el protocolo de ruteo dinámico y el comando ip unnumbered no son necesarios.

EIGRP IPV6 en segmento SVTI con diferentes subredes

Para IPv6, la situación es diferente. Esto se debe a que las direcciones locales de link IPv6 (FE80::/10) se utilizan para generar la adyacencia EIGRP o OSPF. Las direcciones locales de link válidas siempre pertenecen a la misma subred, por lo que no hay necesidad de utilizar el comando ipv6 no numerado para eso.

La topología aquí es la misma que en el ejemplo anterior, excepto que todas las direcciones IPv4 se reemplazan por direcciones IPv6.

Configuración R1:

interface Tunnel1
 no ip address
 ipv6 address FE80:1::1 link-local
 ipv6 address 2001:1::1/64
 ipv6 enable
 ipv6 eigrp 100
 tunnel source Ethernet0/0
 tunnel mode gre ipv6
 tunnel destination 2001::2

interface Loopback0
 description Simulate LAN
 no ip address
 ipv6 address 2001:100::1/64
 ipv6 enable
 ipv6 eigrp 100

interface Ethernet0/0
 no ip address
 ipv6 address 2001::1/64
 ipv6 enable

ipv6 router eigrp 100

Configuración R2:

interface Tunnel1
 no ip address
 ipv6 address FE80:2::2 link-local
 ipv6 address 2001:2::2/64
 ipv6 enable
 ipv6 eigrp 100
 tunnel source Ethernet0/0
 tunnel mode gre ipv6
 tunnel destination 2001::1

interface Loopback0
 description Simulate LAN
 no ip address
 ipv6 address 2001:200::1/64
 ipv6 enable
 ipv6 eigrp 100

interface Ethernet0/0
 no ip address
 ipv6 address 2001::2/64
 ipv6 enable

ipv6 router eigrp 100

Las direcciones del túnel están en diferentes subredes (2001:1::1/64 y 2001:2::2/64), pero eso no es importante. Las direcciones locales de link se utilizan para generar adyacencia. Con estas direcciones, siempre tiene éxito.

En R1:

R1#show ipv6 int brief 
Ethernet0/0            [up/up]
    FE80::A8BB:CCFF:FE00:6400
    2001::1
Loopback0              [up/up]
    FE80::A8BB:CCFF:FE00:6400
    2001:100::1
Tunnel1                [up/up]
    FE80:1::1
    2001:1::1

R1#show ipv6 eigrp neighbors 
EIGRP-IPv6 Neighbors for AS(100)
H   Address             Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                               (sec)         (ms)       Cnt Num
0   Link-local address: Tu1                      12 00:13:58  821  4926  0  17
    FE80:2::2

R1#show ipv6 route eigrp 
...
D   2001:2::/64 [90/28160000]
     via FE80:2::2, Tunnel1
D   2001:200::/64 [90/27008000]
     via FE80:2::2, Tunnel1

En R2:

R2#show ipv6 int brief 
Ethernet0/0            [up/up]
    FE80::A8BB:CCFF:FE00:6500
    2001::2
Loopback0              [up/up]
    FE80::A8BB:CCFF:FE00:6500
    2001:200::1
Tunnel1                [up/up]
    FE80:2::2
    2001:2::2

R2#show ipv6 eigrp neighbors 
EIGRP-IPv6 Neighbors for AS(100)
H   Address             Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                               (sec)         (ms)       Cnt Num
0   Link-local address: Tu1                      14 00:15:31   21  1470  0  18
    FE80:1::1

R2#show ipv6 route eigrp 
...
D   2001:1::/64 [90/28160000]
     via FE80:1::1, Tunnel1
D   2001:100::/64 [90/27008000]
     via FE80:1::1, Tunnel1

El proceso EIGRP instala la red IPv6 del par. En R1, la red 2001:2::/64 está instalada y esa red es una subred diferente a 2001:1::/64. Lo mismo es válido para R2. Por ejemplo, 2001::1/64 está instalado, que es una subred para su dirección IP de peer. No es necesario el comando ipv6 unnumbered aquí. Además, el comando ipv6 address no es necesario en la interfaz de túnel para establecer la adyacencia EIGRP, porque se utilizan las direcciones locales de link (y se generan automáticamente cuando se habilita IPv6 con el comando ipv6 enable).

EIGRP IPV6 en IKEv2 Flex VPN con diferentes subredes

La configuración DVTI para IPv6 es diferente a la de IPv4: ya no es posible configurar una dirección IP estática.

R1(config)#interface Virtual-Template2 type tunnel
R1(config-if)#ipv6 enable 
R1(config-if)#ipv6 address ?
  autoconfig  Obtain address using autoconfiguration
  dhcp        Obtain a ipv6 address using dhcp
  negotiated  IPv6 Address negotiated via IKEv2 Modeconfig

R1(config-if)#ipv6 address

Esto se espera, ya que una dirección estática nunca se clona en una interfaz de acceso virtual. Por este motivo se recomienda el comando ipv6 no numbered para la configuración del hub, y el comando ipv6 address negotiated se recomienda para la configuración de Spoke.

La topología es la misma que en el ejemplo anterior, excepto que todas las direcciones IPv4 se reemplazan por direcciones IPv6.

Configuración del concentrador (R1):

aaa authorization network LOCALIKEv2 local 

crypto ikev2 authorization policy AUTHOR-POLICY 
 ipv6 pool POOL

crypto ikev2 keyring KEYRING
 peer R2
  address 2001::2/64
  pre-shared-key CISCO
 
crypto ikev2 profile default
 match identity remote key-id FLEX
 authentication remote pre-share
 authentication local pre-share
 keyring local KEYRING
 aaa authorization group psk list LOCALIKEv2 AUTHOR-POLICY
 virtual-template 1

interface Loopback0
 no ip address
 ipv6 address 2001:100::1/64
 ipv6 enable
 ipv6 eigrp 100

interface Ethernet0/0
 no ip address
 ipv6 address 2001::1/64
 ipv6 enable

interface Virtual-Template1 type tunnel
 no ip address
 ipv6 unnumbered Loopback0
 ipv6 enable
 ipv6 eigrp 100
 tunnel source Ethernet0/0
 tunnel mode ipsec ipv6
 tunnel protection ipsec profile default

ipv6 local pool POOL 2001:10::/64 64
ipv6 router eigrp 100
 eigrp router-id 1.1.1.1

Configuración de radio (R2):

aaa authorization network FLEX local

crypto ikev2 authorization policy FLEX 
 route set interface

crypto ikev2 keyring KEYRING
 peer R1
  address 2001::1/64
  pre-shared-key CISCO

crypto ikev2 profile default
 match identity remote address 2001::1/64
 identity local key-id FLEX
 authentication remote pre-share
 authentication local pre-share
 keyring local KEYRING
 aaa authorization group psk list FLEX FLEX

interface Tunnel0
 no ip address
 ipv6 address negotiated
 ipv6 enable
 ipv6 eigrp 100
 tunnel source Ethernet0/0
 tunnel mode ipsec ipv6
 tunnel destination 2001::1
 tunnel protection ipsec profile default
!
interface Ethernet0/0
 no ip address
 ipv6 address 2001::2/64
 ipv6 enable

ipv6 router eigrp 100
 eigrp router-id 2.2.2.2

Verificación:

R2#show ipv6 eigrp neighbors 
EIGRP-IPv6 Neighbors for AS(100)
H   Address             Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                               (sec)         (ms)       Cnt Num
0   Link-local address: Tu0                      11 00:12:32   17  1440  0  12
    FE80::A8BB:CCFF:FE00:6500

R2#show ipv6 route eigrp 
....
D   2001:100::/64 [90/27008000]
     via FE80::A8BB:CCFF:FE00:6500, Tunnel0

R2#show crypto session detail 
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection     
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation     
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel0
Uptime: 00:13:17
Session status: UP-ACTIVE     
Peer: 2001::1 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 2001::1
      Desc: (none)
  IKEv2 SA: local 2001::2/500
          remote 2001::1/500 Active 
          Capabilities:(none) connid:1 lifetime:23:46:43
  IPSEC FLOW: permit ipv6 ::/0 ::/0 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 190 drop 0 life (KB/Sec) 4271090/2803
        Outbound: #pkts enc'ed 194 drop 0 life (KB/Sec) 4271096/2803
  
R2#ping 2001:100::1 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 2001:100::1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/4/5 ms

R2#show crypto session detail   
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection     
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation     
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel0
Uptime: 00:13:27
Session status: UP-ACTIVE     
Peer: 2001::1 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 2001::1
      Desc: (none)
  IKEv2 SA: local 2001::2/500
          remote 2001::1/500 Active 
          Capabilities:(none) connid:1 lifetime:23:46:33
  IPSEC FLOW: permit ipv6 ::/0 ::/0 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 292 drop 0 life (KB/Sec) 4271071/2792
        Outbound: #pkts enc'ed 296 drop 0 life (KB/Sec) 4271082/2792

Para DVTI, IPv6 no se puede configurar manualmente. Se recomienda el comando ipv6 no numbered para el concentrador y el comando ipv6 address negotiated se recomienda en el radio.

Este escenario presenta el comando ipv6 unnumbered para DVTI. Es importante observar que, para IPv6 en lugar de IPv4, el comando ipv6 no numerado en la interfaz de plantilla virtual no es necesario. El motivo es el mismo que para el escenario SVTI de IPv6: la dirección ipv6 local de link se utiliza para generar adyacencia. La interfaz de acceso virtual, clonada a partir de la plantilla virtual, hereda la dirección local de link IPv6 y eso es suficiente para generar la adyacencia EIGRP.

Verificación

Actualmente, no hay un procedimiento de verificación disponible para esta configuración.

Troubleshoot

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Advertencias conocidas

Id. de bug Cisco CSCtx45062 FlexVPN: Eigrp no debe verificar las subredes comunes si las ip del túnel son /32.

Este error y corrección no es específico de FlexVPN. Ingrese este comando antes de implementar la corrección (Software Release 15.1):

R2(config-if)#do show run int tun1
Building configuration...

Current configuration : 165 bytes

interface Tunnel1
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.1
 tunnel protection ipsec profile prof1

R2(config-if)#ip address 192.168.200.1 255.255.255.255
Bad mask /32 for address 192.168.200.1

Ingrese este comando después de la corrección (software 15.3):

R2(config-if)#do show run int tun1
Building configuration...

Current configuration : 165 bytes

interface Tunnel1
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.1
 tunnel protection ipsec profile prof1

R2(config-if)#ip address 192.168.200.1 255.255.255.255
R2(config-if)#
*Jun 14 18:01:12.395: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 
192.168.100.1 (Tunnel1) is up: new adjacency

En realidad hay dos cambios en la versión 15.3 del software:

• Netmask /32 se acepta para todas las direcciones IP.
• No hay verificación de subred para un vecino EIGRP cuando utiliza la dirección /32.

Summary

El comportamiento de EIGRP se modifica por el comando ip unnumbered. Inhabilita las verificaciones de la misma subred mientras establece una adyacencia EIGRP.

También es importante recordar que cuando utiliza direcciones IP configuradas estáticamente en la plantilla virtual, no se clona en el acceso virtual. Esta es la razón por la que el comando ip unnumbered es necesario.

Para FlexVPN, no es necesario utilizar el comando ip unnumbered cuando se utiliza la dirección negociada en el cliente. Pero, es importante utilizarlo en el Hub cuando utilice EIGRP. Cuando utiliza el modo de configuración para el ruteo, no se necesita EIGRP.

Para SVTI, IPv6 utiliza direcciones locales de link para la adyacencia, y no hay necesidad de utilizar el comando ipv6 unnumbered.

Para DVTI, IPv6 no se puede configurar manualmente. Se recomienda el comando ipv6 no numbered para el concentrador y el comando ipv6 address negotiated se recomienda en el radio.

Información Relacionada

• Guía de configuración de FlexVPN de Cisco IOS 15.3
• Referencias de Comandos de Cisco IOS 15.3
  
• Soporte Técnico y Documentación - Cisco Systems