Re: Controlar trafico p2p
El 01-04-2010 3:45, Aldrin Martoq escribió: 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 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... Quizas es un tema que a nadie interesa y por eso no participan. Dejemos el tema hasta aqui entonces... nadie extraniará este hilo. Si pasas por Punta Arenas algun dia quizas resolvamos lo del trago favorito. Saludos, = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org =
Re: Controlar trafico p2p
2010/4/1 Miguel Oyarzo O. ad...@aim.cl El 01-04-2010 3:45, Aldrin Martoq escribió: 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 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... Quizas es un tema que a nadie interesa y por eso no participan. Dejemos el tema hasta aqui entonces... nadie extraniará este hilo. Si pasas por Punta Arenas algun dia quizas resolvamos lo del trago favorito. Saludos, Yo la encontraba interesante, (de las pocas actuales que venia siguiendo) pero como para leer y digerir lentamente revisando las anotaciones del caso.. y sin mucho que aportar. Saludos -- Miguel
Re: Controlar trafico p2p
El 27-03-2010 22:57, Aldrin Martoq escribió: 2010/3/27 Miguel Oyarzo O.ad...@aim.cl: El 26-03-2010 22:13, Aldrin Martoq escribió: 2010/3/26 Miguel Oyarzo O.ad...@aim.cl: El 25-03-2010 0:57, Aldrin Martoq escribió: Gracias por el puntero, pero HS-TCP no parece tener nada que ver con ruteo/shaping. El traffic shaping NO esta basado en el stack TCP... 2) Traffic Shapping basado 100% en el stack de TCP/IP y no requiere ver el contenido de la data del paquete. tc y tcng son 2 de las herramienta que permite disciplinar las las qdisc, darles a las conexiones prioridad, velocidad, reorganizarlas en clases y subclases para que los paquetes que entran a la interfaz salgan en orden distinto a pfifo_fast (como HTB). Precisamente, ¿en qué te basas para decir que el traffic shapping del kernel está basado en el stack TCP? Eso está incorrecto. Por que esto ocurre en la Interface Layer (if_ethersubr.c), en la fase de Preparación del Frame antes de ponerlo en cola output de la interfaz. Esta etapa definida en el stack de TCP/IP y es el ultimo proceso antes de poner el frame al medio fisico. En este preciso punto (Interface Queuing del stack) mediante tc es posible reoganizar los frames, priorizarlos usando algoritmos de colas como HTB, HFSC, SFQ y otros; gestionar los que estan macados, darles rate, etc. 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. 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 Tu te debes estar refiriendo al Rate Shapping en la Capa 2/OSI (y a QoS talvez), pero el thread es de traffic shaping de protocolos. De hecho con esta herramienta no puedes indicar que protocolo TCP/IP va mas rapido o más lento o con mas o menos prioridad, ebtables solo mira frames (y con suerte la IP). No me hace sentido hablar de Traffic Shaping de Tramas, el tema se desarrolla en Paquetes (capa 3), sea por colas o por manejo de la ventana TCP de cada paquete. Saludos, = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org =
Re: Controlar trafico p2p
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/
Re: Controlar trafico p2p
El 26-03-2010 22:13, Aldrin Martoq escribió: 2010/3/26 Miguel Oyarzo O.ad...@aim.cl: El 25-03-2010 0:57, Aldrin Martoq escribió: Gracias por el puntero, pero HS-TCP no parece tener nada que ver con ruteo/shaping. El traffic shaping NO esta basado en el stack TCP... A ver... para que vamos a dejar pasar este comentario. :) En Linux tienes varios mecanismos de traffic shaping: 1) filtro L7 para descubrir paquetes P2P, H323, SIP, Skpype, etc, etc y aplicar QoS en base a alguna estrategia. 2) Traffic Shapping basado 100% en el stack de TCP/IP y no requiere ver el contenido de la data del paquete. tc y tcng son 2 de las herramienta que permite disciplinar las las qdisc, darles a las conexiones prioridad, velocidad, reorganizarlas en clases y subclases para que los paquetes que entran a la interfaz salgan en orden distinto a pfifo_fast (como HTB). Precisamente, ¿en qué te basas para decir que el traffic shapping del kernel está basado en el stack TCP? Eso está incorrecto. Por que esto ocurre en la Interface Layer (if_ethersubr.c), en la fase de Preparación del Frame antes de ponerlo en cola output de la interfaz. Esta etapa definida en el stack de TCP/IP y es el ultimo proceso antes de poner el frame al medio fisico. En este preciso punto (Interface Queuing del stack) mediante tc es posible reoganizar los frames, priorizarlos usando algoritmos de colas como HTB, HFSC, SFQ y otros; gestionar los que estan macados, darles rate, etc. Qué es incorrecto? = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org =
Re: Controlar trafico p2p
2010/3/27 Miguel Oyarzo O. ad...@aim.cl: El 26-03-2010 22:13, Aldrin Martoq escribió: 2010/3/26 Miguel Oyarzo O.ad...@aim.cl: El 25-03-2010 0:57, Aldrin Martoq escribió: Gracias por el puntero, pero HS-TCP no parece tener nada que ver con ruteo/shaping. El traffic shaping NO esta basado en el stack TCP... 2) Traffic Shapping basado 100% en el stack de TCP/IP y no requiere ver el contenido de la data del paquete. tc y tcng son 2 de las herramienta que permite disciplinar las las qdisc, darles a las conexiones prioridad, velocidad, reorganizarlas en clases y subclases para que los paquetes que entran a la interfaz salgan en orden distinto a pfifo_fast (como HTB). Precisamente, ¿en qué te basas para decir que el traffic shapping del kernel está basado en el stack TCP? Eso está incorrecto. Por que esto ocurre en la Interface Layer (if_ethersubr.c), en la fase de Preparación del Frame antes de ponerlo en cola output de la interfaz. Esta etapa definida en el stack de TCP/IP y es el ultimo proceso antes de poner el frame al medio fisico. En este preciso punto (Interface Queuing del stack) mediante tc es posible reoganizar los frames, priorizarlos usando algoritmos de colas como HTB, HFSC, SFQ y otros; gestionar los que estan macados, darles rate, etc. 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 Los filtros/matchers como l7filter, iptables, ebtables, etc permiten marcar internamente el tipo de tráfico, pero el traffic shaping no es afectado por ningún parámetro TCP/IP (ni el ruteo en tal caso, pues tampoco ve conexiones TCP/IP). Qué es incorrecto? Que ajustar parámetros de TCP/IP mejoran el rendimiento de ruteo/traffic shaping. El kernel no ve ni mantiene conexiones TCP/IP en ambos casos. -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Controlar trafico p2p
2010/3/26 Javier Garay javierzga...@gmail.com: El 26 de marzo de 2010 18:32, Aldrin Martoq amar...@dcc.uchile.clescribió: 2010/3/26 Aldrin Martoq amar...@dcc.uchile.cl: 2010/3/26 Javier Garay javierzga...@gmail.com: Que herramienta me sirve para monitorear trafico como el p2p? estoy probando ntop, pero no sirve para eso, al menos por lo que veo. Debe haber algo mejor, pero con ntop por al menos debes determinar qué tráfico es bueno y el resto lo tomas como malo. Revisando en internet, verifica si tu cisco exporta en formato netflow. Si lo hace, y estaba viendo que me pordría ayudar, pero ¿En que estas pensando tu? Primero que captures y tengas data, puede ser del linux con ntop y del cisco con netflow (ese lo puedes redirigir a ntop o ve si lo puedes guardar en otro lado, y tal vez analizarlo con scripts perl y ese tipo de cosas). Segundo, que la analices antes y después de aplicar algo en la red. Entre paréntesis, no entiendo por qué ntop no te sirve... el tipo de información que debieras obtener es similar a lo siguiente: http://www.cyberciti.biz/faq/debian-ubuntu-install-ntop-network-traffic-monitoring-software/ En particular: http://www.cyberciti.biz/faq/wp-content/uploads/2008/07/ntop-output-1.png Por ejemplo, en un tarro yo tengo este tipo de estadísticas: - Global: eth0 20% eth1 60% br0 20% - paquetes: unicast 96% entre 1024 y 1518 bytes: 50% ip 99% ttl entre 33-64: 60% - distribución protocolos: ssh: 69% http: 6% mail: 9% otro: 16% (¡con gráficos historial de todo esto!) También puedo saber información particular como: hosts con más tráfico, sitios mas visitados, tamaño consultas DNS, etc... -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Controlar trafico p2p
El 25-03-2010 0:57, Aldrin Martoq escribió: 2010/3/23 Miguel Oyarzo O.ad...@aim.cl: Respecto de tu preocupación por 500MB analizados, el kernel de linux puede analizar trafico de hasta 1GBbps sin problema (desde el kernel 2.6.19 solo le das el tunning correcto a los parametros del kernel y habilitas el modulo HS-TCP). Gracias por el puntero, pero HS-TCP no parece tener nada que ver con ruteo/shaping. El traffic shaping NO esta basado en el stack TCP... A ver... para que vamos a dejar pasar este comentario. :) En Linux tienes varios mecanismos de traffic shaping: 1) filtro L7 para descubrir paquetes P2P, H323, SIP, Skpype, etc, etc y aplicar QoS en base a alguna estrategia. 2) Traffic Shapping basado 100% en el stack de TCP/IP y no requiere ver el contenido de la data del paquete. tc y tcng son 2 de las herramienta que permite disciplinar las las qdisc, darles a las conexiones prioridad, velocidad, reorganizarlas en clases y subclases para que los paquetes que entran a la interfaz salgan en orden distinto a pfifo_fast (como HTB). Control de trafico (por descarte de paquetes y sin reorganizar las colas): 3) Traffic Shaping con SQUID (para los protocolos que puede manejar) 4) Control de speed con iptables. Me queda alguno en el tintero? = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org =
Re: Controlar trafico p2p
Que herramienta me sirve para monitorear trafico como el p2p? estoy probando ntop, pero no sirve para eso, al menos por lo que veo. El 26 de marzo de 2010 12:36, Miguel Oyarzo O. ad...@aim.cl escribió: El 25-03-2010 0:57, Aldrin Martoq escribió: 2010/3/23 Miguel Oyarzo O.ad...@aim.cl: Respecto de tu preocupación por 500MB analizados, el kernel de linux puede analizar trafico de hasta 1GBbps sin problema (desde el kernel 2.6.19 solo le das el tunning correcto a los parametros del kernel y habilitas el modulo HS-TCP). Gracias por el puntero, pero HS-TCP no parece tener nada que ver con ruteo/shaping. El traffic shaping NO esta basado en el stack TCP... A ver... para que vamos a dejar pasar este comentario. :) En Linux tienes varios mecanismos de traffic shaping: 1) filtro L7 para descubrir paquetes P2P, H323, SIP, Skpype, etc, etc y aplicar QoS en base a alguna estrategia. 2) Traffic Shapping basado 100% en el stack de TCP/IP y no requiere ver el contenido de la data del paquete. tc y tcng son 2 de las herramienta que permite disciplinar las las qdisc, darles a las conexiones prioridad, velocidad, reorganizarlas en clases y subclases para que los paquetes que entran a la interfaz salgan en orden distinto a pfifo_fast (como HTB). Control de trafico (por descarte de paquetes y sin reorganizar las colas): 3) Traffic Shaping con SQUID (para los protocolos que puede manejar) 4) Control de speed con iptables. Me queda alguno en el tintero? = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org = -- Atte, Javier Andrés Garay G. Ingeniero en Informática Plug And Play Net S.A. www.papnet.cl
Re: Controlar trafico p2p
2010/3/26 Miguel Oyarzo O. ad...@aim.cl: El 25-03-2010 0:57, Aldrin Martoq escribió: Gracias por el puntero, pero HS-TCP no parece tener nada que ver con ruteo/shaping. El traffic shaping NO esta basado en el stack TCP... A ver... para que vamos a dejar pasar este comentario. :) En Linux tienes varios mecanismos de traffic shaping: 1) filtro L7 para descubrir paquetes P2P, H323, SIP, Skpype, etc, etc y aplicar QoS en base a alguna estrategia. 2) Traffic Shapping basado 100% en el stack de TCP/IP y no requiere ver el contenido de la data del paquete. tc y tcng son 2 de las herramienta que permite disciplinar las las qdisc, darles a las conexiones prioridad, velocidad, reorganizarlas en clases y subclases para que los paquetes que entran a la interfaz salgan en orden distinto a pfifo_fast (como HTB). Precisamente, ¿en qué te basas para decir que el traffic shapping del kernel está basado en el stack TCP? Eso está incorrecto. -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Controlar trafico p2p
2010/3/26 Javier Garay javierzga...@gmail.com: Que herramienta me sirve para monitorear trafico como el p2p? estoy probando ntop, pero no sirve para eso, al menos por lo que veo. Debe haber algo mejor, pero con ntop por al menos debes determinar qué tráfico es bueno y el resto lo tomas como malo. Para la latencia, el otro día encontre smokeping. -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Controlar trafico p2p
2010/3/26 Aldrin Martoq amar...@dcc.uchile.cl: 2010/3/26 Javier Garay javierzga...@gmail.com: Que herramienta me sirve para monitorear trafico como el p2p? estoy probando ntop, pero no sirve para eso, al menos por lo que veo. Debe haber algo mejor, pero con ntop por al menos debes determinar qué tráfico es bueno y el resto lo tomas como malo. Revisando en internet, verifica si tu cisco exporta en formato netflow. -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Controlar trafico p2p
El 26 de marzo de 2010 18:32, Aldrin Martoq amar...@dcc.uchile.clescribió: 2010/3/26 Aldrin Martoq amar...@dcc.uchile.cl: 2010/3/26 Javier Garay javierzga...@gmail.com: Que herramienta me sirve para monitorear trafico como el p2p? estoy probando ntop, pero no sirve para eso, al menos por lo que veo. Debe haber algo mejor, pero con ntop por al menos debes determinar qué tráfico es bueno y el resto lo tomas como malo. Revisando en internet, verifica si tu cisco exporta en formato netflow. Si lo hace, y estaba viendo que me pordría ayudar, pero ¿En que estas pensando tu? -- Atte, Javier Andrés Garay G. Ingeniero en Informática Plug And Play Net S.A. www.papnet.cl
Re: Controlar trafico p2p
2010/3/23 Miguel Oyarzo O. ad...@aim.cl: Respecto de tu preocupación por 500MB analizados, el kernel de linux puede analizar trafico de hasta 1GBbps sin problema (desde el kernel 2.6.19 solo le das el tunning correcto a los parametros del kernel y habilitas el modulo HS-TCP). Gracias por el puntero, pero HS-TCP no parece tener nada que ver con ruteo/shaping. El traffic shaping NO esta basado en el stack TCP... Entiendo que Linux puede más que eso, pero yo no he probado control sobre más trafico. Sin un análisis de cuánto tráfico estamos hablando, cualquier decisión será bastante al aire: - tal vez un simple PC haciendo tc no sea suficiente o involucre una latencia inaceptable No te entiendo esta reflexión. - tal vez sea mejor *bsd o algo por hardware argumenta, tal vez no deja claro. Lo que intento decir, independiente de qué utilice Javier, es que tienes que tener mediciones antes y después de aplicar cualquier traffic shaping con cualquier solución. Cosas importantes es cuanta latencia agrega la caja, el nivel de uso de CPU, etc. Incluso te puedes dar el lujo de probar otras soluciones como PF o alguna solución por hardware, pero sólo las puedes comparar si tienes mediciones. Otra cosa importante es intentar determinar qué tipo de tráfico está viajando en la red. De lo que habla Javier veo que no tiene claro este tipo de análisis, así no puedes saber cuánto mejoró implementar la caja y qué tipo de tráfico se sintió afectado. - tal vez no tenga sentido porque hoy la mayoría del tráfico p2p está encriptado y gracias al hole punching en cualquier puerto (hasta Transmission en GNOME me reporta todo encriptado para bajar la beta de ubuntu). IE: solo generarás latencia. En Linux Traffic shapping cuenta paquetes y considera el tamaño de los mismos para tomar una decisión. No es relevante si esta encriptado o no, quizas en filtros L7 esto presente un problema, no con TC de linux. Respecto que la mayoría del trafico P2P esta encriptado, no se de donde sacas eso. Yo solo conzoco el esfuerzo de bittorrent, pero que en la practica no dio nungun resultado dado la escaza migración entre sus clientes P2P a trafico encriptado. Precisamente, dado que están encriptados es mucho más difícil poder determinar si una conexión es tráfico P2P o no. De la página de l7filter: L7-filter is a classifier for Linux's Netfilter that identifies packets based on application layer data. It can classify packets as Kazaa, HTTP, Jabber, Citrix, Bittorrent, FTP, Gnucleus, eDonkey2000, etc., regardless of port. It complements existing classifiers that match on IP address, port numbers and so on. Ni la red Ares ni la red Edonkey trabajan hoy encriptadas, quizas por la misma razon. La mayoría de los ISP intentan limitar el tráfico P2P, por eso que hace rato los programas están encriptando el tráfico y usando cualquier puerto, incluso puertos como el 80. Es una tendencia que veo hace tiempo, por ejemplo yo he usado Azureus (ahora Vuze) y Transmission. Estoy casi seguro que los programas windows hacen un montón de truculencias precisamente para evitar este tipo de control. Ahora, con un análisis del tráfico de red, podriamos saber qué tanto es... -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Controlar trafico p2p
2010/3/23 Javier Andres Garay javier.gga...@gmail.com: Respecto de tu preocupación por 500MB analizados, el kernel de linux puede analizar trafico de hasta 1GBbps sin problema (desde el kernel 2.6.19 solo le das el tunning correcto a los parametros del kernel y habilitas el modulo HS-TCP). Entiendo que Linux puede más que eso, pero yo no he probado control sobre más trafico. Para manejar más de 100 MB de trafico se necesita una implementación completa a 1 Gbps... Yo aspiro máximo a 100 Mbps. Menos carga aún. Sin un análisis de cuánto tráfico estamos hablando, cualquier decisión será bastante al aire: En horarios punta el trafico alcanza los 50 MB de downmstream con 400 usuarios conectados y 30 MB de upstream... Estoy hablando del trafico total. Yo lo separaría en tráfico HTTP, EMAIL, etc, para que sepas cuánto mejora/empeora. Una herramienta que hace esto es ntop y no es necesario que sea de router para medir esto. ¿Alguien tiene una herramienta mejor? - tal vez un simple PC haciendo tc no sea suficiente o involucre una latencia inaceptable Tengo un servidor Intel SR1435 (referencia http://www.geeks.com/details.asp?InvtId=SR1435-XEON3400-2cpc=RECOM), tal vez las lan cards que este tiene no sean suficiente. El consumo total de ancho de banda pasa por un cisco 2950 sin problema alguno con puertas 10/100. ¿Será necesario comprar una tarjeta de red PC/PC Express/ de alto rendimiento o que soporte todo el trafico? No creo, se ve buen tarro. Estaba buscando info acerca de como tunear las NIC, pero no encuentro... - tal vez sea mejor *bsd o algo por hardware Probé hacer algo con FreeBSD, pero francamente Debian me ha dado mejores resultados en cuanto a lo que he logrado hacer hasta ahora. Con FreeBSD el sistema se colgaba bruscamente al ponerlo como puente entre el CMTS e internet, con Debian esto no ha ocurrido. De hecho las tarjetas en modo promiscuo y viendo datos del trafico con tcpdump solo me funcionó en Debian. Hmm.. Me imagino que fue problema de drivers o algo por el estilo. -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Controlar trafico p2p
On Mon, 2010-03-22 at 18:38 +0100, Miguel Oyarzo O. wrote: pero dijiste que es una LAN (IPs privadas por definicion). Ojo que una LAN no tiene por qué ser privada, no mezclemos los conceptos... Saludos, -- Jens
Re: Controlar trafico p2p
El 23-03-2010 5:38, Aldrin Martoq escribió: 2010/3/22 Miguel Oyarzo O.ad...@aim.cl: El 23-03-2010 1:52, Aldrin Martoq escribió: 2010/3/22 Javier Andres Garayjavier.gga...@gmail.com: Lo otro sería: Cliente -CableModem -CMTS -Debian -Internet... Supongo que la última es la indicada, pero dado que es un equipo tan grande, tendrás que dimensionar bien cuánto tráfico viaja y cuánto puedes procesar. Definitivamente ese es el esquema. No lo veo complicado, tu estas repartiendo IPs publicas, por lo tanto tienes un bloque asigando solo para ti. Si es asi, solo asignale una IP publica a la maquina debian y reprograma tu CMTS para q reparta la IP del nuevo Gateway. Con eso el trafico IP se irá Debian y podras controlar trafico eficientemente. (Nada le gana a Linux en traffic shaping) Que el trafico IP pase o no por el CMTS no tiene importancia, pues ese solo es util en la capa 2 para activar o desactivar tus modems. ¿Chequeaste lo que es un CMTS? Está hablando de un ISP, pueden ser de 25 a 2000 clientes *por cable* HFC. Digamos que en hora peak tienes 500 usuarios navegando a 1 Mb cada uno, son 500Mb que analizar constantemente... Otra idea: en mi casa tengo 8Mb y estoy por cable. Javier dijo claramente que es un pequeño ISP, sigue el hilo de la conversación. Se perfectamente lo que es un CMTS y los he instalado y configurado, incluso hasta los CMTS tipo PC de bajo costo basados en Linux y cablemodems inalambricos MMDS. Respecto de tu preocupación por 500MB analizados, el kernel de linux puede analizar trafico de hasta 1GBbps sin problema (desde el kernel 2.6.19 solo le das el tunning correcto a los parametros del kernel y habilitas el modulo HS-TCP). Entiendo que Linux puede más que eso, pero yo no he probado control sobre más trafico. Sin un análisis de cuánto tráfico estamos hablando, cualquier decisión será bastante al aire: - tal vez un simple PC haciendo tc no sea suficiente o involucre una latencia inaceptable No te entiendo esta reflexión. - tal vez sea mejor *bsd o algo por hardware argumenta, tal vez no deja claro. - tal vez no tenga sentido porque hoy la mayoría del tráfico p2p está encriptado y gracias al hole punching en cualquier puerto (hasta Transmission en GNOME me reporta todo encriptado para bajar la beta de ubuntu). IE: solo generarás latencia. En Linux Traffic shapping cuenta paquetes y considera el tamaño de los mismos para tomar una decisión. No es relevante si esta encriptado o no, quizas en filtros L7 esto presente un problema, no con TC de linux. Respecto que la mayoría del trafico P2P esta encriptado, no se de donde sacas eso. Yo solo conzoco el esfuerzo de bittorrent, pero que en la practica no dio nungun resultado dado la escaza migración entre sus clientes P2P a trafico encriptado. Ni la red Ares ni la red Edonkey trabajan hoy encriptadas, quizas por la misma razon. = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org =
Re: Controlar trafico p2p
El 23-03-2010 12:56, Jens Hardings escribió: On Mon, 2010-03-22 at 18:38 +0100, Miguel Oyarzo O. wrote: pero dijiste que es una LAN (IPs privadas por definicion). Ojo que una LAN no tiene por qué ser privada, no mezclemos los conceptos... Saludos, Eso es verdad!. YO referia a una LAN de direccionamiento privado. Gracias por la aclaración. = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org =
Re: Controlar trafico p2p
Respecto de tu preocupación por 500MB analizados, el kernel de linux puede analizar trafico de hasta 1GBbps sin problema (desde el kernel 2.6.19 solo le das el tunning correcto a los parametros del kernel y habilitas el modulo HS-TCP). Entiendo que Linux puede más que eso, pero yo no he probado control sobre más trafico. Para manejar más de 100 MB de trafico se necesita una implementación completa a 1 Gbps... Yo aspiro máximo a 100 Mbps. Menos carga aún. Sin un análisis de cuánto tráfico estamos hablando, cualquier decisión será bastante al aire: En horarios punta el trafico alcanza los 50 MB de downmstream con 400 usuarios conectados y 30 MB de upstream... Estoy hablando del trafico total. - tal vez un simple PC haciendo tc no sea suficiente o involucre una latencia inaceptable Tengo un servidor Intel SR1435 (referencia http://www.geeks.com/details.asp?InvtId=SR1435-XEON3400-2cpc=RECOM), tal vez las lan cards que este tiene no sean suficiente. El consumo total de ancho de banda pasa por un cisco 2950 sin problema alguno con puertas 10/100. ¿Será necesario comprar una tarjeta de red PC/PC Express/ de alto rendimiento o que soporte todo el trafico? - tal vez sea mejor *bsd o algo por hardware Probé hacer algo con FreeBSD, pero francamente Debian me ha dado mejores resultados en cuanto a lo que he logrado hacer hasta ahora. Con FreeBSD el sistema se colgaba bruscamente al ponerlo como puente entre el CMTS e internet, con Debian esto no ha ocurrido. De hecho las tarjetas en modo promiscuo y viendo datos del trafico con tcpdump solo me funcionó en Debian. Otro dato: el CMTS es router tambien... es un uBR7200
Re: Controlar trafico p2p
El 22-03-2010 21:14, Javier Andres Garay escribió: Hola, me gustaría saber si alguien tiene conocimiento/información/howto de como controlar el ancho de banda para p2p. He sabido que es muy engorroso hacerlo por puertos, pero me da la impresión que si hubiera alguna especie de control sobre los protocolos p2p, sería mejor. En definitiva lo que me gustaría hacer es conceder un bajo ancho de banda a todo lo que sea p2p y así liberar. Estoy usando un bridge montado en Debian 5 (2.6.26-2-686) entre mi lan y mi router. Espero sus respuestas. Gracias. Atte, Javier Lo que mejor resulta es crear QDISCS mediante tc (traffic controler) o tcng y usar esta politica: Todo lo que sea conocido sale por bandas priorizadas y con buena velocidad, el resto se va a una cola pequeña sin prioridad y baja velocidad. Lo anterior es muy efectivo, pero depende de tu conocimiento de TCP/IP (puertos y estados de una conexion) Otra opcion conocida son los los filtros Layer 7 (L7) para iptables, pero no logran detectar todos los paquetes P2P que existen hoy y en alto trafico relentiza unos preciados milisegundos cada paquete q atravieza el fw (debe ser analizado uno por uno). Usas a debian como un Bridge? No estoy seguro que se puedan usar colas de disciplina qdisc en modo Bridge. La idea no me hace mucho sentido, pienso que debes configurar la maquina como ruteador. Saludos, = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org =
Re: Controlar trafico p2p
El 22 de marzo de 2010 13:38, Miguel Oyarzo O. ad...@aim.cl escribió: Lo anterior es muy efectivo, pero depende de tu conocimiento de TCP/IP (puertos y estados de una conexion) Tengo algunos libros que leer al respecto y puedo mejorar. Otra opcion conocida son los los filtros Layer 7 (L7) para iptables, pero no logran detectar todos los paquetes P2P que existen hoy y en alto trafico relentiza unos preciados milisegundos cada paquete q atravieza el fw (debe ser analizado uno por uno). Eso es lo que menos quiero ya que estoy hablando de mucho trafico y cada bit es preciado. Usas a debian como un Bridge? No estoy seguro que se puedan usar colas de disciplina qdisc en modo Bridge. La idea no me hace mucho sentido, pienso que debes configurar la maquina como ruteador. No puedo hacerlo, ya que ya estoy detras de un router. Si pudiera manejar el trafico sin hacer enmascaramiento seria fabuloso, pero no se como hacerlo. Saludos, Igualmente. Javier.
Re: Controlar trafico p2p
El 22-03-2010 22:07, Javier Andres Garay escribió: El 22 de marzo de 2010 13:38, Miguel Oyarzo O.ad...@aim.cl escribió: Lo anterior es muy efectivo, pero depende de tu conocimiento de TCP/IP (puertos y estados de una conexion) Tengo algunos libros que leer al respecto y puedo mejorar. Otra opcion conocida son los los filtros Layer 7 (L7) para iptables, pero no logran detectar todos los paquetes P2P que existen hoy y en alto trafico relentiza unos preciados milisegundos cada paquete q atravieza el fw (debe ser analizado uno por uno). Eso es lo que menos quiero ya que estoy hablando de mucho trafico y cada bit es preciado. Usas a debian como un Bridge? No estoy seguro que se puedan usar colas de disciplina qdisc en modo Bridge. La idea no me hace mucho sentido, pienso que debes configurar la maquina como ruteador. No puedo hacerlo, ya que ya estoy detras de un router. Si pudiera manejar el trafico sin hacer enmascaramiento seria fabuloso, pero no se como hacerlo. pero dijiste que es una LAN (IPs privadas por definicion). Puedes usar tu Debian como Gateway para la LAN y la segunda interfaz conectada con la LAN de tu Router. Obviamente tendrás que tener 2 clases distintas de IP asociadas a las interfaces del debian (ej: 192.168.1.1 y 192.168.2.1, ambas clase C) Otra cosa: No necesitas enmascara nada, solo usa tu Debian como ruteador, te aseguro que ningun paquete será enmascarado, el router solo enrutará. Piensa que ese mismo paquete que va hacia internet será re-enrutado mas de 10 veces hasta llegar a su destino y nadie se percata de ello. Bueno, parece que qdisc es tu solución, usa tcng (la sintaxis es mas clara si eres programador de algo, sino tc nomas, la sintaxis es complicada en un comienzo) Juega con esto: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm Normalmente no requieres más documentación ;-) Saludos, = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org =
Re: Controlar trafico p2p
pero dijiste que es una LAN (IPs privadas por definicion). Disculpa, me equivoque, no es una LAN, uso ips publicas pues estoy hablando de un pequeño isp que obiamente entrega ips publicas, podriamos llamarla WAN. Puedes usar tu Debian como Gateway para la LAN y la segunda interfaz conectada con la LAN de tu Router. Obviamente tendrás que tener 2 clases distintas de IP asociadas a las interfaces del debian (ej: 192.168.1.1 y 192.168.2.1, ambas clase C) El problema es que el router es un cmts. Tendría que redireccionar el trafico a mi Debian y luego volver a entregarlo al cmts para que lo envíe al exterior, ya que el diagrama actual es asi: Cliente - CableModem - CMTS - Internet... Quedaría así: Cliente - CableModem - CMTS - Debian - CMTS - Internet... Lo otro sería: Cliente - CableModem - CMTS - Debian - Internet... Otra cosa: No necesitas enmascara nada, solo usa tu Debian como ruteador, te aseguro que ningun paquete será enmascarado, el router solo enrutará. Piensa que ese mismo paquete que va hacia internet será re-enrutado mas de 10 veces hasta llegar a su destino y nadie se percata de ello. ¿Esto lo hago solo con tc? Bueno, parece que qdisc es tu solución, usa tcng (la sintaxis es mas clara si eres programador de algo, sino tc nomas, la sintaxis es complicada en un comienzo) Gracias. Saludos, Gracias denuevo y saludos.
Re: Controlar trafico p2p
2010/3/22 Javier Andres Garay javier.gga...@gmail.com: pero dijiste que es una LAN (IPs privadas por definicion). Disculpa, me equivoque, no es una LAN, uso ips publicas pues estoy hablando de un pequeño isp que obiamente entrega ips publicas, podriamos llamarla WAN. Puedes usar tu Debian como Gateway para la LAN y la segunda interfaz conectada con la LAN de tu Router. Obviamente tendrás que tener 2 clases distintas de IP asociadas a las interfaces del debian (ej: 192.168.1.1 y 192.168.2.1, ambas clase C) El problema es que el router es un cmts. Tendría que redireccionar el trafico a mi Debian y luego volver a entregarlo al cmts para que lo envíe al exterior, ya que el diagrama actual es asi: Cliente - CableModem - CMTS - Internet... Quedaría así: Cliente - CableModem - CMTS - Debian - CMTS - Internet... Lo otro sería: Cliente - CableModem - CMTS - Debian - Internet... Supongo que la última es la indicada, pero dado que es un equipo tan grande, tendrás que dimensionar bien cuánto tráfico viaja y cuánto puedes procesar. Me imagino que ya tienes cubiertos los temas no técnicos, como avisar a los clientes que estás filtrando su tráfico... Otra cosa: No necesitas enmascara nada, solo usa tu Debian como ruteador, te aseguro que ningun paquete será enmascarado, el router solo enrutará. Piensa que ese mismo paquete que va hacia internet será re-enrutado mas de 10 veces hasta llegar a su destino y nadie se percata de ello. ¿Esto lo hago solo con tc? No, no lo puedes hacer sólo con tc... la mayoría lo hace con un mix entre iproute, iptables, algunos módulos extras como los que detectan p2p (l7filter) e incluso algunos demonios. Algo de documentación hay en Linux Advanced Routing Traffic Control: http://lartc.org/ -- Aldrin Martoq http://aldrin.martoq.cl/
Re: Controlar trafico p2p
El 23-03-2010 1:52, Aldrin Martoq escribió: 2010/3/22 Javier Andres Garayjavier.gga...@gmail.com: pero dijiste que es una LAN (IPs privadas por definicion). Disculpa, me equivoque, no es una LAN, uso ips publicas pues estoy hablando de un pequeño isp que obiamente entrega ips publicas, podriamos llamarla WAN. Puedes usar tu Debian como Gateway para la LAN y la segunda interfaz conectada con la LAN de tu Router. Obviamente tendrás que tener 2 clases distintas de IP asociadas a las interfaces del debian (ej: 192.168.1.1 y 192.168.2.1, ambas clase C) El problema es que el router es un cmts. Tendría que redireccionar el trafico a mi Debian y luego volver a entregarlo al cmts para que lo envíe al exterior, ya que el diagrama actual es asi: Cliente - CableModem - CMTS - Internet... Quedaría así: Cliente - CableModem - CMTS - Debian - CMTS - Internet... Lo otro sería: Cliente - CableModem - CMTS - Debian - Internet... Supongo que la última es la indicada, pero dado que es un equipo tan grande, tendrás que dimensionar bien cuánto tráfico viaja y cuánto puedes procesar. Definitivamente ese es el esquema. No lo veo complicado, tu estas repartiendo IPs publicas, por lo tanto tienes un bloque asigando solo para ti. Si es asi, solo asignale una IP publica a la maquina debian y reprograma tu CMTS para q reparta la IP del nuevo Gateway. Con eso el trafico IP se irá Debian y podras controlar trafico eficientemente. (Nada le gana a Linux en traffic shaping) Que el trafico IP pase o no por el CMTS no tiene importancia, pues ese solo es util en la capa 2 para activar o desactivar tus modems. Saludos, = Miguel A. Oyarzo O. Ingeniería en Redes y Telecomunicaciones Austro Internet S.A.INALAMBRICA S.A. Teléfono: [+05661] 710030 Punta Arenas - Chile Linux User: # 483188 - counter.li.org =
Re: Controlar trafico p2p
2010/3/22 Miguel Oyarzo O. ad...@aim.cl: El 23-03-2010 1:52, Aldrin Martoq escribió: 2010/3/22 Javier Andres Garayjavier.gga...@gmail.com: Lo otro sería: Cliente - CableModem - CMTS - Debian - Internet... Supongo que la última es la indicada, pero dado que es un equipo tan grande, tendrás que dimensionar bien cuánto tráfico viaja y cuánto puedes procesar. Definitivamente ese es el esquema. No lo veo complicado, tu estas repartiendo IPs publicas, por lo tanto tienes un bloque asigando solo para ti. Si es asi, solo asignale una IP publica a la maquina debian y reprograma tu CMTS para q reparta la IP del nuevo Gateway. Con eso el trafico IP se irá Debian y podras controlar trafico eficientemente. (Nada le gana a Linux en traffic shaping) Que el trafico IP pase o no por el CMTS no tiene importancia, pues ese solo es util en la capa 2 para activar o desactivar tus modems. ¿Chequeaste lo que es un CMTS? Está hablando de un ISP, pueden ser de 25 a 2000 clientes *por cable* HFC. Digamos que en hora peak tienes 500 usuarios navegando a 1 Mb cada uno, son 500Mb que analizar constantemente... Otra idea: en mi casa tengo 8Mb y estoy por cable. Sin un análisis de cuánto tráfico estamos hablando, cualquier decisión será bastante al aire: - tal vez un simple PC haciendo tc no sea suficiente o involucre una latencia inaceptable - tal vez sea mejor *bsd o algo por hardware - tal vez no tenga sentido porque hoy la mayoría del tráfico p2p está encriptado y gracias al hole punching en cualquier puerto (hasta Transmission en GNOME me reporta todo encriptado para bajar la beta de ubuntu). IE: solo generarás latencia. Yo primero mediría de cuánto estamos hablando y qué tipo de tráfico se gasta en qué cosas (web, ftp, correo, desconocido). -- Aldrin Martoq http://aldrin.martoq.cl/
