Mediciones Redes Rfc2544

5/12/2018 MEDICIONESREDESRFC2544-slidepdf.
com
Curso de Evaluación de pérformance de Redes
Medidas a realizar en dispositivos de redes
1 Conceptos previos sobre mediciones .................................................................... 2

1.1 Conformance vs. Performance ........................................................... 2
1.2 Dos visiones sobre la creación de estándares de pruebas ...................... 2
2 Introducción...................................................................................................... 2
3 Tareas realizadas por el BMWG............................................................................ 3
4 Terminología y metodología de pruebas según RFC 1242 y RFC 2544 ....................... 3

4.1 Arquitectura de pruebas (RFC 2544 ítem 6) ......................................... 3
4.2 Throughput ..................................................................................... 5
4.3 Latency........................................................................................... 6
4.4
4.5 Frame loss rate
Back-to-back ...............................................................................
frames 7
........................................................................ 8
4.6 System recovery .............................................................................. 9
4.7 Reset.............................................................................................10
4.8 Consideraciones generales ...............................................................11
4.8.1 Formato y tamaño de trama .....................................................11
4.8.2 Verificación de tramas recibidas................................................11
4.8.3 Modificadores .........................................................................11
4.8.4 Direcciones de protocolo ..........................................................12
5 Terminología y metodología de pruebas según RFC 2285 y RFC 2889......................12

5.1 Fully meshed throughput, frame loss and forwarding rate ....................13
5.2 Partially meshed one-to-many/many-to-one .......................................15
5.3 Partially meshed multiple devices ......................................................16
5.4 Partially meshed unidirectional traffic.................................................17
5.5 Congestion Control ..........................................................................18
5.6 Forward Pressure and Maximum Forwarding Rate ..............................19
5.7 Address caching capacity ................................................................21
5.8 Address learning rate.......................................................................22
5.9 Errored frames filtering ....................................................................23
5.10 Broadcast frame Forwarding and Latency .........................................25
6 Instruemntal diponible.......................................................................................26
6.1 Instrumentos de mano.....................................................................26
6.2 Instrumentos de campo ...................................................................28
6.3 Instrumentos de laboratorio .............................................................28
7 Referencias ......................................................................................................31
http://slidepdf.com/reader/full/mediciones-redes-rfc2544 1/30
5/12/2018 MEDICIONESREDESRFC2544-slidepdf.com
1 Conceptos previos sobre mediciones
1.1 Conformance vs. Performance

Existen dos grandes grupos de tipos de medidas, de conformidad ( conformance) y de
rendimiento ( performance). La conformidad permite comprobar si un dispositivo
cumple con las recomendaciones, el rendimiento, nos dice que tan bien se comporta el
equipo bajo diferentes condiciones. Por ejemplo eligiendo un grupo de dispositivos
todos ellos pueden “pasar” las pruebas de conformidad, pero con las pruebas de
rendimiento se puede comparar los dispositivos. [1]
Pruebas de conformance Pruebas de performance

¿Envía y recibe los mensajes en el formato ¿Realiza correctamente la priorización de
correcto? mensajes?
¿El dispositivo se apaga al recibir un mensaje
inapropiado? ¿Con alta caga de tráfico continúa
funcionando?
¿Realiza la tarea deseada? ¿Bloquea comunicaciones no deseadas?
1.2 Dos enfoques sobre la creación de estándares de pruebas
• Internet Engineering Task Force (IETF) en el grupo Benchmarking Methodology

Working Group (BMWG): el enfoque se basa en la creación de dos tipos de
documentos, de terminología (define las características funcionales relevantes)
y de metodología de pruebas.
• MEF (Metro Ethernet Forum) y el ATM Forum: son basados en la ratificación de
estándares, todas las pruebas hacen referencia al estándar en cuestión.
El método utilizado por el IETF (BMWG) se considera más apropiado para medidas de
performance, mientras que el utilizado por el MEF y el ATM Forum se considera más
apropiado para medidas de conformance. [2]
2 Introducción
Se analizarán definiciones y medidas a realizar en dispositivos de redes, basándose en

las RFC’s propuestas por el IETF (BMWG), las medidas apuntan a poder describir el
rendimiento ( performance) de un equipo bajo prueba DUT ( device under test ). El
análisis se basará en cuatro FRC’s:
• Definición de términos utilizados
o
o
RCF
RFC 1242 (Benchmarking Terminology
2285 (Benchmarking Terminology for
for LAN
Network Interconnection
Switching Devices) Devices)

• Pruebas a realizar
RFC 2544 (Benchmarking Methodology for Network Interconnect Devices)
o
RFC 2889 (Benchmarking Methodology for LAN Switching Devices)

o
Posteriormente se hará un estudio (teórico) del instrumental disponible para realizar

este u otro tipo de pruebas, analizando los posibles campos de aplicación.
Al final del trabajo se presentan medidas realizadas sobre equipos utilizando algunas
de las medidas recomendadas en la RFC 2544.
3 Tareas realizadas por el BMWG
La principal meta
concerniente del BMWG
a medidas es de realizar
de performance una serie
en tecnologías de de recomendaciones
interredes en lo
( internetworking
technologies) más aún estas recomendaciones se pueden enfocar en los sistemas o
servicios que son construidos por estas tecnologías.
Cada recomendación describirá:

La clase de equipo, sistema, o servicio brindado.
•
Discutirá las características de performance correspondiente a cada clase.

•
Deberá identificar claramente el tipo de medida.

•
Deberá brindar los requerimientos para la presentación de los resultados

•
obtenidos, en un formato común y no ambiguo.
El alcance del BMWG está limitado a la caracterización de la tecnología utilizada

mediante estímulos simulados en ambientes de laboratorio. En otras palabras el BMWG
no pretende producir benchmarks para redes operacionales.
4 Terminología y metodología de pruebas según RFC 1242 y RFC 2544
La RFC 2544 discute y define un número de pruebas que pueden ser utilizadas para
describir y comparar las características de performance de dispositivos de
interconexión de redes. Asimismo describe los formatos para el reporte de los
resultados de las pruebas.
Este trabajo se centrará en las pruebas de rendimiento ( Benchmarking tests)
descriptas en la RFC 2544 (ítem 26):
•
Throughput (ítem 26.1)
• Latency (ítem 26.2)
• Frame loss rate (ítem 26.3)
• Back-to-back frames (ítem 26.4)
• System recovery (ítem 26.5)
• Reset (ítem 26.6)
Los siguientes términos definidos en mayúscula tienen un significado particular
• DEBE (MUST ): el ítem es obligatorio.
• DEBERÍA (SHOULD): el ítem es recomendado, pueden existir motivos para
ignorar el ítem en ciertas circunstancias, de ser así debe de ser estudiado
cuidadosamente.
• PUEDE (MAY ): el ítem es opcional, se puede llegar a omitir el ítem.
4.1 Arquitectura de pruebas (RFC 2544 ítem 6)
La manera ideal de implementar las pruebas es usar un equipo de prueba ( tester ) con
puertos de transmisión y recepción, es la arquitectura recomendada (ver figura 1). De
ser así el equipo de prueba puede determinar si todos los paquetes transmitidos fueron
recibidos y verificar que los paquetes correctos sean recibidos.
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
algún modo que
ser imposibles desimulen
realizar un
conúnico equipo de
la precisión prueba ciertas
necesaria, medidas
por ejemplo: pueden
para llegarde
la prueba a
latencia (latency ) deben de estar sincronizados mediante una unidad externa (ejemplo
GPS) o sincronizados directamente (ejemplo mediante cable coaxial).
Figura 2
Es posible
modelo realizar
a un sistemalasde
pruebas
DUT´s más allá de un DUT
interconectados por (RFC 2544 ítem 19) extendiendo el
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
Definición (RFC 1242 ítem 3.17): La máxima tasa a la cual ninguna de las tramas
ofrecidas es descartada por el dispositivo.
Objetivo: Medir el throughput según RFC 1242.
Procedimiento:
Enviar un número específico de tramas a una tasa específica a través 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 máxima 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 tamaños de tramas especificados (ver 4.8.1).
Presentación de resultados:
Se DEBERÍA reportar en forma de gráfica donde la coordenada x = tamaño de la
trama, la coordenada y =la tasa de transmisión de las tramas. Se DEBERÍA
graficar tanto los valores teóricos como los valores obtenidos en el ensayo.
Ejemplo: la grafica muestra los valores teóricos, por más detalles consultar RFC 2544
apéndice B
Figura 4
Eje X: tamaño de tramas (bytes)

Eje Y: cantidad de tramas por segundos (FPS)
4.3 Latency
Definición (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 según RFC 1242.
Procedimiento:
Primero se determina el throughput del DUT para cada uno de los largos de
trama (ver 4.8.1). Se envía un flujo de datos de un particular tamaño de trama
a través del DUT al throughput que se determinó anteriormente, hacia un
destino específico. El flujo deberá ser de por lo menos 120 segundos de
duración. 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 lógica 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 definición 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.
Se DEBERÍA presentar en forma de tabla con una columna para cada tipo de
tamaño de trama.
Observación: si se utilizan dos instrumentos para la medición de la latencia, estos

deben de estar sincronizados entre sí.
Ejemplo: [3]
Largo de trama (bytes) Tramas por segundo (FPS) Store & Forward Latency (us)
64 13000 450
128 8200 480
256 4500 502
512 2349 562
1024 1197 658
1280 958 704
1518 812 775
4.4 Frame loss rate
Definición (RFC 1242 ítem 3.6): Porcentaje de tramas que deberían ser enviadas
(forwarded) por un dispositivo de red bajo estado estacionario de carga (constante)
pero no son enviadas (forwarded) por la falta de recursos.
Objetivo: Medir la tasa de pérdida de tramas según RFC 1242.
Procedimiento:
Se envía un específico número de tramas a una tasa específica a través del DUT
y se cuentan cuantas tramas son transmitidas por el DUT. La tasa de pérdida de
tramas se calcula como:
( (contador_entrada – contador_salida) * 100 ) / contador_entrada
El primertasa
máxima ensayo será para
del medio la tasa para
de entrada, de tramas que corresponde
cada tamaño al 100%
de trama (ver 4.8.1).de la
Se repite el procedimiento para la tasa que corresponde al 90% del máximo
utilizado y luego para el 80% de esta tasa. Esta secuencia continuará
(reduciendo en intervalos del 10%) hasta que hallan dos pruebas exitosas en
las cuales no se encuentren tramas perdidas.
Se DEBERÍA reportar en forma de gráfica. El eje de las X deberá ser la tasa de
tramas de entrada, como un porcentaje de la tasa teórica para el medio, a un
específico tamaño de trama. El eje de las Y deberá ser el porcentaje de pérdidas
de tramas para una específica tasa de entrada.
Figura 6
Observación: Esta medida es útil para conocer el comportamiento del DUT en una
condición de sobrecarga de la red, como se comportaría el DUT frente a condiciones
patológicas como ser por ejemplo tormentas de broadcast ( broadcast storms).
4.5 Back-to-back frames
Definición (RFC 1242 ítem 3.1): Tramas de un mismo largo, enviadas a una tasa para
la cual hay una separación legalmente mínima entre tramas, para un medio dado,
durante un período de tiempo, comenzando desde el estado inactivo (idle time).
Figura 7
Objetivo: medir el back-to-back frames definido según RFC 1242.
Procedimiento:
Se envía una ráfaga de tramas con el mínimo inter-frame gap al DUT y se
cuentan las tramas “forwardeadas” por el DUT. Si la cuenta de tramas
transmitidas es igual al número de tramas “forwardeadas” se incrementa el
largo de la ráfaga y la prueba se vuelve a correr.
Si el número de tramas “forwardeadas” es menor que el número de tramas
transmitidas, se reduce el largo de la ráfaga y la prueba se vuelve a correr.
El valor del back-to-back frames es el número de tramas con el mayor tamaño
de ráfaga para el cual el DUT puede manejarlas sin pérdida de tramas.
La duración 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
Se DEBERÍA presentar en forma de tabla con una columna para cada tamaño de
trama que se probó. Se PUEDE reportar la desviación estándar de cada medida.
Largo de tramas (bytes) Cantidad de tramas
64 37200
128 21112
256 11320
512 5872
1024 2992
1280 2395
1518 2030
Observaciones:
Esta prueba intenta determinar la capacidad del buffer del DUT.
Figura 9
Existen una cantidad de dispositivos que pueden producir ráfagas back-to-back

frames, como por ejemplo backup de sistemas (ejemplo rdump). En redes con
MTU pequeños (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 situación de
sobrecarga.
Procedimiento:
Primero se determina el throughput del DUT para cada tamaño de trama
especificado. Luego se envía un flujo de datos a la tasa mínima entre: el 110%
del throughput o la máxima 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 recuperación se determina por la resta de las marcas de tiempo B
y A. La prueba DEBERÍA ser repetida un número de veces y el promedio de los
resultados deberá ser reportado.
Figura 10
Se DEBERÍA reportar en formato de tabla con una columna para cada tamaño
de trama utilizado.
Largo de trama (bytes) Tramas por segundo (FPS) Recovery Time (us)
64 14300 2800
128 8445 2750
256 4528 2730
512 2349 2730
1024 1197 2720
1280 958 2720
1518 812 2720
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 tamaño de trama
especificado.
Luego se envía un flujo continuo de tramas al determinado throughput para el
mínimo 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
El valor de reset podrá ser reportado como un simple conjunto de valores, uno
para cada tipo de reset.
Tipo de reset Tiempo de reset (segundos)
Hardware 6.3
Software 3.1
Corte de energía 6.7
4.8 Consideraciones generales
Para las pruebas antes mencionadas, la RFC 2544 especifica un conjunto de

consideraciones a tener en cuenta. A continuación se mencionan las más importantes.
4.8.1 Formato y tamaño de tramas (RFC 2544 ítems 8 y 9)

Por ejemplo, para TCP/IP sobre Ethernet, se utilizarán paquetes UDP (los DUT pueden
descartar tramas que no incluyan una cabecera de capa 4 válida, ver Apéndice C.2.1
RFC 2544), con tamaños de tramas entre 64 y 1518 bytes. Los valores recomendados
en la RFC para los tamaños de trama son 64, 128, 256, 512, 1024, 1280 y 1518 bytes.
4.8.2 Verificación de tramas recibidas (RFC 2544 ítem 10)

El equipo de prueba no deberá incluir para sus resultados, tramas que no
correspondan a las tramas de pruebas. Por ejemplo los update de routing no deben ser
incluidos en la cuenta de tramas recibidas. Preferentemente el equipo de prueba
deberá incluir un número de secuencia en las tramas transmitidas y verificar estos
números en las tramas recibidas. De ser así el reporte de los resultados debe incluir el
número de tramas descartadas, fuera de orden y cantidad de tramas duplicadas.
4.8.3 Modificadores (RFC 2544 ítem 11)
Para las pruebas se deben de tener en cuenta las posibles funcionalidades disponibles
en el DUT y corroborar que estas funcionen correctamente. La RFC recomienda correr
todas las pruebas con y sin modificadores separadamente. Las funcionalidades a tener
en cuenta son:
•
Manejo de con
tramas de broadcast : determinar si hay algún efecto
de tramas la presencia de tramas de broadcast (1% del totalen
delatramas).
tasa de envío

• Manejo de tramas de gestión: determinar que el DUT responde correctamente este
tipo de tramas (se envía una trama por segundo).

• Manejo de tramas de routing updates: determinar que al modificar de las tablas de
ruteo no se vea afectada la tasa de envío (se envía una trama de routing update
acorde al protocolo, por ejemplo en RIP cada 30 segundos, OSPF cada 90
segundos).

• Manejo de filtros: determinar si el manejo de filtros en el DUT impacta
negativamente en la tasa de envío de tramas (se utilizan el rango de direcciones IP
asignadas al BMWG).
11
4.8.4 Direcciones de protocolo (RFC 2544 ítems 12, 14 y 16)
Las pruebas deberán ser realizadas utilizando tanto un único direccionamiento como
múltiples direcciones. Por
toman aleatoriamente de ejemplo en el de
un conjunto, casoesta
de IP, las direcciones
manera se prueba deel destino
motor dese
búsqueda de rutas.
• Direccionamiento de tráfico. Diferenciar entre tráfico bidireccional y unidireccional.
• Pruebas de multipuerto. Se envían tramas desde todos los puertos de entrada
hacia todos los puertos de salida, con una secuencia definida. De esta forma se
busca que el DUT maneje (como en el mundo real) varios paquetes direccionados
hacia un mismo puerto.
5 Terminología y metodología de pruebas según RFC 2285 y RFC 2889
Extiende la metodología definida en la RFC 2544 para dispositivos de capa 2,

dispositivos que manejan la conmutación de tramas en la capa de Control de Acceso al
Medio (capa MAC). Asimismo se describen formatos específicos para el reporte de los
resultados de las pruebas.
Este trabajo se centrará en las pruebas de rendimiento ( Benchmarking tests)
descriptas en la RFC 2889 (ítem 5):
• Fully meshed throughput, frame loss and forwarding rates (ítem 5.1)
• Partially meshed one-to-many/many-to-one (ítem 5.2)
• Partially meshed multiple devices (ítem 5.3)
• Partially meshed unidirectional traffic (ítem 5.4)
• Congestion Control (ítem 5.5)
• Forward Pressure and Maximum Forwarding Rate (ítem 5.6)
• Address caching capacity (ítem 5.7)
•
Address learningfiltering
rate (ítem 5.8)

• Errored frames (ítem 5.9)

• Broadcast frame Forwarding and Latency (ítem 5.10)
Los siguientes términos definidos en la RFC 2285 son de carácter general para las
pruebas listadas anteriormente:

• Loads (ítem 3.5)
o Intended load (Iload): El número de FPS que una fuente externa intenta
transmitir al DUT/SUT para ser enviadas a una interfase de salida
específica.
o Offered load (Oload): El número de FPS que una fuente externa puede
transmitir al DUT/SUT para ser enviadas a una interfase de salida
específica.
o Maximum offered load (MOL): El máximo número de FPS que una fuente
externa puede transmitir al DUT/SUT para ser enviadas a una interfase
de salida específica.
o Overloading: intento de carga al DUT/SUT por encima de la tasa máxima
de transmisión permitida por el medio.
Observaciones: es importante diferenciar la carga que una fuente externa

intenta aplicar al DUT/SUT con la carga observada o medida que realmente se
aplica. Las colisiones o los mecanismos de control de congestión pueden afectar
la tasa de transmisión que una fuente externa transmite al DUT/SUT.
12
La máxima carga permitida por el medio puede ser mayor a la que un

dispositivo externo puede aplicar al DUT/SUT.
Forwarding rates (ítem

rate3.6)
•
o Forwarding (FR): el número de FPS que un DUT/SUT puede

transmitir correctamente a las interfaces de destino dada una carga
ofrecida.
o Forwarding rate at maximum offered load (FRMOL): el número de FPS
que un DUT/SUT puede transmitir correctamente a las interfaces de
destino a la máxima carga ofrecida.
o Maximum forwarding rate (MFR): la tasa de envío más alta de un
DUT/SUT tomada de un conjunto interactivo de medidas de tasa de
envío.
Observaciones: la tasa de envío a la máxima ofrecida puede ser menos que la
máxima tasa que un dispositivo puede enviar exitosamente.
La tasa de envío de un dispositivo puede degradarse antes que la carga máxima
sea alcanzada.
Ejemplo:
Dispositivo de prueba DUT/SUT
(Offered load) (Forwarding Rate)
14,880 fps - MOL 7,400 fps - FRMOL
13,880 fps 8,472 fps
12,880 fps 12,880 fps - MFR
5.1 Fully meshed throughput, frame loss and forwarding rate

Definición (RFC 2285: ítem 3.1) Fully Meshed traffic: tramas ofrecidas a un designado
número de interfaces de un DUT/SUT, las cuales cada una de ellas recibe tramas de
todas las otras interfaces bajo prueba.
Figura 12
Objetivo: Determinar el throughput, frame loss y el forwarding rate ofrecidos al

DUT/SUT cuando el trafico es totalmente mallado según RFC 2285.
13
Procedimiento:
Todos los puertos en el equipo de prueba DEBERÍA comenzar la transmisión de
tramas con una diferencia entre ellos de un 1% de la duración de la prueba.
Cada
robin),puerto DEBE
ejemplo de transmitir hacia
seis puertos conlos
unaotros segúnpor
dirección la siguiente
puerto: secuencia (round
Source Port Destination Ports (in order of transmission)
Port #1 2 3 4 5 6 2...
Port #2 3 4 5 6 1 3...
Port #3 4 5 6 1 2 4...
Port #4 5 6 1 2 3 5...
Port #5 6 1 2 3 4 6...
Port #6 1 2 3 4 5 1...
El ensayo debe realizarse con los formatos y tamaños de tramas especificados

(ver 4.8.1).
Se DEBERÍA presentar los resultados en forma de gráfica, donde la coordenada
x=tamaño de trama, y=resultado de la prueba (throughput, frame loss o el
forwarding rate)
Ejemplo:
Forwarding Rate Test
Frame Length = 64
Offered Load = 15,237,939 bps (20.00% util)
Forwarding Rate = 416,656 frames/sec (20.00% util)
ForwardingForwarding
Maximum Rate = 2,083,322 frames/sec
Rate (MFR) (100.00%
= 2,083,322 util)
(frames/sec)
Forwarding Rate at Maximum Offered Load (FRMOL) = 2,083,322 (frames/sec) at MOL of
76,190,084 (bps) 100.00 (% util)
Throughput Test
(Start = 100.0 Min = 0.0 Max = 100.0 Resolution = 0.5)
Frame Length = 64
Throughput test parameters: Start = 100.0 Min = 0.0 Max = 100.0 Res = 0.5
Offered load = 76,190,084 bps (100.000% util) ILoad = 100.000% util
Frame Loss Rate = 0.000002 (1 frame)
Frame Loss Rate = 0.000003 (1 frame)
Frame Loss Rate = 0.000000 (0 frames)
Frame
Binary Loss Rate
search = 0.000005
complete: (1 frame)
Throughput is 24,999,936 bps (32.813% util)
Observaciones:
Como se observa en la tabla existe una distribución balanceada de la carga

sobre todas los puertos. De no seguir este algoritmo se producirán
inconsistencias en los resultados. Esta prueba no pretende simular tráfico real.
Para pruebas que utilizan múltiples direcciones por puerto, el puerto de destino
es el mismo y el par de direcciones fuente/destino, deben de ser elegidas
14
aleatoriamente, para ejercitar la habilidad del DUT/SUT de buscar en las tables

de direcciones.
5.2 Partially meshed one-to-many/many-to-one

Definición (RFC 2285: ítem 3.3.2): Partially Meshed traffic: tramas ofrecidas hacia una
o más interfaces de entradas del DUT/SUT y direccionadas hacia una o más interfaces
de salida, donde las interfaces son mutuamente excluyentes y mapeadas en las formas
one-to-many, many-to-one or many-to-many (ver figura 13)
Figura 13
Objetivo: Determinar el throughput ofrecido al DUT/SUT cuando el trafico es
parcialmente mallado según RFC 2285.
Procedimiento:
Dependiendo de la dirección del tráfico (one-to-many, many-to-one) algunos o
todos los puertos estarán transmitiendo. Todos los puertos en el equipo de
prueba DEBERÍA comenzar la transmisión de tramas con una diferencia entre
ellos de un 1% de la duración de la prueba. La forma de transmitir las tramas
será acorde al algoritmo de round robin.
(ver 4.8.1).
Se DEBERÍA
x=tamaño depresentar los resultados
trama, y=resultado de laenprueba
forma (throughput).
de gráfica, donde la coordenada
Observaciones:
Tráfico parcialmente mallado simula mejor conexiones de backbones que el
tráfico totalmente mallado.
Ejemplo:
Forwarding Rate test
Direction = Reverse (One to Many)
Frame Length = 64
Offered Load = 544,212 bps (10.00% util)
15

MFR = 148,808 (frames/sec)
FRMOL = 148,808 (frames/sec) at MOL of 5,442,150 (bps) 100.00 (% util)
Forwarding Rate test
Direction = One (Many to One)
Frame Length = 64
Maximum Forwarding Rate (MFR) = 145,587 (frames/sec)
Forwarding Rate at Maximum Offered Load (FRMOL) = 145,587 (frames/sec) at MOL of
5,659,501(bps) 8.00 (% util)
5.3 Partially meshed multiple devices
Objetivo: medir el throughput y el forwarding rate ofrecidos de dos DUT equipados con
múltiles puertos e interconectados por un puerto de alta velocidad ( high speed
backbone uplink ), por ejemplo GbE, ATM, SDH/SONET.
Figura 14
Procedimiento:
tramas
Cada con una
puerto DEBEdiferencia entre
transmitir ellos
hacia losde un 1%
otros de la
según la secuencia
duración de
delaround
prueba.
robin.
El tráfico local se PUEDE remover de la lista de round robin.
(ver 4.8.1).
x=tamaño de trama, y=resultado de la prueba (throughput o forwarding rate).
Ejemplo:
LocalTraffic = Yes
16
Frame Length = 64
Forwarding
Offered LoadRate = 833,324 bps
= 76,190,084 frames/sec (40.00%
(100.00% util) 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)
ILoad = 50.000% util
Binary search complete: Throughput is 16,368,844 bps (21.484% util)
5.4 Partially meshed unidirectional traffic
Objetivo: Determinar
puertos el DUT/SUT el throughput
están ofrecido
enviando tramas al DUT/SUT
a la otra mitad de cuando la mitad
los puertos. de los
Figura 15
Procedimiento:
tramas con una diferencia entre ellos de un 1% de la duración de la prueba.
Cada puerto transmisor DEBE enviar tramas hacia todos los puertos receptores
según la secuencia de round robin.
17

(ver 4.8.1).
x=tamaño de trama, y=resultado de la prueba (throughput o forwarding rate).
Ejemplo:
Frame Length = 64
MFR = 1041661 (frames/sec)
FRMOL = 1041661 (frames/sec) at MOL of 38,095,052 (bps) 100.00 (% util)
Throughput Test
Frame Length = 64
Throughput Test Parameters: Start = 100.0 Min = 0.0 Max = 100.0 Resolution = 0.5
Intended Load (ILoad) = 100.000% util
Binary search complete: Throughput is 38,095,052 bps (99.999% util)
5.5 Congestion Control
Objetivo: Determinar como el DUT maneja la congestión en los siguientes casos:

• Como el DUT implementa el control de congestión
• Como la congestión en un puerto afecta el tráfico de puertos no congestionados
Este procedimiento determina si están presentes los mecanismos de control de
congestión head of line blocking (HOLB) y/o back pressure.
Procedimiento:
Figura 16
18
Esta prueba DEBE se debe realizar con múltiplos de cuatro puertos (dos puertos
de entrada y dos de salida) con el mismo MOL. Ambas fuentes transmisoras
DEBE transmitir el mismo número de tramas. La primera fuente DEBE de
transmitir tramas
segunda fuente al MOL
DEBE alternadamente
transmitir a ambosal puertos
al MOL solamente de recepción. La
puerto congestionado. El
puerto sin congestión 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 congestión no deben de ser descartadas
debido a la congestión en otros puertos.
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 conmutación. Una conmutación con HOLB
descartará paquetes destinados a puertos no congestionados, pudiendo haber
congestión en otros puertos.
Back pressure está definida como cualquier técnica utilizada por el DUT/SUT
para evitar la pérdida de tramas, impidiendo que las fuentes de tráfico
transmitan tramas hacia fuentes congestionadas.
Si no hay control de congestión el porcentaje esperado de pérdida 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.
5.6 Forward Pressure and Maximum Forwarding Rate
Objetivo:
La prueba de Forward Pressure sobrecarga un puerto del DUT/SUT y mide la
salida para la forward pressure. Si el DUT/SUT transmite con interframe gap
menor a 96 bits, existe forward pressure.
La prueba de Maximun Forwarding Rate mide el valor de pico de la FR cuando la

carga varía entre el valor del throughput (hallado en 5.1) y el MOL.
19
Procedimiento:
Figura 17
Forward Pressure: Esta prueba se realiza enviando tráfico a una carga mayor
que la velocidad
el estándar IEEE de líneaesutilizando
802.3 un IFG
de 96 bits). de 88
El DUT en bits (el mínimo
el puerto IFG debe
de salida definido en
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 mínimo FR utilizado debe ser el resultado
de la prueba de fully meshed throughput.
Ejemplo
Frame
OfferedLength
Load ==12,499,968
64 bps (32.81% 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
5.7 Address caching capacity
Definición (RFC 2285: ítem 3.8.1):Es número de direcciones MAC que el DUT/SUT
puede almacenar y enviar correctamente tramas hacia el destino sin perder tramas y
sin inundar. Este número se pude dar en función de la cantidad de interfaces, por
módulo o por dispositivo.
Objetivo: Determinar Address caching capacity según RFC 2285.
Procedimiento:
Figura 18
Esta prueba DEBE de ser desarrollada por lo menos en una configuración de

tres puertos. Un puerto de aprendizaje (Learning, Lport), otro de prueba (Test,
Tport) y otro de monitoreo (Monitor, Mport).
El Lport envía tramas de aprendizaje con dirección de origen variable y
dirección de destino fija, correspondiente al Tport. Al recibir tramas con
dirección 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 búsqueda binaria se determina el exacto número de
direcciones soportadas por puerto.
Se DEBERIA
•
presentar en forma de tabla incluyendo:
Número de direcciones usadas por cada iteración de prueba (variable).
• Iload utilizada para cada iteración.
• Número de tramas de prueba que fueron ofrecidas al Tport.
• El contador de tramas de inundación en el Tport. Si el número no es cero
significa que el DUT/SUT envió una trama de inundación en la cual la
dirección de destino no estaba en la tabla.
• Número de tramas correctamente enviadas al Lport durante la porción
de la prueba (durante la iteración).
• El contador de tramas de inundación en el Lport. Si el número no es cero
significa que el DUT/SUT envió una trama de inundación en la cual la
dirección de destino no estaba en la tabla.
21
• El contador de tramas de inundación en el Mport.
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
5.8 Address learning rate
Objetivo: Determinar la tasa de aprendizaje de direcciones de un dispositivo de

conmutación (LAN switching device).
Procedimiento:
Se utiliza la misma configuración que en 5.7. Un algoritmo similar al visto en
5.7 para determinar el address caching capacity, es utilizado para determinar el
address learning rate. Esta prueba itera la tasa a la cual las tramas de
aprendizaje son enviadas. Se recomienda configurar el número de direcciones
enviadas como el máximo caching capacity.
Igual que 5.7.
Ejemplo:
Address Learning Rate Test
22
5.9 Errored frames filtering

Objetivo: Determinar el comportamiento del DUT bajo condiciones anormales o frente
a tramas con errores. El resultado de la prueba indica si el DUT/SUT filtra los errores o
simplemente propaga las tramas con errores hacia el destino.
Procedimiento:
Cada una de las siguientes tramas ilegales para Ethernet deben de ser
chequeadas:
• Oversize: El DUT/SUT PUEDE filtrar tramas mayores a 1518 bytes de
largo. Tramas con un tamaño mayor al estándar no se deberían enviar.
DUT/SUT que soportan tramas marcadas (tagged) PUEDE enviar tramas
hasta incluso 1522 bytes de largo.
• Undersize: El DUT/SUT DEBE filtrar tramas menores a 64 bytes de largo
para que no sean propagadas a través del DUT/SUT.
• CRC Errors: El DUT/SUT DEBE filtrar tramas cuyo chequeo de validación
de secuencia es erróneo.
• Dribble Bit Errors: El DUT/SUT DEBE corregir y enviar tramas que
contengan dribbling bits. Tramas transmitidas hacia el DUT/SUT que no
terminan en un octeto límite, pero contienen un control de secuencia
válido DEBE de ser aceptada por el DUT/SUT y transmitida hacia el
correcto puerto de salida con el final de la trama terminando en un
• octeto límite.
Aligment Errors: El DUT/SUT DEBE filtrar tramas cuyo chequeo de
validación de secuencia y no terminan en un octeto límite. Esto es un
combinación de errores de CRC y errores de dribble bits.
23
Para cada una de las condiciones antes mencionadas se DEBE decir si PASAN o
FALLAN. Para propósitos de diagnósticos 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
DribbleLength
Frame Bits Test: Passed
= 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
5.10 Broadcast frame Forwarding and Latency
Objetivo:
broadcast.Determinar
el throughput y la latencia de un DUT cuando se envía tráfico de
Procedimiento:
Ser deberán correr dos pruebas:
Broadcast Frame Throughput: Se utiliza un solo puerto fuente para
•
transmitir tramas con la dirección de broadcast utilizando el formato de

tramas especificado en la RFC 2544. Se seleccionan puertos para medir
el FR y la tasa de pérdida de tramas.
Broadcast Frame Latency: Se utiliza la misma configuración que en el
•
caso anterior, solo se envía una trama de prueba y se mide la latencia

para cada puerto receptor.
Se DEBE reportar en forma de gráfica. La coordenada x = largo de trama, la
coordenada y = resultado de la prueba (throughput y latencia)
Ejemplo:
Broadcast Frames Throughput and Latency Test
Throughput
Frame LengthTest Parameters: Start = 100.0 Min = 0.0 Max = 100.0 Res = 0.5
= 64
Frame Loss Rate = (0 frames)
Forwarding Rate = 148,808 fps (100.00% util)
Binary search complete:
Avg Latency is 183.585 microseconds
Frame Length = 128
Frame Loss Rate = (0 frames)
Forwarding Rate = 84,459 fps (100.00% util)
Binary search complete:
Avg Latency is 172.883 microseconds
25
6. Instrumental disponible
Si bien las recomendaciones del BMWG apuntan a pruebas de laboratorio, hoy en día
se dispone ydemedidas
laboratorio un variado tipo delos
de campo, instrumental, el cual
mismos apuntan permite
(según realizar medidas
corresponda) de
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.
Básicamente, se pueden clasificar en tres “categorías de instrumentos”, las mismas se

realizaron en base a la portabilidad, funcionalidades de los instrumentos y costo:
• Portabilidad: existen dos grupos portables y no portables

o Portables: pensados para campo, priorizan en el diseño parámetros
como el peso, autonomía (duración de baterías), protección para golpes,
acceso remoto, etc.
o No portables: instrumentos pensados para ambientes de laboratorio, en
general tienen mayor porte y están diseñados para estantes ( shelves),
priorizan las funcionalidades, cantidad de interfaces, no requieren una
alta integración como en los portables.
• Funcionalidades de los instrumentos: se relaciona con las prestaciones como
ser, cantidad y tipo de interfaces disponibles (Ethernet, Fibre Channel, SDH,
etc.) y medidas que permiten realizar.
• Costo: Varía acorde a los otros dos parámetros.
Categorías de instrumentos:
• Instrumentos de mano
•
Instrumentos
• Instrumentos de
de campo
laboratorio
6.1 Instrumentos de mano
Instrumentos con pocas interfaces disponibles (no más de dos), en general no se

permiten pruebas simultáneas en ambas interfaces (ej.: no se puede utilizar el puerto
Ethernet y el GbE al mismo tiempo).
Comúnmente 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 certificación de cableado),
transmisión de paquetes, etc.
26
Vienen equipados con herramientas como

ser: Estadísticas de paquetes, Ping, Trace
Route, etc.
27
Muchas veces se adoptan las pruebas de la RFC 2544 (con 2

instrumentos uno como master y otro como slave) para
brindar medidas de tráfico asimétrico (caso ADSL).
Este tipo de medidas puede ser planteadas para conocer el

estado del enlace en un momento dado.
6.2 Instrumentos de campo
Instrumentos que brindan la posibilidad de otras prestaciones como ser:

• Mayor densidad de puertos por placas ( 2, 4 y 8 puertos Ethernet/Fast, GbE)
• Permiten medidas simultáneas en los puertos.
• Placas con otras funcionalidades (ejemplo: SDH-NG, ATM)
• Monitoreo del tráfico (sniffer )
• Permiten realizar medidas acorde RFC2889
• Permiten realizar pruebas de conformance.
Algunos de estos instrumentos son híbridos, permitiendo pruebas en equipos de datos

y de las redes de transporte (por ejemplo SDH).
6.3 Instrumentos de Laboratorio
Instrumentos no portables (generalmente para ser instalados en bastidores) pensados

para pruebas en laboratorios, este tipo de instrumental definen conjuntos de pruebas
los cuales se componen de:
• Recomendaciones: RFC 2544, RFC2889, Draft–ietf–bmwg–fib–meth–xx.txt,
Draft–ietf–ospf–hitless–restart.xx.txt, etc, MEF 9 Conformance Test Suite. [7]
•
Pruebas propietarias
o Variaciones de los estándar [7]
o Pruebas definidas por el fabricante [4] [7] [3]
Los tipos de prueba son por ejemplo:

• BGP (conformance y performance): verificar si el DUT cumple con lo definido
en las siguientes especificaciones de BGP: RFC1771, RFC 1772, draft-ietf-idr-
bgp4-12,and draft-ietf-idr-bgp4-17. [4]
• OSPF verificar si el DUT cumple con lo definido en las siguientes
especificaciones: RFC 1583, RFC 2328, RFC 2370, RFC 1587, RFC 1765, RFC
2740. [4]
28
• Calidad de servicio (QoS): priorización de colas (Queue Priorization) medir la

capacidad del sistema de priorizar un fuljo sobre otro. [7]
Seguridad: Pruebas
flood de Negación del servicioping
(DoS), source address[7]
spoofing
•
detection, ping (ICMP echo) detection, of death detection.
• Access Services: escalabilidad de sesiones PPPoX (cantidad de sesiones PPPoX

que se pueden iniciar y mantener), PPPoX session setup rate (cuantas sesiones
puede establece por ejemplo 25 sesiones/segundo). [7]
• IP Multicast: Scaled group forwarding matriz (cuantos grupos multicast el

sistema puede manejar sin perder trafico), aggregated multicast throughput,
multicast latency, IGMP multisession scalability. [7]
Ejemplo: instrumental de
laboratorio, en general requieren un
Terminal (externo) para la
configuración y presentación de
datos.
Tipo de prueba Tiempo

medidade Cantidad
ensayosde Tamaño
tramasde Tiempo Total
Throughput 10 seg 10 veces 7 tipos 11min 40 seg
Frame Loss 10 seg 5 veces 7 tipos 5 min 50 seg
Rate
Latency 120 seg 20 veces 7 tipos 4hs 40 min
Back-to-Back 2 seg 10 X 50 7 tipos 1hs 57 min
Frames veces
System 60 seg 10 veces 7 tipos 1hs 16 min
Recovery
Tiempo total de pruebas 8hs
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.
[3] Spirent Communications (http://www.spirentcom.com) / Layer3_Testing.pdf,

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) (http://132.151.1.19/html.charters/bmwg-

charter.html)
[7] Agilent Tecnologies (http://advanced.comms.agilent.com/n2x/docs/journal/), The Journal of
Internet Test Methodologies.
[8] Anritsu Corporation (www.anritsu.com/ )
[9] MEF (Metro Ethernet Forum)
Ing. Pablo Scaniello

Mail: scan.pablo@gmail.com
Ing. Gonzalo Sosa
Mail: renacuaj@adinet.com.uy
30

Mediciones Redes Rfc2544

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mediciones Redes Rfc2544

Hochgeladen von

Copyright:

Verfügbare Formate

5/12/2018 MEDICIONESREDESRFC2544-slidepdf.

Curso de Evaluación de pérformance de Redes

Medidas a realizar en dispositivos de redes

1 Conceptos previos sobre mediciones .................................................................... 2

3 Tareas realizadas por el BMWG............................................................................ 3

4 Terminología y metodología de pruebas según RFC 1242 y RFC 2544 ....................... 3

5 Terminología y metodología de pruebas según RFC 2285 y RFC 2889......................12

Curso de Evaluación de pérformance de Redes

1 Conceptos previos sobre mediciones

1.1 Conformance vs. Performance

Pruebas de conformance Pruebas de performance

1.2 Dos enfoques sobre la creación de estándares de pruebas

• Internet Engineering Task Force (IETF) en el grupo Benchmarking Methodology

Se analizarán definiciones y medidas a realizar en dispositivos de redes, basándose en

RFC 2889 (Benchmarking Methodology for LAN Switching Devices)

Posteriormente se hará un estudio (teórico) del instrumental disponible para realizar

Curso de Evaluación de pérformance de Redes

3 Tareas realizadas por el BMWG

Cada recomendación describirá:

Discutirá las características de performance correspondiente a cada clase.

Deberá identificar claramente el tipo de medida.

Deberá brindar los requerimientos para la presentación de los resultados

obtenidos, en un formato común y no ambiguo.

El alcance del BMWG está limitado a la caracterización de la tecnología utilizada

4 Terminología y metodología de pruebas según RFC 1242 y RFC 2544

4.1 Arquitectura de pruebas (RFC 2544 ítem 6)

Curso de Evaluación de pérformance de Redes

La misma funcionalidad se puede obtener con el transmisor ( sender ) separado del

Existen limitaciones a tener en cuenta en este enfoque por ejemplo la latencia

Curso de Evaluación de pérformance de Redes

Eje X: tamaño de tramas (bytes)

Curso de Evaluación de pérformance de Redes

Definición (RFC 1242 ítem 3.8):

Curso de Evaluación de pérformance de Redes

Observación: si se utilizan dos instrumentos para la medición de la latencia, estos

4.4 Frame loss rate

Objetivo: Medir la tasa de pérdida de tramas según RFC 1242.

Curso de Evaluación de pérformance de Redes

4.5 Back-to-back frames

Objetivo: medir el back-to-back frames definido según RFC 1242.

Curso de Evaluación de pérformance de Redes

Existen una cantidad de dispositivos que pueden producir ráfagas back-to-back

4.6 System recovery

Curso de Evaluación de pérformance de Redes

Curso de Evaluación de pérformance de Redes

4.8 Consideraciones generales

Para las pruebas antes mencionadas, la RFC 2544 especifica un conjunto de

4.8.1 Formato y tamaño de tramas (RFC 2544 ítems 8 y 9)

4.8.2 Verificación de tramas recibidas (RFC 2544 ítem 10)

4.8.3 Modificadores (RFC 2544 ítem 11)

Curso de Evaluación de pérformance de Redes

4.8.4 Direcciones de protocolo (RFC 2544 ítems 12, 14 y 16)

5 Terminología y metodología de pruebas según RFC 2285 y RFC 2889

Extiende la metodología definida en la RFC 2544 para dispositivos de capa 2,

Observaciones: es importante diferenciar la carga que una fuente externa

Curso de Evaluación de pérformance de Redes

La máxima carga permitida por el medio puede ser mayor a la que un

Forwarding rates (ítem

o Forwarding (FR): el número de FPS que un DUT/SUT puede

5.1 Fully meshed throughput, frame loss and forwarding rate

Objetivo: Determinar el throughput, frame loss y el forwarding rate ofrecidos al

Curso de Evaluación de pérformance de Redes

El ensayo debe realizarse con los formatos y tamaños de tramas especificados