Problema:
Deseo simular algunos escenarios de red.
a) Simular en un salto satelital
b) Simular perdida de paquetes
Lo anterior es de mucha utilidad porque permite probar escenarios -casi reales-. Se pueden probar aplicaciones y conocer como se comportan ante una alta tasa de pérdida de paquetes y/o ante altos tiempos de respuesta. Otra opción es conocer el comportamiento ante pérdidad y/o RTT aleatorios y muchas otras cosas.
Solución:
Netem (Network Emulacion) que permite simular escenarios de red muy tipicos en redes WAN, MAN y Satelitales.
Netem es controlado con el comando tc que es parte de iproute2
Ejemplos:
a) Simular el Round Trip Time de un salto satelital (550 ms):
# tc qdisc add dev eth0 root netem delay 550ms
Fijense del tiempo del ping antes y durante el comando (salto del 10 al 11):
[root@localhost ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=51.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=48.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=50.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=49.8 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=51.8 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=53 time=50.4 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=53 time=49.9 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=53 time=50.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=53 time=51.1 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=53 time=50.6 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=53 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=53 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=53 time=600 ms
b) Simular una red WAN con tiempos de mayor variación (de 100 ms - 10 ms) de manera aleatoria:
# tc qdisc change dev eth0 root netem delay 100ms 10ms
64 bytes from 8.8.8.8: icmp_seq=60 ttl=53 time=49.3 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=53 time=50.5 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=53 time=59.6 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=53 time=50.7 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=53 time=49.6 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=53 time=143 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=53 time=152 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=53 time=157 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=53 time=153 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=53 time=159 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=53 time=155 ms
c) Simular perdida % de paquetes:
# tc qdisc change dev eth0 root netem loss 0.1%
El comando anterior ocasiona una pérdida de 1/1000 paquetes descartados de manera aleatoria
Más opciones:
Existen muchas otras opciones como:
a) Duplicar paquetes
# tc qdisc change dev eth0 root netem duplicate 9%
b) Corromper (dañar) un paquete:
# tc qdisc change dev eth0 root netem corrupt 0.1%
Mas información:
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
http://www.cyberciti.biz/faq/linux-traffic-shaping-using-tc-to-control-http-traffic/
Mostrando entradas con la etiqueta tcpip. Mostrar todas las entradas
Mostrando entradas con la etiqueta tcpip. Mostrar todas las entradas
miércoles, 7 de septiembre de 2011
sábado, 6 de marzo de 2010
Como medir el ancho de banda de un enlace
Introduccion:
En repetidas oportunidades nos vemos en la necesidad de medir el ancho de banda de algun enlace, ya sea el mismo una red LAN, WAN, MAN utilizando satelite, microondas, fibra, etc y no sabemos como.
Para los conocedores del area tambien es comun que la gente de transmision nos indiquen que el enlace a nivel de capa 2 esta perfecto que no hay errores ni perdidas y que las pruebas de BERT salieron sin errores. Sin embargo al momento de probar dicho enlace con un router y transportando IP nos vemos con inconvenientes. Ahora bien, algo que es muy cierto es que el cliente tiene la ultima palabra, si el cliente dice que ve errores y/o que la aplicacion no funciona hay que revisar.
Objetivo:
Vamos a medir el ancho de banda y calidad de un enlace. Cuando me refiero a enlace puede ser la comunicacion en un enlace WAN, entre dos equipos en una misma LAN. Para estas pruebas el medio fisico (wireless, satelite, fibra, microondas) es irrelevante.
Software necesario:
Linux y/o Windows
Iperf
Como hacer el estudio:
Vamos a basar nuestro estudio en el programa Iperf. Wikipedia en su pagina en Ingles define Iperf como un programa moderno para probar redes que es capaz de crear stream TCP y UDP y mide el ancho de banda de la red donde se ejecutan. Iperf fue realizado en C++
Iperf es un programa cliente - servidor por ello es necesario instalar el programa en al menos dos dispositivos. El mismo programa funciona tanto cliente como servidor. Su comportamiento varia segun las opciones que utilicemos al momento de ejecutarlo.
Una ventaja de Iperf es que hacemos la prueba en capa 3, es decir en IP, con Iperf podemos probar TCP y UDP y con distintos programas de paquete. Esto es sensacional.
Procedimiento:
Es necesario dos equipos donde uno es cliente y el otro sera el servidor. Por default Iperf mide el ancho de banda desde el cliente al servidor (sin embargo existe una opcion de medicion bi-direccional)
Ejemplos utiles:
1) Prueba mas basica. Opciones por default.
Lado server:
[root@monitor-2 root]# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Lado cliente:
[root@pemon ~]# iperf -c 10.1.1.1
------------------------------------------------------------
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.1.1.2 port 51096 connected with 10.1.1.2 port 5001
[ 3] 0.0-10.0 sec 84.4 MBytes 70.8 Mbits/sec
2) Vamos a probar un Megabit entre el cliente y el servidor durante 15 segundo en paquetes UDP.
Lado server:
iperf -s -u
Lado cliente
[root@pemon ~]# iperf -c 10.1.1.1. -t 15 -u
3) Realizar una prueba de 2 Megabits de envio simultaneo entre el cliente y el servidor de paquetes UDP por 15 segundos
Lado server:
iperf -s -u
Lado cliente
[root@pemon ~]# iperf -c 10.1.1.1 -t 15 -u -d -b 2000000
{SUPRIMI UN POCO DE LA SALIDA}
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.0-15.0 sec 3.58 MBytes 2.00 Mbits/sec 0.180 ms 0/ 2553 (0%)
[ 3] 0.0-15.0 sec 3.58 MBytes 2.00 Mbits/sec 0.011 ms 0/ 2553 (0%)
Vamos a estudiar rapidamente el comando del cliente:
* con el -t 15 le indicamos 15 segundos
* -u que fuese UDP
* -d que fuese dual (envio y recepcion a la misma vez)
* -b 2000000 = 2 Mbits
Vamos a estudiar la salida tambien:
El intervalo fueron 15 segundos, se transfirio 3.58 Megabytes, el ancho de banda son 2 Mbits, el jitter es de 0.180 ms, se perdieron 0 datagramas de 2553 datagramas lo que representa 0 % de perdida
Recomendaciones:
Personalmente me agrada hacer mis estudios con Iperf utilizando UDP por diversas razones:
- Puedo indicar el ancho de banda
- No tengo inconvenientes con el Windows Size y/o perdida de algun acknowledge me baje drasticamente el Ancho de Banda
- Con la prueba de UDP yo mismo puedo calcular el impacto de las perdida de paquetes (imaginen la diferencia de perdida de paquetes (o errados) entre una red Wireless y una red cableada..
Salida del comado iperf --help para su referencia:
[root@monitor-2 root]# iperf --help
Usage: iperf [-s|-c host] [options]
iperf [-h|--help] [-v|--version]
Client/Server:
-f, --format [kmKM] format to report: Kbits, Mbits, KBytes, MBytes
-i, --interval # seconds between periodic bandwidth reports
-l, --len #[KM] length of buffer to read or write (default 8 KB)
-m, --print_mss print TCP maximum segment size (MTU - TCP/IP header)
-p, --port # server port to listen on/connect to
-u, --udp use UDP rather than TCP
-w, --window #[KM] TCP window size (socket buffer size)
-B, --bind bind to , an interface or multicast address
-C, --compatibility for use with older versions does not sent extra msgs
-M, --mss # set TCP maximum segment size (MTU - 40 bytes)
-N, --nodelay set TCP no delay, disabling Nagle's Algorithm
-V, --IPv6Version Set the domain to IPv6
Server specific:
-s, --server run in server mode
-D, --daemon run the server as a daemon
Client specific:
-b, --bandwidth #[KM] for UDP, bandwidth to send at in bits/sec
(default 1 Mbit/sec, implies -u)
-c, --client run in client mode, connecting to
-d, --dualtest Do a bidirectional test simultaneously
-n, --num #[KM] number of bytes to transmit (instead of -t)
-r, --tradeoff Do a bidirectional test individually
-t, --time # time in seconds to transmit for (default 10 secs)
-F, --fileinput input the data to be transmitted from a file
-I, --stdin input the data to be transmitted from stdin
-L, --listenport # port to recieve bidirectional tests back on
-P, --parallel # number of parallel client threads to run
-T, --ttl # time-to-live, for multicast (default 1)
Miscellaneous:
-h, --help print this message and quit
-v, --version print version information and quit
[KM] Indicates options that support a K or M suffix for kilo- or mega-
The TCP window size option can be set by the environment variable
TCP_WINDOW_SIZE. Most other options can be set by an environment variable
IPERF_, such as IPERF_BANDWIDTH.
Report bugs to
Links utiles:
http://www.noc.ucf.edu/Tools/Iperf/
http://sourceforge.net/projects/iperf/
http://en.wikipedia.org/wiki/Iperf
En repetidas oportunidades nos vemos en la necesidad de medir el ancho de banda de algun enlace, ya sea el mismo una red LAN, WAN, MAN utilizando satelite, microondas, fibra, etc y no sabemos como.
Para los conocedores del area tambien es comun que la gente de transmision nos indiquen que el enlace a nivel de capa 2 esta perfecto que no hay errores ni perdidas y que las pruebas de BERT salieron sin errores. Sin embargo al momento de probar dicho enlace con un router y transportando IP nos vemos con inconvenientes. Ahora bien, algo que es muy cierto es que el cliente tiene la ultima palabra, si el cliente dice que ve errores y/o que la aplicacion no funciona hay que revisar.
Objetivo:
Vamos a medir el ancho de banda y calidad de un enlace. Cuando me refiero a enlace puede ser la comunicacion en un enlace WAN, entre dos equipos en una misma LAN. Para estas pruebas el medio fisico (wireless, satelite, fibra, microondas) es irrelevante.
Software necesario:
Linux y/o Windows
Iperf
Como hacer el estudio:
Vamos a basar nuestro estudio en el programa Iperf. Wikipedia en su pagina en Ingles define Iperf como un programa moderno para probar redes que es capaz de crear stream TCP y UDP y mide el ancho de banda de la red donde se ejecutan. Iperf fue realizado en C++
Iperf es un programa cliente - servidor por ello es necesario instalar el programa en al menos dos dispositivos. El mismo programa funciona tanto cliente como servidor. Su comportamiento varia segun las opciones que utilicemos al momento de ejecutarlo.
Una ventaja de Iperf es que hacemos la prueba en capa 3, es decir en IP, con Iperf podemos probar TCP y UDP y con distintos programas de paquete. Esto es sensacional.
Procedimiento:
Es necesario dos equipos donde uno es cliente y el otro sera el servidor. Por default Iperf mide el ancho de banda desde el cliente al servidor (sin embargo existe una opcion de medicion bi-direccional)
Ejemplos utiles:
1) Prueba mas basica. Opciones por default.
Lado server:
[root@monitor-2 root]# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Lado cliente:
[root@pemon ~]# iperf -c 10.1.1.1
------------------------------------------------------------
Client connecting to 10.1.1.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.1.1.2 port 51096 connected with 10.1.1.2 port 5001
[ 3] 0.0-10.0 sec 84.4 MBytes 70.8 Mbits/sec
2) Vamos a probar un Megabit entre el cliente y el servidor durante 15 segundo en paquetes UDP.
Lado server:
iperf -s -u
Lado cliente
[root@pemon ~]# iperf -c 10.1.1.1. -t 15 -u
3) Realizar una prueba de 2 Megabits de envio simultaneo entre el cliente y el servidor de paquetes UDP por 15 segundos
Lado server:
iperf -s -u
Lado cliente
[root@pemon ~]# iperf -c 10.1.1.1 -t 15 -u -d -b 2000000
{SUPRIMI UN POCO DE LA SALIDA}
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.0-15.0 sec 3.58 MBytes 2.00 Mbits/sec 0.180 ms 0/ 2553 (0%)
[ 3] 0.0-15.0 sec 3.58 MBytes 2.00 Mbits/sec 0.011 ms 0/ 2553 (0%)
Vamos a estudiar rapidamente el comando del cliente:
* con el -t 15 le indicamos 15 segundos
* -u que fuese UDP
* -d que fuese dual (envio y recepcion a la misma vez)
* -b 2000000 = 2 Mbits
Vamos a estudiar la salida tambien:
El intervalo fueron 15 segundos, se transfirio 3.58 Megabytes, el ancho de banda son 2 Mbits, el jitter es de 0.180 ms, se perdieron 0 datagramas de 2553 datagramas lo que representa 0 % de perdida
Recomendaciones:
Personalmente me agrada hacer mis estudios con Iperf utilizando UDP por diversas razones:
- Puedo indicar el ancho de banda
- No tengo inconvenientes con el Windows Size y/o perdida de algun acknowledge me baje drasticamente el Ancho de Banda
- Con la prueba de UDP yo mismo puedo calcular el impacto de las perdida de paquetes (imaginen la diferencia de perdida de paquetes (o errados) entre una red Wireless y una red cableada..
Salida del comado iperf --help para su referencia:
[root@monitor-2 root]# iperf --help
Usage: iperf [-s|-c host] [options]
iperf [-h|--help] [-v|--version]
Client/Server:
-f, --format [kmKM] format to report: Kbits, Mbits, KBytes, MBytes
-i, --interval # seconds between periodic bandwidth reports
-l, --len #[KM] length of buffer to read or write (default 8 KB)
-m, --print_mss print TCP maximum segment size (MTU - TCP/IP header)
-p, --port # server port to listen on/connect to
-u, --udp use UDP rather than TCP
-w, --window #[KM] TCP window size (socket buffer size)
-B, --bind
-C, --compatibility for use with older versions does not sent extra msgs
-M, --mss # set TCP maximum segment size (MTU - 40 bytes)
-N, --nodelay set TCP no delay, disabling Nagle's Algorithm
-V, --IPv6Version Set the domain to IPv6
Server specific:
-s, --server run in server mode
-D, --daemon run the server as a daemon
Client specific:
-b, --bandwidth #[KM] for UDP, bandwidth to send at in bits/sec
(default 1 Mbit/sec, implies -u)
-c, --client
-d, --dualtest Do a bidirectional test simultaneously
-n, --num #[KM] number of bytes to transmit (instead of -t)
-r, --tradeoff Do a bidirectional test individually
-t, --time # time in seconds to transmit for (default 10 secs)
-F, --fileinput
-I, --stdin input the data to be transmitted from stdin
-L, --listenport # port to recieve bidirectional tests back on
-P, --parallel # number of parallel client threads to run
-T, --ttl # time-to-live, for multicast (default 1)
Miscellaneous:
-h, --help print this message and quit
-v, --version print version information and quit
[KM] Indicates options that support a K or M suffix for kilo- or mega-
The TCP window size option can be set by the environment variable
TCP_WINDOW_SIZE. Most other options can be set by an environment variable
IPERF_
Report bugs to
Links utiles:
http://www.noc.ucf.edu/Tools/Iperf/
http://sourceforge.net/projects/iperf/
http://en.wikipedia.org/wiki/Iperf
jueves, 31 de diciembre de 2009
Mejorar el rendimiento de Windows XP en redes P2P / Servidor
Situacion:
Deseo mejorar el rendimiento de Windows XP en redes P2P
Explicacion:
Como todos sabemos el ancho de banda contratado para Internet es subutilizado por la mayoria de las persona, ciertas estadisticas indican que incluso la mayoria de los suscriptores de DSLs aprovechan menos del 60% del ancho de banda que ofrece el proveedor. Por otro lado, Windows XP SP2 aplico en su stack TCP/IP ciertos algoritmos sobre intento de conexiones y conexiones simultaneas, entre ellas una que indica que solo puede realizar hasta 10 intentos de conexiones por segundo. Esta ultima afecta directamente los problemas P2P tales como torrent y emule.
Solucion:
Opcion 1:
1) Instalar el patch que se puede conseguir en: http://www.lvllord.de/?lang=en&url=downloads
El patch fue creado por: http://www.lvllord.de/ y se consigue en ingles y en aleman. Durante la instalacion probablemente Windows indique que se estan modificando archivos del sistema, indicarle que se desea continuar.
Opcion 2:
2) - En un editor hexadecimal localiza del lado izquiero el valor 4F322
- Cambiar 0a 00 00 00 a 00 00 0a 00
Extra #1:
Tambien recomiendo apoyarse en el sencillo programa TCP Optimizer el cual es una aplicacion sencilla, intuitiva que ajusta ciertos valores del registro de windows. No dejes de utilizarlo
Extra #2:
Asignarle más prioridad al proceso de P2P (por ejemplo utorrent o emule): Administrador de Tareas --> Procesos --> Click derecho sobre el proceso --> Arriba de lo normal
SIEMPRE REALIZAR UN BACKUP DEL ARCHIVO TCPIP.SYS
Luego de realizar los cambios mi windows mejoro notablemente en los servicios P2P
Nota:
Este articulo fue basado en http://www.speedguide.net/read_articles.php?id=1497 y en mi propia experiencia
Suerte!
Deseo mejorar el rendimiento de Windows XP en redes P2P
Explicacion:
Como todos sabemos el ancho de banda contratado para Internet es subutilizado por la mayoria de las persona, ciertas estadisticas indican que incluso la mayoria de los suscriptores de DSLs aprovechan menos del 60% del ancho de banda que ofrece el proveedor. Por otro lado, Windows XP SP2 aplico en su stack TCP/IP ciertos algoritmos sobre intento de conexiones y conexiones simultaneas, entre ellas una que indica que solo puede realizar hasta 10 intentos de conexiones por segundo. Esta ultima afecta directamente los problemas P2P tales como torrent y emule.
Solucion:
Opcion 1:
1) Instalar el patch que se puede conseguir en: http://www.lvllord.de/?lang=en&url=downloads
El patch fue creado por: http://www.lvllord.de/ y se consigue en ingles y en aleman. Durante la instalacion probablemente Windows indique que se estan modificando archivos del sistema, indicarle que se desea continuar.
Opcion 2:
2) - En un editor hexadecimal localiza del lado izquiero el valor 4F322
- Cambiar 0a 00 00 00 a 00 00 0a 00
Extra #1:
Tambien recomiendo apoyarse en el sencillo programa TCP Optimizer el cual es una aplicacion sencilla, intuitiva que ajusta ciertos valores del registro de windows. No dejes de utilizarlo
Extra #2:
Asignarle más prioridad al proceso de P2P (por ejemplo utorrent o emule): Administrador de Tareas --> Procesos --> Click derecho sobre el proceso --> Arriba de lo normal
SIEMPRE REALIZAR UN BACKUP DEL ARCHIVO TCPIP.SYS
Luego de realizar los cambios mi windows mejoro notablemente en los servicios P2P
Nota:
Este articulo fue basado en http://www.speedguide.net/read_articles.php?id=1497 y en mi propia experiencia
Suerte!
Suscribirse a:
Entradas (Atom)
BGP Stream: un año de análisis sobre incidentes BGP
BGP Stream: un año de análisis sobre incidentes BGP 04/03/2024 Por Alejandro Acosta , Coordinador de I+D en LACNIC LACNIC presenta la prim...
