Introducción
Este documento describe cómo resolver problemas de interfaz de encapsulación de routing genérico (GRE) en un entorno SD-WAN.
Antecedentes
En la solución Cisco Viptela, los casos prácticos de las interfaces GRE incluyen:
- Enviar tráfico a ZScaler (HTTP-Proxy) a través de vSmart Data-Policy o localmente.
- Interfaz GRE de servicio principal con respaldo predeterminado al Data Center.
- encadenamiento de servicios
Hay casos en los que la interfaz GRE puede no activarse o no funcionar.
En esas situaciones, compruebe
- La interfaz GRE se activa/activa a través de: show interface gre*
- Keepalives GRE a través de: show tunnel gre-keepalives
Metodología
Si hay un problema, configure una Lista de control de acceso (ACL o lista de acceso) para ver si los paquetes GRE (47) se están saliendo/ingresando.
No puede ver los paquetes GRE a través de TCP Dump, ya que los paquetes son generados por el trayecto rápido.
A veces, debido a la traducción de direcciones de red (NAT), se pueden descartar señales de mantenimiento GRE. En este caso, inhabilite el keepalive y vea si se activa el túnel.
Además, si el túnel GRE está inestable e inhabilitando keepalives, esto mantiene la interfaz activa/activa.
Sin embargo, tiene un inconveniente, donde si hay un problema legítimo, es difícil averiguar que el GRE no funciona.
Vea aquí en el documento que muestra un ejemplo.
Esta es una configuración de interfaz GRE en funcionamiento
IN VPN0
vpn 0
interface gre1
ip address 192.0.2.1/30
tunnel-source
tunnel-destination
tcp-mss-adjust 1300
no shutdown
!
interface gre2
ip address 192.0.2.5/30
tunnel-source
tunnel-destination
tcp-mss-adjust 1300
no shutdown
!
!
lado de servicio IN
vpn
service FW interface gre1 gre2
En la solución Cisco SD-WAN basada en rutas vEdge, las interfaces GRE funcionan como Active-standby y no Active-Active.
En un momento dado, sólo hay una interfaz GRE en estado Up/Up.
Práctica
Crear una política para listas de acceso
vEdge# show running-config policy access-list
policy
access-list GRE-In
sequence 10
match
protocol 47
!
action accept
count gre-in
!
!
default-action accept
!
access-list GRE-Out
sequence 10
match
protocol 47
!
action accept
count gre-out
!
!
default-action accept
!
!
vEdge#
Cree los contadores gre-in y gre-out y luego debe aplicar ACL a la interfaz (nuestro túnel pasa por ge0/0).
La ACL anterior se puede aplicar con la dirección de origen de la interfaz física y la dirección de destino del extremo GRE.
vEdge# show running-config vpn 0 interface ge0/0
vpn 0
interface ge0/0
ip address 198.51.100.1/24
tunnel-interface
encapsulation ipsec
max-control-connections 1
allow-service all
no allow-service bgp
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service ospf
no allow-service stun
!
no shutdown
access-list GRE-In in
access-list GRE-Out out
!
!
vEdge#
Ahora puede ver los contadores para los paquetes GRE de entrada y salida porque están en la trayectoria rápida, no se puede ver con la utilidad tcpdump.
vEdge# show policy access-list-counters
COUNTER
NAME NAME PACKETS BYTES
----------------------------------
GRE-In gre-in 176 10736
GRE-Out gre-out 88 2112
vEdge#
Este es nuestro túnel GRE.
vEdge# show interface gre1
IF IF IF TCP
AF ADMIN OPER TRACKER ENCAP PORT SPEED MSS RX TX
VPN INTERFACE TYPE IP ADDRESS STATUS STATUS STATUS TYPE TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
---------------------------------------------------------------------------------------------------------------------------------------------------------
0 gre1 ipv4 192.0.2.1/30 Up Up NA null service 1500 05:05:05:05:00:00 1000 full 1420 0:07:10:28 2968 2968
vEdge#
vEdge# show running-config vpn 0 interface gre1
vpn 0
interface gre1
ip address 192.0.2.1/30/30
tunnel-source-interface ge0/0
tunnel-destination 192.0.2.5/30
no shutdown
!
!
vEdge#
Puede verificar si el tráfico está en la interfaz GRE a través del comando show app cflowd flows.
Este es un ejemplo que muestra el tráfico bidireccional (tanto de entrada como de salida):
vEdge# show app cflowd flows
TCP TIME EGRESS INGRESS
SRC DEST IP CNTRL ICMP TOTAL TOTAL MIN MAX TO INTF INTF
VPN SRC IP DEST IP PORT PORT DSCP PROTO BITS OPCODE NHOP IP PKTS BYTES LEN LEN START TIME EXPIRE NAME NAME
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10 203.0.113.1 203.0.113.11 61478 443 0 6 16 0 203.0.113.254 3399 286304 60 1339 Sun Apr 8 10:23:05 2018 599 gre1 ge0/6
10 203.0.113.11 203.0.113.1 443 61478 0 6 24 0 203.0.113.1262556 192965 40 1340 Sun Apr 8 10:23:05 2018 592 ge0/6 gre1
Ejemplo de desactivación de keepalives (KA) en la interfaz GRE:
El valor predeterminado de KA es 10 (intervalo hello) y 3 (tolerancia)
Un KA de 0 0, inhabilita el KA en la interfaz GRE.
vEdge# show running-config vpn 0 interface gre* | details
vpn 0
interface gre1
description "Primary ZEN"
ip address <ip/mask>
keepalive 0 0
tunnel-source
tunnel-destination
no clear-dont-fragment
mtu 1500
tcp-mss-adjust 1300
no shutdown
!
Una interfaz GRE que está ACTIVA/Abajo se muestra como ACTIVA/ACTIVA (pasando la verificación KA).
Vea, TX contador aquí a medida que aumenta cuando KA está OFF. Significa que vEdge es TX para los paquetes, pero no se ve el aumento en el contador RX, lo que apunta a un problema remoto.
vEdge# show interface gre*
IF IF TCP
ADMIN OPER ENCAP PORT SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
---------------------------------------------------------------------------------------------------------------------------------------------------
### With KA ON
0 gre1 192.0.2.1/30 Up Down null service 1500 cb:eb:98:02:00:00 - - 1300 - 413218129 319299248
### With KA OFF
0 gre1 192.0.2.1/30 Up Up null service 1500 cb:eb:98:02:00:00 100 half 1300 0:00:01:19 413218129 319299280
Comentarios