Re: Ruteo No me funciona
On Thu, 2010-03-25 at 20:28 -0300, Aldrin Martoq wrote: 2010/3/25 Javier Garay javierzga...@gmail.com: Estoy con ip_forward en 1. Las reglas que he agregado al Debian son: route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.5.1 ¿Eso sera suficiente segun mi esquema? Eso está malo. Las rutas del comando route son basadas en el destino, no en el origen. Tienes que tener básicamente estas rutas: # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.5.0 0.0.0.0 255.255.255.0 U 2 00 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 2 00 eth1 0.0.0.0 192.168.5.1 0.0.0.0 UG0 00 eth0 Lo que necesita conocer el gw/debian son las rutas detrás del router, para ello necesitas una ruta por defecto en tu gateway hacia el router asi consigues que todas las redes detrás de tu gw/debian puedan comunicarse con tu ISP en este caso. El comando especifico, ni la menor idea. Haz un ping y mira en el eth0/debian si vuelve el paquete de vuelta: debian # tcpdump -ni eth0 icmp pc $ ping -c 1 ip de afuera -- -- Luis Michael Ibarra Tlf: 51-1-995070639
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: Ruteo No me funciona
Gracias por su ayuda amigos, ya lo he conseguido. He activado ip_forward y he agregado la ruta por defecto en el debian y funciono perfecto. Gracias. El 27 de marzo de 2010 10:30, Michael Ibarra michael.iba...@gmail.comescribió: On Thu, 2010-03-25 at 20:28 -0300, Aldrin Martoq wrote: 2010/3/25 Javier Garay javierzga...@gmail.com: Estoy con ip_forward en 1. Las reglas que he agregado al Debian son: route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.5.1 ¿Eso sera suficiente segun mi esquema? Eso está malo. Las rutas del comando route son basadas en el destino, no en el origen. Tienes que tener básicamente estas rutas: # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.5.0 0.0.0.0 255.255.255.0 U 2 00 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 2 00 eth1 0.0.0.0 192.168.5.1 0.0.0.0 UG0 00 eth0 Lo que necesita conocer el gw/debian son las rutas detrás del router, para ello necesitas una ruta por defecto en tu gateway hacia el router asi consigues que todas las redes detrás de tu gw/debian puedan comunicarse con tu ISP en este caso. El comando especifico, ni la menor idea. Haz un ping y mira en el eth0/debian si vuelve el paquete de vuelta: debian # tcpdump -ni eth0 icmp pc $ ping -c 1 ip de afuera -- -- Luis Michael Ibarra Tlf: 51-1-995070639 -- Atte, Javier Andrés Garay G. Ingeniero en Informática Plug And Play Net S.A. www.papnet.cl
