Generador de latencia para simular condiciones reales de enlaces WAN

Fecha: 28 de octubre del 2014 Clase: Exploration 3

Escenario

En este escenario se intentan reproducir las condiciones de latencia propias de enlaces WAN,

y que no son posibles en un ambiente de laboratorio, como muchos escenarios de las clases.

En las pruebas originales se utilizó una versión trial de un simulador de enlaces, pero la idea original

se gestó en una charla en el cofee break de las clases con un alumno para crear un prototipo casero

y configurar la latencia a demanda con un preset.

Todo el mérito de este desarrollo es de Nahuel Osella quien le dio vida al prototipo.

Pruebas con el software de emulación de latencia

C:\Users\CIT>ping 192.168.72.101 -t

Haciendo ping a 192.168.72.101 con 32 bytes de datos:

Respuesta desde 192.168.72.101: bytes=32 tiempo=480ms TTL=128

Respuesta desde 192.168.72.101: bytes=32 tiempo=289ms TTL=128

Respuesta desde 192.168.72.101: bytes=32 tiempo=47ms TTL=128

Respuesta desde 192.168.72.101: bytes=32 tiempo=642ms TTL=128

Respuesta desde 192.168.72.101: bytes=32 tiempo=521ms TTL=128

---resumido---

Respuesta desde 192.168.72.101: bytes=32 tiempo=839ms TTL=128

Respuesta desde 192.168.72.101: bytes=32 tiempo=198ms TTL=128

Tiempo de espera agotado para esta solicitud.

Respuesta desde 192.168.72.101: bytes=32 tiempo=477ms TTL=128

Respuesta desde 192.168.72.101: bytes=32 tiempo=832ms TTL=128

Tiempo de espera agotado para esta solicitud.

Respuesta desde 192.168.72.101: bytes=32 tiempo=266ms TTL=128

Respuesta desde 192.168.72.101: bytes=32 tiempo=746ms TTL=128

Tiempo de espera agotado para esta solicitud.

Respuesta desde 192.168.72.101: bytes=32 tiempo=412ms TTL=128

---resumido---

Respuesta desde 192.168.72.101: bytes=32 tiempo=231ms TTL=128

Estadísticas de ping para 192.168.72.101:

Paquetes: enviados = 50, recibidos = 39, perdidos = 11

(22% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

Mínimo = 47ms, Máximo = 842ms, Media = 470ms

Pruebas con el generador de latencia de “Circo System”

Pruebas iniciales del prototipo

(gentileza de Nahuel Osella)

C:\Users\CIT>ping -t 192.168.1.201 (esta es la IP del generador)

Haciendo ping a 192.168.1.201 con 32 bytes de datos:

Respuesta desde 192.168.1.201: bytes=32 tiempo=65ms TTL=100 (con 60 mseg de retardo)

Respuesta desde 192.168.1.201: bytes=32 tiempo=60ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=62ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=63ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=11ms TTL=100 (con 10 mseg de retardo)

Respuesta desde 192.168.1.201: bytes=32 tiempo=10ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=9ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=7ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=223ms TTL=100 (con 300 mseg de retardo)

Respuesta desde 192.168.1.201: bytes=32 tiempo=294ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=293ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=520ms TTL=100 (con 500 mseg de retardo)

Respuesta desde 192.168.1.201: bytes=32 tiempo=573ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=570ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=575ms TTL=100

Respuesta desde 192.168.1.201: bytes=32 tiempo=2060ms TTL=100 (con 2000 mseg de retardo)

Respuesta desde 192.168.1.201: bytes=32 tiempo=2176ms TTL=100

---resumido---

Estadísticas de ping para 192.168.1.201:

Paquetes: enviados = 139, recibidos = 139, perdidos = 0

(0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

Mínimo = 7ms, Máximo = 2182ms, Media = 547ms

Control-C

Pruebas reales con tráfico IPSec

Con este escenario se intenta verificar las caídas del tunel IPSec por pérdidas de paquetes, pérdidas por latencia

o paquetes duplicados. Se intenta generar una conexión tan miserable como las condiciones reales a las que se

enfrenta el tráfico en internet.

El HUB en el centro, aporta colisiones y como TAP para sniffear el tráfico en la WAN.

(gentileza de Nahuel Osella)

Verificación

Cordoba#sh crypto ipsec sa

IPv4 Crypto ISAKMP SA

dst src state conn-id status

192.168.11.10 192.168.10.10 QM_IDLE 1004 ACTIVE

IPv6 Crypto ISAKMP SA

Cordoba#

Cordoba#sh crypto ipsec sa

interface: FastEthernet0/1

Crypto map tag: VPN, local addr 192.168.11.10

protected vrf: (none)

local ident (addr/mask/prot/port): (172.16.2.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (172.16.1.0/255.255.255.0/0/0)

current_peer 192.168.10.10 port 500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 9105, #pkts encrypt: 9105, #pkts digest: 9105

#pkts decaps: 9109, #pkts decrypt: 9109, #pkts verify: 9109

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 27 (paquetes duplicados)

---resumido---

Cordoba#

Utilización de la función “duplicador de paquetes” para verificar el check de IPSec

*Oct 27 22:09:21.382: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed

connection id=5, sequence number=39

*Oct 28 00:21:04.617: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed

connection id=29, sequence number=321

*Oct 27 22:06:43.710: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed

connection id=3, sequence number=326

La VPN nunca se cayó, por consiguiente, el IPSec, al menos en esta prueba, no se vuelve inestable

ante latencia, la próxima prueba será también con mayor pérdida de paquetes, allá vamos.

Configuración de los equipos

Rosario#sh runn

Building configuration...

Current configuration : 1299 bytes

version 12.2

hostname Rosario

ip dhcp pool DHCP

network 172.16.1.0 255.255.255.0

default-router 172.16.1.1

crypto isakmp policy 10

encr aes 256

authentication pre-share

group 5

lifetime 3600

crypto isakmp key Presh4red address 192.168.11.10

crypto ipsec transform-set ENCRIPTA esp-3des esp-sha-hmac

mode transport

crypto map MYMAP 10 ipsec-isakmp

set peer 192.168.11.10

set security-association lifetime seconds 900

set transform-set ENCRIPTA

set pfs group5

match address 101

interface Ethernet0

ip address 172.16.1.1 255.255.255.0

ip nat inside

interface Ethernet1

ip address 192.168.10.10 255.255.255.0

ip nat outside

crypto map MYMAP

ip nat inside source list 100 interface Ethernet1 overload

ip classless

ip route 0.0.0.0 0.0.0.0 192.168.10.1

access-list 100 deny ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255

access-list 100 permit ip 172.16.1.0 0.0.0.255 any

access-list 101 permit ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255

end

Rosario#

Cordoba#sh runn

Building configuration...

Current configuration : 1934 bytes

version 12.4

hostname Cordoba

ip dhcp pool DHCP

network 172.16.2.0 255.255.255.0

default-router 172.16.2.1

crypto isakmp policy 10

encr aes 256

authentication pre-share

group 5

lifetime 3600

crypto isakmp key Presh4red address 192.168.10.10

crypto ipsec transform-set ENCRIPTA esp-3des esp-sha-hmac

mode transport

crypto map VPN 10 ipsec-isakmp

set peer 192.168.10.10

set security-association lifetime seconds 900

set transform-set ENCRIPTA

set pfs group5

match address 101

interface FastEthernet0/0

ip address 172.16.2.1 255.255.255.0

ip nat inside

interface FastEthernet0/1

ip address 192.168.11.10 255.255.255.0

ip nat outside

crypto map VPN

ip route 0.0.0.0 0.0.0.0 192.168.11.1

ip classless

ip nat inside source list 100 interface FastEthernet0/1 overload

access-list 100 deny ip 172.16.2.0 0.0.0.255 172.16.1.0 0.0.0.255

access-list 100 permit ip 172.16.2.0 0.0.0.255 any

access-list 101 permit ip 172.16.2.0 0.0.0.255 172.16.1.0 0.0.0.255

end

Cordoba#

(2014) Networking may cause paranoid minds

Rosario, Argentina