metodologia de diseÑo de red top down

Practicas Pre Profesionales II UPAO

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,


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 clienteParte 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.


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.

DisponibilidadLa 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,


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.

PerformanceCuando 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.

SeguridadEl 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.


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.


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:

o Conexiones WAN entre países y ciudades.

o Edificios y pisos, y posibilidades cuartos y casetas.

o Conexiones WAN y LAN entre edificios y entre campos.

o Una indicación de la capa de datos (WAN, LANS).

o El Número de servicios proveedor de WANS.

o La localización de las líneas y interruptores, aunque no es necesario en el eje y centro.

o La localización y alcance de redes virtuales (VPN’s), que conecta los servicios de los

proveedor WAN.

o La localización de las principales estructuras.

o La localización de las mayores estaciones de ejecución de la red.

o La localización y alcance de algunas LAN’s Virtuales (VLAN’s).

o La topología de algunos sistemas de seguridad Firewall.

o La localización de algunos sistemas de dial- in y dial out.

o Algunas indicaciones de donde residen algunas estaciones de trabajo, aunque no

necesariamente la localización explicita de cada estación de trabajo.


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 MedioEs 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 fiberMulti –mode fiber

Shielded twisted pair (STP)

UTP categoría 5

Cable coaxial

Microondas

Radiofrecuencia.

Láser

Infrarrojo


Supervisando la Arquitectura Ambiental y RestriccionesCuando 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 existenteEstudiar 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 RedPoder 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


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 RedPara 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


Analizando la Utilización de la RedUtilizació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 ProtocoloEl 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).


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

Análisis de la Exactitud de RedUsted 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


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 RedLa 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


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


El Chequeo del estado de los Routers principales, Switches, y FirewallsEl 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


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 AlmacenamientoPara 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.


Tabla Nro. 05 Formulario de Almacenamiento de Datos

Documentar el Flujo de Tráfico en la Red ExistenteLa 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.


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 RedComo 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:


· 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/ServidorEl 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


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 PuntoCon 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.


Flujo de Tráfico de Servidor/ServidorEl 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 DistribuidoLa 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:


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

Caracterización de Carga de TráficoPara 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


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.


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ónEl 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


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 AplicacionesPara 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 através de redes


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


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.


Comportamiento de Broadcast/MulticastUn 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


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

Practicas Pre Profesionales II UPAOusará 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.


· 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 errorLos 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


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 ServicioEl 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


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.


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 CargaEl 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.)


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 GarantizadoEl 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


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 QoSUsted 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


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 clienteEn 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.

metodologia de diseÑo de red top down

Documents