Segurança : Cisco FlexVPN

EIGRP em SVTI, em DVTI, e em IKEv2 FlexVPN com o exemplo Unnumbered comando Configuration "IP[v6] do”

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como configurar o Enhanced Interior Gateway Routing Protocol (EIGRP) em um número de encenações comum-encontradas no ® do Cisco IOS. A fim aceitar uma adjacência do vizinho EIGRP, o Cisco IOS deve obter o pacote de hello de EIGRP de um endereço IP de Um ou Mais Servidores Cisco ICM NT dentro da mesma sub-rede. É possível desabilitar essa verificação com o comando ip unnumbered.

O primeiro parte do artigo apresenta uma falha EIGRP quando recebe um pacote que não esteja na mesma sub-rede.

Um outro exemplo demonstra o uso do comando ip unnumbered que desabilita essa verificação, e permite que o EIGRP forme uma adjacência entre os pares que pertencem às sub-redes diferentes.

Este artigo igualmente apresenta um desenvolvimento do hub and spoke de FlexVPN com um endereço IP de Um ou Mais Servidores Cisco ICM NT enviado do server. Para esta encenação, a verificação das sub-redes é desabilitada para o comando ip address negotiated e igualmente para o comando ip unnumbered. O comando ip unnumbered é usado primeiramente para o tipo (P2P) ponto a ponto relações, e este faz a FlexVPN um ajuste perfeito desde que é baseado em uma arquitetura P2P.

Ultimamente, uma encenação do IPv6 é apresentada junto com diferenças para as interfaces de túnel virtuais estáticas (SVTI) e as interfaces de túnel virtuais dinâmicas (DVTI). Há umas leves mudanças no comportamento quando você compara o IPv6 às encenações do IPv4.

Adicionalmente, as mudanças entre as versões do Cisco IOS 15.1 e 15.3 são apresentadas (identificação de bug Cisco CSCtx45062).

O comando ip unnumbered é precisado sempre para DVTI. Isto é porque os endereços IP de Um ou Mais Servidores Cisco ICM NT estático-configurados em uma interface de molde virtual são clonados nunca a uma interface de acesso virtual. Além disso, uma relação sem um endereço IP de Um ou Mais Servidores Cisco ICM NT configurado não pode estabelecer nenhuma adjacência do protocolo de roteamento dinâmico. O comando ip unnumbered não é necessário para SVTI, mas sem essa sub-rede, a verificação é executada quando a adjacência do protocolo de roteamento dinâmico é estabelecida. O comando unnumbered do IPv6 não é precisado igualmente para encenações do IPV6 devido aos endereços locais de link que são usados a fim construir adjacências EIGRP.

Contribuído por Michal Garcarz e por Olivier Pelerin, engenheiros de TAC da Cisco.

Pré-requisitos

Requisitos

Cisco recomenda que você tem o conhecimento básico destes assuntos:

  • Configuração de VPN no Cisco IOS
  • Configuração de FlexVPN no Cisco IOS

Componentes Utilizados

A informação neste documento é baseada na versão do Cisco IOS 15.3T.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

EIGRP em um segmento de Ethernet com sub-redes diferentes

Topologia: Roteador1 (r1) (e0/0: 10.0.0.1/24)-------(e0/1: 10.0.1.2/24) Roteador2 (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

Mostras do r1:

*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

O Cisco IOS não forma uma adjacência, que seja esperada. Para obter mais informações sobre disto, refira o que fazem o meio do mensagem " não em sub-rede comum " EIGRP? artigo.

EIGRP no segmento SVTI com sub-redes diferentes

A mesma situação ocorre quando você usa as interfaces de túnel virtuais (VTI) (túnel de encapsulamento de roteamento genérico (GRE)).

Topologia: 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

Mostras do r1:

*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

Este é um comportamento esperado.

Use o comando IP unnumbered

Este exemplo mostra como usar o comando ip unnumbered que desabilita a verificação e a permite o estabelecimento de uma sessão EIGRP entre pares em sub-redes diferentes.

A topologia é similar ao exemplo anterior, mas os endereços dos túneis são definidos agora através do comando ip unnumbered que pontos aos laços de retorno:

Topologia: 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

Mostras do r1:

*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 

O R2 é similar a este.

Depois que você muda o comando ip unnumbered em uma configuração de endereço IP específica, uma adjacência EIGRP não forma.

EIGRP em SVTI ao segmento DVTI com sub-redes diferentes 

Este exemplo igualmente usa o comando ip unnumbered. As regras mencionadas previamente aplicam-se a DVTI também.

Topologia: R1(Tun1: 172.16.0.1/24)-------(Virtual-template: 172.17.0.2/24) R2

O exemplo anterior é alterado aqui a fim usar DVTI em vez de SVTI. Adicionalmente, a proteção do túnel é adicionada neste exemplo.

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

Tudo trabalha como esperado:

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

Quanto para aos exemplos anteriores, quando você tenta configurar 172.16.0.1 e 172.17.0.2 diretamente sob as interfaces de túnel, o EIGRP falha com exatamente o mesmo erro que antes.

EIGRP IKEv2 no cabo flexível VPN com sub-redes diferentes

Está aqui o exemplo para a configuração do hub and spoke de FlexVPN. O server envia o endereço IP de Um ou Mais Servidores Cisco ICM NT através do modo de configuração para o cliente.

Topologia: R1(e0/0: 172.16.0.1/24)-------(e0/1: 172.16.0.2/24) R2

Configuração do hub (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

Configuração de raio:

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

Os usos SVTI do spoke a fim conectar ao hub que usa DVTI para todo o spokes. Porque o EIGRP não é tão flexível como o Open Shortest Path First (OSPF) e não são possíveis para o configurar sob a relação (SVTI ou DVTI), a rede 0.0.0.0 é usada no spoke a fim assegurar-se de que o EIGRP esteja permitido na relação Tun0. Uma interface passiva é usada a fim assegurar-se de que a adjacência esteja formada somente na relação Tun0.

Para este desenvolvimento, é igualmente necessário configurar o IP unnumbered no hub. Quando você configura manualmente um endereço IP de Um ou Mais Servidores Cisco ICM NT sob a interface de molde virtual, não está clonada à interface de acesso virtual. Então, a interface de acesso virtual não tem um endereço IP de Um ou Mais Servidores Cisco ICM NT atribuído, e a adjacência EIGRP não forma. Eis porque o comando ip unnumbered é exigido sempre para DVTI conecta a fim formar uma adjacência EIGRP.

Neste exemplo, uma adjacência EIGRP é construída entre 1.1.1.1 e 192.168.0.9.

Teste no hub:

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



Da perspectiva do spoke, o comando ip address negotiated trabalha o mesmos que o comando unnumbered do endereço IP de Um ou Mais Servidores Cisco ICM NT, e a verificação da sub-rede é desabilitada. 

Teste no 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 configuração para distribuir

A versão 2 do intercâmbio de chave de Internet (IKEv2) é uma outra opção. É possível usar o modo de configuração a fim empurrar rotas. Nesta encenação, o EIGRP e o comando ip unnumbered não são precisados.

Você pode alterar o exemplo anterior a fim configurar o hub para enviar essa rota através do modo de configuração:

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

O spoke vê 1.1.1.1 como a estática, não EIGRP:

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


Os mesmos trabalhos na direção oposta. O spoke envia uma rota ao hub:

crypto ikev2 authorization policy FLEX 
 route set access-list SPLIT

ip access-list standard SPLIT
 permit 2.2.2.0 0.0.0.255

O hub vê-o como a estática (não 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 esta encenação, o protocolo de roteamento dinâmico e o comando ip unnumbered não são precisados.

IPV6 EIGRP no segmento SVTI com sub-redes diferentes

Para o IPv6, a situação é diferente. Isto é porque os endereços locais de link do IPv6 (FE80::/10) são usados a fim construir o EIGRP ou a adjacência de OSPF. Os endereços locais de link válidos não pertencem sempre à mesma sub-rede, tão lá são nenhuma necessidade de usar o comando unnumbered do IPv6 para aquele.

A topologia aqui é a mesma que para o exemplo anterior, salvo que todos os endereços do IPv4 são substituídos com os endereços do IPv6.

Configuração do 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

Configuração 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

Os endereços do túnel estão em sub-redes diferentes (2001:1::1/64 e 2001:2::2/64), mas aquele não é importante. Os endereços locais de link são usados a fim construir a adjacência. Com estes endereços, sucede sempre.

No 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

No 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

A rede do IPv6 do par é instalada pelo processo de EIGRP. No r1, a rede de 2001:2::/64 é instalada, e essa rede é uma sub-rede diferente do que 2001:1::/64. O mesmo é verdadeiro no R2. Por exemplo, 2001::1/64 são instalados, que é uma sub-rede para seu endereço IP do peer. Não há nenhuma necessidade para o comando unnumbered do IPv6 aqui. Adicionalmente, o comando address do IPv6 não é precisado na interface de túnel a fim estabelecer a adjacência EIGRP, porque os endereços locais de link estão usados (e aqueles estão gerados automaticamente quando você permite o IPv6 com o comando enable do IPv6).

IPV6 EIGRP IKEv2 no cabo flexível VPN com sub-redes diferentes

A configuração DVTI para o IPv6 é diferente do que para o IPv4: não é possível configurar anymore um endereço IP estático.

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

Isto é esperado, desde que um endereço estático é clonado nunca a uma interface de acesso virtual. Eis porque o comando unnumbered do IPv6 é recomendado para a configuração do hub, e o comando negociado endereço do IPv6 é recomendado para a configuração de raio.

A topologia é a mesma que o exemplo anterior, salvo que todos os endereços do IPv4 são substituídos com os endereços do IPv6.

Configuração do hub (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

Configuração do spoke (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

Verificação:

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, o IPv6 não pode ser configurado manualmente. O comando unnumbered do IPv6 é recomendado para o hub, e o comando negociado endereço do IPv6 é recomendado no spoke.

Esta encenação apresenta ao IPv6 o comando unnumbered para DVTI. É importante observar que, para o IPv6 ao contrário do IPv4, o comando unnumbered do IPv6 na interface de molde virtual não está precisado. A razão para esta é a mesma que para a encenação do IPv6 SVTI: o endereço do IPv6 do link local é usado para a adjacência de construção. A interface de acesso virtual, que é clonada do virtual-molde, herda o endereço local de link do IPv6, e aquele é suficiente a fim construir a adjacência EIGRP.

Verificar

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshooting

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Caveats conhecidos

Identificação de bug Cisco CSCtx45062 FlexVPN: Eigrp não deve verificar sub-redes comum se o túnel IP é /32.

Estes erro e reparo não são FlexVPN-específicos. Incorpore este comando antes que você execute o reparo (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

Incorpore este comando após o reparo (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

Há realmente duas mudanças no Software Release 15.3:

  • A Máscara de rede /32 é aceitada para todos os endereços IP de Um ou Mais Servidores Cisco ICM NT.
  • Não há nenhuma verificação da sub-rede para um vizinho EIGRP quando você usa o endereço de /32.

Resumo

O comportamento EIGRP é mudado pelo comando ip unnumbered. Desabilita verificações para a mesma sub-rede quando estabelecer uma adjacência EIGRP.

É igualmente importante recordar que quando você usa o endereço IP configurado de DVTIs estaticamente no virtual-molde, não está clonado ao acesso virtual. Eis porque o comando ip unnumbered é precisado.

Para FlexVPN, não há nenhuma necessidade de usar o comando ip unnumbered quando você usa o endereço negociável no cliente. Mas, é importante usá-lo no hub quando você usa o EIGRP. Quando você usa o modo de configuração distribuindo, o EIGRP não está precisado.

Para SVTI, o IPv6 usa endereços locais de link para a adjacência, e não há nenhuma necessidade de usar o comando unnumbered do IPv6.

Para DVTI, o IPv6 não pode ser configurado manualmente. O comando unnumbered do IPv6 é recomendado para o hub, e o comando negociado endereço do IPv6 é recomendado no spoke.

Informação relacionada


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 116346