-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El Viernes, 19 de Marzo de 2004 21:25, Saul Nova Barrueta escribió:
Ahora bien, hice un script (bien pedorro) hoy en la mañana donde uso htb, pero según yo tengo el mismo problema, o tengo algo muy similar. Empezaré con lo que deseo (algo muy sencillo para empezar). Quiero en x maquina o x red poder hacer un download desde http (80) a 10KBytes y un download de ftp (21,20) a 20KBytes, como estoy en una LAN (como prueba) monté un servidor http y un ftp en la misma caja linux, todo lo tengo conctado a un hub 3com de 10Mbps (el cual segun por pruebas que he hecho maximo me da 1MByte de transferencia). Tambien quiero tener un máximo de 50KBytes de conexión en total, asi que 10+20=30KBytes, y los 20KBytes los quiero para usarlos en otras cosas como conexión via VNC o correo y si no se usa kiero que esos 20KB restantes puedan ser usados por los ftp o http.
Mis comandos quedaron de la sig forma:
* Tu ejemplo incluye prioridades de un trafico sobre otro a la hora de asignar ancho de banda, doy por echo que la sintaxis es correcta, tendria que tirar de chuleta, asi que si en algun lado te pongo que verifiques la construccion de la regla, no lo des por echo por que hablo de memoria.
tc qdisc del dev eth1 root #Borro cualkier regla tc qdisc add dev eth1 root handle 1: htb default 20 #todo el trafico se va a la banda 20
* la cola padre propietaria de todo el ancho de banda
tc class add dev eth1 parent 1: classid 1:1 htb rate 50kbps ceil 50kbps
* la cola hija y que se encargara de repartir el excedente, segun prioridades, que la cola padre le asigne como disponible.
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 20kbps ceil 50kbps #este es el hijo con prio 0
* Esta banda tiene MAYOR prioridad que la siguiente y mayor ancho de banda MINIMO establecido y puede llegar a tener el total del ancho de banda, es decir, CONSUMIR EL TOTAL DEL ANCHO (ceil 50kbps)
tc class add dev eth1 parent 1:1 classid 1:20 htb rate 10kbps ceil 50kbps prio 1 #segun yo todo el trafico cae en esta banda, para postereiormente repartirse a la banda correspondiente, no se si esto este bien hecho o no
* Esta banda tiene MENOR prioridad que la anterior y menor ancho de banda MINIMO establecido, y puede tambien crecer hasta el total del ancho (ceil 50kbps) y es logicamente la que por defecto recibe el trafico "general" o no marcado por defecto ya que no es la que ostenta prioridad.
tc qdisc add dev eth1 parent 1:10 handle 10: sfq #asocio las candas con las colas sfq tc qdisc add dev eth1 parent 1:20 handle 20: sfq
* esto hara que el trafico que se produzca en cada banda, se le asigne un justo reparto, es decir si hay 5 conexiones ftp y 20 kbps se le asignaran a cada conexion 4 (notese en toda configuracion la disponibilidad de ancho de banda del servidor remoto). * Por seguir un orden cambio tu orden de reglas tc filter add dev eth0 protocol ip parent 1: handle 1 fw classid 1:10 * Me ha parecido ver en las reglas iptables y en la creacion de las colas y bandas que eth1 es la interfaz que comunica con interntet y no eth0, verifica esto, no obstante en este filtro se asocia la marca 1 a la banda 10, que recordemos es la que ostenta MAYOR PRIORIDAD y que en caso de existir trafico marcado prioritariamente sera premiado con ancho de banda, el trafico marcado como menor prioridad sera enviado a la banda con menor prioridad y penalizado en caso de no haber excedente a limitarse al minimo asignado, el restante, que es el de menor prioridad, la cola padre lo enviara a la banda 20, opcion default de la primera regla del arbol de bandas.
iptables -A FORWARD -o eth1 -i eth0 -p tcp --dport 20:21 -t mangle -j MARK --set-mark 1 #marco los paquetes para posteriormente asociarlos a su respactiva banda y que la banda se encargue de el
* Aqui parece que dice que eth1 es la interfaz de internet y eth0 la que conecta con la LAN, verifica que esto este en consonancia con los parametros empleados en la creacion del arbol de bandas, y el trafico cuyo destino sea el rango de puertos 20 al 21 sea marcado con 1, por accion del filtro fw antes comentado sera enviado a la banda PRIORITARIA 10 , y es el que sera premiado en caso de ser necesario y el que recibira el excedente (notese que la primera funcionalidad de las bandas es garantizar un minimo de ancho de banda a ciertas aplicaciones, protocolos, etc).
tc filter add dev eth0 protocol ip parent 1: handle 2 fw classid 1:20
* Con este filtro en la cola padre el trafico marcado con 2 se destinara a la banda de MENOR prioridad 20, nuevamente atencion sobre si se esta actuando sobre la interfaz correcta.
iptables -A FORWARD -o eth1 -i eth0 -p tcp --dport 80 -t mangle -j MARK --set-mark 2
* Lo mismo que lo anterior el trafico cuyo destino sea el puerto 80 sea marcado con 2
Tambien si detengo la descarga de mi http aumenta la del FTP (cual debe de ser), pero aumenta muy lento, y sigo teniendo mis demas servicios muy lentos como el http o el vnc.
* Bueno ten en cuenta que la banda a la que se destinan las peticiones ftp es la PRIORITARIA, por tanto los demas traficos NO son prioritarios, ademas de esto tendria que soltar ahora un autentico ladrillo sobre los problemas de las conexiones asincronas y como "engañar" al isp para que empiece a encolar a la maxima velocidad, la gestion de las colas de retraso en el canal de subida para no colapsar la conexion, la conveniencia de poner los routers en monopuesto, etc, etc, y algo muy importante esta totalmente demostrado que asignar unos valores elevados de ancho de banda no es nada bueno, una vez conseguida la media del ancho de banda real que no tiene absolutamente nada que ver con la publicidad del proveedor (ver la documentacion existente del paquete wondershaper de SuSE para las formulas y como conseguirlo) si se obtiene un valor de 300kbps por ejemplo, mas que recomendable es obligado limitar el uso por ejemplo a 295 o incluso 290, esto que puede parecer un desperdicio de ancho de banda dara como resultado que no se produzcan colapsos por los picos de bajada de ancho de banda en la linea, que no olvide que se produciran muchos cada hora y un colapso dara al traste con todo lo ganado en los esporadicos picos aprovechados a maximo ancho de banda, mantendra la linea estable y una latencia baja, como consecuencia en el corto y medio plazo el rendimiento de la linea (que es lo que importa) sera mucho mas eficiente y no en descargas puntuales
Jose María, ojalá me puedas ayudar estoy desesperado, si me puedas pasar tu configuracion te lo agradeceré asi como a todos le agradezco que cuando menos lean mi mail.
* Los scripts particulares usados no te valdran, son configuraciones personalizadas, ajustadas a necesidades particulares de redes, que pueden estar conectadas a otras redes remotas cuyos scripts deben estar relacionados, incorporan bandas prioritarias para cierto trafico en caso de existir sobrante en detrimento de otros, hay algunos con 50 bandas, con interfaces virtuales para "intentar" gestionar trafico que con el protocolo ipv4 es dificil o poco posible, y esto esta relacionado con scripts de cortafuegos que pueden incorporar de 350 reglas para arriba, por tanto deberas encontrar tu script mediante prueba y error e ir afinandolo a las necesidades particulares de tu red, importante ademas de lo relacionado con ser moderado con el ancho de banda real disponible, saber que porcentaje de trafico se genera para unos u otros protocolos, muestreos serios por fechas, epocas vacacionales, festivos, visperas de los mismos, etc, si se sirven webs o sitios de comercio, ver la procedencia de las consultas y tener en cuenta lo anterior para paises distintos y horarios medios y tareas cron que apliquen por fechas-horas unos u otros scripts, etc, etc, en definitiva scripts que no tengan nada que ver con tus redes, al igual que los mios, los encontraras a paladas por internet. * Suerte y recuerda que lo dificil es conseguir la estructura basica de lo que uno necesita, el ajuste o afinamiento para conseguir el "mejor" rendimiento suele ser trivial y hasta entretenido. * Y me voy a celebrar mi santo que llevo varias semanas movidas. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAXHvfAXFL65CppEIRAjm7AJ9tTWeyABID9NPPhHEGL06itD51+wCfaNqO TvvIr4kD76wtGqNit9KL1Mc= =ZFEX -----END PGP SIGNATURE-----