Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Dispredes PDF
Dispredes PDF
Pruebas de performance
Realiza correctamente la priorizacin de
mensajes?
Con alta caga de trfico contina
funcionando?
Bloquea comunicaciones no deseadas?
2 Introduccin
Se analizarn definiciones y medidas a realizar en dispositivos de redes, basndose en
las RFCs propuestas por el IETF (BMWG), las medidas apuntan a poder describir el
rendimiento (performance) de un equipo bajo prueba DUT (device under test). El
anlisis se basar en cuatro FRCs:
Definicin de trminos utilizados
o RCF 1242 (Benchmarking Terminology for Network Interconnection Devices)
o RFC 2285 (Benchmarking Terminology for LAN Switching Devices)
Pruebas a realizar
o RFC 2544 (Benchmarking Methodology for Network Interconnect Devices)
o RFC 2889 (Benchmarking Methodology for LAN Switching Devices)
Posteriormente se har un estudio (terico) del instrumental disponible para realizar
este u otro tipo de pruebas, analizando los posibles campos de aplicacin.
Al final del trabajo se presentan medidas realizadas sobre equipos utilizando algunas
de las medidas recomendadas en la RFC 2544.
Figura 1
La misma funcionalidad se puede obtener con el transmisor (sender) separado del
receptor (receiver), ver figura 2. Si (transmisor y receptor) no son controlados de
algn modo que simulen un nico equipo de prueba ciertas medidas pueden llegar a
ser imposibles de realizar con la precisin necesaria, por ejemplo: para la prueba de
latencia (latency) deben de estar sincronizados mediante una unidad externa (ejemplo
GPS) o sincronizados directamente (ejemplo mediante cable coaxial).
Figura 2
Es posible realizar las pruebas ms all de un DUT (RFC 2544 tem 19) extendiendo el
modelo a un sistema de DUTs interconectados por ejemplo:
LAN-WAN-LAN: 802.3-> DUT 1 -> X.25 @ 64kbps -> DUT 2 -> 802.3
Inter-LAN: 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3
Figura 3
Existen limitaciones a tener en cuenta en este enfoque por ejemplo la latencia
introducida por otros dispositivos (ejemplo CSUs/DSUs, switches, etc.).
4.2 Throughput
Definicin (RFC 1242 tem 3.17): La mxima tasa a la cual ninguna de las tramas
ofrecidas es descartada por el dispositivo.
Objetivo: Medir el throughput segn RFC 1242.
Procedimiento:
Enviar un nmero especfico de tramas a una tasa especfica a travs del DUT,
luego contar las tramas correctamente recibidas desde el DUT. Si la cantidad de
tramas ofrecidas es menor a la cantidad de tramas correctamente recibidas
desde el DUT, la tasa del flujo ofrecido se reduce y el ensayo se vuelve a correr.
El throughput es la mxima tasa a la cual la cantidad de tramas transmitidas
por el DUT es la misma que la transmitida por el equipo de prueba. El ensayo
debe realizarse con los formatos y tamaos de tramas especificados (ver 4.8.1).
Presentacin de resultados:
Se DEBERA reportar en forma de grfica donde la coordenada x= tamao de la
trama, la coordenada y=la tasa de transmisin de las tramas. Se DEBERA
graficar tanto los valores tericos como los valores obtenidos en el ensayo.
Ejemplo: la grafica muestra los valores tericos, por ms detalles consultar RFC 2544
apndice B
Figura 4
Eje X: tamao de tramas (bytes)
Eje Y: cantidad de tramas por segundos (FPS)
4.3 Latency
Definicin (RFC 1242 tem 3.8):
Para dispositivos Store and Forward: El intervalo de tiempo comenzando
cuando el ltimo bit de la trama entrante alcanza el puerto de entrada y terminando
cuando el primer bit de la misma trama es visto en el puerto de salida.
Para dispositivos bit Forwarding: El intervalo de tiempo comenzando cuando
el final del primer bit de la trama entrante alcanza el puerto de entrada y terminando
cuando el comienzo del primer bit de la misma trama es visto en el puerto de salida.
Figura 5
Objetivo: medir la latencia segn RFC 1242.
Procedimiento:
Primero se determina el throughput del DUT para cada uno de los largos de
trama (ver 4.8.1). Se enva un flujo de datos de un particular tamao de trama
a travs del DUT al throughput que se determin anteriormente, hacia un
destino especfico. El flujo deber ser de por lo menos 120 segundos de
duracin. Un marcador (tag) deber ser incluido dentro de una trama luego de
los 60 segundos. El tiempo en el cual esta trama es completamente transmitida
se graba (marca de tiempo A). La lgica del receptor en el equipo de prueba
debe reconocer este marcador en el flujo de datos y grabar el tiempo en el cual
esta trama es recibida (marca de tiempo B).
La latencia es la resta de las marcas de tiempo B y A. Esta definicin sirve tanto
para dispositivos store and forward como para bit forwarding.
Esta prueba debe repetirse por lo menos 20 veces y reportar el valor medio de
los valores guardados.
Presentacin de resultados:
Se DEBERA presentar en forma de tabla con una columna para cada tipo de
tamao de trama.
Figura 6
Observacin: Esta medida es til para conocer el comportamiento del DUT en una
condicin de sobrecarga de la red, como se comportara el DUT frente a condiciones
patolgicas como ser por ejemplo tormentas de broadcast (broadcast storms).
Figura 7
Objetivo: medir el back-to-back frames definido segn RFC 1242.
Procedimiento:
Se enva una rfaga de tramas con el mnimo inter-frame gap al DUT y se
cuentan las tramas forwardeadas por el DUT. Si la cuenta de tramas
transmitidas es igual al nmero de tramas forwardeadas se incrementa el
largo de la rfaga y la prueba se vuelve a correr.
Si el nmero de tramas forwardeadas es menor que el nmero de tramas
transmitidas, se reduce el largo de la rfaga y la prueba se vuelve a correr.
El valor del back-to-back frames es el nmero de tramas con el mayor tamao
de rfaga para el cual el DUT puede manejarlas sin prdida de tramas.
La duracin de la prueba deber de ser por lo menos de 2 segundos y repetida
por lo menos 50 veces. El valor reportado deber ser el promedio de los valores
obtenidos.
Figura 8
Presentacin de resultados:
Se DEBERA presentar en forma de tabla con una columna para cada tamao de
trama que se prob. Se PUEDE reportar la desviacin estndar de cada medida.
Largo de tramas (bytes)
64
128
256
512
1024
1280
1518
Cantidad de tramas
37200
21112
11320
5872
2992
2395
2030
Observaciones:
Esta prueba intenta determinar la capacidad del buffer del DUT.
Figura 9
Existen una cantidad de dispositivos que pueden producir rfagas back-to-back
frames, como por ejemplo backup de sistemas (ejemplo rdump). En redes con
MTU pequeos (por ejemplo Ethernet) se deben transmitir muchos fragmentos,
dado que el proceso de reensamblado implica tener todos los fragmentos , la
perdida de uno de ellos puede causar un loop en el transmisor (con el
transmisor intentado enviar un bloque largo de datos).
4.6 System recovery
Objetivo: caracterizar la rapidez a la cual el DUT se repone de una situacin de
sobrecarga.
Procedimiento:
Primero se determina el throughput del DUT para cada tamao de trama
especificado. Luego se enva un flujo de datos a la tasa mnima entre: el 110%
del throughput o la mxima tasa para ese medio, durante al menos 60
segundos. A una marca de tiempo A determinado se reduce al 50% de la tasa
actual y se graba el tiempo de la ltima trama perdida (marca de tiempo B).
El tiempo de recuperacin se determina por la resta de las marcas de tiempo B
y A. La prueba DEBERA ser repetida un nmero de veces y el promedio de los
resultados deber ser reportado.
Figura 10
Presentacin de resultados:
Se DEBERA reportar en formato de tabla con una columna para cada tamao
de trama utilizado.
Largo de trama (bytes)
64
128
256
512
1024
1280
1518
4.7 Reset
Objetivo: Caracterizar la rapidez a la cual el DUT se recupera de un reset de hardware
o software.
Procedimiento:
Primero se determina el throughput del DUT para cada tamao de trama
especificado.
Luego se enva un flujo continuo de tramas al determinado throughput para el
mnimo largo de tramas. Causar un reset en el DUT. Monitorear la salida hasta
que las tramas comiencen a ser forwardeadas y guardar los tiempos en que la
ltima trama del flujo inicial (marca A) y la primera trama del siguiente flujo
(marca B) son recibidas. Esta prueba podr ser corrida utilizando tramas con
direcciones de redes directamente conectadas al DUT.
El valor de reset se obtiene de la resta de las marcas de tiempo B y A.
Figura 11
10
Presentacin de resultados:
El valor de reset podr ser reportado como un simple conjunto de valores, uno
para cada tipo de reset.
Tipo de reset
Hardware
Software
Corte de energa
11
Los siguientes trminos definidos en la RFC 2285 son de carcter general para las
pruebas listadas anteriormente:
12
Ejemplo:
Dispositivo de prueba
(Offered load)
14,880 fps - MOL
13,880 fps
12,880 fps
DUT/SUT
(Forwarding Rate)
7,400 fps - FRMOL
8,472 fps
12,880 fps - MFR
Figura 12
Objetivo: Determinar el throughput, frame loss y el forwarding rate ofrecidos al
DUT/SUT cuando el trafico es totalmente mallado segn RFC 2285.
13
Procedimiento:
Todos los puertos en el equipo de prueba DEBERA comenzar la transmisin de
tramas con una diferencia entre ellos de un 1% de la duracin de la prueba.
Cada puerto DEBE transmitir hacia los otros segn la siguiente secuencia (round
robin), ejemplo de seis puertos con una direccin por puerto:
Source Port
Port
Port
Port
Port
Port
Port
#1
#2
#3
#4
#5
#6
3
4
5
6
1
2
4
5
6
1
2
3
5
6
1
2
3
4
6
1
2
3
4
5
2...
3...
4...
5...
6...
1...
Observaciones:
Como se observa en la tabla existe una distribucin balanceada de la carga
sobre todas los puertos. De no seguir este algoritmo se producirn
inconsistencias en los resultados. Esta prueba no pretende simular trfico real.
Para pruebas que utilizan mltiples direcciones por puerto, el puerto de destino
es el mismo y el par de direcciones fuente/destino, deben de ser elegidas
14
Figura 13
Objetivo: Determinar el throughput ofrecido al DUT/SUT cuando el trafico es
parcialmente mallado segn RFC 2285.
Procedimiento:
Dependiendo de la direccin del trfico (one-to-many, many-to-one) algunos o
todos los puertos estarn transmitiendo. Todos los puertos en el equipo de
prueba DEBERA comenzar la transmisin de tramas con una diferencia entre
ellos de un 1% de la duracin de la prueba. La forma de transmitir las tramas
ser acorde al algoritmo de round robin.
El ensayo debe realizarse con los formatos y tamaos de tramas especificados
(ver 4.8.1).
Presentacin de resultados:
Se DEBERA presentar los resultados en forma de grfica, donde la coordenada
x=tamao de trama, y=resultado de la prueba (throughput).
Observaciones:
Trfico parcialmente mallado simula mejor conexiones de backbones que el
trfico totalmente mallado.
Ejemplo:
Forwarding Rate test
Direction = Reverse (One to Many)
Frame Length = 64
Offered Load = 544,212 bps (10.00% util)
Forwarding Rate = 14,880 frames/sec (10.00% util)
Offered Load = 1,632,636 bps (30.00% util)
15
Figura 14
Procedimiento:
Todos los puertos en el equipo de prueba DEBERA comenzar la transmisin de
tramas con una diferencia entre ellos de un 1% de la duracin de la prueba.
Cada puerto DEBE transmitir hacia los otros segn la secuencia de round robin.
El trfico local se PUEDE remover de la lista de round robin.
El ensayo debe realizarse con los formatos y tamaos de tramas especificados
(ver 4.8.1).
Presentacin de resultados:
Se DEBERA presentar los resultados en forma de grfica, donde la coordenada
x=tamao de trama, y=resultado de la prueba (throughput o forwarding rate).
Ejemplo:
Forwarding Rate Test
LocalTraffic = Yes
16
Frame Length = 64
Offered Load = 15,237,939 bps (20.00% util)
Forwarding Rate = 416,662 frames/sec (20.00% util)
Offered Load = 30,475,878 bps (40.00% util)
Forwarding Rate = 833,324 frames/sec (40.00% util)
Offered Load = 76,190,084 bps (100.00% util)
Forwarding Rate = 2,083,322 frames/sec (100.00% util)
MFR = 2,083,322 (frames/sec)
FRMOL = 2,083,322 (frames/sec) at MOL of 76,190,084 (bps) 100.00 (% util)
Throughput Test
LocalTraffic=No
Frame Length = 64
Throughput Test Parameters: Start = 100.0 Min = 0.0 Max = 100.0 Resolution = 0.5
Offered load = 76,190,084 bps (100.000% util)
Intended Load (ILoad) = 100.000% util Frame Loss
Rate = 28.5 (17,855,864 frames)
Offered load = 38,094,848 bps (50.000% util)
ILoad = 50.000% util
Frame Loss Rate = 0.000013 (4 frames)
Offered load = 19,047,219 bps (25.000% util)
ILoad = 25.000% util
Frame Loss Rate = 0.000006 (1 frames)
Offered load = 9,523,609 bps (12.500% util)
ILoad = 12.500% util
Frame Loss Rate = 0.000000 (0 frames)
Offered load = 16,368,844 bps (21.484% util)
ILoad = 21.484% util
Frame Loss Rate = 0.000000 (0 frames)
Binary search complete: Throughput is 16,368,844 bps (21.484% util)
Figura 15
Procedimiento:
Todos los puertos en el equipo de prueba DEBERA comenzar la transmisin de
tramas con una diferencia entre ellos de un 1% de la duracin de la prueba.
Cada puerto transmisor DEBE enviar tramas hacia todos los puertos receptores
segn la secuencia de round robin.
17
Procedimiento:
Figura 16
18
Esta prueba DEBE se debe realizar con mltiplos de cuatro puertos (dos puertos
de entrada y dos de salida) con el mismo MOL. Ambas fuentes transmisoras
DEBE transmitir el mismo nmero de tramas. La primera fuente DEBE de
transmitir tramas al MOL alternadamente a ambos puertos de recepcin. La
segunda fuente DEBE transmitir al MOL solamente al puerto congestionado. El
puerto sin congestin debe de recibir a una tasa igual al 50% de MOL. El puerto
congestionado debe de recibir a una tasa de entre 100 y 150% de MOL.
Las tramas destinadas al puerto sin congestin no deben de ser descartadas
debido a la congestin en otros puertos.
Presentacin de resultados:
La prueba DEBE reportar en el puerto no congestionado, el frame loss rate, el
FR (a 50% del Oload) y en el puerto congestionado el fame loss rate.
Observaciones:
Si el HOLB est presente los paquetes son encolados en el buffer del puerto de
entrada o en la placa de la matriz de conmutacin. Una conmutacin con HOLB
descartar paquetes destinados a puertos no congestionados, pudiendo haber
congestin en otros puertos.
Back pressure est definida como cualquier tcnica utilizada por el DUT/SUT
para evitar la prdida de tramas, impidiendo que las fuentes de trfico
transmitan tramas hacia fuentes congestionadas.
Si no hay control de congestin el porcentaje esperado de prdida de tramas en
el puerto congestionado es de 33% (a 150% de sobrecarga). Este puerto est
recibiendo 100% de un puerto y 50% del otro y solo puede sacar 100%.
(150 50) / 150.
Ejemplo:
Congestion Control Test
Frame Length = 64
Intended Load (ILoad) = 100.0
Port Block 1 (Ports: Port 1, Port 2, Port 3 and Port 4)
Transmit Port 1 Offered Load = 76,190,105 bps (100.00% util)
Transmit Port 2 Offered Load = 76,190,105 bps (100.00% util)
Port 1 Port 3 (uncongested) FR = 74,404 fps FLR = 0.00%
Port 1 Port 4 (congested) FR = 10,618 fps FLR = 85.73%
Port 2 Port 4 (congested) FR = 138,197 fps FLR = 7.13%
Head of line blocking not observed in any port blocks.
Back pressure not observed in any port blocks.
19
Procedimiento:
Figura 17
Forward Pressure: Esta prueba se realiza enviando trfico a una carga mayor
que la velocidad de lnea utilizando un IFG de 88 bits (el mnimo IFG definido en
el estndar IEEE 802.3 es de 96 bits). El DUT en el puerto de salida debe enviar
las tramas con un IFG de 96 bits, si transmite a un menor IFG se detecta
forward pressure.
Maximun Forwarding Rate: esta prueba es similar a la medida de FR descripta
en 5.1, sin embargo en este ensayo el mnimo FR utilizado debe ser el resultado
de la prueba de fully meshed throughput.
Presentacin de resultados:
Ejemplo
Forwarding Rate Test
Frame Length = 64
Offered Load = 12,499,968 bps (32.81% util)
Forwarding Rate = 341,796 frames/sec (32.81% util)
Offered Load = 14,404,608 bps (37.81% util)
Forwarding Rate = 393,876 frames/sec (37.81% util)
Offered Load = 16,309,452 bps (42.81% util)
Forwarding Rate = 445,961 frames/sec (42.81% util)
Offered Load = 35,357,081 bps (92.81% util)
Forwarding Rate = 966,795 frames/sec (92.81% util)
Offered Load = 37,261,721 bps (97.81% util)
Forwarding Rate = 1,018,875 frames/sec (97.81% util)
Offered Load = 38,095,032 bps (100.00% util)
Forwarding Rate = 1,041,661 frames/sec (100.00% util)
MFR = 1,041,661 frames/sec (100.000% util)
Note: Starting Offered load (in this case 32.81% for 64 byte frames) is equal to result of
throughput test in the test starting on Page 1 (Fully Meshed Throughput, Frame Loss and
Forwarding Rates). This should be derived for each frame size, per RFC 2889.
Forwarding Pressure Test
Port Pair: Port1 Port2
ILoad = 150,602 fps Max Theoretical ILoad = 148,809 fps FR = 146,439 fps
Forward pressure not observed.
20
Figura 18
Esta prueba DEBE de ser desarrollada por lo menos en una configuracin de
tres puertos. Un puerto de aprendizaje (Learning, Lport), otro de prueba (Test,
Tport) y otro de monitoreo (Monitor, Mport).
El Lport enva tramas de aprendizaje con direccin de origen variable y
direccin de destino fija, correspondiente al Tport. Al recibir tramas con
direccin de origen variable el DUT/SUT debe de aprender estas direcciones. Las
direcciones de origen DEBE de estar en orden secuencial.
El Tport debe de retornar las tramas aprendidas hacia el Lport.
El Mport escucha las tramas que son inundadas o las tramas perdidas.
Mediante un algoritmo de bsqueda binaria se determina el exacto nmero de
direcciones soportadas por puerto.
Presentacin de resultados:
Se DEBERIA presentar en forma de tabla incluyendo:
Nmero de direcciones usadas por cada iteracin de prueba (variable).
Iload utilizada para cada iteracin.
Nmero de tramas de prueba que fueron ofrecidas al Tport.
El contador de tramas de inundacin en el Tport. Si el nmero no es cero
significa que el DUT/SUT envi una trama de inundacin en la cual la
direccin de destino no estaba en la tabla.
Nmero de tramas correctamente enviadas al Lport durante la porcin
de la prueba (durante la iteracin).
El contador de tramas de inundacin en el Lport. Si el nmero no es cero
significa que el DUT/SUT envi una trama de inundacin en la cual la
direccin de destino no estaba en la tabla.
21
Ejemplo:
Address Caching Capacity Test
AddressCachingLoads is 2000:100:4096:1 (start:min:max:resolution)
Learning rate (Intended Load) is 50 fps
Age time is 300 seconds
Presentacin de resultados:
Igual que 5.7.
Ejemplo:
Address Learning Rate Test
22
23
Presentacin de resultados:
Para cada una de las condiciones antes mencionadas se DEBE decir si PASAN o
FALLAN. Para propsitos de diagnsticos los contadores de tramas actuales
PUEDE ser reportados.
Ejemplo:
Errored Frames Test
Frame Length = 64, 20.0% utilization
No-Error Frames Test: Passed
Undersize Frames Test: Passed
Oversize Frames Test: Passed
CRC Errors Test: Passed
Alignment Errors Test: Passed
Dribble Bits Test: Passed
Frame Length = 64, 30.0% utilization
No-Error Frames Test: Passed
Undersize Frames Test: Passed
Oversize Frames Test: Passed
CRC Errors Test: Passed
Alignment Errors Test: Passed
Dribble Bits Test: Passed
RFC 2889 Errored Frames Test
Duration = 30
24
Presentacin de resultados:
Se DEBE reportar en forma de grfica. La coordenada x = largo de trama, la
coordenada y = resultado de la prueba (throughput y latencia)
Ejemplo:
Broadcast Frames Throughput and Latency Test
Throughput Test Parameters: Start = 100.0 Min = 0.0 Max = 100.0 Res = 0.5
Frame Length = 64
Offered Load = 76,190,105 bps (100.00% util)
Frame Loss Rate = (0 frames)
Forwarding Rate = 148,808 fps (100.00% util)
Binary search complete:
Throughput is 76,190,105 bps (100.00% util)
Avg Latency is 183.585 microseconds
Frame Length = 128
Offered Load = 86,486,220 bps (100.00% util)
Frame Loss Rate = (0 frames)
Forwarding Rate = 84,459 fps (100.00% util)
Binary search complete:
Throughput is 86,486,220 bps (100.00% util)
Avg Latency is 172.883 microseconds
25
6. Instrumental disponible
Si bien las recomendaciones del BMWG apuntan a pruebas de laboratorio, hoy en da
se dispone de un variado tipo de instrumental, el cual permite realizar medidas de
laboratorio y medidas de campo, los mismos apuntan (segn corresponda) a realizar
medidas de conformidad (conformance) y de rendimiento (performance).
Se pretende brindar un breve descriptivo de los instrumentos disponibles, pueden
existir excepciones a lo expuesto.
Bsicamente, se pueden clasificar en tres categoras de instrumentos, las mismas se
realizaron en base a la portabilidad, funcionalidades de los instrumentos y costo:
Categoras de instrumentos:
Instrumentos de mano
Instrumentos de campo
Instrumentos de laboratorio
6.1 Instrumentos de mano
Instrumentos con pocas interfaces disponibles (no ms de dos), en general no se
permiten pruebas simultneas en ambas interfaces (ej.: no se puede utilizar el puerto
Ethernet y el GbE al mismo tiempo).
Comnmente permiten realizar cuatro de las 6 pruebas descriptas en la RFC 2544, a
saber: Throughput, Latency, Frame loss rate y Back-to-back frames, no miden System
recovery y Reset.
No permiten medir acorde a la RFC 2889.
Permiten un monitoreo de red, pero no husmear la misma (sniffer).
Pensados para pruebas de conectividad de red (no certificacin de cableado),
transmisin de paquetes, etc.
26
27
28
Ejemplo:
instrumental
laboratorio, en general requieren
Terminal
(externo)
para
configuracin y presentacin
datos.
Tipo de prueba
Throughput
Frame Loss
Rate
Latency
Back-to-Back
Frames
System
Recovery
Tiempo de
medida
10 seg
10 seg
Cantidad de
ensayos
10 veces
5 veces
Tamao de
tramas
7 tipos
7 tipos
11min 40 seg
5 min 50 seg
120 seg
2 seg
20 veces
10 X 50
veces
10 veces
7 tipos
7 tipos
4hs 40 min
1hs 57 min
7 tipos
1hs 16 min
60 seg
de
un
la
de
Tiempo Total
29
7 Referencias
[1] http://www.isd.mel.nist.gov/projects/openarch/Jun_2002/EthernetIP_Perf_Metrics_2002-06-
04.pdf.
[2] http://www.ieee802.org/802_tutorials/march04/WPP_tutorial_03_15_04_v01.ppt.
Layer2_Testing.pdf
[4] Ixia (http://www.ixiacom.com/library/white_papers/), Border Gateway Protocol (BGP):
Conformance and Performance Testing, Open Shortest Path First (OSPF): Conformance and
Performance Testing
[5] Sunrise telecom (http://www.sunrisetelecom.com/)
[6] IETF-drafts (Internet Engineering Task Force)
charter.html)
(http://132.151.1.19/html.charters/bmwg-
30