QoS parte 1: MANGLE

Definiciones: Para que sea de fcil entendimiento har algunas definiciones artesanas para el caso concreto que vamos a desarrollar. El caso que se desarrollar en esta gua es el de peticiones/establecimiento/respuesta en una conexin a internet; osea desde una red local hacia la nube (internet). No tomaremos la nomenclatura usada en la wiki porque trae confusin, pero si mencionaremos como encaja cada definicion con la info de la wiki. Interfaces consumidoras, son las interfaces desde las cuales se realizan las solicitudes de conexin, para nuestro caso solicitudes a internet; estas interfaces son las que usamos para conectar las computadoras de nuestra red cableada y/o inalmbrica. Interface productora, es la interface que responde a una conexin de solicitud de una interface consumidora; esta interface comunmente es por la cual nos conectamos a internet. Se sabe que este tipo de conexin -conexin a internet, entiendase conexin a una pgina web, http, TCP- tiene siempre dos sentidos, directo y reverso, envio y recepcion. Para no complicar el asunto el marcado lo haremos considerando slo un sentido, y hablando de interfaces el sentido ser desde las interfaces consumidoras hacia la productora. Para nuestro caso especifico y segun el packet flow de la wiki de mikrotik: Nuestra interface consumidora vendra a ser la Interface In. y la interface productora sera la Interface Out. Por el sentido nico adoptado en este ejemplo todas las interfaces consumidoras (donde se inicia la peticin) aportarn al Global In, y las productoras (de donde llega la respuesta) aportarn al Global Out. Global-In y Global-out son dos de las tres interfaces virtuales que mikrotik tiene para contabilizar los packetes. La tercera interface es Global-Total. Desarrollo Analizaremos el caso de las conexines web a los puertos 80 y 443, conexiones a las que le daremos el mismo tratamiento, vale decir que compartirn el mismo marcado y a causa de esto en un posterior manejo de colas sern tratados bajo las mismas reglas. Datos: interface productora = WAN interfaces consumidoras = LAN, LAN1, LAN2 Algunos tienen todas sus interfaces consumidoras unidas con un puente por tanto tambin pueden usar interface consumidora = BRIDGE1 por ejemplo.

Otros pueden tener sus interfaces consumidoras en modo switch por tanto pueden usar como interface consumidora = interface que hace de master-port. Marcado de la conexin a travs de las interfaces consumidoras, sentido directo. Marcar la conexin primero asegura una mayor rapidez en el posterior marcado de los paquetes, tambin asegura la trazabilidad de los mismos. Estas reglas le sern familiares.

/ip firewall mangle add action=mark-connection chain=prerouting comment="Https up connection" \ disabled=no dst-port=443 in-interface=LAN new-connection-mark=\ http_up_cnx passthrough=yes protocol=tcp add action=mark-connection chain=prerouting comment="Http up connection" \ disabled=no dst-port=80 in-interface=LAN new-connection-mark=http_up_cnx \ passthrough=yes protocol=tcp

"Marcar la conexin de los paquetes (mark-connection) antes de rutear (prerouting) que inician en la LAN (in-interface) y tienen como puerto destino 443 (dst-port) y dejar pasar para su posterior uso (passthrough=yes)" Ntese que hemos declarado el parmetro in-interface=LAN esto significa que unicamente vamos a marcar paquetes que transiten por esa interface, las otras LAN1 LAN2.. quedan sin control de calidad. Usted puede declarar el parmetro in-interface=!WAN y tener la flexibilidad de considerar a todas las interfaces consumidoras en una sola regla. Osea luego de este cambio la regla marcara los paquetes de todas la interfaces consumidoras. Tambin se puede declarar in-interface=BRIDGE1 en caso de tener las interfaces de la LAN con puente. Si las tiene en modo SWITCH (routerOS v 5.X) basta con declarar en in-interface la interface master. Estas dos reglas podrian unirse en una considerando dst-port=443,80 en las versiones 5.X para la 3.X introduciendo la regla por Terminal. Muchos consideran innecesario declarar in-interface o src-address en esta regla y eso es un error comn, es lo que denomino conexiones no-explcitas. Obviamente al no especificar estos datos el marcado se va a realizar en todas las interfaces y en todos los sentidos posibles. En el caso de tener un proxy paralelo externo (ej. Squid o TC) no es recomendable usar el artificio in-interface=!WAN, porque se estara incluyendo en la regla del marcado a la interface que le corresponde al proxy y esto puede causar trabajo innecesario al routerOS.

Marcado de los paquetes enviados a travs de las conexiones establecidas Esta regla le ser familiar.

"Marcar los paquetes (mark-packet) antes del rutear (prerouting) provenientes de la conexin especificada (connection-mark) y no dejar pasar (passthrough=no)" Cdigo:
add action=mark-packet chain=prerouting comment="Http up packet" \ connection-mark=http_up_cnx disabled=no new-packet-mark=http_up_pkt \ passthrough=no

Hasta aqu ya hemos marcado los paquetes que se inician en la interface consumidora y que tienen por destino la interface productora (este sentido al que denominamos directo o peticin esta formado por los paquetes que se suben hacia la nube) Ahora llega el momento de marcar los paquetes de la conexin de recepcin en la/s interface/s productora/s. Pero antes de caer en error debemos recordar lo siguiente: Que la conexin que desarrollamos en este ejemplo tiene dos sentidos gracias a la maga del routerOS, por tal razn no es necesario marcar la conexin de recepcin en su reemplazo podemos seguir usando la conexin de peticin y restara slo marcar los paquetes de recepcin. "Marcar los paquetes (mark-packet) despues de rutear (postrouting) provenientes de la conexin especificada (connection-mark) que terminan en la LAN (outinterface) y no dejar pasar (passthrough=no)" (fragmento) Cdigo:
add action=mark-packet chain=postrouting comment="Http down small packet" \ connection-mark=http_up_cnx out-interface=LAN connection-bytes=0-256000 disabled=no new-packet-mark=http_down_pkt \ protocol=tcp passthrough=no

Ntese que estamos usando el parmetro connection-mark=http_up_cnx Un error comun es evitar el uso del connetion-mark y en reemplazo hacer el marcado usando la cadena postrouting, especificando una interface o cualquier otro parmetro para intentar identificar la conexion de recepcin, podra usarse, pero hacerlo as no asegura que esa conexin sea la conexin reversa que da respuesta a la conexion directa del consumidor y que es la que nos interesa controlar. En la muestra anterior se esta considerando contabilizar el tamao de la conexion de recepcin, vea connection-bytes=0-256000 Sabemos que una conexin web puede usarse para ver pginas como tambin para descargar archivos por tanto podemos nombrar de tres modos distintos a los paquetes que provienen de una conexin en pequea, media y grande, segun la cantidad de informacin que se obtiene. El bloque completo sera como se muestra a continuacin: Cdigo:
/ip firewall mangle

add action=mark-packet chain=postrouting comment="Http down small packet" \ connection-mark=http_up_cnx out-interface=LAN disabled=no new-packetmark=http_down_pkt \ passthrough=no protocol=tcp connection-bytes=0-256000 add action=mark-packet chain=postrouting comment="Http down medium packet" \ connection-mark=http_up_cnx out-interface=LAN disabled=no new-packetmark=\ http_down_medium_pkt passthrough=no protocol=tcp connection-bytes=256000-512000 add action=mark-packet chain=postrouting comment="Http down large packet" \ connection-mark=http_up_cnx out-interface=LAN disabled=no new-packetmark=\ http_down_big_pkt passthrough=no protocol=tcp connection-bytes=512000-0

Hasta este punto usted tiene una regla de marcado correcta de las tantas que pueden realizarse. La cual identifica plenamente una conexin en sus dos sentidos, con verdadera traza y a la cual puede contabiliza correctamente la cantidad de informacin que comparte.

<---------------complemento--------------> A manera de ejemplo y para su uso posterior en el captulo Queue Tree, escribiremos las reglas correspondientes para algunos servicios y conexiones importantes (desde luego usted podr adaptar o crear sus propias reglas segn su necesidad) para seguir nuestro modelo. Siga el orden en el cual se presentan las reglas. ICMP y DNS, estas conexiones manejan una cantidad de informacin pequea por lo que las reglas para recepcin sern obviadas, lo que se busca es dar paso priorizado al envio. Cdigo:
/ip firewall mangle add action=mark-connection chain=prerouting comment="Icmp connection" \ disabled=no new-connection-mark=icmp_cnx passthrough=yes protocol=icmp add action=mark-packet chain=prerouting comment="Icmp packet" \ connection-mark=icmp_cnx disabled=no new-packet-mark=icmp_pkt \ passthrough=no add action=mark-connection chain=prerouting comment="Dns connection" \ disabled=no dst-port=53 new-connection-mark=dns_cnx passthrough=yes \ protocol=tcp add action=mark-connection chain=prerouting comment="Dns connection" \ disabled=no dst-port=53 new-connection-mark=dns_cnx passthrough=yes \ protocol=udp add action=mark-packet chain=prerouting comment="Dns packet" connectionmark=\ dns_cnx disabled=no new-packet-mark=dns_pkt passthrough=no

Ntese que para este servicio no estamos siendo explcitos en cuanto a la interface de entrada (in-interface), esto por que estamos planeando marcar peticiones de

cualquier interface y en cualquier sentido. Esta regla le es totalmente familiar. WEBCACHE, la regla siguiente es para que ustedes denominan full cache, es la que aplicamos a las peticiones http. y la variacin que sufre es el paramtro chain=postrouting y se preguntarn por que ya no uso chain=output? la respuesta es simple: nosotros ahora estamos controlando la conexin desde que se inicia hasta que termina, tenemos su traza y si queremos identificarlo tendremos que interceptarlo justo antes de marcamos como recepcin osea antes de marcarlo como http_up_cnx q se efectua en chain=postrouting. Cdigo:
add action=mark-packet chain=postrouting comment="Cache webproxy" disabled=no \ dscp=4 new-packet-mark=cache_pkt passthrough=no

Tome nota que usamos dscp=4 y este es el valor que previamente establecimos en el servidor webproxy TOS (DSPS). WINBOX, marcado para nuestro programa de administracin. A partir de ahora marcaremos tanto la conexin de envio como la de recepcin. Cdigo:
add action=mark-connection chain=prerouting comment="WinBox connection" \ disabled=no dst-port=8291 in-interface=LAN new-connection-mark=winbox_cnx passthrough=yes \ protocol=tcp add action=mark-connection chain=prerouting comment="WinBox connection" \ disabled=no dst-port=20561 in-interface=LAN new-connection-mark=winbox_cnx passthrough=yes \ protocol=udp add action=mark-packet chain=prerouting comment="WinBox packet" \ connection-mark=winbox_cnx disabled=no new-packet-mark=winbox_pkt \ passthrough=no add action=mark-packet chain=postrouting comment="WinBox packet" \ connection-mark=winbox_cnx out-interface=LAN disabled=no new-packet-mark=\

MSN, YOUTUBE y P2P Cdigo:

add action=mark-connection chain=prerouting comment="Msn connection" \ disabled=no dst-port=1863 in-interface=LAN new-connection-mark=msn_cnx \ passthrough=yes protocol=tcp add action=mark-packet chain=prerouting comment="Msn packet" connectionmark=\ msn_cnx disabled=no new-packet-mark=msn_pkt passthrough=no add action=mark-packet chain=postrouting comment="Msn down packet" \ connection-mark=msn_cnx out-interface=LAN disabled=no new-packetmark=msn_down_pkt \ passthrough=no add action=mark-connection chain=prerouting comment="YouTube connection" \ disabled=no dst-address=208.117.224.0/19 in-interface=LAN \ new-connection-mark=youtube_cnx passthrough=yes add action=mark-connection chain=prerouting comment="YouTube connection" \

content=youtube disabled=no dst-address=74.125.0.0/16 in-interface=LAN \ new-connection-mark=youtube_cnx passthrough=yes add action=mark-packet chain=prerouting comment="YouTube packet" \ connection-mark=youtube_cnx disabled=no new-packet-mark=youtube_pkt \ passthrough=no add action=mark-packet chain=postrouting comment="YouTube down packet" \ connection-mark=youtube_cnx out-interface=LAN disabled=no new-packet-mark=\ youtube_down_pkt passthrough=no add action=mark-connection chain=prerouting comment="P2p connection" \ disabled=no in-interface=LAN new-connection-mark=p2p_cnx p2p=all-p2p \ passthrough=yes add action=mark-packet chain=prerouting comment="P2p packet" connectionmark=\ p2p_cnx disabled=no new-packet-mark=p2p_pkt passthrough=no

Aqui todas las reglas que se escribieron inicialmente, nos referimos a las reglas para las conexiones Https y Http mostradas. Cdigo:
add action=mark-connection chain=prerouting comment="Https up connection" \ disabled=no dst-port=443 in-interface=LAN new-connection-mark=\ http_up_cnx passthrough=yes protocol=tcp add action=mark-connection chain=prerouting comment="Http up connection" \ disabled=no dst-port=80 in-interface=LAN new-connection-mark=http_up_cnx \ passthrough=yes protocol=tcp add action=mark-packet chain=prerouting comment="Http up packet" \ connection-mark=http_up_cnx disabled=no new-packet-mark=http_up_pkt \ passthrough=no add action=mark-packet chain=postrouting comment="Http down small packet" \ connection-mark=http_up_cnx out-interface=LAN disabled=no new-packetmark=http_down_pkt \ passthrough=no protocol=tcp connection-bytes=0-256000 add action=mark-packet chain=postrouting comment="Http down medium packet" \ connection-mark=http_up_cnx out-interface=LAN disabled=no new-packetmark=\ http_down_medium_pkt passthrough=no protocol=tcp connection-bytes=256000-512000 add action=mark-packet chain=postrouting comment="Http down large packet" \ connection-mark=http_up_cnx out-interface=LAN disabled=no new-packetmark=\ http_down_big_pkt passthrough=no protocol=tcp connection-bytes=512000-0

Y luego finalizamos con FTP, Otras UDP, Otras TCP. Cdigo:

add action=mark-connection chain=prerouting comment="FTP connection" \ disabled=no dst-port=20-21 in-interface=LAN new-connection-mark=ftp_cnx \ passthrough=yes protocol=tcp add action=mark-packet chain=prerouting comment="FTP packet" connectionmark=\ ftp_cnx disabled=no new-packet-mark=ftp_pkt passthrough=no

Tarea redactar FTP down connection.

Cdigo:
add action=mark-connection chain=prerouting comment="Otras UDP connection" \ disabled=no in-interface=LAN new-connection-mark=otras_udp_cnx \ passthrough=yes protocol=udp add action=mark-packet chain=prerouting comment="Otras UDP packet" \ connection-mark=otras_udp_cnx disabled=no new-packet-mark=otras_udp_pkt \ passthrough=no add action=mark-packet chain=postrouting comment="Otras udp down packet" \ connection-mark=otras_udp_cnx out-interface=LAN disabled=no new-packet-mark=\ otras_udp_all_pkt passthrough=no

Cdigo:
add action=mark-connection chain=prerouting comment="Otras connection" \ disabled=no in-interface=LAN new-connection-mark=otras_cnx passthrough=\ yes protocol=tcp add action=mark-packet chain=prerouting comment="Otras packet" \ connection-mark=otras_cnx disabled=no new-packet-mark=otras_pkt \ passthrough=no add action=mark-packet chain=postrouting comment=\ "Otras down small connection" connection-bytes=0-512000 connection-mark=\ otras_cnx out-interface=LAN disabled=no new-packet-mark=otras_small_pkt passthrough=no \ protocol=tcp add action=mark-packet chain=postrouting comment=\ "Otras down large connection" connection-bytes=512000-0 connection-mark=\ otras_cnx out-interface=LAN disabled=no new-packet-mark=otras_large_pkt passthrough=no \ protocol=tcp

Se consider segmentar las conexiones de descarga para Otras down segn el tamao de informacin. <-----------------------------------------------> Una regla importante y que por dems interesante es la de segmentar las conexiones de envio segn el tamao de informacin que contiene o acumula. Esta regla correspondera a la seccion de las conexiones Http_up_cnx. Se deja cmo tarea escribir dicha regla.

No se pierda la prxima entrega Qos parte 2: QUEUE TREE Ver cmo afecta la restriccin de la velocidad de subida a la de descarga sincronizadamente gracias a esta forma de marcado. Y algunas otra mejoras a los modelos que ya conoce.

QoS parte 2 : QUEUE TREE

Resumen del captulo anterior: De las reglas para Mangle. Ya sabemos y tenemos marcadas nuestras conexiones y paquetes para determinado servicio, sea DNS, peticiones Http, YouTube, etc. Tambin tenemos identificadas las conexiones tanto de envio como de recepcin iniciadas desde todas nuestras interfaces consumidoras, incluso segmentadas por volumen de informacin transmitida. Cabe resaltar que gracias a la manera en la cual se ha procedido a marcar los paquetes en el Mangle (vese chain e interface de las reglas), los paquetes marcados aportarn valores para las dos variables integradoras globales, y esto es como sigue: Chain prerouting a GlobalIn (que representar todo lo que se sube por la interface LAN) y chain postrouting a GlobalOut (que representar todo lo que se baja por la interface LAN). Definiciones: Lo escrito aqui cumple principalmente para nuestro ejemplo de conexin a internet, tambin para cualquier tipo de conexin pero las magnitudes deberian reproporcionarse. Para entender el rbol de colas (Queue Tree), recreativamente diremos que esto es como una especie de campo de concentracin en el cual nosotros tendremos paquetes marcados pertenecientes a dos bandos, un bando que pertenece al GlobalIn (paquetes de envio) y otro al GlobalOut (paquetes de recepcion). Este campo de concentracin tiene una puerta angosta de entrada, una ventana amplia en el techo y al otro extremo un portn enorme de evacuacin. Por la puerta angosta (ADSL_UP) es por donde se inician los paquetes de envio, por cada paquete de envio que ingresa y es procesado (ROUTING) para seguidamente ser enviado fuera, desde la nube (INTERNET) y entrando por el techo (ADSL_DOWN) muchos paquetes de recepcin ingresan al campo de concentracin (BUFFER_ROUTER) y estos paquetes de recepcin normalmente debieran salir raudamente por el porton (LAN_WLAN). De este pequea ilustracin usted puede deducir cmo debera controlar correctamente la descarga, nte que todo se origina con el paquete de envio, que podemos cuantificar. En contraste como respuesta no sabemos a exactamente cuanto paquete va a ingresar. El rbol de colas no es nada ms diferente al ordenamiento y la formacin de filas que deben hacer todos los paquetes tanto de envio como recepcin dentro del campo de concentracin, otorgandoles diferentes prioridades en procesamiento a determinados paquetes que pertenecen a servicios especficos, asi cmo tambin indicando las velocidades a la que deben fluir. Desarrollo La parte ms importante de un buen manejo de colas es la inclusin de reglas para mximos de velocidad y seteos prioridades de a los paquetes de envio, osea un buen manejo del grupo del GlobalIn asegura casi siempre un resultado deseado homlogo en el grupo de los paquetes recibidos GlobalOut. Para aquellas conexiones en que no sea posible regular los paquetes recibidos a partir de una regulacin de los paquetes enviados, se tendra que regularlos indirectamente.

Una regulacin indirecta se logra haciendo que los paquetes hagan colas y se retrasen, acumulndolos en el buffer -esto a veces causa saturacin del equipo y otras muchas veces latencia en la conexin-, logrando de esta manera que el servidor que esta en la nube no reciba la conformidad de entrega a tiempo o tambin explicitamente se logra desechando los paquetes; el servidor en la nube entender que debe bajar su velocidad de entrega o cerrar dicha conexin. Un error comn es dedicarse a restringir las descargas, obviando por completo las subidas; esto causa un desperdicio del ancho de banda y posible saturacin del buffer del routerOS. Si los paquetes ya llegaron a nuestro router deberiamos siempre despacharlos, pues ya se hizo uso del ancho de banda de descarga y se continuar mientras no limitemos/priorizemos las subidas. Nuestro rbol tendr dos ramas principales, una llamada Peticiones asociada al GlobalIn u otra llamadaRecepciones asociada al GlobalOut. Es posible que muchos de ustedes usen el apartado SimpleQueue para hacer alguna limitacin por IP/Cliente por tal motivo los parent de las ramas principales van a ser cambiadas a las respectivas out-interface's . Osea, las peticiones terminan en la interface productora WAN y las recepciones terminan en la interface consumidora LAN. Cdigo:
/queue tree add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=256k \ max-limit=256k name=Peticion parent=WAN priority=1 add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=1024k \ max-limit=1024k name=Recepcion parent=LAN priority=1

Nte la limitacion de velocidad, max-limit de 256k y 1024k para subida y descarga, usted debera usar un 90% del valor global que desea repartir entre todos sus usuarios y que efectivamente su proveedor le pueda otorgar. Puesto que estas ramas son principales se est asignando todo el ancho efectivo en los parmetros limi-at y max-limit. Para la rama de peticiones: Cdigo:
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=32k name=Dns_in packet-mark=dns_pkt parent=Peticion priority=1 \ queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=32k name=Icmp_in packet-mark=icmp_pkt parent=Peticion priority=\ 1 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=24k name=Msn_in packet-mark=msn_pkt parent=Peticion priority=4 \ queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=96k \ max-limit=128k name=Ftp_in packet-mark=ftp_pkt parent=Peticion priority=8 \ queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=128k name=Winbox_in packet-mark=winbox_pkt parent=Peticion \ priority=1 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=16k name=Youtube_in packet-mark=youtube_pkt parent=Peticion \ priority=8 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=1k \ max-limit=2k name=P2p_in packet-mark=p2p_pkt parent=Peticion priority=8 \

queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=256k name="Http Up" packet-mark=http_up_pkt parent=Peticion \ priority=1 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=96k \ max-limit=128k name=Otras packet-mark=otras_pkt parent=Peticion priority=\ 8 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=48k \ max-limit=64k name=Otras_UDP packet-mark=otras_udp_pkt parent=Peticion \ priority=8 queue=default

Es importante no olvidar establecer max-limit a todas las reglas del rbol as como tambin setearles un priority segn convenga a la red. Una regla importante para hacer el llenado: Valores limit-at: la suma de todos los valores asignados a las ramas hijas deben ser menor o igual al valor seteado en la rama padre. Valores max-limit: el valor asignado a la rama hija no sebe superar al valor seteado en la rama padre. Nte que muchas de las velocidades max-limit que se usan en esta seccion son pequeas, pero son lo suficiente como para que envie la peticin y pueda responder continuamente la conformidad de recepcin de los paquetes en la conexin. Para la rama Recepcin: Cdigo:
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=1024k name="Http down small" packet-mark=http_down_pkt parent=\ Recepcion priority=1 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=896k name="Http down medium" packet-mark=http_down_medium_pkt \ parent=Recepcion priority=4 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=768k name="Http down big" packet-mark=http_down_big_pkt parent=\ Recepcion priority=8 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=512k name="Otras udp" packet-mark=otras_udp_all_pkt parent=\ Recepcion priority=8 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=768k name="Otras small" packet-mark=otras_small_pkt parent=\ Recepcion priority=4 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=512k name="Otras large" packet-mark=otras_large_pkt parent=\ Recepcion priority=8 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=512k name="Msn down" packet-mark=msn_down_pkt parent=Recepcion \ priority=4 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=512k name="Winbox down" packet-mark=winbox_down_pkt parent=\ Recepcion priority=1 queue=default add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=768k name="Youtube down" packet-mark=youtube_down_pkt parent=\ Recepcion priority=8 queue=default

Al igual que en la rama de Peticiones no debe olvidar setear valores para limit, max-limit y priority.

Y un pequeo bastago en el tronco principal que lo usamos para el full cach, esto sirve para escapar del lmite de descarga impuesto a Recepcin Cdigo:
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=4M name="Cache full" packet-mark=cache_pkt parent=global-out \ priority=1 queue=default

El uso de rfagas en la rama de Recepcin es un desperdicio de recursos, en vez de ello usted podra pensar en subirle la velocidad mxima, puesto que el ancho de banda es este lado de la red es amplio. El uso de rfagas en la rama de Peticion es muy til y podra usarlo para dar un empuje a conexiones que compiten continuamente. Tambien para peticiones que tienen menos prioridad y que desea darles aliento pero manteniendolos al margen es muy recomendado. Ya por finalizar esta entrega me gustara adelantar algunos tips. Vea esta regla: add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \ max-limit=1024k name="Http down small" packet-mark=http_down_pkt parent=\ Recepcion priority=1 queue=default Actualmente yo utilizo el tipo Random Early Detection (RED) con unos valores personalizados y va bien para quienes tienen harta saturacin; Para los que no tienen ese problema usar Stochastic Fairness Queuing (SFQ) les ir mostro con la reparticn. Aunque nada mejor que una combinacin de estas dos x') Una segunda edicin de este hilo podra hablar de los tipos de cola que puede emplear, o quiz sea un post nuevo?, no lo defino an. Tambin la creacin de rfagas un tuto para encontrar los valores correctos. Espero les haya gustado. Cualquier acotacin o aclaracin, es bienvenida.