Controlar trafico p2p

[Aldrin Martoq]

2010/3/31 Miguel Oyarzo O. <admin en 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/