2010/3/31 Miguel Oyarzo O. <ad...@aim.cl>: > El 27-03-2010 22:57, Aldrin Martoq escribió: >> No, eso no es TCP/IP, el traffic shaping es a nivel de capa 2, algo >> que es utilizado por todos los protocolos en linux. De hecho, los >> mismos algoritmos de encolamiento pueden ser utilizados para cualquier >> tipo de tráfico como UDP, ICMP, NETBIOS, etc. Como muestra de que no >> tiene nada que ver con TCP/IP, puedes hacer traffic shaping en linux >> con una caja que actua de bridge (ni siquiera rutea o sabe de >> conexiones). >> http://ebtables.sourceforge.net/examples/real.html#example5 > Estas mal interpretando el ejemplo. Solo estas mostrando una herramienta MAC > filtering complementaria a iptables. > Intenta usar ese Bridge/Filter en un red ruteada y ve si funciona (jamas lo > hará!). Por otro lado en este ejemplo no esta deshabilitado en STACK de > TCP/IP, no podría pues se está esta usando una cola de discliplina.
Lo que digo yo es que las colas de traffic shapping Y el ruteo no ven conexiones TCP/IP, luego que cambies algo respecto a TCP/IP no influye en ambas cosas. El ejemplo es precisamente eso: la selección de paquetes (filtrado) se hace con otra herramienta, pero en la implementación de cbq (traffic shapping) se hace justo cuando se va a escribir el paquete en la red, por eso te digo que es la capa 2. El sistema de traffic shapping en linux (ejemplo con CBQ) es muy simple: alguien selecciona los paquetes de acuerdo a algún criterio y los clasifica ("marca"); luego en el momento justo antes de escribir un paquete (antes de enviarlo a la NIC o tarjeta de red), según su clasificación y las estadísticas de cada "clase" se determina si el paquete es descartado o no. Es decir, hay dos etapas: la parte de clasificación o marcado (que puedes usar un montón de herramientas, como ebtables o iptables) y la parte en que defines el tipo de descarte de paquetes (por eso asignas vía tc el control de tráfico a cada interfaz, pues es en el momento antes de escribir el paquete en la red cuando se hace el descarte o traffich shapping). En ninguna parte de este sistema está involucrado los parámetros de TCP/IP, pues no se almacenan conexiones. Incluso, si tu filtro es en base a iptables, tampoco afectan los parámetros TCP/IP pues aún así el kernel no mantiene tablas de conexiones... En el peor caso, si estas haciendo NAT con iptables (lo cual SI mantiene las conexiones) en este caso eventualmente afectaria a la etapa de "filtrado" o selección de paquetes para las clases, pero el traffic shapping cbq sólo ve clases y en ese sentido ningún parámetro TCP/IP afecta su funcionamiento. Por otro lado, el bridge si funciona en una red ruteada, de hecho en el ejemplo ya está en una red ruteada: USUARIO (gateway .1) ----- [bridge transparente con cbq] ---- (.1 router) ---- internet > Además, que ebtables trabaje en conjunto con CBQ para crear un > "Rate Shapping" entre las MACs no quiere decir que el Traffic Shapping no > tenga que ver con TCP/IP. > De hecho la cola CBQ mostrada en el ejemplo es una implementación de la capa > IP (No Capa 2) > http://broadcastengineering.com/mag/broadcasting_classbased_queuing/ > http://en.wikipedia.org/wiki/Class-based_queueing [...] Que "sirva para..." no es lo mismo que la forma como está implementado/construido, en el mismo ejemplo aparece UDP que no es TCP/IP. Lo único que te he reclamado es que los parámetros TCP/IP no tienen nada que ver con tc o ruteo. Esta es creo la quinta vuelta de este punto y ya no veo mucho sentido ni entretención (aparte que estamos discutiendo solo los dos); esto se hubiera resuelto hace rato con /ponga su trago favorito acá/, pero Punta Arenas está algo lejos... -- Aldrin Martoq http://aldrin.martoq.cl/