|
|
Método para la ecualización del ancho de banda
(64099 lectures)
Por Jose Luis Nogueira
scero
(http://www.scero.net)
Creado el 07/04/2003 21:02 modificado el 07/04/2003 21:02
|
En este artículo expongo un método con el cual podréis "ecualizar" el ancho de banda de vuestra conexión, gracias a las herramientas QoS. |
Pagina1/1 |
1. Introducción
Desde hace algún tiempo he estado intentado ecualizar el ancho de
banda de mi conexión, con el fin de poder garantizar que siempre se
dispone de un ancho de banda mínimo para un determinado servicio o
máquina de una red.
Para entender la utilidad de esto supongamos que tenemos una red como
la siguiente
es muy habitual encontrarse con el hecho de que el cliente 1
comienza a utilizar ancho de banda de forma masiva y continua (ftp,
p2p, etc...); de manera que si en un momento posterior el cliente
2 intenta utilizar la conexión para cosas más livianas (navegar),
este descubre que la conexión esta copada por el primero y todo el
acceso le va muy lento.
En este artículo pretendo explicar un método para poder evitar esta
u otras situaciones en las cuales el ancho de banda es utilizado de
una manera poco justa entre los usuarios (servicios) o como mínimo
de una manera no adecuada. Entre otras cosas pretendo explicar la
forma de conseguir lo siguiente:
- Asegurar que no haya en la red usuarios (o servicios) que utilizan
el ancho de banda ocasionando un acceso precario para los otros
- Establece prioridades entre las máquinas cliente de nuestra red (si
esto fuese necesario)
- Garantizar un ancho de banda mínimo para cada servicio o grupo de
servicios (ftp, telnet, ssh, www, etc ...)
No quiero que ninguno piense que este es el único método para poder
ecualizar un ancho de banda, esto sería un error. Lo único que pretendo
en este artículo es dar a conocer algunos de los servicios QoS (quality
of service) que están disponibles en el núcleo de Linux; estos servicios
se pueden utilizar de muchas formas y combinar entre ellos para solucionar
problemas muy complejos. En general el método que os voy a explicar
es muy potente y simple a la vez, de todos modos si alguno cree que
puede mejorarse de alguna manera, estoy abierto a todo tipo de sugerencias.
En este artículo parto de la base de que todos los lectores:
- Sabéis compilar el kernel de Linux
- Sabéis usar netfilter (iptables) de los kernels 2.4.x
- Tenéis conocimientos mínimos de administración de redes en Linux
2. Método utilizado para la ecualización
Este método se puede representar de manera gráfica de la siguiente
manera:
Aviso: este gráfico es una simplificación de la realidad, únicamente
pretende servir con fines didácticos; el proceso que realmente sigue
Linux es un poco más complejo e intervienen más factores. Como se
puede observar la idea es utilizar Netfilter para marcar los
paquetes según el tratamiento que se desee darles, cuando estos paquetes
lleguen al dispositivo de red por el que deben salir a internet (o
cualquier otra red) son tratados según un árbol de preferencias que
especifica el ancho de banda que le corresponde, la prioridad, etc...
En los siguiente puntos se encuentra una explicación detallada de
como implementar este método.
2.1. Compilación de Kernel
Lo primero que se debe hacer es habilitar todos los soportes a utilizar
en el Kernel.
Para poder emplear Netfilter, como mínimo:
Networking options -->
[*] Network packet filtering (replaces ipchains)
IP: Netfilter Configuration -->
<*> netfilter MARK match support
<*> Connection state match support
<*> Packet filtering
<*> Packet mangling
<*> MARK target support
Si adicionalmente se desea hacer Masquerading y demás historias
también se deberían activar sus correspondiente soportes.
Para poder usar los servicios QoS necesarios para este método
es necesario:
Networking options -->
QoS and/or fair queueing -->
[*] QoS and/or fair queueing
<*> HTB packet scheduler
<*> SFQ queue
<*> Ingress Qdisc
[*] QoS support
[*] Rate estimator
[*] Packet classifier API
<*> TC index classifier
<*> Routing table based classifier
<*> Firewall based classifier
[*] Traffic policing (needed for in/egress)
2.2. Creación de un árbol de preferencias para un dispositivo
Con árbol de preferencias de preferencias pretendo hacer referencia
(de forma informal) a una estructura de ``clases'' o ``bandas''
(según la traducción) en la que hay dependencias padre-hijo entre
sus miembros.
Para poder implementar esta estructura es necesario conocer los algoritmos
que voy a emplear en cada una de sus clases. Hay que tener en cuenta
que no son lo únicos que se pueden aplicar, existen otros con diferentes
características:
Algoritmo sfq (Stochastic Fairness Queueing)
Es una implementación sencilla de la familia de algoritmos de colas
justas (fair queueing).
En este algoritmo el tráfico se divide en un número bastante grande
de colas FIFO, una por cada conversación. Entonces se envía el tráfico
de una manera parecida a round robin, dando a cada sesión por turnos
la oportunidad de enviar datos.
Es decir es un algoritmo que busca una equidad entre todas las peticiones
para repartir de la manera más justa posible el ancho de banda.
Algoritmo htb (Hierarchical Token Bucket)
Es una algoritmo utilizado para dividir el ancho de banda según nos
interese de manera que se puede especificar un ancho de banda
mínimo y un ancho de banda máximo. De manera que el algoritmo
asegura la disponibilidad del mínimo, y en caso de que haya ancho
de banda libre se puede llegar hasta el máximo.
Existe otros algoritmos que hacen cosas similares, pero este es el
único (por lo que he probado) que permite pedir prestado ancho
de banda que no se use.
Reparto de los anchos de banda en el árbol de preferencias
Para crear el árbol cada uno puede aplicar los criterios que más le
convengan, en este apartado explicaré como hacerlo y daré un par de
ideas que pueden resultar interesantes.
Para los ejemplos que hay a continuación se supone:
- La conexión a internet (podría ser cualquier otra red) es de 300Kbps
- La conexión a internet se realiza por el interface eth1
- Interesa crear dos bandas de similar ancho de banda,
una se usará para navegar por la web y la otra para todos los demás
servicios
- La banda empleada para navegar por la web será prioritaria
frente a la otra
Para este caso tan sencillo, se puede representar el árbol de preferencias
como
para conseguir esto se puede proceder de la siguiente manera:
tc qdisc add dev eth1 root handle 1: htb default 20
Con esto se crea una banda principal (root) con el nombre 1:,
que por defecto manda todos los paquetes a la banda 20.
tc class add dev eth1 parent 1: classid 1:10 htb rate 100kbps
ceil 200kbps
Con esto se crea una banda que depende de la principal (parent
1:), tiene un ancho de banda mínimo de 100kbps (rate 100kbps)
y puede llegar a tener hasta 200kbps (ceil 200kbps). Como no se ha
indicado nada sobre la prioridad se supone que tiene prioridad máxima
(es decir 0). A esta banda se le llama 10 y depende de la 1 (1:10).
tc class add dev eth1 parent 1: classid 1:20 htb rate 100kbps
ceil 200kbps prio 1
Con esto se crea una banda de similares características a la anterior
con la salvedad de que tiene menor prioridad (prio 1) . Su
nombre es 20, al depender de la 1 se denomina (1:20). Esta
será la banda por defecto para los paquetes (default 20), como
se indico en el primer comando.
En este árbol cada una de las bandas tiene un ancho de 100kbps y puede
crecer hasta 200kbps. Es importante tener el cuenta que los comandos:
tc qdisc add dev eth1 root handle 1: htb default 20
tc class add dev eth1 parent 1: classid 1:10 htb rate 100kbps
ceil 300kbps
tc class add dev eth1 parent 1: classid 1:20 htb rate 100kbps
ceil 300kbps prio 1
En la práctica con estos comandos se genera un árbol de idénticas
características al anterior, pues si la conexión solo dispone de 300kbps
y 100kbps son asignados de forma fija para cada banda, solo quedan
100kbps sin ocupar que son los que pueden repartirse la banda 10 y
20.
En muchos casos este modelo es indeseable pues si solo se utiliza
una de las bandas, por ejemplo la 10 (para navegar) se está desaprovechando
mucha velocidad, pues como máximo se puede llegar a 200kbps en lugar
de los 300kbps, por lo que se está infrautilizando la conexión.
La solución a este problema es conseguir que las bandas se presten
velocidad si no lo usan, conseguir esto es muy sencillo ya que en
las colas htb siempre se comportan de este modo, con la salvedad
de que la banda root (1) no puede prestar ancho de banda a sus
hijas. Por tanto la solución se podría dar como:
tc qdisc add dev eth1 root handle 1: htb default 20
tc class add dev eth1 parent 1: classid 1:1 htb rate 300kbps
ceil 300kbps
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 100kbps
ceil 300kbps
tc class add dev eth1 parent 1:1 classid 1:20 htb rate 100kbps
ceil 300kbps prio 1
En este caso la banda root (1). Tiene una única hija la banda
(1:1) (que acapara todo el ancho de la conexión) la cual a
su vez tiene dos hijas (1:10) y (1:20), que tienen características
similares a las ya descritas en el caso anterior. En este caso la
banda 1:1 puede prestar su conexión a sus hijas, de modo que cada
hija tiene su ancho de banda mínimo 100kbps y puede llegar a tener
hasta 300kbps, si este no se usa por otra.
Gráficamente este segundo ejemplo se puede representar como
Como es evidente este es el ejemplo más sencillo que puede darse con
únicamente dos bandas, si fuese necesario se pueden crear tantas bandas
como sea necesario (1:30, 1:40, ...) según necesidades.
Combinación con colas sfq
Se puede ganar mucho en comportamiento si se combinan las clases htb
con clases sfq que se encarguen de repartir justamente las
peticiones que reciben, por ese motivo es muy recomendable combinar
los árboles htb con estas. Esto es tan sencillo como asignar
una cola de este tipo para cada banda final, esto se puede hacer de
este modo:
tc qdisc add dev eth1 parent 1:10 handle 10: sfq
tc qdisc add dev eth1 parent 1:20 handle 20: sfq
...
2.3. Marcado de paquetes (Netfilter)
Ahora se debe utilizar la herramienta iptables para marcar
los paquetes con valores; posteriormente los paquetes serán filtrados
según los valores con los que ahora se marquen. Para esto no existe
una receta ``mágica'' pues depende de lo que se desee en cada
caso.
Por ejemplo si se tiene una red con un servidor que da acceso a internet
y dos clientes (similar al primer gráfico que use en este artículo).
De manera que lo que interesa es dar un tratamiento diferente a los
paquetes que llegar de cada máquina, se pueden usar las siguientes
reglas:
iptables -A FORWARD -s 192.168.1.13 -t mangle -j MARK -set-mark
1
iptables -A FORWARD -s 192.168.1.18 -t mangle -j MARK -set-mark
2
iptables -A POSTROUTING -o eth1 -p tcp -dport 20:21 -t mangle
-j MARK -set-mark 3
De este modo los paquetes de la máquina con ip 192.168.1.13
son marcados con el valor 1, los paquetes de la máquina con
ip 192.168.1.18 con el valor 2 y los paquetes con destino
a un ftp con el valor 3.
2.4. Asociación de marcas con las bandas del árbol de preferencias
Para finalizar se debe asociar a cada marca una banda, para que de
este modo según interese se de un tratamiento o otro a cada paquete.
Esto se puede hacer con el comando:
tc filter add dev (dispositivo) protocol ip parent (clase_padre)
handle 1 fw classid (clase_destino)
Si interesase que todos los paquetes marcados con el valor 1 fuesen
a la banda 10, se podría usar algo similar a:
tc filter add dev eth1 protocol ip parent 1: handle 1 fw classid
1:10
3. Ejemplo completo
Supongamos que dada una red se desea separar las conexión a ftp del
resto de conexiones a internet, de manera que se de mucha más prioridad
a las conexiones ftp. En esta supuesta red, el servidor (donde se
implementará el sistema QoS) da servicio de conexión a toda
la red por masquerading (sobre iptables). El supuesto servidor se
comunica por el dispositivo eth0 con la red local y con eth1
con internet, la velocidad de conexión es de 512kbps.
Para conseguir lo deseado se podría, por ejemplo, escribir los siguientes
comandos:
# Creación del árbol de bandas
tc qdisc add dev eth1 root handle 1: htb default 20 # Por defecto
toda la información irá a la banda 20
tc class add dev eth1 parent 1: classid 1:1 htb rate 512kbps
ceil 512kbps
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 300kbps
ceil 512kbps
tc class add dev eth1 parent 1:1 classid 1:20 htb rate 200kbps
ceil 512kbps prio 1 # Esta banda tiene menor prioridad y menor ancho
de banda mínimo
# Asociación de colas sfq con bandas
tc qdisc add dev eth1 parent 1:10 handle 10: sfq
tc qdisc add dev eth1 parent 1:20 handle 20: sfq
# Se asocia la marca 1 con la banda 10
tc filter add dev eth1 protocol ip parent 1: handle 1 fw classid
1:10
# Reglas de filtrado (se marca con un 1 a todos los paquetes
destinados a un ftp)
iptables -A FORWARD -i eth0 -o eth1 -p tcp -dport 20:21 -t
mangle -j MARK -set-mark 1 # Se marca con 1 todos los paquetes con
destino a un ftp
4. Herramientas de verificación
Para controlar que el sistema se comporta de forma correcta se pueden
usar dos comandos, el primero muestra el comportamiento de la banda
root (1:) y las bandas sfq. Este comando es:
tc -s qdisc ls dev ethx
Hay que substituir la x por el valor del dispositivo a mirar.
Si se desea controlar el comportamiento de htb es necesario
usar:
tc -s -d class show dev ethx
Hay que substituir la x por el valor del dispositivo a mirar.
Al controlar los htb es interesante sobre todo controlar los
campos lended y borrowed; pues muestran el comportamiento
de préstamos de ancho de banda.
Espero que os sirva de utilidad y lo disfrutéis. Si encontrais algún error en el documento agradecería que me lo comunicaseis. Gracias. |
|
|
|
|
|
|---|
Comentarios
Es posible que se hayan omitido algunos comentarios considerados poco constructivos
| 1. Re: Método para la ecualización del ancho de banda (07/04/2003 22:56, #13456)
Por: r00z |
Muy interesante el tema y muy bien explicado.
Yo también estoy haciendo mis pruebas modificando un script parecido llamado wondershaper (http://lartc.org/wondershaper/). En la parte de la configuración donde se especifica el ancho de banda de subida y bajada recomienda poner los valores "algo" más bajos que los reales para evitar que se cree la cola en el router ADSL y no en la própia máquina. Alguien sabe si hay algun método para saber si los paquetes se ponen en la cola de la máquina o si pasan directamente? Es para dejar estos valores al máximo posible (que no es plan de desperdiciar unos bytes que pago religiosamente cada mes a precio de oro)
No sé si me he explicado bien pero bueno. | No es pot respondre
|
2. Re: Método para la ecualización del ancho de banda (07/04/2003 23:59, #13461)
Por: scero (http://scero.homelinux.org:8080) |
Te has explicado perfectamente ;)
No puedo asegurarte nada sobre el tema, principalmente porque no uso ADSL (uso ONO). Ya habia leido cosas al respecto de lo que comentas, pero por las pruebas que he podido hacer no he notado la necesidad de reservar ese pequeño espacio, a pesar de que suelo tener la conexión muy saturada, tanto para subida como para bajada.
| No es pot respondre
|
3. Re: Método para la ecualización del ancho de banda (08/04/2003 20:52, #13491)
Por: Kiko |
Respecto del ancho de banda de subida, si puedes averiguarlo, porque cuando la cosa está congestionada, las colas se forman en el router y lo que interesa es que se formen en el linux para poder "aplicarle la prioridad que te interese". Lo que has de hacer es acceder al router y averiguar como estan las colas tcp (en un linux lo harías con un netstat -an, en el router..., pues dependerá del router).
Respecto del ancho de banda de bajada, éso es más complicado, porque en este caso las colas se forman en los enrutadores de tu ISP (y acceder a esa información ya es cosa más complicada...). En este caso lo que te interesa es que no se formen colas de paquetes tcp en ningun enrutador de tu isp de camino a tu casa para que la latencia no se vea afectada cuando el trafico de bajada es intenso. Perder un poquito de ancho de banda en este caso es inevitable (es el precio que hay que pagar por conservar la latencia).
Es un tema un poco complejo de explicar, en el readme del wonder shaper está bastante bien explicado. | No es pot respondre
|
|
4. Re: Método para la ecualización del ancho de banda (07/04/2003 23:05, #13457)
Por: Myth |
| un artículo collonut y que me va a ir de perlas. Gracias scero :) | No es pot respondre
|
5. Re: Método para la ecualización del ancho de banda (07/04/2003 23:50, #13458)
Por: Relay |
| Perfecto, solo un pequeño punto. Lee aqui:
Algoritmo htb (Hierarchical Token Bucket)
Es una algoritmo utilizado para dividir el ancho de banda según nos interese de manera que se puede especificar un ancho de banda mínimo y un ancho de banda máximo. De manera que el algoritmo asegura la disponibilidad del mínimo, y en caso de que haya ancho de banda libre se puede llegar hasta el mínimo. !!!! Se puede llegar al máximo no? eso he entendido. | No es pot respondre
|
|
|
7. Re: Método para la ecualización del ancho de banda (08/04/2003 01:18, #13463)
Por: Tzac |
Antes de nada felicitarte por el artículo, el tema es muy complejo y has conseguido realizar una introducción muy sencilla y atractiva.
Personalmente me he peleado con este tema ya hace algún tiempo y para un control satisfactorio de mi conexión me ví obligado a utilizar una interfaz IMQ, ya que sino no controlas el ancho de banda recibido, que es el que realmente te satura la conexión.
Realmente el problema que yo me he encontrado es algo que no he conseguido resolver y del que nadie ha sido capaz de darme una buena solución. El problema consiste en que puedo delimitar el tráfico que se consume a través del puerto http, pero me es imposible distinguir dentro de este el correspondiente a navegar y a las descargas a través de http. El resultado es que sigo igual, un usuario que pille un servidor desaprensivo me deja sin conexión para navegar en el resto de los puestos :(.
Pero bueno, solo lo comento porque me recordaste las noches sin dormir por culpa de los cbq, htb, tbq y compañía... un saludo de un gallego que alucina con el nivel y trabajo de estos mallorquines :) | No es pot respondre
|
8. Re: Método para la ecualización del ancho de banda (08/04/2003 05:52, #13469)
Por: r00z |
| Yo también hecho de menos una solución para esto. Habia pensado en clasificar las conexiones dinámicamente según el total de bytes consumidos dando prioridad a las conexiones que menos ancho de banda hayan consumido sin importar el puerto o protocolo. Así todas las conexiones gozarían de una prioridad alta al principio y las que consumiesen más ancho de banda poco a poco irían perdiendo esa prioridad. Lástima que no exista ninguna extensión que permita clasificar según el ancho de banda consumido. A ver si me decido un dia de estos y me pongo en serio con esto a ver si puedo sacar algo de provecho. | No es pot respondre
|
9. Re: contolar el ancho de banda del trafíco http (11/04/2003 22:17, #13571)
Por: murfy |
...El problema consiste en que puedo delimitar el tráfico que se consume a través del puerto http, pero me es imposible distinguir dentro de este el correspondiente a navegar y a las descargas a través de http...
Creo que con Squid se puede hacer esto. No lo he probado, pero aquí explica como hacerlo.
| No es pot respondre
|
10. Re: contolar el ancho de banda del trafíco http (19/02/2004 11:07, #19808)
Por: Rafa G. |
| Con SQUID puedes limitar la descarga de ficheros con las ACLs (pones las extensiones) y luego defines unas delay pools. Lo he montado y funciona muy bien :-) | No es pot respondre
|
|
|
11. Re: Método para la ecualización del ancho de banda (08/04/2003 09:35, #13470)
Por: djgera (http://www.vmlinuz.com.ar) |
Muy, muy buen articulo, sobre todo porque es más practico que teorico, (al grano), que es lo que se pregunta generalmente sobre este tema.
Gracias! | No es pot respondre
|
12. Re: Método para la ecualización del ancho de banda (08/04/2003 13:37, #13475)
Por: rafaexpo |
| Me parece muy, pero que muy bueno, estoy haciendo algunas pruebillas si me saltan dudas te comento.
Gracias por tu escrito | No es pot respondre
|
13. Re: Método para la ecualización del ancho de banda (08/04/2003 16:17, #13478)
Por: Solomons |
Que gusto ver como subis el nivel de Bulma con estos artículos, norawena ;-) Ya tengo ganas de hacer pruebas en la oficina para evitar que se quede frita la conexión por los downloads de ftp o cvs.
Ya que estoy, hay un detalle que no se si está mal escrito. En el apartado 2.2, sección Reparto de los anchos de banda en el árbol de preferencias, hay un párrafo que dice:
La solución a este problema es conseguir que las bandas se presten velocidad si no lo usan, conseguir esto es muy sencillo ya que en las colas sfq siempre se comportan de este modo [...]
Y sin embargo en todas las lineas del ejemplo inmediatamente posterior pone:
tc qdisc add dev eth1 root handle 1: htb default 20 [...]
¿Es eso correcto?
Por lo demás, collonut :-) Fíjate si tiene nivel el artículo que esta collonada es lo único que se me ocurre alegar O;-)
Au, un sasludo
Nota privada: ¿sigues filtrándome? He respondido tu "dedicatoria" esta tarde. | No es pot respondre
|
14. Re: Método para la ecualización del ancho de banda (08/04/2003 19:28, #13488)
Por: scero (http://scero.homelinux.org:8080) |
Totalmente correcto, en la frase me he colado de tipo de cola, lo siento. Lo corrijo en el artículo ahora mismo.
Supongo que estos algunos de fallos son probocados porque lo escribí inicialmente en Lyx/LaTeX y al pasarlo a html (cosa que hice medio a mano) me he colado en algunas cosillas.
Por cierto si alguien quiere completa el artículo con cualquier tipo de explicación o ampliación (colas p_fifo, bit TOS, ...) puede pedirme el original y se lo pasaré.
Muchas gracias por la anotación y saludos. | No es pot respondre
|
|
15. Re: Método para la ecualización del ancho de banda (08/04/2003 23:44, #13496)
Por: anónimo |
Primero enhorabuena por el articulo porque es excelente para una introduccion de nivel muy bueno. Querria hacerte una pregunta:
Quiero compartir una conexion ADSL entre 3 personas usando linux como router y un modem adsl. Quiero tener 3 clases hijas de la 1:1 de tu ejemplo (la inmediatamente siguiente de la root). Estas clases corresponden a tres IPs (los 3 amigos). Despues de cada una de las tres hojas "cliente", quiero que salgan otras tres (una para web, smtp y resto). Y de tal manera que cada uno tenga en total como minimo un 33.3% del ancho de banda si estan los tres conectados, y si solo hay dos por ejemplo, pues un 50% para cada uno.
Esto se supone q tiene q aplicarse a la interfaz q da al modem para el uplink. ¿Se podria hacer? ¿Podrias pastear algo rapidito ? se me da muy muy mal :(( :) Gracias por adelantado si alguien lo pastea :)
Y otra cosa. ¿Seria interesante aplicarle a la otra interfaz del router (a la q da a la red interna) colas HTB ? vamos, lo digo para q en bajada uno no chupe mas q otro ... o eso tambien se implementa en tu ejemplo?. Quiero decir, que lo que has explicado es para el uplink, pero para el downlink no has dicho nada. Yo puedo enviar como maximo 100k, pero recibir mas estando copando la del resto, no?
Muchas gracias por adelantado, y muchas gracias tb por tu articulo. | No es pot respondre
|
16. Re: Método para la ecualización del ancho de banda (09/04/2003 10:01, #13510)
Por: scero (http://scero.homelinux.org:8080) |
Antes de nada veo que tienes el mismo problema conceptual que yo me encontré: "separar las bajadas de las subidas". Este problema no es tal, pues si te fijas en los ejemplos del artículo, siempre se controla la banda por la que se envía la información pero no por cual te llega, y esto es porque por norma general siempre se baja más de los que se sube. Por tanto si una determinada información (por ejemplo de ftp) se pide por una banda de 100Kbps, la información de subida es despreciable, pero la de bajada nunca superará los 100Kbps. Con esto ya te libras de discernir entre upload y download, por otra parte si vas a usar mucha subida siempre puedes hacer bandas expecificas para ello, aunque esto solo es justificable si tienes un servidor (www, ftp, ...) que trabaja mucho.
Respecto al modelo que comentas que deseas aplicar no tendrás mucho problema en implementarlo siguiendo los pasos del artículo. Simplemente crea las tres colas htb dependientes de la 1:1 supongamos que se llaman 1:10, 1:20, y 1:30; ahora es realizar nuevamente el proceso pero tomando como padres estas, al estilo de:
tc class add dev ethX parent 1:10 classid 10:100 htb rate XXXkbps ceil XXXkbps
Espero que te sea útil, si no he entendido bien la pregunta o no te a quedado clara la respuesta no dudes en preguntar otra vez. | No es pot respondre
|
|
17. duda upload/download (09/04/2003 12:53, #13515)
Por: murfy |
Excelente el articulo. Yo implementé algo parecido con el script cbq-init .
Mi duda: Supongamos que tenemos una linea ADSL asimetrica (300Kb/s subida y 2Mb/s de bajada). Según entendi en el articulo lo que se limita con htb es la subida, es decir las peticiones de mis clientes a Internet. Es decir que para implementarlo en este caso tendria que definir que la velocidad de la conexión es de 300Kb/s y no de 2Mb/s. ¿Esto es asi?
Por otro lado tiene cierto sentido limitar unicamente la subida (las peticiones de los clientes), pues para que quiero limitar la bajada si los datos ya me han llegado a mi router/shaper linux? Una vez que los datos estan en el router para que leches van a esperar alli, pudiendo entregarselos al cliente, ¿es correcto esto? o por el contrario merece la pena limitar y repartir la bajada también?
Según me comentarón existen unos aparatitos packetshaper bastante eficientes que sirven para gestionar el ancho de banda. Me parece que lo que hacen es modificar el tamaño de la ventana de transmision de los paquetes. En vez de simplemente dejar el paquete en una cola hasta que pueda salir adecuan la velocidad de las conexiones tcp modificando el tamaño de la ventana de transmisión de los paquetes enviados. ¿Existe algo parecido en linux?
El articulo esta muy bien, quizas yo hubiera añadido algunos enlaces a modo de bibliografía:
http://www.roback.cc/howto/bandwidth.html
http://www.redes-linux.com/manuales/ancho_banda/Limitar-COMO.pdf
http://www.redes-linux.com/manuales/ancho_banda/traffic_shaper_bidireccional.pdf
http://www.docum.org/stef.coene/qos/docs/
etc ...
Un saludo!
| No es pot respondre
|
18. Re: duda upload/download (09/04/2003 17:11, #13519)
Por: El cobarde anónimo |
"Por otro lado tiene cierto sentido limitar unicamente la subida [..] o por el contrario merece la pena limitar y repartir la bajada también? "
Yo tengo la misma duda. Quiero decir, el articulo esta basado en shappear el trafico en la interfaz que da al modem, por lo que conformamos lo que sube, para asi repartir adecuadamente el ancho de banda de subida, y asi por ejemplo, el trafico ftp de subida no corte a una conexion ssh. hasta aqui correcto, ¿no? Bien, pero digo yo. Si la subida son 300kbits, y la bajada 2 Mbits, lo mas logico es que ESA conexion, por ejemplo, ssh, tambien tenga paquetes de bajada que pueden ser cortados por un download p2p masivo, asi que tambien digo yo que habra que hacer QoS de bajada. Pero claro, se supone que eso deberia estar implementado en el router del otro extremo (en este caso el Dslam de ADSL) al que NO tenemos acceso. Por tanto, en este caso concluyo que NO serviria de NADA conformar el trafico de bajada, pues no tenemos acceso al dslam.
Pero imaginar la siguiente situacion. Tenemos un enlace adsl asimetrico de 2 megas de bajada y 300k de subida y queremos repartirlo igualitariamente para 2 personas, TANTO de subida como de bajada, no? entonces en este caso, SI que habria que hacer conformado en la interfaz del router que da a la red interna para que ambos tengan como minimo 1 mb de bajada, y conformado en la interfaz que da al modem para tener como minimo los 150 kbits cada uno de subida ¿no? aqui esta mi duda, si serviria y si se podria hacer. Porque claro, de nada sirve solo conformar el trafico de subida y limtiar por ejemplo, el trafico p2p de subida, si luego el p2p de bajada te copa TODO (y jode por ejemplo al que este navegando por web). ¿Se podria encontrar alguna solucion? es que sigo sin comprender de que serviria solo conformar el de subida, si lo q jode es la bajada. Y escribiendo esto tampoco entiendo entonces la funcion de los aparatos packetkeeper en una empresa entre el router para internet y el switch troncal si suceden las mismas cosas.
Por otro lado, lo que comentas de modificar en tiempo real el tamaño de ventana TCP en funcion del ancho de banda es MUY interesante. A ver si alguno con conocimientos mas profundos puede darnos algo de luz sobre este tema. Y porque no, si encontramos solucion a ambos problemas que he expuesto, ampliar el turorial tan magnifico que ha hecho este integrante de bulma.
Espero q este hilo se alargue hasta encontrar la solucion!! :)
un saludo a todos | No es pot respondre
|
19. Re: duda upload/download (10/04/2003 00:48, #13530)
Por: r00z |
La idea de modificar el tamaño de la ventana parece bueno aunque también tiene sus inconvenientes (podeis mirar esta comparación poco imparcial, apartado TCP Rate Limiting).
Otro solución que aparece más o menos en el enlace anterior es la de crear varias colas con diferentes prioriades con la diferencia de meter los ACKs de los paquetes de cada cola en esa misma cola. Con esto simulamos una conexión lenta para las conexiones con poca prioridad y una conexión rápida para las de más prioridad. Mirando el código del wonder shaper he visto que se da prioridad máxima a todos los paquetes ACK por lo que todas las conexiones siempre enviarán los paquetes al máximo y se descartaran (una vez recibidos) en nuestra máquina si vemos que los recibimos demasiado rápido. Esto hace que con una conexión al límite los paquetes tienen que ser reenviados consumiendo más ancho de banda. No soy un experto en esto y no sé si sólo serviría para paquetes TCP (en UDP no hay ACKs verdad?). Tampoco sé cómo se podría relacionar un ACK con una conexión.
| No es pot respondre
|
20. Re: duda upload/download (10/04/2003 20:01, #13546)
Por: scero (http://scero.homelinux.org:8080) |
| Respecto a lo de las bandas de subida y bajada ya he comentado cosas antes. Por lo que he podido observar la velocidad de bajada se ajusta a las características de la "banda" (como las he llamado en el artículo) por la que se realiza la petición. De modo que si se realiza una petición por una "banda" de 100Kbps la velocidad de bajada de respuesta no superará los 100Kbps (salvo prestamos y demás historias). | No es pot respondre
|
21. Re: duda upload/download (11/04/2003 19:28, #13564)
Por: El cobarde anónimo |
A ver, segun tu, si una banda pone 100k como maximo para la subida, los datos de bajada que provengan de esa banda, tampoco superaran los 100k. Entonces, ¿Que es lo que ocurre con TODOS aquellos datos que superen esos 100kbits/sg? rechazados? si es asi, entonces quieres decir que como consecuencia de ser rechazados, es el propio TCP en el destino el que amolda su velocidad de tx hacia nuestro router (mecanismos que tienen TCP), no?
Es que si es asi, se me estaria produciendo una gran confusion, puesto q tengo en mis manos un tipo que ha hecho un script MUY bueno en el q usa el dispositivo imq para poder realizar ESO (lo de que en el otro extremo se reajuste la velocidad de tx mediante los algoritmos del propio TCP). Si quereis pasteo un fragmento de su explicacion:
Theory on using imq to "shape" inbound traffic:
It's impossible to directly limit the rate of data that will be sent to you by other hosts on the internet. In order to shape the inbound traffic rate, we have to rely on the congestion avoidance algorithms in TCP. Because of this, WE CAN ONLY ATTEMPT TO SHAPE INBOUND TRAFFIC ON TCP CONNECTIONS. This means that any traffic that is not tcp should be placed in the high-prio class, since dropping a non-tcp packet will most likely result in a retransmit which will do nothing but unnecessarily consume bandwidth.
We attempt to shape inbound TCP traffic by dropping tcp packets when they overflow the HTB queue which will only ss them on at a certain rate (RATEDN) which is slightly wer than the actual capability of the inbound device. By ropping TCP packets that are over-rate, we are simulating the same packets getting dropped due to a queue-overflow on our ISP's side. The advantage of this is that our ISP's queue will never fill because TCP will slow it's
transmission rate in response to the dropped packets in the assumption that it has filled the ISP's queue, when in reality it has not.
The advantage of using a priority-based queuing discipline is that we can specifically choose NOT to drop certain types of packets that we place in the higher priority buckets (ssh, telnet, etc). This is because packets will always be dequeued from the lowest priority class with the stipulation that packets will still be dequeued from every class fairly at a minimum rate (in this script, each bucket will deliver at least it's fair share of 1/7 of the bandwidth).
Reiterating main points:
* Dropping a tcp packet on a connection will lead to a slower rate of reception for that connection due to the congestion avoidance algorithm.
* We gain nothing from dropping non-TCP packets. In fact, if they were important they would probably be retransmitted anyways so we want to try to never drop these packets. This means that saturated TCP connections will not negatively effect protocols that don't have a built-in retransmit like TCP.
* Slowing down incoming TCP connections such that the total inbound rate is less than the true capability of the device (ADSL/Cable Modem) SHOULD result in little to no packets being queued on the ISP's side (DSLAM, cable concentrator, etc). Since these ISP queues have been observed to queue 4 seconds of data at 1500Kbps or 6 megabits of data, having no packets queued there will mean lower latency.
Caveats (questions posed before testing):
* Will limiting inbound traffic in this fashion result in poor bulk TCP performance?
- Preliminary answer is no! Seems that by prioritizing ACK packets (small | No es pot respondre
|
22. Re: duda upload/download (11/04/2003 20:10, #13566)
Por: scero (http://scero.homelinux.org:8080) |
es el propio TCP en el destino el que amolda su velocidad de tx hacia nuestro router (mecanismos que tienen TCP), no?
Si miras algo de teoría de redes veras que existen varios sistemas para negociar la velocidad en cualquier conexión de cualquier protocolo. Concretamente en el caso que planteas del TCP no es una excepción, en toda conexión siempre se negocia (aunque sea forzando un sistema de descarte) una velocidad.
De todos modos la cosa es bien simple, _pruebalo_. Monta dos bandas sobre la root (para evitar que se presten ancho de banda), filtra todos los paquetes de un protocolo (por ejemplo ftp) hacia una de ellas y verás como la velocidad de recepción de los datos no supera la velocidad de esa banda. Si lo haces solucionarás tus dudas de una manera irrefutable, con unas pocas lineas lo tienes montado. Ya me contarás como te ha ido. | No es pot respondre
|
23. Re: duda upload/download (11/04/2003 22:59, #13572)
Por: El cobarde anónimo |
Si no te llevo la contraria :-). Ahora mismo estoy haciendo el script para hacer la prueba, aunque con lo que tu me digas me vale. Lo que me es raro es porque la gente en internet levanta scripts un tanto complicados (el tema de imq es principalmente para poder gestionar varios enlaces wan como uno solo y poder balancear la carga modelandola como una sola) para poder hacer el shapping de bajada, bien implementandolo como arriba esta descrito, o bien haciendolo en la otra interfaz (la que da a la red interna). ¿Me podrias decir donde has encontrado la información que tu posees sobre la limitacion que se produce en la bajada usando las colas para el uplink? ¿ o es empirico ?
A lo mejor HTB ya de por si implementa esas restricciones de bajada haciendo uso del auto-reajuste de velocidades del TCP. quien sabe ...
También he leido en otros sitios (manual de LARTC) que el QoS en el caso nuestro ( modem/router ADSL) solo se puede implementar en el trafico de outbound, ya que para el inbound seria necesario practicarselo al router del otro extremo (DSlam en este caso) manipulando SU outbound (el del dslam que va hacia nuestro router).
Con esto repito que te hago caso a tu consejo. Simplemente pasteo temas que se ve de manera muy recurrente en listas de correo y manuales, y q por lo visto, está equivocado. | No es pot respondre
|
24. Re: duda upload/download (12/04/2003 15:16, #13584)
Por: scero (http://scero.homelinux.org:8080) |
> Si no te llevo la contraria :-)
No me considero ningún experto en redes, simplemente es un tema que me gusta, por tanto puedes llevarme toda la contraria si estoy equivocado ;)
La afirmación la he hecho basandome únicamente en mi experiencia y las las pruebas que he hecho con este tipo de colas.
La verdad es que no me he leido la documentación de sobre como está implementado el algoritmo htb (falta de tiempo :( ), y por tanto no puedo con certeza explicar como se implementa esta acción; de todos modos si quieres información detallada este algoritmo tiene su propia homepage en internet esta .
Si tienes tiempo y te documentas sobre el tema ya nos contarás que has descubierto, desde luego parece un tema muy interesante.
| No es pot respondre
|
25. Re: duda upload/download (11/04/2003 23:17, #13575)
Por: un escritor |
| Una duda. Si una clase, de por si, limita la velocidad de subida por ejemplo, en 100k, tambien lo hará con el de bajada (como acabas de decir) .. que ocurre con las conexiones asimetricas? si la subida son 512kbis y la bajada 2 Mbits/sg, y definimos tres clases de 512/3, se supone que en bajada, no se superaran los 512/3 por clase. Y la pregunta es ¿Que ocurre con el ancho de banda sobrante de los 2 Mbits? ¿se pierden? y si me contestas que lo coge el que mayor prioridad tenga, si estan conectados los tres, me quieres decir que en subida no se podria repartir nada sobrante porque no habria, pero en bajada si, ¿bien?
un saludo y enhorabuena por tu articulo | No es pot respondre
|
|
|
|
26. Re: Método para la ecualización del ancho de banda (09/04/2003 17:22, #13520)
Por: El cobarde anónimo |
Primero enhorabuena por tu articulo. Es MUY bueno. Escribo para la siguiente duda. Expones que el " camino" que siguen los paquetes IP en un router Linux conectado al modem ADSL seria el siguiente:
paquetes de datos --> Netfilter (opcion mangle) obteniendo paquetes marcados --> interfaz ethx que da al modem --> conformado de trafico HTB haciendo uso tb de las marcas hechas anteriormente --> internet
Bien, mi pregunta es la siguiente: si yo coloco un script tb en el router linux que haga de Firewall y NAT para los de la red interna ¿en donde se colocan ambas cosas en el camino descrito antes? interfereria hacer un script haciendo estas funciones en el transcurso del script HTB ?
Muchas gracias | No es pot respondre
|
27. Re: Método para la ecualización del ancho de banda (09/04/2003 17:25, #13521)
Por: El cobarde anónimo |
Primero enhorabuena por tu articulo. Es MUY bueno. Escribo para la siguiente duda. Expones que el " camino" que siguen los paquetes IP en un router Linux conectado al modem ADSL seria el siguiente:
paquetes de datos --> Netfilter (opcion mangle) obteniendo paquetes marcados --> interfaz ethx que da al modem --> conformado de trafico HTB haciendo uso tb de las marcas hechas anteriormente --> internet
Bien, mi pregunta es la siguiente: si yo coloco un script tb en el router linux que haga de Firewall y NAT para los de la red interna ¿en donde se colocan ambas cosas en el camino descrito antes? interfereria hacer un script haciendo estas funciones en el transcurso del script HTB ?
Y el camino a la inversa como seria tb? paquete q entra desde el modem al router y hay que deshacer lo hecho anteriormente.
Muchas gracias | No es pot respondre
|
28. Re: Método para la ecualización del ancho de banda (16/04/2003 00:26, #13652)
Por: PiotR (http://barrapunto.com) |
| http://lartc.org/ | No es pot respondre
|
29. Re: Método para la ecualización del ancho de banda (11/05/2003 22:03, #14324)
Por: Edgar (http://mxrisc.dnsq.org) |
| en el manejo de las cadenas con iptables el especificas el puerto de destino haces "-dport" lo correcto seria "--dport"
y para marcar el paquete haces "-set-mark" y nuevamente lo corrector seria "--set-mark", es algo que por sentido comun el lector deveria corregir pero no caeria mal corregirlo.
Saludos. | No es pot respondre
|
|
30. Re: Método para la ecualización del ancho de banda (02/06/2003 18:55, #14866)
Por: Enrique Porta |
| Hola a todos.
Queria hacer la siguiente pregunta. ¿Como puedo eliminar un arbol de preferencias, para que no exista ningun tipo de restricciones?
Gracias. | No es pot respondre
|
31. Re: Método para la ecualización del ancho de banda (10/07/2003 05:12, #15791)
Por: Edgar (http://mxrisc.dnsq.org) |
| si necesitan mas informacion sobre el tema esta este sitio en español.
http://midgard.heimy.org/~javi/asgard/lartc/index.html | No es pot respondre
|
32. RE: Método para la ecualización del ancho de banda (30/07/2003 17:26, #16159)
Por: Snachez Guillermo |
| hola a todos, estuve leyendo toda la doc que pude encontrar en cuento a "controlar" el ancho de banda. y logré hacer un script, basado en el del articulo, pero del cual solo me funciona el control saliente, cabe aclarar, que estoy aplicando los controles sobre la eth0 que está conectada a la red local, no a internet que está conectada a otra placa. Quiero lograr controlar también el tráfico entrante por esa interfaz, y en base a lo que he leido, opte por IMQ. El cual "aparentemente" esta funcionando bien. Digo esto, porque en el resumen que solicito al iptables. marca los paquetes entrantes de manera correcta, los filtros estan cargados correctamente y las marcas concuerdan, y las qdisc tambien. Pero ninguna de las colas está contabilizando paquetes, cuando solicito la info me devuelven:
class htb 2:12 parent 2:1 prio 0 rate 256Kbit ceil 256Kbit burst 1926b cburst 1926b
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 48174 ctokens: 48174
Por favor, necesito una mano.
desde ya muchas gracias !!! | No es pot respondre
|
33. RE: Método para la ecualización del ancho de banda (05/10/2004 21:37, #23697)
Por: Anónimo |
| Hola estoy interesado en como controlar el AB en linux, y soy nuevo me ayudan con un script en el cual limite AB por ip , osea los que se encuentren dentro de una red. tanto de bajada como de subida | No es pot respondre
|
|
34. Exelente... y Ayuda (12/08/2003 17:43, #16377)
Por: Juan Saransig |
| Es un tema interesante, y del cual necesitamos toda la ayuda (Documentacion Algoritmos Detallados) gracias...
Espero su respuesta lo mas pronto | No es pot respondre
|
35. Re: Exelente... y Ayuda (01/09/2003 21:20, #16849)
Por: scero (http://scero.homelinux.org:8080) |
Si lees los comentarios del artículo, encontrarás algunos enlaces de interes, donde podrás encontrar información sobre el tema. No esperaras que la copie y la pege aquí, ¿verdad?
Respecto a lo de los algoritmos, lo tienes mucho más fácil, mira el código fuente de tu kernel. | No es pot respondre
|
|
36. Ayuda (14/08/2003 22:24, #16432)
Por: Juan Saransig |
| Necestito ayuda con mas teoria y detalles de este articulo gracias | No es pot respondre
|
37. Re: Método para la ecualización del ancho de banda (27/09/2003 15:42, #17263)
Por: Ricardo A. |
| Este sitio es un oasis y los felicito... He estado recompilando el kernel 2.4.21 de un Debian Woody, e instalé builtin todos los módulos necesarios, según el artículo, para correr el QoS y está todo OK. Es decir, veo los módulos instalados, no hubo problemas de compilación, funciona todo bien el pinguino...
Pero cuando ejecuto el comando "tc" para definir la primera banda, ahí me quedo, porque el bash me tira: "tc: command not found"... y no logro salir de allí, porque tampoco funciona con /sbin/tc ni encuentro el "tc" en ningún directorio... o sea, parece que el tc no se ha instalado por alguna razón... Alguna idea??? Si es urgente mejor porque estaba necesitando esto para mi trabajo y ahora me veo empantanado...
Gracias por adelantado,
Ricardo A.
Buenos Aires | No es pot respondre
|
38. Re: Método para la ecualización del ancho de banda (28/09/2003 20:54, #17286)
Por: scero (http://scero.homelinux.org:8080) |
Por lo que me explicas en el artículo, el problema que tienes no es de kernel sino de paquetes. Es necesario que instales el paquete que contiene el programa "tc", el nombre de este paquete para debian es "iproute".
Un saludo. | No es pot respondre
|
|
39. Re: Método para la ecualización del ancho de banda (19/11/2003 09:45, #18152)
Por: wless |
Estupendo artículo junto con el del Wonder Shaper.
Os pego un pequeño scrip que prepare para dibidir el ancho de banda de mi lan, espero que os sirva de ayuda y aportar mi granito de arena.
Si pensais que hay algo mal no dudeis en postearlo, a mi me funciona, pero soy nuevo en esto del linux y vete tu a saber...
Espero no molestar con un post tan largo
*Use la banda 2: para no interferir con el Wonder Shaper
#!/bin/bash
#minilancontrol
#scrip para la gestion del ancho de banda en una minilan(256/128) por wless
DEV=eth1
RATEUP=80
case "$1" in
start)
#creaciuon del arbol de bandas
tc qdisc add dev $DEV root handle 2: htb default 60
tc class add dev $DEV parent 2: classid 2:1 htb rate 120kbps ceil ${RATEUP}kbps
tc class add dev $DEV parent 2:5 classid 2:50 htb rate $[50*$RATEUP/100]kbps ceil ${RATEUP}kbps
tc class add dev $DEV parent 2:6 classid 2:60 htb rate $[50*$RATEUP/100]kbps ceil ${RATEUP}kbps prio 1
#tc class add dev $DEV parent 2:7 classid 2:70 htb rate $[4*$RATEUP/100]kbps ceil ${RATEUP}kbps prio 2
#asociacion de colas sfq con bandas
tc qdisc add dev $DEV parent 2:50 handle 50: sfq
tc qdisc add dev $DEV parent 2:60 handle 60: sfq
#tc qdisc add dev $DEV parent 3:70 handle 70: sfq
#se asocian marcas con bandas
tc filter add dev $DEV protocol ip parent 2: handle 5 fw classid 2:50
tc filter add dev $DEV protocol ip parent 2: handle 6 fw classid 2:60
#tc filter add dev $DEV protocol ip parent 3: handle 7 fw classid 3:70
#reglas de filtrado
iptables -A FORWARD -s 192.168.1.3 -i $DEV -t mangle -j MARK --set-mark 5
iptables -A FORWARD -s 192.168.1.2 -i $DEV -t mangle -j MARK --set-mark 6
#iptables -A FORWARD -s 192.168.1.0/24 -i $DEV -t mangle -j MARK --set-mark 7
echo "MiniLanControl started"
;;
stop)
# borro la reglas de filtrado
iptables -t mangle -F FORWARD 2> /dev/null > /dev/null
iptables -t mangle -X FORWARD 2> /dev/null > /dev/null
# borro las bandas
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
echo "MiniLanControl stoped"
;;
restart)
$0 stop
$0 start
;;
status)
# muestro datos interesantes
echo "[qdisc]"
tc -s qdisc show dev $DEV
echo "[class]"
tc -s class show dev $DEV
echo "[filter]"
tc -s filter show dev $DEV
echo " "
echo "[iptables]"
iptables -t mangle -L FORWARD -xnv
exit
;;
*)
echo "Use: $0 {start|stop|restart|status}"
;;
esac
#fin
| No es pot respondre
|
40. Re: Método para la ecualización del ancho de banda (19/12/2003 11:20, #18706)
Por: Anónimo |
| muy bueno, pero... hay algún entorno gráfico para configurar todo esto de forma cómoda?
no sé... un GUI o frontend que modifique el script....
esque el tema linux no lo domino nada que digamos. :D | No es pot respondre
|
41. Re: Método para la ecualización del ancho de banda (04/02/2004 21:24, #19608)
Por: Anónimo |
| Vale, yo tengo una duda... Si a demás de todo esto, en vez de una salida, disponemos de dos... ¿hay alguna manera a demás de balancear dicha salida?... Es decir, para evitar que una de las conexiones de salida se sature, que automáticamente enrute hacia la otra... más que alta disponibilidad, lo que me gustaría seria optimizar las conexiones de los clientes de la red local... ¿es posible?...
A demás, para agrabarlo aún más, los proveedores de las distintas salidas son diferentes... :S
Gracias... | No es pot respondre
|
42. Re: Método para la ecualización del ancho de banda (22/08/2005 17:38, #27978)
Por: velkro |
se puede hacer y es muy facil.
leete 'Linux Advanced Routing & Traffic Control', mas especificamente: 4.2.2. Load balancing.
http://lartc.org/howto/lartc.rpdb.multiple-links.html
saludos, velkro. | No es pot respondre
|
|
43. Re: Método para la ecualización del ancho de banda (20/02/2004 02:35, #19821)
Por: Anònim |
| Muy bueno el articulo, corto pero bueno.
Con respecto a un comentario de un gallego por ahi arriba
responde otro gallego. :) Creo que es lo que buscas pero no estoy muy seguro.
Existe layer7 QoS, no viene en el nucleo y hay que parchear
kernel y varias utilidades, no recuerdo la pagina ahora mismo
pero si pones en google layer7 Qos te saldra, o layer7+qos+ howto.
¿Y que haze esto?
Pues lo lei por encima pero permite crear reglas QoS para
servicios en los que el numero del puerto es aleatorio.
Tambien util para redes en que los emules y derivados
cambian extrañamente de puerto. :P Todo ello basandose
en unas reglas que incluyen aparte. Ideal para filtrar
el ancho de la navegacion ya que de otra forma es imposible
por el uso de diferentes puertos.
Para dejarlo claro imaginaos que creais una regla para el
emule y claro si el tio cambia de puerto ya estamos jodidos... pues con esto no importa el puerto el que estee
por que lo filtrara adecuademente.
Para el tema de navegacion la regla interna es sencilla
todo los paquetes que vengan con tags html pues los filtra
como le indiques y asi hay ya predeterminadas para muchas
cosas.
Lastima que no estee dentro del nucleo y haya que andar
ha parchear todo cada vez que se actualize. :( | No es pot respondre
|
44. Re: Método para la ecualización del ancho de banda (23/03/2004 17:51, #20277)
Por: Javier |
| Hola
muy bueno el articulo, pero tengo un problema, cuando pongo la ultima linea:
iptables -A POSTROUTING -o eth1 -p tcp -dport 20:21 -t mangle -j MARK -set-mark 3
Bad argument `20:21'
Try `iptables -h' or 'iptables --help' for more information.
me tira esos errores, si alguien tiene idea de lo que esta pasando se los agradesc.
mi idea es poder limitar ciertos puertos y dejar libres unos pocos, ya que la red tiene muchas pcs conectadas y a todas les tengo que garantizar un par de servicios.
gracias
javier ramirez
jramirez@bit2net.com | No es pot respondre
|
45. Re: Método para la ecualización del ancho de banda (02/06/2004 12:33, #21660)
Por: LZ |
| El problema esta en --dport, son dos guiones en lugar de uno, para el caso general si es una letra es un guion y si son varias letras (palabra) son dos guiones. | No es pot respondre
|
|
|
46. Re: Método para la ecualización del ancho de banda (24/03/2004 18:16, #20305)
Por: Anònim |
| te tengo un par de preguntas
yo tengo en una pc una coneccion directa,
de ahi va a 30 pcs mas, y yo tengo que garantizarle
algunos servicios nuestros, en puertos que van entre
el 20000 y el 25000 ojo, en el momento de limitar,
yo conosco esos puertos, pero mas o menos andan
por ese orden el tema es que necesito bloquear, o
limitar todo lo demas a como mucho 100kbits y poder
asignarle, por ejemplo 200kbit al puerto 22333 y
200kbit al 22444. ya recompile el kernel, pero no
logro hacer que me limite, trabaja como si no hubiese
puesto nada....me podes dar una mano ?
te lo voy a agradecer
mucho
Saludos
Javier | No es pot respondre
|
47. Re: Método para la ecualización del ancho de banda (08/04/2004 16:25, #20574)
Por: Marcelo |
| Hola el imforma esta muy bueno y es el problema que me esta ocurriendo en la oficina pero megustaria si hay algo para windows ? | No es pot respondre
|
48. Re: Método para la ecualización del ancho de banda (02/06/2004 12:30, #21659)
Por: LZ |
| Intento montar esto del QoS pero me da problemas con los algoritmos de division del ancho de banda, el htb, en concreto, con la primera linea que aparece en el articulo responde con un error que dice asi:
Unknown qdisc "htb", hence option "default" is unparsable
Y no se a que se debe, los paquetes han sido instalados y el kernel compilado, he repasado esto varias veces. He leido todos los comentarios del articulo y no veo a nadie que le pase parecido. En fin, si alguien me puede orientar se lo agradeceria mucho.
Saludos. | No es pot respondre
|
49. Re: Método para la ecualización del ancho de banda (10/06/2004 10:20, #21838)
Por: montal |
El error que a mi me da es el siguiente:
root@dewify:/usr/src# tc qdisc add dev eth0 root handle 1: htb default 20
RTNETLINK answers: Invalid argument
y tengo configurado en el nucleo CONFIG_IP_MULTIPLE_TABLES
¿alguna ayuda?, gracias | No es pot respondre
|
50. Re: Método para la ecualización del ancho de banda (23/06/2004 16:48, #22039)
Por: Edwin Valencia |
| Holas...
Pues buscando en la Red encontre que ambos problemas se deben a que el kernel de redhat 2.4.20 si tiene soporte para HTB pero el paquete iproute2 NO. Asi que toca que bajarce el codigo fuente y parcharlo para que tenga soporte para esta.
el link de donde podes obtener mas info:
http://breu.bulma.net/?l3297
Saludos... | No es pot respondre
|
|
|
51. Re: Método para la ecualización del ancho de banda (07/07/2004 02:35, #22261)
Por: orzoways (http://www.redaerea.com) |
Un poco de Help,please.
Pues estoy intentando implementar esto ya que me vendria de perillas , pero me encuentro con el siguiente error.Tengo creado el metodo del ejemplo completo(3), que me viene de lujo pues tengfo una adsl 512, sin modificar nada y me da este error:
llegal "rate"
Usage: ... qdisc add ... htb [default N] [r2q N]
default minor id of class to which unclassified packets are sent {0}
r2q DRR quantums are computed as rate in Bps/r2q {10}
debug string of 16 numbers each 0-3 {0}
... class add ... htb rate R1 burst B1 [prio P] [slot S] [pslot PS]
[ceil R2] [cburst B2] [mtu MTU] [quantum Q]
rate rate allocated to this class (class can still borrow)
burst max bytes burst which can be accumulated during
idle period {computed}
ceil definite upper class rate (no borrows) {rate}
cburst burst but for ceil {computed}
mtu max packet size we create rate map for {1600}
prio priority of leaf; lower are served first {0}
quantum how much bytes to serve from leaf at once {use r2q}
TC HTB version 3.3
????
alguien me peude dar idea de lo k me esta pasando??.
Tambien de dice k tengo un error en la instrucion de la marca de paquetes ya k cambio el 20:21 por el 80:81 y me dice k bad argument `80:81' ???
No lo entiendo ya que e mirado la regla del iptable de marcado de paquetes y esta bien,en fin ya me tiene loco.Lo unico k esto intentando hacier es dar prioridad a la gente de mi red que van a ver paginas web sobre todo lo demas.
Un salu2 | No es pot respondre
|
52. duda (09/09/2004 13:10, #23221)
Por: perdido |
muy buenas!
tengo un problemilla y espero que alguien me pueda ayudar... la cosa es que estoy intentando hacer funcionar el cbq-init (un script que hace algo parecido a lo que aquí se describe) y no lo logro. tengo un debian woody 3.0 con el kernel 2.4 y todos los modulos de QoS añadidos y el paquete iproute instalado. el caso es que todas las llamadas al tc me dan error:
- Invalid argument o
- No such file or directory
Creo que es porque los comandos tc generados por el script no se ajustan a la especificacion que aparece en el man. he intentado buscar otra version del paquete iproute que pudiese contener otro tc y encontre el "iproute_20010824-8woody1_i386.deb" que tenia buena pinta pero hace lo mismo...
alguien ha hecho funcionar este script en estas condiciones? bueno, espero haberme explicado bien. muchas gracias por la ayuda que me podais dar. | No es pot respondre
|
53. Re: Método para la ecualización del ancho de banda (24/09/2004 17:41, #23403)
Por: Itnash |
| Articulo muy interesante...felicidades!
Para rizar el rizo, me gustaría plantear una duda para el caso en que tengamos una ADSL. La cuestión es que por contrato el ISP te garantiza un 10% del BW total. Con esta falta de precisión del BW disponible, cómo és posible asegurar un ancho de banda para diferentes tipos de tráfico? por ejemplo si tenemos el tráfico FTP limitado a 100kb y el tráfico HTTP a 100kb también, si el BW que nos ofrece en ese instante el ISP són 50 míseros kb ( >10% de una ADSL 256kb), que sucede con las colas? hay algún metodo/sw de monitorizar el BW total disponible, de forma que pudieras adaptar las colas a él?
Gracias! | No es pot respondre
|
54. Re: Método para la ecualización del ancho de banda (15/10/2004 16:01, #23836)
Por: Peto |
| Muy buen articulo, aunque tengo un problea:
hice el mismo arbol que tu cambiando cuanto queria de ancjho de banda, pero si veo las herramientas *tc -s *d ... aparece como si los paquetes estuvieran yendo hacia 1:10, :20, etc.
La cuestion es que desde uno de las maquinas que manda paquetes al 1:20 que tiene como maximo 200Kbps hago un cheuqeo de cuanto es lo que esta saliendo y me aparece 815!!!!, obviamente el ancho de banda total es 1Mb, no se que puedo estar errando, se agradeceria una ayudita!!! :)
Saudos desde Uruguay,
Peto | No es pot respondre
|
55. Re: Método para la ecualización del ancho de banda (16/10/2004 02:23, #23841)
Por: pancho |
| exelenete me ha sido muy util ya que estaba tratando este tema y no lo encontraba tan claro como aqui saludos
Fernando | No es pot respondre
|
56. Re: Método para la ecualización del ancho de banda (28/12/2004 22:46, #24815)
Por: fequay (http://guliv.cl) |
| hoola he estado tratando de hacer funcionar el ejemp´lo aqui puesto...
he tenido algun error en el script donde tengo mi reglas de iptables al reiniciarlo....
RTNETLINK answers: File exists
quien me pueda echar una manito...acerca de este error...
desde ya gracias.. | No es pot respondre
|
57. Re: Método para la ecualización del ancho de banda (12/03/2005 04:37, #25641)
Por: Maurolx |
| Para la gente que se encuentra con el siguiente error "RTNETLINK answers: File exists ".Esto se da por que estan queriendo ingresar una banda ya ingresada.Deben borrar todo ,con el siguiente comando "tc qdisc del dev ethX root",donde X es la interfaz. | No es pot respondre
|
58. Re: Método para la ecualización del ancho de banda (18/08/2005 23:09, #27927)
Por: fequay (http://www.guliv.cl) |
| Ahora que se cual es el error, RTNETLINK answers: File exists, donde lo pones al principio.
1.- antes de las clases nietas
2.- antes de la clase hija
3.- o antes de la clase padre
4.- o antes de la clase abuelo la principal..
Esa es mi duda. ya que al poner tc qdisc del dev ethX root entre algunas me sigue dando el error | No es pot respondre
|
|
|
59. Re: Método para la ecualización del ancho de banda (16/06/2005 17:59, #27146)
Por: Leonardo |
| INGREIBLE!!! EXPLICACION !!!
Esta muy bien y los resultados son buenisimos! estaba buscando como hacer una sola cosa mas ...
Ok yo tengo un ISP con X cantidad de repetidroas con X cantidad de clientes para poder marcar cada paquete tendria que hacer un super iptables super enorme lo cual me mataria la memoria RAM.
pero creo que podria hacerce si tuviera iptables manera de decirle
iptables -A fwilimitadobackbone -s "el ip del cliente" -d "archivo donde estan las rutas de mi backbone nacional" -t mangale -j MARK -set-mark 2
Por que sino seria un iptables extremadamente grande para decirle cada ruta del backbone que tiene que pasar ilimitado y despues decirle que lo demas es limitado a x cantidad de kb dependiendo el personaje que se conecta...
bueno si alguien tiene una idea sobre esto le voy a agradecer que me responda con copia a mi correo que esta ahi arriba ! GRACIAS!!! | No es pot respondre
|
60. Comprobar configuracion (11/12/2005 20:15, #29962)
Por: Sorian |
Esto que he hecho esta bien?:
ESTA ES MI SITUACION:
servidor eth0--> Internet eth1--> Red local
ip 192.168.1.1 minimo 2000 maximo 3766
ip's 192.168.1.2 - 192.168.1.4 minimo 300 y si sobra hasta 1766
ip 192.168.1.5 minimo 25 maximo 30
ESTE ES EL SCRIPT QUE HE CREADO:
#!/bin/bash
#Creo el arbol de bandas
tc qdisc add dev eth0 root handle 1:htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 4096kbps ceil 4096kbps
tc class add dev eth0 parent 1: classid 1:10 htb rate 2000kbps ceil 37666kbps
tc class add dev eth0 parent 1: classid 1:20 htb rate 300kbps ceil 1766kbps
tc class add dev eth0 parent 1: classid 1:30 htb rate 25kbps ceil 30kbps
#Asocio las colas sfq con las bandas
tc qdisc add dev eth0 parent 1:10 handle 10: sfq
tc qdisc add dev eth0 parent 1:20 handle 20: sfq
tc qdisc add dev eth0 parent 1:30 handle 30: sfq
# Asocio marcas con bandas
tc filter add dev eth0 protocol ip parent 1: handle 1 fw classid 1:10
tc filter add dev eth0 protocol ip parent 1: handle 2 fw classid 1:20
tc filter add dev eth0 protocol ip parent 1: handle 3 fw classid 1:30
# Reglas de filtrado
iptables -A FORWARD -s 192.168.1.1 -t mangle -j MARK --set-mark 1
iptables -A FORWARD -s 192.168.1.2 -t mangle -j MARK --set-mark 2
iptables -A FORWARD -s 192.168.1.3 -t mangle -j MARK --set-mark 2
iptables -A FORWARD -s 192.168.1.4 -t mangle -j MARK --set-mark 2
iptables -A FORWARD -s 192.168.1.5 -t mangle -j MARK --set-mark 3 | No es pot respondre
|
61. Re: Método para la ecualización del ancho de banda (17/12/2005 03:43, #30074)
Por: jonathan |
Scero, trate de enviarte un mensaje a traves de tu web, pero no me funciono.
queria comentarte que estoy intentado levantar una red local con las mismas caracteristicas que la del ejemplo y no puedo lograrlo, necesito urgente que alguien me de una ayuda y hace 4 dias que no encuentro nada de nada.
Por favor, si no es molestia, te agradeceria que te comuniques conmigo. Muchas Gracias
Jonathan | No es pot respondre
|
62. Re: Método para la ecualización del ancho de banda (31/07/2006 07:01, #34066)
Por: HERNAN |
| Me dirijo a ustedes para ver si me pueden ayudar ya que estoy un poco estancado.
Paso a detallarles en que estoy estancado:
Bueno antes que nada estoy tratando de lograr que un server httpd y ssh tenga limitado el download y el upload del mismo para determinadas ip's ahora bien despues de haber echo cantidades de scripts con iptables y TC no logro acotar el upload de los clientes del server ahora bien mi duda fundamental es ,¿necesito si o si tener dos placas de red?... ya que veo que la mayoria de los scripts que polulan por internet hablan de eth0 y eth1 y ahi es donde deciden la velocidad de upload y la download.
Por otro lado mediante iptables les agrego los marks a cada regla pero en todas las que se refieren al upload del supuesto cliente no funcionan , me podrian aclarar.
Otra duda que tengo es si en las directivas Htb rate son generales para upload y download, porque de ser asi creo que mi problema esta en el iptables donde no se como determinar los paquetes que vienen desde una PC cliente y por ende no puedo determinarles el Filtro TC...
Bueno espero que me puedan ayudar, desde ya muchas gracias. | No es pot respondre
|
63. Re: Método para la ecualización del ancho de banda (22/09/2006 02:02, #35170)
Por: jortiz |
| Lo he leido muy bien todo, pero tengo una duda, en tu script, la eth1 está conectada al router y la eth0 a la LAN? o es al reves? | No es pot respondre
|
|
|
|
|---|
|
|
|
|
Calificacion
 
Vots: 64 |
Danos tu opinion:
|
|
|
|
|
|
|
|
