-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El Sáb 11 Ene 2003 22:00, Gustavo Muslera escribió:
El sáb, 11-01-2003 a las 17:46, Madieta escribió:
Buenas.
Tengo en casa un servidor SuSE 8.0 que, entre otras cosas, hace de gateway y firewall (con SuSEfirewall2) para mi pequeña red. Desde hace un tiempo comparto la conexión (ADSL 256 kbps bajada/128 kbps subida) con unos vecinos. Me gustaría saber si hay alguna manera de limitar el ancho de banda para no "pisarnos" los unos a los otros (sobretodo ellos a mi, ya que se pasan un poco bajando mp3). Ellos me pagan una tercera parte del coste mensual de la conexión, por lo que querría poder decirle al servidor algo así como: a la IP 192.168.1.51 dale como máximo una tercera parte del ancho (85 kbps bajada/42 kbps subida). Cómo podría hacer esto? Entre los HOWTOs que te incluye SuSE (o podes buscarlo en internet, quizas haya una version mas actualizada y/o en español del mismo) hay un "bandwidth limiting howto" que un poco responde a eso.
Quizás el Advanced Routing Howto, sección nueve, sea algo más general, pero creo que conviene conocer la base de las cosas, no?
En esencia, podes definirte delay pools en el Squid para regular cuanto ancho de banda le asignas a los que cumplen determinados criterios y se comunican via ese proxy. Por otro lado, podes definirte alguna estrategia de QoS para regular preferencia de salida de paquetes en base a subredes y cosas por el estilo.
Creo que lo segundo es lo más adecuado, pues no hace falta montar un proxy. Pero tal y como recomienda el howto antes citado, usar CBQ como disciplina de encolado es demasiado lioso para algo tan sencillo. Aviso que no tengo mucha idea, pero de nuevo basándome en el susodicho cómo, y usando TBF podría ser algo así (supongo que eth0 es router->internet) : #----------------------- # Esto es para el tráfico HACIA internet: # Creamos una disciplina PRIO en la raíz de disciplinas # Por defecto PRIO crea tres hijos, si queremos más usamos 'band <num>' # podemos ignorar 'priomap' porque asignamos filtros a las sub-qdiscs, ¿no? # No estoy seguro... tc qdisc add dev eth0 root handle 1: prio # A cada hijo le seguirá un Token Bucket Filter: (burst podría ser 500?) tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 42kbit latency 50ms burst 1000 tc qdisc add dev eth0 parent 1:2 handle 11: tbf rate 42kbit latency 50ms burst 1000 tc qdisc add dev eth0 parent 1:3 handle 12: tbf rate 42kbit latency 50ms burst 1000 # Ahora asignamos los filtros: (ips al azar) tc filter add dev eth0 protocol parent 10: ip prio 1 u32 match ip src 192.168.1.51/32 tc filter add dev eth0 protocol parent 11: ip prio 1 u32 match ip src 192.168.1.52/32 tc filter add dev eth0 protocol parent 12: ip prio 1 u32 match ip src 192.168.1.53/32 #----------------------- Escribir lo mismo para el tráfico en sentido inverso debería resultar obvio. Mmm, no tengo ni idea de si esto funcionaría, pero me encantaría oir algún comentario porque en breve tendré que montar algo así y me gustaría llegar con ello masticadete... ;-) ________________ Miguel de Benito. http://8027.org GPG Fingerprint: D5B5 5163 F3C5 E786 FDF4 D4BD 9C9A 9251 7D7D 5925 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+IOhxnJqSUX19WSURAmcwAJ4y+XZYwNrk7Ct1VwWiZHJzTIZufwCg47LN b2GgUW7gWOT63Ez90JMUQas= =cy7u -----END PGP SIGNATURE-----