Configuración del túnel IOS XE de Secure Access mediante BGP y ECMP
Contenido
Introducción
Este documento describe los pasos necesarios para configurar y resolver problemas del túnel VPN IPSec entre Cisco Secure Access y Cisco IOS XE mediante BGP y ECMP.
Diagrama de la red
En este ejemplo de laboratorio, este escenario muestra que la red 192.168.150.0/24 tiene un segmento de LAN detrás del dispositivo Cisco IOS XE, y 192.168.200.0/24 tiene un conjunto de IP utilizado por RAVPN con usuarios que se conectan a la cabecera Secure Access.
El objetivo final es utilizar ECMP en túneles VPN entre el dispositivo Cisco IOS XE y la cabecera Secure Access. Para entender mejor la topología, consulte el diagrama:
Nota: Este es un ejemplo de flujo de paquetes que puede aplicar los mismos principios a cualquier otro flujo y a Secure Internet Access desde la subred 192.168.150.0/24 detrás del router Cisco IOS XE.
Prerequisites
Requirements
Se recomienda que tenga conocimiento de estos temas:
- Configuración y gestión de CLI de Cisco IOS XE
- Conocimientos básicos de los protocolos IKEv2 e IPSec
- Configuración inicial de Cisco IOS XE (dirección IP, SSH, licencia)
- Conocimientos básicos de BGP y ECMP
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- C8000V con versión de software 17.9.4a
- PC con Windows
- Organización Cisco Secure Access
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Antecedentes
Los túneles de red de Secure Access tienen una limitación de ancho de banda de 1 Gbps por túnel único. Si el ancho de banda de Internet de flujo ascendente/descendente es superior a 1 Gbps y desea utilizarlo por completo, debe configurar varios túneles utilizando el mismo Data Center de acceso seguro agrupándolos en un único grupo ECMP.
Cuando finaliza varios túneles con un único grupo de túnel de red (dentro de un único DC de Secure Access), de forma predeterminada forman un grupo ECMP desde la perspectiva de cabecera de Secure Access. Una vez que la cabecera de Secure Access envía el tráfico hacia el dispositivo VPN en las instalaciones, carga los balances entre los túneles (suponiendo que se reciban las rutas correctas de los peers BGP).
Para lograr la misma funcionalidad con el dispositivo VPN en las instalaciones, debe configurar varias interfaces VTI en un único router y asegurarse de que se aplican las configuraciones de routing adecuadas. En este artículo se explican esos escenarios en cada paso.
Configurar
Configuración de Secure Access
Hay configuraciones especiales que se deben aplicar en el lado de Secure Access para formar un grupo ECMP desde varios túneles VPN usando el protocolo BGP.
Configuración del Grupo de Túnel de Red:
- Cree un nuevo grupo de túnel de red (o edite uno existente):
- Especifique la ID de túnel y la frase de contraseña:
- Configure las opciones de ruteo, especifique el ruteo dinámico e ingrese su número de AS interno. En este escenario de laboratorio, el ASN es igual a 65000:
- Observe los detalles del túnel de la sección Datos para la Configuración del Túnel.
Configuración de Cisco IOS XE
Esta sección trata sobre la configuración de CLI que debe aplicarse en el router Cisco IOS XE. Para configurar correctamente los túneles IKEv2, la vecindad BGP y el equilibrio de carga ECMP a través de las interfaces de túnel virtual.
Se explica cada sección y se mencionan las advertencias más comunes.
Parámetros IKEv2 e IPsec
Configure la política IKEv2 y la propuesta IKEv2. Estos parámetros definen qué algoritmos se utilizan para IKE SA (fase 1):
crypto ikev2 proposal sse-proposal
encryption aes-gcm-256
prf sha256
group 19 20
crypto ikev2 policy sse-pol
proposal sse-proposal
Nota: Consulte los parámetros recomendados y óptimos marcados en negrita en la Supported IPsec Parameters SSE Guide.
Defina el anillo de claves IKEv2 que explica la dirección IP de cabecera y la clave previamente compartida utilizada para autenticarse con la cabecera SSE:
crypto ikev2 keyring sse-keyring
peer sse
address 35.179.86.116
pre-shared-key local <boring_generated_password>
pre-shared-key remote <boring_generated_password>
Configurar par de perfiles IKEv2
Define el tipo de identidad IKE que se va a utilizar, que coincide con el par remoto y que el router local de identidad IKE está enviando al par. La identidad IKE de la cabecera SSE es del tipo de dirección IP y es igual a la IP pública de la cabecera SSE.
Advertencia: Para establecer varios túneles con el mismo grupo de túnel de red en el lado SSE, todos deben utilizar la misma identidad IKE local. Cisco IOS XE no admite estos escenarios, ya que requiere un par único de identidades IKE locales y remotas por túnel. Para superar esta limitación, la cabecera SSE se ha mejorado para aceptar la ID de IKE en el formato de: <tunnel_id>+<suffix>@<org><hub>.sse.cisco.com
Como se explicó en el escenario de laboratorio, el ID de túnel se definió como: cat8k-dmz. En un escenario normal, configuraría el router para enviar la identidad IKE local como: cat8k-dmz@8195165-622405748-sse.cisco.com.
Sin embargo, para establecer varios túneles con el mismo grupo de túnel de red, se deben utilizar los ID de IKE locales: cat8k-dmz+tunnel1@8195165-622405748-sse.cisco.com y cat8k-dmz+tunnel2@8195165-622405748-sse.cisco.com.
El sufijo agregado a cada cadena: (túnel1 y túnel2).
Nota: Como se mencionó anteriormente. las identidades IKE locales son ejemplos utilizados en este escenario de laboratorio. Puede definir cualquier sufijo que desee, solo asegúrese de cumplir con los requisitos.
crypto ikev2 profile sse-ikev2-profile-tunnel1
match identity remote address 35.179.86.116 255.255.255.255
identity local email cat8k-dmz+tunnel1@8195165-622405748-sse.cisco.com
authentication remote pre-share
authentication local pre-share
keyring local sse-keyring
dpd 10 2 periodic
crypto ikev2 profile sse-ikev2-profile-tunnel2
match identity remote address 35.179.86.116 255.255.255.255
identity local email cat8k-dmz+tunnel2@8195165-622405748-sse.cisco.com
authentication remote pre-share
authentication local pre-share
keyring local sse-keyring
dpd 10 2 periodic
Configure el conjunto de transformación IPSec. Esta configuración define los algoritmos utilizados para la Asociación de seguridad IPsec (fase 2):
crypto ipsec transform-set sse-transform esp-gcm 256
mode tunnel
Configurar perfiles IPSec que vinculan perfiles IKEv2 con conjuntos de transformación:
crypto ipsec profile sse-ipsec-profile-1
set transform-set sse-transform
set ikev2-profile sse-ikev2-profile-tunnel1
crypto ipsec profile sse-ipsec-profile-2
set transform-set sse-transform
set ikev2-profile sse-ikev2-profile-tunnel2
Interfaces de túnel virtual
Esta sección trata sobre las configuraciones de las interfaces de túnel virtual y las interfaces de loopback utilizadas como orígenes de túnel. En el escenario de laboratorio discutido anteriormente, debe establecer dos interfaces VTI con un solo par utilizando la misma dirección IP pública. Además, el dispositivo Cisco IOS XE sólo tiene una interfaz de salida GigabitEthernet1. Cisco IOS XE no admite configuraciones de más de un VTI con el mismo origen de túnel y destino de túnel.
Para superar esta limitación, puede utilizar las interfaces de loopback y definirlas como un origen de túnel en el VTI respectivo.
Existen algunas opciones para lograr la conectividad IP entre el loopback y una dirección IP pública SSE:
- Asigne una dirección IP públicamente enrutable a una interfaz de bucle invertido (requiere la propiedad de un espacio de direcciones IP públicas).
- Asigne una dirección IP privada a una interfaz de loopback y NAT de tráfico dinámico con un origen de IP de loopback.
- Utilice la interfaz VASI (no admitida en muchas plataformas, engorroso de configurar y solucionar problemas).
En este escenario, los siguientes pasos descritos detallan la segunda opción.
Configure dos interfaces de loopback y agregue el comando "ip nat inside" debajo de cada una.
interface Loopback1
ip address 10.1.1.38 255.255.255.255
ip nat inside
end
interface Loopback2
ip address 10.1.1.70 255.255.255.255
ip nat inside
end
Defina la lista de control de acceso NAT dinámica y la sentencia de sobrecarga NAT:
ip access-list extended NAT
10 permit ip 10.1.1.0 0.0.0.255 any
ip nat inside source list NAT interface GigabitEthernet1 overload
Configuración de las Interfaces de Túnel Virtuales:
interface Tunnel1
ip address 169.254.0.10 255.255.255.252
tunnel source Loopback1
tunnel mode ipsec ipv4
tunnel destination 35.179.86.116
tunnel protection ipsec profile sse-ipsec-profile-1
end
!
interface Tunnel2
ip address 169.254.0.14 255.255.255.252
tunnel source Loopback2
tunnel mode ipsec ipv4
tunnel destination 35.179.86.116
tunnel protection ipsec profile sse-ipsec-profile-2
end
Nota: Como se describe en el escenario de laboratorio, las direcciones IP asignadas a las VTI provienen de subredes no superpuestas de 169.254.0.0/24. Puede utilizar otros espacios de subred, sin embargo, hay ciertos requisitos relacionados con BGP, que requiere espacio de dirección.
Routing BGP
Esta sección cubre los pasos de configuración que se requieren para establecer la vecindad BGP con la cabecera SSE. El proceso BGP en la cabecera SSE escucha en cualquier IP de la subred 169.254.0.0/24. Para establecer el peering BGP en ambos VTI, hay dos vecinos para definir" 169.254.0.9 (Tunnel1) y 169.254.0.13 (Tunnel2). Además, debe especificar el valor de AS remoto que se ve en el panel SSE.
A partir de noviembre de 2025, todas las organizaciones Secure Access recién creadas deben utilizar el ASN 3264 público de forma predeterminada para el peering BGP en los grupos de túnel de red. Las organizaciones existentes establecidas antes de noviembre de 2025 pueden seguir utilizando el ASN 64512 privado reservado anteriormente para los peers BGP de acceso seguro.
router bgp 65000
bgp log-neighbor-changes
neighbor 169.254.0.9 remote-as 32644
neighbor 169.254.0.9 ebgp-multihop 255
neighbor 169.254.0.13 remote-as 32644
neighbor 169.254.0.13 ebgp-multihop 255
!
address-family ipv4
network 192.168.150.0
neighbor 169.254.0.9 activate
neighbor 169.254.0.13 activate
maximum-paths 2
Nota: Las rutas recibidas de ambos peers deben ser exactamente iguales. De forma predeterminada, el router sólo instala uno en la tabla de ruteo. Para permitir que se instale más de una ruta duplicada en la tabla de routing (y activar ECMP), debe configurar "maximum-paths <number of routes>".
Verificación
Panel de acceso seguro
Debe ver dos túneles primarios en el panel SSE:
Router Cisco IOS XE
Verifique que ambos túneles estén en estado READY desde el lado de Cisco IOS XE:
wbrzyszc-cat8k#show crypto ikev2 sa
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.1.1.70/4500 35.179.86.116/4500 none/none READY
Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:20, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/255 sec
CE id: 0, Session-id: 6097
Local spi: A15E8ACF919656C5 Remote spi: 644CFD102AAF270A
Tunnel-id Local Remote fvrf/ivrf Status
6 10.1.1.38/4500 35.179.86.116/4500 none/none READY
Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:20, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/11203 sec
CE id: 0, Session-id: 6096
Local spi: E18CBEE82674E780 Remote spi: 39239A7D09D5B972
Verifique que la vecindad BGP esté ACTIVA con ambos peers:
wbrzyszc-cat8k#show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
169.254.0.9 4 32644 17281 18846 160 0 0 5d23h 15
169.254.0.13 4 32644 17281 18845 160 0 0 5d23h 15
Verifique que el router aprenda las rutas adecuadas de BGP (y que haya al menos dos saltos siguientes instalados en la tabla de ruteo):
wbrzyszc-cat8k#show ip route 192.168.200.0
Routing entry for 192.168.200.0/25, 2 known subnets
B 192.168.200.0 [20/0] via 169.254.0.13, 5d23h
[20/0] via 169.254.0.9, 5d23h
B 192.168.200.128 [20/0] via 169.254.0.13, 5d23h
[20/0] via 169.254.0.9, 5d23h
wbrzyszc-cat8k#show ip cef 192.168.200.0
192.168.200.0/25
nexthop 169.254.0.9 Tunnel1
nexthop 169.254.0.13 Tunnel2
Inicie el tráfico y verifique que se utilizan ambos túneles y vea que los contadores de encapsulamiento y desencapsulamiento aumentan para ambos:
wbrzyszc-cat8k#show crypto ipsec sa | i peer|caps
current_peer 35.179.86.116 port 4500
#pkts encaps: 1881087, #pkts encrypt: 1881087, #pkts digest: 1881087
#pkts decaps: 1434171, #pkts decrypt: 1434171, #pkts verify: 1434171
current_peer 35.179.86.116 port 4500
#pkts encaps: 53602, #pkts encrypt: 53602, #pkts digest: 53602
#pkts decaps: 208986, #pkts decrypt: 208986, #pkts verify: 208986
Opcionalmente, puede recopilar capturas de paquetes en ambas interfaces VTI para garantizar que el tráfico tenga una carga equilibrada entre las VTI. Refiérase a la Guía de Configuración y Captura de Paquetes Incrustados en Software para configurar la Captura de Paquetes Incrustada en los dispositivos Cisco IOS XE. En el ejemplo, el host detrás del router Cisco IOS XE con la IP de origen de: 192.168.150.1 estaba enviando solicitudes ICMP a varias IP desde la subred 192.168.200.0/24. Como puede ver, las solicitudes ICMP tienen la misma carga equilibrada entre los túneles.
wbrzyszc-cat8k#show monitor capture Tunnel1 buffer brief
----------------------------------------------------------------------------
# size timestamp source destination dscp protocol
----------------------------------------------------------------------------
0 114 0.000000 192.168.150.1 -> 192.168.200.2 0 BE ICMP
1 114 0.000000 192.168.150.1 -> 192.168.200.2 0 BE ICMP
10 114 26.564033 192.168.150.1 -> 192.168.200.5 0 BE ICMP
11 114 26.564033 192.168.150.1 -> 192.168.200.5 0 BE ICMP
wbrzyszc-cat8k#show monitor capture Tunnel2 buffer brief
----------------------------------------------------------------------------
# size timestamp source destination dscp protocol
----------------------------------------------------------------------------
0 114 0.000000 192.168.150.1 -> 192.168.200.1 0 BE ICMP
1 114 2.000000 192.168.150.1 -> 192.168.200.1 0 BE ICMP
10 114 38.191000 192.168.150.1 -> 192.168.200.3 0 BE ICMP
11 114 38.191000 192.168.150.1 -> 192.168.200.3 0 BE ICMP
Nota: Existen múltiples mecanismos de balanceo de carga ECMP en los routers Cisco IOS XE. De forma predeterminada, el balanceo de carga por destino está habilitado, lo que garantiza que el tráfico a la misma IP de destino siempre tome la misma trayectoria. Puede configurar el balanceo de carga por paquete, que balancea aleatoriamente el tráfico incluso para la misma IP de destino.
Información Relacionada
- Guía del usuario de Secure Access
- Cómo Recopilar la Captura de Paquetes Integrada
- Soporte Técnico y Documentación - Cisco Systems
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
3.0 |
10-Jul-2026
|
Título actualizado, introducción, ortografía, gramática, estructura de oraciones, espaciado, texto alternativo y alertas de CCW. |
1.0 |
21-Oct-2024
|
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)