Limitar ancho de banda por ip???

[xWin2]

Buenas!

Alguien me puede guiar en el siguiente tema:
Resulta que quiero limitarle la subida por ip a 5KB, sin tener en cuenta Layer7 ni nada de eso, que la limitación sea fija...

Hay alguna forma de hacerlo en linux (distro ipcop) y de forma facil?

Gracias!








__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Boris Quiroz]

Post by xWin2
Buenas!
Resulta que quiero limitarle la subida por ip a 5KB, sin tener en cuenta
Layer7 ni nada de eso, que la limitación sea fija...
Hay alguna forma de hacerlo en linux (distro ipcop) y de forma facil?

Traffic Shapping

[Fabian Alejandro]

El limitar upload se complica, porque las queues de tc estan pensadas
para lo que la interface envia, no lo que recibe. Forma bruta y facil
es por medio de policy drop de paquetes. Forma mas prolija (con
queues), bridge o imq.
Algunos ejemplos:
www.lartc.org.
Saludos.
Fabian.

Post by xWin2
Buenas!
Resulta que quiero limitarle la subida por ip a 5KB, sin tener en cuenta
Layer7 ni nada de eso, que la limitación sea fija...
Hay alguna forma de hacerlo en linux (distro ipcop) y de forma facil?
Gracias!
________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
Probalo ya!

[Luciano Ruete]

Post by xWin2
Buenas!
Resulta que quiero limitarle la subida por ip a 5KB, sin tener en cuenta
Layer7 ni nada de eso, que la limitación sea fija...
Hay alguna forma de hacerlo en linux (distro ipcop) y de forma facil?

htb-gen[1]

Podes setear el ancho de banda por cada ip de tu LAN, tanto de subida como de
bajada. La conf es muy fácil.

[1] http://freshmeat.net/projects/htb-gen/

[xWin2]

Gracias Luciano, es justo lo que estaba buscando...

Lo voy a probar, y cualquier cosita le consulto al desarrollador del
htb-gen... ;)

Saludos!

Post by Luciano Ruete

Post by xWin2
Buenas!
Resulta que quiero limitarle la subida por ip a 5KB, sin tener en cuenta
Layer7 ni nada de eso, que la limitación sea fija...
Hay alguna forma de hacerlo en linux (distro ipcop) y de forma facil?

htb-gen[1]
Podes setear el ancho de banda por cada ip de tu LAN, tanto de subida como de
bajada. La conf es muy fácil.
[1] http://freshmeat.net/projects/htb-gen/

[lucas coudures]

no se si es justo lo que necesitas pero podrias probar con squid, es
un proxy-cache donde podes crear delay pools, para que solo navegue a
la velocidad que vos queres, ademas de poder bloquearle un monton de
cosas.

http://www.squid-cache.org/

[m***@yahoo.com.ar]

Si no me equivoco, Luciano publicó hará uno o dos
meses un script bastante piola para limitar anchos de
banda, por IP.

Yo estaba trabajando con algo así en mi PC, cuando
tenía banda ancha (snif!):

--8<----------------------------

INTENET=eth1
MAXIMO=120kbit

# Borrar reglas anteriores de bandwith shaping
tc qdisk del dev $INTERNET root

# Crear el "disco" principal
tc qdisk add dev $INTERNET \
root handle 1:0 htb default 15

# Agregar la clase encargada de distribuir el bandwith
tc class add dev $INTERNET \
parent 1:0 classid 1:1 htb rate $MAXIMO

# Limitar el ancho de banda de cada máquina
tc class add dev $INTERNET \
parent 1:1 classid 8:1 htb rate 32kbit ceil $MAXIMO
iptables -I OUTPUT -t mangle -o $INTERNET \
--source 192.168.0.1 -j MARK --set-mark 1
tc filter add dev $INTERNET protocol ip \
parent 1:0 prio 1 handle 1 fw flowid 8:1

tc class add dev $INTERNET \
parent 1:1 classid 8:2 htb rate 32kbit ceil $MAXIMO
iptables -I OUTPUT -t mangle -o $INTERNET \
--source 192.168.0.2 -j MARK --set-mark 2
tc filter add dev $INTERNET protocol ip \
parent 1:0 prio 1 handle 2 fw flowid 8:2

tc class add dev $INTERNET \
parent 1:1 classid 8:3 htb rate 32kbit ceil $MAXIMO
iptables -I OUTPUT -t mangle -o $INTERNET \
--source 192.168.0.3 -j MARK --set-mark 1
tc filter add dev $INTERNET protocol ip \
parent 1:0 prio 1 handle 3 fw flowid 8:3

.
.
.

# (estaría mejor hacer eso con un for)

--8<----------------------------

No es de lo mejor, pero a mí me andaba bien.
También usé el squid-caching-proxy que se te sugiere
en un mail anterior, pero en modo "proxy transparente"
(http://en.wikipedia.org/wiki/Transparent_proxy#Transparent_and_non-transparent_proxy_server),
es de cagarse de risa la cara de mi viejo al recién
encender su PC y ver que Yahoo! se cargaba tan rápido
como si tuviéramos fibra óptica (cuando en realidad yo
acababa de acceder a Yahoo! desde otra PC... jajaja).

--
Matonga






__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Fabian Alejandro]

Post by m***@yahoo.com.ar
Si no me equivoco, Luciano publicó hará uno o dos
meses un script bastante piola para limitar anchos de
banda, por IP.
Yo estaba trabajando con algo así en mi PC, cuando
--8<----------------------------
INTENET=eth1
MAXIMO=120kbit
# Borrar reglas anteriores de bandwith shaping
tc qdisk del dev $INTERNET root
# Crear el "disco" principal
tc qdisk add dev $INTERNET \
root handle 1:0 htb default 15
# Agregar la clase encargada de distribuir el bandwith
tc class add dev $INTERNET \
parent 1:0 classid 1:1 htb rate $MAXIMO
# Limitar el ancho de banda de cada máquina
tc class add dev $INTERNET \
parent 1:1 classid 8:1 htb rate 32kbit ceil $MAXIMO
iptables -I OUTPUT -t mangle -o $INTERNET \
--source 192.168.0.1 -j MARK --set-mark 1

y estas reglas te andaban? en la interfaz internet se supone que la ip
de la lan esta enmascarada, no sabe nada de 192.168.0.*

Saludos.
Fabian.

[m***@yahoo.com.ar]

Post by m***@yahoo.com.ar

Post by m***@yahoo.com.ar
Si no me equivoco, Luciano publicó hará uno o dos
meses un script bastante piola para limitar anchos

de

Post by m***@yahoo.com.ar
banda, por IP.
Yo estaba trabajando con algo así en mi PC, cuando
--8<----------------------------
INTENET=eth1
MAXIMO=120kbit
# Borrar reglas anteriores de bandwith shaping
tc qdisk del dev $INTERNET root
# Crear el "disco" principal
tc qdisk add dev $INTERNET \
root handle 1:0 htb default 15
# Agregar la clase encargada de distribuir el

bandwith

Post by m***@yahoo.com.ar
tc class add dev $INTERNET \
parent 1:0 classid 1:1 htb rate $MAXIMO
# Limitar el ancho de banda de cada máquina
tc class add dev $INTERNET \
parent 1:1 classid 8:1 htb rate 32kbit ceil

$MAXIMO

Post by m***@yahoo.com.ar
iptables -I OUTPUT -t mangle -o $INTERNET \
--source 192.168.0.1 -j MARK --set-mark 1

y estas reglas te andaban? en la interfaz internet
se supone que la ip
de la lan esta enmascarada, no sabe nada de
192.168.0.*

Sí, lo probé y funcionaba.

Recuerdo además haber leído en la documentación de
iptables que éste es capaz de recordar de qué IP
provenía el paquete antes de enmascararlo. De hecho
así es como luego puede devolver los paquetes a la IP
correcta cuando ingresan de afuera por una conexión
enmascarada, al menos en el caso de TCP.

Hice pruebas de hacer una descarga con Flashget (no
conocía FDM) (ambas máquinas Windozas, no tenía otra
cosa a mano) con 10 partes concurrentes en uno, y 1
sola parte en otro, y ambos bajaban a 59 +/- 4 kbps
(la conexión era de 128 kbps). Esto me da la seguridad
de que funcionaba bien, ya que además cuando quitaba
las reglas de bandwith shaping la primer máquina (10
partes concurrentes) se comía a la segunda y no le
dejaba descargar -bajaba pero a duras penas y un
lamentable 1/2 kbps, promedio).

Lo que me queda duda ahora es si el shaping que hice
funcionaría también con UDP...

--
Matonga






__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Fabian Alejandro]

Post by m***@yahoo.com.ar

Post by m***@yahoo.com.ar

Post by m***@yahoo.com.ar
INTENET=eth1
MAXIMO=120kbit
# Borrar reglas anteriores de bandwith shaping
tc qdisk del dev $INTERNET root
# Crear el "disco" principal
tc qdisk add dev $INTERNET \
root handle 1:0 htb default 15
# Agregar la clase encargada de distribuir el

bandwith

Post by m***@yahoo.com.ar
tc class add dev $INTERNET \
parent 1:0 classid 1:1 htb rate $MAXIMO
# Limitar el ancho de banda de cada máquina
tc class add dev $INTERNET \
parent 1:1 classid 8:1 htb rate 32kbit ceil

$MAXIMO

Post by m***@yahoo.com.ar
iptables -I OUTPUT -t mangle -o $INTERNET \
--source 192.168.0.1 -j MARK --set-mark 1

y estas reglas te andaban? en la interfaz internet
se supone que la ip
de la lan esta enmascarada, no sabe nada de
192.168.0.*

Sí, lo probé y funcionaba.
Recuerdo además haber leído en la documentación de
iptables que éste es capaz de recordar de qué IP
provenía el paquete antes de enmascararlo. De hecho
así es como luego puede devolver los paquetes a la IP
correcta cuando ingresan de afuera por una conexión
enmascarada, al menos en el caso de TCP.
Hice pruebas de hacer una descarga con Flashget (no
conocía FDM) (ambas máquinas Windozas, no tenía otra
cosa a mano) con 10 partes concurrentes en uno, y 1
sola parte en otro, y ambos bajaban a 59 +/- 4 kbps
(la conexión era de 128 kbps). Esto me da la seguridad
de que funcionaba bien, ya que además cuando quitaba
las reglas de bandwith shaping la primer máquina (10
partes concurrentes) se comía a la segunda y no le
dejaba descargar -bajaba pero a duras penas y un
lamentable 1/2 kbps, promedio).

Lo que vos dices es una bajada, que es facil limitarlo, entonces
interprete mal tu script, -o $INTERNET yo pense que era el upload a
internet, no descarga.
En los scripts que vi suelen llamar $INIF y $EXTIF, para evitar estos
malentendidos.
Saludos.

[xWin2]

Tengo configurado un Squid, y limitado a 8KB por IP, el problema está
con otras aplicaciones como Ares por ejemplo, que ocupan todo el ancho
de banda que tienen disponible, por eso quiero limitarlos un poco y no
bloquearlos definitivamente...
Tampoco me sirve mucho usar Layer7 ya que la mayoría de los P2P están
encriptando los paquetes para no ser detectados en L7 (uTorrent, eMule,
etc.) :( :( :(

Post by lucas coudures
no se si es justo lo que necesitas pero podrias probar con squid, es
un proxy-cache donde podes crear delay pools, para que solo navegue a
la velocidad que vos queres, ademas de poder bloquearle un monton de
cosas.
http://www.squid-cache.org/

[Herr Groucho]

Post by Luciano Ruete

Post by xWin2
Resulta que quiero limitarle la subida por ip a 5KB, sin tener en
cuenta Layer7 ni nada de eso, que la limitación sea fija...
Hay alguna forma de hacerlo en linux (distro ipcop) y de forma facil?

htb-gen[1]
Podes setear el ancho de banda por cada ip de tu LAN, tanto de
subida como de bajada. La conf es muy fácil.
[1] http://freshmeat.net/projects/htb-gen/

Bien, estoy llegando a un punto donde me empiezan a interesar este
tipo de temas.
a) Suficiente ancho de banda disponible en mi casa como para que
compartirlo con reglas explícitas tenga sentido.
b) Compañeros de trabajo con comportamiento "agresivo" hacia la red,
como correr peers p2p todo el tiempo en lugar circunstancialmente y
sólo cuando no sería notado por la gente con autoridad para indicarme
que filtre ese tipo de tráfico en el gateway a Internet.


Tenía pendiente usar tu script htb-gen como primera aproximación al
tema y para empezar a indagar en los conceptos relacionados. La
limitación que creo que tiene tu script para mis casos de uso es que
no maneja el uso de ancho de banda originado o terminado en el propio
router, sólo el que pasa de largo de una interfaz a otra.
Significaría que el script se adapta a una configuración de router
puro, como el que se encontraría en un cybercafé de barrio :-) pero
no al caso de un servidor hogareño o de pequeña empresa que hace de
router y de muchas otras cosas más, como servidor web, o peer p2p.

Quiero que si dejo corriendo un programa p2p corriendo en el servidor
de mi casa, que el acceso al sitio web hospedo en mi servidor no se
vea adversamente afectado, ni quiero que durante las horas del día en
las que hay otras máquinas encendidas y usando Internet en mi casa
estas noten una degradación significativa de la calidad de servicio.

En otras palabras, quiero que el tráfico originado o terminado en el
servidor mismo que hace de router para mi red interna sufra la misma
clasificación en "prio" y "junk" que el tráfico originado o terminado
en los hosts de la red interna.
htb-gen permite generar reglas a tal efecto?

La otra pregunta que tengo es qué es htb_init y si me pierdo algo por
no usarlo. Entiendo que es otro generador de reglas y que tu htb-gen
puede generar configuraciones para htb_init para htb_init genere las
reglas... pero para qué querría hacer eso en lugar de hacer todo
directamente con uno u otro script?

En cuanto a activar las reglas, un método que no parece estar
mencionado en la configuración y que es el que yo creo que adoptaría
sería colocar las reglas generadas en /etc/network/interfaces en
sentencias "up" asociadas a las diferentes interfaces.

Finalmente, quisiera saber si estás aceptando parches cosméticos
(ortografía, redacción, etc.), y si tendrías el paquete .deb fuente
disponible y si te interesaría que mantuviera un paquete de htb-gen
oficial para Debian basado en el tuyo si eventualmente llego a
aprender lo suficiente del tema de htb como para hacerme cargo de un
paquete de htb-gen.

[Luciano Ruete]

This e-mail Groucho's mode: berborragicus

Post by Luciano Ruete

Post by xWin2
Resulta que quiero limitarle la subida por ip a 5KB, sin tener en
cuenta Layer7 ni nada de eso, que la limitación sea fija...
Hay alguna forma de hacerlo en linux (distro ipcop) y de forma facil?

htb-gen[1]
Podes setear el ancho de banda por cada ip de tu LAN, tanto de
subida como de bajada. La conf es muy fácil.
[1] http://freshmeat.net/projects/htb-gen/

Bien, estoy llegando a un punto donde me empiezan a interesar este
tipo de temas.
a) Suficiente ancho de banda disponible en mi casa como para que
compartirlo con reglas explícitas tenga sentido.
b) Compañeros de trabajo con comportamiento "agresivo" hacia la red,
como correr peers p2p todo el tiempo en lugar circunstancialmente y
sólo cuando no sería notado por la gente con autoridad para indicarme
que filtre ese tipo de tráfico en el gateway a Internet.
Tenía pendiente usar tu script htb-gen como primera aproximación al
tema y para empezar a indagar en los conceptos relacionados. La
limitación que creo que tiene tu script para mis casos de uso es que
no maneja el uso de ancho de banda originado o terminado en el propio
router, sólo el que pasa de largo de una interfaz a otra.

En realidad no es una limitación de htb-gen sino del kernel de Linux.
La limitación viene dada porque las classful qdisc[1] solo funcionan con
tráfico saliente y no con tráfico entrante.
Esto quiere decir que cuando yo "cuelgo" una qdisc de un device, esta funciona
sólo para todo lo que va a salir por ese device y no para lo que entra.

Hay una lógica de porque esto es así y es que a los desarrolladores les sonó
más lógico manejar colas(queues) más complejas sobre algo en que yo tengo el
control(el output) y no sobre algo que no lo tengo(el input).

En la práctica, para regular el ancho de banda a un punto no queda otra que
dropear paquetes para que el tráfico baje, y esto termina en retransmisiones
hasta que el "congestion control" de tcp se adapta a la situación.
Hacer eso en "output" y hacerlo en "input" es igual de eficaz como grosero.

De hecho yo puedo inventar un device virtual(con IMQ o IFB), "colgarle" una
classful qdisc, y hacer pasar por ese virtual device todo el tráfico que
ingresa por un device real.
IFB es parte oficial del kernel desde hace algunas versiones, y el que
menciono es uno de sus usos más populares, por lo que los propios
desarrolladores de alguna manera aceptan el uso de qdiscs para input.

Otro camino es usar una qdisc especial llamada ingress[2], no permite
jerarquía ni borrowing(es decir no es clasfull) pero permite usar tc filters
con TBF para aplicar distintos anchos de banda a cada filtro.

Significaría que el script se adapta a una configuración de router
puro, como el que se encontraría en un cybercafé de barrio :-) pero
no al caso de un servidor hogareño o de pequeña empresa que hace de
router y de muchas otras cosas más, como servidor web, o peer p2p.
Quiero que si dejo corriendo un programa p2p corriendo en el servidor
de mi casa, que el acceso al sitio web hospedo en mi servidor no se
vea adversamente afectado, ni quiero que durante las horas del día en
las que hay otras máquinas encendidas y usando Internet en mi casa
estas noten una degradación significativa de la calidad de servicio.
En otras palabras, quiero que el tráfico originado o terminado en el
servidor mismo que hace de router para mi red interna sufra la misma
clasificación en "prio" y "junk" que el tráfico originado o terminado
en los hosts de la red interna.
htb-gen permite generar reglas a tal efecto?

short answer: no, htb-gen esta pensado para un router puro.

long answer(usando htb-gen-0.9-b1): podrías crear un virtual device con
IMQ/IFB el cual reciba el tráfico entrante. Luego confiugrás en
htb-gen-rates.conf la ip del propio servidor, usando el device virtual como
entrante y el real como saliente. Y hasta aca todo bonito.
Habría un solo problema más.
<problema>
Si en htb-gen seteas para un cliente como prio el puerto 80(x ej), quiere
decir que un cliente que está pidiendo una pagina web tiene prioridad. Esto
se mapea a "dst port 80" en la interfaz de download y "src port 80" en la
interfaz de upload.
En el caso de poner puerto 80 para un servidor querrías exactamente el
comportamiento contrario, es decir, "src port 80" en la interfaz de download
y "dst port 80" en la interfaz de upload.

Se me ocurren dos soluciones:
1)invertir a proposito los valores de iface_up e iface_down en la conf de las
ips que corresponden a servidores.
2)implementando "yet another parameter" en htb-gen-rates.conf que determine si
la ip es un server o un cliente(es decir si hace falta invertir el sentido de
los puertos o no).
</problema>

La otra pregunta que tengo es qué es htb_init y si me pierdo algo por
no usarlo. Entiendo que es otro generador de reglas y que tu htb-gen
puede generar configuraciones para htb_init para htb_init genere las
reglas... pero para qué querría hacer eso en lugar de hacer todo
directamente con uno u otro script?

htb_init permite crear arboles de jerarquias a voluntad, lo cual permite ir
separando el ancho de banda en porciones lógicas para luego en algún punto
llegar a los clientes o servicioes reales, aprobechando la totalidad de la
funcionalidad de htb.

htb-gen oculta esta funcionalidad poniendo a todos los clientes al mismo
nivel, bajo un mimso padre que tiene el total del ancho de banda, y luego
genera unas jerarquías hijas por cliente para separar prio y junk.
El beneficio de htb-gen es la simplicidad, ya que armar y mantener jerarquías
usando htb_init resulta engorroso e imantenible con esquemas muy grandes o
muy dinámicos.

La capacidad de integrar htb-gen en htb_init(capacidad que fue removida de
htb-gen para la versión 0.9 ya que nunca la use) permite crear jerarquías
libremente con htb_init, y luego colgar de una de esas ramas una
configuración de htb-gen.

En cuanto a activar las reglas, un método que no parece estar
mencionado en la configuración y que es el que yo creo que adoptaría
sería colocar las reglas generadas en /etc/network/interfaces en
sentencias "up" asociadas a las diferentes interfaces.

con "colocar las reglas generadas" a que te referis?, si es el comando
up htb-gen tc_all estoy deacuerdo y se podría agregar a la doc, sobre todo al
README.Debian, si lo que te referis es a colocar la salida de tc_stdout x ej,
sería inmantenible tener que re-editar /etc/network/interfaces cada vez que
cambias un toque htb-gen-rates.conf

Finalmente, quisiera saber si estás aceptando parches cosméticos
(ortografía, redacción, etc.),

totalmente :-), en el TODO de htb-gen-0.8.4 se puede leer:
"-Someone correct my ofensive english along doc/scripts"

(probablemente hasta ofensive este mal escrito,...googling... sí, está mal
escrito: es offensive)

y si tendrías el paquete .deb fuente

estem... te adjunto lo que sería mi paquete ".deb fuente" :-), es un script y
se usa parado en el home del repo de htb-gen, y me facilita la creación de
paquetes en cada release, de hecho si haces un pull[3] del repositorio de
htb-gen lo vas a encontrar bajo el directorio "scripts/"

disponible y si te interesaría que mantuviera un paquete de htb-gen
oficial para Debian basado en el tuyo si eventualmente llego a
aprender lo suficiente del tema de htb como para hacerme cargo de un
paquete de htb-gen.

Absolutamente, bienvenido sea! :-D

[1]http://lartc.org/howto/lartc.qdisc.classful.html
[2]http://lartc.org/howto/lartc.adv-qdisc.ingress.html
[3]git-clone http://www.lugmen.org.ar/~luciano/git-repo/htb-gen/.git

[Alejandro Vargas]

Post by Luciano Ruete
En realidad no es una limitación de htb-gen sino del kernel de Linux.
La limitación viene dada porque las classful qdisc[1] solo funcionan con
tráfico saliente y no con tráfico entrante.

Bueno, eso es lógico ya que el tráfico entrante cuando entra es porque
ya llegó. Pero hay maneras de controlarlo con imq por ejemplo.

Post by Luciano Ruete
1)invertir a proposito los valores de iface_up e iface_down en la conf de las
ips que corresponden a servidores.
2)implementando "yet another parameter" en htb-gen-rates.conf que determine si
la ip es un server o un cliente(es decir si hace falta invertir el sentido de
los puertos o no).

Lo que yo veo en todos estos frontends para configurar tc, es que al
final se vuelven tan complicados como escribir las reglas de TC a
mano. Lo que está haciendo falta es algo más descriptivo. O sea, algo
donde planteés la situación que tenés y qué querés hacer y el frontend
se encargue de decidir las reglas. Algo así como decirle: tengo un
servidor web en tal dirección, un usuario con tal prioridad en tal
parte, y quiero que el bit torrent tenga tal ancho de banda. Si hay
que invertir cosas, porque la dirección del servidor web corresponde
con la del equipo que hace de router, que sea el frontend el que se
encargue de hacerlo.

Post by Luciano Ruete
El beneficio de htb-gen es la simplicidad, ya que armar y mantener jerarquías
usando htb_init resulta engorroso e imantenible con esquemas muy grandes o
muy dinámicos.

Lo que te decía, que al final se complica igual o más la cosa.

[Herr Groucho]

Post by Alejandro Vargas

Post by Luciano Ruete
En realidad no es una limitación de htb-gen sino del kernel de
Linux. La limitación viene dada porque las classful qdisc[1] solo
funcionan con tráfico saliente y no con tráfico entrante.

Bueno, eso es lógico ya que el tráfico entrante cuando entra es
porque ya llegó. Pero hay maneras de controlarlo con imq por
ejemplo.

Post by Luciano Ruete
1)invertir a proposito los valores de iface_up e iface_down en la
conf de las ips que corresponden a servidores.
2)implementando "yet another parameter" en htb-gen-rates.conf que
determine si la ip es un server o un cliente(es decir si hace
falta invertir el sentido de los puertos o no).

Lo que yo veo en todos estos frontends para configurar tc, es que
al final se vuelven tan complicados como escribir las reglas de TC
a mano. Lo que está haciendo falta es algo más descriptivo. O sea,
algo donde planteés la situación que tenés y qué querés hacer y el
tengo un servidor web en tal dirección, un usuario con tal
prioridad en tal parte, y quiero que el bit torrent tenga tal ancho
de banda. Si hay que invertir cosas, porque la dirección del
servidor web corresponde con la del equipo que hace de router, que
sea el frontend el que se encargue de hacerlo.

Bueno, el primer paso entonces es enunciar descriptivamente los
requisitos.
Veamos los requisitos para un servidor hogareño como el mío, que
también es servidor de algunas cosas para afuera y de varias más para
adentro.
En lo que sigue, todo lo que está entre <> puede ser sustituido por
otros valores.

Reglas para el tráfico que no se enruta a través de esta máquina, sino
que es recibido o transmitido por esta máquina:

0) El tráfico originado en una máquina accesible a través de <eth0> y
terminado en esta máquina, así como el tráfico originado en esta
máquina y terminado en una máquina accesible a través de <eth0> no
está sujeto a restricciones ni priorización. (Vista desde la red
interna, esta máquina está tan libre de restricciones como entre sí
lo están las demás máquinas de la red interna).

1) El tráfico originado en una máquina accesible a través de <ppp0> y
terminado en esta máquina, así como el tráfico originado en esta
máquina y terminado en una máquina accesible a través de <ppp0> se
clasifica en 2 categorías: prioritario y chatarra.
- Es prioritario el tráfico de paquetes menores a 100 bytes
(No queremos molestar a TCP cagándole sus ACKs, etc.)
- Es prioritario el tráfico ICMP
(No queremos cagarle nada al protocolo de control de Internet)
- Es prioritario el tráfico UDP
(El DNS tiene que andar bien)
- Es prioritario el tráfico TCP perteneciente o relacionado a
conexiones originadas en esta máquina y dirigidas a los puertos
<ssh, ftp, http, smtp, pop3, pop3s, imaps, imaps, xmpp, xmpps>. Esta
lista es igual a la que se menciona en la regla 2.
(Además de router es ciudadano de primera de nuestra red)
- Es prioritario el tráfico TCP perteneciente o relacionado a
conexiones destinadas a esta máquina y dirigidas a los puertos
<ssh, ftp, http, smtp, pop3, imap, pop3s e imaps>. Esta lista
debe poder ser configurada diferentemente a la del punto anterior.
(Esta máquina es un servidor además de router)
- El resto del tráfico es chatarra
(Si no puedo nombrarlo, evidentemente no me importa y es chatarra,
hasta tanto no se termine de universalizar el uso de HTTP como capa
de transporte, y tengamos que irnos a capa 7 para distinguir lo
importante de la chatarra)

1.1) El tráfico chatarra tendrá garantizado un ancho de banda mínimo
de <10%> de la capacidad del enlace <ppp0>.
El tráfico prioritario tendrá disponible entre el <100%> y el <90%>
del ancho de banda del enlace <ppp0>, según lo que deje libre el
tráfico chatarra.

1.2.1) El ancho de banda chatarra originado o destinado a este host
comparte ancho de banda con el tráfico chatarra enrutado a través de
este host originado o destinado a un host accesible a través de
<eth0>.

1.2.2) El ancho de banda prioritario originado o destinado a este host
comparte ancho de banda con el tráfico prioritario enrutado a través
de este host originado o destinado a un host accesible a través de
<eth0>, pero a diferencia del tráfico chatarra, se debe garantizar
una distribución equitativa del ancho de banda para tráfico
prioritario entre este host y cada uno de los hosts accesibles a
través de <eth0> que estén activamente cursando tráfico prioritario.


Reglas para el tráfico que se enruta a través de esta máquina:

2) El tráfico originado en una máquina accesible a través de <ppp0> y
terminado en una máquina accesible a través de <eth0>, así como el
tráfico originado en una máquina accesible a través de <eth0> y
terminado en una máquina accesible a través de <ppp0> se clasifica en
2 categorías: prioritario y chatarra.
- Es prioritario el tráfico de paquetes menores a 100 bytes
(No queremos molestar a TCP cagándole sus ACKs, etc.)
- Es prioritario el tráfico ICMP
(No queremos cagarle nada al protocolo de control de Internet)
- Es prioritario el tráfico UDP
(Los jueguitos tienen que andar bien, así como el DNS)
- Es prioritario el tráfico TCP perteneciente o relacionado a
conexiones dirigidas a los puertos <ssh, ftp, http, smtp, pop3,
pop3s, imap, imaps, xmpp y xmpps>.
- El resto del tráfico es chatarra.


Ejemplos de los efectos que esas reglas se supone que causan:

- Si dejo bittorrent corriendo en el servidor/router:
- no repercute negativamente en la experiencia de usuario al usar
la web, el mail, la mensajería instantánea, etc. desde la red
interna.
- un aptitude upgrade en el servidor baja a velocidad decente.
- puedo usar mi webmail y mostrar mis fotos a través de mi servidor
web estando en el trabajo o en la casa de un familiar o amigo.
- puedo hacer ssh a mi máquina sin que la latencia sea inmunda.
- El MTA de mi servidor no se pone pastoso para enviar o recibir
mensajes por estar alguien usando redes p2p en mi red o en mi
servidor.
- Si me pongo a bajar cosas por HTTP o FTP en mi máquina, marc sólo me
putea por quitarle la mitad del ancho de banda a su máquina, y no
más.
- Si me pongo a bajar descontroladamente en el servidor y en 2 de las
máquinas de la red interna, cada una de esas 3 puede gozar de
aproximadamente 1/3 del ancho de banda del enlace.
- Si pongo una cuarta máquina máquina a bajar, se reacomoda todo y
las cuatro disfrutan de 1/4 del ancho de banda del enlace a
Internet.
- Si viene un amigo y enchufa su notebook y se pone también a
bajar a lo, recibe 1/5 del ancho de banda del enlace, y la
restricción no se puede eludir colocándose él una dirección IP
diferente de la que le asignó mi servidor DHCP.

Quién es el valiente que responde con las reglas que implementan ese
comportamiento?
(generadas a mano o con htb-gen)

[Demian Pecile]

Post by Herr Groucho

Post by Alejandro Vargas

Post by Luciano Ruete
En realidad no es una limitación de htb-gen sino del kernel de
Linux. La limitación viene dada porque las classful qdisc[1] solo
funcionan con tráfico saliente y no con tráfico entrante.

Bueno, eso es lógico ya que el tráfico entrante cuando entra es
porque ya llegó. Pero hay maneras de controlarlo con imq por
ejemplo.

Post by Luciano Ruete
1)invertir a proposito los valores de iface_up e iface_down en la
conf de las ips que corresponden a servidores.
2)implementando "yet another parameter" en htb-gen-rates.conf que
determine si la ip es un server o un cliente(es decir si hace
falta invertir el sentido de los puertos o no).

Lo que yo veo en todos estos frontends para configurar tc, es que
al final se vuelven tan complicados como escribir las reglas de TC
a mano. Lo que está haciendo falta es algo más descriptivo. O sea,
algo donde planteés la situación que tenés y qué querés hacer y el
tengo un servidor web en tal dirección, un usuario con tal
prioridad en tal parte, y quiero que el bit torrent tenga tal ancho
de banda. Si hay que invertir cosas, porque la dirección del
servidor web corresponde con la del equipo que hace de router, que
sea el frontend el que se encargue de hacerlo.

Bueno, el primer paso entonces es enunciar descriptivamente los
requisitos.
Veamos los requisitos para un servidor hogareño como el mío, que
también es servidor de algunas cosas para afuera y de varias más para
adentro.
En lo que sigue, todo lo que está entre <> puede ser sustituido por
otros valores.
Reglas para el tráfico que no se enruta a través de esta máquina, sino
0) El tráfico originado en una máquina accesible a través de <eth0> y
terminado en esta máquina, así como el tráfico originado en esta
máquina y terminado en una máquina accesible a través de <eth0> no
está sujeto a restricciones ni priorización. (Vista desde la red
interna, esta máquina está tan libre de restricciones como entre sí
lo están las demás máquinas de la red interna).
1) El tráfico originado en una máquina accesible a través de <ppp0> y
terminado en esta máquina, así como el tráfico originado en esta
máquina y terminado en una máquina accesible a través de <ppp0> se
clasifica en 2 categorías: prioritario y chatarra.
- Es prioritario el tráfico de paquetes menores a 100 bytes
(No queremos molestar a TCP cagándole sus ACKs, etc.)
- Es prioritario el tráfico ICMP
(No queremos cagarle nada al protocolo de control de Internet)
- Es prioritario el tráfico UDP
(El DNS tiene que andar bien)
- Es prioritario el tráfico TCP perteneciente o relacionado a
conexiones originadas en esta máquina y dirigidas a los puertos
<ssh, ftp, http, smtp, pop3, pop3s, imaps, imaps, xmpp, xmpps>. Esta
lista es igual a la que se menciona en la regla 2.
(Además de router es ciudadano de primera de nuestra red)
- Es prioritario el tráfico TCP perteneciente o relacionado a
conexiones destinadas a esta máquina y dirigidas a los puertos
<ssh, ftp, http, smtp, pop3, imap, pop3s e imaps>. Esta lista
debe poder ser configurada diferentemente a la del punto anterior.
(Esta máquina es un servidor además de router)
- El resto del tráfico es chatarra
(Si no puedo nombrarlo, evidentemente no me importa y es chatarra,
hasta tanto no se termine de universalizar el uso de HTTP como capa
de transporte, y tengamos que irnos a capa 7 para distinguir lo
importante de la chatarra)
1.1) El tráfico chatarra tendrá garantizado un ancho de banda mínimo
de <10%> de la capacidad del enlace <ppp0>.
El tráfico prioritario tendrá disponible entre el <100%> y el <90%>
del ancho de banda del enlace <ppp0>, según lo que deje libre el
tráfico chatarra.
1.2.1) El ancho de banda chatarra originado o destinado a este host
comparte ancho de banda con el tráfico chatarra enrutado a través de
este host originado o destinado a un host accesible a través de
<eth0>.
1.2.2) El ancho de banda prioritario originado o destinado a este host
comparte ancho de banda con el tráfico prioritario enrutado a través
de este host originado o destinado a un host accesible a través de
<eth0>, pero a diferencia del tráfico chatarra, se debe garantizar
una distribución equitativa del ancho de banda para tráfico
prioritario entre este host y cada uno de los hosts accesibles a
través de <eth0> que estén activamente cursando tráfico prioritario.
2) El tráfico originado en una máquina accesible a través de <ppp0> y
terminado en una máquina accesible a través de <eth0>, así como el
tráfico originado en una máquina accesible a través de <eth0> y
terminado en una máquina accesible a través de <ppp0> se clasifica en
2 categorías: prioritario y chatarra.
- Es prioritario el tráfico de paquetes menores a 100 bytes
(No queremos molestar a TCP cagándole sus ACKs, etc.)
- Es prioritario el tráfico ICMP
(No queremos cagarle nada al protocolo de control de Internet)
- Es prioritario el tráfico UDP
(Los jueguitos tienen que andar bien, así como el DNS)
- Es prioritario el tráfico TCP perteneciente o relacionado a
conexiones dirigidas a los puertos <ssh, ftp, http, smtp, pop3,
pop3s, imap, imaps, xmpp y xmpps>.
- El resto del tráfico es chatarra.
- no repercute negativamente en la experiencia de usuario al usar
la web, el mail, la mensajería instantánea, etc. desde la red
interna.
- un aptitude upgrade en el servidor baja a velocidad decente.
- puedo usar mi webmail y mostrar mis fotos a través de mi servidor
web estando en el trabajo o en la casa de un familiar o amigo.
- puedo hacer ssh a mi máquina sin que la latencia sea inmunda.
- El MTA de mi servidor no se pone pastoso para enviar o recibir
mensajes por estar alguien usando redes p2p en mi red o en mi
servidor.
- Si me pongo a bajar cosas por HTTP o FTP en mi máquina, marc sólo me
putea por quitarle la mitad del ancho de banda a su máquina, y no
más.
- Si me pongo a bajar descontroladamente en el servidor y en 2 de las
máquinas de la red interna, cada una de esas 3 puede gozar de
aproximadamente 1/3 del ancho de banda del enlace.
- Si pongo una cuarta máquina máquina a bajar, se reacomoda todo y
las cuatro disfrutan de 1/4 del ancho de banda del enlace a
Internet.
- Si viene un amigo y enchufa su notebook y se pone también a
bajar a lo, recibe 1/5 del ancho de banda del enlace, y la
restricción no se puede eludir colocándose él una dirección IP
diferente de la que le asignó mi servidor DHCP.
Quién es el valiente que responde con las reglas que implementan ese
comportamiento?
(generadas a mano o con htb-gen)

Ojo que mañana te sacan un p2p por udp y te complican, yo diria de
tratar al udp como bueno si conocido, chatarra si desconocido ...
tipo 53 (dns), 27015 (CS), etc...

Desgraciadamente por ahora mi conocimiento es minusculo, por lo que paso
del desafio :)

Saludos

Demian

[Herr Groucho]

Post by Demian Pecile

Post by Herr Groucho

Post by Alejandro Vargas
Lo que yo veo en todos estos frontends para configurar tc, es
que al final se vuelven tan complicados como escribir las reglas
de TC a mano. Lo que está haciendo falta es algo más
descriptivo. O sea, algo donde planteés la situación que tenés y
qué querés hacer y el frontend se encargue de decidir las
reglas. Algo así como decirle: tengo un servidor web en tal
dirección, un usuario con tal prioridad en tal parte, y quiero
que el bit torrent tenga tal ancho de banda. Si hay que invertir
cosas, porque la dirección del servidor web corresponde con la
del equipo que hace de router, que sea el frontend el que se
encargue de hacerlo.

Bueno, el primer paso entonces es enunciar descriptivamente los
requisitos.
Veamos los requisitos para un servidor hogareño como el mío, que
también es servidor de algunas cosas para afuera y de varias más
para adentro.

[muchas reglas]

Post by Demian Pecile

Post by Herr Groucho
Quién es el valiente que responde con las reglas que implementan
ese comportamiento?
(generadas a mano o con htb-gen)

Ojo que mañana te sacan un p2p por udp y te complican, yo diria de
tratar al udp como bueno si conocido, chatarra si desconocido ...
tipo 53 (dns), 27015 (CS), etc...

Es buen enfoque, pero como se trata de mi red, mis máquinas, mi
enlace, no se trata de jugar a la policía de red, sino a poder usar
más provechosamente los recursos. Es decir: tienen que sacar un
sistema p2p que use UDP, que usarlo en mi red, tiene que molestarme
el ancho de banda que consuma, y tiene que molestarme aún más tener
que parar la descarga para hacer algo más urgente a velocidad
decente...

Mientras todo eso no ocurra prefiero reglas simples, más fáciles de
entender y mantener.

[Boris Quiroz]

Post by Herr Groucho

Post by Demian Pecile

Post by Herr Groucho

Post by Alejandro Vargas
Lo que yo veo en todos estos frontends para configurar tc, es
que al final se vuelven tan complicados como escribir las reglas
de TC a mano. Lo que está haciendo falta es algo más
descriptivo. O sea, algo donde planteés la situación que tenés y
qué querés hacer y el frontend se encargue de decidir las
reglas. Algo así como decirle: tengo un servidor web en tal
dirección, un usuario con tal prioridad en tal parte, y quiero
que el bit torrent tenga tal ancho de banda. Si hay que invertir
cosas, porque la dirección del servidor web corresponde con la
del equipo que hace de router, que sea el frontend el que se
encargue de hacerlo.

Bueno, el primer paso entonces es enunciar descriptivamente los
requisitos.
Veamos los requisitos para un servidor hogareño como el mío, que
también es servidor de algunas cosas para afuera y de varias más
para adentro.

[muchas reglas]

Post by Demian Pecile

Post by Herr Groucho
Quién es el valiente que responde con las reglas que implementan
ese comportamiento?
(generadas a mano o con htb-gen)

Ojo que mañana te sacan un p2p por udp y te complican, yo diria de
tratar al udp como bueno si conocido, chatarra si desconocido ...
tipo 53 (dns), 27015 (CS), etc...

Crees que alguna vez salga un p2p por un protocolo "no confiable"?
Recuerda que UDP no garantiza que el paquete llegue de un lado a otro...


Es buen enfoque, pero como se trata de mi red, mis máquinas, mi

Post by Herr Groucho
enlace, no se trata de jugar a la policía de red, sino a poder usar
más provechosamente los recursos. Es decir: tienen que sacar un
sistema p2p que use UDP, que usarlo en mi red, tiene que molestarme
el ancho de banda que consuma, y tiene que molestarme aún más tener
que parar la descarga para hacer algo más urgente a velocidad
decente...

Uhm, mas que prohibir algo que te moleste, creo que tambien tienes que
pensar en tus equipos y que les está molestando a ellos. Yo soy de los que
se preocupan de ver que tanto trafico innecesario anda por la red y tratar
de eliminarlo o bien reducirlo al máximo. Hay algunas conexiones que quizas
a nosotros no pueden provocarnos mayores problemas, pero para nuestros
equipos de conectividad esas mismas conexiones/trafico puede ser algo
molesto...

Mientras todo eso no ocurra prefiero reglas simples, más fáciles de

Post by Herr Groucho
entender y mantener.

La idea es que uno se entienda y sepa que es lo que tiene :-)

Saludos.

[Demian Pecile]

Post by Herr Groucho

Post by Demian Pecile

Post by Herr Groucho

Post by Alejandro Vargas
Lo que yo veo en todos estos frontends para configurar tc, es
que al final se vuelven tan complicados como escribir las reglas
de TC a mano. Lo que está haciendo falta es algo más
descriptivo. O sea, algo donde planteés la situación que tenés y
qué querés hacer y el frontend se encargue de decidir las
reglas. Algo así como decirle: tengo un servidor web en tal
dirección, un usuario con tal prioridad en tal parte, y quiero
que el bit torrent tenga tal ancho de banda. Si hay que invertir
cosas, porque la dirección del servidor web corresponde con la
del equipo que hace de router, que sea el frontend el que se
encargue de hacerlo.

Bueno, el primer paso entonces es enunciar descriptivamente los
requisitos.
Veamos los requisitos para un servidor hogareño como el mío, que
también es servidor de algunas cosas para afuera y de varias más
para adentro.

[muchas reglas]

Post by Demian Pecile

Post by Herr Groucho
Quién es el valiente que responde con las reglas que implementan
ese comportamiento?
(generadas a mano o con htb-gen)

Ojo que mañana te sacan un p2p por udp y te complican, yo diria de
tratar al udp como bueno si conocido, chatarra si desconocido ...
tipo 53 (dns), 27015 (CS), etc...

Crees que alguna vez salga un p2p por un protocolo "no confiable"?
Recuerda que UDP no garantiza que el paquete llegue de un lado a otro...

Segun recuerdo es confiable, solo que no es orientado a coneccion.
Por otro lado es mucho mas complicado shapear udp ya que no tiene los
mismos mecanismos que tcp, ya que no hay conección, como decíamos antes.
Asi googleando rapido, ya que no me acuerdo donde lei que ya había
algunos encontre
http://tecnologia.universia.es/tec/software/manolito.htm que usa udp
para compartir musica.

Post by Herr Groucho
Es buen enfoque, pero como se trata de mi red, mis máquinas, mi
enlace, no se trata de jugar a la policía de red, sino a poder usar
más provechosamente los recursos. Es decir: tienen que sacar un
sistema p2p que use UDP, que usarlo en mi red, tiene que molestarme
el ancho de banda que consuma, y tiene que molestarme aún más tener
que parar la descarga para hacer algo más urgente a velocidad
decente...

Era una sugerencia ya que lo que te és util hoy a vos puede serme util
mañana a otro, y las necesidades del otro pueden incluir la de controlar
udp, sin ir mas lejos se me ocurre por ejemplo el querer controlar la
VoIP que usa UDP ...

Saludos

Demian

[Alejandro Vargas]

Post by Demian Pecile
udp, sin ir mas lejos se me ocurre por ejemplo el querer controlar la
VoIP que usa UDP ...

Justamente ese es un caso interesante: la voip no necesita muchísimo
ancho de banda. Según el codec con 2kbits o con 8kbits o 64kbits
pueden ser suficientes. Es más, la pérdida de unos cuantos paquetes no
es muy molesta. PERO, lo importante es que tenga poca latencia. No
podés encolarlo por mucho tiempo. De hecho, es preferible que los
paquetes directamente se pierdan antes de que lleguen retrasados, por
eso se usa UDP y no TCP.

[Herr Groucho]

Post by Demian Pecile

Post by Herr Groucho

Post by Demian Pecile

Post by Herr Groucho

Post by Alejandro Vargas
Lo que yo veo en todos estos frontends para configurar
tc, es que al final se vuelven tan complicados como
escribir las reglas de TC a mano. Lo que está haciendo
falta es algo más descriptivo. O sea, algo donde
planteés la situación que tenés y qué querés hacer y el
frontend se encargue de decidir las reglas. Algo así
como decirle: tengo un servidor web en tal dirección, un
usuario con tal prioridad en tal parte, y quiero que el
bit torrent tenga tal ancho de banda. Si hay que
invertir cosas, porque la dirección del servidor web
corresponde con la del equipo que hace de router, que
sea el frontend el que se encargue de hacerlo.

Bueno, el primer paso entonces es enunciar
descriptivamente los requisitos.
Veamos los requisitos para un servidor hogareño como el
mío, que también es servidor de algunas cosas para afuera
y de varias más para adentro.

[muchas reglas]

Post by Demian Pecile

Post by Herr Groucho
Quién es el valiente que responde con las reglas que
implementan ese comportamiento?
(generadas a mano o con htb-gen)

Ojo que mañana te sacan un p2p por udp y te complican, yo
diria de tratar al udp como bueno si conocido, chatarra si
desconocido ... tipo 53 (dns), 27015 (CS), etc...

Crees que alguna vez salga un p2p por un protocolo "no
confiable"? Recuerda que UDP no garantiza que el paquete llegue
de un lado a otro...

Segun recuerdo es confiable, solo que no es orientado a coneccion.

No, no es confiable. Si querés confiabilidad la tenés que implementar
vos por encima de UDP.

Post by Demian Pecile
Por otro lado es mucho mas complicado shapear udp ya que no tiene
los mismos mecanismos que tcp, ya que no hay conección, como
decíamos antes. Asi googleando rapido, ya que no me acuerdo donde
lei que ya había algunos encontre
http://tecnologia.universia.es/tec/software/manolito.htm que usa
udp para compartir musica.

Ok, por suerte no lo uso, así que no me preocupa. Recuerden: no busco
ser ser policía de mí mismo; busco mejorar la percepción de calidad
de servicio.

Post by Demian Pecile

Post by Herr Groucho
Es buen enfoque, pero como se trata de mi red, mis máquinas,
mi enlace, no se trata de jugar a la policía de red, sino a poder
usar más provechosamente los recursos. Es decir: tienen que sacar
un sistema p2p que use UDP, que usarlo en mi red, tiene que
molestarme el ancho de banda que consuma, y tiene que molestarme
aún más tener que parar la descarga para hacer algo más urgente a
velocidad decente...

Era una sugerencia ya que lo que te és util hoy a vos puede serme
util mañana a otro, y las necesidades del otro pueden incluir la de
controlar udp, sin ir mas lejos se me ocurre por ejemplo el querer
controlar la VoIP que usa UDP ...

Bueno, servite escribir un conjunto de especificaciones mejores.

[Alejandro Vargas]

Post by Boris Quiroz
Crees que alguna vez salga un p2p por un protocolo "no confiable"?
Recuerda que UDP no garantiza que el paquete llegue de un lado a otro...

No importa, igual se usa. Simplemente armas por udp tu propio
protocolo de verificación de llegada de los paquetes. Es más engorroso
pero el UDP se está usando muchísimo justamente proque es más fácil
saltarse los firewalls.

Fijate Skype, que funciona casi en cualquier situación y permite
conexiones de cliente a cliente incluso cuando ambos estan detras de
NAT. El truco es usar paquetes UDP. Ambos clientes se ponen a mandar
paquetes al otro y cada router piensa que los paquetes entrantes son
respuestas a los paquetes salientes por eso los manda a donde
corresponde.

[m***@yahoo.com.ar]

El Jueves, 21 de Junio de 2007 08:16, Alejandro

El 21/06/07, Luciano Ruete

Otra opción más barata:

En realidad se me vienen dos a la mente (en ningún
orden en particular):

0) Le filtrás los puertos P2P al c*r*j*, e instalás un
proxy socks que limite entrada y salida, para uso de
esta gente que necesite P2P.

1) Otra: metés todo el tráfico P2P por una placa
virtual (hay algo de eso en mensajes anteriores de
hace uno o dos meses, creo que de un thread de traffic
shaping justamente), y dejás que los que usan P2P se
maten entre ellos y dejen andar al resto. La placa
"virtual" era un módulo del kernel que ahora no
recuerdo, y que podés especificarle el ancho de banda
entrante Y saliente máximo (de hecho la discusión en
el thread era porque no podías especificar entrada y
salida asimétrica, si decías por ej. 64 kbps era tanto
para subida como para bajada).

--
Matonga


__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[m***@yahoo.com.ar]

Post by m***@yahoo.com.ar

El Jueves, 21 de Junio de 2007 08:16, Alejandro

El 21/06/07, Luciano Ruete

(...)
1) Otra: metés todo el tráfico P2P por una placa
virtual (hay algo de eso en mensajes anteriores de
hace uno o dos meses, creo que de un thread de
traffic shaping justamente),

¡No encuentro los mensajes! Pero hay unos del 2002,
donde se habla del módulo "shaper":

http://www.lugmen.org.ar/pipermail/lug-list/2002-December/019749.html

--
Matonga



__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Alejandro Vargas]

Post by m***@yahoo.com.ar
1) Otra: metés todo el tráfico P2P por una placa
virtual (hay algo de eso en mensajes anteriores de
hace uno o dos meses, creo que de un thread de traffic
shaping justamente), y dejás que los que usan P2P se
maten entre ellos y dejen andar al resto. La placa
"virtual" era un módulo del kernel que ahora no
recuerdo, y que podés especificarle el ancho de banda
entrante Y saliente máximo (de hecho la discusión en
el thread era porque no podías especificar entrada y
salida asimétrica, si decías por ej. 64 kbps era tanto
para subida como para bajada).

Es una solución funcional pero un poco tosca. Si nadie está usando el
ancho de banda, no hay motivo para no prestárselo a los P2P. La cosa
es que en el momento que alguien quiera mirar una página web, él tenga
prioridad y ni se entere de que hasta hace 5 segundos el ancho de
banda estaba totalmente ocupado por P2P.

[Herr Groucho]

Post by m***@yahoo.com.ar

El Jueves, 21 de Junio de 2007 08:16, Alejandro

El 21/06/07, Luciano Ruete

En realidad se me vienen dos a la mente (en ningún
0) Le filtrás los puertos P2P al c*r*j*, e instalás un
proxy socks que limite entrada y salida, para uso de
esta gente que necesite P2P.

Muy bien, dame una lista infalible de puertos p2p. :-)
Además odio los proxies y complicar las cosas.

Post by m***@yahoo.com.ar
1) Otra: metés todo el tráfico P2P por una placa
virtual (hay algo de eso en mensajes anteriores de
hace uno o dos meses, creo que de un thread de traffic
shaping justamente), y dejás que los que usan P2P se
maten entre ellos y dejen andar al resto. La placa
"virtual" era un módulo del kernel que ahora no
recuerdo, y que podés especificarle el ancho de banda
entrante Y saliente máximo (de hecho la discusión en
el thread era porque no podías especificar entrada y
salida asimétrica, si decías por ej. 64 kbps era tanto
para subida como para bajada).

Ahh.. Algo me dijo Luciano, pero me vendió mal el concepto y concluí
que era una forma horrible de hacer las cosas... Viéndolo como una
placa de red virtual con capacidad de definirme el through put
entrante y saliente, no suena para nada horrible!

[Alejandro Vargas]

Post by Herr Groucho
Muy bien, dame una lista infalible de puertos p2p. :-)
Además odio los proxies y complicar las cosas.

Las reglas para detectar los p2p pueden ser muchas y muy variadas. Tal
vez requiera l7filter. Lo interesante sería que fuera fácilmente
actualizable. Cuando alguien descubre una manera mejor de detectar los
P2P o una manera de detectar algún P2P nuevo que hayan sacado (por
ejemplo ahora Pando), podría aportarla al proyecto y después de
evaluarse podría ponerse en internet para que el programa la
descargara automáticamente o previa autorización del administrador.

Lo importante es que no haga falta actualizar todo el software para
tener nuevos tipos de filtros.

[m***@yahoo.com.ar]

Post by Alejandro Vargas

Post by Herr Groucho
Muy bien, dame una lista infalible de puertos p2p.

:-)

Post by Herr Groucho
Además odio los proxies y complicar las cosas.

Las reglas para detectar los p2p pueden ser muchas y
muy variadas. Tal
vez requiera l7filter. Lo interesante sería que
fuera fácilmente
actualizable. Cuando alguien descubre una manera
mejor de detectar los
P2P o una manera de detectar algún P2P nuevo que
hayan sacado (por
ejemplo ahora Pando), podría aportarla al proyecto y
después de
evaluarse podría ponerse en internet para que el
programa la
descargara automáticamente o previa autorización del
administrador.
Lo importante es que no haga falta actualizar todo
el software para
tener nuevos tipos de filtros.

eMule soporta conexiones cifradas. Si bien dice que es
"para mayor seguridad", en realidad (y te lo insinúan
en la misma documentación) es para que los firewalls y
sistemas de control de tráfico no puedan reconocer el
tráfico de la mula.

-
Matonga






__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[xWin2]

Post by m***@yahoo.com.ar
eMule soporta conexiones cifradas. Si bien dice que es
"para mayor seguridad", en realidad (y te lo insinúan
en la misma documentación) es para que los firewalls y
sistemas de control de tráfico no puedan reconocer el
tráfico de la mula.

Y BitTorrent también lo soporta, y yo lo he visto funcionar pasando a
través de un firewall con filtro de layer7 activado, aunque parece que
ya viene un firewall por hardware que también puede limitar el protocolo
de BitTorrent encriptado...

[Alejandro Vargas]

Post by xWin2
Y BitTorrent también lo soporta, y yo lo he visto funcionar pasando a
través de un firewall con filtro de layer7 activado, aunque parece que
ya viene un firewall por hardware que también puede limitar el protocolo
de BitTorrent encriptado...

Bueno, un firewall "por hardware" es más bien un firewall al que no le
podés cambiar el software. Actualmente todo se hace por software,
incluso las cosas que deberían hacerse por hardware (como un modem).
Así que si ese firewall "por hardware" tiene "el secreto" para filtrar
los paquetes de bit torrent encriptados, eventualmente alguien hará lo
mismo con software libre.

[xWin2]

Post by Alejandro Vargas
Bueno, un firewall "por hardware" es más bien un firewall al que no le
podés cambiar el software. Actualmente todo se hace por software,
incluso las cosas que deberían hacerse por hardware (como un modem).
Así que si ese firewall "por hardware" tiene "el secreto" para filtrar
los paquetes de bit torrent encriptados, eventualmente alguien hará lo
mismo con software libre.

Exacto!, pero hasta el momento no he visto nada por layer7 u open
source... :(

Habrá que esperar un poco más... :)

[redondos]

Post by xWin2

Post by Alejandro Vargas
Bueno, un firewall "por hardware" es más bien un firewall al que no le
podés cambiar el software. Actualmente todo se hace por software,
incluso las cosas que deberían hacerse por hardware (como un modem).
Así que si ese firewall "por hardware" tiene "el secreto" para filtrar
los paquetes de bit torrent encriptados, eventualmente alguien hará lo
mismo con software libre.

Exacto!, pero hasta el momento no he visto nada por layer7 u open
source... :(

Para netfilter/iptables, l7 filter:

[1] http://l7-filter.sourceforge.net/

[Luciano Ruete]

Post by redondos

Post by xWin2

Post by Alejandro Vargas
Bueno, un firewall "por hardware" es más bien un firewall al que no le
podés cambiar el software. Actualmente todo se hace por software,
incluso las cosas que deberían hacerse por hardware (como un modem).
Así que si ese firewall "por hardware" tiene "el secreto" para filtrar
los paquetes de bit torrent encriptados, eventualmente alguien hará lo
mismo con software libre.

Exacto!, pero hasta el momento no he visto nada por layer7 u open
source... :(

[1] http://l7-filter.sourceforge.net/

tambien dentro de netfilter esta ipp2p

[Luciano Ruete]

Post by redondos

Post by xWin2

Post by Alejandro Vargas
Bueno, un firewall "por hardware" es más bien un firewall al que no le
podés cambiar el software. Actualmente todo se hace por software,
incluso las cosas que deberían hacerse por hardware (como un modem).
Así que si ese firewall "por hardware" tiene "el secreto" para filtrar
los paquetes de bit torrent encriptados, eventualmente alguien hará lo
mismo con software libre.

Exacto!, pero hasta el momento no he visto nada por layer7 u open
source... :(

[1] http://l7-filter.sourceforge.net/

Tambien dentro de netfilter esta ipp2p[2], si bien el autor se canso un poco
(la ultima release fue hace 10 meses), lo tengo en producción en un par de
servers y funciona muy bien: es efectivo y performante.
Falla en los protocolos encryptados al igual que l7.

ipp2p lo he usado en empresas donde quieren directamente _bloquear_
p2p(obviamente con algunas gerenciales excepciones) y los empleados que
pueden llegar a usar p2p encriptados son infimos o nulos.

Si lo que se busca es _controlar_ p2p por experiencia(hago sysadmin en 2
small/medium isps) es imposible estar al día en saber lo que efectivamente
_es_ p2p.
El enfoque que mejor me funcionó es mucho más simple como efectivo:
-determinar que cosas _no_ son p2p y darles prioridad
-darle menor prioridad(y opcionalmente menor ancho de banda) al resto del
trafico, p2p cae aca adentro.

Es muy facil ir agregando nuevos protocolos a la lista de prioritarios y se
obtienen muy buenos resultados, lo que tiene que andar bien funciona
bien(htb-gen funciona así).

Por ultimo, si se convinan los 2 esquemas: defino prio y junk y le sumo al
junk ipp2p/l7, tengo algo que es casi infalible.


[2]http://www.ipp2p.org/

[xWin2]

Post by redondos

Post by xWin2

Post by Alejandro Vargas
Bueno, un firewall "por hardware" es más bien un firewall al que no le
podés cambiar el software. Actualmente todo se hace por software,
incluso las cosas que deberían hacerse por hardware (como un modem).
Así que si ese firewall "por hardware" tiene "el secreto" para filtrar
los paquetes de bit torrent encriptados, eventualmente alguien hará lo
mismo con software libre.

Exacto!, pero hasta el momento no he visto nada por layer7 u open
source... :(

[1] http://l7-filter.sourceforge.net/

Pero l7 filter me parece que todavía no detecta los P2P encriptados, por
eso puse que habrá que esperar un poco más...

En la página http://l7-filter.sourceforge.net/protocols, en la parte de
BitTorrent dice esto:

Note: Some Bittorrent clients are starting to implement end-to-end
encryption which may make it very difficult to use the methods below to
identify their traffic. The recent development of the Message Stream
Encryption protocol is specifically designed to avoid any packet
classification by ensuring no signature bytes are sent in the header.

[m***@yahoo.com.ar]

Post by xWin2

Post by xWin2
Y BitTorrent también lo soporta, y yo lo he visto

funcionar pasando a

Post by xWin2
través de un firewall con filtro de layer7

activado, aunque parece que

Post by xWin2
ya viene un firewall por hardware que también

puede limitar el protocolo

Post by xWin2
de BitTorrent encriptado...

Bueno, un firewall "por hardware" es más bien un
firewall al que no le
podés cambiar el software. Actualmente todo se hace
por software,
incluso las cosas que deberían hacerse por hardware
(como un modem).
Así que si ese firewall "por hardware" tiene "el
secreto" para filtrar
los paquetes de bit torrent encriptados,
eventualmente alguien hará lo
mismo con software libre.

Convengamos que hoy en día, "por hardware" más bien
uno debe entender "por firmware", ya que generalmente
es un micro tipo Actions o ARM, corriendo un firmware
guardado en ROM o Flash.

--
Matonga


__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Alejandro Vargas]

Post by m***@yahoo.com.ar
Convengamos que hoy en día, "por hardware" más bien
uno debe entender "por firmware", ya que generalmente
es un micro tipo Actions o ARM, corriendo un firmware
guardado en ROM o Flash.

Si, y hay que recordar que últimamente hay montones de equipos incluso
de marcas más o menos conocidas que usan al menos un núcleo de linux.
El otro dia me sorprendió que una cámara web de esas que se acceden
por red, marca sony, tiene un linux. Miren:

# nmap -O 192.168.100.188

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2007-06-30 23:13 CEST
Interesting ports on 192.168.100.188:
(The 1662 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
8081/tcp open blackice-icecap
MAC Address: 00:01:4A:0C:A7:54 (Sony)
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20
Uptime 10.418 days (since Wed Jun 20 13:12:08 2007)

Nmap finished: 1 IP address (1 host up) scanned in 4.862 seconds

A demás de esto, el router ADSL que me mandaron cuando puse el ADSL2+
tiene también un linux adentro (y la configuración por página web
soporta QOS, y prioridades no sólo a nivel IP sino por cada puerto del
router. Tiene 4 puertos ehternet pero el router parece que los ve como
4 placas etherhet. De hecho, estan juntadas en un bridge pero se las
puede aislar. Miren esto:

-> sh


BusyBox v1.00 (2005.11.02-03:32+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

# cat /proc/cpuinfo
system type : 96348GW-11
processor : 0
cpu model : BCM6348 V0.7
BogoMIPS : 254.77
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available

[xWin2]

Post by Alejandro Vargas
A demás de esto, el router ADSL que me mandaron cuando puse el ADSL2+

Te hago una pregunta OT, en que zona pusiste ADSL2+, ya está disponible
en Mendoza?

Gracias!

[Herr Groucho]

Post by xWin2

Post by Alejandro Vargas
A demás de esto, el router ADSL que me mandaron cuando puse el ADSL2+

Te hago una pregunta OT, en que zona pusiste ADSL2+, ya está
disponible en Mendoza?

Él vive en León...

[redondos]

Post by Herr Groucho

Post by xWin2

Post by Alejandro Vargas
A demás de esto, el router ADSL que me mandaron cuando puse el ADSL2+

Te hago una pregunta OT, en que zona pusiste ADSL2+, ya está
disponible en Mendoza?

Él vive en León...

...que es una ciudad española. (jeez! :))

[Alejandro Vargas]

Post by xWin2
Te hago una pregunta OT, en que zona pusiste ADSL2+, ya está disponible
en Mendoza?

:) Estubo disponible en mi zona cuando Jazztel llegó a la central del
crucero, hace varios meses. :P

[Alfredo Rezinovsky]

Post by Herr Groucho

Post by m***@yahoo.com.ar

El Jueves, 21 de Junio de 2007 08:16, Alejandro

El 21/06/07, Luciano Ruete

En realidad se me vienen dos a la mente (en ningún
0) Le filtrás los puertos P2P al c*r*j*, e instalás un
proxy socks que limite entrada y salida, para uso de
esta gente que necesite P2P.

Muy bien, dame una lista infalible de puertos p2p. :-)
Además odio los proxies y complicar las cosas.

A mi me esta funcionando bien identificando puertos de protocolos
conocidos. y limitando el resto. No es infalible pero funciona.

[Alejandro Vargas]

Post by Alfredo Rezinovsky

Post by Herr Groucho
Muy bien, dame una lista infalible de puertos p2p. :-)
Además odio los proxies y complicar las cosas.

A mi me esta funcionando bien identificando puertos de protocolos
conocidos. y limitando el resto. No es infalible pero funciona.

Pero hay protocolos que no usan puertos fijos. El ftp activo, por
ejemplo. Supongo que eso lo solucionas marcando los paquetes con el
helper de ftp de iptables. El otras cosas como el sip, o el skype creo
que también usan técnicas parecidas: usan un puerto conocido para los
"trámites" y elijen un puerto nuevo para la transferencia de datos
"pesada".

[Alejandro Vargas]

Post by Demian Pecile
Ojo que mañana te sacan un p2p por udp y te complican, yo diria de
tratar al udp como bueno si conocido, chatarra si desconocido ...
tipo 53 (dns), 27015 (CS), etc...

Que yo sepa, los P2P ya usan UDP.

El problema puede venir en protocolos que te interesa priorizar pero
que no necesariamente usan un puerto determinado, como voz sobre IP o
videoconferencias. En ese caso probablemente ser haría necesario un
módulo helper de nat capaz de detectar el inicio de la conexión y
entender el protocolo para seguirle el hilo y determinar cuáles son
los puertos que va a usar.

[Alejandro Vargas]

Post by Herr Groucho
Reglas para el tráfico que no se enruta a través de esta máquina, sino

Yo pondría algo directamente una pantalla especial para la máquina
local (puerto origen, puerto destino, orden de prioridad, ancho de
banda minimo y maximo)

Post by Herr Groucho
0) El tráfico originado en una máquina accesible a través de <eth0> y
terminado en esta máquina, así como el tráfico originado en esta
máquina y terminado en una máquina accesible a través de <eth0> no
está sujeto a restricciones ni priorización. (Vista desde la red
interna, esta máquina está tan libre de restricciones como entre sí
lo están las demás máquinas de la red interna).

Me suena complicado. Podría ser separarlo por placas. Algo así como:
restricciones de ancho de banda para la placa eth0: y ahí por un lado
el tráfico locales y por otro el tráfico ruteado. Así para cada placa
de red.

Post by Herr Groucho
- Es prioritario el tráfico de paquetes menores a 100 bytes
(No queremos molestar a TCP cagándole sus ACKs, etc.)

Es una buena idea mientras no le de a los que hacen programas P2P por
mandar todos paquetes chiquititos para engañar a eso también.

Post by Herr Groucho
- Es prioritario el tráfico ICMP
(No queremos cagarle nada al protocolo de control de Internet)
- Es prioritario el tráfico UDP
(El DNS tiene que andar bien)

Para no preguntar demasiadas cosas lo bueno sería que se activara todo
esto junto con una sola opcion y que estubiera por defecto, tal vez
habiendo un botón de "avanzado" que permita cambiar individualmente
los valores. En realidad, yo creo que esto es deseable siempre así que
casi nadie lo tocaría. No se a quien pueda interesarle no priorizar el
DNS, por ejemplo.

Post by Herr Groucho
- Es prioritario el tráfico TCP perteneciente o relacionado a
conexiones originadas en esta máquina y dirigidas a los puertos
<ssh, ftp, http, smtp, pop3, pop3s, imaps, imaps, xmpp, xmpps>. Esta
lista es igual a la que se menciona en la regla 2.

Me parece que con tantas opciones se vuelve a complicar. Pienso que
tal vez sería más práctico algo así como una lista ya predefinida
donde podamos cambiar las propiedades. Esa lista podría ser editable
mediante configuraciones avanzadas o incluso podría ser descargable
automáticamente desde algún servidor en internet.

Te cuento un ejemplo: mi receptor de satélite tiene (obviamente) una
manera de escanear los canales que transmiten y armar una lista. Pero
esa lista, como te imaginarás, es de miles de canales. Para no tener
una lista tan larga, permite armar paquetes y moverte fácilmente por
esas listas. Pero el hecho de armar esos paquetes es engorroso (ir
mirando qué hay y agregar uno a uno los canales que te interesan,
después agruparlos por categorías (documentales, películas, series,
infantiles, noticias, etc.). Pero la cosa cambia mucho cuando le das a
"descargar" y te bajas unas cuantas listas que la gente ya haya
preparado. Después personalizarla a tu gusto ya no cuesta nada.

Post by Herr Groucho
El tráfico prioritario tendrá disponible entre el <100%> y el <90%>

No te olvides de que nunca hay que asignar el 100% del ancho de banda
de la interfaz entrante. Perderás un poquitito pero evitás que los
paquetes entrantes sean encolados por el proveedor. De esa forma, si
hay una cola esta se forma en tu maquina y podés controlar el órden en
que se da paso a los paquetes. Si se arma una cola en el proveedor ya
no podrás priorizar el ssh por ejemplo.

Dice el libro del LARTC que los proveedores suelen tener colas grandes
porque eso mejora el uso del ancho de banda para ellos, pero en
nuestro caso no nos interesa porque queremos tener control sobre esa
cola.
Cosa muy probable, ya que el router es la máquina chica (que consume
poco) que siempre está funcionando, así que es el lugar más lógico
para poner un mldonkey.

Post by Herr Groucho
- no repercute negativamente en la experiencia de usuario al usar
la web, el mail, la mensajería instantánea, etc. desde la red
interna.

Bueno, se me ocurre que sería interesante facilitar aún más las cosas
para el usaurio. Preguntarle sólo qué servicios locales se corren y
cuál es el ancho de banda de subida y bajada y que "algo" genere
automáticamente las reglas más recomendables para ese caso. De hecho,
ese "algo" podría estar en internet o depender de algo que se pueda
descargar automáticamente desde internet para así poder ir mejorando
la cosa sin tener que actualizar software.

El programa también podría hacer una pureba para adivinar por sí mismo
el ancho de banda de la línea. Lo que tendría que hacer sería
suspender temporalmente el ruteo y los servicios locales y probar una
descarga y un envío a uno o más servidores en internet y medir el
ancho de banda conseguido.

Post by Herr Groucho
- Si me pongo a bajar descontroladamente en el servidor y en 2 de las
máquinas de la red interna, cada una de esas 3 puede gozar de
aproximadamente 1/3 del ancho de banda del enlace.
- Si pongo una cuarta máquina máquina a bajar, se reacomoda todo y
las cuatro disfrutan de 1/4 del ancho de banda del enlace a
Internet.

También sería interesante poder asignar a alguna máquina, mediante IP
o mediante MAC, una prioridad especial para la máquina del jefe.

Ya cosas más avanzadas podrían ser asignar los anchos de banda por
grupos de máquinas. Eso te permitiría, en una empresa, meter en el
mismo grupo a los que estan en la misma oficina. Así si se quejan de
que está lento, pueden mirar a su alrededor para encontrar al culpable
y nadie puede molestar a otro de otra oficina.

Post by Herr Groucho
Quién es el valiente que responde con las reglas que implementan ese
comportamiento?

Yo creo que esto es más que nada cosa de paciencia. Si está orientado
a una interfaz de usuario, primero habría que diseñar esa interfaz.
Planteados exactamente cuáles son los datos de que disponemos la cosa
es leer el LARTC y probar hasta que salga. Probablemente llegarás a
reglas complicadas pero la idea es tener que hacerlo una sola vez.

[Herr Groucho]

Post by Alejandro Vargas

Post by Herr Groucho
Reglas para el tráfico que no se enruta a través de esta máquina,

Yo pondría algo directamente una pantalla especial para la máquina
local (puerto origen, puerto destino, orden de prioridad, ancho de
banda minimo y maximo)

Post by Herr Groucho
0) El tráfico originado en una máquina accesible a través de
<eth0> y terminado en esta máquina, así como el tráfico originado
en esta máquina y terminado en una máquina accesible a través de
<eth0> no está sujeto a restricciones ni priorización. (Vista
desde la red interna, esta máquina está tan libre de
restricciones como entre sí lo están las demás máquinas de la red
interna).

Me suena complicado. Podría ser separarlo por placas. Algo así
como: restricciones de ancho de banda para la placa eth0: y ahí por
un lado el tráfico locales y por otro el tráfico ruteado. Así para
cada placa de red.

No estoy diseñando tu programa de configuración de traffic shaping:
estoy explicando cuáles son las reglas que quiero para mí.

Post by Alejandro Vargas

Post by Herr Groucho
- Es prioritario el tráfico de paquetes menores a 100 bytes
(No queremos molestar a TCP cagándole sus ACKs, etc.)

Es una buena idea mientras no le de a los que hacen programas P2P
por mandar todos paquetes chiquititos para engañar a eso también.

Que lo hagan, no me interesa. Sería ridículamente ineficiente y nadie
usaría ese sistema p2p tan lento...

Post by Alejandro Vargas

Post by Herr Groucho
- Es prioritario el tráfico ICMP
(No queremos cagarle nada al protocolo de control de Internet)
- Es prioritario el tráfico UDP
(El DNS tiene que andar bien)

Para no preguntar demasiadas cosas lo bueno sería que se activara
todo esto junto con una sola opcion y que estubiera por defecto,
tal vez habiendo un botón de "avanzado" que permita cambiar
individualmente los valores. En realidad, yo creo que esto es
deseable siempre así que casi nadie lo tocaría. No se a quien pueda
interesarle no priorizar el DNS, por ejemplo.

Pero hay que saber qué hace el botón mágico ese.

Post by Alejandro Vargas

Post by Herr Groucho
- Es prioritario el tráfico TCP perteneciente o relacionado a
conexiones originadas en esta máquina y dirigidas a los puertos
<ssh, ftp, http, smtp, pop3, pop3s, imaps, imaps, xmpp, xmpps>.
Esta lista es igual a la que se menciona en la regla 2.

Me parece que con tantas opciones se vuelve a complicar. Pienso que
tal vez sería más práctico algo así como una lista ya predefinida
donde podamos cambiar las propiedades.

Y quién predefinió la lista?

Post by Alejandro Vargas
Esa lista podría ser
editable mediante configuraciones avanzadas o incluso podría ser
descargable automáticamente desde algún servidor en internet.

Whatever. Quiero ese comportamiento!

Post by Alejandro Vargas

Post by Herr Groucho
El tráfico prioritario tendrá disponible entre el <100%> y el <90%>

No te olvides de que nunca hay que asignar el 100% del ancho de
banda de la interfaz entrante.

Si no hay nada más que tráfico prioritario presente, quiero que el
traáfico prioritario use todo el ancho de banda disponible!

Post by Alejandro Vargas
Perderás un poquitito pero evitás
que los paquetes entrantes sean encolados por el proveedor.

Mirá... sin traffic shaping activado, todo el tráfico tiene el 100%
del ancho de banda disponible, así no tiene que ser problema.
Además recordá que al tráfico no prioritario le asigné un mínimo
garantizado de 10% de la capacidad del enlace, pero no quiere decir
eso que el tráfico prioritario sólo puede usar hasta el 90% del
enlace: en ausencia de tráfico no prioritario, el tráfico prooritario
debe poder usar el 100% del enlace.

Post by Alejandro Vargas
De esa
forma, si hay una cola esta se forma en tu maquina y podés
controlar el órden en que se da paso a los paquetes. Si se arma una
cola en el proveedor ya no podrás priorizar el ssh por ejemplo.

No tiene por que armarse cola en el ISP, si el tráfico prioritario
tiene garantizado el 90% del enlace y el no prioritario tiene
garantizado el 10% del enlace.
Tal vez no fui explícito antes: dije que el tráfico prioritario podía
usar entre el 90% y el 100% del enlace, pero queda más claro diciendo
que se le garantiza el 90% del enlace.
Pero esos valores son míminos garantizados. Si hay más ancho de banda
disponible, tanto el tráfico prioritario como el no prioritario
tienen que poder usarlo, hasta saturar el enlace.

Post by Alejandro Vargas
Cosa muy probable, ya que el router es la máquina chica (que
consume poco) que siempre está funcionando, así que es el lugar más
lógico para poner un mldonkey.

Efectivamente y así es como lo uso, solo que no estoy todo el tiempo
compartiendo cosas, sino de vez en cuando...

Post by Alejandro Vargas

Post by Herr Groucho
- no repercute negativamente en la experiencia de usuario al
usar la web, el mail, la mensajería instantánea, etc. desde la
red interna.

Bueno, se me ocurre que sería interesante facilitar aún más las
cosas para el usaurio. Preguntarle sólo qué servicios locales se
corren y cuál es el ancho de banda de subida y bajada y que "algo"
genere automáticamente las reglas más recomendables para ese caso.

Vos hacé ese algo! Yo estoy hablando de lo que ese algo termine
haciendo cuando se le pida que haga feliz al usuario!

Post by Alejandro Vargas
De hecho, ese "algo" podría estar en internet o depender de algo
que se pueda descargar automáticamente desde internet para así
poder ir mejorando la cosa sin tener que actualizar software.

Aburrido!

Post by Alejandro Vargas
El programa también podría hacer una pureba para adivinar por sí
mismo el ancho de banda de la línea. Lo que tendría que hacer sería
suspender temporalmente el ruteo y los servicios locales y probar
una descarga y un envío a uno o más servidores en internet y medir
el ancho de banda conseguido.

Ni en pedo dejo a un programa apagarme servicios!

Post by Alejandro Vargas

Post by Herr Groucho
- Si me pongo a bajar descontroladamente en el servidor y en 2 de
las máquinas de la red interna, cada una de esas 3 puede gozar de
aproximadamente 1/3 del ancho de banda del enlace.
- Si pongo una cuarta máquina máquina a bajar, se reacomoda
todo y las cuatro disfrutan de 1/4 del ancho de banda del enlace
a Internet.

También sería interesante poder asignar a alguna máquina, mediante
IP o mediante MAC, una prioridad especial para la máquina del jefe.

No, eso no me interesa. Que las cosas sean simples, todos iguales.

Post by Alejandro Vargas

Post by Herr Groucho
Quién es el valiente que responde con las reglas que implementan
ese comportamiento?

Yo creo que esto es más que nada cosa de paciencia. Si está
orientado a una interfaz de usuario, primero habría que diseñar esa
interfaz.

No. Primero díganme si las condiciones que plateé tienen sentido.
Luego escriban por mí a mano o como les guste las reglas que
implementen esas restricciones. Luego las pruebo y valido. Luego, si
tenés ganas escribís tu GUI.

Post by Alejandro Vargas
Planteados exactamente cuáles son los datos de que
disponemos la cosa es leer el LARTC y probar hasta que salga.

Ese era el desfío!

[Alejandro Vargas]

Post by Herr Groucho
No tiene por que armarse cola en el ISP, si el tráfico prioritario
tiene garantizado el 90% del enlace y el no prioritario tiene
garantizado el 10% del enlace.

Si tu enlace es ligeramente más lento por cualqueir motivo (incluso
lentitud de tu CPU, ruido en la línea, etc), se armará una cola del
lado del proveedor. Por eso en el LARTC recomienda nunca tratar de
aprovechar el 100%. Una pequeña pérdida de velocidad puede
significarte una gran ganancia en interactividad (ssh, telnet, dns,
etc.).

Post by Herr Groucho

Post by Alejandro Vargas
Bueno, se me ocurre que sería interesante facilitar aún más las
cosas para el usaurio. Preguntarle sólo qué servicios locales se
corren y cuál es el ancho de banda de subida y bajada y que "algo"
genere automáticamente las reglas más recomendables para ese caso.

Vos hacé ese algo! Yo estoy hablando de lo que ese algo termine
haciendo cuando se le pida que haga feliz al usuario!

Ok, ok, esperate un poco. Me parece que primero habría que definir con
qué datos contamos para después poder preparar un programa que use
esos datos para generar reglas. No es que me anime a hacerlo porque he
tocado poco del asunto, pero creo que entre todos podríamos pensar en
algo.

Post by Herr Groucho

Post by Alejandro Vargas
De hecho, ese "algo" podría estar en internet o depender de algo
que se pueda descargar automáticamente desde internet para así
poder ir mejorando la cosa sin tener que actualizar software.

Aburrido!

Bueno, si no querés aburrirte ponete vos a definier esas reglas y
ponerlas en internet en lugar de ser un simple usuario.

Post by Herr Groucho

Post by Alejandro Vargas
El programa también podría hacer una pureba para adivinar por sí
mismo el ancho de banda de la línea. Lo que tendría que hacer sería
suspender temporalmente el ruteo y los servicios locales y probar
una descarga y un envío a uno o más servidores en internet y medir
el ancho de banda conseguido.

Ni en pedo dejo a un programa apagarme servicios!

No dije apagarte los servicios. Dije solamente dropear TODO excepto
algún puerto en particular, preferentemente alguno que suela tener
prioridad para los proveedores, como el 80. Después hace una descarga
y un envío, mide los tiempos y vuelve a dejar todo como estaba.

Post by Herr Groucho

Post by Alejandro Vargas
También sería interesante poder asignar a alguna máquina, mediante
IP o mediante MAC, una prioridad especial para la máquina del jefe.

No, eso no me interesa. Que las cosas sean simples, todos iguales.

Pero... no te interesaría, por ejemplo que cuando estés en tu estación
de trabajo por ejemplo buscando algo en google, las cosas funcionaran
lo mejor posible?

Lo cual me recuerda que una de las cosas interesantes que puede hacer
SQUID es asignar ancho de banda en función del tamaño de la
transferencia. O sea, que si en una página web normalmente no hay nada
más grande de 100k (texto, imágenes, etc), cuando la transferencia
supera digamos los 150k, le da prioridad a los demás.

Post by Herr Groucho
No. Primero díganme si las condiciones que plateé tienen sentido.
Luego escriban por mí a mano o como les guste las reglas que
implementen esas restricciones. Luego las pruebo y valido. Luego, si
tenés ganas escribís tu GUI.

Creo que de esa manera deben haber nacido todos los frontends que hay
dando vueltas, y por eso son todos complicados (unos más y otros
menos).

Post by Herr Groucho

Post by Alejandro Vargas
Planteados exactamente cuáles son los datos de que
disponemos la cosa es leer el LARTC y probar hasta que salga.

Ese era el desfío!

Entonces no necesitás preguntar acá: copia lo que dice el LARTC y
probá como te ofrecías a hacer.

[Herr Groucho]

Post by Alejandro Vargas

Post by Herr Groucho
No tiene por que armarse cola en el ISP, si el tráfico
prioritario tiene garantizado el 90% del enlace y el no
prioritario tiene garantizado el 10% del enlace.

Si tu enlace es ligeramente más lento por cualqueir motivo (incluso
lentitud de tu CPU, ruido en la línea, etc), se armará una cola del
lado del proveedor. Por eso en el LARTC recomienda nunca tratar de
aprovechar el 100%. Una pequeña pérdida de velocidad puede
significarte una gran ganancia en interactividad (ssh, telnet, dns,
etc.).

Post by Herr Groucho

Post by Alejandro Vargas
Bueno, se me ocurre que sería interesante facilitar aún más las
cosas para el usaurio. Preguntarle sólo qué servicios locales
se corren y cuál es el ancho de banda de subida y bajada y que
"algo" genere automáticamente las reglas más recomendables para
ese caso.

Vos hacé ese algo! Yo estoy hablando de lo que ese algo termine
haciendo cuando se le pida que haga feliz al usuario!

Ok, ok, esperate un poco. Me parece que primero habría que definir
con qué datos contamos para después poder preparar un programa que
use esos datos para generar reglas. No es que me anime a hacerlo
porque he tocado poco del asunto, pero creo que entre todos
podríamos pensar en algo.

Post by Herr Groucho

Post by Alejandro Vargas
De hecho, ese "algo" podría estar en internet o depender de
algo que se pueda descargar automáticamente desde internet para
así poder ir mejorando la cosa sin tener que actualizar
software.

Aburrido!

Bueno, si no querés aburrirte ponete vos a definier esas reglas y
ponerlas en internet en lugar de ser un simple usuario.

Post by Herr Groucho

Post by Alejandro Vargas
El programa también podría hacer una pureba para adivinar por
sí mismo el ancho de banda de la línea. Lo que tendría que
hacer sería suspender temporalmente el ruteo y los servicios
locales y probar una descarga y un envío a uno o más servidores
en internet y medir el ancho de banda conseguido.

Ni en pedo dejo a un programa apagarme servicios!

No dije apagarte los servicios. Dije solamente dropear TODO excepto
algún puerto en particular, preferentemente alguno que suela tener
prioridad para los proveedores, como el 80. Después hace una
descarga y un envío, mide los tiempos y vuelve a dejar todo como
estaba.

Post by Herr Groucho

Post by Alejandro Vargas
También sería interesante poder asignar a alguna máquina,
mediante IP o mediante MAC, una prioridad especial para la
máquina del jefe.

No, eso no me interesa. Que las cosas sean simples, todos
iguales.

Pero... no te interesaría, por ejemplo que cuando estés en tu
estación de trabajo por ejemplo buscando algo en google, las cosas
funcionaran lo mejor posible?

Psss... "Lo mejor posible" en mi estación de trabajo sería que
desenchufara a todo el mundo al carajo y tuviera todo el enlace para
mí solo!
La ventaja de la distribución equitativa es que todo el mundo entiende
lo que está pasando: "ahh, somos tres giles usando Internet: lógico,
nos anda 3 veces más lento que cuando cada uno está solo...". Además
de que la explicación de las reglas en lenguaje natural es más
compacta y sencilla y por encima de todo, pienso que cuando las cosas
tienen excepciones y casos particulares y valores arbitrarios por
todos lados están feas y mal pensadas.
Entonces, dejame mis reglas simples!

Post by Alejandro Vargas
Entonces no necesitás preguntar acá: copia lo que dice el LARTC y
probá como te ofrecías a hacer.

Uff... Nadie me quiere consentir!

[Alejandro Vargas]

Post by Herr Groucho
Reglas para el tráfico que no se enruta a través de esta máquina, sino

Se me ocurre una solución un poco sucia pero si funciona no importa:
si cuesta tanto controlar el tráfico local y diferenciarlo del tráfico
ruteado, tal vez se podría meter el control en una máquina virtual
armada con user mode linux.

[Herr Groucho]

Post by Alejandro Vargas

Post by Herr Groucho
Reglas para el tráfico que no se enruta a través de esta máquina,

Se me ocurre una solución un poco sucia pero si funciona no

No comparto ese enfoque!

Post by Alejandro Vargas
si cuesta tanto controlar el tráfico local y diferenciarlo
del tráfico ruteado, tal vez se podría meter el control en una
máquina virtual armada con user mode linux.

Sí, lo pensé.