Metodologia topdownespañol

Metodología Top Down

METODOLOGIA DE DISEÑO DE RED TOP DOWN

Historia de la Metodología TOP DOWN
El diseño de red top-down es una disciplina que creció del éxito de la programación
de software estructurado y el análisis de sistemas estructurados. El objetivo principal
del análisis de sistemas estructurado es representar más exacto las necesidades de
los usuarios, que a menudo son lamentablemente ignoradas. Otro objetivo es hacer
el proyecto manejable dividiéndolo en módulos que pueden ser más fácil de
mantener y cambiar.

El diseño de red top-down es una metodología para diseñar redes que comienza en
las capas superiores del modelo de referencia de OSI antes de mover a las capas
inferiores. Esto se concentra en aplicaciones, sesiones, y transporte de datos antes
de la selección de routers, switches, y medios que funcionan en las capas inferiores.

El proceso de diseño de red top-down incluye exploración divisional y estructuras
de grupo para encontrar la gente para quien la red proporcionará servicios y de
quien usted debería conseguir la información valiosa para hacer que el diseño tenga
éxito.

El diseño de red top-down es también iterativo. Para evitar ser atascado en detalles
demasiado rápido, es importante conseguir primero una vista total de los
requerimientos de un cliente. Más tarde, más detalle puede ser juntado en
comportamiento de protocolo, exigencias de escalabilidad, preferencias de
tecnología, etcétera. El diseño de red top-down reconoce que el modelo lógico y el
diseño físico pueden cambiarse cuando más información es juntada.

Como la metodología top-down es iterativa, un acercamiento top-down deja a un
diseñador de red ponerse "en un cuadro grande" primero y luego moverse en
espiral hacia abajo segun exigencias técnicas detalladas y especificaciones.

Los Sistemas de Cisco recomiendan un acercamiento modular con su modelo
jerárquico de tres capas. Este modelo divide redes en nucleo, distribución, y capas
de acceso. La Arquitectura Segura de Cisco para Empresas (SAFE) y compuesto de
un Modelo de Red de Empresa, son también aproximaciones modulares para el
diseño de la red.

Con un acercamiento estructurado diseñamos la red, cada módulo es diseñado por
separado, aún con relación a otros módulos. Todos los módulos son diseñados
usando un acercamiento top-down que se concentra en los requerimientos,

Marcos Huerta S. 18


aplicaciones, y una estructura lógica antes de la selección de dispositivos físicos y
productos que se implementara en el diseño.

Fase I: Identificando objetivos y necesidades del cliente
Parte 1. Análisis de los objetivos y limitaciones del negocio

Los objetivos y limitaciones incluyen la capacidad de correr las aplicaciones de red
que reune los objetivos comerciales corporativos, y la necesidad de trabajar dentro
de restricciones comerciales, como paquete, personal limitado que esta conectado a
una red, y márgenes de tiempo cortos.

El comprender los objetivos comerciales y sus restricciones de sus clientes es un
aspecto crítico del diseño de red. Armado con un análisis cuidadoso de los objetivos
comerciales de su cliente, usted puede proponer un diseño de red que contara con
la aprobación de su cliente.

El entendimiento de la estructura corporativa también le ayudará a reconocer la
jerarquía de dirección. Uno de sus primeros objetivos en las etapas tempranas del
diseño de un proyecto de red debe determinar quiénes son los funcionarios con
poder de decisión. ¿Quién tendrá las autoridades para aceptar o rechazar su
propuesta de diseño de red?

Además del análisis de objetivos comerciales y determinación de la necesidad de su
cliente de apoyar aplicaciones nuevas y existentes, es importante analizar cualquier
restricción comercial que afectará su diseño de red.

Si usted tiene en mente cambios de estrategias comerciales y gestión de redes de
empresa discutido en las secciones anteriores, se hace posible poner una lista de
los objetivos comerciales en el diseño de alguna red típica:
Ø Aumento de ingresos y ganancia.
Ø Aumento de Cuota de mercado.
Ø Expansión de nuevos mercados.
Ø Aumente ventajas competitivas sobre compañías en el mismo mercado.
Ø Reduzca gastos.
Ø Aumente la productividad de empleado.
Ø Acorte ciclos de desarrollo de producto.
Ø Use la fabricación justo a tiempo.
Ø Plan alrededor de escaseces componentes.
Ø Ofrezca nuevos servicios de cliente.
Ø Ofrezca el mejor soporte de cliente.

Marcos Huerta S. 19


Ø Abra la red a componentes claves (perspectivas, inversionistas, clientes, socios de
negocio, proveedores, y empleados).
Ø Construya relaciones y accesibilidad de información a un nuevo nivel, como una
base para un modelo organizacional de red.
Ø Evite la interrupción comercial causada por problemas de seguridad de red.
Ø Evite la interrupción comercial causada por desastres naturales y poco naturales.
Ø Modernice tecnologías anticuadas.
Ø Reduzca los gastos de telecomunicaciones y red , incluso elevado asociado con
redes separadas para voz, datos, y vídeo

Parte 2. Análisis de los objetivos y limitaciones técnicas

En este parte trata de dar algunos alcances para analizar las metas técnicas de los
clientes para implementar una nueva red o actualizar una existente. Conociendo las
metas técnicas de nuestros clientes podremos recomendar nuevas tecnologías que al
implementarlas cumplan con sus expectativas.

Los típicos objetivos técnicos son adaptabilidad, disponibilidad, funcionalidad, seguridad,
manejabilidad, utilidad, adaptabilidad, y factibilidad.

Uno de los principales objetivos de este capitulo es poder conversar con sus clientes en
términos que ambos puedan entender.

Escalabilidad
La escalabilidad se refiere de cuanto es capaz de dar soporte al crecimiento del diseño
de la red. Uno de los principales objetivos para muchas empresas es que su red sea
altamente escalable, especialmente las empresas grandes que normalmente tienen un
crecimiento rápido tanto en usuarios, aplicaciones y conexiones de red. El diseño de red
que usted propone a un cliente debería ser capaz de adaptarse a aumentos del uso de
red y el alcance.

Disponibilidad
La disponibilidad se refiere a todo el tiempo que una red está disponible a usuarios y es
a menudo una meta difícil de alcanzar para los que diseñan la red, ésta puede ser
expresada en porcentajes por año, mes, semana, día u hora comparado con tiempo total
del periodo.

La palabra disponibilidad puede ser mal entendida por los usuarios para lo que se debe
ser muy cuidadoso en explicar en que consiste la disponibilidad de la red para ello se
puede usar la palabra fiabilidad que se refiere a varios factores, como la exactitud,

Marcos Huerta S. 20


rangos de error, estabilidad, y la cantidad de tiempo entre fracasos lo que refleja la
disponibilidad de la red.

Disponibilidad también lo asocian con la redundancia que no es un objetivo para el
diseño de red, mas bien es una solución, se refiere que se duplica los enlaces a la red
para reducir tiempos lo que permite continuidad después de fallas o desastres.

Disponibilidad esta asociada también con la resistencia que significa cuanto estrés
puede manejar la red con rapidez, que la red pueda manejar los problemas incluyendo
los de seguridad, brechas, desastres naturales y no naturales, errores humanos, fallas
del hardware o software.

Performance
Cuando se analiza los requerimientos técnicos para el diseño de la red, se puede
convencer a los clientes para aceptar la performance de la red, incluyendo rendimiento,
exactitud, eficacia, tardanza, y tiempo de respuesta.

Analizar el estado actual de la red puede ayudar a ver que cambios se podrían realizar
para que mejore la performance de la red. Las metas de la performance de la red están
bastante ligada con las metas de la escalabilidad.

Seguridad
El diseño de la seguridad es uno de los aspectos más importantes en el diseño de red
empresarial. Al incrementar las amenazas tanto dentro como fuera de la red de la
empresa se debe tener reglas y tecnologías de seguridad actualizadas e incorruptibles.
Las metas más deseadas de muchas empresas es que los problemas de seguridad no
afecten a la habilidad de conducir los negocios de la empresa, osea que si se presentara
algún tipo de problema la empresa debe ser capaz de seguir con sus actividades
normales.

La primera tarea para el diseño de la seguridad es planificar. Lo que significa que
debemos reconocer las partes más vulnerables de la red, analizando los riesgos y
encontrando requerimientos.

Como es el caso de la mayoría de las exigencias técnicas de diseño, alcanzando
objetivos de seguridad significa hacer compensaciones. Las puestas en práctica de
seguridad pueden aumentar el costo de despliegue y funcionamiento de la red, también
puede afectar la productividad de usuarios, sobre todo si se dificulta el modo de trabajo
para proteger recursos y datos. La Seguridad también puede afectar la redundancia del
diseño de red por ejemplo si el tráfico pasa por dispositivos de cifrado.

Marcos Huerta S. 21


Manejabilidad (Administración)
Cada cliente tiene objetivos y una forma de administrar la red diferente. Algunos clientes
tienen metas claras de cómo administrar la red y otras metas menos específicas. Si su
cliente tiene proyectos definidos, debe asegurarse que se documenten, porque usted
tendrá que referirse a los proyectos seleccionando el equipo. En algunos casos, el
equipo tiene que ser excluido porque esto no soporta la administración de funciones que
el cliente requiere.

La administración de la red debe ser simplificada. Simplificarlos en paquetes de
funciones de administración se entienden fácilmente y usados por administradores de
red. Durante la reunión de inicial de exigencias técnicas para el diseño o actualización
de una red, se puede usar la terminología ISO para simplificar la discusión de las metas
de los administradores de red con sus clientes, de la siguiente manera:

• Administración de funcionamiento. Analizar el tráfico y el comportamiento de
aplicación para optimizar una red, quedar en acuerdos de nivel de servicio, y el plan
para la extensión
• Administración de defecto. Descubrir, aislar y corregir de problemas; reportando los
problemas a usuarios finales y gerentes.
• Administración de configuración. Control, funcionamiento, identificación, y recolectar
datos de dispositivos de administración
• Administración de Seguridad. Supervisión y pruebas de seguridad y política de
protección, manteniendo y distribuyendo contraseñas y otra autenticación e
información de autorización, llaves de cifrado directivas, y adhesión de revisión a
política de seguridad.
• Administración de la contabilidad. Contabilizar el uso de la red para asignar gastos
para conectar una red a usuarios y/o plan para cambios de exigencias de capacidad

Parte 3. Graficando la Red Existente

Esto se basa en una ejecución en un mapa de una red y aprendiendo la localización de
la mayoría de los dispositivos y segmentos en el trabajo de la red y identificando algunos
métodos establecidos para el direccionamiento y nombramiento y también archivando,
investigando los cables físicos, reservas que son muy importante en la característica de
la infraestructura de la red.

Ejecución de un Mapa de Red
Para la mayoría de los diseñadores de red; la interconexión de dispositivos y segmentar
de la red es un buen camino para comenzar la compresión del flujo circulatorio.

Marcos Huerta S. 22


El objetivo es obtener un mapa ya implementado de la red, algunos diseños de los
clientes pueden tener mapas para un nuevo y mejor diseño de la red.

Herramientas para la Ejecución de un Mapa de Red
Para ejecutar un mapa de la existencia de la red, deberíamos invertir en una buena
herramienta de diagrama de red. Tales como:
Ø Visio Corporations.
Ø Visio Profesional.
Ø Visio Profesional Ships.

Algunas compañías ofrecen esquematizar automáticamente el descubrimiento de la red
existente, usando el siguiente software:
Ø Pinpoint Software’s ClickNet Professional.
Ø NetSuite Development.
Ø Net Suite Advanced Professional Design.
Ø NetSuite Professional Audit (similar ClickNet).

¿Que debería Incluir en un Mapa de Red?
Usando las herramientas mencionadas deberá desarrollar un mapa de red en la cual
deberá contener lo siguiente:
Ø Conexiones WAN entre países y ciudades.
Ø Edificios y pisos, y posibilidades cuartos y casetas.
Ø Conexiones WAN y LAN entre edificios y entre campos.
Ø Una indicación de la capa de datos (WAN, LANS).
Ø El Número de servicios proveedor de WANS.
Ø La localización de las líneas y interruptores, aunque no es necesario en el eje y
centro.
Ø La localización y alcance de redes virtuales (VPN’s), que conecta los servicios
de los proveedor WAN.
Ø La localización de las principales estructuras.
Ø La localización de las mayores estaciones de ejecución de la red.
Ø La localización y alcance de algunas LAN’s Virtuales (VLAN’s).
Ø La topología de algunos sistemas de seguridad Firewall.
Ø La localización de algunos sistemas de dial- in y dial out.
Ø Algunas indicaciones de donde residen algunas estaciones de trabajo, aunque
no necesariamente la localización explicita de cada estación de trabajo.

Marcos Huerta S. 23


Caracterizando el Direccionamiento y el Nombramiento de la Red
La infraestructura lógica de la red envuelve documentar cualquier estrategia que su
cliente tiene para el direccionamiento y nombramiento de la red.
Cuando dibuje los detalles de los mapas de la red, deberá incluir los sites, routers,
segmentos de la red y servicios.

Usted tiene que investigar el direccionamiento de la capa de red que usa, el esquema de
direccionamiento que usa su cliente puede influenciar en la habilidad de adaptar su
nuevo diseño de red a los objetivos, aquí definirá el mejor método de direccionamiento
que se pueda usar para su diseño de red. Entre los cuales tenemos:
Ø Subnetting.
Ø Variable Lenght Subnet Masking (VLSM).
Ø Supernetting o Aggregations.
Ø Summarization.
Estos métodos se explicaran más adelante cuando se seleccione el protocolo y
direccionamiento de red.

Caracterizando el Cableado y el Medio
Es importante comprender el cableado y la instalación eléctricos del diseño de la red con
el objetivo de identificar posibles y potenciales problemas. Si es posible usted deberá
documentar el tipo de cableado que usa, la distancia ya que esta información ayudara a
determinar la Tecnología de la capa de enlace basado en las restricciones de distancia.

Cuando el diseño del cableado esta en exploración, determine cuales son los equipos y
los cables que están etiquetado en la red existente.

Por ejemplo: la red de un edificio debería archivar las conexiones de un número de
cable y el tipo de instalación que esta en uso en la red.

Probablemente la instalación entre los edificios es unos de los sgtes:
Ø Single –mode fiber
Ø Multi –mode fiber
Ø Shielded twisted pair (STP)
Ø UTP categoría 5
Ø Cable coaxial
Ø Microondas
Ø Radiofrecuencia.
Ø Láser
Ø Infrarrojo

Marcos Huerta S. 24


Supervisando la Arquitectura Ambiental y Restricciones
Cuando esta investigando el cableado hay que poner mucha atención en los problemas
ambientales con la posibilidad de que el cableado podría pasar muy cerca donde haya
lugares propensos a inundarse, cerca de las carreteras donde el tráfico de los vehículos
podría quebrar los cables, calefacciones, etc.

Este seguro que no tenga ningún problema legal a la hora de tender un cableado, por
ejemplo al cruzar un cableado por una calle donde tenga que romper pistas.

Cuando construya preste atención a la arquitectura si este afecta la implementación de
su diseño, este seguro que la arquitectura puede soportar el diseño tales como:
Ø Aire acondicionado.
Ø Calefacción.
Ø Ventilación.
Ø Protección de interferencias electromagnéticas.
Ø Puertas que no estén cerradas, etc.

Supervisando el buen Funcionamiento de la Red existente
Estudiar el performance de una red existente te da una línea básica dimensional para
poder medir y compara el performance del nuevo diseño de red propuesto el cual le
ayudara a demostrar a su cliente cuan mejor es su diseño en performance una vez
implementado.

Si la red es muy grande para estudiar todos sus segmentos, preste mayor atención en
la red de backbone antigua y las nuevas áreas que se conectan así como redes que se
integran al backbone.

Por ejemplo capturar la circulación la red con un analizador de protocolo como parte de
tu análisis de la línea básica, podría identificar cuales de los protocolos están realmente
trabajando en la red y no contar con la creencia de los clientes (ethereal).

Analizando la Performance precisa de la Red
Poder identificar la performance precisa de una red no es tarea fácil. Una de las tareas
es seleccionar el tiempo para hacer estos análisis para poder determinar el momento
exacto para poder realizarlo y determinar los problemas que presenta la red durante los
periodos altos de tráfico, etc.

Los problemas de la red no son usualmente causados por los envíos de malas
estructuras de tramas. En el caso token ring (La red Token-Ring es una implementación
del standard IEEE 802.5, en el cual se distingue más por su método de transmitir la

Marcos Huerta S. 25


información que por la forma en que se conectan las computadoras., el problema
usualmente esta por estación y problema de cable, en el caso de ethernet, es un difícil
precisar la causa del problema.

Algunos clientes no reconocen el valor de estudiar las redes existentes antes del diseño
y la implementación. Los clientes generalmente se avocan por un diseño rápido por lo
cual puede hacer difícil poder dar marcha atrás y insistir en tiempo para desarrollar la
performance precisa de la red existente. Un buen entendimiento de los objetivos
técnicos y de negocio del cliente pueden ayudar a decidir que cantidad de tráfico deberá
analizar en la red.

Analizando la Disponibilidad de la Red
Para documentar características de disponibilidad de la red existente, junte cualquier
estadística que el cliente tiene durante el tiempo medio entre fallas (MTBF) y tiempo
medio de reparación (MTTR) para las redes en conjunto así como segmentos de red
principales. Compare estas estadísticas con la información en la que usted se ha
juntado en MTBF y objetivos MTTR, ¿Espera el cliente que su nuevo diseño aumente
MTBF y disminuya MTTR? ¿Son los objetivos del cliente consideración realista del
estado corriente de la red?

Diríjase a los ingenieros de red y técnicos sobre las causas de los períodos más
recientes y más perjudiciales del tiempo de indisponibilidad.

Interpretando como un investigador forense, trate de conseguir muchos lados a la
historia. A veces los mitos se desarrollan sobre lo que causó una interrupción de red.
(Usted puede conseguir por lo general una vista más exacta de causas de problema de
ingenieros y técnicos que de usuarios y gerentes.)
Puede usar esta Tabla Nro. 01 para documentar.

Tabla Nro. 01 Caracterizar la Disponibilidad de la Red

Marcos Huerta S. 26


Analizando la Utilización de la Red
Utilización de red es una medida de cuanta ancho de banda está en el uso durante un
intervalo de tiempo específico. La utilización es comúnmente especificada como un
porcentaje de capacidad. Si un instrumento que supervisa la red dice que la utilización
de red en un segmento de Fast Ethernet es el 70%, por ejemplo, este significa que el
70% de la capacidad 100-Mbps está en el uso, hecho un promedio sobre un margen de
tiempo especificado o ventana.

Diferentes instrumentos usan diferente promedio de ventanas para calcular la utilización
de red. Algunos instrumentos dejan al usuario cambiar la ventana. La utilización de un
intervalo largo puede ser útil para reducir la cantidad de datos estadísticos que deben
ser analizados, pero la granularidad es sacrificada.

Figura Nro. 09. Analizando la Utilización de la Red

Utilización del Ancho de Banda por Protocolo
El desarrollo de una performance preciso de la performance de red también debería
incluir la utilización de medición del tráfico de broadcast contra el tráfico unicast, y por
cada protocolo principal. Algunos protocolos envían excesivo tráfico de broadcast, que
puede degradar seriamente la performance, sobre todo en redes switchadas.

Para medir la utilización del ancho de banda por protocolo, coloque un analizador de
protocolo en cada segmento de la red principal y llena una tabla como la mostrada en la
figura. Si el analizador soporta porcentajes relativos y absolutos, especifique el ancho de
banda usada por protocolos en comparación al total de ancho de banda en uso. Uso
relativo especifica cuanto ancho de banda es usada por protocolo en comparación con
el ancho de banda total actualmente en uso en el segmento. Uso absoluto especifica
cuanta ancho de banda es usada por protocolo en comparación con la capacidad total
del segmento (por ejemplo, en comparación con 100 Mbps en Fast Ethernet).

Marcos Huerta S. 27


Tabla Nro. 02 Utilización del Ancho de Banda por Protocolo

Análisis de la Exactitud de Red
Usted puede usar a un probador BER (también llamado BERT) en líneas seriales para
probar el número de bits dañados comparados a los totales de bits.

Con redes por paquete switchados, hace más sentido de medir el paquete (packer) de
errores porque un paquete entero es considerado malo si un solo bit es cambiado o
descartado. En redes por paquete switchados, una estación de envío calcula un ciclo de
redundancia CRC basado en los bits del paquete. La estación de envío reemplaza el
valor del CRC en el paquete. Una estación de recepción determina si el bit ha sido
cambiado entonces descarta el paquete y vuelve a calcular el CRC otra vez y
comparando el resultado con el CRC del paquete. Un paquete con CRC malo es
descartado y debe ser transmitido de nuevo por el remitente. Por lo general un protocolo
de capa superior tiene el trabajo de transmitir de nuevo los paquetes que no se ha
reconocidos.

Un analizador de protocolo puede comprobar el CRC en los paquetes recibidos. Como
la parte de su análisis de performance preciso, usted debería rastrear el número de
paquetes recibidos con CRC malo cada hora o cada dos días. Como es normal los
errores aumentan con la utilización, errores de documento como una función del número
de bytes vistos por el instrumento de escucha. Un umbral de regla básica bueno para
considerar errores malsanos es que una red no debería tener más de un paquete malo
por megabyte de datos. (Errores calculados este camino le deja simular una serie BERT.
Simplemente el cálculo de un porcentaje de paquetes malos comparados con paquetes
buenos nos explica el tamaño de paquete y de ahí no da una indicación buena de
cuantos trozos realmente se han dañados).

Además del rastreo de errores de capa de enlace de datos, como errores CRC, un
análisis del performance preciso debería incluir la información en problemas de capa
superior. Un analizador de protocolo que incluye un sistema experto, como WildPackets
EtherPeek NX analizador de red, se apresura la identificación de problemas de capa

Marcos Huerta S. 28


superior por automáticamente generando diagnósticos y síntomas para conversaciones
de red y aplicaciones.

La exactitud también debería incluir una medida de paquetes perdidos. Usted puede
medir paquetes perdidos midiendo el tiempo de respuesta.

Enviando paquetes para medir cuanto tiempo este toma para recibir una respuesta,
documente cualquier paquete que no recibe una respuesta, probablemente porque la
petición o la respuesta fue perdido. Correlacione la información sobre paquetes perdidos
con otras medidas de interpretación para determinar si los paquetes perdidos indican
una necesidad de aumentar el ancho de banda, para disminuir errores CRC, o mejorar
dispositivos de funcionamiento entre redes. Usted también puede medir paquetes
perdidos mirando la estadística guardada por gestores de tráfico en el número de
paquetes descartados de colas de salida o entrada.

Analizando la Eficiencia de la Red
La utilización de ancho de banda es optimizada para la eficacia cuando las aplicaciones
y los protocolos son configurados para enviar cantidades grandes de datos por paquete,
así minimizando el número de paquete y tardanzas de ida y vuelta requeridas para una
transacción. El número de paquetes por transacción también puede ser minimizado si el
receptor es configurado con una ventana grande que lo permite aceptar paquetes
múltiples antes de que esto debiera enviar un reconocimiento.

Cambiando la transmisión y recepción del tamaño de buffer- paquete de los clientes y
los servidores pueden causar la eficacia mejorada por paquete recibido en la ventana. El
aumento de la unidad de transmisión máxima (MTU) en interfaces del router también
puede mejorar la eficacia.

Por otra parte, el aumento del MTU es a veces necesario en interfaces del router de
aquellos que usan túneles. Los problemas pueden ocurrir cuando una cabecera
suplementario es añadido por el túnel hace que el paquete sean más grandes que falta
MTU. Un síntoma típico de este problema es que los usuarios pueden ping y Telnet,
pero no usar el Protocolo de Transferencia de Hipertexto (HTTP), FTP, y otros
protocolos que usan los paquetes grandes. Una solución es aumentar el MTU en el
interfaz del router.

Para determinar si los objetivos de su cliente para la eficacia de red son realistas, usted
debería usar un analizador de protocolo para examinar los tamaños de los paquetes que
se usa en la red. Muchos analizadores de protocolo le dejan tabla de salida como el que
se especifica en la figura 3.7

Marcos Huerta S. 29


Figura Nro. 10. Graficando el Tamaño de los Paquetes del Backbone

Analizar la Tardanza y Tiempo de Respuesta
Para verificar que la performance de un nuevo diseño de red se encuentra dentro de las
exigencias de un cliente, es importante medir el tiempo de respuesta entre dispositivos
de red antes y después de que un nuevo diseño de red es puesto en práctica. El tiempo
de respuesta puede ser medido por muchos caminos. Usando un analizador de
protocolo, usted puede mirar la cantidad de tiempo entre paquetes y conseguir una
estimación del tiempo de respuesta en la capa de enlace de datos, capa de transporte, y
capa de aplicación. (Este es una estimación porque los tiempos de llegada de paquete
en un analizador sólo pueden acercarse tiempos de llegada de paquete en estaciones
finales.)
Un modo más común de medir tiempo de respuesta es enviar paquetes de ping y medir
el tiempo de ida y vuelta (RTT) para enviar una petición y recibir una respuesta.
Midiendo RTT, usted también puede medir la variación RTT. Medidas las variaciones
son importantes para aplicaciones que no pueden tolerar muchas variaciones (por
ejemplo, voz y aplicaciones de vídeo). Usted también puede documentar cualquier
pérdida de paquetes.
Usted puede usar una tabla para documentar estas medidas ver figura:

Tabla Nro. 03 Medida del Tiempo de Respuesta

Marcos Huerta S. 30


El Chequeo del estado de los Routers principales, Switches, y Firewalls
El paso final en la caracterización de las redes existentes debe comprobar el
comportamiento de los dispositivos de funcionamiento entre redes en las redes. Este
incluye routers e switches que unen capas de una topología jerárquica, routers de
backbone e switches, y firewalls que tendrán los papeles más significativos en su nuevo
diseño de red. No es necesario comprobar cada switch de LAN, sólo los switches
principales, routers, y firewalls.

La comprobación del comportamiento y la salud de un dispositivo de funcionamiento
entre redes incluye la determinación que ocupado el dispositivo es (utilización de CPU),
cuantos paquetes esto ha tratado, cuantos paquetes esto se ha perdido, y el estado de
los buffer y colas. Su método para tasar la salud de un dispositivo de funcionamiento
entre redes depende del vendedor y la arquitectura del dispositivo.

Parte 4. Caracterizando un diseño de trafico de red

Este sección describe las técnicas para caracterizar el flujo de tráfico, el volumen de
tráfico, y el comportamiento de protocolo. Las técnicas incluyen el reconocimiento de
tráfico fuente y almacenaje de datos, documentar las aplicaciones y uso el de protocolo,
y evaluar del tráfico de red causado por protocolos comunes.

El la sección anterior se habló de la caracterización de la red existente en términos de
su estructura e interpretación. Como el análisis de la situación existente es un paso
importante en un acercamiento de análisis de sistemas para diseñar, este sección se
habla de la caracterización de la red existente en términos de flujo de tráfico. Esta
sección también cubre nuevas exigencias de diseño de red, añadiendo los dos primeras
secciones que cubrieron objetivos de diseño comerciales y técnicos. Esta sección
reenfoca en exigencias de diseño y describe exigencias en términos de flujo de tráfico,
carga, y comportamiento; y calidad de servicio (QoS) exigencias.

Caracterizando el Flujo de Trafico

La caracterización del flujo de tráfico implica identificar fuentes y destinos del tráfico de
red y analizar la dirección y la simetría de datos que viajan entre fuentes y destinos. En
algunas aplicaciones, el flujo es bidireccional y simétrico. (Ambos finales del flujo envían
el tráfico en aproximadamente el mismo precio.) En otras aplicaciones, el flujo es
bidireccional y asimétrico. Las estaciones de cliente envían pequeñas preguntas y los
servidores envían grandes corrientes de datos. Los broadcast de una aplicación, el flujo
es unidireccional y asimétrico. Esta sección habla de la caracterización de la dirección y

Marcos Huerta S. 31


la simetría del flujo de tráfico en una red existente y análisis del flujo para nuevas
aplicaciones de red.

La Identificación de las Principales Fuentes de Tráfico y Almacenamiento
Para entender el flujo de tráfico de red, usted debería identificar primero comunidades
de usuario y almacenamiento de datos para las aplicaciones existentes.

A comunidad de usuario es un grupo de trabajadores que usan una aplicación particular
o un grupo de aplicaciones. Una comunidad de usuario puede ser un departamento
corporativo o un grupo de departamentos. Sin embargo, en muchos ambientes, el uso
de aplicación cruza muchos departamentos. Cuando más corporaciones usan la
dirección de la matriz y forman equipos virtuales para completar un proyecto, se hace
más necesario caracterizar comunidades de usuario por aplicación y uso de protocolo
más bien que por el límite de departamentos.

Para documentar comunidades de usuario, pida a su cliente ayudarle a llenar un
formulario de Comunidades de Usuario mostrada en la Tabla Nro. 04. Para la columna
de posición de la figura, los nombres de posición de uso que usted ya documentó en un
mapa. Para aplicaciones, nombres de aplicación de uso en los cuales usted ya
documentó en los formularios de Aplicaciones de Red.

Tabla Nro. 04 Comunidades de Usuarios

Además de la documentación de comunidades de usuario, caracterizando el flujo de
tráfico también requiere que usted documente los principales almacenamiento de datos.
Un almacenamiento de datos (a veces llamaba a colector de datos) es un área en una
red donde los datos de capa de aplicación residen. Un almacenamiento de datos puede
ser un servidor, un grupo de servidores, una red de área de almacenaje (SAN), un
ordenador central, una unidad de reserva de cinta, una biblioteca de vídeo digital, o
cualquier dispositivo o componente de un red donde las cantidades grandes de datos
son almacenadas. Para ayudarle a documentar los principales almacenamiento de
datos, pida a su cliente ayudarle a llenar el siguiente formulario. Para la Posición, la
Aplicación, y las columnas de Comunidad de Usuario, usa nombres que usted ya
documentó en un mapa y otras cartas.

Marcos Huerta S. 32


Tabla Nro. 05 Formulario de Almacenamiento de Datos

Documentar el Flujo de Tráfico en la Red Existente
La documentación del flujo de tráfico implica identificar y caracterizar flujos de tráfico
individuales entre fuentes de tráfico y almacenes. Los flujos de tráfico se han hecho
recientemente un tema caliente para la discusión en la comunidad de Internet. Mucho
progreso está siendo hecho en la definición de flujos, medición de comportamiento de
flujo, y permiso de una estación final de especificar los requerimientos de performance
por flujo.

Para entender mejor el comportamiento de flujo de tráfico, usted puede leer la Petición
de Comentarios (RFC) 2722, "Medida de Flujo de Tráfico: Arquitectura." El RFC 2722
describe una arquitectura para la medida y reportaje de flujos de tráfico de red, y habla
como la arquitectura está relacionada con una arquitectura de flujo de tráfico total para
el intranet y el Internet.

La medición del comportamiento de flujo de tráfico puede ayudar a un diseñador de red
a determinar qué trafico de routers deberían ser peer en los protocolos de
encaminamiento que usan un sistema peering, como el Border Gateway Protocol (BGP).
La medición del comportamiento de flujo de tráfico también puede ayudar a los
diseñadores de la red y debran hacer lo siguiente:
• Caracterice el comportamiento de redes existentes.
• Plan de desarrollo y extensión de la red.
• Cuantifique la performance de la red.
• Verifice la calidad del servicio de red.
• Asigne el uso de aplicaciones y usuarios de la red .

Un flujo individual de tráfico de red puede ser definido como protocolo e información de
aplicación transmitida entre entidades que se comunican durante una sesión sola. Un
flujo tiene atributos como dirección, simetría, caminos de enrutamiento, opciones de
enrutamiento, número de paquetes, número de bytes, y se dirige el flujo hacia una
dirección final. Una entidad que se comunica puede ser un sistema de final (host), una
red, o un sistema autónomo.

Marcos Huerta S. 33


El método más simple para caracterizar el tamaño de un flujo es medir el número de
Kilobytes o Mbytes por segundo entre entidades que se comunican. Para caracterizar el
tamaño de un flujo, use un analizador de protocolo o conecte a la red el sistema de
dirección para registrar la carga entre fuentes importantes y destinos. Los instrumentos
de Cisco para caracterizar flujos de tráfico incluyen Cisco FlowCollector y el Analizador
de Datos, que están basados en el Cisco NetFlow la tecnología.

Usted puede usar el formulario siguiente descirto para documentar información sobre la
dirección y volumen de flujos de tráfico. El objetivo es documentar los Kilobytes o
Mbytes por segundo entre pares de sistemas autónomos, redes, hosts, y aplicaciones.

Para conseguir la información para llenar los formularios, coloque un dispositivo que
monitoree el core de la red y déjele coleccionar datos por uno o dos días. Para
conseguir la información para llenar la columna de Path, usted puede encender la
opción de grabar-ruta de registro en una red de IP. La opción de ruta de registro tiene
algunas desventajas, sin embargo. Esto no apoya redes muy grandes y es a menudo
minusválido para razones de seguridad. Usted también puede estimar el path mirando la
tabla de encaminamiento y análizando el tráfico de red en multiples segmentos.

Tabla Nro. 06 Flujo de Tráfico en la Red Existente

La Caracterización de Tipos de Flujo de Tráfico para Nuevas Aplicaciones de Red
Como mencionado, un flujo de red puede ser caracterizado por su dirección y simetría.
La dirección especifica si los datos viajan en ambas direcciones o en sólo una dirección.
La dirección también especifica el camino que un flujo toma cuando esto viaja de la
fuente al destino por una de las redes. La simetría describe si el flujo tiende a tener alta
performance o requerimientos de QoS en una dirección que en la otra dirección. Muchas
aplicaciones de red tienen requerimientos diferentes en cada dirección. Algunas
tecnologías de transmisión como la Línea de Suscriptor Digital Asimétrica (ADSL), son
fundamentalmente asimétricas.

Una técnica buena para caracterizar flujo de tráfico de red debe clasificar aplicaciones
que soportan una de los tipos de flujo conocidos:

Marcos Huerta S. 34


• Flujo de tráfico de terminal/host.
• Flujo de tráfico de cliente/servidor.
• Flujo de tráfico Punto a Punto.
• Flujo de tráfico de servidor/servidor.
• Flujo de tráfico de cálculo distribuido.

En su libro “Análisis de Red, Arquitectura, y Diseño”, Segunda Edición, James D.
McCabe hace un trabajo excelente de caracterización de los distintos modelos de flujo.

Flujo de Tráfico de Terminal/host
El tráfico de terminal/host es por lo general asimétrico. El terminal envía unos caracteres
y el host envía muchos caracteres. El Telnet es un ejemplo de una aplicación que
genera el tráfico de terminal/host. Por defecto detrás de Telnet consiste en que el
terminal envía un simple paquete cada vez que el usuario escribe un carácter. El host
devuelve caracteres múltiples, según lo que el usuario escribió. Como una ilustración,
considere el principio de una sesión Telnet que comienza con el usuario que escribe su
nombre. Una vez que el host recibe cada paquete para los caracteres del nombre, el
host devuelve un paquete de mensaje de regreso (como la Contraseña Requerida).

Flujo de Tráfico de Cliente/Servidor
El tráfico de cliente/servidor es el mejor tipo de flujo conocido y el más extensamente
usado. Los servidores son generalmente poderosas computadoras dedicadas a
administrar el almacenaje de disco, impresoras, u otros recursos de red. Los clientes
son ordenadores personales o estaciones de trabajo en las cuales los usuarios dirigen
aplicaciones. Los clientes confían en servidores para el acceso a recursos, como
almacenaje, periféricos, software de aplicación, y poder de procesamiento.

Los clientes envían preguntas y peticiones a un servidor. El servidor responde con datos
o el permiso para el cliente para enviar datos. El flujo es por lo general bidireccional y
asimétrico. Las peticiones del cliente son típicamente pequeños paquetes, excepto
cuando escribe datos al servidor, en cuyo caso ellos son más grandes. Las respuestas
del servidor son de un rango de 64 bytes a 1500 bytes o más, dependiendo del tamaño
maximo del paquete.

En un ambiente TCP/IP, muchas aplicaciones son puestas en práctica de una manera
de cliente/servidor, aunque las aplicaciones fueran inventadas antes de que el modelo
de cliente/servidor fuera inventado. Por ejemplo, el Protocolo de Transferencia de
Archivos (FTP) tiene un lado de servidor y cliente. Los clientes de FTP usan
aplicaciones de FTP para dirigirse a servidores de FTP.
Estos días, el Protocolo de Transferencia de Hipertexto (HTTP) es probablemente el
protocolo de cliente/servidor el más extensamente usado. Los clientes usan una

Marcos Huerta S. 35


aplicación de navegador de web, como Netscape, para poder conectarse con el servidor
web. El flujo es bidireccional y asimétrico. Cada sesión a menudo dura sólo unos
segundos porque los usuarios tienden a saltar de un sitio Web al otro.

Flujo de Tráfico Punto a Punto
Con el flujo tráfico punto a punto, el flujo es por lo general bidireccional y simétrico. Las
entidades que se comunican transmiten cantidades aproximadamente iguales de la
información. No hay ninguna jerarquía.

Cada dispositivo es considerado tan importante el uno como el otro, y ningún dispositivo
tiene considerablemente más datos que el otro dispositivo. En pequeños ambientes de
LAN, loa administradores de red a menudo establecen las configuraciones con los
ordenadores personales en un punto a punto de modo que cada uno pueda tener
acceso a datos de cada uno e impresoras. No hay ningún servidor de archivo central o
servidor de impresora. Otro ejemplo de punto a punto el ambiente es preparado para
multiusuarios UNIX o host donde los usuarios establecen FTP, Telnet, HTTP, y sesiones
de Sistema de Archivos de Red entre host.

Cada host actúa tanto como cliente y como servidor. Hay muchos flujos en ambas
direcciones.

Recientemente las aplicaciones punto a punto para descargar música, videos, y
software han ganado la popularidad. Cada usuario publica la música u otro material y
permite que otros usuarios en el Internet descarguen los datos. Este es considerado
tráfico punto a punto porque cada usuario actúa tanto como distribuidor y consumidor de
datos. El flujo de tráfico es bidireccional y simétrico. La mayor parte de empresas y
muchas redes de universidad rechazan este tipo de tráfico punto a punto por dos
motivos. Primero, esto puede causar una cantidad excesiva del tráfico, y, segundo, el
material publicado es a menudo copyright por alguien además de la persona que lo
publica.

Un otro ejemplo de aplicación punto a punto es una reunión de negocios entre la gente
de una empresa en sitios remotos usando equipos de videoconferencia. En una reunión,
cada asistente puede comunicar tantos datos como son necesarios en cualquier
momento. Todos los sitios tienen las mismas exigencias QoS. Una reunión es diferente
para cada situación donde la videoconferencia es usada para diseminar la información.
Con la diseminación de información, como una clase de formación o un discurso por un
presidente corporativo a empleados, la mayor parte de los datos fluyen del sitio central.
Unas preguntas son permitidas de los sitios remotos. La diseminación de información es
por lo general puesta en práctica usando un modelo de cliente/servidor.

Marcos Huerta S. 36


Flujo de Tráfico de Servidor/Servidor
El tráfico de servidor/servidor incluye transmisiones entre servidores y transmisiones
entre manejo de aplicaciones. Los servidores se dirigen a otros servidores para
implementar los servicios de directorio, una cahe pesadamente usa datos, los mirrow de
datos para equilibrio de carga y redundancia, backup de datos, y disponibilidad de
broadcast de servicio.

Los servidores manejan las aplicaciones por algunos mismos motivos, sino también
hacer cumplir políticas de seguridad y actualizar datos de dirección de red.
Con el tráfico de red de servidor/servidor, el flujo es generalmente bidireccional. La
simetría del flujo depende de la aplicación. Con la mayor parte de aplicaciones de
servidor/servidor, el flujo es simétrico, pero en algunos casos esto es heredado de
servidores, con algunos servidores que envían y y almacenan más datos que otros.

Flujo de Tráfico de Cálculo Distribuido
La informática distribuida se refiere a aplicaciones que requieren múltiples nodos que
trabajan y realizan cálculos juntos para completar un trabajo.

Algunas tareas de modelos complejos no pueden ser llevadas a cabo en un margen de
tiempo razonable a menos que múltiples computadoras traten datos y dirijan algoritmos
simultáneamente. Los efectos especiales para películas a menudo son desarrollados y
calculados en un ambiente distribuido. La informática distribuida también es usada en la
industria de semiconductor para calcular las necesidades extremas del diseño y
verificación de un microchip, y en la industria de defensa para proporcionar ingeniería y
simulaciones militares.

Con algunas aplicaciones de cálculo distribuidas, el manejador de tarea dice a los nodos
de cálculo que hacer en una base infrecuente, causando poco flujo de tráfico. Con otras
aplicaciones, hay comunicación frecuente entre el manejador de tarea y los nodos de
cálculo.

La Documentación de Flujo de Tráfico para Aplicaciones Nuevas y Existentes de
la Red
Para documentar el flujo de tráfico para nuevo (y existentes) de aplicaciones de red,
caracterice el tipo de flujo para cada aplicación y ponga las comunidades de usuario en
una lista y los almacenes de datos que tienen que ver con aplicaciones. Usted puede
usar este formulario:

Marcos Huerta S. 37


Tabla Nro. 07 Flujo de Tráfico para Aplicaciones Nuevas y Existentes

Caracterización de Carga de Tráfico
Para seleccionar topologías apropiadas y tecnologías para encontrar los objetivos de un
cliente, es importante caracterizar la carga de tráfico con el flujo de tráfico. La
caracterización de la carga de tráfico puede ayudarle a diseñar redes con la capacidad
de uso local suficiente y flujos de redes.

A causa de muchos factores implicados en la caracterización del tráfico de red, las
estimaciones de carga de tráfico con poca probabilidad serán precisas. El objetivo es
evitar simplemente un diseño que tiene cualquier cuello de botella crítico. Para evitar
cuellos de botella, usted puede investigar modelos de uso de aplicación, tiempos
ociosos entre paquetes y sesiones, tamaños de paquetes, y otros patrones de tráfico
behaviorísticos para protocolos de sistema y aplicación.

Otro acercamiento a la evitación de cuellos de botella debe lanzar simplemente
cantidades grandes de ancho de banda en el problema. Una interpretación estricta de
principios de análisis de sistemas no aprobaría tal acercamiento, pero el ancho de
banda es barato estos días. El ancho de banda de LAN es muy barato. No hay
simplemente ninguna excusa para no usar Fast Ethernet (o mejor) en todas las nuevas
estaciones de trabajo e switches, y la mayor parte de organizaciones también pueden
permitirse a usar Gigabit Ethernet en switch a switch y switch a servidor. El ancho de
banda WAN es todavía cara en algunas partes del mundo, incluso áreas rurales de los
Estados Unidos. Pero en muchas partes de los Estados Unidos y el resto del mundo, el
ancho de banda ha sido sobre aprovisionada y no está hasta cerca de ser sobre
utilizado.

El Cálculo de Carga de Tráfico Teórica
La carga de tráfico (a veces llamado carga ofrecida) es la suma de todos los nodos de
red de datos que estan listo para transmitir en un tiempo particular. Un objetivo general
para la mayor parte de diseños de red es que la capacidad de red debería ser más que

Marcos Huerta S. 38


adecuada de manejar la carga de tráfico. El desafío debe determinar si la capacidad
propuesta para un nuevo diseño de red es suficiente para manejar la carga potencial.

En su libro Redes de Área Locales y Metropolitanas, Guillermo Stallings proporciona
algunos cálculos atrás el-desarrollo para la carga de tráfico calculadora. El Stallings
indica que usted puede hacer un cálculo elemental basado simplemente en el número
de la transmisión de estaciones, como rápidamente cada estación genera mensajes, y el
tamaño de mensajes. Por ejemplo, para una red con una capacidad propuesta de 1
Mbps, si 1000 estaciones envían paquetes de 1000 bits cada segundo, entonces la
carga ofrecida iguala la capacidad. Aunque Stallings se refiriera a la capacidad de un
LAN, capacidad podría referirse a la capacidad de una WAN, una entera red o las partes
de una rede, o la el trafico de la placa madre de un switch o router.

En general, para contar si la capacidad es suficiente, sólo unos parámetros son
necesarios:
• El número de estaciones.
• El tiempo medio que una estación es ociosa entre el envío de paquetes.
• El tiempo requerido transmitir un mensaje una vez el acceso medio es ganado.

Estudiando tiempos ociosos y tamaño de los paquetes con un analizador de protocolo, y
estimando el número de estaciones, usted puede determinar si la capacidad propuesta
es suficiente.

Si usted investiga tipos de flujo de tráfico, como hablado antes en este capítulo, usted
puede desarrollar estimaciones más precisas de la carga.

En vez de asumir que todas las estaciones tienen calidades similares que generan
carga, usted puede asumir que las estaciones usando una aplicación particular tienen
calidades similares que generan carga. Las asunciones pueden ser hechas sobre
tamaño de paquete y tiempo ocioso para una aplicación después de que usted ha
clasificado el tipo de flujo y ha identificado los protocolos usado por la aplicación.

Para una aplicación de cliente/servidor, el tiempo ocioso para el servidor depende del
número de clientes que usan al servidor, y la arquitectura y las características de
interpretación del servidor (velocidad de acceso de disco, velocidad de acceso de RAM,
caching mecanismos, etcétera).

Estudiando el tráfico de red de servidores con un analizador de protocolo, usted puede
estimar un tiempo ocioso medio.

Marcos Huerta S. 39


El tiempo ocioso en el lado de cliente depende en parte de la acción de usuario, el que
significa que es imposible predecir exactamente el tiempo ocioso. Sin embargo, usted
puede hacer estimaciones del tiempo ocioso estudiando el tráfico con un analizador de
protocolo y usando escrituras para simular acciones de usuario en el peor de los caso, o
usando un instrumento de modelado de red.

Después de que usted ha identificado la carga de tráfico aproximada para un flujo de
aplicación, usted puede estimar la carga total para una aplicación multiplicando la carga
para el flujo por el número de dispositivos que usan la aplicación. La investigación que
usted hace en el tamaño de comunidades de usuario y el número (de servidores) de
almacen de datos puede ayudarle a calcular una exigencia del ancho de banda
agregada aproximada para cada aplicación.

La documentación de la posición de comunidades de usuario y almacenes de datos, en
las cuales usted hizo el formulario, puede ayudarle a entender la cantidad de tráfico que
fluirá de un segmento al otro. Este puede ayudar en la selección de tecnologías de
columna vertebral y dispositivos de funcionamiento entre redes.

Estimando la carga de tráfico, además de la investigación de tiempos ociosos entre
paquetes, tamaños de paquetes, y comportamiento de flujo, usted también debería
investigar modelos de uso de aplicación y exigencias QoS. Algunas aplicaciones son
usadas con poca frecuencia, pero requieren una cantidad grande del ancho de banda
cuando ellos son usados.

Documentación de Patrones de uso de Aplicación
El primer paso en la documentación de modelos de uso de aplicación debe identificar
comunidades de usuario, el número de usuarios en las comunidades, y las aplicaciones
que emplean los usuarios. Este paso, que fue cubierto ya antes en esta sección, puede
ayudarle a identificar el número total de usuarios para cada aplicación.

Además de la identificación del número total de usuarios para cada aplicación, usted
también debería documentar la información siguiente:
• La frecuencia de sesiones de aplicación (el número de sesiones por día, semana,
mes o independientemente del período de tiempo es apropiado).
• La longitud de una sesión de aplicación media.
• El número de usuarios simultáneo de una aplicación.

Armado con la información en la frecuencia y la longitud de sesiones, y el número de
sesiones simultáneas, usted puede predecir más exactamente la exigencia de ancho de

Marcos Huerta S. 40


banda agregada para todos los usuarios de una aplicación. Si no es práctico investigar
estos detalles, usted puede hacer algunas conclusiones:
• Usted puede asumir que el número de usuarios de una aplicación es igual al número
de usuarios simultáneos.
• Usted puede asumir que todas las aplicaciones son usadas todo el tiempo de modo
que su cálculo de ancho de banda sea un caso pico de estimación (máxima).
• Usted puede asumir que cada usuario abre sólo una sesión y que una sesión dura
todo el día hasta que el usuario cierre la aplicación al final de día.

Refinando Estimaciones de Carga de Tráfico causada por Aplicaciones
Para refinar la estimación de requerimientos de aplicación ancho de banda, usted tiene
que investigar el tamaño de objetos de datos enviados por aplicaciones, la sobrecarga
causada por capas de protocolo, y cualquier carga adicional causada por la inicialización
de aplicación. (Algunas aplicaciones envían mucho más tráfico durante la inicialización
que durante la operación estable.)

Como las aplicaciones y los usuarios varían extensamente en el comportamiento, es
difícil estimar exactamente el tamaño medio de objetos de datos que los usuarios
transfieren el uno al otro y a servidores. (La respuesta de ingeniería verdadera a la
mayor parte de preguntas relacionadas para conectar a la red tráfico es "esto depende.")
el cuadro siguiente proporciona algunas estimaciones para tamaños de objeto que
usted puede usar haciendo cálculos atrás de la carga de tráfico de aplicación, pero
recordar que el cuadro proporcionado no toma el lugar de un análisis cuidadoso del
comportamiento de aplicación actual.

Tabla Nro. 08 Tamaño Aproximado de Objetos de Transferencia de Aplicaciones a
través de redes

Marcos Huerta S. 41


La Estimación de Sobrecarga de Tráfico para Varios Protocolos
La sección anterior habló de la caracterización de la carga de tráfico de aplicación
mirando el tamaño de objetos de datos que las aplicaciones transfieren a través de
redes. Para caracterizar completamente el comportamiento de aplicación, usted debería
investigar qué protocolos usa una aplicación. Una vez que usted sabe los protocolos,
usted puede calcular la carga de tráfico más exactamente añadiendo el tamaño de
cabecera de protocolo al tamaño de objetos de datos.

Tabla Nro. 09 de Sobrecarga de Tráfico para varios Protocolos

La Estimación de Carga de Tráfico Causada por Inicialización de Sesión y
Estación de Trabajo
Según las aplicaciones y protocolos que usa una estación de trabajo, la inicialización de
estación de trabajo puede causar una carga en redes debido al número de paquetes y,
en algunos casos, el número de paquetes de broadcast. Aunque este se haga menos de
un problema cuando el ancho de banda de red se ha hecho con estaciones de trabajo
con CPUs rápidas y baratas, que hará de modo que el procesamiento transmitido no sea
una preocupación.

La Estimación de Carga de Tráfico Causada por Protocolos de Enrutamiento
En este punto en el proceso de diseño de red, usted no podría haber seleccionado
protocolos de encaminamiento para el nuevo diseño de red, pero usted debería haber
identificado protocolos de encaminamiento que corren en la red existente. Ayudarle a
caracterizar tráfico de red causado por protocolos de enrutamiento, Tabla le mostrara la

Marcos Huerta S. 42


cantidad de ancho de banda usada por herencia de protocolos de enrutamiento vector-
distancia.

Tabla Nro. 10 Ancho de banda Usada por Herencia de Protocolos de enrutamiento

Un router envía largas tablas de enrutamiento de vector-distancia que cada minuto
puede usar un porcentaje significativo del ancho de banda de la WAN. Como el
protocolo de encaminamiento limita el número de rutas por paquete, en redes grandes,
un router de tráfico envía paquetes múltiples para enviar la tabla entera.

Los nuevos protocolos de encaminamiento, como OSPF y EIGRP, usan ancho de banda
muy pequeña. En caso de OSPF, su preocupación principal debería ser la cantidad de
ancho de banda consumida por los paquetes de sincronización de base de datos que los
routers de tráfico envían cada 30 minutos. Subdividiendo una red de OSPF en áreas y
usando la ruta sumarizada, este tráfico puede ser minimizado. Otro tráfico de
sincronización de base de datos, es el único tráfico que OSPF envía después de la
inicialización es pequeño paquete Hello cada 10 segundos.

El EIGRP también envía paquetes Hello, pero con más frecuencia que OSPF (cada 5
segundos). Por otra parte, EIGRP no envía ninguna actualización de ruta periódica o
paquetes de sincronización de base de datos. Esto sólo envía actualizaciones de ruta
cuando hay cambios en la topología.

Caracterización del Comportamiento del Tráfico
Seleccionar una apropiada solución de diseño de red, usted tiene que entender el
protocolo y el comportamiento de las aplicaciones además de flujos de tráfico y carga.
Por ejemplo, para seleccionar topologías apropiada de LAN, usted tiene que investigar
el nivel del tráfico de broadcast en la LAN. Para aprovisionar la capacidad adecuada
para LAN y WAN, usted tiene que chequear la utilización extra de ancho de banda
causada por protocolos ineficientes y tamaños de paquetes no óptimos o retransmisión
de temporizadores.

Marcos Huerta S. 43


Comportamiento de Broadcast/Multicast
Un paquete de broadcast que va a todas las estaciones de red en un LAN. En la capa
de enlace de datos, la dirección de destino de un paquete de broadcast es
FF:FF:FF:FF:FF:FF (todos 1s en el binario). A paquete de multicast es un paquete que
va a un subconjunto de estaciones. Por ejemplo, un paquete destinado a
01:00:0C:CC:CC:CC va a routers de tráfico Cisco e switches que dirigen el Protocolo de
Descubrimiento Cisco (CDP) en un LAN.

Los dispositivos de capa 2 , como switches y bridge, envian los paquetes de broadcast y
multicast a todos los puertos. El envió de paquetes de broadcast y multicast puede ser
un problema de escalabilidad para grandes edificaciones de (switches o bridge) redes.
Un router no envia tráfico de broadcast o multicast. Todos los dispositivos en un lado de
un router son considerados la parte de un solo dominio de bradcast.

Además de la inclusión de routers en el diseño de una red disminuira el transporte de
broadcast, usted también puede limitar el tamaño de un dominio de broadcast poniendo
en práctica LAN virtuales (VLANs). Tecnología de VLAN, que en la sección, "El diseño
de una Topología de Red," habla más detalladamente, permite que un administrador de
red subdivida a usuarios en subredes asociando puertos del switch con uno o varios
VLANs. Aunque un VLAN pueda atravesar muchos switches, el tráfico de broadcast
dentro de un VLAN no es transmitido fuera del VLAN.

Demasiados paquetes de broadcast pueden abrumar estaciones finales, switches, y
routers. Es importante que usted investigue el nivel del tráfico de broadcast en su diseño
propuesto y limite el número de estaciones en un simple dominio de broadcast. El
término radiación de broadcast a menudo es usado para describir el efecto de broadcast
que se extienden del remitente a todos los dispositivos en un dominio de broadcast. La
radiación de broadcast puede degradar la performance en estaciones de red.

La tarjeta de interfaz de red (NIC) con una estación de red pasa broadcast y multicast
relevantes a la CPU de la estación. Algunos NICs pasan todas las multicast a la CPU,
aun cuando las multicast no son relevantes, porque las NICs no tienen el software de
conductor que es más selectivo. El software de conductor inteligente puede decir una
NIC que multicast pasa a la CPU. Lamentablemente, no todos los conductores tienen
esta inteligencia. Las CPUs en las estaciones de red se hacen abrumadas tratando de
procesar niveles altos de broadcast y multicast. Si más del 20 por ciento del tráfico de
red es broadcast o multicast, la red tiene que ser segmentada usando routers o VLANs.

Otra causa posible del pesado tráfico de broadcast es la tormenta de broadcast causada
por intermitencias en la red o estaciones de red caídas. Por ejemplo, una máscara de

Marcos Huerta S. 44


subred de mal asignada puede hacer que una estación envíe paquetes de ARP
innecesariamente porque la estación no se distingue correctamente entre estación y
direcciones de broadcast, haciéndolo enviar ARPs para direcciones de broadcast.

En general, sin embargo, el tráfico de broadcast es necesario e inevitable. El
encaminamiento y la conmutación de protocolos usan broadcast y multicast para
compartir la información sobre la topología de la red. Los servidores envían broadcast y
multicast para anunciar sus servicios. Los protocolos de escritorio como AppleTalk,
NetWare, NetBIOS, y TCP/IP requieren de paquetes de broadcast y multicast para
encontrar los servicios y chequear para la autenticarse de direcciones y nombres.

Cuando diseñamos una topología de red, se cubrirá en secciones mas adelante mas
detalladamente, mostramos una tabla de recomendaciones para limitar el número de
estaciones en un dominio de broadcast solo basada en el protocolo (s) de escritorio en
uso.

Tabla Nro. 11 Tamaño Máximo en un Dominio de Broadcast

Eficacia de Red
La caracterización del comportamiento de tráfico de red requiere la ganancia de un
entendimiento de la eficacia de las nuevas aplicaciones de red. Eficacia se refiere a si
las aplicaciones y los protocolos usan el ancho de banda con eficacia. La eficacia es
afectada por el tamaño del paquete, la interacción de protocolos usados por una
aplicación, windowing y control de flujo, y mecanismos de recuperación de error.

Tamaño del Paquete
Usando un tamaño de paquete que es el máximo apoyo para el medio en uso tiene un
impacto positivo en la performance de red para aplicaciones de bulk. Para aplicaciones
de transferencia de archivo, en particular, usted debería usar la unidad máxima de
transmisión más grande posible (MTU). Según las pilas de protocolo que su cliente

Marcos Huerta S. 45


usará en el nuevo diseño de red, el MTU puede ser configurado para algunas
aplicaciones.

En un ambiente IP, usted debería evitar aumentar el MTU más de lo soportado, evitar la
fragmentación y reensamblación de paquetes. Cuando los dispositivos al final de los
nodos o routers tienen que fragmentar y volver a reensamblar paquetes, la performance
se degrada.

Los sistemas operativos modernos soportan el descubrimiento del MTU. Con el
descubrimiento MTU, el software puede descubrir dinámicamente y usar el tamaño más
grande del paquete que cruzará la red sin requerir la fragmentación. El descubrimiento
de MTU generalmente trabaja, pero hay algunos problemas con ello como mencionamos
en el "Análisis de Eficacia de Red".

Interacción de Protocolo
La ineficiencia en redes no es causada sólo por pequeños tamaños de paquetes. La
ineficiencia también es causada por la interacción de protocolos y la no correcta
configuración de temporizadores de reconocimiento y otros parámetros.

Windowing y Control de Flujo
Para entender realmente el tráfico de red, usted tiene que entender el control de flujo y
windowing. Un dispositivo TCP/IP, por ejemplo, envía segmentos (paquetes) de datos
en secuencia rápida, sin esperar un reconocimiento, hasta que su envío de ventana ha
sido agotado. Una estación envía la ventana está basado en el recipiente que reciba la
ventana. El estado del recipiente en cada paquete TCP determina cuantos datos está
listo para recibir. Este total puede variar de unos bytes hasta 65,535 bytes. El recipiente
de ventana está basado en cuanta memoria el receptor tiene y que tan rápido procesa
los datos recibidos. Usted puede optimizar la eficacia de red aumentando la memoria y
el poder de CPU en las estaciones finales, el cual pueden causar ventanas de recipiente
grande.

Algunas aplicaciones TCP/IP corren encima de UDP, y no TCP. En este caso, no
hay ningún control de flujo o el control de flujo es manejado en la sesión o capa
de aplicación. Mostramos una lista para determinar qué protocolos están basados
en TCP y qué protocolos están basados en UDP:
• Protocolo de transferencia de archivos (FTP): Puerto de TCP 20 (datos) y puerto
TCP 21 (control).
• Telnet: Puerto de TCP 23.
• Protocolo de Transferencia Postal Simple (SMTP): Puerto de TCP 25.

Marcos Huerta S. 46


• Protocolo de Transferencia de Hipertexto (HTTP): Puerto de TCP 80.
• Protocolo de Dirección de Red Simple (SNMP): Puertos de UDP 161 y 162.
• Sistema de Nombre de Esfera (DNS): Puerto de UDP 53.
• Protocolo de Transferencia de Archivos Trivial (TFTP): Puerto de UDP 69.
• Servidor de DHCP: Puerto de UDP 67.
• Cliente de DHCP: Puerto de UDP 68.
• Llamada de Procedimiento Remota (RPC): Puerto de UDP 111

Mecanismos de Recuperación de error
Los mecanismos de recuperación de error mal diseñados pueden gastar el ancho de
banda. Por ejemplo, si un protocolo retransmite de nuevo datos muy rápidamente sin
esperar un periodo de tiempo para recibir un reconocimiento, este puede causar la
degradación del performance para el resto de la red debido al ancho de banda usada.

Los protocolos de baja conexión por lo general no ponen en práctica la recuperación de
error. Mayormente en la capa de enlace de datos y los protocolos de capa de red son de
baja conexión. Algunos protocolos de capa de transporte, como UDP, son de baja
conexión.

Los mecanismos de recuperación de error para protocolos orientados por conexión
varían. TCP implementa un algoritmo de nuevo de retransmisión adaptable, el que
significa que el ratio de nuevas retransmisiones se reduce cuando la red esta
congestionada, el cual optimiza el uso del ancho de banda.

Las nuevos implementaciones TCP también ponen en práctica ACK selectivo (SACK),
esta descrito en el RFC 2018. Sin el SACK, esta predispuesto al error, los altos caminos
de tardanza pueden experimentar que el rendimiento baje debido al camino que TCP
reconoce datos. Los reconocimientos de TCP (ACKs) son acumulativos hasta el punto
donde un problema ocurre. Si los segmentos pierden el número de ACK es uno más que
el número del último byte que fue recibido antes de la pérdida, aun si más segmentos
llegaran después de la pérdida. No hay ningún camino para el receptor para recibir
algún reporte de un agujero en los datos recibidos. Este hace que el remitente espere un
tiempo de ida y vuelta para averiguar sobre cada segmento perdido, o retransmita de
nuevo innecesariamente segmentos que el recipiente puede haber recibido
correctamente.

Con el mecanismo de SACK, el recipiente TCP rellena el campo de opción de SACK en
la cabecera TCP para informar al remitente de los bloques no contiguos de datos que
han sido recibidos. El remitente puede retransmitir de nuevo entonces sólo los
segmentos ausentes. RFC 2018 define una opción TCP para rellenar los números de

Marcos Huerta S. 47


secuencia recibida para bloques y otra opción TCP para informar al recipiente durante el
apretón de manos de tres caminos que el host soporta SACK.

Caracterizando los Requerimientos de Calidad de Servicio
El análisis de los requerimientos de tráfico de red no es completamente tan simple como
identificando flujos, midiendo la carga para flujos, y caracterizando el comportamiento de
tráfico como de broadcast y de comportamiento error. Usted también tiene que
caracterizar los requerimientos QoS para aplicaciones.

Sólo conociendo los requerimientos de carga (ancho de banda) para una aplicación no
es suficiente. Usted también tiene que conocer si los requerimientos son flexibles o
inflexibles. Algunas aplicaciones siguen trabajando (aunque despacio) cuando el ancho
de banda no es suficiente. Otras aplicaciones, como voz y aplicaciones de vídeo, son
dadas inútiles si un cierto nivel del ancho de banda no está disponible. Además, si usted
tiene una mezcla de aplicaciones flexibles e inflexibles en una red, usted tiene que
determinar si es práctico tomar prestada el ancho de banda de la aplicación flexible para
guardar el funcionamiento de aplicación inflexible.

La voz es también inflexible en cuanto a la tardanza. La voz es también sensible a la
pérdida de paquete, que resulta en recorte de periódico de voz y se salta. Sin la
configuración apropiada en toda la red de QoS, la pérdida puede ocurrir debido a
enlaces congestionados y un pobre buffer de paquetes y manejo de dirección de cola
en los routers.

Siguiendo esta sección siguiente que analiza los requerimientos de QoS usando ATM e
Internet la técnica Engineering Task Force (IETF). El objetivo de estas secciones es
introducirle en la terminología del ATM y IETF que los ingenieros usan para clasificar el
tráfico y especificar los requerimientos de QoS por clases de tráfico. Aunque el material
sea muy altamente técnico y detallado, esto debería darle alguna idea fundamental
sobre la clasificación de los tipos de aplicaciones que jugarán una parte en su diseño de
red y estar preparado para futuros capítulos que cubren estrategias de diseño y
optimización de redes que pueden encontrar las necesidades de varias aplicaciones.

Calidad de ATM de Especificaciones de Servicio
En su documento "Especificación del Manejo de Trafico la Versión 4.1” el Forum de
ATM hace un trabajo excelente de clasificar los tipos de servicio que una red puede
ofrecer para soportar diferentes clases de aplicaciones. Incluso si su cliente no tiene
ningunos proyectos de usar la tecnología del Modo de Transferencia Asincrónico (ATM),
la terminología del Foro de ATM es todavía provechosa porque esto identifica los
diferentes parámetros que las clases de aplicaciones deben especificar para solicitar un

Marcos Huerta S. 48


cierto tipo del servicio de red. Estos parámetros incluyen tardanza y variación del
tamaño de tardanza, pérdida de datos, y picos de tráfico máximo, sostenible, y mínimos.
Aunque usted debiera sustituir la palabra celda con paquete en algunos casos, las
definiciones de Foro de ATM pueden ayudarle a clasificar aplicaciones en cualquier red,
hasta redes que no son ATM.

El Foro de ATM define seis categorías de servicio, cada uno de las cuales es descrito
más detalladamente en esta sección:
• Velocidad binaria constante (CBR)
• Velocidad binaria variable de tiempo real (rt-VBR)
• Velocidad binaria variable no tiempo real (nrt-VBR)
• Velocidad binaria no especificada (UBR)
• Velocidad binaria disponible (ABR)
• Precio de marco garantizado (GFR)

Para cada categoría de servicio, el Foro de ATM especifica un juego de parámetros para
describir tanto tráfico presente en la red como el QoS requerido de la red. El Foro de
ATM también define mecanismos de control de tráfico que la red puede usar para
encontrar objetivos QoS. La red puede implementar tales mecanismos de conexión de
control de admisión y asignación de recurso diferentes para cada categoría de servicio.

Las categorías de servicio son distinguidas al comienzo siendo tiempo real o tiempo no
real. El CBR y rt-VBR son categorías de servicio de tiempo real. Las aplicaciones de
tiempo real, como voz y aplicaciones de vídeo, requieren la variación de tardanza y
tardanza fuertemente obligada. Las aplicaciones en tiempo no real, como
cliente/servidor y aplicaciones de datos de terminal/host, no requieren la tardanza
fuertemente obligada y retrasan la variación. El Nrt-VBR, UBR, ABR, y GFR son
categorías de servicio tiempo no real.

Categoría de Servicio de Velocidad Binaria Constante
Cuando CBR es usado, unos recursos de reservas de red del final del sistema de la
fuente y pregunta por una garantía QoS negociado es asegurado a todas las celdas
mientras las celdas se conforman a las pruebas de conformidad relevantes. La fuente
puede emitir celdas en el pico de celda máximo (PCR) en cualquier momento y para
cualquier duración y los compromisos QoS deberían pertenecer. El CBR es usado por
aplicaciones que necesitan la capacidad de solicitar que una cantidad estática del ancho
de banda estuviera continuamente disponible durante una conexión de por vida. La
cantidad de ancho de banda que una conexión requiere es especificada por el valor de
PCR.

Marcos Huerta S. 49


El servicio de CBR intenta soportar aplicaciones de tiempo real que requieren la
variación de tardanza fuertemente obligada (por ejemplo, la voz, el vídeo, y la emulación
de circuitos), pero no es restringido a estas aplicaciones. La fuente puede emitir celdas
debajo de PCR negociado o ser silenciosa durante períodos del tiempo. Se asume que
celdas que son retrasadas más allá del valor especificado por la tardanza de
transferencia de parámetros de celdas máxima (maxCTD) son del valor
considerablemente reducido a la aplicación.

Categoría de Servicio de Velocidad Binaria Variable Tiempo no real
La categoría de servicio nrt-VBR es requerida para aplicaciones de tiempo no real que
tienen características de tráfico bursty. El servicio es caracterizado en términos de PCR,
SCR, y MBS. Para celdas que son transferidas dentro del contrato de tráfico, la
aplicación espera una proporción baja de pérdida de celdas (CLR). El servicio de nrt-
VBR puede

Servicio de Control de Carga
El Servicio de control-Carga es definido en RFC 2211 y provee a un cliente un flujo de
datos con QoS que se aproxima al QoS este mismo flujo recibiría una descarga en la
red. El control de admisión es aplicado a los requisitos de servicio solicitado y es
recibido aun cuando la red esta sobrecargada.

El Servicio de Control-Carga es requerido para aplicaciones que son muy sensibles a
condiciones sobrecargadas, como aplicaciones de tiempo real.

Estas aplicaciones trabajan bien en redes descargadas, pero degradan rápidamente en
redes sobrecargadas. Un servicio, como el Control-Carga que imita redes descargadas
sirve estos tipos de aplicaciones bien.

Asumiendo que la red funciona correctamente, un servicio de control-carga esta
solicitando de la aplicación puede asumir lo siguiente:
• Un alto porcentaje de paquetes transmitidos será recepcionados con éxito al final
de los nodos de la red. (El porcentaje de paquetes que no es entregado con éxito
debe aproximarse al índice de errores de paquete básico del medio de transmisión.)
• La tardanza de tránsito experimentada por un porcentaje muy alto de los paquetes
entregados no excederá el mínimo transmitido en la tardanza experimentada por
cualquier paquete con éxito entregado. (Esta tardanza de tránsito mínima incluye la
tardanza de velocidad de luz más el tiempo de procesamiento fijo en routers y otros
dispositivos de comunicaciones a lo largo del camino.)

Marcos Huerta S. 50


El servicio de control-carga no acepta o hace el uso de valores objetivo específicos para
parámetros como tardanza o pérdida. En cambio, la aceptación de una petición del
servicio de control-carga implica un compromiso por el nodo de red para proveer el
requester del servicio estrechamente equivalente con esto proporcionado a incontrolado
(mejor esfuerzo) tráfico en condiciones ligeramente cargadas.

Un nodo de red que acepta una petición del servicio de control-carga debe usar
funciones de control de admisión para asegurar que los recursos adecuados están
disponibles para manejar el nivel solicitado del tráfico, como definido por las solicitudes
TSpec . Los recursos incluyen el ancho de banda del, router o el espacio del bufer-
puerto del switch, y la capacidad computacional del motor que avanza el paquete.

Servicio Garantizado
El RFC 2212 describe el comportamiento requerido del nodo de red llamado a entregar
un servicio garantizado esta características garantiza tanto la tardanza como ancho de
banda. El servicio garantizado proporciona la firma (matemáticamente probable) en la
tardanzas de punta a punta que hacen cola paquete. Esto no intenta minimizar la
inquietud y no está preocupado por reparar la tardanza, como la tardanza de
transmisión. (Reparar la tardanza es una propiedad del camino elegido, que es
determinado por el mecanismo de sistema, como RSVP.)

El servicio garantizado garantiza que los paquetes llegarán dentro del plazo de entrega
garantizado y no serán descartado debidos a desbordamientos, condición de que el
tráfico del flujo es conformado por TSpec. Una serie de nodos de red que ponen en
práctica la implementación del RFC 2212 esta asegura un nivel de ancho de banda,
cuando es usado por un flujo regulado, produce un servicio salto-tardanza sin la pérdida
de cola (asumiendo que no falla ningún componentes de red o cambios de la
encaminamiento durante la vida del flujo).

El servicio garantizado es requerido para aplicaciones que necesitan una garantía que
un paquete no llegará más tarde que un cierto tiempo después de que fue transmitido
por su fuente. Por ejemplo, algunas aplicaciones de repetición de audio y de vídeo son
intolerantes de un paquete que llega después de su tiempo de repetición esperado. Las
aplicaciones que tienen exigencias de tiempo real también pueden usar el servicio
garantizado.

El ratio es medido en bytes de datagramas IP por segundo, y puede extenderse de 1
byte por segundo a tan grande como 40 TB por segundo (el ancho de banda teórica
máxima de solo un hilo de fibra). El tamaño del paquete puede extenderse de 1 byte a
250 GB. El rango de valores es intencionadamente grande para tener en cuenta futuras

Marcos Huerta S. 51


anchos de banda. El rango no intenta implicar tanto a un nodo de red tiene que soportar
el rango de la red entera.

La expectativa del grupo de funcionamiento de Servicios Integrado consiste en que un
revelador de software puede usar RFCs relevante para desarrollar aplicaciones
inteligentes que pueden poner exactamente el ratio de paquete y el tamaño. Una
aplicación por lo general puede estimar exactamente la tardanza esperada que hace
cola que el servicio garantizado proporcionará. Si la tardanza es más grande que
esperado, la aplicación puede modificar su paquete simbólico para conseguir una
tardanza inferior.

Como un diseñador de red, no le visitarán generalmente para estimar ratios de paquete
simbólico y tamaños. Por otra parte, usted debería reconocer qué necesidad de
aplicaciones garantizada el servicio y tienen alguna idea de su comportamiento de falta
y si una reconfiguración del comportamiento de falta es posible. Si una aplicación puede
solicitar el ancho de banda de terabytes por segundo, usted tiene que saber este debido
al efecto negativo que esto podría tener en otras aplicaciones.

Documentación Requerimientos de QoS
Usted debería trabajar con su cliente para clasificar cada aplicación de red en una
categoría de servicio. Una vez que usted ha clasificado la aplicación, usted debería
rellenar "la columna" de Requerimientos de QoS en la Tabla Nro. 07

Si su cliente tiene aplicaciones que pueden ser caracterizadas como necesitando la
controla-carga o el servicio garantizado, usted puede usar aquellos términos rellenando
"la columna" de Requerimientos de QoS. Si su cliente planea usar el ATM, usted puede
usar la terminología del Foro de ATM para categorías de servicio. Incluso si su cliente no
planea usar el ATM o IETF QoS, usted todavía puede usar el Foro de ATM o la
terminología de grupo de funcionamiento de Servicios Integrada. Otra alternativa debe
usar simplemente los términos inflexible y flexible. Inflexible es una palabra genérica
para describir cualquier aplicación que tiene exigencias específicas para ancho de
banda constante, tardanza, variación de tardanza, exactitud, y rendimiento. Flexible, por
otra parte, es un término genérico para aplicaciones que simplemente esperan que la
red haga el un mejor esfuerzo para encontrar los requerimientos. Muchas aplicaciones
no multimedia tienen requerimientos de QoS flexibles.

Para aplicaciones de voz, usted debería hacer más de una entrada en Tabla Nro. 07
debido a los requerimientos diferentes de flujo de control de llamada y la corriente de
audio. El flujo de control de llamada, se usa para establecer llamadas perdidas, no tiene
coacciones de tardanza estrictas, pero esto requiere una alta disponibilidad de red y

Marcos Huerta S. 52


puede haber un requerimiento GoS que debería ser especificada. Para la corriente de
voz, la clasificación QoS debería ser puesta en una lista usando el término de ATM o el
término de IETF servicio garantizado.

Resumen de Identificando objetivos y necesidades del cliente
En este punto en el proceso de diseño de red, usted ha identificado las aplicaciones de
red de un cliente y los requerimientos técnicas para un diseño de red que puede apoyar
las aplicaciones.

Este resume, "Identificando las Necesidades de Su Cliente y Objetivos." La Fase de
análisis de requerimientos es la fase más importante en el diseño red de la metodología
top down. La ganancia de un entendimiento sólido de los requerimientos de su cliente le
ayuda a seleccionar tecnologías que encuentran los criterios de un cliente para el éxito.

Usted debería ser capaz ahora de analizar los objetivos comerciales y técnicos de un
cliente y estar listo a comenzar a desarrollar un diseño de red lógico y físico. "Diseño de
Red Lógico," que diseñan una topología de red lógica, desarrollando el direccionamiento
de capa de red y nombramiento del modelo, selección de switches y de protocolos de
enrutamiento, y planificación de seguridad de red y estrategias de dirección.

Fase II: Diseño de una Red Lógica

Parte 5. Diseño de una topología de red

En este capítulo, usted aprenderá técnicas para desarrollar una topología de red. A
topología es un mapa de la red que indican segmentos de red, puntos de interconexión,
y comunidades de usuario. Además los sitios geográficos puedan aparecer en el mapa,
el objetivo del mapa es mostrar la geometría de la red, no la geografía física o
implementación técnica. El mapa es una vista panorámica del alto nivel de la red,
análoga a un dibujo arquitectónico que muestra la posición y el tamaño de cuartos para
un edificio, pero no los materiales de construcción para fabricar los cuartos.

El diseño de una topología de red es el primer paso en la fase de diseño lógica de la
metodología de diseño de red Top Down. Para encontrar los objetivos de un cliente para
escalabilidad y adaptabilidad, es importante para el arquitecto una topología lógica antes
de seleccionar productos físicos o tecnologías. Durante la fase de diseño de topología,
usted identifica redes y puntos de interconexión, el tamaño y alcance de redes, y los
tipos de dispositivos de funcionamiento entre redes que serán requeridos, pero no los
dispositivos actuales.

Marcos Huerta S. 53


Este capítulo proporciona tips tanto para diseño de redes WAN de campus como
empresariales, y se concentra en el diseño de red jerárquico, que es una técnica para
diseñar campus escalable y redes WAN usando un modelo modular por capas. Además
del diseño de red jerárquico, en esta sección también cubre topologías de diseño de red
redundantes y topologías con objetivos de seguridad. (La seguridad es cubierta más
detalladamente en la Parte 8, "Desarrollo de la Seguridad de Red.") Este capítulo
también cubre el Modelo de Red Empresarial Compuesta, que es la parte de la
Arquitectura Segura Empresarial de Cisco (SAFE).

Diseño de Red Jerárquica
Para encontrar los objetivos comerciales y técnicos de un cliente para un diseño de red
corporativo, usted podría tener que recomendar que una topología de red que consiste
en muchos interrelacionara componentes. Esta tarea es hecha más fácil si usted puede
"dividir y triunfar" el trabajo y desarrollar el diseño en capas.

Cada capa puede ser enfocada en funciones específicas, permitiéndole elegir los
correctos sistemas y caracteristicas para la capa. Por ejemplo, en La figura 11, routers
WAN de alto velocidad puede llevar el tráfico a través del backbone WAN de la
empresa, los routers de velocidad media pueden unir edificios en cada campus, y los
switches pueden conectar dispositivos de usuario y servidores dentro de edificios.

Figura Nro. 11. Topología Jerárquica

Una topología jerárquica típica esta dividida por tres capas:
• Una Capa Core de routers y switches de alta velocidad que son optimizados para
disponibilidad e performance.
• Una Capa de distribución routers y switches para la implementación de políticas.

Marcos Huerta S. 54

Metodologia topdownespañol

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Metodologia topdownespañol

Similaire à Metodologia topdownespañol (20)

Metodologia topdownespañol