Cisco 891F con ZBF y túnel IKEv2 con velocidades de descarga lentas

[Translator]

Hola a todos: 

en una de nuestras sucursales hemos pasado de una línea dedicada entre ubicaciones a un enlace de Internet (50 Mbps) con túnel IKEv2 a la oficina principal de nuestro router 891F. Como el router está ahora conectado a Internet, también implementamos ZBF en él para ofrecer una seguridad básica.

Todo el tráfico de la sucursal se envía a través del túnel VPN a la oficina principal y, a continuación, a donde sea necesario.

Desde el cambio los usuarios están teniendo problemas con las bajas velocidades de descarga desde la oficina principal desde cualquier fuente (es decir, descargas desde Internet, desde servidores de oficina, ...).
Por extraño que parezca, la cantidad de tráfico que se carga en los servidores de la oficina principal o en Internet o la navegación por la Web se realiza rápidamente a través de la misma ruta y del mismo equipo.

Este problema me está rascando la cabeza, ya que realmente no puedo identificar el problema ya que el enlace de Internet en sí es estable, el túnel VPN es estable, la configuración ZBF es bastante simple, no hay caídas en las interfaces, el router en sí tiene un uso de CPU de 20 - 30%, no hay NAT.

Intenté quitar ZBF entre las zonas INTERIOR y EXTERIOR sin ningún efecto, simplifiqué el ZBF, agregé el mapa del parámetro ooo como leí que podía ayudar pero nada produjo ningún resultado.

Mi sospecha es que algo en el router 891F es el problema, pero simplemente no puedo resolverlo.
Estoy adjuntando la configuración relevante y espero que alguien pueda señalar dónde buscar y cómo resolver este problema.

[Translator]

correcto, él menciona INside y OUTside así que respondo OUTside, 
Fuera es el túnel aquí.
solo quiero confirmar 

[Translator]

Nunca he configurado una interfaz de túnel como esta. ¿Algún puntero sobre cómo aplicar cambios a una interfaz de túnel específica?

[Translator]

interface GigabitEthernet8
 description Softnet internet link
 ip address x.x.x.x 255.255.255.248
 zone-member security OUTSIDE
 duplex auto
 speed auto
 no cdp enable
 crypto map Styria-VPN

 @Joseph W. Doherty usa IPSec bajo la interfaz WAN Veo su adjunto.
@igor.hamzic81 en la interfaz anterior 

[Translator]

Entonces he estado cambiando el MTU y MSS bajo la interfaz correcta sin éxito, me temo.

[Translator]

reducir más la MTU

ip mtu 1360 
ip tcp mss 1300

[Translator]

He probado el

mtu y

mss-adjust

en la interfaz externa y se dirigió a MTU 1360 y MSS 1320, pero no ha habido ningún cambio. La situación no ha cambiado con la descarga entrecortada y la carga rápida desde la sucursal. Muy frustrante.

@Joseph W. Doherty
¿Significa esto que debo aplicar estos ajustes a la interfaz de túnel o que debe colocarlos en la interfaz exterior es suficiente?

[Translator]

Debe aplicar el

MTU (unidad de transmisión básica)

y

adjust-mss

a las interfaces de túnel, no a las interfaces físicas.

[Translator]

Necesitaré confirmación de OP o revisión de la configuración adjunta (en mi teléfono, no puedo abrir archivos adjuntos), pero es posible que el cifrado no esté utilizando ninguna interfaz de túnel.  (Si es así, no he visto ese uso en años).

[Translator]

Cuando lo haga

show ip int brief

Veo lo siguiente:

Interface IP-Address OK? Method Status Protocol
Async3 unassigned YES unset administratively down down
BRI0 unassigned YES NVRAM administratively down down
BRI0:1 unassigned YES unset administratively down down
BRI0:2 unassigned YES unset administratively down down
FastEthernet0 unassigned YES NVRAM administratively down down
GigabitEthernet0 unassigned YES unset up up
GigabitEthernet1 unassigned YES unset administratively down down
GigabitEthernet2 unassigned YES unset administratively down down
GigabitEthernet3 unassigned YES unset administratively down down
GigabitEthernet4 unassigned YES unset administratively down down
GigabitEthernet5 unassigned YES unset administratively down down
GigabitEthernet6 unassigned YES unset administratively down down
GigabitEthernet7 unassigned YES unset administratively down down
GigabitEthernet8 x.x.x.x YES NVRAM up up
NVI0 x.x.x.x YES unset up up
Vlan1 unassigned YES unset administratively down down
Vlan15 10.71.3.1 YES NVRAM up up
Vlan16 10.71.1.1 YES NVRAM up up
Vlan20 10.71.2.1 YES NVRAM up up

Las interfaces Gi8 y NVI0 tienen la misma IP pública.

[Translator]

Acabo de borrar la mayor parte de lo que esta respuesta contenía anteriormente, porque aunque todavía sospecho cuál es la causa probable de su problema de rendimiento, y además creo, que podría ser remediado, no es una empresa trivial.  El uso de conformadores también sería probablemente una parte clave de la mitigación, al igual que el acceso a Internet desde la sede central para el tráfico de Internet normal o sin procesar separado del tráfico de Internet de tránsito VPN.

Su mejor opción podría ser tratar de encontrar un consultor para trabajar con usted.

Por cierto, las estadísticas del modelador de sucursales muestran:

463676 packets, 201109055 bytes
(queue depth/total drops/no-buffer drops) 0/510/0
(pkts output/bytes output) 463166/200452531

463676 - 463166 = 510 packets dropped (.11%)
201109055 - 200452531 = 656,524 bytes dropped

Ahora podemos "ver" lo que podría (¿por qué podría? porque tampoco sabemos cómo su proveedor aplica la velocidad de 50 Mbps) haber estado sucediendo dentro del trayecto de tránsito de Internet.  (De estas estadísticas, de la sucursal a la sede central, no parece estar experimentando gran parte de un problema.)

[Translator]

---

@Joseph W. Doherty escribió:

es posible que crypto no esté utilizando ninguna interfaz de túnel.

---

Buen punto. Estaba pensando en DMVPN.

En ese caso, el

adjust-mss

debe estar en la interfaz interna de los dispositivos en cada lado del link. No cambiaría la MTU.

[Translator]

"Buen punto. Estaba pensando en DMVPN".

Sí o p2p GRE o túneles VTI.

"En ese caso, el

adjust-mss

debe estar en la interfaz interna de los dispositivos en cada lado del link."

Con el antiguo enfoque de interfaz criptográfica, no hay equivalente de interfaz de túnel.  En el archivo adjunto, debería funcionar si se aplica en todas las interfaces internas (en este caso, las SVI) que utilizarán criptografía.

Si se aplica en la interfaz criptográfica, hmm Me pregunto - considerar 

TCP adjust-mss

a la luz de:

Porque

crypto map

está conectado directamente a las interfaces físicas, no hay una separación clara de funciones en el transporte subyacente frente a la sesión IPsec de superposición. Esto añade complejidad a las funciones de soporte que tratan con el tráfico pre y post encapsulado; por ejemplo, QoS pre-classify y IP access-group. Además, hay funciones que funcionan sólo con el tráfico encapsulado anterior o posterior, pero no con ambos; por ejemplo, captura de paquetes incrustada y NetFlow. No se admite el tráfico multidifusión, el tráfico no IP ni el tráfico de múltiples rutas de igual coste (ECMP).

Lógicamente,

TCP adjust-mss

se debe aplicar al flujo de texto sin formato.

Oh, por cierto, también mirando lo anterior, se encontró, el

crypto map approach

está a punto de salir.

"No cambiaría la MTU".

Cambie la MTU, definitivamente no cambie la MTU IP, generalmente se recomienda.  Sin embargo, el mismo problema con lo anterior no debería aplicarse al tráfico cifrado.  Si se aplica a la interfaz criptográfica, ¿se aplica al texto no cifrado, cifrado o ambos?

También se puede utilizar en las SVI.

Aunque a menudo se sugiere en general, para evitar la fragmentación, en el mundo real, probablemente importa poco cuando

TCP adjust-mss

está en uso.  Esto se debe a que sospecho que la mayoría del tráfico no TCP no establece un bit DF.  Y para el tráfico TCP,

TCP adjust-mss

no depende de la configuración del bit DF.

[Translator · Accepted solution]

Si hay otros sitios' mover el router a otros sitios y verificar la misma configuración' 

Veo una vez el mismo problema y finalmente el problema fue isp.

No pierda su tiempo 

Gracias 

MHM

[Translator · Accepted solution]

BTW @igor.hamzic81, para ser claro, estoy dispuesto a ayudarte más, ya que, de nuevo, he tenido experiencia (exitosamente) haciendo lo que estás haciendo.  Una vez más, sin embargo, hacer esto a través de una infraestructura de tránsito multipunto, donde no se tiene control sobre dicha infraestructura, crea muchos problemas potenciales, y para mitigar algunos de ellos, no es "bonito", o como escribí anteriormente, trivial.

Usar Internet, además, como WAN dedicada de clase empresarial requiere un gran compromiso, en el tiempo y, a veces, en el capital.  Sin embargo, hacer esto también suele ofrecer una gran rentabilidad de la inversión.

Una vez más, como hacer esto no es trivial, es por eso que recomiendo tratar de encontrar un consultor que pueda ayudarle a lograr esto.  Como, la asistencia que necesita, creo que no se puede prestar fácilmente a través de este sitio.

Por cierto, si desea crear un "prototipo" utilizando Internet como medio de transporte WAN, agregue una conexión a Internet barata en la sede central y cree un enlace p2p entre la sede central y su sucursal. p2p es fácil de optimizar y se puede hacer con poco coste en tiempo o capital.

Si te gusta cómo funciona un prototipo así, entonces puedes considerar ir a un enfoque similar a DMVPN (como lo mencionó @Elliot Dierksen), pero aunque son bastante simples de configurar, para que funcionen bien (es decir, evitar problemas de rendimiento), es la parte no trivial.

[Translator]

Hola a todos:

lo siento por la falta de respuesta, pero otros proyectos se tomaron mi tiempo. De todos modos, según la información que obtuve, parece que el problema está en un router de nuestro ISP que parece estar inundado de tráfico. Ahora están en proceso de reemplazarlo y espero que la situación sea mejor la próxima semana cuando pueda confirmar que realmente está bien (cerraré el tema entonces).

Gracias a todos por su ayuda y consejo. Realmente tengo información nueva para el futuro y realmente necesito mirar hacia el cambio del túnel VPN de la

crypto map

a una interfaz de túnel en el futuro.