Successfully reported this slideshow.

Metodologia topdownespañol

8,292 views

Published on

Metodologia topdownespañol

  1. 1. Metodología Top Down METODOLOGIA DE DISEÑO DE RED TOP DOWN Historia de la Metodología TOP DOWN El diseño de red top-down es una disciplina que creció del éxito de la programación de software estructurado y el análisis de sistemas estructurados. El objetivo principal del análisis de sistemas estructurado es representar más exacto las necesidades de los usuarios, que a menudo son lamentablemente ignoradas. Otro objetivo es hacer el proyecto manejable dividiéndolo en módulos que pueden ser más fácil de mantener y cambiar. El diseño de red top-down es una metodología para diseñar redes que comienza en las capas superiores del modelo de referencia de OSI antes de mover a las capas inferiores. Esto se concentra en aplicaciones, sesiones, y transporte de datos antes de la selección de routers, switches, y medios que funcionan en las capas inferiores. El proceso de diseño de red top-down incluye exploración divisional y estructuras de grupo para encontrar la gente para quien la red proporcionará servicios y de quien usted debería conseguir la información valiosa para hacer que el diseño tenga éxito. El diseño de red top-down es también iterativo. Para evitar ser atascado en detalles demasiado rápido, es importante conseguir primero una vista total de los requerimientos de un cliente. Más tarde, más detalle puede ser juntado en comportamiento de protocolo, exigencias de escalabilidad, preferencias de tecnología, etcétera. El diseño de red top-down reconoce que el modelo lógico y el diseño físico pueden cambiarse cuando más información es juntada. Como la metodología top-down es iterativa, un acercamiento top-down deja a un diseñador de red ponerse "en un cuadro grande" primero y luego moverse en espiral hacia abajo segun exigencias técnicas detalladas y especificaciones. Los Sistemas de Cisco recomiendan un acercamiento modular con su modelo jerárquico de tres capas. Este modelo divide redes en nucleo, distribución, y capas de acceso. La Arquitectura Segura de Cisco para Empresas (SAFE) y compuesto de un Modelo de Red de Empresa, son también aproximaciones modulares para el diseño de la red. Con un acercamiento estructurado diseñamos la red, cada módulo es diseñado por separado, aún con relación a otros módulos. Todos los módulos son diseñados usando un acercamiento top-down que se concentra en los requerimientos,Marcos Huerta S. 18
  2. 2. Metodología Top Down aplicaciones, y una estructura lógica antes de la selección de dispositivos físicos y productos que se implementara en el diseño.Fase I: Identificando objetivos y necesidades del cliente Parte 1. Análisis de los objetivos y limitaciones del negocio Los objetivos y limitaciones incluyen la capacidad de correr las aplicaciones de red que reune los objetivos comerciales corporativos, y la necesidad de trabajar dentro de restricciones comerciales, como paquete, personal limitado que esta conectado a una red, y márgenes de tiempo cortos. El comprender los objetivos comerciales y sus restricciones de sus clientes es un aspecto crítico del diseño de red. Armado con un análisis cuidadoso de los objetivos comerciales de su cliente, usted puede proponer un diseño de red que contara con la aprobación de su cliente. El entendimiento de la estructura corporativa también le ayudará a reconocer la jerarquía de dirección. Uno de sus primeros objetivos en las etapas tempranas del diseño de un proyecto de red debe determinar quiénes son los funcionarios con poder de decisión. ¿Quién tendrá las autoridades para aceptar o rechazar su propuesta de diseño de red? Además del análisis de objetivos comerciales y determinación de la necesidad de su cliente de apoyar aplicaciones nuevas y existentes, es importante analizar cualquier restricción comercial que afectará su diseño de red. Si usted tiene en mente cambios de estrategias comerciales y gestión de redes de empresa discutido en las secciones anteriores, se hace posible poner una lista de los objetivos comerciales en el diseño de alguna red típica: Ø Aumento de ingresos y ganancia. Ø Aumento de Cuota de mercado. Ø Expansión de nuevos mercados. Ø Aumente ventajas competitivas sobre compañías en el mismo mercado. Ø Reduzca gastos. Ø Aumente la productividad de empleado. Ø Acorte ciclos de desarrollo de producto. Ø Use la fabricación justo a tiempo. Ø Plan alrededor de escaseces componentes. Ø Ofrezca nuevos servicios de cliente. Ø Ofrezca el mejor soporte de cliente.Marcos Huerta S. 19
  3. 3. Metodología Top Down Ø Abra la red a componentes claves (perspectivas, inversionistas, clientes, socios de negocio, proveedores, y empleados). Ø Construya relaciones y accesibilidad de información a un nuevo nivel, como una base para un modelo organizacional de red. Ø Evite la interrupción comercial causada por problemas de seguridad de red. Ø Evite la interrupción comercial causada por desastres naturales y poco naturales. Ø Modernice tecnologías anticuadas. Ø Reduzca los gastos de telecomunicaciones y red , incluso elevado asociado con redes separadas para voz, datos, y vídeo Parte 2. Análisis de los objetivos y limitaciones técnicas En este parte trata de dar algunos alcances para analizar las metas técnicas de los clientes para implementar una nueva red o actualizar una existente. Conociendo las metas técnicas de nuestros clientes podremos recomendar nuevas tecnologías que al implementarlas cumplan con sus expectativas. Los típicos objetivos técnicos son adaptabilidad, disponibilidad, funcionalidad, seguridad, manejabilidad, utilidad, adaptabilidad, y factibilidad. Uno de los principales objetivos de este capitulo es poder conversar con sus clientes en términos que ambos puedan entender. Escalabilidad La escalabilidad se refiere de cuanto es capaz de dar soporte al crecimiento del diseño de la red. Uno de los principales objetivos para muchas empresas es que su red sea altamente escalable, especialmente las empresas grandes que normalmente tienen un crecimiento rápido tanto en usuarios, aplicaciones y conexiones de red. El diseño de red que usted propone a un cliente debería ser capaz de adaptarse a aumentos del uso de red y el alcance. Disponibilidad La disponibilidad se refiere a todo el tiempo que una red está disponible a usuarios y es a menudo una meta difícil de alcanzar para los que diseñan la red, ésta puede ser expresada en porcentajes por año, mes, semana, día u hora comparado con tiempo total del periodo. La palabra disponibilidad puede ser mal entendida por los usuarios para lo que se debe ser muy cuidadoso en explicar en que consiste la disponibilidad de la red para ello se puede usar la palabra fiabilidad que se refiere a varios factores, como la exactitud,Marcos Huerta S. 20
  4. 4. Metodología Top Down rangos de error, estabilidad, y la cantidad de tiempo entre fracasos lo que refleja la disponibilidad de la red. Disponibilidad también lo asocian con la redundancia que no es un objetivo para el diseño de red, mas bien es una solución, se refiere que se duplica los enlaces a la red para reducir tiempos lo que permite continuidad después de fallas o desastres. Disponibilidad esta asociada también con la resistencia que significa cuanto estrés puede manejar la red con rapidez, que la red pueda manejar los problemas incluyendo los de seguridad, brechas, desastres naturales y no naturales, errores humanos, fallas del hardware o software. Performance Cuando se analiza los requerimientos técnicos para el diseño de la red, se puede convencer a los clientes para aceptar la performance de la red, incluyendo rendimiento, exactitud, eficacia, tardanza, y tiempo de respuesta. Analizar el estado actual de la red puede ayudar a ver que cambios se podrían realizar para que mejore la performance de la red. Las metas de la performance de la red están bastante ligada con las metas de la escalabilidad. Seguridad El diseño de la seguridad es uno de los aspectos más importantes en el diseño de red empresarial. Al incrementar las amenazas tanto dentro como fuera de la red de la empresa se debe tener reglas y tecnologías de seguridad actualizadas e incorruptibles. Las metas más deseadas de muchas empresas es que los problemas de seguridad no afecten a la habilidad de conducir los negocios de la empresa, osea que si se presentara algún tipo de problema la empresa debe ser capaz de seguir con sus actividades normales. La primera tarea para el diseño de la seguridad es planificar. Lo que significa que debemos reconocer las partes más vulnerables de la red, analizando los riesgos y encontrando requerimientos. Como es el caso de la mayoría de las exigencias técnicas de diseño, alcanzando objetivos de seguridad significa hacer compensaciones. Las puestas en práctica de seguridad pueden aumentar el costo de despliegue y funcionamiento de la red, también puede afectar la productividad de usuarios, sobre todo si se dificulta el modo de trabajo para proteger recursos y datos. La Seguridad también puede afectar la redundancia del diseño de red por ejemplo si el tráfico pasa por dispositivos de cifrado.Marcos Huerta S. 21
  5. 5. Metodología Top Down Manejabilidad (Administración) Cada cliente tiene objetivos y una forma de administrar la red diferente. Algunos clientes tienen metas claras de cómo administrar la red y otras metas menos específicas. Si su cliente tiene proyectos definidos, debe asegurarse que se documenten, porque usted tendrá que referirse a los proyectos seleccionando el equipo. En algunos casos, el equipo tiene que ser excluido porque esto no soporta la administración de funciones que el cliente requiere. La administración de la red debe ser simplificada. Simplificarlos en paquetes de funciones de administración se entienden fácilmente y usados por administradores de red. Durante la reunión de inicial de exigencias técnicas para el diseño o actualización de una red, se puede usar la terminología ISO para simplificar la discusión de las metas de los administradores de red con sus clientes, de la siguiente manera: • Administración de funcionamiento. Analizar el tráfico y el comportamiento de aplicación para optimizar una red, quedar en acuerdos de nivel de servicio, y el plan para la extensión • Administración de defecto. Descubrir, aislar y corregir de problemas; reportando los problemas a usuarios finales y gerentes. • Administración de configuración. Control, funcionamiento, identificación, y recolectar datos de dispositivos de administración • Administración de Seguridad. Supervisión y pruebas de seguridad y política de protección, manteniendo y distribuyendo contraseñas y otra autenticación e información de autorización, llaves de cifrado directivas, y adhesión de revisión a política de seguridad. • Administración de la contabilidad. Contabilizar el uso de la red para asignar gastos para conectar una red a usuarios y/o plan para cambios de exigencias de capacidad Parte 3. Graficando la Red Existente Esto se basa en una ejecución en un mapa de una red y aprendiendo la localización de la mayoría de los dispositivos y segmentos en el trabajo de la red y identificando algunos métodos establecidos para el direccionamiento y nombramiento y también archivando, investigando los cables físicos, reservas que son muy importante en la característica de la infraestructura de la red. Ejecución de un Mapa de Red Para la mayoría de los diseñadores de red; la interconexión de dispositivos y segmentar de la red es un buen camino para comenzar la compresión del flujo circulatorio.Marcos Huerta S. 22
  6. 6. Metodología Top Down El objetivo es obtener un mapa ya implementado de la red, algunos diseños de los clientes pueden tener mapas para un nuevo y mejor diseño de la red. Herramientas para la Ejecución de un Mapa de Red Para ejecutar un mapa de la existencia de la red, deberíamos invertir en una buena herramienta de diagrama de red. Tales como: Ø Visio Corporations. Ø Visio Profesional. Ø Visio Profesional Ships. Algunas compañías ofrecen esquematizar automáticamente el descubrimiento de la red existente, usando el siguiente software: Ø Pinpoint Software’s ClickNet Professional. Ø NetSuite Development. Ø Net Suite Advanced Professional Design. Ø NetSuite Professional Audit (similar ClickNet). ¿Que debería Incluir en un Mapa de Red? Usando las herramientas mencionadas deberá desarrollar un mapa de red en la cual deberá contener lo siguiente: Ø Conexiones WAN entre países y ciudades. Ø Edificios y pisos, y posibilidades cuartos y casetas. Ø Conexiones WAN y LAN entre edificios y entre campos. Ø Una indicación de la capa de datos (WAN, LANS). Ø El Número de servicios proveedor de WANS. Ø La localización de las líneas y interruptores, aunque no es necesario en el eje y centro. Ø La localización y alcance de redes virtuales (VPN’s), que conecta los servicios de los proveedor WAN. Ø La localización de las principales estructuras. Ø La localización de las mayores estaciones de ejecución de la red. Ø La localización y alcance de algunas LAN’s Virtuales (VLAN’s). Ø La topología de algunos sistemas de seguridad Firewall. Ø La localización de algunos sistemas de dial- in y dial out. Ø Algunas indicaciones de donde residen algunas estaciones de trabajo, aunque no necesariamente la localización explicita de cada estación de trabajo.Marcos Huerta S. 23
  7. 7. Metodología Top Down Caracterizando el Direccionamiento y el Nombramiento de la Red La infraestructura lógica de la red envuelve documentar cualquier estrategia que su cliente tiene para el direccionamiento y nombramiento de la red. Cuando dibuje los detalles de los mapas de la red, deberá incluir los sites, routers, segmentos de la red y servicios. Usted tiene que investigar el direccionamiento de la capa de red que usa, el esquema de direccionamiento que usa su cliente puede influenciar en la habilidad de adaptar su nuevo diseño de red a los objetivos, aquí definirá el mejor método de direccionamiento que se pueda usar para su diseño de red. Entre los cuales tenemos: Ø Subnetting. Ø Variable Lenght Subnet Masking (VLSM). Ø Supernetting o Aggregations. Ø Summarization. Estos métodos se explicaran más adelante cuando se seleccione el protocolo y direccionamiento de red. Caracterizando el Cableado y el Medio Es importante comprender el cableado y la instalación eléctricos del diseño de la red con el objetivo de identificar posibles y potenciales problemas. Si es posible usted deberá documentar el tipo de cableado que usa, la distancia ya que esta información ayudara a determinar la Tecnología de la capa de enlace basado en las restricciones de distancia. Cuando el diseño del cableado esta en exploración, determine cuales son los equipos y los cables que están etiquetado en la red existente. Por ejemplo: la red de un edificio debería archivar las conexiones de un número de cable y el tipo de instalación que esta en uso en la red. Probablemente la instalación entre los edificios es unos de los sgtes: Ø Single –mode fiber Ø Multi –mode fiber Ø Shielded twisted pair (STP) Ø UTP categoría 5 Ø Cable coaxial Ø Microondas Ø Radiofrecuencia. Ø Láser Ø InfrarrojoMarcos Huerta S. 24
  8. 8. Metodología Top Down Supervisando la Arquitectura Ambiental y Restricciones Cuando esta investigando el cableado hay que poner mucha atención en los problemas ambientales con la posibilidad de que el cableado podría pasar muy cerca donde haya lugares propensos a inundarse, cerca de las carreteras donde el tráfico de los vehículos podría quebrar los cables, calefacciones, etc. Este seguro que no tenga ningún problema legal a la hora de tender un cableado, por ejemplo al cruzar un cableado por una calle donde tenga que romper pistas. Cuando construya preste atención a la arquitectura si este afecta la implementación de su diseño, este seguro que la arquitectura puede soportar el diseño tales como: Ø Aire acondicionado. Ø Calefacción. Ø Ventilación. Ø Protección de interferencias electromagnéticas. Ø Puertas que no estén cerradas, etc. Supervisando el buen Funcionamiento de la Red existente Estudiar el performance de una red existente te da una línea básica dimensional para poder medir y compara el performance del nuevo diseño de red propuesto el cual le ayudara a demostrar a su cliente cuan mejor es su diseño en performance una vez implementado. Si la red es muy grande para estudiar todos sus segmentos, preste mayor atención en la red de backbone antigua y las nuevas áreas que se conectan así como redes que se integran al backbone. Por ejemplo capturar la circulación la red con un analizador de protocolo como parte de tu análisis de la línea básica, podría identificar cuales de los protocolos están realmente trabajando en la red y no contar con la creencia de los clientes (ethereal). Analizando la Performance precisa de la Red Poder identificar la performance precisa de una red no es tarea fácil. Una de las tareas es seleccionar el tiempo para hacer estos análisis para poder determinar el momento exacto para poder realizarlo y determinar los problemas que presenta la red durante los periodos altos de tráfico, etc. Los problemas de la red no son usualmente causados por los envíos de malas estructuras de tramas. En el caso token ring (La red Token-Ring es una implementación del standard IEEE 802.5, en el cual se distingue más por su método de transmitir laMarcos Huerta S. 25
  9. 9. Metodología Top Down información que por la forma en que se conectan las computadoras., el problema usualmente esta por estación y problema de cable, en el caso de ethernet, es un difícil precisar la causa del problema. Algunos clientes no reconocen el valor de estudiar las redes existentes antes del diseño y la implementación. Los clientes generalmente se avocan por un diseño rápido por lo cual puede hacer difícil poder dar marcha atrás y insistir en tiempo para desarrollar la performance precisa de la red existente. Un buen entendimiento de los objetivos técnicos y de negocio del cliente pueden ayudar a decidir que cantidad de tráfico deberá analizar en la red. Analizando la Disponibilidad de la Red Para documentar características de disponibilidad de la red existente, junte cualquier estadística que el cliente tiene durante el tiempo medio entre fallas (MTBF) y tiempo medio de reparación (MTTR) para las redes en conjunto así como segmentos de red principales. Compare estas estadísticas con la información en la que usted se ha juntado en MTBF y objetivos MTTR, ¿Espera el cliente que su nuevo diseño aumente MTBF y disminuya MTTR? ¿Son los objetivos del cliente consideración realista del estado corriente de la red? Diríjase a los ingenieros de red y técnicos sobre las causas de los períodos más recientes y más perjudiciales del tiempo de indisponibilidad. Interpretando como un investigador forense, trate de conseguir muchos lados a la historia. A veces los mitos se desarrollan sobre lo que causó una interrupción de red. (Usted puede conseguir por lo general una vista más exacta de causas de problema de ingenieros y técnicos que de usuarios y gerentes.) Puede usar esta Tabla Nro. 01 para documentar. Tabla Nro. 01 Caracterizar la Disponibilidad de la RedMarcos Huerta S. 26
  10. 10. Metodología Top Down Analizando la Utilización de la Red Utilización de red es una medida de cuanta ancho de banda está en el uso durante un intervalo de tiempo específico. La utilización es comúnmente especificada como un porcentaje de capacidad. Si un instrumento que supervisa la red dice que la utilización de red en un segmento de Fast Ethernet es el 70%, por ejemplo, este significa que el 70% de la capacidad 100-Mbps está en el uso, hecho un promedio sobre un margen de tiempo especificado o ventana. Diferentes instrumentos usan diferente promedio de ventanas para calcular la utilización de red. Algunos instrumentos dejan al usuario cambiar la ventana. La utilización de un intervalo largo puede ser útil para reducir la cantidad de datos estadísticos que deben ser analizados, pero la granularidad es sacrificada. Figura Nro. 09. Analizando la Utilización de la Red Utilización del Ancho de Banda por Protocolo El desarrollo de una performance preciso de la performance de red también debería incluir la utilización de medición del tráfico de broadcast contra el tráfico unicast, y por cada protocolo principal. Algunos protocolos envían excesivo tráfico de broadcast, que puede degradar seriamente la performance, sobre todo en redes switchadas. Para medir la utilización del ancho de banda por protocolo, coloque un analizador de protocolo en cada segmento de la red principal y llena una tabla como la mostrada en la figura. Si el analizador soporta porcentajes relativos y absolutos, especifique el ancho de banda usada por protocolos en comparación al total de ancho de banda en uso. Uso relativo especifica cuanto ancho de banda es usada por protocolo en comparación con el ancho de banda total actualmente en uso en el segmento. Uso absoluto especifica cuanta ancho de banda es usada por protocolo en comparación con la capacidad total del segmento (por ejemplo, en comparación con 100 Mbps en Fast Ethernet).Marcos Huerta S. 27
  11. 11. Metodología Top Down Tabla Nro. 02 Utilización del Ancho de Banda por Protocolo Análisis de la Exactitud de Red Usted puede usar a un probador BER (también llamado BERT) en líneas seriales para probar el número de bits dañados comparados a los totales de bits. Con redes por paquete switchados, hace más sentido de medir el paquete (packer) de errores porque un paquete entero es considerado malo si un solo bit es cambiado o descartado. En redes por paquete switchados, una estación de envío calcula un ciclo de redundancia CRC basado en los bits del paquete. La estación de envío reemplaza el valor del CRC en el paquete. Una estación de recepción determina si el bit ha sido cambiado entonces descarta el paquete y vuelve a calcular el CRC otra vez y comparando el resultado con el CRC del paquete. Un paquete con CRC malo es descartado y debe ser transmitido de nuevo por el remitente. Por lo general un protocolo de capa superior tiene el trabajo de transmitir de nuevo los paquetes que no se ha reconocidos. Un analizador de protocolo puede comprobar el CRC en los paquetes recibidos. Como la parte de su análisis de performance preciso, usted debería rastrear el número de paquetes recibidos con CRC malo cada hora o cada dos días. Como es normal los errores aumentan con la utilización, errores de documento como una función del número de bytes vistos por el instrumento de escucha. Un umbral de regla básica bueno para considerar errores malsanos es que una red no debería tener más de un paquete malo por megabyte de datos. (Errores calculados este camino le deja simular una serie BERT. Simplemente el cálculo de un porcentaje de paquetes malos comparados con paquetes buenos nos explica el tamaño de paquete y de ahí no da una indicación buena de cuantos trozos realmente se han dañados). Además del rastreo de errores de capa de enlace de datos, como errores CRC, un análisis del performance preciso debería incluir la información en problemas de capa superior. Un analizador de protocolo que incluye un sistema experto, como WildPackets EtherPeek NX analizador de red, se apresura la identificación de problemas de capaMarcos Huerta S. 28
  12. 12. Metodología Top Down superior por automáticamente generando diagnósticos y síntomas para conversaciones de red y aplicaciones. La exactitud también debería incluir una medida de paquetes perdidos. Usted puede medir paquetes perdidos midiendo el tiempo de respuesta. Enviando paquetes para medir cuanto tiempo este toma para recibir una respuesta, documente cualquier paquete que no recibe una respuesta, probablemente porque la petición o la respuesta fue perdido. Correlacione la información sobre paquetes perdidos con otras medidas de interpretación para determinar si los paquetes perdidos indican una necesidad de aumentar el ancho de banda, para disminuir errores CRC, o mejorar dispositivos de funcionamiento entre redes. Usted también puede medir paquetes perdidos mirando la estadística guardada por gestores de tráfico en el número de paquetes descartados de colas de salida o entrada. Analizando la Eficiencia de la Red La utilización de ancho de banda es optimizada para la eficacia cuando las aplicaciones y los protocolos son configurados para enviar cantidades grandes de datos por paquete, así minimizando el número de paquete y tardanzas de ida y vuelta requeridas para una transacción. El número de paquetes por transacción también puede ser minimizado si el receptor es configurado con una ventana grande que lo permite aceptar paquetes múltiples antes de que esto debiera enviar un reconocimiento. Cambiando la transmisión y recepción del tamaño de buffer- paquete de los clientes y los servidores pueden causar la eficacia mejorada por paquete recibido en la ventana. El aumento de la unidad de transmisión máxima (MTU) en interfaces del router también puede mejorar la eficacia. Por otra parte, el aumento del MTU es a veces necesario en interfaces del router de aquellos que usan túneles. Los problemas pueden ocurrir cuando una cabecera suplementario es añadido por el túnel hace que el paquete sean más grandes que falta MTU. Un síntoma típico de este problema es que los usuarios pueden ping y Telnet, pero no usar el Protocolo de Transferencia de Hipertexto (HTTP), FTP, y otros protocolos que usan los paquetes grandes. Una solución es aumentar el MTU en el interfaz del router. Para determinar si los objetivos de su cliente para la eficacia de red son realistas, usted debería usar un analizador de protocolo para examinar los tamaños de los paquetes que se usa en la red. Muchos analizadores de protocolo le dejan tabla de salida como el que se especifica en la figura 3.7Marcos Huerta S. 29
  13. 13. Metodología Top Down 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 RespuestaMarcos Huerta S. 30
  14. 14. Metodología Top Down El Chequeo del estado de los Routers principales, Switches, y Firewalls El paso final en la caracterización de las redes existentes debe comprobar el comportamiento de los dispositivos de funcionamiento entre redes en las redes. Este incluye routers e switches que unen capas de una topología jerárquica, routers de backbone e switches, y firewalls que tendrán los papeles más significativos en su nuevo diseño de red. No es necesario comprobar cada switch de LAN, sólo los switches principales, routers, y firewalls. La comprobación del comportamiento y la salud de un dispositivo de funcionamiento entre redes incluye la determinación que ocupado el dispositivo es (utilización de CPU), cuantos paquetes esto ha tratado, cuantos paquetes esto se ha perdido, y el estado de los buffer y colas. Su método para tasar la salud de un dispositivo de funcionamiento entre redes depende del vendedor y la arquitectura del dispositivo. Parte 4. Caracterizando un diseño de trafico de red Este sección describe las técnicas para caracterizar el flujo de tráfico, el volumen de tráfico, y el comportamiento de protocolo. Las técnicas incluyen el reconocimiento de tráfico fuente y almacenaje de datos, documentar las aplicaciones y uso el de protocolo, y evaluar del tráfico de red causado por protocolos comunes. El la sección anterior se habló de la caracterización de la red existente en términos de su estructura e interpretación. Como el análisis de la situación existente es un paso importante en un acercamiento de análisis de sistemas para diseñar, este sección se habla de la caracterización de la red existente en términos de flujo de tráfico. Esta sección también cubre nuevas exigencias de diseño de red, añadiendo los dos primeras secciones que cubrieron objetivos de diseño comerciales y técnicos. Esta sección reenfoca en exigencias de diseño y describe exigencias en términos de flujo de tráfico, carga, y comportamiento; y calidad de servicio (QoS) exigencias. Caracterizando el Flujo de Trafico La caracterización del flujo de tráfico implica identificar fuentes y destinos del tráfico de red y analizar la dirección y la simetría de datos que viajan entre fuentes y destinos. En algunas aplicaciones, el flujo es bidireccional y simétrico. (Ambos finales del flujo envían el tráfico en aproximadamente el mismo precio.) En otras aplicaciones, el flujo es bidireccional y asimétrico. Las estaciones de cliente envían pequeñas preguntas y los servidores envían grandes corrientes de datos. Los broadcast de una aplicación, el flujo es unidireccional y asimétrico. Esta sección habla de la caracterización de la dirección yMarcos Huerta S. 31
  15. 15. Metodología Top Down la simetría del flujo de tráfico en una red existente y análisis del flujo para nuevas aplicaciones de red. La Identificación de las Principales Fuentes de Tráfico y Almacenamiento Para entender el flujo de tráfico de red, usted debería identificar primero comunidades de usuario y almacenamiento de datos para las aplicaciones existentes. A comunidad de usuario es un grupo de trabajadores que usan una aplicación particular o un grupo de aplicaciones. Una comunidad de usuario puede ser un departamento corporativo o un grupo de departamentos. Sin embargo, en muchos ambientes, el uso de aplicación cruza muchos departamentos. Cuando más corporaciones usan la dirección de la matriz y forman equipos virtuales para completar un proyecto, se hace más necesario caracterizar comunidades de usuario por aplicación y uso de protocolo más bien que por el límite de departamentos. Para documentar comunidades de usuario, pida a su cliente ayudarle a llenar un formulario de Comunidades de Usuario mostrada en la Tabla Nro. 04. Para la columna de posición de la figura, los nombres de posición de uso que usted ya documentó en un mapa. Para aplicaciones, nombres de aplicación de uso en los cuales usted ya documentó en los formularios de Aplicaciones de Red. Tabla Nro. 04 Comunidades de Usuarios Además de la documentación de comunidades de usuario, caracterizando el flujo de tráfico también requiere que usted documente los principales almacenamiento de datos. Un almacenamiento de datos (a veces llamaba a colector de datos) es un área en una red donde los datos de capa de aplicación residen. Un almacenamiento de datos puede ser un servidor, un grupo de servidores, una red de área de almacenaje (SAN), un ordenador central, una unidad de reserva de cinta, una biblioteca de vídeo digital, o cualquier dispositivo o componente de un red donde las cantidades grandes de datos son almacenadas. Para ayudarle a documentar los principales almacenamiento de datos, pida a su cliente ayudarle a llenar el siguiente formulario. Para la Posición, la Aplicación, y las columnas de Comunidad de Usuario, usa nombres que usted ya documentó en un mapa y otras cartas.Marcos Huerta S. 32
  16. 16. Metodología Top Down Tabla Nro. 05 Formulario de Almacenamiento de Datos Documentar el Flujo de Tráfico en la Red Existente La documentación del flujo de tráfico implica identificar y caracterizar flujos de tráfico individuales entre fuentes de tráfico y almacenes. Los flujos de tráfico se han hecho recientemente un tema caliente para la discusión en la comunidad de Internet. Mucho progreso está siendo hecho en la definición de flujos, medición de comportamiento de flujo, y permiso de una estación final de especificar los requerimientos de performance por flujo. Para entender mejor el comportamiento de flujo de tráfico, usted puede leer la Petición de Comentarios (RFC) 2722, "Medida de Flujo de Tráfico: Arquitectura." El RFC 2722 describe una arquitectura para la medida y reportaje de flujos de tráfico de red, y habla como la arquitectura está relacionada con una arquitectura de flujo de tráfico total para el intranet y el Internet. La medición del comportamiento de flujo de tráfico puede ayudar a un diseñador de red a determinar qué trafico de routers deberían ser peer en los protocolos de encaminamiento que usan un sistema peering, como el Border Gateway Protocol (BGP). La medición del comportamiento de flujo de tráfico también puede ayudar a los diseñadores de la red y debran hacer lo siguiente: • Caracterice el comportamiento de redes existentes. • Plan de desarrollo y extensión de la red. • Cuantifique la performance de la red. • Verifice la calidad del servicio de red. • Asigne el uso de aplicaciones y usuarios de la red . Un flujo individual de tráfico de red puede ser definido como protocolo e información de aplicación transmitida entre entidades que se comunican durante una sesión sola. Un flujo tiene atributos como dirección, simetría, caminos de enrutamiento, opciones de enrutamiento, número de paquetes, número de bytes, y se dirige el flujo hacia una dirección final. Una entidad que se comunica puede ser un sistema de final (host), una red, o un sistema autónomo.Marcos Huerta S. 33
  17. 17. Metodología Top Down El método más simple para caracterizar el tamaño de un flujo es medir el número de Kilobytes o Mbytes por segundo entre entidades que se comunican. Para caracterizar el tamaño de un flujo, use un analizador de protocolo o conecte a la red el sistema de dirección para registrar la carga entre fuentes importantes y destinos. Los instrumentos de Cisco para caracterizar flujos de tráfico incluyen Cisco FlowCollector y el Analizador de Datos, que están basados en el Cisco NetFlow la tecnología. Usted puede usar el formulario siguiente descirto para documentar información sobre la dirección y volumen de flujos de tráfico. El objetivo es documentar los Kilobytes o Mbytes por segundo entre pares de sistemas autónomos, redes, hosts, y aplicaciones. Para conseguir la información para llenar los formularios, coloque un dispositivo que monitoree el core de la red y déjele coleccionar datos por uno o dos días. Para conseguir la información para llenar la columna de Path, usted puede encender la opción de grabar-ruta de registro en una red de IP. La opción de ruta de registro tiene algunas desventajas, sin embargo. Esto no apoya redes muy grandes y es a menudo minusválido para razones de seguridad. Usted también puede estimar el path mirando la tabla de encaminamiento y análizando el tráfico de red en multiples segmentos. Tabla Nro. 06 Flujo de Tráfico en la Red Existente La Caracterización de Tipos de Flujo de Tráfico para Nuevas Aplicaciones de Red Como mencionado, un flujo de red puede ser caracterizado por su dirección y simetría. La dirección especifica si los datos viajan en ambas direcciones o en sólo una dirección. La dirección también especifica el camino que un flujo toma cuando esto viaja de la fuente al destino por una de las redes. La simetría describe si el flujo tiende a tener alta performance o requerimientos de QoS en una dirección que en la otra dirección. Muchas aplicaciones de red tienen requerimientos diferentes en cada dirección. Algunas tecnologías de transmisión como la Línea de Suscriptor Digital Asimétrica (ADSL), son fundamentalmente asimétricas. Una técnica buena para caracterizar flujo de tráfico de red debe clasificar aplicaciones que soportan una de los tipos de flujo conocidos:Marcos Huerta S. 34
  18. 18. Metodología Top Down • Flujo de tráfico de terminal/host. • Flujo de tráfico de cliente/servidor. • Flujo de tráfico Punto a Punto. • Flujo de tráfico de servidor/servidor. • Flujo de tráfico de cálculo distribuido. En su libro “Análisis de Red, Arquitectura, y Diseño”, Segunda Edición, James D. McCabe hace un trabajo excelente de caracterización de los distintos modelos de flujo. Flujo de Tráfico de Terminal/host El tráfico de terminal/host es por lo general asimétrico. El terminal envía unos caracteres y el host envía muchos caracteres. El Telnet es un ejemplo de una aplicación que genera el tráfico de terminal/host. Por defecto detrás de Telnet consiste en que el terminal envía un simple paquete cada vez que el usuario escribe un carácter. El host devuelve caracteres múltiples, según lo que el usuario escribió. Como una ilustración, considere el principio de una sesión Telnet que comienza con el usuario que escribe su nombre. Una vez que el host recibe cada paquete para los caracteres del nombre, el host devuelve un paquete de mensaje de regreso (como la Contraseña Requerida). Flujo de Tráfico de Cliente/Servidor El tráfico de cliente/servidor es el mejor tipo de flujo conocido y el más extensamente usado. Los servidores son generalmente poderosas computadoras dedicadas a administrar el almacenaje de disco, impresoras, u otros recursos de red. Los clientes son ordenadores personales o estaciones de trabajo en las cuales los usuarios dirigen aplicaciones. Los clientes confían en servidores para el acceso a recursos, como almacenaje, periféricos, software de aplicación, y poder de procesamiento. Los clientes envían preguntas y peticiones a un servidor. El servidor responde con datos o el permiso para el cliente para enviar datos. El flujo es por lo general bidireccional y asimétrico. Las peticiones del cliente son típicamente pequeños paquetes, excepto cuando escribe datos al servidor, en cuyo caso ellos son más grandes. Las respuestas del servidor son de un rango de 64 bytes a 1500 bytes o más, dependiendo del tamaño maximo del paquete. En un ambiente TCP/IP, muchas aplicaciones son puestas en práctica de una manera de cliente/servidor, aunque las aplicaciones fueran inventadas antes de que el modelo de cliente/servidor fuera inventado. Por ejemplo, el Protocolo de Transferencia de Archivos (FTP) tiene un lado de servidor y cliente. Los clientes de FTP usan aplicaciones de FTP para dirigirse a servidores de FTP. Estos días, el Protocolo de Transferencia de Hipertexto (HTTP) es probablemente el protocolo de cliente/servidor el más extensamente usado. Los clientes usan unaMarcos Huerta S. 35
  19. 19. Metodología Top Down aplicación de navegador de web, como Netscape, para poder conectarse con el servidor web. El flujo es bidireccional y asimétrico. Cada sesión a menudo dura sólo unos segundos porque los usuarios tienden a saltar de un sitio Web al otro. Flujo de Tráfico Punto a Punto Con el flujo tráfico punto a punto, el flujo es por lo general bidireccional y simétrico. Las entidades que se comunican transmiten cantidades aproximadamente iguales de la información. No hay ninguna jerarquía. Cada dispositivo es considerado tan importante el uno como el otro, y ningún dispositivo tiene considerablemente más datos que el otro dispositivo. En pequeños ambientes de LAN, loa administradores de red a menudo establecen las configuraciones con los ordenadores personales en un punto a punto de modo que cada uno pueda tener acceso a datos de cada uno e impresoras. No hay ningún servidor de archivo central o servidor de impresora. Otro ejemplo de punto a punto el ambiente es preparado para multiusuarios UNIX o host donde los usuarios establecen FTP, Telnet, HTTP, y sesiones de Sistema de Archivos de Red entre host. Cada host actúa tanto como cliente y como servidor. Hay muchos flujos en ambas direcciones. Recientemente las aplicaciones punto a punto para descargar música, videos, y software han ganado la popularidad. Cada usuario publica la música u otro material y permite que otros usuarios en el Internet descarguen los datos. Este es considerado tráfico punto a punto porque cada usuario actúa tanto como distribuidor y consumidor de datos. El flujo de tráfico es bidireccional y simétrico. La mayor parte de empresas y muchas redes de universidad rechazan este tipo de tráfico punto a punto por dos motivos. Primero, esto puede causar una cantidad excesiva del tráfico, y, segundo, el material publicado es a menudo copyright por alguien además de la persona que lo publica. Un otro ejemplo de aplicación punto a punto es una reunión de negocios entre la gente de una empresa en sitios remotos usando equipos de videoconferencia. En una reunión, cada asistente puede comunicar tantos datos como son necesarios en cualquier momento. Todos los sitios tienen las mismas exigencias QoS. Una reunión es diferente para cada situación donde la videoconferencia es usada para diseminar la información. Con la diseminación de información, como una clase de formación o un discurso por un presidente corporativo a empleados, la mayor parte de los datos fluyen del sitio central. Unas preguntas son permitidas de los sitios remotos. La diseminación de información es por lo general puesta en práctica usando un modelo de cliente/servidor.Marcos Huerta S. 36
  20. 20. Metodología Top Down Flujo de Tráfico de Servidor/Servidor El tráfico de servidor/servidor incluye transmisiones entre servidores y transmisiones entre manejo de aplicaciones. Los servidores se dirigen a otros servidores para implementar los servicios de directorio, una cahe pesadamente usa datos, los mirrow de datos para equilibrio de carga y redundancia, backup de datos, y disponibilidad de broadcast de servicio. Los servidores manejan las aplicaciones por algunos mismos motivos, sino también hacer cumplir políticas de seguridad y actualizar datos de dirección de red. Con el tráfico de red de servidor/servidor, el flujo es generalmente bidireccional. La simetría del flujo depende de la aplicación. Con la mayor parte de aplicaciones de servidor/servidor, el flujo es simétrico, pero en algunos casos esto es heredado de servidores, con algunos servidores que envían y y almacenan más datos que otros. Flujo de Tráfico de Cálculo Distribuido La informática distribuida se refiere a aplicaciones que requieren múltiples nodos que trabajan y realizan cálculos juntos para completar un trabajo. Algunas tareas de modelos complejos no pueden ser llevadas a cabo en un margen de tiempo razonable a menos que múltiples computadoras traten datos y dirijan algoritmos simultáneamente. Los efectos especiales para películas a menudo son desarrollados y calculados en un ambiente distribuido. La informática distribuida también es usada en la industria de semiconductor para calcular las necesidades extremas del diseño y verificación de un microchip, y en la industria de defensa para proporcionar ingeniería y simulaciones militares. Con algunas aplicaciones de cálculo distribuidas, el manejador de tarea dice a los nodos de cálculo que hacer en una base infrecuente, causando poco flujo de tráfico. Con otras aplicaciones, hay comunicación frecuente entre el manejador de tarea y los nodos de cálculo. La Documentación de Flujo de Tráfico para Aplicaciones Nuevas y Existentes de la Red Para documentar el flujo de tráfico para nuevo (y existentes) de aplicaciones de red, caracterice el tipo de flujo para cada aplicación y ponga las comunidades de usuario en una lista y los almacenes de datos que tienen que ver con aplicaciones. Usted puede usar este formulario:Marcos Huerta S. 37
  21. 21. Metodología Top Down Tabla Nro. 07 Flujo de Tráfico para Aplicaciones Nuevas y Existentes Caracterización de Carga de Tráfico Para seleccionar topologías apropiadas y tecnologías para encontrar los objetivos de un cliente, es importante caracterizar la carga de tráfico con el flujo de tráfico. La caracterización de la carga de tráfico puede ayudarle a diseñar redes con la capacidad de uso local suficiente y flujos de redes. A causa de muchos factores implicados en la caracterización del tráfico de red, las estimaciones de carga de tráfico con poca probabilidad serán precisas. El objetivo es evitar simplemente un diseño que tiene cualquier cuello de botella crítico. Para evitar cuellos de botella, usted puede investigar modelos de uso de aplicación, tiempos ociosos entre paquetes y sesiones, tamaños de paquetes, y otros patrones de tráfico behaviorísticos para protocolos de sistema y aplicación. Otro acercamiento a la evitación de cuellos de botella debe lanzar simplemente cantidades grandes de ancho de banda en el problema. Una interpretación estricta de principios de análisis de sistemas no aprobaría tal acercamiento, pero el ancho de banda es barato estos días. El ancho de banda de LAN es muy barato. No hay simplemente ninguna excusa para no usar Fast Ethernet (o mejor) en todas las nuevas estaciones de trabajo e switches, y la mayor parte de organizaciones también pueden permitirse a usar Gigabit Ethernet en switch a switch y switch a servidor. El ancho de banda WAN es todavía cara en algunas partes del mundo, incluso áreas rurales de los Estados Unidos. Pero en muchas partes de los Estados Unidos y el resto del mundo, el ancho de banda ha sido sobre aprovisionada y no está hasta cerca de ser sobre utilizado. El Cálculo de Carga de Tráfico Teórica La carga de tráfico (a veces llamado carga ofrecida) es la suma de todos los nodos de red de datos que estan listo para transmitir en un tiempo particular. Un objetivo general para la mayor parte de diseños de red es que la capacidad de red debería ser más queMarcos Huerta S. 38
  22. 22. Metodología Top Down adecuada de manejar la carga de tráfico. El desafío debe determinar si la capacidad propuesta para un nuevo diseño de red es suficiente para manejar la carga potencial. En su libro Redes de Área Locales y Metropolitanas, Guillermo Stallings proporciona algunos cálculos atrás el-desarrollo para la carga de tráfico calculadora. El Stallings indica que usted puede hacer un cálculo elemental basado simplemente en el número de la transmisión de estaciones, como rápidamente cada estación genera mensajes, y el tamaño de mensajes. Por ejemplo, para una red con una capacidad propuesta de 1 Mbps, si 1000 estaciones envían paquetes de 1000 bits cada segundo, entonces la carga ofrecida iguala la capacidad. Aunque Stallings se refiriera a la capacidad de un LAN, capacidad podría referirse a la capacidad de una WAN, una entera red o las partes de una rede, o la el trafico de la placa madre de un switch o router. En general, para contar si la capacidad es suficiente, sólo unos parámetros son necesarios: • El número de estaciones. • El tiempo medio que una estación es ociosa entre el envío de paquetes. • El tiempo requerido transmitir un mensaje una vez el acceso medio es ganado. Estudiando tiempos ociosos y tamaño de los paquetes con un analizador de protocolo, y estimando el número de estaciones, usted puede determinar si la capacidad propuesta es suficiente. Si usted investiga tipos de flujo de tráfico, como hablado antes en este capítulo, usted puede desarrollar estimaciones más precisas de la carga. En vez de asumir que todas las estaciones tienen calidades similares que generan carga, usted puede asumir que las estaciones usando una aplicación particular tienen calidades similares que generan carga. Las asunciones pueden ser hechas sobre tamaño de paquete y tiempo ocioso para una aplicación después de que usted ha clasificado el tipo de flujo y ha identificado los protocolos usado por la aplicación. Para una aplicación de cliente/servidor, el tiempo ocioso para el servidor depende del número de clientes que usan al servidor, y la arquitectura y las características de interpretación del servidor (velocidad de acceso de disco, velocidad de acceso de RAM, caching mecanismos, etcétera). Estudiando el tráfico de red de servidores con un analizador de protocolo, usted puede estimar un tiempo ocioso medio.Marcos Huerta S. 39
  23. 23. Metodología Top Down El tiempo ocioso en el lado de cliente depende en parte de la acción de usuario, el que significa que es imposible predecir exactamente el tiempo ocioso. Sin embargo, usted puede hacer estimaciones del tiempo ocioso estudiando el tráfico con un analizador de protocolo y usando escrituras para simular acciones de usuario en el peor de los caso, o usando un instrumento de modelado de red. Después de que usted ha identificado la carga de tráfico aproximada para un flujo de aplicación, usted puede estimar la carga total para una aplicación multiplicando la carga para el flujo por el número de dispositivos que usan la aplicación. La investigación que usted hace en el tamaño de comunidades de usuario y el número (de servidores) de almacen de datos puede ayudarle a calcular una exigencia del ancho de banda agregada aproximada para cada aplicación. La documentación de la posición de comunidades de usuario y almacenes de datos, en las cuales usted hizo el formulario, puede ayudarle a entender la cantidad de tráfico que fluirá de un segmento al otro. Este puede ayudar en la selección de tecnologías de columna vertebral y dispositivos de funcionamiento entre redes. Estimando la carga de tráfico, además de la investigación de tiempos ociosos entre paquetes, tamaños de paquetes, y comportamiento de flujo, usted también debería investigar modelos de uso de aplicación y exigencias QoS. Algunas aplicaciones son usadas con poca frecuencia, pero requieren una cantidad grande del ancho de banda cuando ellos son usados. Documentación de Patrones de uso de Aplicación El primer paso en la documentación de modelos de uso de aplicación debe identificar comunidades de usuario, el número de usuarios en las comunidades, y las aplicaciones que emplean los usuarios. Este paso, que fue cubierto ya antes en esta sección, puede ayudarle a identificar el número total de usuarios para cada aplicación. Además de la identificación del número total de usuarios para cada aplicación, usted también debería documentar la información siguiente: • La frecuencia de sesiones de aplicación (el número de sesiones por día, semana, mes o independientemente del período de tiempo es apropiado). • La longitud de una sesión de aplicación media. • El número de usuarios simultáneo de una aplicación. Armado con la información en la frecuencia y la longitud de sesiones, y el número de sesiones simultáneas, usted puede predecir más exactamente la exigencia de ancho deMarcos Huerta S. 40
  24. 24. Metodología Top Down banda agregada para todos los usuarios de una aplicación. Si no es práctico investigar estos detalles, usted puede hacer algunas conclusiones: • Usted puede asumir que el número de usuarios de una aplicación es igual al número de usuarios simultáneos. • Usted puede asumir que todas las aplicaciones son usadas todo el tiempo de modo que su cálculo de ancho de banda sea un caso pico de estimación (máxima). • Usted puede asumir que cada usuario abre sólo una sesión y que una sesión dura todo el día hasta que el usuario cierre la aplicación al final de día. Refinando Estimaciones de Carga de Tráfico causada por Aplicaciones Para refinar la estimación de requerimientos de aplicación ancho de banda, usted tiene que investigar el tamaño de objetos de datos enviados por aplicaciones, la sobrecarga causada por capas de protocolo, y cualquier carga adicional causada por la inicialización de aplicación. (Algunas aplicaciones envían mucho más tráfico durante la inicialización que durante la operación estable.) Como las aplicaciones y los usuarios varían extensamente en el comportamiento, es difícil estimar exactamente el tamaño medio de objetos de datos que los usuarios transfieren el uno al otro y a servidores. (La respuesta de ingeniería verdadera a la mayor parte de preguntas relacionadas para conectar a la red tráfico es "esto depende.") el cuadro siguiente proporciona algunas estimaciones para tamaños de objeto que usted puede usar haciendo cálculos atrás de la carga de tráfico de aplicación, pero recordar que el cuadro proporcionado no toma el lugar de un análisis cuidadoso del comportamiento de aplicación actual. Tabla Nro. 08 Tamaño Aproximado de Objetos de Transferencia de Aplicaciones a través de redesMarcos Huerta S. 41
  25. 25. Metodología Top Down 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 laMarcos Huerta S. 42
  26. 26. Metodología Top Down cantidad de ancho de banda usada por herencia de protocolos de enrutamiento vector- distancia. Tabla Nro. 10 Ancho de banda Usada por Herencia de Protocolos de enrutamiento Un router envía largas tablas de enrutamiento de vector-distancia que cada minuto puede usar un porcentaje significativo del ancho de banda de la WAN. Como el protocolo de encaminamiento limita el número de rutas por paquete, en redes grandes, un router de tráfico envía paquetes múltiples para enviar la tabla entera. Los nuevos protocolos de encaminamiento, como OSPF y EIGRP, usan ancho de banda muy pequeña. En caso de OSPF, su preocupación principal debería ser la cantidad de ancho de banda consumida por los paquetes de sincronización de base de datos que los routers de tráfico envían cada 30 minutos. Subdividiendo una red de OSPF en áreas y usando la ruta sumarizada, este tráfico puede ser minimizado. Otro tráfico de sincronización de base de datos, es el único tráfico que OSPF envía después de la inicialización es pequeño paquete Hello cada 10 segundos. El EIGRP también envía paquetes Hello, pero con más frecuencia que OSPF (cada 5 segundos). Por otra parte, EIGRP no envía ninguna actualización de ruta periódica o paquetes de sincronización de base de datos. Esto sólo envía actualizaciones de ruta cuando hay cambios en la topología. Caracterización del Comportamiento del Tráfico Seleccionar una apropiada solución de diseño de red, usted tiene que entender el protocolo y el comportamiento de las aplicaciones además de flujos de tráfico y carga. Por ejemplo, para seleccionar topologías apropiada de LAN, usted tiene que investigar el nivel del tráfico de broadcast en la LAN. Para aprovisionar la capacidad adecuada para LAN y WAN, usted tiene que chequear la utilización extra de ancho de banda causada por protocolos ineficientes y tamaños de paquetes no óptimos o retransmisión de temporizadores.Marcos Huerta S. 43
  27. 27. Metodología Top Down Comportamiento de Broadcast/Multicast Un paquete de broadcast que va a todas las estaciones de red en un LAN. En la capa de enlace de datos, la dirección de destino de un paquete de broadcast es FF:FF:FF:FF:FF:FF (todos 1s en el binario). A paquete de multicast es un paquete que va a un subconjunto de estaciones. Por ejemplo, un paquete destinado a 01:00:0C:CC:CC:CC va a routers de tráfico Cisco e switches que dirigen el Protocolo de Descubrimiento Cisco (CDP) en un LAN. Los dispositivos de capa 2 , como switches y bridge, envian los paquetes de broadcast y multicast a todos los puertos. El envió de paquetes de broadcast y multicast puede ser un problema de escalabilidad para grandes edificaciones de (switches o bridge) redes. Un router no envia tráfico de broadcast o multicast. Todos los dispositivos en un lado de un router son considerados la parte de un solo dominio de bradcast. Además de la inclusión de routers en el diseño de una red disminuira el transporte de broadcast, usted también puede limitar el tamaño de un dominio de broadcast poniendo en práctica LAN virtuales (VLANs). Tecnología de VLAN, que en la sección, "El diseño de una Topología de Red," habla más detalladamente, permite que un administrador de red subdivida a usuarios en subredes asociando puertos del switch con uno o varios VLANs. Aunque un VLAN pueda atravesar muchos switches, el tráfico de broadcast dentro de un VLAN no es transmitido fuera del VLAN. Demasiados paquetes de broadcast pueden abrumar estaciones finales, switches, y routers. Es importante que usted investigue el nivel del tráfico de broadcast en su diseño propuesto y limite el número de estaciones en un simple dominio de broadcast. El término radiación de broadcast a menudo es usado para describir el efecto de broadcast que se extienden del remitente a todos los dispositivos en un dominio de broadcast. La radiación de broadcast puede degradar la performance en estaciones de red. La tarjeta de interfaz de red (NIC) con una estación de red pasa broadcast y multicast relevantes a la CPU de la estación. Algunos NICs pasan todas las multicast a la CPU, aun cuando las multicast no son relevantes, porque las NICs no tienen el software de conductor que es más selectivo. El software de conductor inteligente puede decir una NIC que multicast pasa a la CPU. Lamentablemente, no todos los conductores tienen esta inteligencia. Las CPUs en las estaciones de red se hacen abrumadas tratando de procesar niveles altos de broadcast y multicast. Si más del 20 por ciento del tráfico de red es broadcast o multicast, la red tiene que ser segmentada usando routers o VLANs. Otra causa posible del pesado tráfico de broadcast es la tormenta de broadcast causada por intermitencias en la red o estaciones de red caídas. Por ejemplo, una máscara deMarcos Huerta S. 44
  28. 28. Metodología Top Down 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 clienteMarcos Huerta S. 45
  29. 29. Metodología Top Down usará en el nuevo diseño de red, el MTU puede ser configurado para algunas aplicaciones. En un ambiente IP, usted debería evitar aumentar el MTU más de lo soportado, evitar la fragmentación y reensamblación de paquetes. Cuando los dispositivos al final de los nodos o routers tienen que fragmentar y volver a reensamblar paquetes, la performance se degrada. Los sistemas operativos modernos soportan el descubrimiento del MTU. Con el descubrimiento MTU, el software puede descubrir dinámicamente y usar el tamaño más grande del paquete que cruzará la red sin requerir la fragmentación. El descubrimiento de MTU generalmente trabaja, pero hay algunos problemas con ello como mencionamos en el "Análisis de Eficacia de Red". Interacción de Protocolo La ineficiencia en redes no es causada sólo por pequeños tamaños de paquetes. La ineficiencia también es causada por la interacción de protocolos y la no correcta configuración de temporizadores de reconocimiento y otros parámetros. Windowing y Control de Flujo Para entender realmente el tráfico de red, usted tiene que entender el control de flujo y windowing. Un dispositivo TCP/IP, por ejemplo, envía segmentos (paquetes) de datos en secuencia rápida, sin esperar un reconocimiento, hasta que su envío de ventana ha sido agotado. Una estación envía la ventana está basado en el recipiente que reciba la ventana. El estado del recipiente en cada paquete TCP determina cuantos datos está listo para recibir. Este total puede variar de unos bytes hasta 65,535 bytes. El recipiente de ventana está basado en cuanta memoria el receptor tiene y que tan rápido procesa los datos recibidos. Usted puede optimizar la eficacia de red aumentando la memoria y el poder de CPU en las estaciones finales, el cual pueden causar ventanas de recipiente grande. Algunas aplicaciones TCP/IP corren encima de UDP, y no TCP. En este caso, no hay ningún control de flujo o el control de flujo es manejado en la sesión o capa de aplicación. Mostramos una lista para determinar qué protocolos están basados en TCP y qué protocolos están basados en UDP: • Protocolo de transferencia de archivos (FTP): Puerto de TCP 20 (datos) y puerto TCP 21 (control). • Telnet: Puerto de TCP 23. • Protocolo de Transferencia Postal Simple (SMTP): Puerto de TCP 25.Marcos Huerta S. 46
  30. 30. Metodología Top Down • Protocolo de Transferencia de Hipertexto (HTTP): Puerto de TCP 80. • Protocolo de Dirección de Red Simple (SNMP): Puertos de UDP 161 y 162. • Sistema de Nombre de Esfera (DNS): Puerto de UDP 53. • Protocolo de Transferencia de Archivos Trivial (TFTP): Puerto de UDP 69. • Servidor de DHCP: Puerto de UDP 67. • Cliente de DHCP: Puerto de UDP 68. • Llamada de Procedimiento Remota (RPC): Puerto de UDP 111 Mecanismos de Recuperación de error Los mecanismos de recuperación de error mal diseñados pueden gastar el ancho de banda. Por ejemplo, si un protocolo retransmite de nuevo datos muy rápidamente sin esperar un periodo de tiempo para recibir un reconocimiento, este puede causar la degradación del performance para el resto de la red debido al ancho de banda usada. Los protocolos de baja conexión por lo general no ponen en práctica la recuperación de error. Mayormente en la capa de enlace de datos y los protocolos de capa de red son de baja conexión. Algunos protocolos de capa de transporte, como UDP, son de baja conexión. Los mecanismos de recuperación de error para protocolos orientados por conexión varían. TCP implementa un algoritmo de nuevo de retransmisión adaptable, el que significa que el ratio de nuevas retransmisiones se reduce cuando la red esta congestionada, el cual optimiza el uso del ancho de banda. Las nuevos implementaciones TCP también ponen en práctica ACK selectivo (SACK), esta descrito en el RFC 2018. Sin el SACK, esta predispuesto al error, los altos caminos de tardanza pueden experimentar que el rendimiento baje debido al camino que TCP reconoce datos. Los reconocimientos de TCP (ACKs) son acumulativos hasta el punto donde un problema ocurre. Si los segmentos pierden el número de ACK es uno más que el número del último byte que fue recibido antes de la pérdida, aun si más segmentos llegaran después de la pérdida. No hay ningún camino para el receptor para recibir algún reporte de un agujero en los datos recibidos. Este hace que el remitente espere un tiempo de ida y vuelta para averiguar sobre cada segmento perdido, o retransmita de nuevo innecesariamente segmentos que el recipiente puede haber recibido correctamente. Con el mecanismo de SACK, el recipiente TCP rellena el campo de opción de SACK en la cabecera TCP para informar al remitente de los bloques no contiguos de datos que han sido recibidos. El remitente puede retransmitir de nuevo entonces sólo los segmentos ausentes. RFC 2018 define una opción TCP para rellenar los números deMarcos Huerta S. 47
  31. 31. Metodología Top Down secuencia recibida para bloques y otra opción TCP para informar al recipiente durante el apretón de manos de tres caminos que el host soporta SACK. Caracterizando los Requerimientos de Calidad de Servicio El análisis de los requerimientos de tráfico de red no es completamente tan simple como identificando flujos, midiendo la carga para flujos, y caracterizando el comportamiento de tráfico como de broadcast y de comportamiento error. Usted también tiene que caracterizar los requerimientos QoS para aplicaciones. Sólo conociendo los requerimientos de carga (ancho de banda) para una aplicación no es suficiente. Usted también tiene que conocer si los requerimientos son flexibles o inflexibles. Algunas aplicaciones siguen trabajando (aunque despacio) cuando el ancho de banda no es suficiente. Otras aplicaciones, como voz y aplicaciones de vídeo, son dadas inútiles si un cierto nivel del ancho de banda no está disponible. Además, si usted tiene una mezcla de aplicaciones flexibles e inflexibles en una red, usted tiene que determinar si es práctico tomar prestada el ancho de banda de la aplicación flexible para guardar el funcionamiento de aplicación inflexible. La voz es también inflexible en cuanto a la tardanza. La voz es también sensible a la pérdida de paquete, que resulta en recorte de periódico de voz y se salta. Sin la configuración apropiada en toda la red de QoS, la pérdida puede ocurrir debido a enlaces congestionados y un pobre buffer de paquetes y manejo de dirección de cola en los routers. Siguiendo esta sección siguiente que analiza los requerimientos de QoS usando ATM e Internet la técnica Engineering Task Force (IETF). El objetivo de estas secciones es introducirle en la terminología del ATM y IETF que los ingenieros usan para clasificar el tráfico y especificar los requerimientos de QoS por clases de tráfico. Aunque el material sea muy altamente técnico y detallado, esto debería darle alguna idea fundamental sobre la clasificación de los tipos de aplicaciones que jugarán una parte en su diseño de red y estar preparado para futuros capítulos que cubren estrategias de diseño y optimización de redes que pueden encontrar las necesidades de varias aplicaciones. Calidad de ATM de Especificaciones de Servicio En su documento "Especificación del Manejo de Trafico la Versión 4.1” el Forum de ATM hace un trabajo excelente de clasificar los tipos de servicio que una red puede ofrecer para soportar diferentes clases de aplicaciones. Incluso si su cliente no tiene ningunos proyectos de usar la tecnología del Modo de Transferencia Asincrónico (ATM), la terminología del Foro de ATM es todavía provechosa porque esto identifica los diferentes parámetros que las clases de aplicaciones deben especificar para solicitar unMarcos Huerta S. 48
  32. 32. Metodología Top Down cierto tipo del servicio de red. Estos parámetros incluyen tardanza y variación del tamaño de tardanza, pérdida de datos, y picos de tráfico máximo, sostenible, y mínimos. Aunque usted debiera sustituir la palabra celda con paquete en algunos casos, las definiciones de Foro de ATM pueden ayudarle a clasificar aplicaciones en cualquier red, hasta redes que no son ATM. El Foro de ATM define seis categorías de servicio, cada uno de las cuales es descrito más detalladamente en esta sección: • Velocidad binaria constante (CBR) • Velocidad binaria variable de tiempo real (rt-VBR) • Velocidad binaria variable no tiempo real (nrt-VBR) • Velocidad binaria no especificada (UBR) • Velocidad binaria disponible (ABR) • Precio de marco garantizado (GFR) Para cada categoría de servicio, el Foro de ATM especifica un juego de parámetros para describir tanto tráfico presente en la red como el QoS requerido de la red. El Foro de ATM también define mecanismos de control de tráfico que la red puede usar para encontrar objetivos QoS. La red puede implementar tales mecanismos de conexión de control de admisión y asignación de recurso diferentes para cada categoría de servicio. Las categorías de servicio son distinguidas al comienzo siendo tiempo real o tiempo no real. El CBR y rt-VBR son categorías de servicio de tiempo real. Las aplicaciones de tiempo real, como voz y aplicaciones de vídeo, requieren la variación de tardanza y tardanza fuertemente obligada. Las aplicaciones en tiempo no real, como cliente/servidor y aplicaciones de datos de terminal/host, no requieren la tardanza fuertemente obligada y retrasan la variación. El Nrt-VBR, UBR, ABR, y GFR son categorías de servicio tiempo no real. Categoría de Servicio de Velocidad Binaria Constante Cuando CBR es usado, unos recursos de reservas de red del final del sistema de la fuente y pregunta por una garantía QoS negociado es asegurado a todas las celdas mientras las celdas se conforman a las pruebas de conformidad relevantes. La fuente puede emitir celdas en el pico de celda máximo (PCR) en cualquier momento y para cualquier duración y los compromisos QoS deberían pertenecer. El CBR es usado por aplicaciones que necesitan la capacidad de solicitar que una cantidad estática del ancho de banda estuviera continuamente disponible durante una conexión de por vida. La cantidad de ancho de banda que una conexión requiere es especificada por el valor de PCR.Marcos Huerta S. 49
  33. 33. Metodología Top Down El servicio de CBR intenta soportar aplicaciones de tiempo real que requieren la variación de tardanza fuertemente obligada (por ejemplo, la voz, el vídeo, y la emulación de circuitos), pero no es restringido a estas aplicaciones. La fuente puede emitir celdas debajo de PCR negociado o ser silenciosa durante períodos del tiempo. Se asume que celdas que son retrasadas más allá del valor especificado por la tardanza de transferencia de parámetros de celdas máxima (maxCTD) son del valor considerablemente reducido a la aplicación. Categoría de Servicio de Velocidad Binaria Variable Tiempo no real La categoría de servicio nrt-VBR es requerida para aplicaciones de tiempo no real que tienen características de tráfico bursty. El servicio es caracterizado en términos de PCR, SCR, y MBS. Para celdas que son transferidas dentro del contrato de tráfico, la aplicación espera una proporción baja de pérdida de celdas (CLR). El servicio de nrt- VBR puede Servicio de Control de Carga El Servicio de control-Carga es definido en RFC 2211 y provee a un cliente un flujo de datos con QoS que se aproxima al QoS este mismo flujo recibiría una descarga en la red. El control de admisión es aplicado a los requisitos de servicio solicitado y es recibido aun cuando la red esta sobrecargada. El Servicio de Control-Carga es requerido para aplicaciones que son muy sensibles a condiciones sobrecargadas, como aplicaciones de tiempo real. Estas aplicaciones trabajan bien en redes descargadas, pero degradan rápidamente en redes sobrecargadas. Un servicio, como el Control-Carga que imita redes descargadas sirve estos tipos de aplicaciones bien. Asumiendo que la red funciona correctamente, un servicio de control-carga esta solicitando de la aplicación puede asumir lo siguiente: • Un alto porcentaje de paquetes transmitidos será recepcionados con éxito al final de los nodos de la red. (El porcentaje de paquetes que no es entregado con éxito debe aproximarse al índice de errores de paquete básico del medio de transmisión.) • La tardanza de tránsito experimentada por un porcentaje muy alto de los paquetes entregados no excederá el mínimo transmitido en la tardanza experimentada por cualquier paquete con éxito entregado. (Esta tardanza de tránsito mínima incluye la tardanza de velocidad de luz más el tiempo de procesamiento fijo en routers y otros dispositivos de comunicaciones a lo largo del camino.)Marcos Huerta S. 50
  34. 34. Metodología Top Down El servicio de control-carga no acepta o hace el uso de valores objetivo específicos para parámetros como tardanza o pérdida. En cambio, la aceptación de una petición del servicio de control-carga implica un compromiso por el nodo de red para proveer el requester del servicio estrechamente equivalente con esto proporcionado a incontrolado (mejor esfuerzo) tráfico en condiciones ligeramente cargadas. Un nodo de red que acepta una petición del servicio de control-carga debe usar funciones de control de admisión para asegurar que los recursos adecuados están disponibles para manejar el nivel solicitado del tráfico, como definido por las solicitudes TSpec . Los recursos incluyen el ancho de banda del, router o el espacio del bufer- puerto del switch, y la capacidad computacional del motor que avanza el paquete. Servicio Garantizado El RFC 2212 describe el comportamiento requerido del nodo de red llamado a entregar un servicio garantizado esta características garantiza tanto la tardanza como ancho de banda. El servicio garantizado proporciona la firma (matemáticamente probable) en la tardanzas de punta a punta que hacen cola paquete. Esto no intenta minimizar la inquietud y no está preocupado por reparar la tardanza, como la tardanza de transmisión. (Reparar la tardanza es una propiedad del camino elegido, que es determinado por el mecanismo de sistema, como RSVP.) El servicio garantizado garantiza que los paquetes llegarán dentro del plazo de entrega garantizado y no serán descartado debidos a desbordamientos, condición de que el tráfico del flujo es conformado por TSpec. Una serie de nodos de red que ponen en práctica la implementación del RFC 2212 esta asegura un nivel de ancho de banda, cuando es usado por un flujo regulado, produce un servicio salto-tardanza sin la pérdida de cola (asumiendo que no falla ningún componentes de red o cambios de la encaminamiento durante la vida del flujo). El servicio garantizado es requerido para aplicaciones que necesitan una garantía que un paquete no llegará más tarde que un cierto tiempo después de que fue transmitido por su fuente. Por ejemplo, algunas aplicaciones de repetición de audio y de vídeo son intolerantes de un paquete que llega después de su tiempo de repetición esperado. Las aplicaciones que tienen exigencias de tiempo real también pueden usar el servicio garantizado. El ratio es medido en bytes de datagramas IP por segundo, y puede extenderse de 1 byte por segundo a tan grande como 40 TB por segundo (el ancho de banda teórica máxima de solo un hilo de fibra). El tamaño del paquete puede extenderse de 1 byte a 250 GB. El rango de valores es intencionadamente grande para tener en cuenta futurasMarcos Huerta S. 51
  35. 35. Metodología Top Down anchos de banda. El rango no intenta implicar tanto a un nodo de red tiene que soportar el rango de la red entera. La expectativa del grupo de funcionamiento de Servicios Integrado consiste en que un revelador de software puede usar RFCs relevante para desarrollar aplicaciones inteligentes que pueden poner exactamente el ratio de paquete y el tamaño. Una aplicación por lo general puede estimar exactamente la tardanza esperada que hace cola que el servicio garantizado proporcionará. Si la tardanza es más grande que esperado, la aplicación puede modificar su paquete simbólico para conseguir una tardanza inferior. Como un diseñador de red, no le visitarán generalmente para estimar ratios de paquete simbólico y tamaños. Por otra parte, usted debería reconocer qué necesidad de aplicaciones garantizada el servicio y tienen alguna idea de su comportamiento de falta y si una reconfiguración del comportamiento de falta es posible. Si una aplicación puede solicitar el ancho de banda de terabytes por segundo, usted tiene que saber este debido al efecto negativo que esto podría tener en otras aplicaciones. Documentación Requerimientos de QoS Usted debería trabajar con su cliente para clasificar cada aplicación de red en una categoría de servicio. Una vez que usted ha clasificado la aplicación, usted debería rellenar "la columna" de Requerimientos de QoS en la Tabla Nro. 07 Si su cliente tiene aplicaciones que pueden ser caracterizadas como necesitando la controla-carga o el servicio garantizado, usted puede usar aquellos términos rellenando "la columna" de Requerimientos de QoS. Si su cliente planea usar el ATM, usted puede usar la terminología del Foro de ATM para categorías de servicio. Incluso si su cliente no planea usar el ATM o IETF QoS, usted todavía puede usar el Foro de ATM o la terminología de grupo de funcionamiento de Servicios Integrada. Otra alternativa debe usar simplemente los términos inflexible y flexible. Inflexible es una palabra genérica para describir cualquier aplicación que tiene exigencias específicas para ancho de banda constante, tardanza, variación de tardanza, exactitud, y rendimiento. Flexible, por otra parte, es un término genérico para aplicaciones que simplemente esperan que la red haga el un mejor esfuerzo para encontrar los requerimientos. Muchas aplicaciones no multimedia tienen requerimientos de QoS flexibles. Para aplicaciones de voz, usted debería hacer más de una entrada en Tabla Nro. 07 debido a los requerimientos diferentes de flujo de control de llamada y la corriente de audio. El flujo de control de llamada, se usa para establecer llamadas perdidas, no tiene coacciones de tardanza estrictas, pero esto requiere una alta disponibilidad de red yMarcos Huerta S. 52
  36. 36. Metodología Top Down puede haber un requerimiento GoS que debería ser especificada. Para la corriente de voz, la clasificación QoS debería ser puesta en una lista usando el término de ATM o el término de IETF servicio garantizado. Resumen de Identificando objetivos y necesidades del cliente En este punto en el proceso de diseño de red, usted ha identificado las aplicaciones de red de un cliente y los requerimientos técnicas para un diseño de red que puede apoyar las aplicaciones. Este resume, "Identificando las Necesidades de Su Cliente y Objetivos." La Fase de análisis de requerimientos es la fase más importante en el diseño red de la metodología top down. La ganancia de un entendimiento sólido de los requerimientos de su cliente le ayuda a seleccionar tecnologías que encuentran los criterios de un cliente para el éxito. Usted debería ser capaz ahora de analizar los objetivos comerciales y técnicos de un cliente y estar listo a comenzar a desarrollar un diseño de red lógico y físico. "Diseño de Red Lógico," que diseñan una topología de red lógica, desarrollando el direccionamiento de capa de red y nombramiento del modelo, selección de switches y de protocolos de enrutamiento, y planificación de seguridad de red y estrategias de dirección.Fase II: Diseño de una Red Lógica Parte 5. Diseño de una topología de red En este capítulo, usted aprenderá técnicas para desarrollar una topología de red. A topología es un mapa de la red que indican segmentos de red, puntos de interconexión, y comunidades de usuario. Además los sitios geográficos puedan aparecer en el mapa, el objetivo del mapa es mostrar la geometría de la red, no la geografía física o implementación técnica. El mapa es una vista panorámica del alto nivel de la red, análoga a un dibujo arquitectónico que muestra la posición y el tamaño de cuartos para un edificio, pero no los materiales de construcción para fabricar los cuartos. El diseño de una topología de red es el primer paso en la fase de diseño lógica de la metodología de diseño de red Top Down. Para encontrar los objetivos de un cliente para escalabilidad y adaptabilidad, es importante para el arquitecto una topología lógica antes de seleccionar productos físicos o tecnologías. Durante la fase de diseño de topología, usted identifica redes y puntos de interconexión, el tamaño y alcance de redes, y los tipos de dispositivos de funcionamiento entre redes que serán requeridos, pero no los dispositivos actuales.Marcos Huerta S. 53

×