Upload
krlmar
View
613
Download
68
Embed Size (px)
Citation preview
Metodologa Top Down
Marcos Huerta S. 18
METODOLOGIA DE DISEO DE RED TOP DOWN
Historia de la Metodologa TOP DOWN El diseo de red top-down es una disciplina que creci del xito de la programacin
de software estructurado y el anlisis de sistemas estructurados. El objetivo principal
del anlisis de sistemas estructurado es representar ms exacto las necesidades de
los usuarios, que a menudo son lamentablemente ignoradas. Otro objetivo es hacer
el proyecto manejable dividindolo en mdulos que pueden ser ms fcil de
mantener y cambiar.
El diseo de red top-down es una metodologa para disear 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 seleccin de routers, switches, y medios que funcionan en las capas inferiores.
El proceso de diseo de red top-down incluye exploracin divisional y estructuras de grupo para encontrar la gente para quien la red proporcionar servicios y de
quien usted debera conseguir la informacin valiosa para hacer que el diseo tenga
xito.
El diseo de red top-down es tambin iterativo. Para evitar ser atascado en detalles demasiado rpido, es importante conseguir primero una vista total de los
requerimientos de un cliente. Ms tarde, ms detalle puede ser juntado en
comportamiento de protocolo, exigencias de escalabilidad, preferencias de
tecnologa, etctera. El diseo de red top-down reconoce que el modelo lgico y el diseo fsico pueden cambiarse cuando ms informacin es juntada.
Como la metodologa top-down es iterativa, un acercamiento top-down deja a un
diseador de red ponerse "en un cuadro grande" primero y luego moverse en espiral hacia abajo segun exigencias tcnicas detalladas y especificaciones.
Los Sistemas de Cisco recomiendan un acercamiento modular con su modelo
jerrquico de tres capas. Este modelo divide redes en nucleo, distribucin, y capas
de acceso. La Arquitectura Segura de Cisco para Empresas (SAFE) y compuesto de
un Modelo de Red de Empresa, son tambin aproximaciones modulares para el
diseo de la red.
Con un acercamiento estructurado diseamos la red, cada mdulo es diseado por
separado, an con relacin a otros mdulos. Todos los mdulos son diseados
usando un acercamiento top-down que se concentra en los requerimientos,
Metodologa Top Down
Marcos Huerta S. 19
aplicaciones, y una estructura lgica antes de la seleccin de dispositivos fsicos y
productos que se implementara en el diseo.
Fase I: Identificando objetivos y necesidades del cliente Parte 1. Anlisis 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 mrgenes de tiempo cortos.
El comprender los objetivos comerciales y sus restricciones de sus clientes es un
aspecto crtico del diseo de red. Armado con un anlisis cuidadoso de los objetivos
comerciales de su cliente, usted puede proponer un diseo de red que contara con
la aprobacin de su cliente.
El entendimiento de la estructura corporativa tambin le ayudar a reconocer la
jerarqua de direccin. Uno de sus primeros objetivos en las etapas tempranas del
diseo de un proyecto de red debe determinar quines son los funcionarios con
poder de decisin. Quin tendr las autoridades para aceptar o rechazar su
propuesta de diseo de red?
Adems del anlisis de objetivos comerciales y determinacin de la necesidad de su
cliente de apoyar aplicaciones nuevas y existentes, es importante analizar cualquier
restriccin comercial que afectar su diseo de red.
Si usted tiene en mente cambios de estrategias comerciales y gestin de redes de
empresa discutido en las secciones anteriores, se hace posible poner una lista de
los objetivos comerciales en el diseo de alguna red tpica:
Aumento de ingresos y ganancia.
Aumento de Cuota de mercado.
Expansin de nuevos mercados.
Aumente ventajas competitivas sobre compaas en el mismo mercado.
Reduzca gastos.
Aumente la productividad de empleado.
Acorte ciclos de desarrollo de producto.
Use la fabricacin justo a tiempo.
Plan alrededor de escaseces componentes.
Ofrezca nuevos servicios de cliente.
Ofrezca el mejor soporte de cliente.
Metodologa Top Down
Marcos Huerta S. 20
Abra la red a componentes claves (perspectivas, inversionistas, clientes, socios de
negocio, proveedores, y empleados).
Construya relaciones y accesibilidad de informacin a un nuevo nivel, como una
base para un modelo organizacional de red.
Evite la interrupcin comercial causada por problemas de seguridad de red.
Evite la interrupcin comercial causada por desastres naturales y poco naturales.
Modernice tecnologas anticuadas.
Reduzca los gastos de telecomunicaciones y red , incluso elevado asociado con
redes separadas para voz, datos, y vdeo
Parte 2. Anlisis de los objetivos y limitaciones tcnicas
En este parte trata de dar algunos alcances para analizar las metas tcnicas de los
clientes para implementar una nueva red o actualizar una existente. Conociendo las
metas tcnicas de nuestros clientes podremos recomendar nuevas tecnologas que al
implementarlas cumplan con sus expectativas.
Los tpicos objetivos tcnicos 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
trminos que ambos puedan entender.
Escalabilidad La escalabilidad se refiere de cuanto es capaz de dar soporte al crecimiento del diseo
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 rpido tanto en usuarios, aplicaciones y conexiones de red. El diseo de red
que usted propone a un cliente debera 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 difcil de alcanzar para los que disean la red, sta puede ser
expresada en porcentajes por ao, mes, semana, da 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,
Metodologa Top Down
Marcos Huerta S. 21
rangos de error, estabilidad, y la cantidad de tiempo entre fracasos lo que refleja la
disponibilidad de la red.
Disponibilidad tambin lo asocian con la redundancia que no es un objetivo para el
diseo de red, mas bien es una solucin, se refiere que se duplica los enlaces a la red
para reducir tiempos lo que permite continuidad despus de fallas o desastres.
Disponibilidad esta asociada tambin con la resistencia que significa cuanto estrs
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 tcnicos para el diseo 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 podran realizar
para que mejore la performance de la red. Las metas de la performance de la red estn
bastante ligada con las metas de la escalabilidad.
Seguridad El diseo de la seguridad es uno de los aspectos ms importantes en el diseo de red
empresarial. Al incrementar las amenazas tanto dentro como fuera de la red de la
empresa se debe tener reglas y tecnologas de seguridad actualizadas e incorruptibles.
Las metas ms 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
algn tipo de problema la empresa debe ser capaz de seguir con sus actividades
normales.
La primera tarea para el diseo de la seguridad es planificar. Lo que significa que
debemos reconocer las partes ms vulnerables de la red, analizando los riesgos y
encontrando requerimientos.
Como es el caso de la mayora de las exigencias tcnicas de diseo, alcanzando
objetivos de seguridad significa hacer compensaciones. Las puestas en prctica de
seguridad pueden aumentar el costo de despliegue y funcionamiento de la red, tambin
puede afectar la productividad de usuarios, sobre todo si se dificulta el modo de trabajo
para proteger recursos y datos. La Seguridad tambin puede afectar la redundancia del
diseo de red por ejemplo si el trfico pasa por dispositivos de cifrado.
Metodologa Top Down
Marcos Huerta S. 22
Manejabilidad (Administracin) Cada cliente tiene objetivos y una forma de administrar la red diferente. Algunos clientes
tienen metas claras de cmo administrar la red y otras metas menos especficas. 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 administracin de funciones que
el cliente requiere.
La administracin de la red debe ser simplificada. Simplificarlos en paquetes de
funciones de administracin se entienden fcilmente y usados por administradores de
red. Durante la reunin de inicial de exigencias tcnicas para el diseo o actualizacin
de una red, se puede usar la terminologa ISO para simplificar la discusin de las metas
de los administradores de red con sus clientes, de la siguiente manera:
Administracin de funcionamiento. Analizar el trfico y el comportamiento de
aplicacin para optimizar una red, quedar en acuerdos de nivel de servicio, y el plan
para la extensin
Administracin de defecto. Descubrir, aislar y corregir de problemas; reportando los
problemas a usuarios finales y gerentes.
Administracin de configuracin. Control, funcionamiento, identificacin, y recolectar
datos de dispositivos de administracin
Administracin de Seguridad. Supervisin y pruebas de seguridad y poltica de
proteccin, manteniendo y distribuyendo contraseas y otra autenticacin e
informacin de autorizacin, llaves de cifrado directivas, y adhesin de revisin a
poltica de seguridad.
Administracin 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 ejecucin en un mapa de una red y aprendiendo la localizacin de
la mayora de los dispositivos y segmentos en el trabajo de la red y identificando algunos
mtodos establecidos para el direccionamiento y nombramiento y tambin archivando,
investigando los cables fsicos, reservas que son muy importante en la caracterstica de
la infraestructura de la red.
Ejecucin de un Mapa de Red
Para la mayora de los diseadores de red; la interconexin de dispositivos y segmentar
de la red es un buen camino para comenzar la compresin del flujo circulatorio.
Metodologa Top Down
Marcos Huerta S. 23
El objetivo es obtener un mapa ya implementado de la red, algunos diseos de los
clientes pueden tener mapas para un nuevo y mejor diseo de la red.
Herramientas para la Ejecucin de un Mapa de Red
Para ejecutar un mapa de la existencia de la red, deberamos invertir en una buena
herramienta de diagrama de red. Tales como:
Visio Corporations.
Visio Profesional.
Visio Profesional Ships.
Algunas compaas ofrecen esquematizar automticamente el descubrimiento de la red
existente, usando el siguiente software:
Pinpoint Softwares ClickNet Professional.
NetSuite Development.
Net Suite Advanced Professional Design.
NetSuite Professional Audit (similar ClickNet).
Que debera 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 pases y ciudades.
Edificios y pisos, y posibilidades cuartos y casetas.
Conexiones WAN y LAN entre edificios y entre campos.
Una indicacin de la capa de datos (WAN, LANS).
El Nmero de servicios proveedor de WANS.
La localizacin de las lneas y interruptores, aunque no es necesario en el eje y
centro.
La localizacin y alcance de redes virtuales (VPNs), que conecta los servicios
de los proveedor WAN.
La localizacin de las principales estructuras.
La localizacin de las mayores estaciones de ejecucin de la red.
La localizacin y alcance de algunas LANs Virtuales (VLANs).
La topologa de algunos sistemas de seguridad Firewall.
La localizacin de algunos sistemas de dial- in y dial out.
Algunas indicaciones de donde residen algunas estaciones de trabajo, aunque
no necesariamente la localizacin explicita de cada estacin de trabajo.
Metodologa Top Down
Marcos Huerta S. 24
Caracterizando el Direccionamiento y el Nombramiento de la Red La infraestructura lgica 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 diseo de red a los objetivos, aqu definir el mejor mtodo de direccionamiento
que se pueda usar para su diseo de red. Entre los cuales tenemos:
Subnetting.
Variable Lenght Subnet Masking (VLSM).
Supernetting o Aggregations.
Summarization.
Estos mtodos se explicaran ms adelante cuando se seleccione el protocolo y
direccionamiento de red.
Caracterizando el Cableado y el Medio
Es importante comprender el cableado y la instalacin elctricos del diseo 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 informacin ayudara a
determinar la Tecnologa de la capa de enlace basado en las restricciones de distancia.
Cuando el diseo del cableado esta en exploracin, determine cuales son los equipos y
los cables que estn etiquetado en la red existente.
Por ejemplo: la red de un edificio debera archivar las conexiones de un nmero de
cable y el tipo de instalacin que esta en uso en la red.
Probablemente la instalacin entre los edificios es unos de los sgtes:
Single mode fiber
Multi mode fiber
Shielded twisted pair (STP)
UTP categora 5
Cable coaxial
Microondas
Radiofrecuencia.
Lser
Infrarrojo
Metodologa Top Down
Marcos Huerta S. 25
Supervisando la Arquitectura Ambiental y Restricciones Cuando esta investigando el cableado hay que poner mucha atencin en los problemas
ambientales con la posibilidad de que el cableado podra pasar muy cerca donde haya
lugares propensos a inundarse, cerca de las carreteras donde el trfico de los vehculos
podra quebrar los cables, calefacciones, etc.
Este seguro que no tenga ningn 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 atencin a la arquitectura si este afecta la implementacin de
su diseo, este seguro que la arquitectura puede soportar el diseo tales como:
Aire acondicionado.
Calefaccin.
Ventilacin.
Proteccin de interferencias electromagnticas.
Puertas que no estn cerradas, etc.
Supervisando el buen Funcionamiento de la Red existente
Estudiar el performance de una red existente te da una lnea bsica dimensional para
poder medir y compara el performance del nuevo diseo de red propuesto el cual le
ayudara a demostrar a su cliente cuan mejor es su diseo en performance una vez
implementado.
Si la red es muy grande para estudiar todos sus segmentos, preste mayor atencin 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 circulacin la red con un analizador de protocolo como parte de
tu anlisis de la lnea bsica, podra identificar cuales de los protocolos estn 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 fcil. Una de las tareas
es seleccionar el tiempo para hacer estos anlisis para poder determinar el momento
exacto para poder realizarlo y determinar los problemas que presenta la red durante los
periodos altos de trfico, etc.
Los problemas de la red no son usualmente causados por los envos de malas
estructuras de tramas. En el caso token ring (La red Token-Ring es una implementacin
del standard IEEE 802.5, en el cual se distingue ms por su mtodo de transmitir la
Metodologa Top Down
Marcos Huerta S. 26
informacin que por la forma en que se conectan las computadoras., el problema
usualmente esta por estacin y problema de cable, en el caso de ethernet, es un difcil
precisar la causa del problema.
Algunos clientes no reconocen el valor de estudiar las redes existentes antes del diseo
y la implementacin. Los clientes generalmente se avocan por un diseo rpido por lo
cual puede hacer difcil poder dar marcha atrs y insistir en tiempo para desarrollar la
performance precisa de la red existente. Un buen entendimiento de los objetivos
tcnicos y de negocio del cliente pueden ayudar a decidir que cantidad de trfico deber
analizar en la red.
Analizando la Disponibilidad de la Red
Para documentar caractersticas de disponibilidad de la red existente, junte cualquier
estadstica que el cliente tiene durante el tiempo medio entre fallas (MTBF) y tiempo
medio de reparacin (MTTR) para las redes en conjunto as como segmentos de red
principales. Compare estas estadsticas con la informacin en la que usted se ha
juntado en MTBF y objetivos MTTR, Espera el cliente que su nuevo diseo aumente
MTBF y disminuya MTTR? Son los objetivos del cliente consideracin realista del
estado corriente de la red?
Dirjase a los ingenieros de red y tcnicos sobre las causas de los perodos ms
recientes y ms 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 interrupcin de red.
(Usted puede conseguir por lo general una vista ms exacta de causas de problema de
ingenieros y tcnicos que de usuarios y gerentes.)
Puede usar esta Tabla Nro. 01 para documentar.
Tabla Nro. 01 Caracterizar la Disponibilidad de la Red
Metodologa Top Down
Marcos Huerta S. 27
Analizando la Utilizacin de la Red Utilizacin de red es una medida de cuanta ancho de banda est en el uso durante un
intervalo de tiempo especfico. La utilizacin es comnmente especificada como un
porcentaje de capacidad. Si un instrumento que supervisa la red dice que la utilizacin
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 utilizacin
de red. Algunos instrumentos dejan al usuario cambiar la ventana. La utilizacin de un
intervalo largo puede ser til para reducir la cantidad de datos estadsticos que deben
ser analizados, pero la granularidad es sacrificada.
Figura Nro. 09. Analizando la Utilizacin de la Red
Utilizacin del Ancho de Banda por Protocolo
El desarrollo de una performance preciso de la performance de red tambin debera
incluir la utilizacin de medicin del trfico de broadcast contra el trfico unicast, y por
cada protocolo principal. Algunos protocolos envan excesivo trfico de broadcast, que
puede degradar seriamente la performance, sobre todo en redes switchadas.
Para medir la utilizacin 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 comparacin al total de ancho de banda en uso. Uso
relativo especifica cuanto ancho de banda es usada por protocolo en comparacin con
el ancho de banda total actualmente en uso en el segmento. Uso absoluto especifica
cuanta ancho de banda es usada por protocolo en comparacin con la capacidad total
del segmento (por ejemplo, en comparacin con 100 Mbps en Fast Ethernet).
Metodologa Top Down
Marcos Huerta S. 28
Tabla Nro. 02 Utilizacin del Ancho de Banda por Protocolo
Anlisis de la Exactitud de Red
Usted puede usar a un probador BER (tambin llamado BERT) en lneas seriales para
probar el nmero de bits daados comparados a los totales de bits.
Con redes por paquete switchados, hace ms 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 estacin de envo calcula un ciclo de
redundancia CRC basado en los bits del paquete. La estacin de envo reemplaza el
valor del CRC en el paquete. Una estacin de recepcin 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 anlisis de performance preciso, usted debera rastrear el nmero de
paquetes recibidos con CRC malo cada hora o cada dos das. Como es normal los
errores aumentan con la utilizacin, errores de documento como una funcin del nmero
de bytes vistos por el instrumento de escucha. Un umbral de regla bsica bueno para
considerar errores malsanos es que una red no debera tener ms de un paquete malo
por megabyte de datos. (Errores calculados este camino le deja simular una serie BERT.
Simplemente el clculo de un porcentaje de paquetes malos comparados con paquetes
buenos nos explica el tamao de paquete y de ah no da una indicacin buena de
cuantos trozos realmente se han daados).
Adems del rastreo de errores de capa de enlace de datos, como errores CRC, un
anlisis del performance preciso debera incluir la informacin en problemas de capa
superior. Un analizador de protocolo que incluye un sistema experto, como WildPackets
EtherPeek NX analizador de red, se apresura la identificacin de problemas de capa
Metodologa Top Down
Marcos Huerta S. 29
superior por automticamente generando diagnsticos y sntomas para conversaciones
de red y aplicaciones.
La exactitud tambin debera 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
peticin o la respuesta fue perdido. Correlacione la informacin sobre paquetes perdidos
con otras medidas de interpretacin 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 tambin puede medir paquetes
perdidos mirando la estadstica guardada por gestores de trfico en el nmero de
paquetes descartados de colas de salida o entrada.
Analizando la Eficiencia de la Red La utilizacin 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 nmero de paquete y tardanzas de ida y vuelta requeridas para una
transaccin. El nmero de paquetes por transaccin tambin puede ser minimizado si el
receptor es configurado con una ventana grande que lo permite aceptar paquetes
mltiples antes de que esto debiera enviar un reconocimiento.
Cambiando la transmisin y recepcin del tamao 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 transmisin mxima (MTU) en interfaces del router tambin
puede mejorar la eficacia.
Por otra parte, el aumento del MTU es a veces necesario en interfaces del router de
aquellos que usan tneles. Los problemas pueden ocurrir cuando una cabecera
suplementario es aadido por el tnel hace que el paquete sean ms grandes que falta
MTU. Un sntoma tpico 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 solucin 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
debera usar un analizador de protocolo para examinar los tamaos 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
Metodologa Top Down
Marcos Huerta S. 30
Figura Nro. 10. Graficando el Tamao de los Paquetes del Backbone
Analizar la Tardanza y Tiempo de Respuesta Para verificar que la performance de un nuevo diseo de red se encuentra dentro de las
exigencias de un cliente, es importante medir el tiempo de respuesta entre dispositivos
de red antes y despus de que un nuevo diseo de red es puesto en prctica. 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
estimacin del tiempo de respuesta en la capa de enlace de datos, capa de transporte, y
capa de aplicacin. (Este es una estimacin porque los tiempos de llegada de paquete
en un analizador slo pueden acercarse tiempos de llegada de paquete en estaciones
finales.)
Un modo ms comn de medir tiempo de respuesta es enviar paquetes de ping y medir
el tiempo de ida y vuelta (RTT) para enviar una peticin y recibir una respuesta.
Midiendo RTT, usted tambin puede medir la variacin RTT. Medidas las variaciones
son importantes para aplicaciones que no pueden tolerar muchas variaciones (por
ejemplo, voz y aplicaciones de vdeo). Usted tambin puede documentar cualquier
prdida de paquetes. Usted puede usar una tabla para documentar estas medidas ver figura:
Tabla Nro. 03 Medida del Tiempo de Respuesta
Metodologa Top Down
Marcos Huerta S. 31
El Chequeo del estado de los Routers principales, Switches, y Firewalls El paso final en la caracterizacin 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 topologa jerrquica, routers de
backbone e switches, y firewalls que tendrn los papeles ms significativos en su nuevo
diseo de red. No es necesario comprobar cada switch de LAN, slo los switches
principales, routers, y firewalls.
La comprobacin del comportamiento y la salud de un dispositivo de funcionamiento
entre redes incluye la determinacin que ocupado el dispositivo es (utilizacin de CPU),
cuantos paquetes esto ha tratado, cuantos paquetes esto se ha perdido, y el estado de
los buffer y colas. Su mtodo para tasar la salud de un dispositivo de funcionamiento
entre redes depende del vendedor y la arquitectura del dispositivo.
Parte 4. Caracterizando un diseo de trafico de red
Este seccin describe las tcnicas para caracterizar el flujo de trfico, el volumen de
trfico, y el comportamiento de protocolo. Las tcnicas incluyen el reconocimiento de
trfico fuente y almacenaje de datos, documentar las aplicaciones y uso el de protocolo,
y evaluar del trfico de red causado por protocolos comunes.
El la seccin anterior se habl de la caracterizacin de la red existente en trminos de
su estructura e interpretacin. Como el anlisis de la situacin existente es un paso
importante en un acercamiento de anlisis de sistemas para disear, este seccin se
habla de la caracterizacin de la red existente en trminos de flujo de trfico. Esta
seccin tambin cubre nuevas exigencias de diseo de red, aadiendo los dos primeras
secciones que cubrieron objetivos de diseo comerciales y tcnicos. Esta seccin
reenfoca en exigencias de diseo y describe exigencias en trminos de flujo de trfico,
carga, y comportamiento; y calidad de servicio (QoS) exigencias.
Caracterizando el Flujo de Trafico
La caracterizacin del flujo de trfico implica identificar fuentes y destinos del trfico de
red y analizar la direccin y la simetra de datos que viajan entre fuentes y destinos. En
algunas aplicaciones, el flujo es bidireccional y simtrico. (Ambos finales del flujo envan
el trfico en aproximadamente el mismo precio.) En otras aplicaciones, el flujo es
bidireccional y asimtrico. Las estaciones de cliente envan pequeas preguntas y los
servidores envan grandes corrientes de datos. Los broadcast de una aplicacin, el flujo
es unidireccional y asimtrico. Esta seccin habla de la caracterizacin de la direccin y
Metodologa Top Down
Marcos Huerta S. 32
la simetra del flujo de trfico en una red existente y anlisis del flujo para nuevas
aplicaciones de red.
La Identificacin de las Principales Fuentes de Trfico y Almacenamiento Para entender el flujo de trfico de red, usted debera 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 aplicacin 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 aplicacin cruza muchos departamentos. Cuando ms corporaciones usan la
direccin de la matriz y forman equipos virtuales para completar un proyecto, se hace
ms necesario caracterizar comunidades de usuario por aplicacin y uso de protocolo
ms bien que por el lmite 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 posicin de la figura, los nombres de posicin de uso que usted ya document en un
mapa. Para aplicaciones, nombres de aplicacin de uso en los cuales usted ya
document en los formularios de Aplicaciones de Red.
Tabla Nro. 04 Comunidades de Usuarios
Adems de la documentacin de comunidades de usuario, caracterizando el flujo de
trfico tambin 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 aplicacin 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 vdeo 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 Posicin, la
Aplicacin, y las columnas de Comunidad de Usuario, usa nombres que usted ya
document en un mapa y otras cartas.
Metodologa Top Down
Marcos Huerta S. 33
Tabla Nro. 05 Formulario de Almacenamiento de Datos
Documentar el Flujo de Trfico en la Red Existente La documentacin del flujo de trfico implica identificar y caracterizar flujos de trfico
individuales entre fuentes de trfico y almacenes. Los flujos de trfico se han hecho
recientemente un tema caliente para la discusin en la comunidad de Internet. Mucho
progreso est siendo hecho en la definicin de flujos, medicin de comportamiento de
flujo, y permiso de una estacin final de especificar los requerimientos de performance
por flujo.
Para entender mejor el comportamiento de flujo de trfico, usted puede leer la Peticin
de Comentarios (RFC) 2722, "Medida de Flujo de Trfico: Arquitectura." El RFC 2722
describe una arquitectura para la medida y reportaje de flujos de trfico de red, y habla
como la arquitectura est relacionada con una arquitectura de flujo de trfico total para
el intranet y el Internet.
La medicin del comportamiento de flujo de trfico puede ayudar a un diseador de red
a determinar qu trafico de routers deberan ser peer en los protocolos de
encaminamiento que usan un sistema peering, como el Border Gateway Protocol (BGP).
La medicin del comportamiento de flujo de trfico tambin puede ayudar a los
diseadores de la red y debran hacer lo siguiente:
Caracterice el comportamiento de redes existentes.
Plan de desarrollo y extensin 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 trfico de red puede ser definido como protocolo e informacin de
aplicacin transmitida entre entidades que se comunican durante una sesin sola. Un
flujo tiene atributos como direccin, simetra, caminos de enrutamiento, opciones de
enrutamiento, nmero de paquetes, nmero de bytes, y se dirige el flujo hacia una
direccin final. Una entidad que se comunica puede ser un sistema de final (host), una
red, o un sistema autnomo.
Metodologa Top Down
Marcos Huerta S. 34
El mtodo ms simple para caracterizar el tamao de un flujo es medir el nmero de
Kilobytes o Mbytes por segundo entre entidades que se comunican. Para caracterizar el
tamao de un flujo, use un analizador de protocolo o conecte a la red el sistema de
direccin para registrar la carga entre fuentes importantes y destinos. Los instrumentos
de Cisco para caracterizar flujos de trfico incluyen Cisco FlowCollector y el Analizador
de Datos, que estn basados en el Cisco NetFlow la tecnologa.
Usted puede usar el formulario siguiente descirto para documentar informacin sobre la
direccin y volumen de flujos de trfico. El objetivo es documentar los Kilobytes o
Mbytes por segundo entre pares de sistemas autnomos, redes, hosts, y aplicaciones.
Para conseguir la informacin para llenar los formularios, coloque un dispositivo que
monitoree el core de la red y djele coleccionar datos por uno o dos das. Para
conseguir la informacin para llenar la columna de Path, usted puede encender la
opcin de grabar-ruta de registro en una red de IP. La opcin de ruta de registro tiene
algunas desventajas, sin embargo. Esto no apoya redes muy grandes y es a menudo
minusvlido para razones de seguridad. Usted tambin puede estimar el path mirando la
tabla de encaminamiento y anlizando el trfico de red en multiples segmentos.
Tabla Nro. 06 Flujo de Trfico en la Red Existente
La Caracterizacin de Tipos de Flujo de Trfico para Nuevas Aplicaciones de Red
Como mencionado, un flujo de red puede ser caracterizado por su direccin y simetra.
La direccin especifica si los datos viajan en ambas direcciones o en slo una direccin.
La direccin tambin especifica el camino que un flujo toma cuando esto viaja de la
fuente al destino por una de las redes. La simetra describe si el flujo tiende a tener alta
performance o requerimientos de QoS en una direccin que en la otra direccin. Muchas
aplicaciones de red tienen requerimientos diferentes en cada direccin. Algunas
tecnologas de transmisin como la Lnea de Suscriptor Digital Asimtrica (ADSL), son
fundamentalmente asimtricas.
Una tcnica buena para caracterizar flujo de trfico de red debe clasificar aplicaciones
que soportan una de los tipos de flujo conocidos:
Metodologa Top Down
Marcos Huerta S. 35
Flujo de trfico de terminal/host.
Flujo de trfico de cliente/servidor.
Flujo de trfico Punto a Punto.
Flujo de trfico de servidor/servidor.
Flujo de trfico de clculo distribuido.
En su libro Anlisis de Red, Arquitectura, y Diseo, Segunda Edicin, James D.
McCabe hace un trabajo excelente de caracterizacin de los distintos modelos de flujo.
Flujo de Trfico de Terminal/host El trfico de terminal/host es por lo general asimtrico. El terminal enva unos caracteres
y el host enva muchos caracteres. El Telnet es un ejemplo de una aplicacin que
genera el trfico de terminal/host. Por defecto detrs de Telnet consiste en que el
terminal enva un simple paquete cada vez que el usuario escribe un carcter. El host
devuelve caracteres mltiples, segn lo que el usuario escribi. Como una ilustracin,
considere el principio de una sesin 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 Contrasea Requerida).
Flujo de Trfico de Cliente/Servidor
El trfico de cliente/servidor es el mejor tipo de flujo conocido y el ms 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 confan en servidores para el acceso a recursos, como
almacenaje, perifricos, software de aplicacin, y poder de procesamiento.
Los clientes envan 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
asimtrico. Las peticiones del cliente son tpicamente pequeos paquetes, excepto
cuando escribe datos al servidor, en cuyo caso ellos son ms grandes. Las respuestas
del servidor son de un rango de 64 bytes a 1500 bytes o ms, dependiendo del tamao
maximo del paquete.
En un ambiente TCP/IP, muchas aplicaciones son puestas en prctica 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 das, el Protocolo de Transferencia de Hipertexto (HTTP) es probablemente el
protocolo de cliente/servidor el ms extensamente usado. Los clientes usan una
Metodologa Top Down
Marcos Huerta S. 36
aplicacin de navegador de web, como Netscape, para poder conectarse con el servidor
web. El flujo es bidireccional y asimtrico. Cada sesin a menudo dura slo unos
segundos porque los usuarios tienden a saltar de un sitio Web al otro.
Flujo de Trfico Punto a Punto Con el flujo trfico punto a punto, el flujo es por lo general bidireccional y simtrico. Las
entidades que se comunican transmiten cantidades aproximadamente iguales de la
informacin. No hay ninguna jerarqua.
Cada dispositivo es considerado tan importante el uno como el otro, y ningn dispositivo
tiene considerablemente ms datos que el otro dispositivo. En pequeos 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 ningn 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 acta tanto como cliente y como servidor. Hay muchos flujos en ambas
direcciones.
Recientemente las aplicaciones punto a punto para descargar msica, videos, y
software han ganado la popularidad. Cada usuario publica la msica u otro material y
permite que otros usuarios en el Internet descarguen los datos. Este es considerado
trfico punto a punto porque cada usuario acta tanto como distribuidor y consumidor de
datos. El flujo de trfico es bidireccional y simtrico. La mayor parte de empresas y
muchas redes de universidad rechazan este tipo de trfico punto a punto por dos
motivos. Primero, esto puede causar una cantidad excesiva del trfico, y, segundo, el
material publicado es a menudo copyright por alguien adems de la persona que lo
publica.
Un otro ejemplo de aplicacin punto a punto es una reunin de negocios entre la gente
de una empresa en sitios remotos usando equipos de videoconferencia. En una reunin,
cada asistente puede comunicar tantos datos como son necesarios en cualquier
momento. Todos los sitios tienen las mismas exigencias QoS. Una reunin es diferente
para cada situacin donde la videoconferencia es usada para diseminar la informacin.
Con la diseminacin de informacin, como una clase de formacin 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 diseminacin de informacin es
por lo general puesta en prctica usando un modelo de cliente/servidor.
Metodologa Top Down
Marcos Huerta S. 37
Flujo de Trfico de Servidor/Servidor El trfico 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 tambin
hacer cumplir polticas de seguridad y actualizar datos de direccin de red.
Con el trfico de red de servidor/servidor, el flujo es generalmente bidireccional. La
simetra del flujo depende de la aplicacin. Con la mayor parte de aplicaciones de
servidor/servidor, el flujo es simtrico, pero en algunos casos esto es heredado de
servidores, con algunos servidores que envan y y almacenan ms datos que otros.
Flujo de Trfico de Clculo Distribuido
La informtica distribuida se refiere a aplicaciones que requieren mltiples nodos que
trabajan y realizan clculos 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 mltiples computadoras traten datos y dirijan algoritmos
simultneamente. Los efectos especiales para pelculas a menudo son desarrollados y
calculados en un ambiente distribuido. La informtica distribuida tambin es usada en la
industria de semiconductor para calcular las necesidades extremas del diseo y
verificacin de un microchip, y en la industria de defensa para proporcionar ingeniera y
simulaciones militares.
Con algunas aplicaciones de clculo distribuidas, el manejador de tarea dice a los nodos
de clculo que hacer en una base infrecuente, causando poco flujo de trfico. Con otras
aplicaciones, hay comunicacin frecuente entre el manejador de tarea y los nodos de
clculo.
La Documentacin de Flujo de Trfico para Aplicaciones Nuevas y Existentes de la Red Para documentar el flujo de trfico para nuevo (y existentes) de aplicaciones de red,
caracterice el tipo de flujo para cada aplicacin 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:
Metodologa Top Down
Marcos Huerta S. 38
Tabla Nro. 07 Flujo de Trfico para Aplicaciones Nuevas y Existentes
Caracterizacin de Carga de Trfico Para seleccionar topologas apropiadas y tecnologas para encontrar los objetivos de un
cliente, es importante caracterizar la carga de trfico con el flujo de trfico. La
caracterizacin de la carga de trfico puede ayudarle a disear redes con la capacidad
de uso local suficiente y flujos de redes.
A causa de muchos factores implicados en la caracterizacin del trfico de red, las
estimaciones de carga de trfico con poca probabilidad sern precisas. El objetivo es
evitar simplemente un diseo que tiene cualquier cuello de botella crtico. Para evitar
cuellos de botella, usted puede investigar modelos de uso de aplicacin, tiempos
ociosos entre paquetes y sesiones, tamaos de paquetes, y otros patrones de trfico
behaviorsticos para protocolos de sistema y aplicacin.
Otro acercamiento a la evitacin de cuellos de botella debe lanzar simplemente
cantidades grandes de ancho de banda en el problema. Una interpretacin estricta de
principios de anlisis de sistemas no aprobara tal acercamiento, pero el ancho de
banda es barato estos das. 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 tambin pueden
permitirse a usar Gigabit Ethernet en switch a switch y switch a servidor. El ancho de
banda WAN es todava 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 Clculo de Carga de Trfico Terica La carga de trfico (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 diseos de red es que la capacidad de red debera ser ms que
Metodologa Top Down
Marcos Huerta S. 39
adecuada de manejar la carga de trfico. El desafo debe determinar si la capacidad
propuesta para un nuevo diseo de red es suficiente para manejar la carga potencial.
En su libro Redes de rea Locales y Metropolitanas, Guillermo Stallings proporciona
algunos clculos atrs el-desarrollo para la carga de trfico calculadora. El Stallings
indica que usted puede hacer un clculo elemental basado simplemente en el nmero
de la transmisin de estaciones, como rpidamente cada estacin genera mensajes, y el
tamao de mensajes. Por ejemplo, para una red con una capacidad propuesta de 1
Mbps, si 1000 estaciones envan paquetes de 1000 bits cada segundo, entonces la
carga ofrecida iguala la capacidad. Aunque Stallings se refiriera a la capacidad de un
LAN, capacidad podra 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, slo unos parmetros son
necesarios:
El nmero de estaciones.
El tiempo medio que una estacin es ociosa entre el envo de paquetes.
El tiempo requerido transmitir un mensaje una vez el acceso medio es ganado.
Estudiando tiempos ociosos y tamao de los paquetes con un analizador de protocolo, y
estimando el nmero de estaciones, usted puede determinar si la capacidad propuesta
es suficiente.
Si usted investiga tipos de flujo de trfico, como hablado antes en este captulo, usted
puede desarrollar estimaciones ms 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 aplicacin particular tienen
calidades similares que generan carga. Las asunciones pueden ser hechas sobre
tamao de paquete y tiempo ocioso para una aplicacin despus de que usted ha
clasificado el tipo de flujo y ha identificado los protocolos usado por la aplicacin.
Para una aplicacin de cliente/servidor, el tiempo ocioso para el servidor depende del
nmero de clientes que usan al servidor, y la arquitectura y las caractersticas de
interpretacin del servidor (velocidad de acceso de disco, velocidad de acceso de RAM,
caching mecanismos, etctera).
Estudiando el trfico de red de servidores con un analizador de protocolo, usted puede
estimar un tiempo ocioso medio.
Metodologa Top Down
Marcos Huerta S. 40
El tiempo ocioso en el lado de cliente depende en parte de la accin de usuario, el que
significa que es imposible predecir exactamente el tiempo ocioso. Sin embargo, usted
puede hacer estimaciones del tiempo ocioso estudiando el trfico 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.
Despus de que usted ha identificado la carga de trfico aproximada para un flujo de
aplicacin, usted puede estimar la carga total para una aplicacin multiplicando la carga
para el flujo por el nmero de dispositivos que usan la aplicacin. La investigacin que
usted hace en el tamao de comunidades de usuario y el nmero (de servidores) de
almacen de datos puede ayudarle a calcular una exigencia del ancho de banda
agregada aproximada para cada aplicacin.
La documentacin de la posicin de comunidades de usuario y almacenes de datos, en
las cuales usted hizo el formulario, puede ayudarle a entender la cantidad de trfico que
fluir de un segmento al otro. Este puede ayudar en la seleccin de tecnologas de
columna vertebral y dispositivos de funcionamiento entre redes.
Estimando la carga de trfico, adems de la investigacin de tiempos ociosos entre
paquetes, tamaos de paquetes, y comportamiento de flujo, usted tambin debera
investigar modelos de uso de aplicacin y exigencias QoS. Algunas aplicaciones son
usadas con poca frecuencia, pero requieren una cantidad grande del ancho de banda
cuando ellos son usados.
Documentacin de Patrones de uso de Aplicacin El primer paso en la documentacin de modelos de uso de aplicacin debe identificar
comunidades de usuario, el nmero de usuarios en las comunidades, y las aplicaciones
que emplean los usuarios. Este paso, que fue cubierto ya antes en esta seccin, puede
ayudarle a identificar el nmero total de usuarios para cada aplicacin.
Adems de la identificacin del nmero total de usuarios para cada aplicacin, usted
tambin debera documentar la informacin siguiente:
La frecuencia de sesiones de aplicacin (el nmero de sesiones por da, semana,
mes o independientemente del perodo de tiempo es apropiado).
La longitud de una sesin de aplicacin media.
El nmero de usuarios simultneo de una aplicacin.
Armado con la informacin en la frecuencia y la longitud de sesiones, y el nmero de
sesiones simultneas, usted puede predecir ms exactamente la exigencia de ancho de
Metodologa Top Down
Marcos Huerta S. 41
banda agregada para todos los usuarios de una aplicacin. Si no es prctico investigar
estos detalles, usted puede hacer algunas conclusiones:
Usted puede asumir que el nmero de usuarios de una aplicacin es igual al nmero
de usuarios simultneos.
Usted puede asumir que todas las aplicaciones son usadas todo el tiempo de modo
que su clculo de ancho de banda sea un caso pico de estimacin (mxima).
Usted puede asumir que cada usuario abre slo una sesin y que una sesin dura
todo el da hasta que el usuario cierre la aplicacin al final de da.
Refinando Estimaciones de Carga de Trfico causada por Aplicaciones
Para refinar la estimacin de requerimientos de aplicacin ancho de banda, usted tiene
que investigar el tamao de objetos de datos enviados por aplicaciones, la sobrecarga
causada por capas de protocolo, y cualquier carga adicional causada por la inicializacin
de aplicacin. (Algunas aplicaciones envan mucho ms trfico durante la inicializacin
que durante la operacin estable.)
Como las aplicaciones y los usuarios varan extensamente en el comportamiento, es
difcil estimar exactamente el tamao medio de objetos de datos que los usuarios
transfieren el uno al otro y a servidores. (La respuesta de ingeniera verdadera a la
mayor parte de preguntas relacionadas para conectar a la red trfico es "esto depende.")
el cuadro siguiente proporciona algunas estimaciones para tamaos de objeto que
usted puede usar haciendo clculos atrs de la carga de trfico de aplicacin, pero
recordar que el cuadro proporcionado no toma el lugar de un anlisis cuidadoso del
comportamiento de aplicacin actual.
Tabla Nro. 08 Tamao Aproximado de Objetos de Transferencia de Aplicaciones a
travs de redes
Metodologa Top Down
Marcos Huerta S. 42
La Estimacin de Sobrecarga de Trfico para Varios Protocolos La seccin anterior habl de la caracterizacin de la carga de trfico de aplicacin
mirando el tamao de objetos de datos que las aplicaciones transfieren a travs de
redes. Para caracterizar completamente el comportamiento de aplicacin, usted debera
investigar qu protocolos usa una aplicacin. Una vez que usted sabe los protocolos,
usted puede calcular la carga de trfico ms exactamente aadiendo el tamao de
cabecera de protocolo al tamao de objetos de datos.
Tabla Nro. 09 de Sobrecarga de Trfico para varios Protocolos
La Estimacin de Carga de Trfico Causada por Inicializacin de Sesin y
Estacin de Trabajo Segn las aplicaciones y protocolos que usa una estacin de trabajo, la inicializacin de
estacin de trabajo puede causar una carga en redes debido al nmero de paquetes y,
en algunos casos, el nmero 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 rpidas y baratas, que har de modo que el procesamiento transmitido no sea
una preocupacin.
La Estimacin de Carga de Trfico Causada por Protocolos de Enrutamiento En este punto en el proceso de diseo de red, usted no podra haber seleccionado
protocolos de encaminamiento para el nuevo diseo de red, pero usted debera haber
identificado protocolos de encaminamiento que corren en la red existente. Ayudarle a
caracterizar trfico de red causado por protocolos de enrutamiento, Tabla le mostrara la
Metodologa Top Down
Marcos Huerta S. 43
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 enva 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 nmero de rutas por paquete, en redes grandes,
un router de trfico enva paquetes mltiples para enviar la tabla entera.
Los nuevos protocolos de encaminamiento, como OSPF y EIGRP, usan ancho de banda
muy pequea. En caso de OSPF, su preocupacin principal debera ser la cantidad de
ancho de banda consumida por los paquetes de sincronizacin de base de datos que los
routers de trfico envan cada 30 minutos. Subdividiendo una red de OSPF en reas y
usando la ruta sumarizada, este trfico puede ser minimizado. Otro trfico de
sincronizacin de base de datos, es el nico trfico que OSPF enva despus de la
inicializacin es pequeo paquete Hello cada 10 segundos.
El EIGRP tambin enva paquetes Hello, pero con ms frecuencia que OSPF (cada 5
segundos). Por otra parte, EIGRP no enva ninguna actualizacin de ruta peridica o
paquetes de sincronizacin de base de datos. Esto slo enva actualizaciones de ruta
cuando hay cambios en la topologa.
Caracterizacin del Comportamiento del Trfico Seleccionar una apropiada solucin de diseo de red, usted tiene que entender el
protocolo y el comportamiento de las aplicaciones adems de flujos de trfico y carga.
Por ejemplo, para seleccionar topologas apropiada de LAN, usted tiene que investigar
el nivel del trfico de broadcast en la LAN. Para aprovisionar la capacidad adecuada
para LAN y WAN, usted tiene que chequear la utilizacin extra de ancho de banda
causada por protocolos ineficientes y tamaos de paquetes no ptimos o retransmisin
de temporizadores.
Metodologa Top Down
Marcos Huerta S. 44
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 direccin 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 trfico 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 trfico de broadcast o multicast. Todos los dispositivos en un lado de
un router son considerados la parte de un solo dominio de bradcast.
Adems de la inclusin de routers en el diseo de una red disminuira el transporte de
broadcast, usted tambin puede limitar el tamao de un dominio de broadcast poniendo
en prctica LAN virtuales (VLANs). Tecnologa de VLAN, que en la seccin, "El diseo
de una Topologa de Red," habla ms 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 trfico 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 trfico de broadcast en su diseo
propuesto y limite el nmero de estaciones en un simple dominio de broadcast. El
trmino radiacin 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
radiacin de broadcast puede degradar la performance en estaciones de red.
La tarjeta de interfaz de red (NIC) con una estacin de red pasa broadcast y multicast
relevantes a la CPU de la estacin. 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 ms 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 ms del 20 por ciento del trfico de
red es broadcast o multicast, la red tiene que ser segmentada usando routers o VLANs.
Otra causa posible del pesado trfico de broadcast es la tormenta de broadcast causada
por intermitencias en la red o estaciones de red cadas. Por ejemplo, una mscara de
Metodologa Top Down
Marcos Huerta S. 45
subred de mal asignada puede hacer que una estacin enve paquetes de ARP
innecesariamente porque la estacin no se distingue correctamente entre estacin y
direcciones de broadcast, hacindolo enviar ARPs para direcciones de broadcast.
En general, sin embargo, el trfico de broadcast es necesario e inevitable. El
encaminamiento y la conmutacin de protocolos usan broadcast y multicast para
compartir la informacin sobre la topologa de la red. Los servidores envan 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 diseamos una topologa de red, se cubrir en secciones mas adelante mas
detalladamente, mostramos una tabla de recomendaciones para limitar el nmero de
estaciones en un dominio de broadcast solo basada en el protocolo (s) de escritorio en
uso.
Tabla Nro. 11 Tamao Mximo en un Dominio de Broadcast
Eficacia de Red
La caracterizacin del comportamiento de trfico 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 tamao del paquete, la interaccin de protocolos usados por una
aplicacin, windowing y control de flujo, y mecanismos de recuperacin de error.
Tamao del Paquete Usando un tamao de paquete que es el mximo 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 debera usar la unidad mxima de
transmisin ms grande posible (MTU). Segn las pilas de protocolo que su cliente
Metodologa Top Down
Marcos Huerta S. 46
usar en el nuevo diseo de red, el MTU puede ser configurado para algunas
aplicaciones.
En un ambiente IP, usted debera evitar aumentar el MTU ms de lo soportado, evitar la
fragmentacin y reensamblacin 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 dinmicamente y usar el tamao ms
grande del paquete que cruzar la red sin requerir la fragmentacin. El descubrimiento
de MTU generalmente trabaja, pero hay algunos problemas con ello como mencionamos
en el "Anlisis de Eficacia de Red".
Interaccin de Protocolo
La ineficiencia en redes no es causada slo por pequeos tamaos de paquetes. La
ineficiencia tambin es causada por la interaccin de protocolos y la no correcta
configuracin de temporizadores de reconocimiento y otros parmetros.
Windowing y Control de Flujo
Para entender realmente el trfico de red, usted tiene que entender el control de flujo y
windowing. Un dispositivo TCP/IP, por ejemplo, enva segmentos (paquetes) de datos
en secuencia rpida, sin esperar un reconocimiento, hasta que su envo de ventana ha
sido agotado. Una estacin enva 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 rpido 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 ningn control de flujo o el control de flujo es manejado en la sesin o capa
de aplicacin. Mostramos una lista para determinar qu protocolos estn basados
en TCP y qu protocolos estn 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.
Metodologa Top Down
Marcos Huerta S. 47
Protocolo de Transferencia de Hipertexto (HTTP): Puerto de TCP 80.
Protocolo de Direccin 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 Recuperacin de error Los mecanismos de recuperacin de error mal diseados pueden gastar el ancho de
banda. Por ejemplo, si un protocolo retransmite de nuevo datos muy rpidamente sin
esperar un periodo de tiempo para recibir un reconocimiento, este puede causar la
degradacin del performance para el resto de la red debido al ancho de banda usada.
Los protocolos de baja conexin por lo general no ponen en prctica la recuperacin de
error. Mayormente en la capa de enlace de datos y los protocolos de capa de red son de
baja conexin. Algunos protocolos de capa de transporte, como UDP, son de baja
conexin.
Los mecanismos de recuperacin de error para protocolos orientados por conexin
varan. TCP implementa un algoritmo de nuevo de retransmisin 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 tambin ponen en prctica 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 nmero de ACK es uno ms que
el nmero del ltimo byte que fue recibido antes de la prdida, aun si ms segmentos
llegaran despus de la prdida. No hay ningn camino para el receptor para recibir
algn 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 opcin 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 slo los
segmentos ausentes. RFC 2018 define una opcin TCP para rellenar los nmeros de
Metodologa Top Down
Marcos Huerta S. 48
secuencia recibida para bloques y otra opcin TCP para informar al recipiente durante el
apretn de manos de tres caminos que el host soporta SACK.
Caracterizando los Requerimientos de Calidad de Servicio
El anlisis de los requerimientos de trfico de red no es completamente tan simple como
identificando flujos, midiendo la carga para flujos, y caracterizando el comportamiento de
trfico como de broadcast y de comportamiento error. Usted tambin tiene que
caracterizar los requerimientos QoS para aplicaciones.
Slo conociendo los requerimientos de carga (ancho de banda) para una aplicacin no
es suficiente. Usted tambin 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 vdeo, son
dadas intiles si un cierto nivel del ancho de banda no est disponible. Adems, si usted
tiene una mezcla de aplicaciones flexibles e inflexibles en una red, usted tiene que
determinar si es prctico tomar prestada el ancho de banda de la aplicacin flexible para
guardar el funcionamiento de aplicacin inflexible.
La voz es tambin inflexible en cuanto a la tardanza. La voz es tambin sensible a la
prdida de paquete, que resulta en recorte de peridico de voz y se salta. Sin la
configuracin apropiada en toda la red de QoS, la prdida puede ocurrir debido a enlaces congestionados y un pobre buffer de paquetes y manejo de direccin de cola
en los routers.
Siguiendo esta seccin siguiente que analiza los requerimientos de QoS usando ATM e
Internet la tcnica Engineering Task Force (IETF). El objetivo de estas secciones es
introducirle en la terminologa del ATM y IETF que los ingenieros usan para clasificar el
trfico y especificar los requerimientos de QoS por clases de trfico. Aunque el material
sea muy altamente tcnico y detallado, esto debera darle alguna idea fundamental
sobre la clasificacin de los tipos de aplicaciones que jugarn una parte en su diseo de
red y estar preparado para futuros captulos que cubren estrategias de diseo y
optimizacin de redes que pueden encontrar las necesidades de varias aplicaciones.
Calidad de ATM de Especificaciones de Servicio En su documento "Especificacin del Manejo de Trafico la Versin 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 tecnologa del Modo de Transferencia Asincrnico (ATM),
la terminologa del Foro de ATM es todava provechosa porque esto identifica los
diferentes parmetros que las clases de aplicaciones deben especificar para solicitar un
Metodologa Top Down
Marcos Huerta S. 49
cierto tipo del servicio de red. Estos parmetros incluyen tardanza y variacin del
tamao de tardanza, prdida de datos, y picos de trfico mximo, sostenible, y mnimos.
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 categoras de servicio, cada uno de las cuales es descrito
ms detalladamente en esta seccin:
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 categora de servicio, el Foro de ATM especifica un juego de parmetros para
describir tanto trfico presente en la red como el QoS requerido de la red. El Foro de
ATM tambin define mecanismos de control de trfico que la red puede usar para
encontrar objetivos QoS. La red puede implementar tales mecanismos de conexin de
control de admisin y asignacin de recurso diferentes para cada categora de servicio.
Las categoras de servicio son distinguidas al comienzo siendo tiempo real o tiempo no
real. El CBR y rt-VBR son categoras de servicio de tiempo real. Las aplicaciones de
tiempo real, como voz y aplicaciones de vdeo, requieren la variacin 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 variacin. El Nrt-VBR, UBR, ABR, y GFR son
categoras de servicio tiempo no real.
Categora 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 garanta 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 mximo (PCR) en cualquier momento y para
cualquier duracin y los compromisos QoS deberan pertenecer. El CBR es usado por
aplicaciones que necesitan la capacidad de solicitar que una cantidad esttica del ancho
de banda estuviera continuamente disponible durante una conexin de por vida. La
cantidad de ancho de banda que una conexin requiere es especificada por el valor de
PCR.
Metodologa Top Down
Marcos Huerta S. 50
El servicio de CBR intenta soportar aplicaciones de tiempo real que requieren la
variacin de tardanza fuertemente obligada (por ejemplo, la voz, el vdeo, y la emulacin
de circuitos), pero no es restringido a estas aplicaciones. La fuente puede emitir celdas
debajo de PCR negociado o ser silenciosa durante perodos del tiempo. Se asume que
celdas que son retrasadas ms all del valor especificado por la tardanza de
transferencia de parmetros de celdas mxima (maxCTD) son del valor
considerablemente reducido a la aplicacin.
Categora de Servicio de Velocidad Binaria Variable Tiempo no real La categora de servicio nrt-VBR es requerida para aplicaciones de tiempo no real que
tienen caractersticas de trfico bursty. El servicio es caracterizado en trminos de PCR,
SCR, y MBS. Para celdas que son transferidas dentro del contrato de trfico, la
aplicacin espera una proporcin baja de prdida 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 recibira una descarga en la
red. El control de admisin 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 rpidamente 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 aplicacin 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 bsico del medio de transmisin.)
La tardanza de trnsito experimentada por un porcentaje muy alto de los paquetes
entregados no exceder el mnimo transmitido en la tardanza experimentada por
cualquier paquete con xito entregado. (Esta tardanza de trnsito mnima incluye la
tardanza de velocidad de luz ms el tiempo de procesamiento fijo en routers y otros
dispositivos de comunicaciones a lo largo del camino.)
Metodologa Top Down
Marcos Huerta S. 51
El servicio de control-carga no acepta o hace el uso de valores objetivo especficos para
parmetros como tardanza o prdida. En cambio, la aceptacin de una peticin 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) trfico en condiciones ligeramente cargadas.
Un nodo de red que acepta una peticin del servicio de control-carga debe usar
funciones de control de admisin para asegurar que los recursos adecuados estn
disponibles para manejar el nivel solicitado del trfico, 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 caractersticas garantiza tanto la tardanza como ancho de
banda. El servicio garantizado proporciona la firma (matemticamente 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
transmisin. (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 llegarn dentro del plazo de entrega
garantizado y no sern descartado debidos a desbordamientos, condicin de que el
trfico del flujo es conformado por TSpec. Una serie de nodos de red que ponen en
prctica la implementacin 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 prdida
de cola (asumiendo que no falla ningn componentes de red o cambios de la
encaminamiento durante la vida del flujo).
El servicio garantizado es requerido para aplicaciones que necesitan una garanta que
un paquete no llegar ms tarde que un cierto tiempo despus de que fue transmitido
por su fuente. Por ejemplo, algunas aplicaciones de repeticin de audio y de vdeo son
intolerantes de un paquete que llega despus de su tiempo de repeticin esperado. Las
aplicaciones que tienen exigencias de tiempo real tambin 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 terica
mxima de solo un hilo de fibra). El tamao del paquete puede extenderse de 1 byte a
250 GB. El rango de valores es intencionadamente grande para tener en cuenta futuras
Metodologa Top Down
Marcos Huerta S. 52
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 tamao. Una
aplicacin por lo general puede estimar exactamente la tardanza esperada que hace
cola que el servicio garantizado proporcionar. Si la tardanza es ms grande que
esperado, la aplicacin puede modificar su paquete simblico para conseguir una
tardanza inferior.
Como un diseador de red, no le visitarn generalmente para estimar ratios de paquete
simblico y tamaos. Por otra parte, usted debera reconocer qu necesidad de
aplicaciones garantizada el servicio y tienen alguna idea de su comportamiento de falta
y si una reconfiguracin del comportamiento de falta es posible. Si una aplicacin puede
solicitar el ancho de banda de terabytes por segundo, usted tiene que saber este debido
al efecto negativo que esto podra tener en otras aplicaciones.
Documentacin Requerimientos de QoS Usted debera trabajar con su cliente para clasificar cada aplicacin de red en una
categora de servicio. Una vez que usted ha clasificado la aplicacin, usted debera
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 trminos rellenando
"la columna" de Requerimientos de QoS. Si su cliente planea usar el ATM, usted puede
usar la terminologa del Foro de ATM para categoras de servicio. Incluso si su cliente no
planea usar el ATM o IETF QoS, usted todava puede usar el Foro de ATM o la
terminologa de grupo de funcionamiento de Servicios Integrada. Otra alternativa debe
usar simplemente los trminos inflexible y flexible. Inflexible es una palabra genrica
para describir cualquier aplicacin que tiene exigencias especficas para ancho de
banda constante, tardanza, variacin de tardanza, exactitud, y rendimiento. Flexible, por
otra parte, es un trmino genrico 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 debera hacer ms 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
Metodologa Top Down
Marcos Huerta S. 53
puede haber un requerimiento GoS que debera ser especificada. Para la corriente de
voz, la clasificacin QoS debera ser puesta en una lista usando el trmino de ATM o el
trmino de IETF servicio garantizado.
Resumen de Identificando objetivos y necesidades del cliente
En este punto en el proceso de diseo de red, usted ha identificado las aplicaciones de
red de un cliente y los requerimientos tcnicas para un diseo de red que puede apoyar
las aplicaciones.
Este resume, "Identificando las Necesidades de Su Cliente y Objetivos." La Fase de
anlisis de requerimientos es la fase ms importante en el diseo red de la metodologa
top down. La ganancia de un entendimiento slido de los requerimientos de su cliente le
ayuda a seleccionar tecnologas que encuentran los criterios de un cliente para el xito.
Usted debera ser capaz ahora de analizar los objetivos comerciales y tcnicos de un
cliente y estar listo a comenzar a desarrollar un diseo de red lgico y fsico. "Diseo de
Red Lgico," que disean una topologa de red lgica, desarrollando el direccionamiento
de capa de red y nombramiento del modelo, seleccin de switches y de protocolos de
enrutamiento, y planificacin de seguridad de red y estrategias de direccin.
Fase II: Diseo de una Red Lgica
Parte 5. Diseo de una topologa de red
En este captulo, usted aprender tcnicas para desarrollar una topologa de red. A
topologa es un mapa de la red que indican segmentos de red, puntos de interconexin,
y comunidades de usuario. Adems los sitios geogrficos puedan aparecer en el mapa,
el objetivo del mapa es mostrar la geometra de la red, no la geografa fsica o
implementacin tcnica. El mapa es una vista panormica del alto nivel de la red,
anloga a un dibujo arquitectnico que muestra la posicin y el tamao de cuartos para
un edificio, pero no los materiales de construccin para fabricar los cuartos.
El diseo de una topologa de red es el primer paso en la fase de diseo lgica de la
metodologa de diseo de red Top Down. Para encontrar los objetivos de un cliente para
escalabilidad y adaptabilidad, es importante para el arquitecto una topologa lgica antes
de seleccionar productos fsicos o tecnologas. Durante la fase de diseo de topologa,
usted identifica redes y puntos de interconexin, el tamao y alcance de redes, y los
tipos de dispositivos de funcionamiento entre redes que sern requeridos, pero no los
dispositivos actuales.
Metodologa Top Down
Marcos Huerta S. 54
Este captulo proporciona tips tanto para diseo de redes WAN de campus como
empresariales, y se concentra en el diseo de red jerrquico, que es una tcnica para
disear campus escalable y redes WAN usando un modelo modular por capas. Adems
del diseo de red jerrquico, en esta seccin tambin cubre topologas de diseo de red
redundantes y topologas con objetivos de seguridad. (La seguridad es cubierta ms
detalladamente en la Parte 8, "Desarrollo de la Seguridad de Red.") Este captulo
tambin cubre el Modelo de Red Empresarial Compuesta, que es la parte de la
Arquitectura Segura Empresarial de Cisco (SAFE).
Diseo de Red Jerrquica
Para encontrar los objetivos comerciales y tcnicos de un cliente para un diseo de red
corporativo, usted podra tener que recomendar que una topologa de red que consiste
en muchos interrelacionara componentes. Esta tarea es hecha ms fcil si usted puede
"dividir y triunfar" el trabajo y desarrollar el diseo en capas.
Cada capa puede ser enfocada en funciones especficas, permitindole elegir los
correctos sistemas y caracteristicas para la capa. Por ejemplo, en La figura 11, routers
WAN de alto velocidad puede llevar el trfico a travs 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. Topologa Jerrquica
Una topologa jerrquica tpica esta dividida por tre
