Problemas de interfaz del Troubleshooting GRE
Opciones de descarga
-
ePub (82.6 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone -
Mobi (Kindle) (68.5 KB)
Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos
Acerca de esta traducción
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Introducción
Este documento describe cómo resolver problemas los problemas de interfaz del Generic Routing Encapsulation (GRE).
Antecedentes
En la solución de Viptela, los casos del uso para las interfaces GRE incluyen:
- Envíe el tráfico a ZScaler (proxy de HTTP) vía la DATA-directiva del vSmart o localmente.
- Interfaz del servicio principal GRE con el valor por defecto-detrás-para arriba al centro de datos.
- Mantenga el encadenamiento
Hay casos, cuando la interfaz GRE puede no subir y/o no trabajando.
En esas situaciones, comprobación para
- La interfaz GRE es up/up vía: muestre el gre* de la interfaz
- Señales de mantenimiento GRE vía: muestre el GRE-Keepalives del túnel
Metodología
Si hay un problema, configure una lista de control de acceso (ACL o lista de acceso) para ver si los 47) paquetes GRE (son /in de salida.
Usted no puede ver los Paquetes GRE vía el TCP vaciar, pues los paquetes son generados por el trayecto rápido.
A veces, debido al Network Address Translation (NAT), las Señales de mantenimiento GRE pueden ser caídas. En este caso, inhabilite el keepalive y vea si sube el túnel.
También, si el túnel GRE es constantemente de aleteo y que inhabilita del Keepalives, esto guarda el up/up de la interfaz.
Sin embargo, tiene una desventaja, donde si hay un problema legítimo, está duro descubrir que el GRE no trabaja.
Vea aquí en el documento que muestra un ejemplo.
Esto es un config de trabajo de la interfaz GRE
EN VPN0
vpn 0
interface gre1
ip address 192.0.2.1/30
tunnel-source <SRC-IP>
tunnel-destination <DST-IP>
tcp-mss-adjust 1300
no shutdown
!
interface gre2
ip address 192.0.2.5/30
tunnel-source <SRC-IP>
tunnel-destination <DST-IP>
tcp-mss-adjust 1300
no shutdown
!
!
EN el lado del servicio
vpn <SRVC-VPN>
service FW interface gre1 gre2
En la solución de Cisco SD-WAN basada en las rutas del vEdge, el GRE interconecta el trabajo como Activo-espera y Activo-no activo.
En cualquier momento, hay solamente la interfaz GRE que está en el estado up-up.
Práctica
Cree una directiva para las 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-en y GRE-hacia fuera y entonces usted necesita aplicar el ACL a la interfaz (nuestro túnel monta sobre ge0/0).
El ACL antedicho se puede aplicar con la dirección de origen de la interfaz física y la dirección destino del punto final 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 usted puede ver los contadores para los Paquetes GRE adentro y hacia fuera porque éstos están en el trayecto rápido, uno no puede ver con la utilidad del 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#
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#
Usted puede verificar si el tráfico va en la interfaz GRE vía el comando de los flujos del cflowd del app de la demostración.
Esto es un tráfico bidireccional de las demostraciones del ejemplo de la muestra (ambos del ingreso y de la 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
Un ejemplo de inhabilitar el Keepalives (KA) en la interfaz GRE:
El KA predeterminado es 10 (intervalo de saludo) y 3 (la 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 <SRC-IP-Addr>
tunnel-destination <DST-IP-Addr>
no clear-dont-fragment
mtu 1500
tcp-mss-adjust 1300
no shutdown
!
Una interfaz GRE que es demostraciones arriba/abajas como UP/UP (pasando el control KA).
Vea, TX contrario aquí como aumenta cuando el KA está apagado. Significa, el vEdge es TX los paquetes, pero usted no ve el aumento en el contador RX, que señala 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
Con la colaboración de ingenieros de Cisco
- Shankar VemulapalliIngeniero de Cisco TAC
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)