Acá en el 5to infierno de infomed, algunos usuarios; están acostumbrados a usar un “MUA” (léase “cliente de correo”) para alar el correo de infomed. Con el boom de la wifi, los médicos querían tener su correo de infomed en el puñetero cliente de correo de android/ios. Tras hacer un forward a los smtp y pop de infomed, el ancho de vianda se fue a la mierda. Por tanto, surgió la necesidad de chapiar el tráfico que va desde/hacia infomed. Por ejemplo, el tráfico smtp, es saliente (subida), sin embargo, el tráfico pop es entrante (bajada).

El servidor que uso como “router”, es un alpine linux. El trinomio bind, dhcp e iptables, sumado al kernel grsec; convierte en mi opinión a alpinelinux en la mejor opción para un router.

Entrando en materia. Tenemos un canal de 2 megabit (256 KB/s). Pero en HDSL, la subida es más triste que la bajada; y además, hay más gente bajando correo que subiendo. Por tanto, usaremos un canal para el smtp, más estrecho que el del pop. En este caso, eth0 será la interfaz donde está el router.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# reiniciamos las colas que hallan en eth0
# para empezar a trabajar en limpio
tc qdisc del root dev eth0
tc qdisc add dev eth0 root handle 1: htb default 30

# un canal de 256 KB/s lo partimos en dos
# una fracción de 10 KB/s y otro de 20KB/s
tc class add dev eth0 parent 1:  classid 1:1  htb rate 256kbps burst 5k
tc class add dev eth0 parent 1:1 classid 1:10 htb rate  20kbps burst 5k
tc class add dev eth0 parent 1:1 classid 1:11 htb rate  10kbps burst 5k

# lo que valla para el pop e imap, lo dejamos en el :10 con 20kbps
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 201.220.211.7 match ip sport 110 0xffff flowid 1:10
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 201.220.211.7 match ip sport 143 0xffff flowid 1:10

# lo que valla por el smtp, en el :11 de 10kbps
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 201.220.211.39 match ip dport 25 0xffff flowid 1:11

Note como en el caso de lo que venga del “.7”, (src) de los puertos pop e imap (sport) pasarán por la cola 1:10. Mientras que en el “.39”, se usan las cláusulas dst y dport.

pero aquí NO terminan las aventuras de QoS

Resulta que el tráfico proveniente de las WiFi era apabullante para el servidor proxy. Mientras que de una IP de una máquina entran 3 peticiones, de la IP de un router wifi entran 30.

En un principio pensaba usar un delay_pool especial para estas ip, pero sería complicar más el esquema de delay_pool que funciona bien por usuarios. Por tanto, el tema de la bajada ya está cubierto. Ningún usuario puede acaparar todo el ancho de banda con una descarga. Sin embargo, 1’000 peticiones de basura (android con proxy configurado) ahogan al proxy. La medida fue, que el tráfico entrante de la wifi, no exceda los 200KB.

En mi caso, los AP usan la ip 10 al 15, por tanto, haciendo un pipe de dummynet y metiéndolos a todos en ese pipe: -que se fajen por los 200KB!

1
2
3
4
5
6
7

ipfw pipe 1 config bw 200KBytes
ipfw add pipe 1 ip from 10.1.1.10 to me
ipfw add pipe 1 ip from 10.1.1.11 to me
ipfw add pipe 1 ip from 10.1.1.12 to me
ipfw add pipe 1 ip from 10.1.1.13 to me
ipfw add pipe 1 ip from 10.1.1.14 to me
ipfw add pipe 1 ip from 10.1.1.15 to me