Charla :


Simulación de tráfico para cálculo de QoS en redes WAN/LAN :


- Conceptos básicos de QoS
	
	- Tráfico Ingress / Egress
	- Un dibujito de como viaja un paquete por todas las cadenas de proceso del Kernel ( KNTPD).


	http://www.docum.org/docum.org/kptd/


	- Donde actúa el QOS

	- El porque de la latencia en el tráfico y su relación con el ancho de banda, explicación de escalado de ventana TCP * (ojo, mirar los apuntes que me lio)


- Schedulers: 

	- Tocken Bucket Filter 
	- Simplest Prio Scheduler
	- Tocken Bucket Filter
	- Class Based Queing (CBQ)
	- Hierarchichal Tocken Bucket (HTB)
	- Hierarchical Fair Scheduler (HFSC)
	- Random Early Drop (RED)
	- GRED

- Disciplinas de cola : Algoritmo que se encarga del sistema de repartición bajo el planificador.



- Inciso : explicar el Intermediate Queing Device (IMQ) y el ECN (Explicit Congestion Notificacion Protocol)

	
	- SFQ
	- ESFQ


#limitamos las conexiones que vayan a cualquier ip de fuera
# Enviaremos tcp-reet a las ips origen, como si la red esdtuviese saturada.

iptables --t filter -A FORWARD -s 192.168.0.0/24 -o eth1 -p tcp --syn --dport 22 -m connlimit --connlimit-above 2 -j REJECT --reject-with tcp-reset

#limitamos las conexiones a la propia maquina (eugenia)

iptables -I INPUT -p tcp --dport 22 -m connlimit --connlimit-above 2 -j REJECT --reject-with tcp-reset


# Tráfico Ingress

# esto en la gateway de una red de ips publicas, no trabajamos en PREROUTING sino en la cadena de FORWARD

# con destino la ip 80.81.113.212, no deja llegar los datos a mas # velocidad

/usr/local/sbin/iptables -t mangle -A FORWARD -i eth0 -dIMQ

- Simulación de tráfico con el módulo netem

Supongamos que queramos simular congestión y retardo de la conexiones tcp/udp entre nuestros ordenadores.

	 
NIST-Net

National Institure of Standards and Technology 

http://snad.ncsl.nist.gov/itg/nistnet/

Network Emulator

http://developer.osdl.org/shemminger/netem/



Netem es una disciplina de cola que adjuntamos como cualquier scheduler (planificador) a nuestro árbol raíz (root qdisc), con lo cual es mucho mas secillo de implementar en nuestro esquema de trabajo de QoS estándar.


Ejemplos


Este es el ejemplo mas simple. Simplemente añadimos un retardo fijo de 100 milisegundos a todos los paquetes que salgan de la red


# tc qdisc add dev eth0 root netem delay 100ms


Retardo de tráfico variable

Las redes reales tienen latencia variable. Es posible añadirle variación de la pseudoaleatoriedad


# tc qdisc change dev eth0 root netem delay 100ms 10ms


y añadimos una latencia variable de 100 milisegundos ± 10 . la variación no puede ser aleatoria pura, claro está.


# tc qdisc change dev eth0 root netem delay 100ms 10ms 25%

Con esta instrucción añadimos un retardo variable de 100 milisegundos y otros ± 10 milisegundos variables, esta segunda variable con un orden de aleatoriedad del 25% dependiente del anterior paquete enviado.

Ojo, el emulador netem no usa correlación estadística, asi que no podemos esperar distribución homogenea, pero nos hacemos una idea aproximada de variación aleatoria.


Distribución del retardo

En una red de verdad, lo normal es que la latencia tenga "saltos" de más a menos. El emulador sería bastante inexacto si trabajamos con valores fijos. Es más lógico emplear una distribución normal para describir la variación en el retardo.

Podemos utilizar una tabla para especificar una distribución no uniforme en la simulación.

# tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal

Las tablas disponible (normal, pareto, paretonormal) vienen con la distribución estándar de traffic control. Nada nos impide crear nuestra propia distribución


Pérdida de paquetes pseudoaleatoria

Podemos crear un tanto por ciento de pérdida de paquetes pseudoaleatorio, la frecuencia de ajuste máximo es 

1/232 = .0000000232%

y depende la frecuencia del timer que hayamos especificado en el kernel al compilarlo (100 Hz por defecto).


# tc qdisc change dev eth0 root netem loss .1%

También le podemos adjuntar un parámetro de correlación

Duplicación de paquetes

Podemos duplicar paquetes. La sintaxis es la misma que acabamode de ver de la pérdida de paquetes.


# tc qdisc change dev eth0 root netem duplicate 1%

Reordenación de paquetes

Netem tambien implemententa reordenación de paquetes, lo que significa que uno de cada N paquetes sufra el retardo que le indiquemos.

# tc qdisc change dev eth0 root netem gap 5 delay 10ms

"gap" es hueco, así que de cada vez, el quinto paquete del grupo (5º, 10º, 15º, ...) tendrá un retraso extra de 10 milisegundos. El resto de paquetes pasará sin ninguna modificación.

Control de flujos de datos

No hay control de tasa de transferencia

¿?

La verdad es que teniendo todo el sistema QoS del kernel Linux, sería una tontería implementarlo en la disciplina netem. En vez de eso, usemo una de las muchas disciplinas que
controlan la velocidad de red. En el ejemplo de la FAQ de netem, utilizamos un Token Bucket Filter (TBF) para limitar la velocidad de salida.

# tc qdisc add dev eth0 root handle 1:0 netem delay 100ms
# tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 256kbit buffer 1600 limit 3000

# tc -s qdisc ls dev eth0
qdisc netem 1: limit 1000 delay 100.0ms
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0 )
qdisc tbf 10: rate 256Kbit burst 1599b lat 26.6ms
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0 )


Ejemplos avanzados : Simulación de retardo hacia un host específico.

En este ejemplo limitaremos el tráfico con destino a una sola IP, algo muy útil en implementaciones de tráfico de VoIP, servidores de juegos o cualquier otro servicio que dependa en gran manera de la latencia del tráfico


# tc qdisc add dev eth0 root handle 1: prio
# tc qdisc add dev eth0 parent 1:6 handle 30: netem \
    delay 200ms 10ms distribution normal

Este comando crea una disciplina de cola de prioridad simple y le adjunta una disciplina netem al handler de prioridad 6

# tc qdisc add dev eth0 parent 30:1 tbf rate 20kbit buffer 1600 limit 3000


Ahora añadimos un scheduler TBF como clase hija para la gestión de la tasa de transferencia de tráfico.

# tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 \
    match ip dst 192.168.0.5/32 flowid 10:6


y para terminar, un filtro clasifica todos los paquetes que salen a la ip 192.168.0.5 con máscara /32 (uno solo host) con prioridad 6



¿Como funciona generar una latencia o pérdida aleatoria pero que cumpla una regla?

Generamos un número aleatorio para hacer un busqueda en una tabla de distribución, generando un valor "número de desviación estándar" (multiplicado por un factor de escala para hacerla integral. El valor de la latencia queda así

    retardo esperado + (# de desviacíon estándar)*(tamaño de la desviación estándar)/escala 


DANIEL@SERIOUSWORKS.NET
http://jopi.seriousworks.net