2. Metodología Top Down - español.pdf

Metodología Top Down

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

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

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

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

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

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

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

Marcos Huerta S.

18


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

Fase I: Identificando objetivos y necesidades del cliente Parte 1. Análisis de los objetivos y limitaciones del negocio Los objetivos y limitaciones incluyen la capacidad de correr las aplicaciones de red que reune los objetivos comerciales corporativos, y la necesidad de trabajar dentro de restricciones comerciales, como paquete, personal limitado que esta conectado a una red, y márgenes de tiempo cortos.

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

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

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

Si usted tiene en mente cambios de estrategias comerciales y gestión de redes de empresa discutido en las secciones anteriores, se hace posible poner una lista de los objetivos comerciales en el diseño de alguna red típica: Ø

Aumento de ingresos y ganancia.

Ø

Aumento de Cuota de mercado.

Ø

Expansión de nuevos mercados.

Ø

Aumente ventajas competitivas sobre compañías en el mismo mercado.

Ø

Reduzca gastos.

Ø

Aumente la productividad de empleado.

Ø

Acorte ciclos de desarrollo de producto.

Ø

Use la fabricación justo a tiempo.

Ø

Plan alrededor de escaseces componentes.

Ø

Ofrezca nuevos servicios de cliente.

Ø

Ofrezca el mejor soporte de cliente.

Marcos Huerta S.

19


Ø

Abra la red a componentes claves (perspectivas, inversionistas, clientes, socios de negocio, proveedores, y empleados).

Ø

Construya relaciones y accesibilidad de información a un nuevo nivel, como una base para un modelo organizacional de red.

Ø

Evite la interrupción comercial causada por problemas de seguridad de red.

Ø

Evite la interrupción comercial causada por desastres naturales y poco naturales.

Ø

Modernice tecnologías anticuadas.

Ø

Reduzca los gastos de telecomunicaciones y red , incluso elevado asociado con redes separadas para voz, datos, y vídeo

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

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

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

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

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

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

Marcos Huerta S.

20


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

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

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

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

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

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

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

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

Marcos Huerta S.

21


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

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

Administración de funcionamiento. Analizar el tráfico y el comportamiento de aplicación para optimizar una red, quedar en acuerdos de nivel de servicio, y el plan para la extensión

•

Administración de defecto. Descubrir, aislar y corregir de problemas; reportando los problemas a usuarios finales y gerentes.

•

Administración de configuración. Control, funcionamiento, identificación, y recolectar datos de dispositivos de administración

•

Administración de Seguridad. Supervisión y pruebas de seguridad y política de protección, manteniendo y distribuyendo contraseñas y otra autenticación e información de autorización, llaves de cifrado directivas, y adhesión de revisión a política de seguridad.

•

Administración de la contabilidad. Contabilizar el uso de la red para asignar gastos para conectar una red a usuarios y/o plan para cambios de exigencias de capacidad

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

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

Marcos Huerta S.

22


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

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

Visio Corporations.

Ø

Visio Profesional.

Ø

Visio Profesional Ships.

Algunas compañías ofrecen esquematizar automáticamente el descubrimiento de la red existente, usando el siguiente software: Ø

Pinpoint Software’s ClickNet Professional.

Ø

NetSuite Development.

Ø

Net Suite Advanced Professional Design.

Ø

NetSuite Professional Audit (similar ClickNet).

¿Que debería Incluir en un Mapa de Red? Usando las herramientas mencionadas deberá desarrollar un mapa de red en la cual deberá contener lo siguiente: Ø

Conexiones WAN entre países y ciudades.

Ø

Edificios y pisos, y posibilidades cuartos y casetas.

Ø

Conexiones WAN y LAN entre edificios y entre campos.

Ø

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

Ø

El Número de servicios proveedor de WANS.

Ø

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

Ø

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

Ø

La localización de las principales estructuras.

Ø

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

Ø

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

Ø

La topología de algunos sistemas de seguridad Firewall.

Ø

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

Ø

Algunas indicaciones de donde residen algunas estaciones de trabajo, aunque no necesariamente la localización explicita de cada estación de trabajo.

Marcos Huerta S.

23


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

Usted tiene que investigar el direccionamiento de la capa de red que usa, el esquema de direccionamiento que usa su cliente puede influenciar en la habilidad de adaptar su nuevo diseño de red a los objetivos, aquí definirá el mejor método de direccionamiento que se pueda usar para su diseño de red. Entre los cuales tenemos: Ø

Subnetting.

Ø

Variable Lenght Subnet Masking (VLSM).

Ø

Supernetting o Aggregations.

Ø

Summarization.

Estos métodos se explicaran más adelante cuando se seleccione el protocolo y direccionamiento de red.

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

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

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

Probablemente la instalación entre los edificios es unos de los sgtes: Ø

Single –mode fiber

Ø

Multi –mode fiber

Ø

Shielded twisted pair (STP)

Ø

UTP categoría 5

Ø

Cable coaxial

Ø

Microondas

Ø

Radiofrecuencia.

Ø

Láser

Ø

Infrarrojo

Marcos Huerta S.

24


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

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

Cuando construya preste atención a la arquitectura si este afecta la implementación de su diseño, este seguro que la arquitectura puede soportar el diseño tales como: Ø

Aire acondicionado.

Ø

Calefacción.

Ø

Ventilación.

Ø

Protección de interferencias electromagnéticas.

Ø

Puertas que no estén cerradas, etc.

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

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

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

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

Los problemas de la red no son usualmente causados

por los envíos de malas

estructuras de tramas. En el caso token ring (La red Token-Ring es una implementación del standard IEEE 802.5, en el cual se distingue más por su método de transmitir la

Marcos Huerta S.

25


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

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

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

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

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

Tabla Nro. 01 Caracterizar la Disponibilidad de la Red

Marcos Huerta S.

26


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

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

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

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

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

Marcos Huerta S.

27


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

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

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

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

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

Marcos Huerta S.

28


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

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

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

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

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

Por otra parte, el aumento del MTU es a veces necesario en interfaces del router de aquellos que usan

túneles. Los problemas pueden ocurrir cuando una cabecera

suplementario es añadido por el túnel hace que el paquete sean más grandes que falta MTU. Un síntoma típico de este problema es que los usuarios pueden ping y Telnet, pero no usar el Protocolo de Transferencia de Hipertexto (HTTP), FTP, y otros protocolos que usan los paquetes grandes. Una solución es aumentar el MTU en el interfaz del router.

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

Marcos Huerta S.

29


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

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

Tabla Nro. 03 Medida del Tiempo de Respuesta

Marcos Huerta S.

30


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

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

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

El la sección anterior se habló de la caracterización de la red existente en términos de su estructura e interpretación. Como el análisis de la situación existente es un paso importante en un acercamiento de análisis de sistemas para diseñar, este sección se habla de la caracterización de la red existente en términos de flujo de tráfico. Esta sección también cubre nuevas exigencias de diseño de red, añadiendo los dos primeras secciones que cubrieron objetivos de diseño comerciales y técnicos. Esta sección reenfoca en exigencias de diseño y describe exigencias en términos de flujo de tráfico, carga, y comportamiento; y calidad de servicio (QoS) exigencias. Caracterizando el Flujo de Trafico La caracterización del flujo de tráfico implica identificar fuentes y destinos del tráfico de red y analizar la dirección y la simetría de datos que viajan entre fuentes y destinos. En algunas aplicaciones, el flujo es bidireccional y simétrico. (Ambos finales del flujo envían el tráfico en aproximadamente el mismo precio.) En otras aplicaciones, el flujo es bidireccional y asimétrico. Las estaciones de cliente envían pequeñas preguntas y los servidores envían grandes corrientes de datos. Los broadcast de una aplicación, el flujo es unidireccional y asimétrico. Esta sección habla de la caracterización de la dirección y

Marcos Huerta S.

31


la simetría del flujo de tráfico en una red existente y análisis del flujo para nuevas aplicaciones de red. La Identificación de las Principales Fuentes de Tráfico y Almacenamiento Para entender el flujo de tráfico de red, usted debería identificar primero comunidades de usuario y almacenamiento de datos para las aplicaciones existentes.

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

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

Tabla Nro. 04 Comunidades de Usuarios

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

Marcos Huerta S.

32


Tabla Nro. 05 Formulario de Almacenamiento de Datos

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

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

La medición del comportamiento de flujo de tráfico puede ayudar a un diseñador de red a determinar qué trafico de routers deberían ser peer en los protocolos de encaminamiento que usan un sistema peering, como el Border Gateway Protocol (BGP). La medición del comportamiento de flujo de tráfico también puede ayudar a los diseñadores de la red y debran hacer lo siguiente: •

Caracterice el comportamiento de redes existentes.

•

Plan de desarrollo y extensión de la red.

•

Cuantifique la performance de la red.

•

Verifice la calidad del servicio de red.

•

Asigne el uso de aplicaciones y usuarios de la red .

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

Marcos Huerta S.

33


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

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

Para conseguir la información para llenar los formularios, coloque un dispositivo que monitoree

el core de la red y déjele coleccionar datos por uno o dos días. Para

conseguir la información para llenar la columna de Path, usted puede encender la opción de grabar-ruta de registro en una red de IP. La opción de ruta de registro tiene algunas desventajas, sin embargo. Esto no apoya redes muy grandes y es a menudo minusválido para razones de seguridad. Usted también puede estimar el path mirando la tabla de encaminamiento y análizando el tráfico de red en multiples segmentos.

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

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

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

Marcos Huerta S.

34


•

Flujo de tráfico de terminal/host.

•

Flujo de tráfico de cliente/servidor.

•

Flujo de tráfico Punto a Punto.

•

Flujo de tráfico de servidor/servidor.

•

Flujo de tráfico de cálculo distribuido.

En su libro “Análisis de Red, Arquitectura, y Diseño”, Segunda Edición, James D. McCabe hace un trabajo excelente de caracterización de los distintos modelos de flujo. Flujo de Tráfico de Terminal/host El tráfico de terminal/host es por lo general asimétrico. El terminal envía unos caracteres y el host envía muchos caracteres. El Telnet es un ejemplo de una aplicación que genera el tráfico de terminal/host. Por defecto detrás de Telnet consiste en que el terminal envía un simple paquete cada vez que el usuario escribe un carácter. El host devuelve caracteres múltiples, según lo que el usuario escribió. Como una ilustración, considere el principio de una sesión Telnet que comienza con el usuario que escribe su nombre. Una vez que el host recibe cada paquete para los caracteres del nombre, el host devuelve un paquete de mensaje de regreso (como la Contraseña Requerida).

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

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

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

35


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

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

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

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

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

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

Marcos Huerta S.

36


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

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

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

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

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

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

Marcos Huerta S.

37


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

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

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

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

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

Marcos Huerta S.

38


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

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

En general, para contar si la capacidad es suficiente, sólo unos parámetros son necesarios: •

El número de estaciones.

•

El tiempo medio que una estación es ociosa entre el envío de paquetes.

•

El tiempo requerido transmitir un mensaje una vez el acceso medio es ganado.

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

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

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

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

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

Marcos Huerta S.

39


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

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

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

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

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

Además de la identificación del número total de usuarios para cada aplicación, usted también debería documentar la información siguiente: •

La frecuencia de sesiones de aplicación (el número de sesiones por día, semana, mes o independientemente del período de tiempo es apropiado).

•

La longitud de una sesión de aplicación media.

•

El número de usuarios simultáneo de una aplicación.

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

Marcos Huerta S.

40


banda agregada para todos los usuarios de una aplicación. Si no es práctico investigar estos detalles, usted puede hacer algunas conclusiones: •

Usted puede asumir que el número de usuarios de una aplicación es igual al número de usuarios simultáneos.

•

Usted puede asumir que todas las aplicaciones son usadas todo el tiempo de modo que su cálculo de ancho de banda sea un caso pico de estimación (máxima).

•

Usted puede asumir que cada usuario abre sólo una sesión y que una sesión dura todo el día hasta que el usuario cierre la aplicación al final de día.

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

Como las aplicaciones y los usuarios varían extensamente en el comportamiento, es difícil estimar exactamente el tamaño medio de objetos de datos que los usuarios transfieren el uno al otro y a servidores. (La respuesta de ingeniería verdadera a la mayor parte de preguntas relacionadas para conectar a la red tráfico es "esto depende.") el cuadro siguiente

proporciona algunas estimaciones para tamaños de objeto que

usted puede usar haciendo cálculos atrás de la carga de tráfico de aplicación, pero recordar que el cuadro proporcionado no toma el lugar de un análisis cuidadoso del comportamiento de aplicación actual.

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

Marcos Huerta S.

41


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

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

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

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

Marcos Huerta S.

42


cantidad de ancho de banda usada por herencia de protocolos de enrutamiento vectordistancia. Tabla Nro. 10 Ancho de banda Usada por Herencia de Protocolos de enrutamiento

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

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

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

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

Marcos Huerta S.

43


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

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

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

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

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

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

Marcos Huerta S.

44


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

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

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

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

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

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

Marcos Huerta S.

45


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

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

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

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

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

Algunas aplicaciones TCP/IP corren encima de UDP, y no TCP. En este caso, no hay ningún control de flujo o el control de flujo es manejado en la sesión o capa de aplicación. Mostramos una lista para determinar qué protocolos están basados en TCP y qué protocolos están basados en UDP: •

Protocolo de transferencia de archivos (FTP): Puerto de TCP 20 (datos) y puerto TCP 21 (control).

•

Telnet: Puerto de TCP 23.

•

Protocolo de Transferencia Postal Simple (SMTP): Puerto de TCP 25.

Marcos Huerta S.

46


•

Protocolo de Transferencia de Hipertexto (HTTP): Puerto de TCP 80.

•

Protocolo de Dirección de Red Simple (SNMP): Puertos de UDP 161 y 162.

•

Sistema de Nombre de Esfera (DNS): Puerto de UDP 53.

•

Protocolo de Transferencia de Archivos Trivial (TFTP): Puerto de UDP 69.

•

Servidor de DHCP: Puerto de UDP 67.

•

Cliente de DHCP: Puerto de UDP 68.

•

Llamada de Procedimiento Remota (RPC): Puerto de UDP 111

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

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

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

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

innecesariamente

segmentos

que

el

recipiente

puede

haber

recibido

correctamente.

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

Marcos Huerta S.

47


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

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

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

La voz es también inflexible en cuanto a la tardanza. La voz es también sensible a la pérdida de paquete, que resulta en recorte de periódico de voz y se salta. Sin la configuración apropiada en toda la red de

QoS, la pérdida puede ocurrir debido a

enlaces congestionados y un pobre buffer de paquetes y manejo de dirección de cola en los routers.

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

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

Marcos Huerta S.

48


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

El Foro de ATM define seis categorías de servicio, cada uno de las cuales es descrito más detalladamente en esta sección: •

Velocidad binaria constante (CBR)

•

Velocidad binaria variable de tiempo real (rt-VBR)

•

Velocidad binaria variable no tiempo real (nrt-VBR)

•

Velocidad binaria no especificada (UBR)

•

Velocidad binaria disponible (ABR)

•

Precio de marco garantizado (GFR)

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

Las categorías de servicio son distinguidas al comienzo siendo tiempo real o tiempo no real. El CBR y rt-VBR son categorías de servicio de tiempo real. Las aplicaciones de tiempo real, como voz y aplicaciones de vídeo, requieren la variación de tardanza y tardanza

fuertemente

obligada.

Las

aplicaciones

en

tiempo

no

real,

como

cliente/servidor y aplicaciones de datos de terminal/host, no requieren la tardanza fuertemente obligada y retrasan la variación. El Nrt-VBR, UBR, ABR, y GFR son categorías de servicio tiempo no real.

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

Marcos Huerta S.

49


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

de

parámetros

de

celdas

máxima

(maxCTD)

son

del

valor

considerablemente reducido a la aplicación.

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

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

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

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

Asumiendo que la red funciona correctamente, un servicio de control-carga esta solicitando de la aplicación puede asumir lo siguiente: •

Un alto porcentaje de paquetes transmitidos será recepcionados con éxito al final de los nodos de la red. (El porcentaje de paquetes que no es entregado con éxito debe aproximarse al índice de errores de paquete básico del medio de transmisión.)

•

La tardanza de tránsito experimentada por un porcentaje muy alto de los paquetes entregados no excederá el mínimo transmitido en la tardanza experimentada por cualquier paquete con éxito entregado. (Esta tardanza de tránsito mínima incluye la tardanza de velocidad de luz más el tiempo de procesamiento fijo en routers y otros dispositivos de comunicaciones a lo largo del camino.)

Marcos Huerta S.

50


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

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

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

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

componentes de red o cambios de la

encaminamiento durante la vida del flujo).

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

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

Marcos Huerta S.

51


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

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

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

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

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

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

Marcos Huerta S.

52


puede haber un requerimiento GoS que debería ser especificada. Para la corriente de voz, la clasificación QoS debería ser puesta en una lista usando el término de ATM o el término de IETF servicio garantizado. Resumen de Identificando objetivos y necesidades del cliente En este punto en el proceso de diseño de red, usted ha identificado las aplicaciones de red de un cliente y los requerimientos técnicas para un diseño de red que puede apoyar las aplicaciones.

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

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

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

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

Marcos Huerta S.

53


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

la Seguridad de Red.") Este capítulo

también cubre el Modelo de Red Empresarial Compuesta, que es la parte de la Arquitectura Segura Empresarial de Cisco (SAFE).

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

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

Figura Nro. 11. Topología Jerárquica

Una topología jerárquica típica esta dividida por tres capas: •

Una Capa Core de routers y switches de alta velocidad que son optimizados para disponibilidad e performance.

•

Una Capa de distribución routers y switches para la implementación de políticas.

Marcos Huerta S.

54


•

Una Capa de Acceso que une en la parte inferior a usuarios vía switches y puntos de acceso inalámbricos.

¿Por qué Usar un Modelo de Diseño de Red Jerárquico? Las redes crecen desatendidas sin ningún plan y tienden a desarrollarse en un formato no estructurado. Doctor Peter Welcher, el autor de diseño de redes y artículos de tecnología para el Mundo de Cisco y otras publicaciones, se refiere a redes inesperadas como redes de pelota-piel.

Welcher explica las desventajas de una topología de pelota-piel indicando los problemas que demasiadas adyacencias de CPU causan. Cuando los dispositivos de red se comunican con muchos otros dispositivos, la carga de trabajo requerida de las CPUs en los dispositivos puede ser pesada. Por ejemplo, en un apartamento grande (Switched) la red, los paquetes de broadcast son pesados. Un paquete de broadcast interrumpe la CPU en cada dispositivo dentro del dominio de broadcast, y demanda procesamiento de tiempo en cada dispositivo para el cual un protocolo que entiende para aquellos broadcast instalado. Este incluye routers, estaciones de trabajo, y servidores.

Otro problema potencial con redes no jerárquicas, además de los paquetes de broadcast, es la carga de trabajo de CPU requerida para los routers para comunicarse con muchos otros routers y tratar la numerosa publicación de ruta. Una metodología de diseño de red jerárquica le deja diseñar una topología modular que limita el número de routers que se comunican.

La utilización de un modelo jerárquico puede ayudarle a minimizar gastos. Usted puede comprar los dispositivos apropiados de funcionamiento entre redes para cada capa jerárquica, así evitando gastos de dinero en características innecesarios para una capa. También, la naturaleza modular del modelo de diseño jerárquico permite la planificación de capacidad exacta de cada capa jerárquica, logrando reducir el ancho de banda perdido innecesariamente. La responsabilidad del manejo de los sistemas de la red pueden ser distribuidos a las diferentes capas de una arquitectura de red modular para controlar gastos de dirección.

La modularidad le deja guardar cada elemento de diseño simple y fácil de entender. La simplicidad minimiza la necesidad de la formación extensa para el personal de operaciones de red y acelera la realización de un diseño. Las pruebas de un diseño de red son hechas fáciles porque hay funcionalidad clara en cada capa. El aislamiento de fallas es mejorado porque los técnicos de red pueden reconocer fácilmente los puntos de transición en la red y le ayudara a aislar puntos de fallas posibles.

Marcos Huerta S.

55


El diseño jerárquico facilita cambios. Cuando los elementos en una red requieren el cambio, el coste de hacer una mejora está contenido a un pequeño subconjunto de la red total. En cambio las grandes arquitecturas de red, los cambios tienden a afectar un número grande de sistemas. La sustitución de un dispositivo puede afectar numerosas redes debido a las interconexiones complejas.

¿Cómo puede Usted Contar Cuando Usted Tiene un Diseño Bueno? Aquí están algunas respuestas sabias de Peter Welcher que están basadas en los principios del diseño de red jerárquico, modular: •

Cuando usted ya sabe añadir un nuevo edificio, piso, enlaces WAN, sitio remoto, servicio de e-comercio, etcétera.

•

Cuando las nuevas adiciones causan el cambio local solo a los dispositivos directamente relacionados.

•

Cuando su red puede doblarse o triplicarse en el tamaño sin cambios de diseño principales.

•

Cuando los problemas es fácil porque no hay ningunas interacciones de complejos protocolo.

Topología Plana Contra Jerárquicas Una topología de red plana es adecuada para redes muy pequeñas. Con un diseño de red plano, no hay ninguna jerarquía. Cada dispositivo de la red tiene esencialmente el mismo trabajo, y la red no es dividida en capas o módulos. Una topología de red plana es fácil para diseñar, de implementar y mantener, mientras permanezca como una red pequeña. Cuando la red crece, sin embargo, una red plana es indeseable. La carencia de jerarquía hace los problemas más difícil. En vez de ser capaz de concentrar esfuerzos para la solución del problema en una sola una área de la red, usted puede tener que inspeccionar la red entera.

Topología WAN Plana Una red de área amplia (WAN) para una pequeña compañía puede consistir en unos sitios conectados en un loop. Cada sitio tiene un router WAN que se une a otros dos sitios adyacentes vía enlaces de punto a punto, como es mostrado en la figura nro. 12. Mientras la WAN es pequeño (en sitios pequeños), los

protocolos de enrutamiento

puede convergir rápidamente, y la comunicación con cualquier otro sitio puede recuperarse cuando un enlaces falla. (Mientras sólo un enlaces falla, la comunicación se recupera. Cuando más de un enlaces falla, algunos sitios son aislados de otros.)

Marcos Huerta S.

56


Figura Nro. 12

Figura Nro. 13. Topología Redundante Jerárquica

Una topología de loop plana no es generalmente recomendada para redes con muchos sitios, sin embargo. Una topología de loop plana puede significar que hay muchos saltos entre routers en lados opuestos del loop, causando la tardanza significativa y una alta probabilidad de fracaso. Si su análisis del flujo de tráfico indica que los routers en los lados opuestos de una topología de loop cambian mucho el tráfico, usted debería recomendar una topología jerárquica en vez de una de loop. Para evitar cualquier punto falle, los routers redundantes o los switches pueden ser colocados en capas superiores de la jerarquía, como mostrado en la figura 12.

La topología de loop plana mostrada en la figura 12 encuentra objetivos para bajos de costo y disponibilidad razonablemente buena. La topología redundante jerárquica mostrada en la figura 13 encuentra objetivos para escalabilidad, disponibilidad alta, y bajo retardo.

Topologías de LAN Plana A principios de los años 1990, un típico diseño para un LAN era ordenadores personales y servidores atados a uno o varios hub en una topología plana. Los ordenadores

Marcos Huerta S.

57


personales y los servidores se implemento un proceso de control de acceso de medios, como pasó de token o Acceso Múltiple con Escucha de Portadora y Detección de Colisiones (CSMA/CD) para control de acceso al ancho de banda compartida. Los dispositivos eran todo parte del mismo dominio de ancho de banda y tenían la habilidad de afectar negativamente la tardanza y el rendimiento para otros dispositivos.

En estos días, los diseñadores de red recomiendan conectar ordenadores personales y servidores a la capa de enlace de datos (Capa 2) switches en vez de hubs. En este caso, la red es segmentada en pequeñas dominios de ancho de banda de modo que un número limitado de dispositivos compita por el ancho de banda en cualquier tiempo. (Sin embargo, los dispositivos compiten realmente por el servicio de conmutación

de

hardware y software, entonces es importante entender las características de performance de los candidato del switches, como se habla en El capítulo 10, "Seleccionando Tecnologías y Dispositivos para Redes de Campus.")

Como se ha discutido en el capítulo 4, "Caracterizando el Tráfico de Red," los dispositivos switches o bridge conectados en una red son la parte del misma dominio de broadcast. Los switches expiden paquetes de broadcast a todos los puertos. Los routers, por otra parte, segmentan redes en dominios de broadcast separados. Un documentado en la Tabla 4-8, un simple dominio de broadcast solo debería ser limitado con unos cientos de dispositivos de modo que los dispositivos no sean abrumados por la tarea de tratar el tráfico de broadcast. Introduciendo la jerarquía en un diseño de red añadiendo routers, la radiación de broadcast es reducida.

Con un diseño jerárquico, los dispositivos de redes pueden ser desplegados para hacer el trabajo que ellos hacen mejor. Los routers pueden ser añadidos a un diseño de red de campus para aislar el tráfico de broadcast. Los switches de alta capacidad se pueden desplegar para maximizar el ancho de banda para aplicaciones de tráfico alto, y los switches finales de baja capacidad se pueden usar cuando, el acceso barato es requerido. Maximizar la performance total por modularización las tareas requeridas de los dispositivos de red es una de las muchas ventajas de usar un modelo de diseño jerárquico.

Topología Malla Contra Malla Jerárquica Los diseñadores de red a menudo recomiendan a una topología de malla por encontrar requerimientos de disponibilidad. En la topología de malla completa, cada routers o o switch están conectados con otro routers

o switch. Una red de malla completa

proporciona redundancia completa, y ofrece una buena performance porque solo hay una tardanza de un simple enlaces entre dos sitio cualquiera. A red de malla parcial

Marcos Huerta S.

58


tiene menos conexiones. Alcanzar otro router o switch en una red de malla parcial podría requerir enlaces intermedios que cruzar, como mostrado en la figura 14 Figura Nro. 14

En una topología de malla completa, cada router o switch está conectado otro routers o switch. El número de enlaces en una topología de malla completa es como sigue: (N * (N – 1)) / 2 El N es el número de routers o switches.

Aunque las redes de malla presenten una buena fiabilidad, ellos tienen muchas desventajas si ellos no son diseñados con cuidado. Las redes de malla pueden ser caras de desplegar y mantener. (Una red de malla completa es sobre todo cara.) las redes de Malla también pueden ser difíciles de optimizar, resolver fallas, y actualizar, a menos que ellos sean diseñados usando un modelo simple, jerárquico. En una topología de malla no jerárquica, los dispositivos de redes no son optimizados para funciones específicas. Contener problemas de red es difícil debido a la carencia de modularidad. Las mejoras de red son problemáticas porque es difícil mejorar sólo una parte de una red.

Las redes de malla tienen límites de escalabilidad para grupos de routers que transmiten encaminamiento de broadcast o publicación de servicio. Como el número de CPU de routers aumenta las adyacencias, la cantidad de ancho de banda y recursos de CPU dedicados a procesamiento de actualizaciones también aumenta.

Una buena regla básica es que usted debería aplicar es el tráfico de broadcast este en menos del 20 % en cada enlace. Esta regla limita el número de routers adyacentes que pueden cambiar las tablas de encaminamiento y publicación de servicio. Esta limitación no es un problema, sin embargo, si usted sigue las pautas para el diseño jerárquico. Un diseño jerárquico, en su misma naturaleza, limita el número de adyacencias de routers.

Marcos Huerta S.

59


Con los protocolos de encaminamiento, como OSPF y EIGRP, el problema no es con el tráfico de broadcast/multicast y recursos de CPU usados para el encaminamiento cotidiano.

El problema es la cantidad de trabajo y ancho de banda requerida restablecer el encaminamiento después de una interrupción. Procure no dejar a su red convertirse en una malla complicada sólo porque esta todavía trabaja. Habrá probablemente una interrupción un día y luego usted puede aprender el camino mas difícil de perdiciones asociadas con

La figura 14 muestra un diseño empresarial clásico jerárquico y redundante. El diseño usa una jerarquía de malla parcial más bien que una malla completa. La figura muestra una red de router empresarial, pero la topología podría ser usada para switches de campus de red también.

Figura Nro. 15. Diseño de una Red Parcial Jerárquica

Para compañías de tamaño medio y pequeñas, el modelo jerárquico a menudo es implementado como a la topología "hub y spoke" con poco o ningún malla. La oficina central corporativa o un centro de datos forman el hub. Los enlacess a oficinas remotas y casas de las telecomunicaciones forman el spokes como se muestra en la figura 16.

Marcos Huerta S.

60


Figura Nro. 16 Hub y Spoke para Compañías Medianas y Pequeñas

El Clásico Modelo Jerárquico de Tres Capas La literatura publicada por el Cisco Systems, Inc habla de un clásico modelo jerárquico de tres capas para topologías de diseño de red. El modelo de tres capas permite la agregación de tráfico y filtrando en tres encaminamiento sucesivo o conmutación de niveles. Este hace el modelo jerárquico de tres capas escalable a redes internacionales grandes.

Aunque el modelo fuera desarrollado a la vez cuando los routers delinearon capas, el modelo puede ser usado para redes conmutadas así como redes ruteadas. Las topologías jerárquicas de tres capas son mostradas en la figura 12 y La figura 15. Cada capa del modelo jerárquico tiene un papel específico. La capa core proporciona el transporte óptimo entre sitios. La capa de distribución conecta servicios de red a la capa de acceso, y implementa políticas de seguridad, carga de tráfico, y encaminamiento. En un diseño WAN, la capa de acceso consiste en routers de borde de las redes de campus. En una red de campus, la capa de acceso proporciona switches o hubs para el acceso de usuario final

La Capa Core El capa core de una topología jerárquica de tres capas es la columna vertebral rápida de las redes. Como la capa core es crítica para la interconectividad, usted debería diseñar la capa core con componentes redundantes. La capa core debería ser muy confiable y debería adaptarse a cambios rápidamente.

Marcos Huerta S.

61


Cuando Configure routers en la capa core, usted debería usar características de encaminamiento que optimicen el rendimiento del paquete. Usted debería evitar usar filtros de paquete u otra característica que hacen más lenta la manipulación de paquetes. Usted debería optimizar el core durante la baja latencia y buena manejabilidad.

El core debería tener un diámetro limitado y consistente. Los routers de tráfico de capa de distribución (o switches) y clientes LANs

pueden ser añadidos al modelo sin

aumentar el diámetro del core. La limitación del diámetro del core proporciona un previsible performance y la facilidad de la solución de problemas.

Para clientes que tienen que conectarse a otras empresas vía un extranet o el Internet, la topología core debería incluir uno o varios enlacess a las redes externas. Los administradores

de

red

corporativos

deberían

desplegarse

regionalmente

y

administradores de oficinas sucursales de planear su propio extranets o conexiones al Internet. La centralización de estas funciones en la capa core reduce la complejidad y el potencial para lo problemas de enrutamiento, y es esencial reducir al mínimo lo que concierne a seguridad.

La introducción de enlacess de socio de negocio con la sucursal donde la colaboración ocurre puede parecer lógica, pero esto significa que usted tiene que permitir el tráfico del compañero en la sucursal, pero no más allá de lo necesario. Con el tiempo, usted terminará con una mezcolanza de listas de control de acceso distribuidas y firewalls, que complica la aplicación de política. Esto también es enormemente alto en gastos si usted desea usar sistemas de detección de intrusión (IDSs) y otras tecnologías de seguridad.

Del mismo modo, algunas oficinas remotas con IPSec conectividad de VPN cambian lejos del acceso en los sitios remotos donde los usuarios tienen el acceso local a Internet además del acceso de IPSec remoto a la oficina central corporativa. A pesar del gasto de ancho de banda, obligando todo el acceso externo a pasar por el core de los medios de red que tienen sólo una seguridad estructurada para administrar, que es un modo bueno de evitar problemas de seguridad.

La Capa de Distribución La capa de distribución de la red es el punto de demarcación entre el acceso y las capas core de la red. La capa de distribución tiene muchos roles, incluso el control del acceso a recursos por razones de seguridad, y control del tráfico de red que cruza el core por motivos de performance. La capa de distribución es a menudo la capa que delinea el dominio de broadcast, (aunque este pueda ser hecho en la capa de acceso también). En

Marcos Huerta S.

62


diseños de red que incluyen LANs virtuales (VLANs), la capa de distribución puede ser configurada para rutear entre VLANs.

La capa de distribución permite que la capa core conecte los sites que corren en diferentes protocolos manteniendo un alto performance. Para mantener un buen performance en el core, la capa de distribución puede redistribuir entre la capa de acceso el intenso ancho de banda de protocolo de encaminamiento y optimizar los protocolos de encaminamiento del core. Por ejemplo, quizás un site en la capa de acceso todavía dirige un protocolo más viejo, como IGRP. La capa de distribución puede redistribuir entre IGRP en la capa de acceso e EIGRP realzado en la capa core.

Para mejorar el performance de los protocolo de enrutamiento, la capa de distribución puede sumarizarse las rutas de la capa de acceso. Para algunas redes, la capa de distribución ofrece una ruta por defecto hacia los routers de la capa de acceso y sólo corre protocolos de enrutamiento dinámicos comunicando con los routers del core.

Para maximizar la jerarquía, la modularidad, y la performance, la capa de distribución debería esconder la información de topología detallada sobre la capa de acceso de routers principales. La capa de distribución debería resumir numerosos destinos de capa de acceso en una publicación en el core. Igualmente, la capa de distribución debería esconder la información de topología detallada sobre la capa core de la capa de acceso resumiendo a una pequeño sumarización de publicaciones o sólo a una ruta por defecto de ser posible. La capa de distribución puede proveer a la capa de acceso de una ruta al router de capa de distribución más cercano que tiene el acceso al core.

La Capa de Acceso La capa de acceso proporciona a usuarios locales de segmento el acceso a las redes. La capa de acceso puede incluir routers, switches, puentes, hubs para compartirmedios, y puntos de acceso inalámbricos. Como mencionado, los switches a frecuentemente son implementado en la capa de acceso en redes de campus para dividir los dominios de ancho de banda para encontrar las demandas de aplicaciones que necesitan mucho ancho de banda o no pueden resistir la tardanza variable caracterizada por el ancho de banda compartida.

Para redes que incluyen pequeñas sucursales y corporaciones de telecomunicaciones, la capa de acceso puede proporcionar el acceso en las redes corporativas usando tecnologías de área amplia como ISDN, Frame Relay, arrendó líneas digitales, y líneas de módem análogas. Usted puede implementar características de enrutamiento, como el enrutamiento de marcado a petición (DDR) y enrutamiento estático, controlar la utilización de ancho de banda y minimizar el costo en la capa de acceso enlacess

Marcos Huerta S.

63


remotos. (DDR guarda un enlace inactivo menos cuando el tráfico especificado tiene que ser enviado.) Pautas para el Diseño de Red Jerárquico Esta sección brevemente describe algunas pautas para el diseño de red jerárquico. Después de estas pautas simples le ayudará a diseñar redes que aprovechan las ventajas del diseño jerárquico.

La primera pauta es que usted debería controlar el diámetro de una topología de red de empresa jerárquica. En la mayor parte de casos, tres capas principales son suficientes (como se mostrado en La figura 15): •

La capa core

•

La capa de distribución

•

La capa de acceso

El control del diámetro de red proporciona la latencia baja y previsible. Esto también le ayuda a predecir caminos de enrutamiento, flujos de tráfico, y requerimientos de capacidad. Un diámetro de red controlado también hace la solución y la documentación de red más fácil.

El control estricto de la topología de red en la capa de acceso debería ser mantenido. La capa de acceso es la más susceptible a violaciones de pautas de diseño de red jerárquicas. Los usuarios en la capa de acceso tienen una tendencia de añadir redes a las redes inapropiadamente. Por ejemplo, un administrador de red en una sucursal podría conectar la rama de la red a otra rama, añadiendo una cuarta capa. Este es un error de diseño de red común que es conocido como adición de una cadena. La figura 17 muestra una cadena.

Figura Nro. 17. Una Cadena y Puerta trasera en la Capa de Acceso

Marcos Huerta S.

64


Además de la evitación de cadenas, usted debería evitar puertas traseras. Las puertas traseras es una unión entre dispositivos en la misma capa, que mostrado en La figura 17. Una puerta trasera puede ser un router suplementario, puente, o switch añadido para unir dos redes. Las puertas traseras deberían ser evitadas porque ellos causan la enrutamiento inesperado y problemas de conmutación y hacen la documentación de red y la solución más difícil.

Finalmente, otra pauta para el diseño de red jerárquico es que usted debería diseñar la capa de acceso primero, seguido de la capa de distribución, y luego finalmente la capa core. Comenzando con la capa de acceso, usted puede realizar más exactamente la planificación de performance para la capa de distribución y core. Usted también puede reconocer las técnicas de optimización que usted necesitará para la capa de distribución y core.

Usted debería diseñar cada capa usando técnicas modulares y jerárquicas y luego planear las interconexiones entre capas basadas en su análisis de carga de tráfico, flujo, y comportamiento. Para entender mejor características de tráfico de red usted puede examinar los conceptos cubiertos en la Fase II. Cuando usted selecciona tecnologías para cada capa, descrito en La Fase III de, "Diseño de Red Físico," usted podría tener que volver y recordar el diseño para otras capas. Recuerde que el diseño de red es un proceso iterativo.

Topologías de Diseño de Red Redundante Los diseños de red redundantes le dejan encontrar requerimientos para la disponibilidad de red duplicando elementos en una red. La redundancia intenta eliminar cualquier simple punto que falle en la red. El objetivo es duplicar cualquier componente requerido cuya falla podría incapacitar aplicaciones críticas. El componente podría ser un router core, un switch, un enlaces entre dos switches, un unidad de canal de servicio (CSU), un suministro de energía, un enlace WAN, conectividad de Internet, etcétera.

Para permitir el negocio survivencia después de un desastre y ofrecer beneficios de performance de carga compartida, algunas organizaciones tienen centros de datos completamente

redundantes.

Otras

organizaciones

tratan

de

realizar

gastos

operacionales usando menos - el nivel completo de redundancia en la red. La redundancia puede ser implementada en redes interiores de campus individuales y entre capas del modelo jerárquico. La implementación de redundancia en redes de campus puede ayudarle a encontrar objetivos de disponibilidad para usuarios que tienen acceso a servicios locales. La Redundancia también puede ser implementada en el borde de la red de empresarial para asegurar la alta disponibilidad por Internet, extranet, y red de acceso privada virtual (VPN).

Marcos Huerta S.

65


Antes de que usted seleccione soluciones de diseño redundantes, usted debería analizar primero los objetivos comerciales y técnicos de su cliente, como hablado en Fase I de esta tesis, "La Identificación de las Necesidades de Su Cliente y Objetivos. "Asegúrese que usted puede identificar aplicaciones críticas, sistemas, dispositivos de funcionamiento entre redes, y enlacess. Analice la tolerancia de su cliente por el riesgo y las consecuencias de no implementar redundancia. Asegúrese para hablar con su cliente de las consecuencias redundancia contra bajos costos, y simplicidad contra la complejidad. La Redundancia añade la complejidad a la topología de red y direccionamiento y enrutamiento a la red.

Caminos de Reserva Para mantener la interconectividad aun cuando uno o varios enlacess están caídos, diseñamos la red redundante que incluye un camino de reserva para paquetes para viajar cuando hay problemas en el camino primario. A camino de reserva consiste en individuales routers e switches y enlacess de reserva entre routers e switches, que duplican dispositivos y enlacess en el camino primario.

Cuando estima la performance de la red para un diseño de red redundante, usted debería tener dos aspectos en cuenta del camino de reserva: •

¿Cuánta capacidad apoya el camino de reserva?

•

¿Cómo rápidamente comenzará la red a usar el camino de reserva?

Usted puede usar un instrumento que modela red para predecir la performance de la red cuando el camino de reserva está en el uso. A veces la performance es peor que el camino primario, pero todavía aceptable.

Es completamente común para un camino de reserva tener menos capacidad que un camino primario. Los enlacess de reserva individuales frecuentemente usan tecnologías diferentes. Por ejemplo, una línea arrendada puede estar en la paralela con una reserva dialup la línea o el circuito ISDN. Diseñando un camino de reserva que tiene la misma capacidad que el camino primario puede ser caro y es sólo apropiado si los requerimientos comerciales del cliente dictan un camino de reserva con las mismas características de performance que el camino primario.

Cambiando al camino de reserva requiere la reconfiguración manual de cualquier componente, entonces los usuarios notarán la interrupción. Para aplicaciones críticas de perdida, la interrupción no es probablemente aceptable. Un automático switcheo es necesario para aplicaciones críticas de perdidas. Usando diseño de redundancia, parcial

Marcos Huerta S.

66


en la red de malla parcial, usted puede automatizar el tiempo de recuperación cuando un enlace falla.

Otra consideración importante con los caminos de reserva consiste en que ellos deben ser probados. A veces los diseñadores de red desarrollan soluciones de reserva que nunca son probadas hasta que una catástrofe pase. Cuando la catástrofe ocurre, los enlacess de reserva no trabajan. En algunos diseños de red, los enlacess de reserva son usados para compartir carga que redundancia. Este tiene la ventaja que el camino de reserva es una solución probada que es con regularidad usada y supervisada como una parte de operaciones cotidianas. Hablan de la carga que comparte más detalladamente en la siguiente sección.

Carga Compartida El objetivo primario de la redundancia es encontrar los requerimientos de disponibilidad. Un segundo objetivo es mejorar la performance soportando la carga compartida a través de enlacess paralelos. La carga compartida, algunas veces llamado el equilibrio de carga, permite que dos o más interfaces o caminos compartan la carga de tráfico.

La carga compartida debe ser planeada y en algunos casos configurados. Algunos protocolos no soportan la carga compartida por defecto. Por ejemplo, cuando corre el Protocolo de Novell’s (RIP), un Intercambio de Paquete de redes (IPX) el router puede recordar sólo una ruta a una red remota. Usted puede cambiar este comportamiento en un router Cisco usando el comando ipx maximum-paths.

En ambientes ISDN, usted puede facilitar la carga compartida configurando un canal de agregación. Agregación de canal significa que un router puede brincar automáticamente ISDN múltiple B canales como el aumento de los requerimientos de ancho de banda

Diseño de Red Modular El diseño de red Top Down le deja perforar abajo a los componentes del diseño de red, y aplicar principios de diseño fundamentales a los componentes así como al diseño total. La jerarquía y redundancia, como mencionado en las secciones anteriores, son conceptos de diseño de red fundamentales.

Otro concepto fundamental relacionado con la jerarquía es la modularidad. Los proyectos de diseño de red grandes y las redes grandes en general consisten en áreas diferentes y módulos. Cada área debería ser diseñada usando un acercamiento sistemático, top down, aplicando la jerarquía y redundancia donde es apropiado. Las soluciones de red y los servicios pueden ser seleccionados en una base por módulo, pero validados como la parte del diseño de red total. Los Sistemas de Cisco usan el

Marcos Huerta S.

67


Modelo de Red de Empresarial Compuesto para describir los diferentes componentes o módulos de una red tipica Empresarial. La siguiente sección describe brevemente el modelo, que es la parte de la Arquitectura Segura de Cisco para Empresas (SAFE).

Modelo de Red Compuesto Empresarial El Modelo de Red Compuesto Empresarial es un modelo que los diseñadores de red pueden usar para simplificar la complejidad de redes grandes. El diseño del modelo le deja aplicar un acercamiento modular, jerárquico para aproximarse a la red. Con el Modelo de Red Compuesto Empresarial, usted puede analizar la funcionalidad, lógicos, y componentes físicos de una red, y así simplificar el proceso de diseñar una red de empresarial total.

El Modelo de Red Compuesto

Empresarial comprende tres áreas principales, que

pueden ser cada uno arregladas de módulos más pequeños: •

Campus de empresa. El campus de empresa incluye los módulos requeridos construir una red de campus robusta que proporciona la alta disponibilidad, la escalabilidad, y la flexibilidad. Esta área contiene todos los elementos para la operación independiente de la red dentro de una posición de campus. Una empresa puede tener más de un campus.

•

Borde de empresa. El borde de empresa agrega la conectividad de varios elementos en el borde de una red de empresa. El borde de empresa área funcional filtra el tráfico de los módulos de borde y rutas en el campus de la empresa. El borde de empresa contiene todos los elementos de red para la comunicación eficiente y segura entre el campus de empresa y localizaciones remotas, socios de negocio, usuarios móviles, y Internet.

•

Borde abastecedor de servicio. Los módulos en esta área funcional no son puestos en práctica por la empresa. Los módulos de borde abastecedor de servicio son incluidos para habilitar la comunicación con otras redes usando tecnologías WAN diferentes y Proveedores de Internet (ISPs).

Cada área del Modelo de Red Compuesto Empresarial es dividida en módulos adicionales. Por ejemplo, un área de campus puede incluir un backbone de campus, una granja de servidores, construyendo acceso y módulos de distribución, y un módulo de manejo de red. El borde de empresa puede incluir WAN, VPN, acceso de Internet, y módulos de e-comercio. Para conseguir la escalabilidad, los módulos pueden ser añadidos si es necesario. Además, los módulos pueden tener submódulos. La figura 5-7 muestra las áreas principales y módulos en el Modelo de Red Compuesto Empresarial.

Marcos Huerta S.

68


Figura Nro. 17. Modelo de Red Compuesto Empresarial

El diseño de una Topología de Diseño de Red de Campus Las topologías de diseño de red de campus deberían encontrar los objetivos de un cliente para disponibilidad e performance presentando pequeñas características de dominio de ancho de banda, pequeños dominios de broadcast, redundancia, servidores mirrow, y múltiples caminos para una estación de trabajo para alcanzar un ruta para comunicaciones off-net. Las redes de campus deberían ser diseñadas usando un acercamiento jerárquico, modular de modo que la red ofrezca una buena performance, mantenibilidad, y la escalabilidad.

La mayor característica de las redes de campus presentan un alto performance, backbone conmutados, llamada el backbone de campus, esto conecta edificios y diferentes partes del campus. Una alta capacidad, la granja de servidores centralizados se conecta al backbone y proporciona recursos de servidor internos a usuarios, por ejemplo, aplicación, archivo, impresiones, correo electrónico, y Servicio de Sistema de Nombre de Dominio (DNS). El manejo de la red es un componente importante en un diseño de red de campus. Un backbone de campus debe proporcionar el acceso a dispositivos de manejo que soporta monitoreo, registro, solución de problemas, seguridad, y otras funciones de manejo común.

Según el Modelo de Red Compuesto Empresarial, un campus consiste en el módulo de infraestructura de campus, una granja de servidores, un módulo de manejo de red, y un módulo de distribución de borde que proporciona la conectividad entre el campus y el resto de las redes. La figura 17 muestra estos módulos e ilustran esta infraestructura de módulos de campus que tienen tres submódulos: •

Edificio de submódulo de acceso. Localizado dentro de un edificio de campus, este submódulo contiene estaciones de trabajo de usuario final y teléfonos de IP

Marcos Huerta S.

69


conectados a los switches o puntos de acceso inalámbricos. Los switches finales más alto proporcionan upenlacess al módulo de distribución del edificio. Los servicios ofrecidos por este módulo incluyen el acceso de red, control de broadcast, filtración de protocolo, y la marcado de paquetes para características de QoS. •

Edificio de submódulo de distribución. El trabajo de este submódulo debe agregar cableado a los armarios dentro de un edificio y proporcionar la conectividad al backbone de campus vía routers (o switches con modulos de enrutamiento). Este submódulo proporciona enrutamiento, QoS, y métodos de control de acceso para encontrar seguridad y requerimientos de performance. Redundancia y la carga compartida son recomendados para este submódulo. Por ejemplo, cada submódulo de distribución de edificio debería tener dos caminos de costo igual en el backbone de campus.

•

Backbone de campus. Backbone de campus es la capa core de la infraestructura de campus. El backbone interconecta el acceso

y distribución de submodulos del

edificio con la granja de servidores, manejo de red, y módulos de distribución de borde. El backbone de campus proporciona la conectividad redundante y rápido conectividad de convergencia. Estas rutas y tráfico conmutan tan rápidamente como es posible de un módulo al otro. Este módulo por lo general usa routers de alta velocidad (o switches con la capacidad de enrutamiento) y proporciona características de seguridad y QoS.

El Protocolo Spanning Tree La topología de cada módulo y submódulo de un diseño de red de campus es parcialmente determinada por el Protocolo de Spanning Tree (STP). El STP es un protocolo y el algoritmo, documentado en la IEEE 802.1D, para dinámicamente "pruning" una topología arbitraria conectada a la Capa 2 switches en spanning tree. La topología esta resuelta con spans la de dominios conmutados enteros y es formada como un árbol matemático, con ramas que se extienden de un tallo sin formar loop o polígonos. El diseñador de red físicamente conecta los switches en una malla, de topología de redundancia, pero STP crea un árbol lógico con no redundancia.

El spanning tree que atraviesa tiene un puente de raíz y un juego de puertos en otros switches que envían el tráfico hacia el puente de raíz. El protocolo dinámicamente selecciona puertos del switch para incluir en la topología de spanning tree para determinar los caminos de costo más bajo al puente de raíz. Los puertos del switch que no son la parte del árbol son deshabilitados de modo que haya un y sólo un camino activo entre cualquier dos estación. El camino de costo más bajo es por lo general el camino de ancho de banda más alta, aunque el costo sea configurable. Los switches envían la Unidad de Datos de Protocolo de Puente (BPDU) de paquetes de uno al otro para construir y mantener el spanning tree. Los switches envían mensajes de

Marcos Huerta S.

70


cambio de topología BPDUs cuando los puertos de switch cambian el estado. Los switch envían mensajes de BPDUs con direcciones multicast

cada dos segundos para

mantener el spanning tree. La cantidad de tráfico causado por los paquetes de BPDU puede parecer excesiva cuando usted primero usa un analizador de protocolo en una red conmutada, pero BPDUs realmente no usa mucho ancho de banda en la mayor parte de redes, y el temporizador corto para enviar BPDUs es importante para el proceso de convergencia.

Convergencia de STP Los switches siguen cuatro pasos para convergir la topología en spanning tree: 1. Los switches seleccionan un solo switch como el puente de raíz. 2. Los switches seleccionan un puerto en cada switch (conocido como el puerto de raíz) que proporciona el camino de costo más bajo al puente de raíz. 3. Para cada segmento de LAN, los switches deciden un puente designado y un puerto designado en cada switch. El puerto designado es un puerto en el segmento de LAN que tiene el camino de costo más bajo al puente de raíz. El puerto designado envía los paquetes del segmento de LAN hacia el puente de raíz. (Todos los puertos en el puente de raíz son puertos designados.) 4. Finalmente, los switches determinan cual puertos del switch deben ser incluido en la topología de spanning tree. Los puertos seleccionados son los puertos de raíz y puertos designados. Estos puertos envían el tráfico. Los otros puertos bloquean el tráfico.

Cuando primero inicializa, los switches asumen que ellos son la raíz y transmiten los mensajes de BPDUs en cada puerto con su puente ID en el campo de Puente de Raíz. Los switches ponen el costo de cero a la raíz. Además del envío de BPDUs, cada switch recibe BPDUs en cada uno de sus puertos. El switch determina qué mensaje es el mejor evaluando BPDUs recibido en el puerto así como el BPDU que esto enviara por el puerto. Si un nuevo BPDU (o BPDU en la localidad generado) es mejor, entonces el viejo mensaje es sustituido.

Para determinar mejor BPDU, el switch comprueba cuatro criterios,. Los cuatro criterios son como sigue: 1. El puente de raíz más bajo ID. 2. El costo de camino más bajo al puente de raíz. 3. El ID del puente de remitente más bajo. 4. El puerto más bajo ID.

Después de que la raíz ha sido determinada, cada switch de no raíz determina cual de sus puertos es el más cercano al puente de raíz. Aquel puerto se hace el puerto de raíz.

Marcos Huerta S.

71


Los switches usan el concepto de costo para juzgar la proximidad a la raíz. Los switches rastrean un costo acumulativo de todos los enlacess al puente de raíz. Cada segmento de LAN tiene un costo. Tabla 12 muestra el valor por defecto de costo para enlacess de velocidades diferentes.

Tabla Nro. 12. Valores de Costo por Defecto IEEE 802.1D

Cuando un switch se inicializa participa en el proceso de convergencia STP para determinar cual de sus puertos será raíz o puertos designados, y qué puertos deben bloquear el flujo de tráfico. Durante el proceso de convergencia, cada puerto del switch pasa por cuatro estados de STP, en el orden presentado en la lista siguiente: •

Bloqueo. Recibe BPDUs sólo.

•

Escucha. Construye el spanning tree.

•

Aprendizaje. Construye la tabla de conmutación (puenteando).

•

Envió. Envía y recibe datos de usuario.

Selección del Puente de Raíz Esto es una buena práctica para controlar qué switch se hace el puente de raíz. El puente de raíz debería ser un switch confiable, rápido en el centro de la topología conmutada. Si usted deja a switches decidir la raíz solos, usted tiene un poco de control de la dirección del flujo de tráfico y la cantidad de la tardanza en enviar un paquete de su red. Si usted no tiene cuidado, un puente lento puede hacerse el puente de raíz. También, los puertos rápidos pueden ser por casualidad quitados del spanning tree por diferencia a velocidad baja de puertos que son más cercanos al puente de raíz.

El puente de raíz es el switch con el ID del puente más bajo. El ID del puente tiene dos partes, un campo de prioridad y la dirección de MAC del switch. Si todas las prioridades son dejadas en su valor por defecto, el switch o el puente con la dirección de MAC más baja se hacen la raíz. Este podría ser fácilmente uno de los productos más tempranos de Cisco, porque Cisco tenía a un vendedor ID tan bajo. (El vendedor ID arregla los primeros 3 bytes de una dirección de MAC, y el vendedor original de Cisco ID era 00:00:0C.)

Marcos Huerta S.

72


El control manual del proceso de selección de puente de raíz es crítico al mantenimiento del rendimiento alto en redes conmutadas. Este puede ser llevado a cabo asegurando que un switch particular tiene el ID puente más bajo. Esto no es recomendado (o hasta posible en algunos switches) para cambiar la parte de dirección de MAC de un ID puente. En cambio, para controlar el ID puente, setee la prioridad de puente. En los switches de Cisco, usted puede usar el juego spantree prioridad o el comando spantreeplantilla 1 prioridad. Usted debería dar una rápida velocidad central, localizado en el switch de prioridad más baja de modo que esto se haga el puente de raíz. Usted también debería bajar la prioridad en el otro switch backup, de modo que esto se haga la raíz si la raíz primaria falla. Generalmente estos dos switches son switches de capa de distribución.

Cisco de Alta cualidad cambia también el soporte de seteo spantree raíz macro. Este macro hace que el switch mire la prioridad actuando del puente de raíz. Si la prioridad en el puente de raíz existente es más alta que 8,192, el macro automáticamente pone la prioridad local con 8,192. Si el puente de raíz existente tiene una prioridad menos de 8,192, el macro pone la prioridad local con uno menos. Para configurar una raíz de reserva, use el juego spantree raíz secundaria macro.

Guardia de Raíz Cisco también soporta las caracteristicas llamado la Guardia de Raíz que protege su red de un switch de velocidad baja secuestrando el trabajo del puente de raíz. Un puerto de switch configurado para la Guardia de Raíz no puede hacerse un puerto de raíz. En cambio el puerto se hace un puerto designado para su segmento de LAN. Si hay mejor BPDU recibido en el puerto, la Guardia de Raíz incapacita el puerto, más bien que toma las BPDU en cuenta y reanudar la elección del puente de raíz. Tienen que habilitar la Guardia de raíz en todos los puertos en todos los switches que no deberían hacerse el puente de raíz.

El Proceso de Cambio de Topología STP Después que el spanning tree ha sido creado, STP todavía necesita adaptarse a cualquier problema de capa física o reconfiguraciones rápida

como es posible sin

introducir cualquier loop. Hay muchas fallas posibles y reconfiguraciones. Algunos de ellos causan interrumpir el tráfico durante 30 segundos (temporizador de Tardanza Avanzado * 2) y unos causan interrumpir el tráfico durante 50 segundos (Máximo Envejecen el temporizador + (temporizador de Tardanza Avanzado * 2)). El temporizador de Edad Máximo controla el tiempo máximo que un puerto de switch salva la información configuración de BPDU. El valor por defecto de la Edad Máxima es 20 segundos.

Marcos Huerta S.

73


Si el puente de raíz falla, otro switch espera hasta que su temporizador de Edad Máximo expire y luego comience el proceso de asumir como el puente de raíz. Si el puente de raíz no falla, pero un camino al puente de raíz falla, el proceso es ligeramente diferente. Si un camino alterno existe, un puerto bloqueado de switch entra en transiciones, escucha, aprende, y transporta después de que su temporizador de Edad Máximo expira. Si un puerto de raíz falla, otro puerto en el switch donde el falla ocurrió la transición se pone directamente escucha y aprende sin esperar que el temporizador de Edad Máximo a expirar.

Aunque haya situaciones donde las ramas enteras del spanning tree no son afectadas, hay también muchas situaciones más donde muchas ramas son afectadas y la reconvergencia toma entre 30 y 50 segundos. Esta cantidad del tiempo puede ser más larga que los valores de intervalo de espera de sesión de capa superior. Las estaciones de final pueden tener que reconectarse de nuevo a sus servidores o los host de aplicaciones.

Escalamiento que Atraviesa el Protocolo Spanning Tree El STP trabaja mejor cuando la red cambiada es guardada relativamente pequeña y los switches tienen CPU suficiente y la poder de RAM para hacer su trabajo con eficacia. En una red de gran tamaño con switches que tienen poca CPU, las BPDUs no puede ser enviado y recibido correctamente, causando loop. Un switch con la RAM insuficiente o problemas de software también podría dejar caer las BPDUs. Además, una red congestionada podría causar problemas para la transmisión de BPDUs.

El STP confía en la recepción oportuna de BPDUs. El Cisco llama a esta característica BPDU Sesgue Descubrimiento esto permite que un switch mantenga la pista de los arribos tarde de BPDUs y notifica al administrador por medio de mensajes syslog. Esta característica es realmente más que una solución. Un mejor plan es diseñar una red conmutada con el cuidado.

Basado en asunciones sobre los temporizadores STP y la propagación del retardo de envió de BPDUs, esto es recomendado para una topología de red conmutada no más de siete switches. En otras palabras, dos switches en la red no deberían estar más de siete saltos lejos del uno del otro. La parte de esta restricción viene del campo de Edad de Mensaje que la BPDUs lleva. Cuando un BPDU es propagado del puente de raíz hacia las hojas del árbol, el campo de Edad de Mensaje es incrementado cada vez que esto va a un switch. Finalmente, cuando la Edad de Mensaje va más allá de la Edad Máxima, el BPDU es desechado. Típicamente, esto ocurre si la raíz está demasiado lejos de algún switch en la red. El problema hace que STP converja de nuevo con mucha más frecuencia que esto debería.

Marcos Huerta S.

74


Aunque algunos temporizadores STP puedan ser cambiados, un mejor acercamiento debe planear en el diseño de red de campus con cuidado de modo que los routers y los protocolos de enrutamiento sean introducidos para limitar la topología del LAN conmutada. Los routers tienen ventajas comparadas a switches en su capacidad de implementar políticas de seguridad, carga compartida, y caracteristicas de QoS. También, los protocolos tienden a convergir mucho más rápidamente que STP. Sin embargo, tanto el IEEE como los vendedores siguen mejorando la performance de STP. Una mejora es el IEEE 802.1w Rapid Spanning Tree (RSTP), cubierto en la siguiente sección.

Rápida Reconfiguración del Spanning Tree IEEE 802.1w, "la Reconfiguración Rápida de Spanning Treee” complementa el estándar 802.1 de 1998 IEEE y define los cambios necesarios en switches para proporcionar la convergencia rápida de spanning tree. El objetivo del 802.1w el comité debería estandarizar un modo mejor de la operación del switch que reduce el tiempo que STP toma para configurar de nuevo y restaurar el servicio después de que falla un enlace, reteniendo las ventajas de plug-and-play de STP.

El RSTP proporciona la convergencia rápida del spanning tree asignando roles de puerto y determinando la topología activa. El RSTP construye sobre STP para seleccionar el switch con el switch de prioridad de más alta como el puente de raíz y luego asigna roles de puerto (raíz, designada, suplente, backup, y deshabilitado) a los puertos individuales. Estos roles asisten en la convergencia rápida, que puede ser muy rápida (dentro de un segundo) debido al mejor conocimiento de la topología.

LANs virtuales Una red de campus debería ser diseñada usando pequeño ancho de banda y pequeñas dominios de broadcast. Un dominio de ancho de banda es un juego de dispositivos que comparten el ancho de banda y compiten por el acceso al ancho de banda. Una tradicional topología bus o Ethernet a base de hub, por ejemplo, es un simple dominio de ancho de banda. Un switch divide en domino de ancho de banda y a menudo es usado para conectar cada dispositivo de modo que la red consista en muchos, muy pequeñas dominios

de ancho de banda. Con switches, a diferencia de hubs, los

dominos de ancho de banda consiste en el puerto del switch y el dispositivo que lo conecta. Si el modo de transmisión usado es full dúplex, una domino de ancho de banda se hace aún más pequeña y consiste en sólo el puerto o el dispositivo.

Un dominio de broadcast es un juego de dispositivos que pueden oírcada uno de todos los paquetes de broadcast. Un paquete de broadcast es un paquete que es enviado a FF:FF:FF:FF:FF:FF de dirección de MAC. En ausencia, los switches no

Marcos Huerta S.

75


dividen dominos

de broadcast. Según Cisco, el módulo de acceso de edificio del

Modelo de Red Compuesto Empresarial debería usar switches y proporcionar el control de broadcast, sin embargo. Para llevar a cabo este, los LANes virtuales son necesarios.

Una LAN Virtual (VLAN) es una emulación de un LAN estándar que permite que la transferencia de datos ocurra sin las restricciones físicas tradicionales colocadas en una red. Un VLAN es un juego de dispositivos de LAN que pertenecen a un grupo administrativo. El grupo administrativo está basado en parámetros de configuración y políticas administrativas más bien que posición física. Los miembros de un VLAN comunican el uno con el otro como si ellos estuvieran en el mismo linea o hub, cuando de hecho ellos pueden ser localizados en segmentos de LAN físicos diferentes. Los miembros de un VLAN se comunican con miembros de dierentes VLAN como si ellos estuvieran en segmentos diferentes de LAN, aun cuando ellos son localizados en el mismo switch. Como VLANs están basados en conexiones lógico en vez de físicas, ellos son muy flexibles.

En los primeros días de VLANs a mediados de los años 1990, había mucha conversación sobre la utilización de VLANs a grupos de usuarios que trabajan en un proyecto juntos, aunque ellos no fueran físicamente localizados juntos. Con VLANs, la posición física de un usuario no importa. Un administrador de red puede asignar a un usuario a una VLAN sin tener en cuenta la posición del usuario. En la teoría, la asignación de VLAN puede estar basada en aplicaciones, protocolos, requerimientos de performance, requerimientos de seguridad, características de carga- tráfico, u otros factores.

Había también mucha conversación sobre VLANs la simplificación de movimientos, añade, y se cambia de una red de campus. La teoría era que con VLANs, los administradores de red pueden quedarse sentados en sus oficinas o en el armario de cableado cuando un usuario final se mueve a una nueva oficina o cubículo. Si un usuario en el departamento de comercialización, por ejemplo, se mueve a una nueva oficina que es físicamente localizada entre ingenieros, la persona de mercadotecnia no podría tener las habilidades de configurar IP por la compatibilidad con la nueva posición. La petición de los ingenieros para ayuda no podría trabajar porque a los ingenieros no les gustan proveedores, y pedir del administrador de red de venir a la oficina y hacer el cambio podría tardar mucho porque los administradores están tan ocupados. En cambio, el administrador de red puede configurar el puerto de interruptor para el dispositivo movido para ser la parte de la mercadotecnia VLAN. Los cambios adicionales pueden ser necesarios para asegurarse que los otros switches aprenden que la mercadotecnia VLAN se ha ampliado en una nueva área. Sin embargo, ningún cambio es requerido en la computadora del proveedor.

Marcos Huerta S.

76


En redes modernas, VLANs no a menudo usan este camino. Manualmente la configuración de la IP no es común ya que DHCP se ha hecho tan popular. También, cuando un VLAN es dispersado a través de muchas redes físicas, el tráfico debe fluir a cada una de aquellas redes, que afecta la performance de las redes y añade a los requerimientos de capacidad de enlaces que conecta VLANs. Las redes con VLANs que emigran por todas partes de la topología de campus son difíciles de manejar y optimizar.

En redes modernas, en vez de tener la extensión en cuenta de un LAN lógico o grupo administrativo a través de muchas LANs físicas, un VLAN se ha hecho un método de subdividir LANs a base de switches físicos en muchos LANs lógicas. Los VLANs permiten que una red grande, plana, a base de switch sea dividida en separados dominio de broadcast. En vez de inundar todas los dominios cada puerto, un switch VLAN-habilitado inunda con broadcast sólo los puertos que son la parte de mismo VLAN que la estación de envío.

Cuando los primeros switches se hicieron populares a mediados de los años 1990, muchas compañías implementaron redes de campus conmutadas grandes con pocos routers. Los objetivos eran contener gastos usando switches en vez de routers, y proporcionar una buena performance porque probablemente los switches eran más rápidos que routers. Sin la capacidad del router de contener tráfico de broadcast, sin embargo, las compañías necesitaron VLANs. Los VLANs permiten que la red plana grande sea dividida en dominos de broadcast. Un router (o un enrutamiento dentro de un módulo de switch) todavía es necesario para la comunicación inter-VLAN.

En redes IP basadas en campus, un VLAN es por lo general su propia subred de IP, debido al trabajo del camino el Protocolo de Resolución de Dirección (ARP). Cuando un host de IP en una subred tiene que alcanzar a otro host en la misma subred, esto envía un mensaje ARP para determinar el Control de Acceso de Medios (MAC) la dirección del host que trata de alcanzar. El mensaje ARP es enviado como un broadcast. Todos los dispositivos que encuentran el uno al otro este camino tienen que estar en la misma VLAN. Así, en una red de IP, VLANs son implementadas por separado como subredes de IP. Un router (o un enrutamiento dentro de un módulo de switch) proporciona la comunicación inter-subnet como lo haceen una interconexion real (no virtual) de LANs.

Diseños de VLAN fundamentales Para comprender VLANs, esto ayudara a pensar acerca de las primeras VLANs reales (no virtuales). Imagine dos switches que no están relacionados el uno con el otro de ningún modo. El Switch A conecta estaciones en la Red A e el Switch B conecta estaciones en la Red B, como mostrado en La figura Nro. 18.

Marcos Huerta S.

77


Figura Nro. 18 Dos Switches con estaciones Conectadas

Cuando Estación A1 en La figura nro.19 envía un broadcast la, Estación A2 y Estación A3 reciben el broadcast, pero ninguna de las estaciones en la Red B recibe el broadcast, porque los dos switches no están conectados. Esta misma configuración puede ser implementada por opciones de configuración en un solo switch, con el resultado mostado en La figura 19 Figura Nro 19.Un Simple Switch Conectados con estaciones de la Red A y Red B

Por la configuración del switch hay ahora dos LANs virtuales implementadas en un solo switch, en vez de dos LANs físicos separados. Este es la belleza de VLANs. Los broadcast, multicast, y el tráfico de destino-desconocido que origina con cualquier miembro de VLAN A son enviados a todos otros miembros de VLAN A, y no a un miembro de VLAN B. El VLAN A tiene las mismas propiedades que un LAN física separada por un routers. El comportamiento del protocolo en La figura 18 es exactamente el mismo como el comportamiento del protocolo en La figura 19.

Marcos Huerta S.

78


Figura Nro. 20 VLAN A y VLAN B separada por dos Switches

Las VLANs pueden atravesar múltiples switches. En La figura nro. 20, ambos switches contienen estaciones que son miembros de VLAN A y VLAN B. Este diseño introduce un nuevo problema, la solución a la cual es especificado en el estandar IEEE 802.1Q y el protocolo de enlace Inter-Switch patentado por Cisco (ISL). El problema tiene que ver con el envio de broadcast, multicast, o paquetes de destino desconocido de un miembro de una VLAN en un switch a los miembros de la misma VLAN en el otro switch.

En la Figura Nro 20, todos los paquetes que van del switch A para el switch B toman el mismo camino de interconexión. El 802.1Q el estándar y el Cisco ISL protocolo definen un método para el switch B para reconocer si un paquete entrante pertenece a VLAN A o a VLAN B. Cuando un paquete deja el switch A, una especial cabecera es añadido al paquete, llamado etiqueta de VLAN. La etiqueta de VLAN contiene un identificador VLAN (ID) que especifica a cual VLAN el paquete pertenece.

Como ambos switches han sido configurados para reconocer VLAN A y VLAN B, ellos pueden intercambiar paquetes a través del enlace de interconexión, y el switch de recipiente puede determinar de cual

VLAN aquellos paquetes deben ser enviados

examinando la etiqueta de la VLAN. El enlace entre los dos switches es a veces llamado enlace-troncal o simplemente un troncal.

Los enlaces troncales permiten que el diseñador de red junte cosas de las VLANs que atraviesan multiples switches. Una consideración de diseño principal determina el alcance de cada VLAN y cuantos switches esto debería atravesar. Como mencionado antes, la mayor parte de diseñadores tratan de mantener pequeño el alcance. Cada VLAN es un dominio de broadcast, y por recomendaciones especificadas en el capítulo anterior (ver Tabla 11), un domino de broadcast debería ser limitado con unos cientos de estaciones de trabajo (u otros dispositivos, como teléfonos de IP).

Otra consideración principal de diseño es la capacidad del enlace troncal. La utilización de métodos se habló en la parte 4, usted debería estudiar el tráfico de red para determinar si usa Fast Ethernet, Gigabit Ethernet, o los múltiplos de la Fast Ethernet o

Marcos Huerta S.

79


Gigabit será requeridos para los enlaces troncales. Aunque Cisco soporta troncales de Ethernet 10-Mbps en algún equipo, 10 Mbps es por lo general suficiente sólo para troncales que apoyan muy pequeñas redes o para redes de laboratorio usadas para aprender y probar objetivos.

LANs inalámbricos Como hemos hablado en Fase I de esta tesis, la movilidad de usuario se ha hecho un objetivo importante para muchas empresas. En un diseño de red de campus, una o varios LANs inalámbricas (WLANs) pueden encontrar con este objetivo para ofrecer intranet y acceso de Internet en áreas abiertas en el campus y en áreas de alta densidad como auditorios, salas de conferencias, y cafeterías. La tecnología de WLAN también permite el despliegue de LANs en oficinas u otras partes de edificios donde puede no ser rentable o práctico para instalar el tendido de cables.

Un WLAN consiste en puntos de acceso que se comunican usando la radiofrecuencia (RF) con clientes inalámbricos. El área que un punto de acceso solo puede cubrir a menudo es llamada a celda inalámbrica. El diseño de una topología WLAN requiere que un diseñador determine el área de cobertura de cada celda inalámbrica y se decida cuantas celdas serán requeridas para encontrar necesidades de cobertura totales. Los factores que afectan la cobertura de un punto de acceso solo incluyen la velocidad de transferencia de datos, el nivel de poder, la opción de antena, y la colocación de antena. Las características arquitectónicas del sitio inalámbrico también afectan la cobertura, como descrito en el "La comprobación de un Sitio para una Instalación Inalámbrica” sección en la parte 3, "Caracterizando las redes Existentes."

La colocación de un Punto de Acceso para Cobertura Máxima La mayor parte de los puntos de acceso usan una antena isotropic, el que significa que la fuerza de señal es teóricamente el mismo cuando es medido a lo largo de los axes en todas las direcciones. Si usted suspende un punto de acceso en el espacio, la cobertura debería parecerse a la de una esfera tridimensional con el punto de acceso en su centro. En realidad, las limitaciones del diseño de antena por lo general causan menos cobertura uniforme, sin embargo. El tipo más común de la antena de punto de acceso es omnidireccional, que no es realmente "omni" o "iso". En vez de una esfera, la cobertura se parece más bien a una donut o un anillo de espuma.

Una antena omnidireccional es por lo general un 4-a 6 pulgadas que transmiten el elemento, a menudo atado al giro o pivot posisionable. La señal que se propaga de una antena omnidireccional es la más fuerte en una dirección perpendicular al eje de antena y la más débil en la misma dirección que el eje de antena. Recordar este puede ayudarle

Marcos Huerta S.

80


a colocar sus antenas para la cobertura máxima (y ayúdarle a decidirse si usted puede necesitar una antena direccional en vez de una antena omnidireccional).

Los puntos de acceso pueden ser montados en una posición horizontal o vertical. Es importante asegurarse que una antena omnidireccional señala directamente. Además de la antena de punto de acceso, también considere la antena en la recepción de estaciones, por lo general notebook. Cada NIC inalámbrica y computadora son diferentes. Algunos ordenadores portátiles tienen antenas largas que se extienden de la tarjeta por la espalda del ordenador portátil, detrás de la pantalla. Otras computadoras pueden no tener una antena incorporada y deben confiar en una antena más pequeña en el NIC. Usted debería probar su diseño de WLAN con una variedad de computadoras y otros dispositivos que los usuarios actuales usarán.

Para una velocidad de transferencia de datos dada, usted puede cambiar el nivel de poder o elegir una antena diferente para cambiar el área de cobertura y la forma de cobertura. Un tamaño de celda grande puede causar a demasiados clientes que comparten la amplitud de banda disponible. (IEEE 802.11 WLANs son redes compartidas, con todos los dispositivos en el mismo dominio de ancho de banda.) Reduciendo el punto de acceso señala el poder o la ganancia de antena, usted puede reducir el tamaño de celda y compartir el ancho de banda con menos clientes. Este causará más puntos de acceso para un área de cobertura dada, pero proporcionará la mejor performance para clientes

WLANs y VLANs Usted puede colocar multiples puntos de acceso en todas partes de una instalación para dar a usuarios la capacidad de navegar libremente en todas partes de un área ampliada manteniendo el acceso ininterrumpido para conectar a los recursos de la red. El método más fácil para usuarios que se aseguran puede navegar debe poner a todos los usuarios en la misma subred de IP y mismo VLAN. Por otra parte, los dispositivos que se mueven de la subred para subred deben adquirir una nueva dirección de IP y pueden perder paquetes que podrían haber sido transmitidos mientras ellos adquirían una dirección.

Siempre que posible, un WLAN debería ser una subred separada para simplificar la dirección de conexion y también mejorar el manejo de la seguridad. El cuidado de todos los clientes inalámbricos en su propia subred hace más fácil para establecer filtros de tráfico para proteger a los clientes de un ataque lanzado a la WLAN.

Marcos Huerta S.

81


Puntos de Acceso Inalámbricos Redundantes Tanto en arquitecturas LAN de campus cableadas como en inalámbricas, la redundancia es por lo general deseable para asegurar una alta la disponibilidad. Ya que con el campus se conecta con la red con WLANs que es la misión mas crítica, Cisco hace llamar una característica punto-acceso reserva caliente esto soporta dos puntos de acceso configurados para usar el mismo canal en un área de una sola cobertura. Sólo uno de los puntos de acceso esta activo. El punto de acceso de reserva pasivamente monitorea la red y el punto de acceso primario. Si el punto de acceso primario falla, el punto de acceso secundario asume para proporcionar la cobertura.

Usted debería colocar el punto de acceso de reserva cerca del punto de acceso esto supervisará y le dará la misma configuración (excepto una dirección de IP diferente). El punto acceso de reserva asociados con el punto de acceso monitoreado de un cliente el punto de acceso supervisado con regularidad es tanto por el interfaz de Ethernet como por el interfaz de RF. Si el punto de acceso monitoreado deja de responder, el punto de acceso de reserva se hace activo, y toma el lugar del punto de acceso supervisado en la red.

Tan pronto como el primer punto de acceso que fallo es detectado nuevamente, la intervención del usuario es requerida. El usuario debería retornar el punto de acceso de reserva al modo de reserva. La falla de reinicializar el punto de acceso de reserva causa que tanto el punto de acceso primario como el de reserva funcionen simultáneamente en el mismo canal cuando el primer punto de acceso vuelve en línea.

Despido y Carga que Comparte en LANes Conectados En redes de campus cableadas, es comun en la práctica común diseñar enlaces redundantes entre LAN conmutadas. La mayor parte de LAN conmutadas implementan el algoritmo spanning tree IEEE 802.1 para evitar loop en la red. El estandar 802.1 es una solución buena para la redundancia, pero no para la carga compartida, porque sólo un camino es activo. Algunos vendedores de switches, incluso Cisco, le dejan tener un spanning tree por VLAN, que puede ser usado para implementar la redundancia. Un switch puede actuar como el puente raíz para una VLAN y como un backup para el puente raíz de otra VLAN.

Cisco Por VLAN Spanning tree + (PVST +) construye por separado una topología de árbol lógico para cada VLAN. El PVST + permite la carga compartida teniendo diferentes caminos por VLAN. El PVST + es menos escalable que el método clásico 802.1, donde hay sólo una raíz y árbol, porque se requiere que el tiempo de CPU es requeridoen las BPDUs para cada VLAN. Cisco venció esta limitación con el Protocolo de Multi-Instance

Marcos Huerta S.

82


Sapnning Tree (MISTP), que permite que un grupo de VLANs sea agrupado en un simple spanning tree.

El IEEE también ha realzado el algoritmo de spanning-tree original con sus estandar Multiples Spanning-Tree (MST), que es documentado en IEEE 802.1s. Protocolo de Multiples Spanning Tree (MSTP) usa RSTP para la convergencia rápida, pero mejora la escalabilidad RSTP agregando un grupo de árboles VLAN-base que atraviesan en distintos casos, y dirigiendo sólo un algoritmo de spanning tree por caso (rápido). Esta arquitectura proporciona multiples caminos para el tráfico de datos, permite la carga compartida, y reduce el número de spanning tree requeridos para soportar un número grande de VLANs.

Si usted usa VLANs en un diseño de red de campus con switches que apoyan 802.1s, PVST + o MISTP, los enlaces redundantes pueden ofrecer la carga compartida como adición para la tolerancia critica. La figura nro. 21 muestra un diseño redundante de LAN de campus que usa el algoritmo de spanning-tree y VLANs.

Figura Nro. 21.

Una Topologia de Campus Redundante Jerárquica

El diseño en la figura nro. 21 aprovecha el concepto de spanning tree por VLAN. El switch A actua como el puente raíz para las VLANs 2, 4, y 6. (Switch B puede hacerse el puente raíz para aquellos VLANs si el Switch A falla.) Switch B actua como el puente raíz para las VLANs 3, 5, y 7. (Switch A se hace el puente de raíz para aquellos VLANs si el Switch B falla.) el resultado es que ambos enlaces de capa de acceso conmutada llevan el tráfico, y failover a un nuevo puente raíz pasa automáticamente si uno de los switches de capa de distribución falla. Tanto la carga compartida como la tolerancia de falta es conseguida. Marcos Huerta S.

83


El diseño en La figura nro. 21 puede escalar a una red de campus muy grande. El diseño ha sido probado en una red que tiene a 8000 usuarios, y 80 switches de capa de acceso, 14 switches de capa de distribución, y 4 routers core de campus (no contando los routers que van a la WAN).

Servidor Redundante Esta sección cubre pautas para servidor redundante en un diseño de red de campus. El archivo, la web, Protocolo de Configuración de Host Dinámico (DHCP), nombre, y servidores de base de datos es todos los candidatos para un diseño redundante de campus, según los reuqerimientos de un cliente. En una red que soporta la Voz sobre IP (VoIP), los servidores que proporcionan el mapeo entre un número de teléfono y una dirección de IP y el procesamiento de llamada de debería ser aprovisionado en una manera redundante. El software de CallManager de Cisco, por ejemplo, soporta un grupo de redundancia donde los servidores estan asignados a roles del servidor primario, secundario, o terciario.

Una vez que un LAN ha sido emigrado a la utilización de servidores de DHCP para la dirección de IP de sistemas final, los servidores DHCP se hacen críticos. A causa de esto, usted debería recomendar servidores DHCP redundantes. Los servidores deberían sostener copias (mirrored) redundantes de la base de datos DHCP de la información de configuración IP.

Los servidores de DHCP pueden ser colocados en la capa de distribución o acceso. En pequeñas redes, los servidores DHCP redundantes a menudo son colocados en la capa de distribución. Para redes más grandes, los servidores DHCP redundantes son por lo general colocados en la capa de acceso. Este evita el tráfico excesivo entre el acceso y capas de distribución, y permite que cada servidor DHCP sirva un porcentaje más pequeño de la población de usuario.

En redes de campus grandes, el servidor DHCP a menudo es colocado en un segmento de red diferente que los sistemas finales usan. Si el servidor está al otro lado de un router, el router puede ser configurado para enviar broadcast de DHCP del sistemas final. El router adelante los broadcast a una dirección de servidor configurada vía el comando ip helper address en un router Cisco. El router inserta la dirección de la interfaz que recibió la petición en el campo de giaddr de la petición de DHCP. El servidor usa el campo de giaddr para determinar de cual el pool de direcciones elegira una dirección.

Los servidores de nombre son menos críticos que servidores DHCP porque los usuarios pueden alcanzar servicios por la dirección en vez del nombre si el servidor de nombre

Marcos Huerta S.

84


falla; porque muchos usuarios no realizan esto, sin embargo, esto es una idea buena de planear para servidores de nombre redundantes. Implemente servidores de nombre el Sistema de Dominio de Nombre de Internet (DNS), el Servicio de Nombramiento de Internet de Windows (WINS), y el Servicio de Nombre de NetBIOS (NBNS). Los servidores de nombre pueden ser colocados en la capa de distribución o el acceso.

En cualquier aplicación donde el costo de tiempo de indisponibilidad para servidores de archivo es una preocupación principal, deberían recomendar a servidores de archivo mirrored. Por ejemplo, en una firma de corretaje donde los brokerage tienen acceso a datos para comprar y vender acciones, los datos pueden ser replicados en dos o más servidores de archivo mirrored. Los servidores de archivo mirrored mantienen datos idénticos. Las actualizaciones de los datos son sincronizadas a través de los servidores. Los servidores deberían estar en redes diferentes y con suministros de energía para maximizar la disponibilidad.

Si el servidor de redundancia completa no es factible debido a consideraciones de costos, reflejando o duplicando los discos duros del servidor de archivo es una idea buena. (Duplicando es lo mismo como reflejando con el rasgo adicional que los dos discos duros son controlados por diferentes controladores de disco.) la implementación de una red de área de almacenaje (SAN) es otra opción. Los SANs se hacen rápidamente una solución popular para organizaciones que buscan el acceso muy confiable, ininterrumpido a cantidades grandes de la información almacenada. Las SANs no son cubiertos en este libro debido a su naturaleza especializada, pero aprender más sobre SANs, vea en Cisco el artículo titulado "La estrategia y justificación Financiera de Redes

de

Área

de

Almacenaje."

Está

disponible

enla

pagina:

http://www.cisco.com/en/US/products/hw/ps4159/ps4358/products_white_paper09186a0 0800c464f.shtml. La redundancia tiene tantas ventajas de performance como disponibilidad. Con servidores de archivo mirrored, es posible compartir la carga de trabajo entre servidores. Usando una red contenida en entrega (CDN) y dispositivos contenidos en servicios contentos, los usuarios pueden ser dirigidos de uno a muchos servidores mirrored todo estos tienen los mismos datos.

La redundancia también puede ser conseguida añadiendo alguna sofisticación al DNS. Cuando un cliente solicita el acceso a un recurso por su nombre de DNS, un servidor DNS puede devolver direcciones de host múltiples en su respuesta. Si este proveerá una buena redundancia depende del software del host. Algunas implementaciones intentan direcciones adicionales si el primero no responde.

Marcos Huerta S.

85


Otra posibilidad es una caracteristica llamada el retorno al punto de origen de DNS, donde el servidor e una lista de direcciones por ciclos. El servidor entrega una dirección diferente con cada petición, pasando por su lista de direcciones. Cuando se pone al final de la lista, este ciclos regresa al principio de la lista. Debido a DNS caching, donde los clientes y otros servidores DNS recuerdan una correlación de nombre para direcciones de mapeo, el DNS retorno al punto de origen de DNS no es perfecto, pero puede ser completamente simple de implementar y configurar en un servidor tipico DNS.

La redundancia y el equilibrio de carga con DNS también pueden trabajar con multiples servidores DNS. Asumiendo que los clientes tienen acceso a diferentes servidores DNS, un servidor puede responder con una dirección, mientras otros servidores responden con direcciones diferentes. Otra vez, DNS el caching puede limitar la eficacia de este método.

Estaciones-para-Router Redundantes Las estaciones de trabajo en una red de campus deben tener el acceso a un router para alcanzar servicios remotos. Como la comunicación de estación de trabajo a router es crítica en la mayor parte de diseños, usted debería pensar en implementar redundancia para esta función.

Una estación de trabajo tiene muchos modos posibles de descubrir un router en su red, dependiendo del protocolo que esta corriendo y también la implementación del protocolo. En las siguientes secciones describen métodos para estaciones de trabajo para aprender sobre routero, y caracteristicas de redundancia que garantizan que una estación de trabajo puede alcanzar un router.

Aunque AppleTalk y Novell NetWare están siendo divididas en fases fuera de muchas redes, esto todavía es usado para aprender como los desarrolladores de aquellos protocolos solucionaron el problema de la comunicación de estación de trabajo a router. Esta sección comienza con una discusión de aquellos protocolos y luego se mueve a la comunicación IP de estación de trabajo para router.

Comunicación de Apple Talk de Estación de trabajo a router Una estación de trabajo AppleTalk recuerda la dirección del router que envió el paquete RTMP más reciente. Aunque la estación de trabajo no participe en el proceso de enrutamiento del protocolo, esto escucha realmente paquetes de broadcast de RTMP y copia en la memoria la dirección del router que envió el broadcast. Mientras hay al menos un router en la red de la estación de trabajo, la estación de trabajo puede alcanzar dispositivos remotos. Si hay routers múltiples en la red de una estación de trabajo, la estación de trabajo muy rápidamente aprende un nuevo modo de alcanzar

Marcos Huerta S.

86


estaciones remotas cuando un router falla, porque los router AppleTalk envían a paquetes RTMP cada 10 segundos.

Para minimizar memoria y requerimientos de procesamiento en un dispositivo AppleTalk, la especificación AppleTalk declara que una estación de trabajo recuerda la dirección de sólo un router (el router más recientemente que envió un paquete RTMP). Recuerde que AppleTalk fue diseñado para correr en 128 KILOBYTES de RAM de Macintosh y fue optimizado para la simplicidad. El resultado es que una estación de trabajo no siempre usa el método más oportuno de alcanzar una estación remota. La estación de trabajo puede seleccionar un camino que incluye un salto extra. La figura nro. 22 muestra el problema de salto-extra.

Figura Nro 22. Problema de Estación de trabajo al router salto-extra

Comunicación Novell de Estación de trabajo a router de NetWare Comunicación Novell de estación de trabajo a router de NetWare es muy simple. Cuando una estación de trabajo NetWare determina que un paquete es destinado a un destino remoto, la estación de trabajo envia un broadcast y encuentra el número de red requeridopara encontrar la ruta al destino. Los router en la red de la estación de trabajo responden a la petición. La estación de trabajo usa el primer router que responde para enviar paquetes al destino. Si la estación de trabajo determina que no puede alcanzar ya el destino, esto automáticamente envía la petición de número de red de hallazgo otra vez. Si un router falla, mientras hay otro router en la red de la estación de trabajo, la estación de trabajo descubre el otro router y la sesión continua.

Comunicación de Estación de trabajo IP a router Las implemetaciones IP varían en como ellos implementan la comunicación de estación de trabajo a router. Algunas estaciones de trabajo IP envían un paquete de Protocolo de Resolución de Dirección (ARP) para encontrar una estación remota. Un router que corre proxy ARP puede responder a la petición de ARP con la dirección de la capa de enlace de datos del router. Los routers de Cisco corren proxy ARP por defecto. Marcos Huerta S.

87


La ventaja de depender de proxy ARP para alcanzar estaciones remotas consiste en que una estación de trabajo no tiene que ser configurada con la dirección de un router. Sin embargo, porque proxy ARP nunca ha sido estandarizado, la mayor parte de administradores de red no dependen de ello. También, muchos expertos de seguridad recomiendan por apagarlo porque lo hace más fácil para un atacante para alcanzar otra red. En cambio, las estaciones de trabajo de IP son dadas la dirección de un router por defecto. Este puede ser manualmente configurado o suministrado por el DHCP. Un router por defecto es la dirección de un router en el segmento local que una estación de trabajo usa para alcanzar servicios remotos. (El router por defecto es por lo general llamado default gateway por motivos históricos.)

Como era el caso con AppleTalk, a veces usando el default gateway no es el camino más oportuno al destino. (Ver La figura nor. 22.) Para ponerse alrededor del problema de extra-salto y agregar la redundancia, alguna estación de trabajo IP implementan y permiten que un administrador de red añada rutas estáticas en un archivo de configuración o configura la estación de trabajo para correr un protocolo de enrutamiento.

Protocolo de router de Reserva Caliente El Protocolo de router de Reserva Caliente de Cisco (HSRP) proporciona un camino para una estación de trabajo IP para seguir comunicando en las redes aun si su entrada de default gateway no esta disponible. En RFC 2338, el IETF estandarizó un protocolo similar llamado el Protocolo Virtual de Router Redundantes (VRRP). Los router en el core, distribución, o capa de acceso pueden dirigir HSRP o VRRP. El diseño de campus mostrado en La figura nro 23 caracteristicas HSRP en la capa core.

El HSRP trabaja creando un router virtual, también llamado a router fantasma, como es mostrado en La figura nro. 23. El router virtual tiene su propio IP y direcciones de MAC. Cada estación de trabajo es configurada para usar el router virtual como default gateway. Cuando una estación de trabajo transmite un paquete de broadcast ARP para encontrar el default gateway, el router HSRP activo responde con la dirección de MAC del router virtual. Si el router activo se desactiva, un router de reserva asume como el router activo, sigue entregando los paquetes de la estación de trabajo. Este cambio es transparente a la estación de trabajo.

Marcos Huerta S.

88


Figura Nro 23. Protocolo de router de Reserva Caliente (HSRP)

Protocolo de Balanceo de Carga Gateway Para conseguir carga compartida junto con redundancia, Cisco también tiene un protocolo nuevo llamado Protocolo de Balanceo de Carga Gateway (GLBP). El GLBP es similar, pero no idéntico, a HSRP y VRRP. Con HSRP y VRRP, los routers de reserva en un grupo son superflujos hasta que el router activo falle. Estos routers de reserva pueden tener el acceso al ancho de banda que es gastada hasta que un problema levante. Aunque grupos de multiples routers virtuales puedan ser configurados para el mismo juego de routers, que es perdida menos, los hosts pueden ser configurados por diferentes default gateway, que resulta una carga administrativa suplementaria. El GLBP proporciona el balanceo de carga sobre multiples routers usando una simple dirección de IP virtual y direcciones multiples de MAC virtuales. Cada host es configurado con la misma dirección de IP virtual, y todos los routers en el grupo de router virtual participan en el transporte de paquetes.

Los miembros de un grupo GLBP eligen un router para ser gateway virtual activa (AVG) para aquel grupo. Otros miembros de grupo proporcionan la reserva para el AVG en caso de que el AVG no este disponible. El AVG asigna una dirección de MAC virtual a cada miembro del grupo GLBP. Cada entrada asume la responsabilidad de mandar paquetes enviados a la dirección de MAC virtual asignada a ello por el AVG. Estas entradas son conocidas como promotores virtuales activos (AVFs) para su dirección de MAC virtual. El AVG es responsable de contestar peticiones de ARP de la dirección de IP virtual. La carga compartida es conseguida por el AVG que contesta a las peticiones de ARP con direcciones de MAC virtuales diferentes.

El diseño de la Topología de Borde Empresarial Según los objetivos de un cliente para disponibilidad, performance, y accesibilidad, el diseño de red de borde empresarial debería presentar caracteristicas de segmentos redundantes WAN en la intranet, y múltiples caminos a extranets y el Internet. El VPNs Marcos Huerta S.

89


también puede ser usado para conectarse a sitios privados empresariales vía proveedor de servicio público WAN o el Internet. Esta sección cubre topologías de borde empresarial que incluyen segmentos WAN redundantes, conexiones múltiples al Internet, y VPNs. La sección también incluye algunos comentarios sobre proveedor de servicio de borde.

Segmentos redundantes WAN Como los enlaces WAN pueden ser piezas críticas de unas redes empresarial, los enlaces WAN (backup) redundantes a menudo son incluidos en una topología de red de borde de empresarial. Una red WAN puede ser diseñada como una malla llena o una malla parcial. Una topología de malla llena proporciona completo redundancia. Esto también proporciona una buena performance porque hay sólo un solo enlace de tardanza entre dos sitio cualquiera. Sin embargo, como ya hemos discutido en este capítulo, una malla llena es costosa para implementar, mantener, mejorar, y resolver problemas. Una topología de malla parcial jerárquica, como mostrado antes en La figura nro. 15, es por lo general suficiente.

Diversidad de Recorrido Aprovisionando enlaces WAN de reserva, usted debería aprender tanto como sea posible sobre el enrutamiento de recorrido física actual. Los diferentes portadores a veces usan las mismas instalaciones, queriendo decir que su camino de reserva es susceptible a los mismos fracasos que su camino primario. Usted debería hacer un poco de trabajo investigador para asegurar que su reserva realmente es una reserva. Los ingenieros de red usan la diversidad de recorrido de término para referirse a la situación óptima del recorrido usando caminos diferentes.

Como los portadores arriendan la capacidad el uno al otro y usan compañías de tercero que proporcionan la capacidad a multiples portadores, se hace más difícil para garantizar la diversidad de recorrido. También, los portadores a menudo combinan el uno con el otro y mezclan su recorrido después de la fusión. Cuando los portadores cada vez más usan técnicas automatizadas para el reencaminamiento de recorrido físico, se hace aún más difícil planear la diversidad porque el reencaminamiento es dinámico.

Sin embargo, usted debería trabajar con los proveedores de sus enlaces WAN para ganar un entendimiento del nivel de la diversidad de recorrido en su diseño de red. Los portadores por lo general quieren trabajar con clientes para proporcionar la información sobre el enrutamiento de recorrido física. (Esté consciente, sin embargo, que portadores a veces proporcionan la información inexacta, basada en bases de datos que no son

Marcos Huerta S.

90


guardadas corrientes.) Tratan de escribir contratos de compromisos de diversidad de recorrido con sus proveedores.

Cuando este analizando diversidad de recorrido, debe estar seguro de analizar su tendido de cables local además de los servicios de su portador. Quizás usted ha diseñado un enlace de ISDN para sostener un enlace de Frame relay. ¿Usan ambos de estos enlaces el mismo tendido de cables para ponerse al punto de demarcación en su red de edificio? ¿Qué tendido de cables usan los enlaces para ponerse a su portador? El tendido de cables que va de su edificio al portador es a menudo el enlace más débil en una red. Puede ser afectado por construcción, inundación, tormentas de hielo, camiones que golpean postes telefónicos, y otros factores.

Las Conexiones Multihoming de Internet Generalmente el significado de multihoming debe "proporcionar más de una conexión para un sistema para tener acceso y ofrecer servicios de red." El término multihoming es usado de muchos modos específicos también. Se dice que un servidor, por ejemplo, es multihomed si esto tiene más de una dirección de capa de red. Las redes pueden entregar aplicaciones multihome de la capa de datos y servicioy servicios.

El término multihoming es usado cada vez más para referirse a la práctica de proveer a la red empresarial más de una entrada en el Internet. Las entradas redundantes en el Internet proporcionan la tolerancia de falta por aplicaciones que requieren el acceso de Internet. Una red empresarial puede ser multihomed al Internet de muchos modos diferentes, según los objetivos de un cliente. La figura nro 22 y Tabla nro 13 que describe algunos métodos para multihoming de conexión de Internet.

Marcos Huerta S.

91


Figura Nro. 22. Opciones para Multihoming de conexión de Internet

Tabla Nro. 13. Descripción de Opciones para Multihoming de conexión de Internet

Marcos Huerta S.

92


En el caso de Opciones C y D, el objetivo podría ser de mejorar la performance de la red permitiendo a sitios empresarial europeos tener acceso al Internet usando el router de Paris y sitios Norteamericanos para usar el router de Nueva York. Este puede ser llevado a cabo correctamente configurando un default gateway en las estaciones finales y una ruta por defecto en routers de la empresa en Europa y Norteamérica. (Una ruta por defecto especifica donde un paquete debería ir si no hay ninguna entrada explícita para la red de destino en la tabla de enrutamiento de un router. La ruta por defecto también es a veces llamada gateway de último recurso.)

Su cliente podría tener objetivos más complejos que el objetivo simple en el párrafo anterior. Quizás su cliente quiere garantizar que los sitios de empresa europeos tengan acceso a sitios de Internet Norteamericanos vía el router de Nueva York. Un objetivo paralelo es que los sitios de empresa Norteamericanos tienen acceso a sitios de Internet europeos vía el router de Paris. Este podría ser un objetivo razonable cuando una constante, de baja latencia es requerida para una aplicación. La latencia es más previsible si la primera parte del camino es a través de la intranet de empresa en vez del Internet. Este objetivo es más difícil de encontrarse que el primer objetivo, sin embargo. Esto requiere que los routers de empresa entiendan rutas del ISP y pongan preferencias en aquellas rutas.

Un objetivo relacionado es usar "la mejor ruta" a través del Internet a los sitios en los cuales los usuarios de empresa más confían. A menos que una empresa se contraiga (y pagas) para manejar la calidad de punta a punta del servicio (QoS), este objetivo no puede ser encontrado. El protocolo de enrutamiento usado en el Internet, BGP, no ofrece la ruta optima. Su único objetivo es proporcionar la accesibilidad y la estabilidad en el sistema de enrutamiento global. Proveedores intermedios con quien una empresa tiene relación comercial no se preocupe si el tráfico de la empresa sigue rutas óptimas, tampoco ellos tienen algun incentivo para hacerlo asi.

Otro objetivo más complejo es garantizar que el tráfico entrante del Internet destinado a sitios de empresa europeas usen el router de Paris y el tráfico entrante para sitios de empresa Norteamericanos usa el router de Nueva York. Este objetivo requiere que los routers de empresa hagan publicidad a las rutas de Internet a sitios de empresa. Las rutas deben incluir la métrica de modo que los routers en el Internet sepan el camino preferido a sitios en el intranet de empresa.

Una otra advertencia cuando una red de empresa es multihomed es el potencial para hacerse una red de tránsito que proporciona interconexiones para otras redes. Mirar la La figura 5-14, considera que el router empresarial aprende rutas del ISP. Si el router empresarial aprende estas rutas cultas, entonces este arriesgo de permitir que la red de

Marcos Huerta S.

93


empresarial se hiciera una red de tránsito y fuera cargado por el tráfico externo involuntario. Cuando una red empresarial se hace una red de tránsito, los routers en el Internet aprenden que ellos pueden alcanzar otros routers en el Internet vía la red empresarial. Para evitar esta situación, los routers empresarial deberían anunciar sólo sus propias rutas. (Alternativamente ellos no pueden corre un protocolo de enrutamiento y dependeran de un enrutamiento estática por defecto.)

En general, multihoming la conexión de Internet puede ser desafiante si los objetivos de un cliente son complejos. Anime a sus clientes a simplificar sus objetivos para asegurar la implementación facil, escalabilidad, disponibilidad, y accesibilidad financiera. Si el objetivo principal es la alta disponibilidad, no asuma que este significa que más redundancia es requerido. Según Howard Berkowitz en su libro la Guía de Supervivencia WAN, "los aumentos Incontrolados de redundancia ayuda a aumentos incontrolados de la complejidad, y realmente pueden disminuir la disponibilidad".

Redes Privadas Virtuales Las redes privadas virtuales (VPNs) usan la encriptación avanzada y tuneles para permitir a organizaciones establecer conexiones privadas de red seguras, de punto a punto, sobre una red de tercero. La red de tercero puede ser una red de proveedor de servicio privada o el Internet público. Una organización puede conectarse a la red de tercero usando una variedad de WAN y tecnologías de acceso remoto, incluso líneas arrendadas, Frame relay, módems de cable, línea de suscriptor digital (DSL), módems análogos, ISDN, etcétera. Las organizaciones también pueden usar VPNs para conectarse a usuarios exteriores, como socios de negocio, clientes, revendedores, y proveedores. Las VPNs también soportan a usuarios móviles y teleconmutación.

La conectividad de punto a punto a través de la red de tercero es típicamente proporcionada por un protocolo que construye un túnel. La construcción de un túnel es una técnica para encapsular paquetes de un protocolo dentro de otro protocolo. Por ejemplo, un túnel puede llevar paquetes IPv4 a través de redes que soportan sólo IPv6. En el contexto de un VPN, la construcción de un túnel es usada para encapsular mensajes privados y aplicar algoritmos de encriptación de pagos.

Los túneles proporcionan una unión lógico, de punto a punto a través de una red IP connectionless, permitiendo la aplicación de caracteristicas de seguridad avanzados. La encriptación es aplicada a la conexión del tunel para revolver datos, así haciendo legible los datos sólo a sistemas autorizados. En aplicaciones donde la seguridad y la privacidad son menos de una preocupación, los túneles pueden ser usados sin la encriptación para proporcionar el soporte de multiprotocolo.

Marcos Huerta S.

94


Los métodos que construye tuneles de capa 2 se encapsula en la capa de enlace de datos del modelo de OSI. Los ejemplos incluyen el Punto a punto que Protocolo de Tuneles (PPTP), Capa 2 Transporte (L2F), MPLS VPNs, y Protocolo de Tuneles de Capa 2 (L2TP) que Construye un túnel. El L2TP es un estándar IETF (RFC 2661) que muchos vendedores soportan para sus soluciones VPN, incluso Cisco y Microsoft. El IETF también desarrolla una nueva versión de L2TP, llamado L2TPv3. El L2TPv3 surge como una ligera solución aún robusto para la Capa 2 de construcción de un túnel.

La capa 3 túnel encapsula en la capa de red. Dos ejemplos son IPSec y el generico enrutamiento de Cisco (GRE). Si sólo los paquetes de IP-unicast están siendo tunelados, IPSec es la mejor opción. El GRE es usado cuando multicast, broadcast, y los paquetes Non-IP tienen que ser tunelados.

Las aplicaciones de VPN para redes empresariales pueden ser divididas en dos categorías principales: sites to sites y acceso remoto. Sites to sites VPNs se concentran en la conexión de oficinas geográficamente dispersadas y son una extensión de la empresa clásica WAN. VPN de sites to sites también puede agregar interconexiones entre multiples organizaciones, en cuyo caso es llamado algún día un extranet VPN. VPNs de acceso remoto se concentran en usuarios remotos y socios de negocio que tienen acceso a la red en un comun- base necesaria.

Site-to-Site VPNs El Sites to sites VPNs ha surgido como un camino relativamente barato para una compañía para conectar sucursales geográficamente dispersadas y oficinas principales vía un proveedor de servicio o el Internet, a diferencia del mantenimiento caro de una WAN privada. Los datos privados de la compañía pueden ser encriptados para enrutarlos por la red del proveedor de servicio o el Internet. Tradicionalmente, los negocios confiaron en las líneas arrendadas de T1 1.544-Mbps privadas para conectar oficinas remotas juntas. Las líneas arrendadas son caras de instalar y mantener. Para muchas compañías, una línea arrendada provee más ancho de banda que es necesaria en un precio demasiado alto. Un sites a sites VPN es una solución más rentable y manejable.

Diseñando la topología de una red de sites to sites, usted debería considerar las mismas necesidades para una WAN privada, incluso la necesidad de la alta disponibilidad con failover automático, performance, seguridad, y escalabilidad. Las topologías más comunes para un sites to sites VPN son como sigue: •

Topología "hub and spoke"

•

Topología de malla

•

Topología de red jerárquica

Marcos Huerta S.

95


La topología "hub and spoke" es usado cuando hay un a simple oficina central o regional con muchas oficinas remotas, y la mayor parte de tráfico está entre los sitios remotos y la posición regional o

oficina central. Este diseño minimiza la complejidad de

configuración teniendo una simple conexión IPSec o un simple túnel GRE de cada posición remota detrás de la posición regional o posición de oficina central. Este diseño no es apropiado cuando hay un nivel alto del tráfico entre sitios remotos o cuando hay una necesidad de redundancia y failover automático. Un realce al diseño debe incluir multiples routers VPN en la oficina central para proporcionar la mejor redundancia.

Los diseños de malla VPN pueden ser o totalmente malla, proporcionando la conectividad "alguno a alguno", o malla parcial, proporcionando la conectividad "unos a unos", según los requerimientos del cliente. La topología malla es un diseño bueno para usar cuando hay un pequeño número de localizaciones totales (regional, oficina central, o posiciones remotas), con una cantidad grande del tráfico que fluye entre unos (malla parcial) o todos (malla llena) de los sitios. En un diseño malla llena, la pérdida de una sola localización sólo afecta el tráfico de aquella posición. Todas otras posiciones permanecen no afectadas. Este diseño no escala bien cuando hay numerosos sitios, debido al número grande de conexiones IPSec o túneles GRE con IPSec que tienen que ser configurados en cada dispositivo.

Una topología VPN jerárquica es una topología híbrida para una compañía grande que tiene muchas oficinas centrales y oficinas regionales con mucho tráfico que fluye entre ellos, y muchas oficinas remotas, con un poco de interacción entre ellos. La topología consiste en un lleno - o malla parcial core, con sitios periféricos que se conectan en el core usando un diseño "hub and spoke". Un diseño jerárquico es el más complejo de los diseños en términos de configuración, y puede tener una combinación de IPSec y túneles GRE.

Acceso remoto VPNs El Acceso remoto VPNs permitido por demanda tienen acceso a las redes de una organización, vía seguras, encriptadas. Los usuarios móviles o remotos, y las sucursales que no tienen que estar siempre conectadas, pueden tener acceso a sus redes corporativas vía una red de tercero, como la red del proveedor de servicio o el Internet. Las empresas usan el acceso remoto VPNs para reducir gastos de comunicaciones por leveraging las infraestructuras locales de los proveedores de servicio que soportan dialup, ISDN, cable de módem, DSL, o el acceso inalámbrico al Internet o la red privada del proveedor.

Cuando implementen una arquitectura de acceso remoto de VPN, una consideración importante es donde iniciar la construcción de un túnel y la encriptación. ¿Debería el

Marcos Huerta S.

96


túnel iniciar en el ordenador personal de cliente o en una red de acceso al servidor (NAS) operado por el proveedor de servicio VPN? En un modelo iniciado por cliente, el túnel encriptado es establecido por el software de cliente usando IPSec, L2TP, o PPTP, así haciendo la red del proveedor de servicio únicamente un medio de transporte a la red corporativa. Una ventaja de un modelo iniciado por cliente consiste en que "la última milla" red de acceso del proveedor de servicio es usada para tener acceso al punto del proveedor de presencia (POP) asegurada. Una desventaja del modelo iniciado por cliente es la necesidad de manejar el software en máquinas de cliente.

En un modelo NAS-iniciado, un usuario remoto tiene acceso a la POP del proveedor de servicio, es autenticado por el proveedor de servicio, y, por su parte, inicia un túnel seguro a la red corporativa de los POP con una arquitectura NAS-iniciada, la VPN inteligentes reside en la red del proveedor de servicio. No hay ningún software de cliente de usuario final para organizar un mantenenimiento, así eliminando cuestiones de manejo de cliente asociadas con el acceso remoto. Los inconvenientes, sin embargo, son la carencia de la seguridad en la red de acceso local que conecta del cliente a la red de proveedor de servicio y la necesidad de interfuncionar con servidores del proveedor. La figura nro.23 muestra a una topologia de acceso remoto de VPN para una compañía de venta al público. La compañía usa tanto túneles iniciados por cliente como NASiniciados.

Figura Nro.23 Un

Acceso Remoto VPN para una Compañía de Venta al Público

El Borde del Proveedor de Servicio Aunque el foco de este capítulo diseñe una topología lógica para una red de empresa, una rapida discusión del proveedor de servicio es garantizada en este punto. El Modelo de Red Compuesto Empresa incluye el módulo de borde del proveedor de servicio, y,

Marcos Huerta S.

97


aunque no se espere que usted diseñe este módulo como un diseñador de red de empresa, usted necesita que tener algún entendimiento de ello y ser capaz de seleccionar al proveedor apropiado (o proveedores) para sus clientes en el diseño. La selección de un proveedor de servicio es algo que usted debería considerar durante la fase de diseño lógica, que es el foco de esta parte (Fase II) de la metodologia. La Fase III se dirige al tema otra vez porque durante aquella fase usted debería hacer algunas selecciones definidas de tecnologías WAN, dispositivos, y proveedores.

En los primeros días de comunicaciones de datos, alli había compañías telefónicas regionales o nacionales y sus clientes, y nada más. La opción de un cliente del proveedor fue dictada por la posición. El nivel de servicio y fijación de precios fue dictado por el proveedor. Hoy, hay una amplia variedad de proveedores de servicio. Los niveles de servicio y la fijación de precios son más negociables.

Encontrar un proveedor que empareja con las necesidades y requerimientos de una empresa requiere un entendimiento bueno de estas necesidades y cultura de empresa y proveedor potencial. Muchos ISPs comienzan pequeños que ofrecen dialup y el servicio de módem a usuarios finales. Estos ISPs pueden no tener la esperiencia de soportar una empresa grande, aunque ellos puedan ser apropiados para usuarios de casa que tienen acceso a la red corporativa usando el software de VPN. Algún foco de ISPs sobre todo en la recepción de servidores y no apoya a usuarios finales. Algunos ISPs son realmente proveedores de servicio de red (NSPs), el que significa que su negocio principal se conecta otro ISPs más bien que empresas o usuarios finales. La selección de proveedores para su diseño de red requiere que usted entienda cuál de estos tipos de servicios usted realmente necesita.

El ISPs y NSPs son a veces clasificados como la Capa 1 hasta Capa 5. Aunque estas categorías no tengan el significado universal, si un proveedor llama a esto proveedor Capa 1 y usted busca a un proveedor barato para conectar una pequeña oficina o a casa, entonces usted sabe mirar en otra parte. La Capa 1 ISPs son grandes

e

internacionales proveedores, mientras que la Capa 5 ISPs es pequeña, proveedores especializados, a veces localizados en una ciudad o área rural. Un proveedor de Capa 5 podría ser tan pequeño como una cafetería de Internet.

Una diferencia importante entre las capas tiene que ver con la relación que un proveedor tiene con otro ISPs. Usando una definición económica del punto (más bien que la definición BGP), una relación de punto significa que dos ISPs no cobran el uno al otro para llevar el tráfico de cada uno. Ellos son tanto del mismo tamaño como es su mutua ventaja para dejar a sus clientes tener el acceso el uno al otro, sin preocuparse de la facturación. Este se diferencia de la otra relación ISP común, que es un proveedor-

Marcos Huerta S.

98


cliente, donde ISP más pequeño paga al ISP más grande por el privilegio de enviar el tráfico por la red del ISP más grande. Este a menudo es llamado comprando el tránsito.

Un proveedor de Capa 1 no compra el tránsito. Un proveedor de Capa 1 tiene un centro de operaciones de red de 24/7 y un backbone nacional o internacional con al menos la conectividad de DS-3, y más como OC-3 a OC-48. El proveedor consigue todas sus rutas bilateral mirando detenidamente arreglos. Sus clientes son principalmente otros proveedores, por esto puede soportar una empresa grande también. Los ejemplos de los proveedores de Capa 1 incluyen UUNet, Cable & Wireless (C&W), Sprint, Qwest, Verio, Level 3, and AT&T. Los proveedores de Capa 2 también tienen backbone de alto ancho de banda y operaciones 24/7, pero ellos son limitados con una presencia regional o nacional y ellos compran el tránsito (a menudo en un descuento por paquete) de un proveedor de Capa 1 el tráfico que va fuera de la región. Un proveedor de Capa 2 consigue todas sus rutas regionales por mirar detenidamente arreglos. Los ejemplos de los proveedores de Capa 2 incluyen SBC, Earthenlaces, y AOL.

Un proveedor de Capa 3 es típicamente un proveedor regional para una región pequeña o de tamaño medio. Por ejemplo, el Inicio de Sesión de América es un proveedor de Capa 3 en la región de Noreste de los Estados Unidos. Un proveedor de Capa 3 compra el tránsito de múltiple proveedores y dirige por defecto tres tabla de enrutamiento por defeecto. No hay ninguna definición general de Capa 4 o Capa 5, pero la Capa 4 podría ser un proveedor metropolitano que es multihomed a dos proveedores regionales, y la Capa 5 podría ser un proveedor pequeño, solo-homed que conecta a usuarios finales vía dialup, módem, o servicio inalámbrico.

En este punto del proceso de diseño, usted debería haber analizado requerimientos y topologías al grado que usted tiene una idea buena de la capa que usted necesitará. Durante la fase de diseño lógico, usted debería comenzar a hacer una lista de criterios para seleccionar a los proveedores y desarrollar un plan y poner el estándar para evaluar a candidatos. Investigue la disponibilidad de proveedores de servicio en las regiones relevantes y comience a pedir informes. Esté específico en sus peticiones de la información de candidatos. Priorice que la información solicitada y indique que tan rápidamente usted necesita una respuesta. Usted también puede querer pedir referencias y comenzar a hacer preguntas sobre el proveedor de otros usuarios en la región. Ver el "La selección de un Proveedor de Servicio WAN" sección de la metodologia la parte 11, "Seleccionando Tecnologías y Dispositivos para Redes de Empresa," para más información en este tema.

Marcos Huerta S.

99


Diseño de Topologías de Red Seguras Esta sección habla de la seguridad de red con relación a topologías de red. La parte 8 se habla mas detalladamente como se implementa la seguridad a la red. El foco de esta sección es topologías lógicas, pero la seguridad física también es brevemente mencionada.

La planificación para la Seguridad Física Cuando desarrolle la topología lógica de una red, usted debería comenzar a conseguir una idea de donde el equipo será instalado. Usted debería comenzar a trabajar con su cliente de diseño en seguida para asegurarse que el equipo crítico será instalado en cuartos de computadora que tienen la protección de acceso no autorizado, robo, vandalismo, y catástrofes como inundaciones, fuegos, tormentas, y terremotos. La seguridad física no es realmente un aspecto del diseño de red lógico, pero es mencionado aquí porque su topología lógica podría tener un impacto en ello, y porque la planificación para la seguridad física debería comenzar en seguida, por si haya mas adelante tiempo para construir o instalar mecanismos de seguridad.

Reuniendo Objetivos de Seguridad con Topologías de Firewall Un firewall es un dispositivo que funciona como cortafuegos entre redes, permitiendo o denegando las transmisiones de una red a la otra. Un firewall puede ser un router con listas de control de acceso (ACLs), una caja de hardware dedicada, o software que corre en un ordenador personal o sistema UNIX. Un firewall debería ser colocado en la topología de red de modo que todo el tráfico desde fuera de la red protegida debiera pasar por el firewall. Una política de seguridad especifica qué tráfico está autorizado a pasar por el firewall.

Los firewall son sobre todo importantes en el límite entre la red de empresa y el Internet. Una topología de firewall básica es simplemente un router de tráfico con una conexión WAN al Internet, una conexión LAN a la red de empresa, y software que tiene rasgos de seguridad. Esta topología elemental es apropiada si su cliente tiene una política de seguridad simple. Las políticas de seguridad simples pueden ser puestas en práctica en el router de tráfico con ACLs. El router de tráfico también puede usar a NAT para esconder direcciones internas de hackeres de Internet.

Para clientes que necesitan publicar datos públicos y proteger datos privados, la topología de firewall puede incluir una LAN pública que recibe web, FTP, DNS, y servidores SMTP. La literatura de seguridad más vieja a menudo se refería a la LAN público como la zona de comercio libre, que es un nombre bueno para ello. Lamentablemente, mas apropiado el término la zona desmilitarizada (DMZ) se ha hecho más popular. La literatura de seguridad se refiere a un host en el DMZ como un host de

Marcos Huerta S.

100


bastion, un sistema seguro que soporta un número limitado de aplicaciones para uso de afuera. El host de bastion sostiene datos que los de afuera pueden tener acceso, como páginas Web, pero son fuertemente protegidos de los usuarios de afuera usándolo para algo además de sus objetivos limitados.

Para clientes más grandes, es recomendado esto usted usa un firewall dedicado además de un router entre el Internet y la red de empresa. Para maximizar la seguridad, usted puede correr caracteristicas de seguridad en el router y en el firewall dedicado. (Para maximizar la performance, por otra parte, usted no puede correr caracteristicas de seguridad en el router) La figura 5-16 muestra a una topologia DMZ segura.

Figura Nro.24 Una Topologia DMZ

Una topología alternativa debe usar dos routers como los firewalls y ubicarlo entre el DMZ, como mostrado en La figura nro 25. Esta topología es llamada una topología de firewall de tres partes. Una desventaja con este acercamiento es que la configuración en los routers podría ser compleja, consistiendo en muchos ACLs para controlar el flujo de tráfico de la red privada y el DMZ. Otra desventaja es que el flujo de tráfico de la empresa se conecta a la red por el DMZ. El DMZ conecta a los servidores públicos que pueden estar comprometidos y acto que lanzan ataques en la red de empresa. Usted puede reforzar esta topología usando routers con ACLs simple al uno o el otro al final del DMZ y también incluso firewall al uno o el otro al final que son configurados con ACLs más complejas. También, los host de bastiones dentro del DMZ deberían dirigir el software del firewall y ser configurados para un determinado limite de servicios.

Figura Nro. 25 Topología de Firewall de tres Partes

Marcos Huerta S.

101


Resumen Este capítulo se concentró en técnicas para desarrollar una topología para un diseño de red. El diseño de una topología de red es el primer paso en la fase de diseño lógico de la metodología de diseño de red top down. Diseñando una topología lógica antes de una realización física, usted puede aumentar la probabilidad de encontrar los objetivos de un cliente para escalabilidad, adaptabilidad, e interpretación.

Este capítulo habló de cuatro características de topologías de red: jerarquía, modularidad, redundancia y seguridad. Todas estas características pueden ser aplicadas a campus como a empresa diseño WAN. Las características no son mutuamente exclusivas. Su objetivo debería ser de diseñar arquitecturas de red jerárquicas, modulares, redundantes, y seguras basadas en los objetivos de su cliente.

La jerarquía y la modularidad le dejan desarrollar una red que consiste en muchos componentes de interrelaciones en una manera fashion y estructurada. La utilización de un modelo jerárquico puede ayudarle a maximizar la performance de red, reducir el tiempo de implementar y fallas de un diseño, y minimizar gastos.

Los diseños de red redundantes le dejan encontrar requerimientos para la disponibilidad de red duplicando componentes de red. La redundancia elimina un simple puntos de falla en la red. La redundancia también facilita la carga compartida que aumenta la performance de la red. La redundancia añade la complejidad y el costo de la red, sin embargo, y debería ser diseñado con el cuidado.

Dependiendo de su particular diseño de red, usted debería planear una topología segura que protega routers core, puntos de demarcación, tendido de cables, switches, servidores, etcétera. La adición de uno o varios firewall a su topología puede ayudarle a proteger redes de empresa de los ataques de afuera .

Después de completar una topología lógica para un cliente, usted debería seguir en la fase de diseño lógico diseñando el direccionamiento y nombramiento del modelo de red, selección de conmutación y protocolos de enrutamiento, y desarrollo de seguridad de red y estrategias de manejo. Estos temas son cubiertos en los siguientes fases. Haciendo un trabajo cuidadoso en la fase de diseño lógico puede aliviar su transición en el diseño de la realización física de la red. Esto también puede prepararle para el trabajo de seleccionar los correctos productos y tecnologías para su cliente.

Marcos Huerta S.

102


Parte 6. Diseño de un modelo de direccionamiento Esta parte proporciona pautas para adjudicar direcciones y nombres a componentes de redes, incluso redes, subredes, routers, servidores, y sistemas de final. En esta parte se enfoca en el Protocolo de Internet (IP) la dirección y el nombramiento. Para beneficiarse más de este capítulo, usted debería tener ya un entendimiento básico de la dirección de IP.

Este capítulo ilustra la importancia de usar un modelo estructurado para dirección de capa de red y nombramiento. Sin la estructura, es fácil quedarse sin direcciones, desperdiciar direcciones, introducir direcciones duplicadas y nombres, y direcciones de uso y nombres que son difíciles de manejar. Para encontrar los objetivos de un cliente para escalabilidad, performance, y manejabilidad, usted debería asignar direcciones y nombres sistemáticamente.

Este capítulo también demuestra la importancia de desarrollar políticas y procedimientos para direccionamiento y nombramiento. Las políticas a menudo implican un plan para distribuir autoridades para direccionamiento y nombramiento para evitar que un departamento tenga que manejar todas las direcciones y nombres. Una central de autoridad pueden asignarse por bloques de direcciones y nombres en una manera jerárquica a departamentos y sucursales.

Pautas para Asignar Direcciones de Capa de Red Las direcciones de capa de red deberían ser planeadas, manejadas, y documentadas. Aunque un sistema final pueda aprender su dirección dinámicamente, no existe ningunos mecanismos para asignar a la red o números de subnet dinámicamente. Estos números deben ser planeados y administrados. Muchas redes añejas donde todavía existen direccionamiento no fue planeada o documentada. Estas redes son difíciles cuando fallan y no escalan.

La lista siguiente proporciona algunas reglas simples para el direccionamiento para la capa de red que le ayudará a la escalabilidad de arquitecto y manejabilidad en un diseño de red. Estas reglas son descritas más detalladamente en secciones posteriores de este parte. Ø

Diseñe un modelo estructurado para direccionamiento antes de asignar cualquier dirección.

Ø

Váyase del cuarto del crecimiento del modelo de direccionamiento. Si usted no planea el crecimiento, usted debería volver a numerar más tarde muchos dispositivos, que es una labor intensa .

Ø

Asigne bloques de direcciones en una manera jerárquica el cual es buena para la escalabilidad y la disponibilidad.

Marcos Huerta S.

103


Ø

Asigne bloques de direcciones basadas en la red física, no en el ingreso de grupo, para evitar problemas cuando los grupos o los individuos se mueven.

Ø

Si el nivel de manejo de dirección de red de regional y sucursales es alto, usted puede delegar autoridad para el direccionamiento regional y redes de sucursal, subredes, servidores, y sistemas finales.

Ø

Para maximizar la flexibilidad y minimizar la configuración, use la dirección dinámica para sistemas finales.

Ø

Para maximizar la seguridad y la adaptabilidad, use direcciones privadas con la Traducción de Dirección de Red (NAT) en ambientes IP.

Usando un Modelo Estructurado para el Direccionamiento de Capa de Red Un modelo estructurado para direccionamiento significa que las direcciones son significativas, jerárquicas, y planeadas. Las direcciones IP que incluyen un prefijo y parte host son estructuradas. La asignación de un número de red IP a una red de empresarial, y luego subneteando el número de red, y subneteando las subredes, es un modelo (jerárquico) estructurado para la dirección IP.

Un modelo estructurado claramente documentado para el direccionamiento facilita el manejo y la solución de problemas. La estructura se hace más fácil para entender mapas, hacer operar el software de manejo de red, y reconocer dispositivos analizando los rastros de un protocolo e informes. Las direcciones estructuradas también facilitan la optimización de red y la seguridad porque ellos hacen más fácil para implementar filtros de red en los firewall, routers, e switches.

Muchas compañías no tienen ningún modelo para el direccionamiento. Cuando no hay ningún modelo, y las direcciones son adjudicadas de un modo desordenado, los problemas siguientes pueden ocurrir: Ø

Red duplicada y direcciones de host

Ø

Las direcciones ilegales que no pueden ser ruteadas en el Internet

Ø

No hay suficientes direcciones en totales, o por grupo.

Ø

Las direcciones que no pueden ser usadas, y gastadas también

La Administración de Direcciones por una Autoridad Central Los

Sistemas

de

Información

Corporativos

(SON)

o

redes

empresariales

departamentales pueden desarrollar un modelo global para el direccionamiento de la Capa de red. Como el diseñador de red, usted debería ayudar al departamento ES desarrollar el modelo. El modelo debería identificar números de red para el core de la red empresarial, y los bloques de las subredes para capas de acceso y la distribución. Dependiendo de la estructura organizativa de la empresa, los administradores de la red dentro de cada región o sucursal pueden dividir en subredes.

Marcos Huerta S.

104


Las direcciones de IP son públicas o privadas. Las direcciones públicas son globalmente únicas y son registradas con unas autoridades de enumeración. Las direcciones privadas nunca son ruteadas en el Internet global y son asignadas de un rango especial, documentada en la Petición de Comentarios (RFC) 1918. Las direcciones privadas son cubiertas más detalladamente en la sección "Usando Direcciones Privadas en un Ambiente IP"más adelante.

Temprano en el proceso de diseño de dirección, usted tiene que contestar estas preguntas en cuanto a las direcciones público contra direcciones privadas: Ø

¿Son públicos, privados, o son ambos tipos de dirección requeridos?

Ø

¿Cuántos sistemas finales necesitan el acceso a la red privada sólo?

Ø

¿Cuántos sistemas finales tienen que ser visibles a la red pública también?

Ø

¿Cómo van a ocurrir la traducción entre direcciones privadas y públicas?

Ø

¿Dónde en la topología de la red va a existir el límite entre direcciones privadas y públicas?

Si usted necesita un número grande de direcciones públicas, usted trabajará con uno de tres registros regionales que asignan bloques grandes del espacio de dirección de IP para el Internet: Ø

El Registro americano para Números de Internet (ARIN) sirve las Américas y algunas otras posiciones que tienen todavía un registro regional. Refiérase a www.arin.net para más información.

Ø

Réseaux IP Européens Centro de Coordinación de Red (RIPE) (NCC) sirve Europa. Refiérase a www.ripe.net para más información.

Ø

Asia Pacific Network Information Center (APNIC) sirve para Asia región de Océano Pacífico. Refiérase a www.apnic.net para más información.

El termino de dirección de proveedor independiente se refiere a direcciones que son asignadas directamente por uno de los registros regionales. En la práctica, la mayor parte de empresas no usan direcciones del espacio de dirección independiente del proveedor. Una organización tiene que manifestarse esto tendrá a aproximadamente 8000 o más host conectados por Internet antes de que se haga elegible para el espacio de dirección independiente del proveedor. Por lo tanto, la mayor parte de empresas trabajan con un Proveedor de Internet (ISP) para obtener direcciones públicas, en cuyo caso sus direcciones son la parte del espacio de dirección asignado por el proveedor. La empresa usa estas direcciones mientras permanece en un suscriptor de proveedor. El cambio a un nuevo proveedor requiere la renumeración, que es un problema con direcciones asignadas por el proveedor. Sin embargo, a menos que usted tenga a numerosos hosts que necesitan las direcciónes públicas, usted usará probablemente direcciones asignadas por el proveedor.

Marcos Huerta S.

105


Distribuyendo Autoridad para Direcciónamiento Uno de los primeros pasos en el desarrollo de un direccionamiento y nombramiento del modelo debe determinar quién implementara el modelo. ¿Cuál administrador de red asigna las direcciones y configurará dispositivos? Cual direccionamiento y configuración será realizado por administradores de red inexpertos, usted debería guardar el modelo simple.

Si hay pocos administradores de red, (que hay en muchas organizaciones), entonces la simplicidad es importante así como minimizando la cantidad de configuración requerida. En estas situaciones, los direccionamientos dinámicos es una recomendación buena. El direccionamiento dinámico, como el Protocolo de Configuración de Host Dinámico (DHCP) para ambientes IP, permite que cada sistema final aprenda su dirección automáticamente. Muy poco, es cuando la configuración es necesaria o requerida.

Si los administradores de red de regional y las sucursales son inexpertos, usted podría pensar no delegar autoridades para el direccionamiento y nonbramiento. Muchos de las pequeñas y medianas compañías mantiene el control estricto de direccionamiento y nombramiento en un nivel (centralizado) corporativo. El control de mantenimiento estricto evita errores que pueden ser causados por los usuarios frustrados y conectarse fallas a la red. El control de mantenimiento estricto puede ser desafiante, especialmente como los administradores de red regionales y los usuarios se hacen más expertos con las redes y empiezan a instalar dispositivos que pueden asignar direcciones.

Usando Direccionamiento Dinámico para Sistemas Finales El direccionamiento dinámico reduce las tareas de configuración requeridas para conectar sistemas finales de redes. El direccionamiento dinámico también soporta a usuarios que cambian de oficinas con frecuencia, viajes, o trabajan en casa de vez en cuando.

Con

el

direccionamiento

dinámico,

una

estación

puede

aprender

automáticamente que segmento se conecta a la red actualmente, y ajustar su dirección de capa de red en consecuencia.

El direccionamiento dinámico es construida para protocolos de escritorio como AppleTalk y Novell NetWare. Los diseñadores de estos protocolos reconocieron la necesidad de minimizar tareas de configuración de modo que los usuarios inexpertos pudieran configurar pequeñas redes. Los protocolos IP, por otra parte, fueron diseñados para correr en computadoras manejadas por administradores de sistema con experiencia, y no apoyaron al principio el direccionamiento dinámico. En años recientes, sin embargo, la importancia del direccionamiento dinámico ha sido reconocida, y la mayor parte de compañías usan DHCP para minimizar tareas de configuración para sistemas finales de IP.

Marcos Huerta S.

106


Muchas redes usan una combinación de la direcciónes estática y dinámica. Las direcciones estáticas son típicamente usadas para servidores, routers y administración de sistema de red. Aunque los switches trabajen debajo de la capa de red en el enlace de datos y capas físicas, esto es también una idea buena de asignar una dirección de capa de red estática a switches para propositos de dirección. Las direcciones dinámicas son típicamente usadas para sistemas finales, incluso teléfonos de IP y estaciones de trabajo.

Según Cisco, las direcciones estáticas son usadas en manejo de redes y los módulos de campus área funcional en el Modelo de Red Compuesto Empresarial Cisco. Las direcciones Estáticas también son usadas en todos los módulos del borde de empresa área funcional (el e-comercio, conectividad de Internet, VPN/remote-access, y módulos WAN).

Otros criterios para usar direccionamiento estáticos vs dinámico incluyen lo siguiente: Ø

El número de sistemas finales. Cuando hay más de aproximadamente 30 sistemas, las direcciónes dinámica es por lo general preferible.

Ø

Renumeración. Si probablemente usted tendrá que volver a numerar sistemas en el futuro y hay muchos sistemas finales, la asignación de dirección dinámica es la mejor opción. La renumeración para direcciones públicas se hará necesaria si nuevo ISP es seleccionado. Además, usted puede planear volver a numerar porque el plan corriente no es bien estructurado o se quedará sin números muy pronto.

Ø

Alta Disponibilidad. Las direcciones de IP estáticamente asignadas están disponibles en cualquier momento. Las direcciones de IP dinámicamente asignadas tienen que ser adquiridas de un servidor primero. Si el servidor falla, una dirección no puede ser adquirida. Para evitar este problema, usted puede desplegar servidores DHCP redundantes o usar direcciones estáticas.

Ø

Seguridad. Con la asignación de direcciónes dinámicas, en la mayor parte de casos, cualquier dispositivo que se conecte a la red puede adquirir una dirección válida. Este impone algún riesgo a la seguridad y puede significar que la dirección dinámica no es apropiada para una compañía con una política de seguridad muy estricta.

Ø

Rastreo de dirección. Si una política de seguridad o dirección requiere que las direcciones sean rastreadas, la dirección estática podría ser más fácil para poner en práctica que la dirección dinámica.

Ø

Parámetros adicionales. Si los sistemas finales necesitan la información más allá de una dirección, la dirección dinámica es útil porque un servidor puede proporcionar parámetros adicionales a clientes junto con la dirección. Por ejemplo, un servidor DHCP proporciona una máscara subnet, un default gateway, y la información opcional como una o varias direcciones de servidor de nombre, incluso

Marcos Huerta S.

107


el Sistema de Nombre de Dominio (DNS) y Servicio de Nombramiento de Internet de Windows (WINS) direcciones de servidor.

Direccionamiento Dinámico AppleTalk El AppleTalk era el primer protocolo de red para soportar el direccionamiento dinámico. El direccionamiento dinámico de AppleTalk inspiró el direccionamiento dinámico IP, así aprendiendo un poco sobre el direccionamiento de AppleTalk le ayudará a entender esquemas modernos para el direccionamiento IP dinámico.

Una dirección de estación de capa de red de AppleTalk consiste en un número de red 16 bits y un nodo de 8 bits ID. La dirección es escrita como nodo de red; por ejemplo, 2210.15 significas 15 de estaciones y 2210 en red. Cuando una estación de AppleTalk inicializa, esto dinámicamente elige su dirección de capa de red de 24 bits, basada parcialmente en la información que esto solicita de los routers en el segmento de red. Un administrador de la red configurara los routers con un rango de cable y uno o varias zonas para cada segmento de red. Los sistemas finales no requieren ninguna configuración.

Después de que una estación de AppleTalk ha elegido una dirección de capa de red, esto salva esta información en la RAM "batería backed-up", que también es llamado la RAM de parámetro, o el PRAM. Cuando una estación de AppleTalk inicializa, esto chequea para ver si esto tiene una dirección en el PRAM. Si esto hace, este usa aquella dirección (después de confirmarque que la dirección es todavía única). Usando la misma dirección después de que reanudar facilita la dirección de red. Sin esta caracteristica, sería más difícil manejar estaciones de AppleTalk, porque una estación recibiría una nueva dirección cada vez que esto inicializó.

Direccionamiento Dinámico Novell NetWare Una dirección de estación de capa de red de NetWare consiste en un número de red de 4 bytes y un nodo ID de 6 bytes. El nodo ID de 6 bytes es el mismo como el Control de Acceso de Medios de la estación (MAC) esta dirección se encuentra en su tarjeta de interfaz de red (NIC). Como una estación NetWare usa su dirección de MAC para su nodo ID, ninguna configuración del nodo ID es requerido.

Un administrador de la red configura routers y servidores en una red de NetWare con el número de red de 4 bytes para un segmento de red. Cuando una estación NetWare inicializa, esto envía un paquete "consiguen al servidor más cercano". Los servidores que responden a este mensaje informan a la estación del número de red para el segmento de red local. (Si no hay ningunos de los servidores en el segmento de la estación, un router responde a la petición "consiguen al servidor más cercano".

Marcos Huerta S.

108


Los routers pueden ser por lo general configurados para retrasar sus respuestas para evitar adelantarse el derecho de un servidor ocupado de responder primero.)

Direccionamieno Dinámica IP Cuando los protocolos IP fueron desarrollados primero, se requirió que un administrador de red configurara a cada host con su dirección de IP única. A mediados de los años 1980,

los

protocolos

fueron

desarrollados

para

soportar

estaciones

diskless

dinámicamente aprendiendo una dirección, que era necesaria porque una estación diskless no tiene ningún almacenaje para salvar una configuración. Estos protocolos incluyeron el Protocolo de Resolución de Dirección Inverso (RARP) y BOOTP. El BOOTP ha evolucionado en DHCP, que ha ganado la popularidad considerable desde finales de los años 1990.

El RARP es limitado en el alcance; la única información devuelta a una estación usando RARP es su dirección de IP. El BOOTP es más sofisticado que RARP, y opcionalmente devuelve la información adicional, incluso la dirección de default gateway, el nombre de un archivo de boot para descargar, y 64 bytes de la información específica de vendedor.

El Protocolo de Configuración de Host Dinámico El DHCP está basado en BOOTP. Los hosts de BOOTP pueden interfuncionar con hosts de DHCP, aunque DHCP añada muchos realces a BOOTP, incluso un campo de información específico de vendedor más grande (llamado el campo de opciones en DHCP) y la asignación automática de direcciones de capa de red reutilizables.El DHCP ha evitado BOOTP en la popularidad, probablemente porque es más fácil configurar. A Diferencia de BOOTP, DHCP no requiere que un administrador de red mantenga una tabla de dirección de MAC-to-IP.

El DHCP usa un modelo de cliente/servidor. Los servidores asignan direcciones de capa de red y salvan la información sobre cual direcciones han sido asignadas. Los clientes dinámicamente solicitan parámetros de configuración de servidores. El objetivo de DHCP es que los clientes no deberían requerir ninguna configuración manual. Además, el administrador de la red no debería entrar en ningún parámetro de configuración por cliente en servidores. El DHCP apoya tres métodos para la asignación de dirección de IP: Ø

Asignación automática. Un servidor DHCP asigna una dirección de IP permanente a un cliente.

Ø

Asignación dinámica. Un servidor DHCP asigna una dirección de IP a un cliente durante un período limitado del tiempo.

Ø

Asignación manual. Un administrador de red asigna una dirección de IP permanente a un cliente, y DHCP es usado simplemente para comunicar la

Marcos Huerta S.

109


dirección asignada al cliente. (La asignación manual es raramente usada porque esto requiere la configuración por cliente, que las asignaciones automáticas y dinámicas no requieren.)

La asignación dinámica es el método más popular, en parte porque sus caracteristicas de reasignación soporta ambientes donde los hosts no estan en línea todo el tiempo, y hay más hosts que direcciones. Con la asignación dinámica, un cliente solicita el uso de una dirección durante un período limitado del tiempo. El período de tiempo es llamado un arriendo.

El mecanismo de asignación garantiza no reasignar aquella dirección dentro del tiempo solicitado, e intenta retornar a la misma dirección de capa de red cada vez que el cliente solicita una dirección. El cliente puede ampliar su arriendo con peticiones subsecuentes. El cliente puede decidir abandonar su arriendo enviando a un mensaje de liberación de DHCP al servidor.

DHCP Relay Agent Tan mencionado, un router puede actuar como un DHCP relay agent. Este significa que el router pasa mensajes de broadcast de DHCP del clientes a servidores DHCP que no están en la misma subred que los clientes. Este evita una exigencia para un servidor DHCP para residir en cada subred con clientes.

Con routers Cisco, usted puede usar el comando de helper-ip address en cada interfaz del router donde los clientes residen para hacer que el router se hiciera un relay agent de DHCP. Un comando de parámetro de dirección debería señalar la dirección de IP del servidor DHCP. Alternativamente, la dirección puede ser una dirección de broadcast de modo que los broadcast de router de DHCP descubran el mensaje en la red especificada. (Una dirección de broadcast debería ser usada sólo si el servidor está en una red directamente conectada porque los routers modernos no envian broadcast dirigidos a otras redes.)

Cuando un router transmite un mensaje descubrir otra red o subred, el router coloca la dirección de IP para el interfaz en el cual el mensaje llegó a la dirección de gateway (giaddr) el campo de cabecera DHCP. El servidor DHCP puede usar la información giaddr para determinar de cual dirección asignada debería venir.

La Versión 6 de IP Dirección Dinámica Como IPv4, y la versión 6 (IPv6) de IP soporta tanto dirección estática como dinámica. El IPv6 llama la autoconfiguración de dirección dinámica. La autoconfiguración de IPv6 puede ser stateful o stateless.

Marcos Huerta S.

110


Con un método de autoconfiguración stateful, los hosts obtienen las direcciones y otros parámetros de un servidor. El servidor almacena una base de datos que contiene la información necesaria y mantiene el control de asignaciones de dirección. Esto debería parecer familiar. El modelo de autoconfiguración stateful es definido en DHCPv6.

La autoconfiguración stateless no requiere ninguna configuración manual de hosts, mínimos (o no) la configuración de routers, y no de servidores. Ya que para un ingeniero de red quién no está preocupado sobre que direcciones son usadas, mientras ellos son únicas y roteable, la autoconfiguración stateless ofrece muchas ventajas. Discutir la autoconfiguración stateless en RFC 2462. Es similar a AppleTalk direccionamiento dinámico.

Con la autoconfiguración stateless, un host genera su propia dirección que usa la información en la localidad disponible más la información anunciada por routers. El proceso comienza con la generación de un enlace-local para un interfaz. El enlace-local es generada combinando el prefijo local del enlace conocido (FE80::/10) con un identificador de interfaz de 64 bits. (Para más información sobre prefijos IPv6, ver el "Jerarquía en Direcciones de la Versión 6 IP".)

El siguiente paso determina la unicidad de la dirección provisional que ha sido sacada combinando el prefijo de dirección de enlace-local con el identificador de interfaz. El host transmite un mensaje de Solicitación Vecino con la dirección provisional como la dirección objetivo. Si otro host usa esta dirección, un Anuncio Vecino es devuelto. En este evento, de autoconfiguración de parada y un poco de intervención manual es requerido. (Como la dirección está por lo general basada en una dirección de NIC, los duplicados son muy improbables.) Si ningunas respuestas son devueltas, la dirección provisional es considerada la conectividad única, y IP con hosts locales es posible ahora.

El paso final del proceso de autoconfiguración envuelve escuchar mensajes de Anuncio del router de tráfico IPv6 que los routers transmiten periódicamente. Un host también puede forzar un Anuncio de Router inmediato transmitiendo un mensaje de Solicitación de Router con dirección de multicast a todo-routers. La Publicidad de Router contiene el cero o más opciones de Información de Prefijo que contienen la información usada por el host para generar una dirección de site- local que tiene un alcance que es limitado con el site-local. La Publicidad de Router también incluye una dirección global con el alcance ilimitado. El anuncio también puede decir a un host como usar un método stateful para completar su autoconfiguración.

Marcos Huerta S.

111


Configuraciín de redes Cero La Configuración Cero que conecta a la red (Zeroconf) el grupo de trabajo del Internet Engineering Task Force (IETF) ha llevado el concepto de la dirección dinámica a un paso adelante que DHCP. Como AppleTalk e IPv6, Zeroconf puede asignar direcciones de IP sin un servidor. Esto también puede traducir entre nombres y direcciones de IP sin un servidor DNS. Para manejar el nombramiento, de Zeroconf multiechan DNS (mDNS), que soporta multicast que se dirige para la resolución de nombre.

Hasta ahora, el trabajo de Zeroconf ha sido limitado con pequeñas redes. El Zeroconf es una tecnología de enlace-local. Las direcciones locales del enlace y los nombres son significativos sólo en una red particular. Ellos no son globalmente únicos. El Zeroconf es apropiado para casa y pequeñas redes de oficina, ad hoc redes en reuniones y conferencias (redes sobre todo inalámbricas), sistemas empotrados como en un coche, y siempre que dos dispositivos tengan que compartir espontáneamente o intercambiar la información.

Aunque el objetivo principal de Zeroconf sea hacer el ordenador personal corriente que conecta a la red más fácil para usar, según el Zeroconf la página de inicio del grupo trabajador (www.zeroconf.org), un objetivo a largo plazo es "permitir la creación de completamente nuevas clases de productos conectados a una red, productos que hoy no serían simplemente comercialemente viables debido a la molestia y gastos de apoyo implicados en fundación, configuración, y mantenimiento de una red."

El Zeroconf tiene muchas ventajas, pero un riesgo potencial consiste en que esto interferirá con sistemas más estructurados para la dirección y llamará asignaciones, aunque el grupo de funcionamiento diga realmente que Zeroconf "debe coexistir elegantemente con redes configuradas más grandes" y que los protocolos Zeroconf "no deben causar el daño a la red cuando una máquina Zeroconf es conectada en una red grande." El Zeroconf tiene algunos rasgos intrigantes y, como el diseñador de red, usted debería tener un poco de familiaridad con ello. El Zeroconf puede solucionar varios problemas para pequeño, ad hoc conecta a la red, y es incorporado a algunos sistemas operativos, incluso Mac OS X. La Utilización de Direcciones Privadas en un Ambiente IP Las direcciones de IP privadas son direcciones que un administrador de red de empresa asigna a redes internas y hosts sin cualquier coordinación de un ISP o uno de los registros regionales. Un ISP o el registro proporcionan direcciones públicas para servidores de web u otros servidores que el acceso de usuarios externo, pero las direcciones públicas no son necesarias para hosts internos y redes. La dirección para hosts internos que tienen que tener acceso a servicios exteriores, como correo

Marcos Huerta S.

112


electrónico, FTP, o servidores de web, puede ser manejada por una Traducción de Dirección de Red (NAT). NAT es cubierto más tarde en esta sección.

En 1918 RFC, el IETF reserva los números siguientes para dirigirse a nodos en redes privadas internas: Clase A 10.0.0.0–10.255.255.255 Clase B

172.16.0.0–172.31.255.255

Clase C

192.168.0.0–192.168.255.255

Una ventaja de las direcciones de red privadas es la seguridad. Las direcciones de red privadas no acceden al Internet. De hecho, las direcciones de red privadas no debe ser anunciado al Internet porque ellos no son globalmente únicos. Por ser direcciones de red internas privadas, un poco de seguridad es conseguido. (La seguridad adicional, incluso firewall y sistemas de descubrimiento de intrusión, también debería ser desplegada.

Las direcciónes privadas también ayuda a encontrar objetivos para adaptabilidad y flexibilidad. La utilización de la dirección privada es más fácil para cambiar ISPs en el futuro. Si la dirección privada ha sido usada, moviendo a nuevo ISP, los únicos cambios de dirección requeridos están en el router o firewall que proporciona servicios de NAT y en cualquier servidor público. Usted debería recomendar la dirección privada a clientes que quieren la flexibilidad de cambiar fácilmente a ISP diferente en el futuro.

Otra ventaja de direcciones de red privadas consiste en que una red de empresa puede anunciar sólo un número de red, o un pequeño bloque de números de red, al Internet. Esto es la práctica buena para evitar anunciar muchos números de red al Internet. Uno de los objetivos de prácticas de Internet modernas es que los routers de Internet no deberían tener que manejar tablas de encaminamiento enormes. Cuando una red de empresa crece, el administrador de la red puede asignar direcciones privadas a nuevas redes, más bien que solicitar números de red públicos adicionales de un ISP o registro. Este evita aumentar el tamaño de la tabla de enrutamiento deInternet.

Los números de red privados dejan a un diseñador de red reservar direcciones de Internet escasas para servidores públicos. Durante los años 1990, cuando el Internet se hizo comercializado y popularizado, un tremendo susto hubo en la comunidad de Internet en cuanto a la escasez de direcciones. Las predicciones extremas fueron hechas debido a que no más direcciones estarían disponibles por la vuelta del siglo. A causa de este susto, dieron a muchas compañías (y muchos ISPs) un pequeño juego de direcciones que tenían que ser con cuidado manejadas para evitar la reducción. Estas compañías reconocen el valor de direcciones privadas para redes internas.

Marcos Huerta S.

113


Advertencias con Dirección Privada Aunque las ventajas de la dirección privada pesen más que las desventajas, es importante ser consciente de los inconvenientes. Un inconveniente consiste en que la externalización de la dirección de red es difícil. Cuando una compañía delega la responsabilidad de dirección de red a una compañía exterior, la compañía exterior típicamente establece consolas de red en su propio sitio que se comunican con dispositivos de funcionamiento entre redes dentro de la red del cliente. Con la dirección privada, sin embargo, las consolas no pueden alcanzar los dispositivos del cliente, porque ningunas rutas a redes internas son anunciadas al exterior. NAT puede ser usado para traducir las direcciones privadas a direcciones públicas, pero entonces pueden haber problemas con la interoperabilidad entre NAT y conectar a la red protocolos de dirección como el Protocolo de Dirección de Red Simple (SNMP).

Otro inconveniente para la dirección privada es la dificultad para comunicarse con compañeros, vendedores, proveedores, etcétera. Como las compañías de compañero también usan probablemente direcciones privadas, construyendo extranets se hace más difícil. También, las compañías que combinan el uno con el otro afrontan una tarea difícil de volver a numerar cualquier dirección duplicada causada por ambas compañías usando las mismas direcciones privadas.

Una otra advertencia tener presente usando direcciones privadas es que es fácil olvidar de usar un modelo estructurado con las direcciones privadas. Los administradores de la red de empresa, que fueron restringidos una vez de direcciones que fueron con cuidado repartidas por ISPs y los registros, están excitados cuando ellos se mueven a la dirección privada y tienen toda red 10.0.0.0 a su disposición.

El entusiasmo no debería eclipsar la necesidad de asignar el nuevo espacio de dirección en una manera estructurada, jerárquica. La dirección jerárquica facilita la ruta summarization dentro de la red de empresarial, que disminuye el ancho de banda y el consumo por protocolos de enrutamiento, reduce el procesamiento en routers, y realza la elasticidad de red.

Traducción de Dirección de Red La Traducción de Dirección de Red (NAT) es un mecanismo IP que es descrito en el documento RFC 3022 para convertir direcciones de una red interior (direcciones privadas) a direcciones que son apropiadas para una red exterior (direcciones publicas), y viceversa. NAT es útil cuando los hosts que tienen que tener acceso a servicios de Internet tienen direcciones privadas. La funcionalidad de NAT puede ser implementadas en una aplicación separada, routers, o firewall.

Marcos Huerta S.

114


El administrador de NAT configura un pool de direcciones exteriores que pueden ser usadas para la traducción. Cuando un host interior envía un paquete, la dirección de la fuente es traducida dinámicamente a una dirección del pool de direcciones exteriores. NAT también tiene una provisión para direcciones estáticas para servidores que necesitan una dirección fija (por ejemplo, una web o envían a servidor que siempre debe mapear a la misma dirección conocida).

Algunos productos de NAT también ofrecen la traducción de puerto para mapear de varias direcciones a la misma dirección. Con la traducción de puerto, todo el tráfico de una empresa tiene la misma dirección. Los números de puerto son usados para distinguir conversaciones separadas. La traducción de puerto reduce el número de direcciones exteriores requeridas. La traducción de puerto es a veces llamada sobrecargando direcciones.

Cuando use NAT, todo el tráfico entre una red de empresa y el Internet debe pasar por la entrada de NAT. Por esta razón, usted debería asegurarse que la entrada de NAT tiene el rendimiento superior y bajo retardo, en particular si los usuarios de empresa dependen de vídeo de Internet o aplicaciones de voz. La entrada de NAT debería tener un procesador rápido que puede examinar y cambiar paquetes muy rápidamente. Tenga presente que, además de la modificación de direcciones de IP, una entrada de NAT debe modificar el IP, TCP, y sumas de control UDP. (Las sumas de control para TCP y UDP cubren una cabecera pseudo que contiene el origen y el destino de direcciones IP.)

En muchos casos, NAT también debe modificar direcciones de IP que ocurren dentro de la parte de datos de un paquete. Las direcciones de IP pueden aparecer en ICMP, FTP, DNS, SNMP, y otros tipos de paquetes. Como NAT tiene el trabajo de traducción de algo tan básico como direcciones de capa de red, puede ser complicado garantizar el comportamiento correcto con todas las aplicaciones. Una entrada de NAT debería ser a fondo probada en un ambiente piloto antes de que sea generalmente desplegado.

Usando un Modelo Jerárquico para Asignar Direcciones Un modelo de direcciónes jerárquica para aplicar la estructura a direcciones de modo que los números en la parte izquierda de una dirección se refieran a bloques grandes de redes o nodos, y los números en la parte derecha de una dirección se refieren a redes individuales o nodos. La dirección jerárquica facilita el encaminamiento jerárquica, que es un modelo para distribuir el conocimiento de una topología de red entre routers de redes. Con la encaminamiento jerárquica, ningún simple router necesita que entender la topología completa. Este parte se enfoca en dirección jerárquica y encaminamiento para ambientes IP, pero los conceptos se aplican a otros ambientes también.

Marcos Huerta S.

115


¿Por qué usar un Modelo Jerárquico para Direccionamiento y Enrutamiento? La parte 5 examinó la importancia de la jerarquía en el diseño de topología. Las ventajas de jerarquía en direccionamiento y encaminamiento del modelo son el mismo como aquellos para un modelo de topología: Ø

Apoya una solución fácil, mejoras, y manejabilidad.

Ø

Interpretación optimizada.

Ø

Convergencia de protocolo de encaminamiento más rápida.

Ø

Escalabilidad.

Ø

Estabilidad.

Ø

Menos recursos de red necesarios (CPU, memoria, buffers, ancho de banda, etcétera).

El direccionamiento jerárquico permite la sumarización(la agregación) de números de red. La sumarización permite que un router agrupe muchos números de red publicados en su tabla de enrutamiento. La sumarización realza la performance de red y la estabilidad. La dirección jerárquica también facilita la subred de longitud variable que enmascara (VLSM). Con VLSM, una red puede ser dividida en subredes de tamaños diferentes, qué ayudan a optimizar el espacio de dirección disponible.

Enrutamiento Jerárquica Enrutamiento jerárquica significa que el conocimiento de la topología de red y configuración es localizado. Ningún router solo tiene que entender como conseguir el uno al otro en el segmento de red. El enrutamiento jerárquica requiere que un administrador de red asigne direcciones en una manera jerárquica. Las direcciónes IP y el enrutamiento han sido algo jerárquicas durante mucho tiempo, pero en años recientes, como el Internet e intranet de empresa han crecido, se ha hecho necesario añadir más jerarquía.

Para entender la enrutamiento jerárquica en términos simples, considere el sistema telefónico. El sistema telefónico ha usado el enrutamiento jerárquica durante años. Cuando usted marca 541-555-1212 de un teléfono en Michigan, el interruptor telefónico en Michigan no sabe alcanzar este número específico en Oregon. El interruptor en Michigan simplemente sabe que el número no es en Michigan y adelante la llamada a una compañía telefónica nacional. Un interruptor en la compañía telefónica nacional sabe que 541 es para Oregon del sur, pero no sabe expresamente donde las llamadas a 555 deberían ir. Un interruptor en Oregon determina qué interruptor de central maneja el 555 prefijo, y aquellas rutas de interruptor la llamada a 1212.

Con los datos de la redes, es similar las decisiones son tomadas cuando un paquete viaja a través de una ruta de red. Sin embargo, en redes de IP tradicionales, las

Marcos Huerta S.

116


decisiones no podían ser completamente tan locales como las decisiones en el ejemplo telefónico. Hasta hace poco, las direcciones de IP para el Internet fueron adjudicadas en una manera no jerárquica. Por ejemplo, dos compañías en Oregon podrían tener la Clase C extensamente diferente los números de red, a pesar de que ellos ambos usan el mismo proveedor para alcanzar el Internet. Este significó que el proveedor tuvo que decir a todos los otros sitios de Internet sobre ambas compañías de Oregon. De este modo, a diferencia del ejemplo de sistema telefónico, un router en Michigan sabría alcanzar redes específicas en Oregon.

Enrutamiento de Interdominios sin Clase A mediados de los años 1990, el IETF e IANA realizaron que la carencia de un modelo jerárquico para asignar direcciones de red en el Internet era un problema de escalabilidad severa. Las tablas de enrutamiento de Internet crecía exponencialmente, y la cantidad de sobrecarga para tratar y transmitir las tablas era significativa. Para obligar el enrutamiento sobrecargado, se hizo claro que el Internet debe adoptar un esquema de dirección jerárquica y el enrutamiento. Para solucionar el elevado problema de enrutamiento, el Internet adoptó la enrutamiento de interdominios sin clases (CIDR) método para resumir rutas. El CIDR especifica que las direcciones de red de IP deberían ser adjudicadas en bloques, y que los routers en el Internet deberían agrupar rutas para reducir en la cantidad de información compartida por routers de Internet.

El documento RFC 2050 proporciona pautas para la asignación de dirección de IP por registros de Internet regionales e ISPs. RFC 2050 estados que:

Un proveedor de Internet obtiene un bloque del espacio de dirección de un registro de dirección, y luego asigna a sus direcciones a sus clientes desde dentro de aquel bloque basado en cada requerimiento del cliente. El resultado de este proceso es que las rutas a muchos clientes serán agregadas juntos, y aparecerán a otros proveedores como una ruta sola. Para la agregación de ruta para ser eficaz, los proveedores de Internet animan a clientes que se afilian a su red a usar el bloque del proveedor, y así volver a numerar sus computadoras. Tal estímulo puede hacerse un requerimiento en el futuro.

Al mismo tiempo que el IETF e IANA se dirigieran al problema de enrutamiento no jerárquica, ellos también se dirigieron al problema de la reducción de dirección de IP. Como mencionado en una sección anterior, el sistema de asignar direcciones en clases significó que muchas direcciones iban a gastar. El IETF desarrolló la dirección sin clases, que proporciona más flexibilidad en la especificación de la longitud de la parte de prefijo de un número de red de IP.

Marcos Huerta S.

117


Encaminamiento sin Clases Contra Encaminamiento de Classful Como mostrado en La figura nro 25, una dirección de IP contiene una parte de prefijo y una parte de Host. Los routers usan el prefijo para determinar el camino para una dirección de destino que no es local. Los routers usan la parte de host para alcanzar a host locales.

La Figura Nro. 25. Las Dos Partes de una Dirección de IP

Un prefijo identifica un bloque de números de host y es usado para enrutar aquel bloque. El enrutamiento tradicional, también conocida como enrutamiento classful, no transmite ninguna información sobre la longitud de prefijo. Con el enrutamiento de classful, los hosts y los routers calculan la longitud de prefijo mirando los pocos primeros bits de una dirección para determinar su clase. Los primeros bits para la Clase A por hasta las direcciones de la clase C son mostradas en la tabla siguiente.

Class

Primer

Prefix

Primer

A

bit = 0

is 8

octet

bits

is 1– 126

Class

Primer

Prefix

Primer

B

2 bits

is 16

octet

= 10

bits

is 128– 191

Class

Primer

Prefix

Primer

C

3 bits

is 24

octet

= 110

bits

is 192– 223

En implemetaciones tempranas de IP, los hosts de IP y los routers entendieron sólo tres longitudes de prefijo: 8, 16, y 24. Este se hizo una limitación cuando las redes crecieron, así subnetting fue introducido. Con subnet, un host (o router) puede ser configurado para entender que la longitud de prefijo local es extendida. Esta configuración es llevada Marcos Huerta S.

118


a cabo con una máscara de subnet. Por ejemplo, los routers y los hosts pueden ser configurados para comprender que la red 10.0.0.0 es subneteada en 254 subredes usando una máscara desubnet de 255.255.0.0.

Una nueva notación ha ganado la popularidad en años recientes indica la longitud de prefijo con un campo de longitud, después del slash. Por ejemplo, en la dirección 10.1.0.1/16, los 16 indican que el prefijo es 16 bits de largo, lo que significa lo mismo que una máscara de subnet de 255.255.0.0.

Los tradicionales hosts de IP y los routers tenían una capacidad limitada de entender longitudes de prefijo y subnet. Ellos entendieron la longitud para configuraciones locales, pero no para configuraciones remotas. El enrutamiento de Classful no transmitió ninguna información sobre la longitud de prefijo. La longitud de prefijo fue calculada de la información sobre la clase de dirección proporcionada en los primeros bits de una dirección, como mencionado antes.

Los protocolos de enrutamiento sin clases, por otra parte, transmiten una longitud de prefijo con una dirección de IP. Este permite protocolos de enrutamiento sin clases a redes de grupo en una entrada y usa la longitud de prefijo que especifique qué redes son agrupadas. Los protocolos de enrutamiento sin clases también aceptan cualquier longitud de prefijo arbitraria, que sólo acepte longitudes de 8, 16, o 24, que el sistema classful dictó.

Los protocolos de enrutamiento sin clases incluyen el Protocolo de Enrutamiento de Información(RIP) la versión 2, Protocolo de Enrutamiento de Gateway de Interior Mejorado (EIGRP), Abrir primero la Trayectoria mas Corta (OSPF), Protocolo de Borde Gateway (BGP), y Sistema intermedio para Sistemas Intermedio (IS - IS).

Los Protocolos de Enrutamiento Classful de incluyen la versión 1 de RIP y la Enrutamiento de Gateway Interior (IGRP).

Ruta de Sumarización (Agregación) Cuando las rutas publicadas en otra red principal, el protocolo de enrutamiento classful automáticamente resumen subredes. Ellos sólo publican una ruta de Clase A, B, o C de red, en vez de rutas a subredes. Como los routers classful y los host no entienden longitudes de prefijo no locales y subredes, no hay ninguna razón de publicar la información sobre longitudes de prefijo. La sumarización automático en una red de clase principal tiene algunas desventajas; por ejemplo, discontiguas subredes no son apoyadas.

Marcos Huerta S.

119


Los protocolos de enrutamiento sin clases publican una ruta y una longitud de prefijo. Si las direcciones son asignadas en una manera jerárquica, un protocolo de enrutamiento sin clases puede ser configurado para agregar subredes en una ruta, esto reduce la sobrecarga en el enrutamiento. La importancia de sumarizar ruta en el Internet ya fue discutido anteriormente. Es también importante resumir (agregar) rutas en una red empresarial. La ruta sumarizadas reduce el tamaño de las tablas de enrutamiento, que minimiza el consumo de ancho de banda y procesamiento en routers. La ruta sumarizada también significa que los problemas dentro de una área de la red no tienden a extenderse a otras áreas.

Ruta Ejemplo de Sumarización Esta sección cubre una ruta sumarizada ejemplo que está basado en la red mostrada en La figura nro. 26. Usted puede ver que un administrador de red asigno direcciones de red 172.16.0.0 a 172.19.0.0 a redes en una sucursal.

Figura Nro. 26. Ruta de Sumarización

El router de sucursal en La figura 26 puede resumir sus números de red locales y reportar que esto tiene 172.16.0.0/14 detrás de ello. Publicando sola esta ruta, el router dice, "los paquetes de la Ruta es para mí si el destino tiene los primeros 14 bits de 172.16." El router publica una ruta a todas las redes donde los primeros 14 bits son iguales a 10101100 000100 en el binario.

Para entender la sumarización en este ejemplo, usted debería convertir el número 172 al binario, que causa el binario el número 10101100. Usted también debería convertir el número 16 a 19 al binario, como mostrado en la tabla siguiente.

Marcos Huerta S.

120


Segundo Octeto en Decimal

Segundo Octeto en Binario

16

00010000

17

00010001

18

00010010

19

00010011

Note que 6 bits extremos izquierdos para el número 16 a 19 son idénticos. Este es lo que hace la ruta sumarizada con una longitud de prefijo de 14 posible en este ejemplo. Primeros 8 bits para las redes son idénticos (todas las redes tienen 172 para el primer octeto), y siguientes 6 bits son también idénticos

Subredes de Discontiguas Como mencionado antes, protocolo de enrutamiento classful automáticamente resumen las subredes. Un efecto secundario de este es que las subredes de discontiguas no son apoyadas. Las subredes deben estar al lado de cada uno otro es decir contiguo. La figura nro.27 muestra una red de empresa con subredes de discontiguas.

Figura Nro.27. Una Red con Subredes de Discontiguas

Con un protocolo de enrutamiento classful como la versión 1 de RIP o IGRP, Router en La figura nro 27 publicar esto se puede conseguir conectando a la red 10.0.0.0. El router B no hace caso de esta publicación, porque puede alcanzar a la red 10.0.0.0. Es directamente conectado para conectar a la red 10.0.0.0. (La parte de enfrente es también verdadera: el router B publica esto puede alcanzar a la red 10.0.0.0, pero router A no hace caso de esta información.) Este significa que los routers no pueden alcanzar subredes remotas de la red 10.0.0.0.

Para solucionar este problema, un protocolo de enrutamiento sin clases puede ser usado. Con un protocolo de enrutamiento sin clases, el router A publica que puede ponerse a redes 10.108.16.0/20. El router B anuncia esto puede ponerse a redes 10.108.32.0/20. (Para entender por qué la longitud de prefijo es 20, convierta los números de red al binario.) como los protocolos de enrutamiento sin clases entienden Marcos Huerta S.

121


prefijos de cualquier longitud (no sólo 8, 16, o 24), los routers en La figura nro.27 puede la ruta a subredes de discontiguas, asumiendo que ellos dirigen un protocolo de encaminamiento sin clases, como OSPF o EIGRP.

Host Móviles El enrutamiento sin clases y las subredes de discontiguas soportan a host móviles. Un host móvil, en este contexto, es un host que se mueve de una red al otro y tiene una dirección de IP estáticamente definida. Un administrador de red puede mover a un host móvil y configurar un router con una ruta específica de host para especificar que el tráfico para el host debería ser ruteado por aquel router.

En La figura nro 28, por ejemplo, reciba 10.108.16.1 se ha movido a una red diferente. Incluso aunque el router haga publicar aquella red el 10.108.16.0/20 esta detrás de ello, el router B puede publicar esto 10.108.16.1/32 esta detrás de ello.

Figura Nro 28. Un Host Móvil

Tomando una decisión de enrutamiento, los protocolos de enrutamiento sin clases emparejan el prefijo más largo. Los routers en el ejemplo tienen en sus mesas tanto 10.108.16.0/20 como 10.108.16.1/32. Cambiando un paquete, los routers usan el prefijo más largo disponible que es apropiado para la dirección de destino en el paquete.

En La figura nro.28, un mejor diseño debería usar DHCP de modo que los host puedan ser movidos sin requerir cualquier reconfiguración en los host o routers. El ejemplo simplemente es usado para explicar el concepto de partido de prefijo más largo. No se destina para ser una recomendación de diseño.

Marcos Huerta S.

122


Enmascaramiento de Subred de Longitud variable La utilización de un protocolo de enrutamiento sin clases significa que usted puede tener tamaños diferentes de subredes dentro de una red sola. La variación del tamaño de subredes también es conocida como el enmascaramiento de subred de longitud variable, o VLSM. El VLSM confía en la información de longitud de prefijo que provee explícitamente con cada uso de una dirección.

La longitud del prefijo es evaluada independientemente en cada lugar que es usado. La capacidad de tener una longitud de prefijo diferente en puntos diferentes soporta la eficacia y flexibilidad en el uso del IP se dirigen al espacio. En vez de cada subred que es el mismo tamaño, usted puede tener tanto subredes grandes como pequeñas.

Un uso para pequeñas subredes es el enlace punto a punto WAN que sólo tienen dos dispositivos (un router durante cada final del enlace). Tal enlace puede usar una máscara de subnet de 255.255.255.252, porque sólo dos dispositivos necesitan direcciones. Los dos dispositivos pueden ser numerados 01 y 10.

El diseño de un Modelo para Nombramiento Los nombres desempeñan un rol esencial en la reunión de los objetivos de un cliente para la usabilidad. Los nombres cortos, significativos realzan la productividad de los usuario y simplifican la dirección de red. Un modelo de nombramiento bueno también refuerza la performance y la disponibilidad de una red. El objetivo es ayudarle a diseñar modelos de nombramiento para redes que encontrarán los objetivos de su cliente para utilidad, manejabilidad, performance, y disponibilidad.

Los nombres son asignados a muchos tipos de recursos en

tipicas redes: routers,

servidores, hosts, impresoras, y otros recursos. Esta sección cubre el nombramiento de dispositivos y redes. Proporcionando nombres para usuarios, grupos, las cuentas, y las contraseñas no son cubiertas, aunque algunas pautas para llamar dispositivos se apliquen a esta sección también.

Un buen modelo de nombramiento debería dejar a un usuario tener acceso transparente a un servicio por nombre más bien que por dirección. Porque los protocolos de una red requieren una dirección, el sistema del usuario debería mapear el nombre a una dirección. El método para mapear un nombre a una dirección puede ser dinámico, usando algun nombramiento corto de protocolo, o estático (por ejemplo, un archivo en el sistema del usuario que pone todos los nombres en una lista y sus direcciones asociadas). Por lo general, un método dinámico es preferible, a despitar el tráfico de red adicional causado por protocolos de nombramiento dinámicos.

Marcos Huerta S.

123


Desarrollando un modelo de nombramiento, considere las preguntas siguientes: Ø

¿Qué tipos de entidades necesitan nombres? ¿Servidores, routers, impresoras, hosts, otros?

Ø

¿Necesitan los sistemas finales nombres? ¿Ofrecerán los sistemas finales algún servicio, como una porción de web personal?

Ø

¿Que es la estructura de nombres, como hace que la porcion de un nombre identifique el dispositivo?

Ø

¿Quién adjudica nombres?

Ø

¿Cómo hacen los host el mapeo de un nombre a una dirección? ¿Va a un sistema dinámico o estático ser proporcionado?

Ø

¿Cómo aprende un host su propio nombre?

Ø

¿Si la dirección dinámica es usada, también serán dinámicos los nombres y se cambiarán cuándo una dirección se cambia?

Ø

¿Debería el sistema de nombramiento usar un punto a punto o modelo de cliente/servidor?

Ø

¿Si los servidores de nombre serán usados, cuánta redundancia (mirroring) será requerido?

Ø

¿Será distribuida la base de datos de nombre entre muchos servidores?

Ø

¿Cómo afectará el sistema de nombramiento seleccionado el tráfico de red?

Ø

¿Cómo afectará el sistema de nombramiento seleccionado la seguridad?

Autoridades que Distribuyen Nombramiento Durante las etapas tempranas de diseñar un modelo de nombramiento, considere quién realmente adjudicará nombres preguntandose las preguntas siguientes: Ø

¿Será completamente controlado el espacio de nombre por unas autoridades centralizadas, o va al nombramiento de algunos dispositivos a ser realizado por agentes descentralizados?

Ø

¿Un departamento corporativo IS nombra los dispositivos en la region y sucursales, o pueden los administradores departamentales implementar el nombramiento en aquellos sitios?

Ø

¿Serán permitidos a los usuarios poner sus propios nombres de sistemas, o son todos los nombres asignados por administradores de red?

La desventaja de distribuir autoridades para el nombramiento es que los nombres se hacen más difíciles de poder controlar y manejar. Si todos los grupos y usuarios estan de acuerdo, y práctican, las mismas políticas, sin embargo, hay muchas ventajas para la distribución de autoridades para el nombramiento.

La ventaja obvia de distribuir autoridades para el nombramiento consiste en que ningún departamento es cargado con el trabajo de asignación y mantenimiento de todos los

Marcos Huerta S.

124


nombres. Otras ventajas incluyen la performance y la escalabilidad. Si cada servidor de nombre maneja una parte del espacio de nombre en vez del espacio de nombre entero, los requerimientos de memoria y poder de procesamiento en los servidores son menores. También, si los clientes tienen el acceso a un servidor de nombre local en vez de depender de un servidor centralizado, muchos nombres pueden ser resueltos a direcciones locales, sin causar el tráfico en las redes. Los servidores locales pueden informar acerca de los dispositivos remotos, para reducir mas adelante el tráfico de red.

Pautas para Asignar Nombres Para maximizar la usabilidad, los nombres deberían ser significativamente cortos, inequívocos, y distintos. Un usuario debería reconocer fácilmente qué nombres van con cual dispositivos. Una buena práctica es incluir un nombre corto para indicar algun tipo de dispositivo. Por ejemplo, usted puede prefijo o sufijo del nombre de un router con los carácteres rtr, switches con sw, servidores con svr, etcétera. La utilización de prefijos significativos o sufijos disminuye la ambigüedad para los usuarios finales, y ayuda a manejar más fácilmente los nombres de dispositivo de instrumentos de dirección de red.

Los nombres también pueden incluir un código de posición. Algunos diseñadores de red usan códigos de aeropuerto en sus modelos de nombramiento. Por ejemplo, todos los nombres en el principio de San Francisco con SFO, todos los nombres en Oakland comienzan con el OAK, etcétera. El código de posición podría ser un número en cambio, pero la mayor parte de personas recuerdan cartas mejor que números.

El intento de evitar nombres que tienen carácteres extraños, como guiones, subraya, asteriscos, etcétera, aun si el protocolo de nombramiento permite estos carácteres (que muchos hacen). Estos carácteres son difíciles de escribir a máquina y pueden hacer que aplicaciones y protocolos se comporten de modos inesperados. Los carácteres extraños podrían significar algo especial a un protocolo. Por ejemplo, el signo de dólar cuando es usado como el último carácter de un nombre de NetBIOS significa que el nombre no aparece en listas del navegador de red o en respuesta a órdenes de revisión de red NetBIOS. Los nombres de NetBIOS con un signo de dólar al final son para el uso administrativo sólo.

Es también lo mejor si los nombres no son letras mayusculas porque la gente por lo general no puede recordar que tecla usar. Los nombres que requieren que un usuario recuerde teclas mezcladas (por ejemplo, DBServer) no son una idea buena.

Usted también debería evitar espacios de nombres. Los espacios aturden a usuarios y no podrían trabajar correctamente con algunas aplicaciones o protocolos. Los nombres deberían ser generalmente ocho carácteres o menos, de ser posible. Este es sobre todo

Marcos Huerta S.

125


verdadero para sistemas operativos, aplicaciones, o protocolos para mapear nombres a nombres de archivo y restringen el tamaño de un nombre del archivo a ocho carácteres. Si un dispositivo tiene más de un interfaz y más de una dirección, usted debería mapear todas las direcciones a un nombre común. Por ejemplo, en un router de multipuerto con direcciones de IP múltiples, asigne el mismo nombre a las direcciones de IP de todo el router. De estos camino el software de dirección de red no asume que un dispositivo de multipuerto es realmente más de un dispositivo.

La Asignación de Nombres en un Ambiente IP El nombramiento en un ambiente IP es llevado a cabo configurando archivos de hosts, servidores de DNS, o Servicio de Información de Red (NIS) servidores. El DNS es usado en el Internet y también ha ganado una extendida popularidad para manejar nombres en redes de empresa. Esto es el sistema de nombramiento recomendado para redes modernas.

Un archivo de hosts dice a una estación de trabajo UNIX como convertir un nombre de host en una dirección de IP. Un administrador de red mantiene un archivo de hosts en cada estación de trabajo en las redes. Tanto el DNS como NIS fueron desarrollados para permitir que un administrador de la red centralizara el nombramiento de dispositivos, usando un acercamiento de base de datos distribuido, en vez de un archivo plano que reside en cada sistema.

Sun Microsystems desarrolló NIS para permitir que un UNIX conecte a la red al administrador para centralizar la dirección de nombres y otros parámetros de configuración. Un administrador puede usar NIS para mantener nombres, usuario e información de contraseña, direcciones de Ethernet, alias de correo, definiciones de grupo, y nombres de protocolo y números. El NIS era una vez completamente común, pero se ha hecho menos común como el estándar de Internet para llamar (DNS) ganó el ímpetu.

El Sistema de Dominio de Nombre El DNS fue desarrollado a principios de los años 1980 cuando se hizo claro que manejando un archivo de hosts que contiene los nombres y direcciones de todos los sistemas en el Internet ya no trabajaría. Cuando el archivo de hosts de Internet creció, se hizo difícil mantener, almacenar, y transmitir a otros hosts.

El DNS es una base de datos distribuida que proporciona un sistema de nombramiento jerárquico. Un nombre de DNS tiene dos partes: un nombre de host y un nombre de dominio. Por ejemplo, en information.priscilla.com, la information es el host, y

Marcos Huerta S.

126


priscilla.com es el dominio. La tabla siguiente muestra algunos dominios de alto nivel más comunes. Esfera

Descripción

.edu

Instituciones educativas

.gov

Agencias del gobierno

.net

Proveedores de red

.com

Compañías comerciales

.org

Empresas no lucrativas

Los dominios de alto nivel, como .biz, .info, .museum, y .name pueden ayudar a prevenir muchas disputas que ocurren sobre el derecho de usar nombres populares y comerciables. Hay también muchos dominios de alto nivel geográficos (por ejemplo .uk para el Reino Unido y .de para Alemania).

La arquitectura DNS distribuye el conocimiento de nombres de modo que ningún simple sistema tuviera que saber todos los nombres. La Corporación de Internet para Nombres Asignados y Números (ICANN) es una corporación no lucrativa que tiene la responsabilidad de dirección de sistema de nombre de dominio total y dominio de alto nivel. El ICANN ha acreditado un juego de registradores competitivos que tienen autoridades sobre nombres bajo el nivel superior.

Cada capa de la jerarquía también puede delegar autoridades. Por ejemplo, un registrador podría delegar las autoridades a un corporativo IS el departamento para un nombre como cisco.com. El departamento IS puede delegar autoridades al departamento de ingeniería para nombres en el engineering.cisco.com subdominio. Dentro del departamento de ingeniería, podrían haber hosts múltiples con nombres como

development.engineering.cisco.com

y

testing.engineering.cisco.com.

La

delegación permite que el DNS sea manejado autónomamente en cada capa, que aumenta la escalabilidad y las ayudas guardan nombres significativos.

El DNS usa un modelo de cliente/servidor. Cuando un cliente tiene que enviar un paquete hacia el nombre de la estación, el software resuelve en el cliente envíando una pregunta de nombre a un servidor DNS local. Si el servidor local no puede resolver el nombre, este pregunta a otros servidores para que puedan resolver. Cuando el servidor de nombre local recibe una respuesta, este replica la respuesta e informa al cache para futuras peticiones. El tiempo que un servidor debería la informar al cache recibida de otros servidores es entrado en la base de datos DNS por un administrador de red. El tráfico de red disminuira en intervalos de mucho tiempo pero también puede hacer difícil Marcos Huerta S.

127


de cambiar un nombre. El viejo nombre podría ser cached en miles de servidores en el Internet.

La dirección de nombres de DNS y servidores es una tarea compleja. Para más información en la dirección de nombres de DNS en un ambiente UNIX, ver el libro clásico por Paul Albitz y Cricket Liu llamado DNS y BIND.

Nombres de DNS dinámicos Con muchas implementaciones de DHCP, cuando un host solicita una dirección de IP de un servidor DHCP, el host también recibe un nombre de host dinámico, algo como pc23.dynamic.priscilla.com. Un nombre dinámico no es apropiado para algunas aplicaciones. Por ejemplo, los servidores de web, los servidores de FTP, y algunas aplicaciones de telefonía de Internet confían en nombres de host estáticos. Para alcanzar a un servidor de web, un usuario teclea un Localizador de Recurso Universal (URL) que está basado en el nombre de dominio del servidor. Si el nombre se cambia dinámicamente, se hace imposible alcanzar al servidor. Con algunas aplicaciones de telefonía de Internet, un usuario tiene que decir a la gente el nombre del host para usar haciendo una llamada al sistema del usuario.

Para estos tipos de aplicaciones, es importante tener una realización DNS que puede asociar un nombre estático con una dirección dinámica. Este puede ser llevado a cabo en una variedad de caminos. Muchos vendedores han desarrollado soluciones creativas con los problemas asociados con nombres en un ambiente DHCP. Las Extensiones DNS IETF grupo trabajador también desarrollan estándares para DNS dinámico. Resumen Este capítulo proporcionó pautas para asignar direcciones y nombres en un ambiente de redes de multiprotocolo. Esta sección ilustró la importancia de usar un modelo estructurado para direccionamiento y nombramiento para hacer más fácil para entender los mapas de red, hacer funcionar el software de dirección de red, reconocer dispositivos con un analizador de protocolo, y encontrar los objetivos de un cliente para la usabilidad.

Las direcciones estructuradas y los nombres facilitan la optimización de red porque ellos hacen más fácil para cifrar filtros de red en firewall, routers, e switches. Las direcciones estructuradas también le ayudan a implementar la ruta sumarizada, que disminuye la utilización de ancho de banda, que procesa en el routers, e inestabilidad de red.

En esta sección también se habló de autoridades de distribución para direccionamiento y nombramiento para evitar que un departamento tenga la necesidad manejar todas las direcciones y nombres. Otro modo de simplificar la tarea de direcciónes y nombramiento Marcos Huerta S.

128


es usar la dirección y el nombramiento dinamico. El direccionamiento dinamico por ejemplo, DHCP para ambiente IP permite que cada sistema final aprenda su dirección automáticamente. El DHCP es recomendado para la dirección de sistemas finales en un diseño de red de campus.

El direcionamiento y el nombramiento son elementos esenciales de la fase de diseño lógica del proceso de diseño de red top down. De ser diseñado correctamente, el modelo de direccionamiento y nombramiento puede reforzar su capacidad de satisfacer las necesidades de un cliente. Ellos también pueden ayudarle a decidirse que el enrutamiento y la conmutación de protocolos para seleccionar, que es cubierto en la siguiente parte.

Parte 7. Selección de los switching y protocolo de enrutamiento El objetivo de este capítulo es ayudarle a seleccionar correctamente los protocolos conmutados y de enrutamiento para el diseño de su red al cliente. Las selecciones que usted hace dependerán de los objetivos comerciales y técnicos de su cliente. Para ayudarle a seleccionar los protocolos correctos para su cliente, la parte cubre los atributos siguientes de conmutación y enrutamiento de protocolos: Ø

Características de tráfico de red.

Ø

Ancho de banda, memoria, y uso de CPU.

Ø

El número aproximado en el trafico de puntos de routers o switches que soportan.

Ø

La capacidad de adaptarse rápidamente a cambios de una redes.

Ø

La capacidad de certificar ruta actualizadas por razones de seguridad.

En este punto en el proceso de diseño de red, usted ha creado una topología de diseño de red y ha desarrollado alguna idea de donde los switches y los routers residirán, pero usted no ha seleccionado ningún switch actual o productos de router. Un entendimiento de la conmutación y enrutamiento de protocolos que un switch o el router deben soportar le ayudará a seleccionar el mejor producto para el trabajo.

Esta sección comienza con una discusión genérica sobre la fabricación de decisión a ayudarle a desarrollar un proceso sistemático para seleccionar soluciones tanto para los componentes lógicos como para físicos de un diseño de red. La fabricación de decisiones sanas en cuanto a protocolos y tecnologías es una habilidad de diseño de red crucial que esta parte puede ayudarle a desarrollar.

Una discusión de cambiar protocolos sigue la sección haciendo decisiones. La sección de conmutación cubre transparentemente

Marcos Huerta S.

puenteos, de conmutación de múltiples

129


capas, realces de algoritmo de spanning-tree, y conmutación de protocolos para transportar LAN virtuales de (VLAN) información.

Una sección en el protocolos de enrutamiento sigue la sección que tiende un puente. La sección de enrutamiento proporciona técnicas para comparar y constratar protocolos de enrutamiento, e incluye la información en el Protocolo de Internet (IP), AppleTalk, y enrutamiento Novell de NetWare. La sección concluye con una tabla que resume la comparación de enrutamiento Tomar Decisiones como Parte del Proceso de Diseño de Red Top Down La siguientes sección proporcionan pautas para seleccionar soluciones de diseño de red para un cliente. Las decisiones que usted hace en cuanto a protocolos y tecnologías deberían estar basadas en la información que usted ha juntado en los objetivos comerciales y técnicos de su cliente.

Los investigadores que estudian modelos de decisión dicen que uno de los aspectos más importantes de tomar una decisión sana es tener una lista de los buenos objetivos. En su libro The Can-Do Manager, publicado por la Asociación de Dirección americana, Tess Kirby dice que hay cuatro factores implicados en tomar decisiones sanas: Ø

Los objetivos deben ser establecidos.

Ø

Muchas opciones deberían ser exploradas.

Ø

Las consecuencias de la decisión deberían ser investigadas.

Ø

Los planes de emergencia deberían ser hechos.

Para emparejar opciones con objetivos, usted puede hacer una tabla de decisión, como la Tabla Nro. 14 que muestra una tabla de decisión que empareja protocolos de enrutamiento a los objetivos comerciales y técnicos de un cliente ficticio. Usted puede desarrollar una tabla similar para cambiar protocolos, tecnologías de diseño de campus, tecnologías de diseño de empresa, protocolos WAN, etcétera. Para desarrollar la tabla, coloque opciones en la columna extrema izquierda y los objetivos principales de su cliente encima. Coloque los objetivos en el orden de prioridad, que comienza con objetivos críticos.

Marcos Huerta S.

130


Tabla Nro.14. Mesa de Decisión de Ejemplo Objetivos Críticos La adaptabilidad — Debe escalar a Debe debe

adaptarse

cambios

de

redes

a una

de

ser

una No

talla industria

unas grande

y tráfico

de compatible

unos routers)

el

segundos

debería Debería

crear mucho correr

estándar

grandes (cientos

dentro

Otros Objetivos

con

Debería en fácil

ser para

routers

configurar

baratos

manejar

y

equipo

existente

BGP

X[*]

X

X

8

7

7

OSPF

X

X

X

8

8

8

ES - ES

X

X

X

8

6

6

IGRP

X

X

EIGRP

X

X

RASGÓN

X

[*] X = Encuentra criterios críticos. 1 = el más Bajo. 10 = el más Alto. Usted puede rellenar la Tabla Nro. 14 primero simplemente poniendo un X en cada opción que encuentra un objetivo crítico. Cualquier opción que no encuentra objetivos críticos puede ser inmediatamente eliminada. Otras opciones pueden ser evaluadas en como bien ellos encuentran otros objetivos, por una escala de 1 a 10.

Después de que una decisión ha sido tomada, usted debería fallar la decisión. Pregúntese lo siguiente: Ø

¿Si esta opción elegida, qué podría equivocarse?

Ø

¿Ha sido intentada esta opción antes (posiblemente con otros clientes)? ¿De ser así, qué problemas ocurrieron?

Ø

¿Cómo reaccionará el cliente a esta decisión?

Ø

¿Cuáles son los planes de emergencia si el cliente no aprueba la decisión?

Este proceso de toma de decisiones puede ser usado tanto durante las fases de diseño de red lógicas como durante físicas. Usted puede usar este proceso para ayudarle a seleccionar protocolos, tecnologías, y dispositivos que encontrarán los requerimientos de un cliente.

Marcos Huerta S.

131


La Selección de puente y Protocolos Conmutados Si su diseño de red incluye switches de Ethernet, usted usará con la mayor probabilidad un puente transparente con el algoritmo de spanning-tree. Usted también podría necesitar un protocolo para conectar switches que soportan LANs virtuales (VLANs). Este protocolo podría ser el Cisco Inter-Switch Link (ISL) protocolo o el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) 802.1Q protocolo.

Con las redes de Token Ring, sus opciones incluyen ruta-fuente de puente (SRB), rutafuente transparente (SRT) un puente, y fuente-ruta switcheada (SRS). Para conectar LANs de Ethernet y Token Ring (y otras redes distintas), usted puede usar un puente de translación o de encapsulamiento de puente.

La IBM desarrolló SRB para redes de Token Ring en los años 1980. A principios de los años 1990, la IBM presentó los protocolos SRB al IEEE. Los protocolos se hicieron el estándar SRT, que es documentado en el Anexo C del 802.1 documento IEEE. Un puente de SRT puede actuar como un puente transparente o un puente fuente-enrutado, según si la información del fuente-enrutado es incluida en un paquete. El SRS mejora la eficacia de un SRT puente y permite caminos paralelos fuente-enrutado, que SRT no soporta.

Aunque un puente y switches de redes de Token Ring todavía existen, la mayor parte de ellos están siendo emigrados a redes Ethernet conmutadas y ruteadas. El resto de esta sección se concentra en los protocolos de conmutación usados en redes de Ethernet típicas.

Puente Transparente Los switches de Ethernet y los puentes usan una tecnología clásica llamada puente transparente. Un puente transparente conecta uno o varios segmentos de LAN de modo que los sistemas finales en segmentos diferentes puedan comunicarse el uno con el otro claramente. Un sistema final envía un paquete a un destino sin saber si el destino es local o al otro lado de un puente transparente. Los puentes transparentes son tan llamados porque su presencia es transparente para terminar sistemas.

Para aprender a enviar paquetes, un puente transparente escucha a todos los paquetes y determina qué estaciones residen en cual segmentos. El puente aprende la posición de dispositivos mirando la dirección de la fuente en cada paquete. El puente desarrolla una tabla de conmutación como es mostrado en la tabla nro. 15 La tabla de conmutación también a veces va por los nombres que tienden un puente sobre tabla, tabla de dirección de MAC, o Contenido de Memoria Direccionable (CAM).

Marcos Huerta S.

132


Tabla nro.15. La Conmutación de Tabla en un Puente o Switch Dirección de MAC

Puerto

08-00-07-06-41-B9

1

00-00-0C-60-7C-01

2

00-80-24-07-8C-02

3

Cuando un paquete llega a un puente, el puente mira la dirección de destino en el paquete y lo compara con las entradas en la tabla de conmutación. Si el puente ha aprendido donde la estación de destino reside (mirando direcciones de la fuente en paquetes anteriores), esto puede enviar el paquete al puerto correcto. Un puente transparente envía (floods) paquetes con una dirección de destino desconocida y todos los paquetes de multicast/broadcast salen del puerto (excepto el puerto en el cual el paquete fue recibido).

Los puentes funcionan en Capas 1 y 2 del modelo de referencia de OSI. Ellos determinan como enviar un paquete basado en la información de la cabecera de Capa 2 jefe del paquete. A diferencia de un router, un puente no mira la información de la Capa 3 o ninguna capa superior. Un puente segmenta dominios de ancho de banda de modo que los dispositivos en lados opuestos de un puente no compitan el uno con el otro por el control de acceso de medios. Un puente no envia colisiones de Ethernet o paquetes de MAC en una red de Token Ring.

Aunque un puente segmente dominos de ancho de banda, esto no segmenta dominos de broadcast (a menos que no este programado por filtros para hacerlo así). Un puente envía a paquetes de broadcast a cada puerto. Este es una cuestión de escalabilidad en que hablaron ya Parte I de esta tesis. Para evitar el tráfico de broadcast excesivo, las redes tendidas un puente y switches deberían ser segmentadas con routers o divididas en VLANs.

Un puente es un dispositivo almacenar-y-enviar. El almacenar y avanzar quiere decir que el puente recibe un paquete completo, determina qué puerto saliente usar, prepara el paquete para el puerto saliente, calcula una comprobación por redundancia cíclica (CRC), y transmite el paquete cuando el medio esta libre en el puerto saliente

Marcos Huerta S.

133


Conmutación Transparente Los switches se hicieron populares a mediados de los años 1990 como un modo barato de dividir LANs sin incurrir en latencia asociada con puentes. Los switches aprovechan circuitos integrados rápidos para ofrecer latencia muy baja. Un switch se comporta esencialmente justo como un puente salvo que es más rápido. Los switches por lo general tienen una densidad de puerto más alta que puentes y un coste inferior por puerto. A causa de estos rasgos, y la latencia baja de switches, los switches son más comunes que puentes estos días.

Los switches tienen la capacidad de hacer el procesamiento almacenar-y-enviar o el procesamiento de conexión directa. Con el procesamiento de conexión directa, un switch rápidamente mira la dirección de destino (el primer campo en un paquete LAN), determina el puerto saliente, e inmediatamente comienza a enviar bits al puerto saliente.

Una desventaja con el procesamiento de conexión directa es que esto envia paquetes ilegales (por ejemplo, runts de Ethernet) y paquetes con errores CRC. En una red que es propensa a runts y errores, el procesamiento de conexión directa no debería ser usado. Algunos switches tienen la capacidad de moverse automáticamente del modo de conexión directa al modo almacenar-y-enviar cuando un umbral de error es alcanzado. Este rasgo es llamado la conmutación de conexión directa adaptable por algunos vendedores.

Un switch también soporta el transporte de mercancías paralelo, mientras que los puentes por lo general no hacen. Cuando un puente típico envia un paquete de un puerto al otro, ningún otro paquete puede ser enviado.

Hay sólo un camino de transporte de mercancías. Un switch, por otra parte, permite caminos de transporte de mercancías múltiples, paralelos, el que significa que un switch puede manejar un volumen alto del tráfico más rápidamente que un puente. Los switches de alta calidad pueden soportar numerosos caminos de transporte de mercancías simultáneos, según la estructura del fabricante de conmutación. (Los fabricantes usan el término de fabricante de conmutación para describir la arquitectura de sus switches.)

La conmutación y las Capas OSI En esta parte, un switch se refiere a un dispositivo que funciona en Capas 1 y 2 del modelo de referencia de OSI, a menos que por otra parte no especificado. El término switch tiene realmente un sentido más genérico aunque. El verbo para cambiar simplemente medios de mover algo a una posición diferente. Un dispositivo de

Marcos Huerta S.

134


funcionamiento entre redes mueve datos que vienen de una interfaz a otra interfaz diferente.

Un hub Ethernet o repetidor cambian bits que vienen a una interfaz a todas las otras interfaces. Un hub trabaja en la Capa que 1 del modelo OSI y no entiende nada más allá de bits. Un switch Ethernet es rápido, puente multipuerto que cambia paquetes basados en la Capa 2 del destino de dirección. Después de que un switch ha aprendido una interfaz correcta para usar un destino unicast particular, este paquetes del switch va aquel destino exclusivo para esa interfaz, a diferencia de un hub que cambia bits a todas las interfaces. Un router cambia paquetes basados en la Capa 3 dirección de destino. Por paquetes unicast, el router conmuta exclusivamente a una interfaz.

El sustantivo switch es un buen término de ingeniería que no debería ser nublado por exageraciones de mercadotecnia. En la electrónica, un switch es un dispositivo que permite o interrumpe el flujo de corriente por un recorrido eléctrico. En la industria de transporte, un switch es un dispositivo hecho de dos carriles movibles diseñados para girar una locomotora de una pista al otro. En el campo conectado a una red, un switch permite o interrumpe el flujo de datos y, aunque esto no gire una locomotora, esto gira realmente bits, y paquetes.

Los routers modernos pueden cambiar paquetes sumamente rápido. Algunos fabricantes añaden la palabra switch a su router el producto llama para enfatizar que los routers son rápido (o casi tan rápido) como los switches de Capa 2. Los routers modernos usan caminos de datos internos rápidos, procesadores paralelos, y avanzado metodos de caching, todos esenciales a la conmutación rápida de datos. Los fabricantes llaman a este producto switches de Capa 3, switches enrutados, switches ruteables, switches de múltiples capas, y muchos otros nombres creativos. En general, un switch de Capa 3, switch enrutable, o router switcheable es un dispositivo que puede manejar tanto Capa 2 como la Capa 3 de conmutación de datos. Un switch de Capa 3 es un router rápido que puede incluir interfaces que toman una decisión de transporte de mercancías basada únicamente en la información de la Capa 2.

Conmutación de Múltiples capas La conmutación de múltiples capas tiene muchos sentidos diferentes. La conmutación de múltiples capas puede referirse a un switch que entiende capas múltiples, incluso capas de transporte y de aplicación. El Cisco también usa el término conmutación de múltiples capas y se refiere a una tecnología avanzada por lo cual los routers (o procesadores de ruta dentro de un switch) se comunican con switches para decir a los switches como enviar paquetes sin la ayuda del router. El Cisco conmutación de múltiples capas tiene tres componentes:

Marcos Huerta S.

135


Ø

Un procesador de ruta o router.

Ø

Un motor de conmutación.

Ø

El Protocolo de Conmutación de Múltiples capas (MLSP).

El procesador de ruta maneja el primer paquete en cada flujo. El procesador de ruta toma una decisión de transporte de mercancías basada en la Capa 3 dirección de destino.

El motor de conmutación rastrea paquetes que fluyen al procesador de ruta y atrás otra vez, y aprende como el procesador de ruta maneja los paquetes. Después del primer paquete en un flujo, el motor de conmutación envia los paquetes para aquel flujo sin enviarles al procesador de ruta.

El MLSP es un protocolo simple usado por el procesador de ruta para permitir la conmutación de múltiples capas y decir al motor de conmutación limpiar la tabla de conmutación de la Capa 3 si hay un cambio de la tabla de enrutamiento o configuración de lista de control de acceso. Aunque los detalles de la conmutación de múltiples capas Cisco estén más allá del alcance de esta sección, es bastante para decir que la tecnología aguanta más investigación si usted pone en práctica un diseño de red con switches Cisco

La Selección del Protocolo Spanning Tree Como hemos hablado en la parte 5, "Diseñando una Topología de Red," los puentes transparentes y los switches ponen en práctica el Protocolo de Spanning tree (STP) para evitar loop en una topología. Una consideración de diseño importante es qué realces a STP usted debería seleccionar para asegurar la disponibilidad alta en sus diseños de red de campus. La parte 5 hablado dos realces importantes: el IEEE 802.1w, que proporciona la nueva convergencia rápida del spannig tree, e IEEE 802.1s, que agrega un juego de VLAN basados en spaning tree que atraviesan en casos distintos y dirige sólo un algoritmo de spanning tree (rápido) por caso. Como descrito en las siguientes secciones, hay muchos otros realces a STP que puede aumentar la disponibilidad y la elasticidad de un diseño de red de campus que confía en STP.

PortFast Cuando un switch arranca, cada puerto del switch pasa por los estados de bloqueo, la escucha, el aprendizaje, y el transporte. La transición al estado de transporte de la inicial que bloquea el estado puede tomar 30 segundos o más. Esta cantidad de tiempo beneficia el desarrollo de un loop-free spanning tree que atraviesa cuando los puertos se conectan a otros switches, pero esto puede ser un problema serio para un puerto que

Marcos Huerta S.

136


conecta una estación de trabajo o el servidor. Usted podría encontrar uno o varios mensajes de error siguientes en una estación de trabajo o servidor: Ø

Microsoft demostraciones de cliente conectadas a una red, " No Domain Controllers Available."

Ø

Novell cliente de NetWare no tiene " Novell Login Screen" sobre bootup.

Ø

Un cliente DHCP no hace un informe, " No DHCP Servers Available."

Ø

Un cliente DHCP usa una dirección de la variedad de Direcciones de IP privada automática (169.254.0.1 a 169.254.255.254) más bien que una dirección asignada por un servidor DHCP.

Ø

Un cliente AppleTalk tiene problemas que muestran zonas o se conectan a servidores.

Ø

Un cliente AppleTalk muestra, "el Acceso a su red de AppleTalk ha sido interrumpido. Para restablecer su conexión, abra y cierre el panel de instrumentos AppleTalk."

En AppleTalk, la tardanza de arranque puede causar a un cliente que usa una dirección de capa de red dinámica que es un duplicado de la dirección de otra estación. Este puede causar problemas serios tanto para el cliente recién booteado como para el cliente que usaba ya la dirección. Además, un cliente puede no tener noticias de un router y decidir que esto está en una LAN solo sin un router. Este lo hará imposible para el cliente de comunicarse con cualquier dispositivo no en su segmento de LAN. La aplicación de escoger del cliente puede mostrar una lista de zona vacía o incompleta.

Con redes de IP, el problema más serio con la tardanza de arranque de puerto de switch es que un cliente puede en el intervalo de espera estar esperando a recibir una dirección de IP de un servidor DHCP. Con algunas realizaciones, si esto pasa, el cliente usa una dirección de la variedad de Direcciones de IP privada automática. Esta dirección no permite la comunicación a través de un router, el que significa que los usuarios no pueden alcanzar el Internet y servidores posiblemente corporativos también.

Si usted conecta un puerto de switch a una estación de trabajo o servidor que tiene una tarjeta de interfaz de red sola (NIC), el riesgo que la unión creará un loop es mínimo. Por lo tanto, no hay ninguna necesidad del puerto para esperar 30 segundos antes de entrar en el estado de transporte. Cisco soporta una caracteristica llamado PortFast que mueve un puerto inmediatamente al estado de transporte, sin requerir que ello pasara por el bloqueo, la escucha, y el aprendizaje de estados. La caracteristica no incapacita STP. Esto simplemente hace que STP salte unos pasos innecesarios cuando un puerto de switch conecta una estación de trabajo o el servidor.

Marcos Huerta S.

137


El PortFast se supone para ser usado sólo en puertos que no conectan otro switch. Sin embargo, a veces este es imprevisible, especialmente como los usuarios y el subalterno conectan a la red a administradores se hacen el sentido común más conectado a una red y deciden instalar su propio equipo. Para proteger una red que usa PortFast, Cisco también apoya una caracteristica llamado la Guardia de BPDU que cierra un puerto PortFast-permitido si un BPDU de otro interruptor es recibido. Usted también puede permitir la Filtración de BPDU, que asegura que PortFast-permitido puertos no envían BPDUs.

UplinkFast y BackboneFast El UplinkFast es una caracteristica de Cisco que puede ser configurado en switches de capa de acceso. El UplinkFast mejora el tiempo de convergencia de STP en caso de un fracaso de uplink redundante de un switch de capa de acceso. Un uplink es una conexión de un switch de capa de acceso a un switch final más alto en la capa de distribución de un diseño de red jerárquico. La figura nro.29 ilustra un diseño de red redundante, jerárquico típico. Los usuarios están relacionados para cambiar en la capa de acceso. El switch de capa de acceso es atado a dos interruptores de capa de distribución. Uno de los uplinks es bloqueado por STP. (STP también ha bloqueado uno de los enlaces entre la distribución y capas principales.)

Figura Nro.29. Un Interruptor de Capa de Acceso con Dos Uplinks a Capa de Distribución Switches

Si el uplink para Cambiar B en La figura nro 29 falla, STP finalmente desbloquea el uplink para Cambiar C, de ahí restaurando la conectividad. Con la falta parámetros de STP, la recuperación toma entre 30 y 50 segundos. Con UplinkFast, la recuperación toma aproximadamente un segundo. La caracteristica de UplinkFast está basado en la

Marcos Huerta S.

138


definición de un grupo uplink. En un switch dado, el grupo uplink consiste en el puerto raíz y todos los puertos que proporcionan una conexión alterna al puente raíz.

Si el puerto raíz falla o la primaria el uplink falla, un puerto del grupo uplink es seleccionado para sustituir inmediatamente el puerto raíz. El UplinkFast debería ser configurado sólo en switches de capa de acceso en el borde de su red y no en distribución o switches de capa core.

Cisco también soporta una caracteristica llamado BackboneFast, que puede salvar un switch hasta 20 segundos (Edad Máxima) reponiéndose de un fallo de enlace indirecto que ocurre en un puerto no local. Cuando permitido en todos los switches en una red cambiada, las velocidades de BackboneFast convergen después de un fallo aprovechando el hecho que un switch implicado en un fallo no local puede ser capaz de moverse en el estado que escucha inmediatamente. En algunas topologías, no es necesario para un switch para esperar el temporizador de Edad Máximo a transcurrir. El switch primero comprueba con otros switches para determinar si su estado es válido. La comprobación es llevada a cabo con dos unidades de datos de protocolo Ciscopatentadas (PDUs) llamado la Pregunta de enlace Raíz (RLQ) y la Respuesta RLQ.

Descubrimiento de Enlaces Unidireccional A veces el hardware falla de tal modo que la conectividad entre dos switches trabaja en sólo una dirección. Este es llamado un enlace unidireccional. El switch A puede oir al switch B, pero en cambio B no puede oír el switch A. Esta situación puede ser causada por el switch receptor B que empieza a morir o débilitarse, el switch transmisor A siendo muerto o débil, o algún otro componente, como un repetidor o cable, no disponible para transmitir o recibir. Por ejemplo, un cable puede trabajar en la capa física (entonces el enlace aumenta) pero ser construido incorrectamente de modo que un puerto de interruptor pueda transmitir, pero no recibir, aunque su compañero sea inconsciente del problema y pueda transmitir y recibir.

Un enlace unidireccional puede causar un loop en una red switcheada. Si un puerto de switch no puede recibir datos, entonces esto no puede oír BPDUs, y esto podría entrar en el estado de transporte cuando su compañero envia ya. Si un puerto de switch no puede enviar datos, entonces esto no puede enviar BPDUs, y su compañero puede ser inconsciente de su existencia. El IEEE no dice como manejar esta situación, pero los vendedores reconocieron el potencial para un problema y ofrecer repararlo. Cisco proporciona el Descubrimiento de enlaces Unidireccional (UDLD) protocolo en switches de alta calidad.

Marcos Huerta S.

139


El UDLD permite que dispositivos conectados por cables ópticos de fibra o de cobre Ethernet supervisen la configuración física de los cables y descubran cuando existe un enlace unidireccional. Cuando un enlace unidireccional es descubierto, UDLD cierra el puerto afectado y alerta al usuario. Un puerto del switch que es configurado para usar UDLD transmite mensajes UDLD periódicamente a los dispositivos vecinos. Los dispositivos durante ambos finales de un enlace deben apoyar UDLD para el protocolo para identificar con éxito e deshabilitar enlaces unidireccionales.

Loop Guard Cisco también soporta una caracteristica llamado la loop guard que esto es intentado para proporcionar la protección adicional contra loop causados por un puerto de bloqueo que erróneamente mueve al estado de transporte. Este por lo general pasa porque uno de los puertos de una topología físicamente redundante (no necesariamente el puerto de bloqueo) deja de recibir BPDUs, quizás debido a un problema de enlace unidireccional.

Si esta habilitado loop guard y BPDUs no son recibidas en un puerto no designado, los movimientos de puerto en el estado inconsistente de loop en vez de moverse al estado escucha, aprendizaje, y transporte. Sin la loop guard STP, el puerto asumiría el papel de puerto designado y el movimiento al estado de transporte , y así crearía un loop. Cuando un BPDU es recibido en un puerto en un estado inconsistente de loop, las transiciones de puerto en otro estado STP. Este significa que la recuperación es automática, y ninguna intervención es necesaria.

Usted puede elegir UDLD o la Loop Guard STP, o ambos, que es recomendado. El UDLD trabaja mejor que la Loop Guard en EtherChannel (que es una agrupación de interfaces de Ethernet en un canal lógico). El UDLD desabilita sólo el interfaz fallado. El canal permanece funcional con las interfaces restantes. La Loop Guard STP bloquea el canal entero en tal falla (poniéndolo en el estado de loop-inconsistente).

El Loop Guard no trabaja donde el enlace ha sido unidireccional ya que fue primero probado. El puerto nunca puede recibir BPDUs, pero no reconocer que hay un problema y hacerse un puerto designado. El UDLD proporciona la protección contra tal problema. Por otra parte, UDLD no protege contra fallas STP causados por problemas de software que causan un puerto designado que no envía a BPDUs. Los problemas de software son menos probables que problemas de hardware, pero ellos podrían pasar. El permiso tanto UDLD como Loop Guard proporciona el nivel más alto de protección.

Marcos Huerta S.

140


Protocolos para Transportar Información VLAN Antes de ir a una discusión de protocolos de Capa 3 de enrutamiento, es importante cubrir algo adicional al protocolo de Capa 2 que pueden ser desplegados en redes cambiadas aquel uso VLANs.

Cuando VLANs son puestos en práctica en una red cambiada, los switches necesitan un método de asegurarse que el tráfico intra-VLAN va a los interfaces correctos. Para beneficiarse de las ventajas de VLANs, los switches tienen que asegurar que el tráfico destinado a VLAN particular va a esta VLAN y no a cualquier otro VLAN. Este puede ser llevado a cabo etiquetando paquetes con la información VLAN. Los Sistemas de Cisco soportan el protocolo enlace de Inter-switch (ISL) e IEEE 802.1Q para la marcación. Estos protocolos fueron mencionados en El capítulo 5, pero las secciones siguientes proporcionan unos detalles más y también cubren el Cisco VLAN protocolo de dirección, VLAN Protocolo trunk (VTP).

Protocolo de Enlace de Inter-switch El Kalpana, Inc, que fue adquirido por Cisco Systems, Inc, desarrolló ISL para llevar la información VLAN en un enlace de switches a router o switch a switch Ethernet 100Mbps. El ISL es un protocolo Cisco-patentado que es suplantado por IEEE estándar 802.1Q protocolo. El ISL generalmente no debería ser recomendado a menos que sus clientes de diseño de red tengan switches Cisco más viejos que no apoyan IEEE 802.1Q.

Un enlace que lleva el tráfico para multiples VLANs es llamado trunk. Antes de colocar un paquete en un trunk, ISL encapsula el paquete en la cabecera ISL y envia. La cabecera incluye un VLAN ID. El paquete mantiene la encapsulación ISL cuando esto viaja a través de la red cambiada, hasta que sea enviado a un puerto de enlace de acceso a un sistema final. Antes de salir al puerto de enlace de acceso, el switch quita la información ISL. Como el paquete llegó con un VLAN ID, el switch sabe qué interfaces deberían recibir el paquete si esto es un multicast o un broadcast.

Protocolo Trunk de VLAN Cisco Protocolo Trunk de VLAN (El VTP) es un switch a switch y switch a router protocolo de dirección de VLAN que cambia cambios de configuración VLAN cuando ellos son hechos a la red. El VTP maneja la adición, la eliminación, y renombrar de VLANs en una red de campus sin requerir la intervención manual en cada switch. El VTP también reduce la configuración manual por automáticamente configurando un nuevo switch o router con la existencia de la información de VLAN cuando el nuevo switch o el router son añadidos a la red.

Marcos Huerta S.

141


En redes cambiadas grandes, usted debería dividir la red en multiples dominios VTP. La división de la red en múltiples dominos reduce la cantidad de información VLAN que cada switch debe mantener. Un switch acepta la información VLAN sólo de switches en su dominio. Los dominios VTP son sueltamente análogas a sistemas autónomos en una red ruteada donde un grupo de routers comparte políticas administrativas comunes. Multiples Dominios VTP son recomendadas en redes grandes. En tamaño medio y pequeñas redes, un dominio VLAN sola es suficiente y minimiza problemas potenciales.

Los switches Cisco pueden ser configurados en servidor VTP, cliente, o modo transparente. En el modo de servidor VTP, usted puede crear, modificar, y suprimir VLANs. Los servidores de VTP salvan sus configuraciones VLAN cuando ellos son impulsados abajo. Los clientes de VTP intercambian la información con otros clientes VTP y servidores, pero usted no puede crear, cambiar, o suprimir VLANs en un cliente VTP. Usted debe hacer esto en un servidor VTP. Los clientes de VTP no salvan sus configuraciones VLAN cuando impulsado abajo. Sin embargo, la mayor parte de switches deberían ser clientes para evitar la información VLAN que se desincronice si las actualizaciones son hechas en muchos switches.

Un switch transparente VTP no anuncia su configuración VLAN y no sincroniza su configuración VLAN basada en la publicidad recibida. Sin embargo, los switches VTPtransparentes envian realmente la publicación de VTP recibida en otros switches. Use el modo transparente cuando un switch en medio de la topología no tiene que emparejar otras configuraciones de switch, pero causaría problemas para otros switches si esto no enviara la información VLAN.

Selección de Protocolos de Enrutamiento Un protocolo de enrutamiento deja a un router dinámicamente aprender a alcanzar otras redes e intercambiar esta información con otros routers o hosts. La selección de protocolos de enrutamiento para su cliente de diseño de red es más difícil que la selección de protocolos de conmutación, porque hay tantas opciones. La decisión es tomada más fácil si usted puede usar una tabla de decisión, como es mostrado en la Tabla Nro.16. Armado con un entendimiento sólido de objetivos de su cliente e información en las características de protocolos de enrutamiento diferentes, usted puede tomar una decisión sana sobre cual protocolos de enrutamiento recomendar.

Caracterización de Protocolos de Enrutamiento Todos los protocolos de enrutamiento tienen el mismo objetivo general: compartir información de accesibilidad de red entre routers. Los protocolos que consiguen este objetivo en una variedad de caminos. Algunos protocolos de enrutamiento envían una tabla de enrutamiento completa a otros routers. Otros protocolos de enrutamiento envían

Marcos Huerta S.

142


la información específica del estado del enlace directamente relacionados. Algunos protocolos de enrutamiento envían periódico paquetes hello para mantener su estado con los routers de punto. Algunos protocolos de enrutamiento incluyen la información avanzada como una máscara subnet o longitud de prefijo con la información de ruta. La mayor parte de protocolos de enrutamiento comparten la información (learned) dinámica, pero en algunos casos, la información de configuración estática es más apropiada.

Table 16. Comparaciones de Protocolo de Enrutamiento Vector Distancia o estado de Enlace

Interior o Exterior

Classful or Classless

Metrica soportada

Escalabilidad

Tiempo de Convergencia

Consumo de recurso

Soporta Securidad? Autenticación Routes?

Facil diseño de matener y repara

RIP version 1

Distance vector

Interior

Classful

Hop count

15 hops

Can be long (if no load balancing)

Memory: low CPU: low Bandwidth: high

No

Easy

RIP version 2

Distance vector

Interior

Classless

Hop count

15 hops

Can be long (if no load balancing)


Yes

Easy

IGRP

Distance vector

Interior

Classful

Bandwidth, 255 hops delay, (default is reliability, load 100)

Quick (uses triggered updates and poison reverse)


No

Easy

EIGRP

Advanced Distance vector

Interior

Classless

Bandwidth, 1000s of delay, routers reliability, load

Very quick (uses DUAL algorithm)

Memory: moderate CPU: low Bandwidth: low

Yes

Easy

OSPF

Link state

Interior

Classless

Cost (100 million divided by bandwidth on Cisco routers)

A few hundred routers per area, a few hundred areas

Quick (uses linkstate advertisements and hello packets)

Memory: high CPU: high Bandwidth: low

Yes

Moderate

BGP

Path vector

Exterior

Classless

Value of path attributes and other configurable factors

1000s of routers

Quick (uses update and keepalive packets, and withdraws routes)


Yes

Moderate

IS-IS

Link state

Interior

Classless

Configured path value, plus delay, expense, and errors

Hundreds of routers per area, a few hundred areas

Quick (uses linkstate advertisements)


Yes

Moderate

RTMP

Distance vector

Interior

N/A

Hop count

15 hops

Can be long

Memory: moderate CPU: moderate Bandwidth: high

No

Easy

AURP

Distance vector

Interior or exterior

N/A

Hop count

15 hops on each side

Pretty quick (supports summarization)

Memory: low CPU: moderate

Yes

Moderate

Marcos Huerta S.

143


Table 16. Comparaciones de Protocolo de Enrutamiento Vector Distancia o estado de Enlace

Interior o Exterior

Classful or Classless

Metrica soportada

Escalabilidad

Tiempo de Convergencia

Consumo de recurso

Soporta Securidad? Autenticación Routes?

Facil diseño de matener y repara

Bandwidth: low IPX RIP

Distance vector

Interior

N/A

Ticks and hop count

15 hops

Pretty quick (uses immediate updates)

Memory: moderate CPU: moderate Bandwidth: high

No

Easy

NLSP

Link state

Interior

N/A

Cost (an integer between 1 and 63) and bandwidth

127 hops

Quick (uses linkstate packets and hierarchical routing)


Yes

Moderate

Los protocolos de enrutamiento que se diferencian en su escalabilidad y características de performance. Muchos protocolos de enrutamiento fueron diseñados para pequeñas redes. Algunos protocolos de enrutamiento trabajan mejor en un ambiente estático y tienen un tiempo duro convergiendo a una nueva topología cuando los cambios ocurren. Algunos protocolos de enrutamiento se suponen para unir redes de campus interiores, y los otros se suponen para unir empresas diferentes. Las pocas siguientes secciones proporcionan más información en las características diferentes de protocolos. Tabla Nro.16 al final de este capítulo resume la comparación de varios protocolos de enrutamiento.

Vector de distancia Vs Estado de Enlace Protocolos de Enrutamiento El enrutamiento de protocolos se cae en dos clases principales: protocolos de vector de distancia y protocolos estado de enlace. Esta sección cubre protocolos de vector de distancia primero. Los protocolos siguientes son protocolos de vector de distancia (o los derivados de los protocolos de vector de distancia):

Ø

IP Routing Information Protocol (RIP) version 1 and 2.

Ø

IP Interior Gateway Routing Protocol (IGRP).

Ø

IP Enhanced IGRP (EIGRP) (an advanced distance-vector protocol).

Ø

IP Border Gateway Protocol (BGP) (a path-vector routing protocol).

Ø

Novell NetWare Internetwork Packet Exchange Routing Information Protocol (IPX RIP).

Ø

AppleTalk Routing Table Maintenance Protocol (RTMP).

Ø

AppleTalk Update-Based Routing Protocol (AURP).

Marcos Huerta S.

144


El termino vector significa dirección o curso. Un vector distancia es un curso que también incluye información de la longitud del curso. Mucho protocolos de enrutamiento vector distancia especifica la longitud del curso con una cuenta de salto. A cuenta de salto especifica el número de routers que deben ser cruzados para alcanzar una red de destino. (Para algunos protocolos, cuenta de salto significa el número de enlaces más bien que el número de routers.)

Un mantenimiento de protocolo de enrutamiento vector de distancia (y transmite) una tabla de enrutamiento que pone redes conocidas en una lista y la distancia a cada red. Tabla Nro 16 muestra una tabla vector de distancia típica.

Tabla Nro.16. Vector de distancia que Derrota Mesa Red

Distancia (en Saltos)

Envíe (a Después Salto)

10.0.0.0

0

(directamente

Puerto 1

relacionado) 172.16.0.0

0

(directamente

Puerto 2

relacionado) 172.17.0.0

1

172.16.0.2

172.18.0.0

2

172.16.0.2

192.168.1.0

1

10.0.0.2

192.168.2.0

2

10.0.0.2

Un protocolo vector distancia envía su tabla de enrutamiento a todos los vecinos. Esto envía un paquete de broadcast que alcanza todos otros routers en el segmento local (y cualquier host que usa la información de enrutamiento). Los protocolos de vector distancia pueden enviar la tabla entera cada vez, o ellos pueden enviar simplemente actualizaciones después de la primera transmisión y sólo de vez en cuando enviar la tabla de enrutamiento completa.

Split-Horizon, Hold-Down y Poison-Reverse Caracteristicas del Protocolo VectorDistancia Un router que corre un protocolo de vector de distancia envía a su tabla de enrutamiento cada uno de sus puertos en una base periódica. Si el protocolo soporta la técnica de horizonte dividido, el router envía sólo rutas que son accesibles vía otros puertos. Este reduce el tamaño de la actualización y, lo que es más importante mejora la exactitud de

Marcos Huerta S.

145


enrutamiento de información. Con el horizonte dividido, un router no envia otra información hacia el otro router que ruta es mejor aprendida en la localidad.

La mayor parte de protocolos de vector de distancia también implementan un temporizador de cuenta regresiva de modo que no crean nueva información sobre una ruta sospechosa a una red, por si la información esté basada en datos antiguos. Los temporizadores de cuenta regresiva son un modo estándar de evitar loop que pueden pasar durante la convergencia. Para entender el problema de loop, considere la red mostrada en La figura nro.30.

Figura Nro.30 Tablas de Enrutamiento deVector distancia Parcial de un Router A y Router B

Cuando los routers transmiten sus broadcast a las tablas de enrutamiento, ellos simplemente envían la de Red y Distancia que se pone dentro la tabla. Ellos no envían en la(Salto Después) columna Send To, que es una de las causas del problema de loop. La secuencia de acontecimientos que pueden conducir a un loop de enrutamiento es como sigue:

1. El Router A para la conexión a la red fallada 172.16.0.0. 2. El Router A quita la Red 172.16.0.0 de su tabla de enrutamiento. 3. Basado en publicaciones de broadcast anteriores del router A, el router B transmite su tabla de enrutamiento que dice que el router B puede alcanzar la red 172.16.0.0. 4. El Router A añade la Red 172.16.0.0 a su tabla de enrutamiento Send To (Salto Después) valor del Router B y una distancia de 2. 5. El Router A recibe un paquete para un host en la red 172.16.0.0. 6. El Router A envía el paquete al Router B. 7. El Router B envía el paquete al Router A.

Los loop de paquetes de acá para allá del Router A al Router B se envian hasta que el valor de tiempo IP expiran. (El tiempo a vivo es un campo en la cabecera IP de un paquete IP que es decrementedo cada vez que un router procesa el paquete.)

Marcos Huerta S.

146


Para hacer asuntos peores, sin el horizonte dividido, en algún punto del Router A envía una actualización de ruta que lo dice puede conseguir Conectarse a la red 172.16.0.0, causando que el Router B actualize la ruta en su tabla con una distancia de 3. Tanto el Router A como Router B sigue enviando actualizaciones de ruta hasta llegar a infinito de los alcances de campo de distancia. (El protocolo de enrutamiento arbitrariamente define una distancia que significa infinito. Por ejemplo, 16 infinito de medios para RIP.) Cuando se pone el infinito de distancia, los router quitan la ruta.

El problema de actualización de ruta es llamado el problema de cuenta a infinito. Una función de cuenta regresiva dice a un router no añadir o actualizar la información para una ruta que ha sido quitada recientemente, hasta que un temporizador de cuenta regresiva expire. En el ejemplo, si el Router usa una cuenta regresiva, esto no añade la ruta para la red 172.16.0.0 que el Router B envía. El horizonte dividido también soluciona el problema en el ejemplo, porque si el Router B usa el horizonte partido, esto no dice el Router sobre una ruta a 172.16.0.0.

Los mensajes envenenamiento inverso son otro modo de apresurarse la convergencia y evitar loop. Con el envenenamiento inverso, cuando un router aprende una ruta de otro router, esto responde devolviendo una actualización a aquel router que pone la distancia en una lista a la red como el infinito. Por hacer así, el router explícitamente declara que la ruta no es directamente accesible.

Las actualizaciones provocadas son otro rasgo avanzado de protocolos de vector distancia que pueden apresurarse la convergencia. Con actualizaciones provocadas, un protocolo de enrutamiento anuncia fallas de ruta inmediatamente. Más bien que esperar simplemente el enrutamiento siguiente con regularidad programada actualizan y no incluso en la actualización cualquier ruta que ha fallado, un router puede enviar inmediatamente una actualización. La actualización (provocada) inmediata pone la ruta fallada en una lista con el juego de distancia al infinito.

Protocolos de Enrutamiento Estado de Enlace Protocolos de enrutamiento de estado de enlace no intercambian las tablas de enrutamiento. En cambio, los routers que corren un protocolo de enrutamiento estado de enlace intercambian la información sobre los enlaces con los cuales un router está conectado. Cada router aprende bastante información sobre enlaces en las redes de router de punto para construir su propia tabla de enrutamiento.

Los protocolos siguientes son protocolos de enrutamiento estado de enlace: Ø

El Camino mas Corto Primero (OSPF)

Marcos Huerta S.

147


Ø

El Sistema Intermedio a Sistema Intermedio (IS - IS)

Ø

Protocolo de Servicios de Enlace de NetWare (NLSP)

Un protocolo de enrutamiento estado de enlace usa el algoritmo un camino más corto primer, como el algoritmo Dijkstra, determinar como alcanzar redes de destino. El algoritmo Dijkstra, que es nombrado por el informático que inventó el algoritmo, Edsger Dijkstra, soluciona el problema de encontrar el camino más corto de un punto de la fuente en un gráfico matemático a un punto de destino. Una de las bellezas del algoritmo es que encontrando el camino más corto a un destino, una fuente también puede encontrar el camino más corto a todos los puntos en el gráfico al mismo tiempo. Este hace el algoritmo sea perfecto para un protocolo de enrutamiento, aunque esto tenga realmente otros usos.

Con el enrutamiento estado de enlace, los routers usan un protocolo hello para establecer una relación (llamada una adyacencia) con routers vecinos. Cada router envía la publicación estado de enlace (LSAs) a cada vecino adyacente. La publicación identifica enlaces y métrica. Cada vecino que recibe una publicación propaga el anuncio en sus vecinos. El resultado es que cada router termina con una base de datos estado de enlace idéntica que describe los nodos y enlaces en el gráfico de redes. Usando el algoritmo Dijkstra, cada router independientemente calcula su camino más corto a cada red y entra en esta información en su tabla de enrutamiento.

El enrutamiento estado de enlace requiere más poder de CPU en el router y memoria que el enrutamiento de vector de distancia, y puede ser más difícil de resolver problemas. El enrutamiento estado de enlace tiene realmente algunas ventajas sobre el enrutamiento de vector de distancia, sin embargo. En general, el enrutamiento estado de enlace fue diseñado para usar menos ancho de banda, ser menos propensa a loop, y convergir más rápidamente que el enrutamiento de vector de distancia, (aunque haya protocolos de vector de distancia, como EIGRP, que tienen aquellas calidades también).

Selección entre Vector Distancia y Protocolos Estado de Enlace Según documentos de diseño de Cisco, usted puede usar las pautas siguientes para ayudarle a decidirse que tipo de protocolo desplegar.

Elija protocolos de vector distancia cuando: Ø

La red usa una topología simple, plana y no requiere un diseño jerárquico.

Ø

La red usa una topología simple "Hub- and Spoke".

Ø

Los administradores no tienen bastante conocimiento para operar y resolver problemas de protocolos de estado de enlace.

Marcos Huerta S.

148


Ø

En el peor de los casos el tiempos de convergencia en la red no son una preocupación.

Elija protocolos estado de enlace cuando: Ø

El diseño de red es jerárquica, que es por lo general el caso para redes grandes.

Ø

Los administradores conocen sobre el protocolo estado de enlace seleccionado.

Ø

La convergencia rápida de la red es crucial.

Métrica de los Protocolo de Enrutamiento El protocolo de enrutamiento usa métrica para determinar qué camino es preferible cuando más de un camino está disponible. Enrutar los protocolos que varían en cual métrica son soportados. El protocolo vector distancia tradicional usa solo la cuenta de salto. Los protocolos nuevos también pueden tener tardanza en cuenta, ancho de banda, fiabilidad, y otros factores. La métrica puede afectar la escalabilidad. Por ejemplo, el RIP soporta sólo 15 saltos. La métrica también puede afectar la performance de la red. Un router que sólo usa el salto cuenta solamente sus únicas

métricas

perdidas la oportunidad de seleccionar una ruta que tiene más saltos sino también más ancho de banda que otra ruta.

Protocolos Jerárquico contra Enrutamiento No jerárquicos Algunos protocolos de enrutamiento no apoyan la jerarquía. Todos los routers tienen las mismas tareas, y cada router es un punto de otro router. Los protocolos de enrutamiento soportan la jerarquía, por otra parte, asigna tareas diferentes a routers, y routers de grupo en áreas, sistemas autónomos, o dominios. En un arreglo jerárquico, algunos routers se comunican con routers locales en la misma área, y otros routers tienen el trabajo de conectarse con areas, dominios, o sistemas autónomos. Un router que conecta un área a otras áreas puede resumir rutas para su área local. El Sumarizar realza la estabilidad porque los routers son protegidos de problemas no en su propia área.

Protocolos Interiores Vs Exteriores El protocolode enrutamiento también puede ser caracterizado por donde ellos son usados. El protocolo interior, como el RIP, OSPF, e IGRP, es usado por routers dentro de la misma empresa o sistema autónomo. El

protocolo, como BGP, realiza el

enrutamiento entre sistemas autónomos múltiples. El BGP es usado en el Internet por routers de punto en sistemas autónomos diferentes para mantener una vista consecuente de la topología del Internet.

Marcos Huerta S.

149


Protocolos de Enrutamiento con Clases Vs Protocolos de Enrutamiento sin Clases En secciones anteriores se habló de las diferencias entre protocolos de enrutamiento IP con clases y protocolos de enrutamiento sin clases. Resumir los conceptos en La parte 6, "Diseñando Modelos de Direccionamientoy Nombramiento," un protocolo de enrutamiento, como el RIP o IGRP, siempre considera la clase de dirección de IP (Clase, A, B, o C). La dirección sumarizada es automática por el número de red principal. Este significa que las subredes de discontiguas no son visibles el uno al otro, y la subred de longitud variable que enmascara (VLSM) no es soportada.

Los protocolos sin clases, por otra parte, transmiten la longitud del prefijo o la información de la mascar de subnet con la direcciones IP de la red. Con protocolos de enrutamiento sin clases, el espacio de dirección IP pueden trazar un mapa de modo que las subredes de discontiguas y VLSM sean soportadas. Los espacios de las direcciones IP pueden trazar un mapa con cuidado de modo que las subredes sean arregladas en bloques contiguos, permitiendo las actualizaciones de ruta a ser resumidas en límites de área.

Dinámico Contra Estático y Enrutamiento por Defecto A ruta estática es una ruta que es configurada a mano y no confía en actualizaciones de un protocolo de enrutamiento. En algunos casos, no es necesario usar un protocolo de enrutamiento. Las rutas estáticas a menudo son usadas para conectarse a un bloque de red. Un bloque de red reside en el borde de unas redes y no es usada como un camino de tránsito para el tráfico que trata de ponerse en algún otro sitio. Un ejemplo de una red de bloque es una compañía que se une al Internet vía un enlace solo a un Proveedor de Internet (ISP). El ISP puede tener una ruta estática a la compañía. No es necesario dirigir un protocolo de enrutamiento entre la compañía y el ISP.

Una desventaja con el enrutamiento estático es la cantidad de administración que puede ser requerida, sobre todo en redes grandes. En redes pequeño, las rutas estáticas tienen muchas ventajas, sin embargo, no deberían ser pasadas por alto al diseñar o mejorar una red. Las rutas estáticas reducen el uso de ancho de banda y son fáciles de detectar fallas. Las rutas estáticas permiten que usted use una ruta además de la que el enrutamiento dinámico eligio, que puede ser beneficioso cuando usted quiere que el tráfico siga un camino específico. Las rutas estáticas también pueden dejarle usar una ruta que es más específica que los permisos de protocolo de enrutamiento dinámico. Las rutas estáticas también facilitan la seguridad porque ellos le dan más control sobre cual redes son accesibles.

La Mayor parte el ISPs tienen muchas rutas estáticas en sus tablas de enrutamiento para alcanzar las redes de sus clientes. En un ISP, cuando el tráfico llega de otros sitios

Marcos Huerta S.

150


del Internet con una dirección de destino que empareja la dirección de red asignada a un cliente, la decisión de encaminamiento es simple. El tráfico entra sólo en una dirección, al router del cliente. No hay ninguna necesidad de un protocolo de encaminamiento.

En routers Cisco, las rutas estáticas tienen prioridad sobre rutas al mismo destino que son aprendidas vía un protocolo de enrutamiento. El Cisco IOS Software también soporta una ruta estática flotante, que es una ruta estática que tiene una distancia administrativa más alta que rutas dinámicamente aprendidas y puede ser así anulada por rutas dinámicamente aprendidas. Una aplicación importante de poner a flote rutas estáticas debe proporcionar rutas de backup cuando ninguna información dinámica está disponible.

Una ruta por defecto es un tipo especial de la ruta estática que es usada cuando no hay ninguna entrada en la tabla de enrutamiento para una red destino. También se llama a la ruta por defecto "la ruta de último recurso." En algunos casos, una ruta por defecto es todo que es necesario. Tome el ejemplo de la red de cliente relacionada con un ISP otra vez. En el lado de cliente, puede no ser necesario o práctico para aprender rutas a todas las redes en el Internet. Si hay sólo una conexión al Internet (del enlace al ISP), todo el tráfico de Internet tiene que entrar en aquella dirección de todos modos. De este modo, el diseñador de red de empresa puede definir simplemente una ruta por defecto que señala al router del ISP.

Aunque estática y rutas por defecto reduzcan el uso de recurso, incluso ancho de banda y CPU del router y recursos de memoria, la compensación es una pérdida de la información detallada sobre el enrutamiento. Los routers con una ruta por defecto siempre envían el tráfico que no es local a un router de tráfico de punto. Ellos no tienen ningún modo de saber que el otro router puede haber perdido algunas de sus rutas. Ellos también no tienen ningún modo de saber si un destino es siempre inalcanzable (por ejemplo, cuando alguien hace un ping y envía múltiples ping a numerosas direcciones de destino IP, algunos de las cuales no son accesibles). Un router con una ruta por defecto envia estos paquetes. Esto no tiene ningún modo de distinguir los destinos que esto no puede alcanzar los destinos que ningun router alcanzara. El enrutamiento por defecto también puede hacer que un router use caminos subóptimos. Para evitar estos tipos de problemas, use el enrutamiento dinámica.

Enrutamiento a Petición El enrutamiento a petición (ODR) es una caracteristica patentado por Cisco que proporciona enrutamiento IP para redes de bloques. El ODR usa el Protocolo de Descubrimiento Cisco (CDP) para llevar la información de enrutamiento mínima entre un sitio principal y bloques de routers. El ODR evita la sobrecarga del enrutamiento

Marcos Huerta S.

151


dinámico sin incurrir en la configuración y manejo de sobrecarga del enrutamiento estático.

La información requerida del enrutamiento IP representar la topología de red para un router en una red de bloques es bastante simple. Por ejemplo, en una topología "huband-spoke", los routers de bloque y de spoke tienen sitios a una conexión WAN hacia el router de hub, y un pequeño número de segmentos de LAN directamente conectados con el router de bloques. Estas redes de bloques pueden no requiere que el router de bloques aprenda cualquier enrutamiento de información IP dinámico.

Con ODR, el router de bloque proporciona la información de ruta por defecto a los routers de bloques, así eliminando la necesidad de configurar una ruta por defectoen cada router de bloques. Los routers de bloques usan CDP para enviar la información de prefijo IP para las interfaces directamente conectados al hub. El router de hub instala rutas de red de bloques en su tabla de enrutamiento. El router de hub también puede ser configurado para redistribuir estas rutas en cualquier IP dinámico configurado el protocolos de enrutamiento. En el router de bloques, ningúna IP del protocolo de enrutamiento es configurada. Este simplifica la configuración y es a menudo una solución buena para la capa de acceso de una red jerárquicamente diseñada.

Restricciones de Escalabilidad para Protocolos de Enrutamiento Seleccionar un protocolo de enrutamiento para un cliente, considere los objetivos de su cliente para escalar la red a una talla grande e investigar las preguntas siguientes para cada protocolo de enrutamiento. Cada una de las preguntas se dirige a una restricción de escalabilidad para protocolos de enrutamiento: Ø

¿Hay allí algún límite colocado en la métrica?

Ø

¿Cómo rápidamente puede el protocolo de enrutamiento convergir cuando las mejoras o los cambios ocurren? Los protocolos estado de enlace tienden a convergir más rápidamente que protocolos de vector distancia. Hablan de la convergencia más detalladamente en la siguiente sección.

Ø

¿Con qué frecuencia los enrutamientos y actualizaciones o publicaciones de estado de enlace son transmitida? ¿La frecuencia de publicaciones es una función de un temporizador, o es actualizaciones provocadas por un acontecimiento, como un fallo de enlace?

Ø

¿Cuántos datos son transmitidos en una publicación de enrutamiento? ¿La tabla entera? ¿Sólo cambios? ¿Es usado el horizonte dividido?

Ø

¿Cuánto la ancho de banda es usada para enviar publicaciones de enrutamiento? la utilización de Ancho de banda es en particular relevante para enlaces de serie de ancho de banda baja.

Marcos Huerta S.

152


Ø

¿Cómo extensamente enruta publicaciones distribuidas? ¿A vecinos? ¿A un área? ¿A todos los routers en el sistema autónomo?

Ø

¿Cuánta utilización de CPU es requerida para procesar publicaciones de enrutamiento o publicaciones de estado de enlace?

Ø

¿Soportan rutas estáticas y rutas por defecto?

Ø

¿Soporta ruta sumarizada?

Estas preguntas pueden ser contestadas mirando el comportamiento del enrutamiento de protocolo con un analizador de protocolo y estudiando las especificaciones relevantes o Petición de Comentarios (RFCs). Las siguientes secciones en este capítulo también pueden ayudarle a entender el comportamiento de protocolo de enrutamiento mejor.

Convergencia de Protocolo de Enrutamiento Convergencia es el tiempo que esto toma para los routers para llegar a un entendimiento consecuente de la topología de redes después de que un cambio ocurre. Un cambio puede ser un segmento de red o el fallo de router, o un nuevo segmento o el router que se afilia a las redes. Para entender la importancia de la convergencia rápida para su cliente particular, usted debería desarrollar un entendimiento de la probabilidad de cambios frecuentes en la red del cliente. ¿Hay allí enlaces que tienden a fallar a menudo? ¿Es la red del cliente siempre esta "bajo construcción" para mejorar debido a problemas de fiabilidad?

Como los paquetes no pueden ser de fuentes fidedignas enrutados a todos los destinos mientras la convergencia ocurre, el tiempo de convergencia es una coacción de diseño crítica. El proceso de convergencia debería completar dentro de unos segundos para aplicaciones sensibles a tiempo, como aplicaciones de voz y aplicaciones SNA-basadas. Cuando SNA es transportado a través de unas redes IP, un protocolo rápido que converge como OSPF es recomendado. Los protocolos estados de enlace fueron diseñados para convergir rápidamente. Algunos protocolos de vector de distancia, como EIGRP, también fueron diseñados para la convergencia rápida.

Un router comienza el proceso de convergencia cuando nota que un enlace a uno de sus routers de punto ha fallado. Un router Cisco envía paquetes de keepalive cada 10 segundos (en ausencia) para ayudarle a determinar el estado de un enlace. En un enlace punto a punto WAN, un router Cisco envía paquetes de keepalive al router al otro lado del enlace. En LANs, un router Cisco envía paquetes de keepalive a sí mismo.

Si un enlace consecutivo falla, un router puede comenzar el proceso de convergencia inmediatamente si nota que el Portador Detecta (CD) una señalde caida. Por otra parte,

Marcos Huerta S.

153


un router comienza la convergencia después de enviar a dos o tres paquetes de keepalive y no recibir una respuesta. En un Token Ring o red de FDDI, un router puede comenzar el proceso de convergencia casi inmediatamente si nota el proceso de beaconing que indica que un segmento de red está caido. En una red de Ethernet, si el propio transceptor del router falla, esto puede comenzar el proceso de convergencia inmediatamente. Por otra parte, el router comienza el proceso de convergencia después de que ha sido incapaz enviar dos o tres paquetes de keepalive.

Si el protocolo de enrutamiento usa paquetes hello y el temporizador hello es más corto que el temporizador keepalive, el protocolo de enrutamiento puede comenzar la convergencia más pronto. Otro factor que influye en el tiempo de convergencia es el equilibrio de carga. Si una tabla de enrutamiento incluye caminos múltiples a un destino, el tráfico puede tomar inmediatamente otros caminos cuando un camino falla.

Enrutamiento de IP Los Protocolos de Enrutamientos IP más común es el RIP, IGRP, EIGRP, OSPF, IS - IS, y BGP. Las secciones siguientes describen un poco de la performance y las características de escalabilidad de los estos protocolos para ayudarle a seleccionar los protocolos correctos para su cliente de diseño de red.

Protocolo de Enrutamiento de Información El Protocolo de Enrutamiento de Información (RIP) era el primer protocolo de enrutamiento estándar desarrollado para ambientes TCP/IP. EL RIP fue desarrollado al principio para el Sistema de Red de Xerox (XNS) protocolos y fue adoptado por la comunidad IP a principios de los años 1980. El RIP era el protocolo de interior más común durante muchos años, probablemente porque es fácil configurar y corre en numerosos sistemas operativos. Esto está todavía en uso en redes más antiguas y redes donde la simplicidad y la facilidad de la solución son importantes. La versión 1 (RIPv1) de RIP es documentada en RFC 1058. La versión 2 (RIPv2) de RIP es documentada en RFC 2453.

RIP transmite su tabla de enrutamiento cada 30 segundos.

RIP permite 25 rutas por paquete, entonces en redes grandes, se requiere que paquetes múltiples envíen la tabla de enrutamiento entera. La utilización de ancho de banda es una cuestión en redes de RIP grandes que incluyen enlaces de ancho de banda baja.

RIPv1: No soporta subredes ni CIDR. Tampoco incluye ningún mecanismo de autentificación de los mensajes. No se usa actualmente. Su especificación está recogida en el RFC 1058.

Marcos Huerta S.

154


RIPv2: Soporta subredes, CIDR y VLSM. Soporta autenticación utilizando uno de los siguientes mecanismos: no autentificación, autentificación mediante contraseña, autentificación mediante contraseña codificada mediante MD5. Su especificación está recogida en el RFC 1723-2453.

Funcionamiento RIP RIP utiliza UDP para enviar sus mensajes y el puerto bien conocido 520. RIP calcula el camino más corto hacia la red de destino usando el algoritmo del vector de distancias. Esta distancia se denomina métrica. En RIPv1 la métrica es estática y vale 1, en cambio se puede modificar su valor en RIPv2.

RIP no es capaz de detectar rutas circulares, por lo que necesita limitar el tamaño de la red a 15 saltos. Cuando la métrica de un destino alcanza el valor de 16, se considera como infinito y el destino es eliminado de la tabla (inalcanzable).

La métrica de un destino se calcula como la métrica comunicada por un vecino más la distancia en alcanzar a ese vecino. Teniendo en cuenta el límite de 15 saltos mencionado anteriormente. Las métricas se actualizan sólo en el caso de que la métrica anunciada más el coste en alcanzar sea estrictamente menor a la almacenada. Sólo se actualizará a una métrica mayor si proviene del enrutador que anunció esa ruta.

Las rutas tienen un tiempo de vida de 180 segundos. Si pasado este tiempo, no se han recibido mensajes que confirmen que esa ruta está activa, se borra. Estos 180 segundos, corresponden a 6 intercambios de información.

Ventajas y desventajas En comparación con otros protocolos de enrutamiento, RIP es más fácil de configurar. Además, es un protocolo abierto, soportado por muchos fabricantes. Por otra parte, tiene la desventaja que, para determinar la mejor métrica, únicamente toma en cuenta el número de saltos (por cuántos routers o equipos similares pasa la información); no toma en cuenta otros criterios importantes, especialmente el número de saltos. Esto puede causar ineficiencias, ya que puede preferir una ruta de bajo ancho de banda, simplemente porque ocupa menos saltos.

Mensajes RIP Tipos de mensajes RIP Los mensajes RIP pueden ser de dos tipos. Petición: Enviados por algún enrutador recientemente iniciado que solicita información de los enrutadores vecinos.

Marcos Huerta S.

155


Respuesta: mensajes con la actualización de las tablas de enrutamiento. Existen tres tipos: Mensajes ordinarios: Se envían cada 30 segundos. Para indicar que en enlace y la ruta siguen activos. Mensajes enviados como respuesta a mensajes de petición. Mensajes enviados cuando cambia algún coste. Sólo se envían las rutas que han cambiado

Formato de los mensajes RIP Los mensajes tienen una cabecera que incluye el tipo de mensaje y la versión del protocolo RIP, y un máximo de 25 entradas RIP de 20 bytes.

Las entradas en RIPv1 contienen la dirección IP de la red de destino y la métrica. Las entradas en RIPv2 contienen la dirección IP de la red, su máscara, el siguiente enrutador y la métrica. La autentificación utiliza la primera entrada RIP.

IGRP (Interior Gateway Routing Protocol, o Protocolo de enrutamiento de pasarela interior) Cisco desarrolló el Protocolo de Enrutamiento de pasarela interior (IGRP) a mediados de los años 1980 para encontrar las necesidades de clientes que requieren un protocolo interior robusto y escalable. Muchos clientes emigraron sus redes de RIP a IGRP para vencer la limitación de 15 saltos del RIP y la confianza en sólo una métrica (cuenta de salto). El IGRP tiene un temporizador de actualizaciones de 90 segundo para enviar actualizaciones de ruta era también más atractivo que el temporizador de actualizaciones de 30 segundo de RIP para los clientes preocupados por la utilización de ancho de banda.

El IGRP usa una metrica compuesto basado en los factores siguientes: Ø

Ancho de banda. El ancho de banda de segmento más bajo de ancho de banda en el camino. Un administrador de red puede configurar el ancho de banda o usar el valor por defecto, que está basado en el tipo de enlace. (La configuración es recomendada para enlaces WAN rápidos si el valor de ancho de banda es menos que la velocidad actual.)

Ø

Tardanza. Una suma de todas las tardanzas para interfaces salientes en el camino. Cada tardanza está inversamente proporcional al ancho de banda de cada interfaz saliente. La tardanza no es calculada dinámicamente.

Ø

Fiabilidad. La fiabilidad del camino, basado en la fiabilidad de interfaz reportada por routers en el camino. En una actualización de IGRP, la fiabilidad es un número de 8

Marcos Huerta S.

156


bloques, donde 255 es el 100 por ciento confiable y 1 es mínimamente confiable. En ausencia, la fiabilidad no es usada a menos que el comando metric weights sea configurada, en cuyo caso es calculado dinámicamente. Ø

Carga. La carga en el camino, basado en la carga de interfaz reportada por routers en el camino. En una actualización de IGRP, la fiabilidad es un número de 8 bloques, donde 255 es el 100 por ciento cargado y 1 es mínimamente cargado. En ausencia, la carga no es usada a menos que el comando metric weights pesos sea configurada, en cuyo caso la carga es calculada dinámicamente.

El IGRP permite el equilibrio de carga sobre caminos-iguales-métricas y no-caminosmétricas-iguales. En IGRP la caracteristica variance significa que si un camino es tres veces mejor que el otro, el mejor camino puede ser usado tres veces más que el otro camino. (Sólo las rutas con la métrica que son dentro de una cierta variedad de la mejor ruta pueden ser usadas como caminos múltiples. Refiérase a la documentación de configuración Cisco para más información.)

El IGRP tiene un mejor algoritmo para publicar y seleccionar una ruta por defecto tanto como la hace RIP. RIP permite que un administrador de red configure una ruta por defecto, que es identificada como la red 0.0.0.0. El IGRP, por otra parte, permite que verdaderas redes sean señaladas como candidatos por ser una falta. Periódicamente, IGRP explora todas las rutas candidatas a rutas por defecto y elige el que tiene la métrica más baja para ser la ruta por defecto actual. Este caracteristica permite más flexibilidad y la mejor performance que la ruta por defecto estática de RIP.

Para reducir el tiempo de convergencia, los soportes de IGRP provocaron publicaciones. Un router provocado envía una publicaciones, que es una nueva tabla de enrutamiento, en respuesta a un cambio (por ejemplo, el fallo de un enlace). Al recibo de una publicación provocada, otros routers también pueden enviar publicaciones provocadas. Un fallo hace que una onda de mensajes de publicaciones se propague en todas partes de la red, tiempo de convergencia que se apresura así y reducir el riesgo de loop.

Protocolo de Enrutamiento Mejorado de Pasarela Interior El Cisco desarrolló el Protocolo de Enrutamiento Mejorado de Pasarela Interior (EIGRP) a principios de los años 1990 para encontrar las necesidades de clientes de empresa con grande, complejas, redes de multiprotocolo. El EIGRP es compatible con IGRP y proporciona un mecanismo de redistribución automático para permitir que rutas IGRP fueran importadas en EIGRP, y viceversa. El EIGRP también puede redistribuir rutas para el RIP, IS - IS, BGP, y OSPF. Además, el soporte de EIGRP al enrutamiento de Novell y AppleTalk, y puede redistribuir RTMP y rutas de RIP de IPX, y Servicio IPX Anunciando el Protocolo (SAP) actualizaciones.

Marcos Huerta S.

157


EIGRP usa la mismo metrica compuesta que IGRP usa y permanece un protocolo de vector de distancia. EIGRP tiene muchos caracteristicas avanzadas y comportamientos no encontrados en IGRP u otros protocolos de vector de distancia, sin embargo Aunque EIGRP todavía envíe vectores con la información de distancia, las actualizaciones son no periódicas, parciales, y saltaron. No periódico significa que las actualizaciones son enviadas sólo cuando hay cambios en la métrica más bien que con regularidad. Parcial significa que las actualizaciones incluyen sólo rutas que se han cambiado, no cada entrada en la tabla de enrutamiento. Saltado significa que las actualizaciones son enviadas sólo a roters afectados. Estos comportamientos significan que EIGRP usa ancho de banda muy pequeña. A Diferencia de IGRP, las publicaciones de EIGRP llevan una longitud de prefijo con cada número de red, que hace EIGRP un protocolo sin clases.

En ausencia, EIGRP resume rutas en los límites de red de classful, sin embargo. Sumarización automática puede ser apagada y manual sumarización usada a cambio, que puede ser provechoso cuando una red incluye subredes de discontiguas.

Uno de los objetivos principales de EIGRP es ofrecer la convergencia muy rápida en redes grandes. Para encontrar este objetivo, los diseñadores de EIGRP adoptaron el algoritmo de actualización de difusión (DUAL) aquel doctor J. J. El Garcia-Luna-Aceves se desarrolló en SRI Internacional.

DUAL especifica un método para routers para almacenar la información de enrutamiento de los vecinos de modo que los routers puedan cambiar a rutas alternativas muy rápidamente. Los routers también pueden preguntar otros routers para aprender rutas alternativas y enviar paquetes hello para determinar la accesibilidad de vecinos. Las garantías DUALES una topología sin loop, así no hay ninguna necesidad de un mecanismo de asimiento abajo, que es otra caracteristica que minimiza el tiempo de convergencia.

DUAL es una razón que EIGRP usa considerablemente menos ancho de banda que IGRP u otros protocolos de vector de distancia. Un router que usa DUAL desarrolla su tabla de enrutamiento usando el concepto de un sucesor factible. Un sucesor factible es un router vecino que tiene el camino de lo-menos-costo a un destino. Cuando un router descubre que un enlace ha fallado, si un sucesor factible tiene una ruta alterna, cambia al router a la ruta alterna inmediatamente, sin causar algún tráfico de red. Si no hay ningún sucesor, el router envía una pregunta a vecinos. La pregunta se propaga a través de la red hasta que una nueva ruta sea encontrada.

Marcos Huerta S.

158


Un router EIGRP desarrolla una tabla de topología que contiene todos los destinos anunciados por routers que colindan. Cada entrada en la tabla contiene un destino y una lista de vecinos que han publicado el destino. Para cada vecino, la entrada incluye la métrica que el vecino publico para aquel destino. Un router calcula su propio métrica para el destino usando la metrica de cada vecino en la combinación con loa metrica del vecino los usa el router para alcanzar al vecino. El router compara la métrica y determina el camino de costo más bajo a un destino y un sucesor factible para usar por si el camino de costo más bajo falle.

EIGRP puede escalar a miles de nodos. Para asegurar la buena performance en redes grandes, EIGRP debería ser usado en redes con topologías jerárquicas simples.

El Primer Camino mas Corto A finales de los años 1980, el IETF reconoció la necesidad de desarrollar un protocolo de enrutamiento estado de enlace interior para encontrar las necesidades de redes de empresa grandes que fueron obligadas por las limitaciones de RIP. El Primer Camino mas Corto (OSPF) protocolo de enrutamiento es un resultado del trabajo del IETF. El OSPF es definido en RFC 2328.

Las ventajas de OSPF son como sigue: Ø

El OSPF es un estándar abierto apoyado por muchos vendedores.

Ø

El OSPF converge rápidamente.

Ø

El OSPF certifica cambios de protocolo para encontrar objetivos de seguridad.

Ø

El OSPF apoya subredes de discontiguas y VLSM.

Ø

El OSPF envía paquetes de multicast, más bien que transmitir paquetes, que reduce la utilización de CPU en hosts de LAN (si los hosts tienen NICs capaz de filtrar multicast).

Ø

Las redes de OSPF pueden ser diseñadas en áreas jerárquicas, que reduce memoria y requerimientos de CPU en routers.

Ø

El OSPF no usa mucho ancho de banda.

Para minimizar la utilización de ancho de banda, OSPF propaga sólo cambios. Otro tráfico de red es limitado con paquetes de sincronización de base de datos que ocurren con poca frecuencia (cada 30 minutos) y paquetes hello que establecen y mantienen adyacencias vecinas y son usados para decidir un router designado en LANs. Los Hellos son enviados cada 10 segundos. En dialup y enlaces de RDSI configurados como el circuito de demanda, OSPF nunca puede estar quieto. En este caso, los routers de OSPF suprimen hellos y los paquetes de sincronización de base de datos.

Marcos Huerta S.

159


Sobre el arranque y cuando hay cambios, un router OSPF multicast la publicación de los estado de enlace (LSAs) a todos los otros routers dentro de la misma área jerárquica. Los routers de OSPF acumulan la información de estado de enlace para calcular el camino más corto a una red de destino. El cálculo usa el algoritmo Dijkstra. El resultado del cálculo es una base de datos de la topología, llamada la base de datos de estado de enlace. Cada router en un área tiene una base de datos idéntica.

Todos los routers dirigen el mismo algoritmo, en paralelo. De la base de datos de estado de enlace, cada router construye un árbol de los caminos más cortos, asi como la raíz del árbol. El árbol de camino más corto proporciona la ruta a cada destino. La información de enrutamiento por fuera sacada aparece en el árbol como hojas. Cuando varias rutas de costo igual a un destino existen, el tráfico es distribuido igualmente entre ellos.

Según RFC 2328, el costo de una ruta es descrito por "una sola métrica sin dimensiones " que es "configurable por un administrador de sistema."

Un costo tiene que ver con el lado de salida de cada interfaz del router. El costo mas bajo, es más probablemente el interfaz debe ser usado para enviar el tráfico de datos. Un costo también tiene que ver con rutas por fuera sacadas (por ejemplo, rutas aprendidas de un protocolo de enrutamiento diferente).

En un router Cisco, el costo de una interfaz por defecto a 100,000,000 dividido con el ancho de banda para el interfaz. Por ejemplo, tanto FDDI como Ethernet 100-Mbps tienen un costo de 1. El costo puede ser a mano configurado. Por lo general es lo mejor si ambos finales de un enlace usan el mismo costo. Si un router Cisco es un final de un enlace y un router non-Cisco es al otro final, usted podría tener que configurar a mano el costo. Como OSPF define el costo métrica tan ampliamente, no se requiere que vendedores convengan como el costo es definido.

Arquitecturas de OSPF El OSPF permite que conjuntos de redes sean agrupados en áreas. La topología de un área es escondida del resto del sistema autónomo. Escondiendo la topología de un área, el tráfico enrutado es reducido. También, el enrutamiento dentro del área es determinada sólo por la propia topología del área, proporcionando la protección de área de datos de enrutamientos malos. Dividiendo routers en áreas, la memoria y los requerimientos de CPU para cada router son limitadas. Un backbone contiguo de área, es llamada el Área 0, cuando una red de OSPF es dividida en áreas. Cada otra área se conecta al Área 0 vía un router de frontera de área (ABR), como mostrado en la figura nro.31. Todo el tráfico entre áreas debe viajar por el

Marcos Huerta S.

160


Área 0. El área 0 debería tener la alta disponibilidad, el rendimiento, y la ancho de banda. El área 0 debería ser fácil para poder y resolver fallas. Un grupo de routers en un rack conectados vía LAN rápido hace un Área buena 0 para muchos clientes.

Figura Nro. 31. Áreas de OSPF Conectadas vía ABRs

Además de ABRs, una red de OSPF puede incluir uno o varios routers de límite de sistema autónomos (ASBRs). Un ASBR conecta una red de OSPF a un sistema autónomo diferente o a una red que usa un protocolo de enrutamiento además de OSPF. Por ejemplo, un ASBR podría conectar una red de campus OSPF interna al Internet.

Cuando diseñe una red de OSPF, asegúrese para asignar números de red en bloques que pueden ser sumarizados. Un ABR debería sumarizar rutas detrás de ello para evitar routers en el backbone y otras áreas que tiene que saber detalles sobre un área particular. La sumarización debe ser configurada en routers Cisco con el comando de area-range

Un ABR que conecta una red de bloques puede ser configurado para inyectar una ruta por defecto en el área de bloque para todas las redes externas que son fuera del sistema autónomo o son aprendidas de otros protocolos de enrutamiento. El router también puede ser configurado para inyectar una ruta por defecto para rutas internas sumarizadas o no sumarizadas a otras áreas. Si un router inyecta una ruta por defecto para todas las rutas, Cisco llama el área un área totalmente stubby. Las áreas totalmente stubby son una técnica Cisco que trabaja a lo largo de todas las areas stubby ABRs son router Cisco.

El Cisco también soporta no-stubby-áreas, que permite la redistribución de rutas externas en OSPF en otra area stubby. No-stubby áreas son especificadas en RFC 1587. (No-stubby áreas no son muy comunes, pero ellos pueden ser usados en una red de bloques que incluye un enlace de herencia a otro protocolo de enrutamiento o

Marcos Huerta S.

161


sistema autónomo que es diferente del enlace usado por el resto de las redes para alcanzar el mundo exterior.)

A causa de los requerimientos de OSPF puede ser estructurado en áreas y la recomendación que rutas sean sumarizadas, puede ser difícil emigrar una red existente a OSPF. También, ampliando una existencia de red de OSPF puede ser desafiante. Si una red es sujeta a cambio rápido o crecimiento, OSPF no podría ser la mejor opción. Para la mayor parte de redes, sin embargo, OSPF es una opción buena debido a su utilización de bajo ancho de banda, escalabilidad, y compatibilidad con vendedores múltiples.

Sistema Intermedio-hacia-Sistema Intermedio Sistema Intermedio-hacia-Sistema Intermedio (IS-IS) es un protocolo estado de enlace dinámico desarrollado para el uso con la Interconexión de Sistema Abierta (OSI) suite de protocolo. Integrado IS - IS es una implementación de IS - IS para OSI variado y redes de IP que ha ganado la popularidad limitada para el uso dentro de redes de IP grandes, jerárquicas, sobre todo dentro del core de ISPs grandes. IS - IS es protocolo

de

enrutamiento interior de entrada sin clases, que es similar en operación a OSPF aunque algo más flexible, eficiente, y escalable.

Como con OSPF, IS - IS puede ser puesto en práctica en una manera jerárquica. Un router puede desempeñar papeles diferentes: Ø

Nivele 1 ruta de routers dentro de un área.

Ø

Nivele 2 ruta de routers entre áreas.

Ø

Nivele 1–2 routers que participan en el Nivel 1 enrutando intra-área y Nivelan 2 enrutando de interárea.

En IS - IS, el límite entre áreas está en un enlace entre routers. Un router pertenece sólo una área. En la comparación, en OSPF, los límites de área residen dentro de un ABR. Algunos interfaces de router en el ABR pertenecen a una área y otros interfaces pertenecen a otra área. Con IS - IS, todas las interfaces de router están en la misma área. Este hace IS - IS algo más modular y significa que en algunos casos, un área puede ser mejorada sin afectar tan muchos routers.

Nivele 1 router dentro de un área (incluso el Nivel 1-2 routers) mantienen una base de datos estado de enlace idéntica que define la topología de su área. Nivele 2 (incluso el Nivel 1-2 routers) también mantienen una base de datos estado de enlace separada para la topologia del Nivel 2.

Marcos Huerta S.

162


A Diferencia de OSPF ABRs, Nivele 1-2 routers no publican el Nivel 2 rutas para Nivelar 1 router. Un Nivel 1 router no tiene ningún conocimiento de destinos fuera de su propia área. Este hace IS - IS más eficiente que OSPF, en cuanto al uso de CPU y el procesamiento

de

publicaciones,

aunque

la

funcionalidad

similar

pueda

ser

implementada en routers Cisco OSPF puede configurar un área totalmente stubby.

Protocolo de Borde de Entrada El IETF desarrolló el Protocolo de Borde de Entrada (BGP) para sustituir el Protocolo de Entrada Exterior ahora obsoleto (EGP) como el estandar exterior el protocolo de enrutamiento para el Internet. El BGP soluciona problemas que EGP tenía con fiabilidad y escalabilidad. El BGP4, la versión corriente de BGP, es especificado en 1771 RFC.

BGP interno (iBGP) puede ser usado en compañía grande a la ruta entre dominios. BGP externo (eBGP) está usado en ruta entre compañías y participar en el enrutamiento de Internet global. El eBGP a frecuentemente usado en multihome empresarial conexión al Internet. Esto es una idea falsa común que el multihoming requiere BGP, pero este no es verdad. Según los objetivos de un cliente y la flexibilidad de las políticas de su ISP, usted puede multihome con rutas por defecto, como fue hablado en El capítulo 5. El correr eBGP puede ser desafiante, requiriendo un entendimiento de las complejidades del enrutamiento de Internet. El eBGP debería ser recomendado sólo a compañías que tienen a ingenieros de red mayores, y una relación buena con su ISPs. Un ingeniero de red inexperto puede configurar eBGP de tal modo que causa problemas para el Internet entero. También, el eBGP debería ser usado sólo en routers con mucha memoria, una CPU rápida, y una conexión de ancho de banda alta al Internet. Una tabla de enrutamiento de Internet contiene más de 100,000 rutas y crece continuamente cuando el Internet se amplía y más compañías usan BGP a la multihome.

El objetivo principal de BGP es permitir que routers intercambien la información en caminos a redes hacia destino. Cada router BGP mantiene una tabla de enrutamiento que pone todos los caminos factibles en una lista a una red particular. Los routers de BGP intercambian la información de enrutamiento sobre el arranque inicial, y luego envían actualizaciones incrementales, usando el protocolo TCP para la entrega confiable de paquetes BGP. Una actualización especifica atributos de camino, que incluyen el origen de información de camino, una secuencia de segmentos de camino de los sistema autónomo, e información de siguiente salto.

Cuando un router BGP recibe actualizaciones de sistemas autónomos múltiples que describen caminos diferentes al mismo destino, el router debe elegir el mejor camino solo para alcanzar aquel destino. Después de que el mejor camino es elegido, BGP propaga el mejor camino a sus vecinos. La decisión está basada en el valor de atributos

Marcos Huerta S.

163


en la actualización (como siguiente salto, pesos administrativos, preferencia local, el origen de la ruta, y longitud de camino) y otros factores BGP-configurables.

Protocolos de Enrutamiento y el Modelo de Diseño Jerárquico Como hablado en El capítulo 5, las redes grandes son diseñadas usando un acercamiento modular, jerárquico. Tal acercamiento es el modelo de diseño jerárquico de tres capas, que tiene una capa principal que es optimizada para disponibilidad e performance, una capa de distribución que pone en práctica políticas, y una capa de acceso que conecta a usuarios. Las tres siguientes secciones hablan de protocolos de enrutamiento para las tres capas del modelo.

Protocolos de Enrutamiento para la Capa Core La capa core debería incorporar enlaces redundantes y carga compartida entre caminos de costo igual. Esto debería proporcionar inmediata respuesta en un evento de falla de enlace y adaptarse muy rápidamente para el cambio. El enrutamiento de protocolos que encuentran estas necesidades incluye EIGRP, OSPF, y IS - IS. La decisión de usar EIGRP, OSPF, o IS - IS debería estar basado en la topología subyacente, el diseño de direccionamiento IP, preferencias de vendedor, y otros objetivos comerciales y técnicos.

El OSPF impone un diseño jerárquico estricto. Las áreas de OSPF deben trazar un plan al mapa al direccionamiento IP, que puede ser difícil de conseguir. EIGRP y IS - IS son más flexibles en cuanto a la estructura jerárquica e al diseño de direccionamiento IP. EIGRP es un protocolo patentado Cisco, sin embargo Aunque Cisco lo haya licenciado a unos vendedores, si los productos de otros vendedores deben ser usados en la realización del diseño de red, entonces EIGRP no podría ser una solución buena. O bien, EIGRP puede ser usado en el core con la redistribución a otro protocolo de enrutamiento en la capa de distribución.

El protocolo de enrutamiento RIP no es recomendado para core. Su respuesta para cambiarse es lenta, que puede causar la conectividad interrumpida.

Protocolos de Enrutamiento para la Capa de Distribución La capa de distribución representa el punto de conexión entre capas de acceso y el core. El protocolo de enrutamiento usados en la capa de distribución incluye RIPv2, EIGRP, OSPF, IS - IS, y ODR. La capa de distribución a menudo tiene el trabajo de redistribución entre el protocolo de enrutamiento usados en la capa core y aquellos usados en la capa de acceso.

Marcos Huerta S.

164


Protocolos de Enrutamiento para la Capa de Acceso La capa de acceso proporciona el acceso para conectarse a los recursos de la red para usuarios locales y remotos. Como con la distribución y capas core, la topología subyacente, el diseño de direccionamiento IP, y preferencias de vendedor conduce la opción de protocolo de enrutamiento. El equipamiento de capa de acceso puede ser menos poderoso que distribución y core, en cuanto al poder de procesamiento y memoria, que influye en la opción de protocolo de enrutamiento.

El protocolo de enrutamiento que deberían ser usados en la capa de acceso incluye RIPv2, OSPF, EIGRP, y ODR. El uso del enrutamiento estático es también una posibilidad. IS - IS no es a menudo apropiado para la capa de acceso porque esto exige más conocimiento para configurar y también no es esta bien para redes dialup. Las limitaciones de usar OSPF como una capa de acceso el protocolo de enrutamiento están relacionadas con su alta memoria y requerimientos de poder de procesamiento y requerimientos de diseño jerárquicos estrictos. La alta memoria y los requerimientos de poder de procesamiento de OSPF pueden ser evitados con el uso de sumarización y planificación de área cuidadosa, sin embargo.

Resumen Este capítulo proporcionó la información para ayudarle a seleccionar los correctos protocolos de enrutamiento para el diseño de su red al cliente. El capítulo cubrió escalabilidad y características de performance de los protocolos y habló de como rápidamente los protocolos pueden adaptarse a cambios.

Decidiendo el correcto protocolos para su cliente le ayudarán a seleccionar el mejor producto de switch y router para el cliente. Por ejemplo, si usted ha decidido que el diseño debe soportar un protocolo de enrutamiento que puede convergir dentro de unos segundos en unas redes grandes, usted no recomendará probablemente a un router que corra únicamente con RIP.

Este capítulo comenzó con una discusión genérica sobre la fabricación de decisión a ayudarle a desarrollar un proceso sistemático para seleccionar soluciones de diseño de red. Una discusión de tender un puente y cambiar protocolos siguió, que cubrió la conmutación que tiende un puente, de múltiples capas transparente, realces para STP, y protocolos VLAN. Una sección en el protocolos de enrutamiento siguió la sección de conmutación.

Marcos Huerta S.

165


Parte 8. Desarrollando Estrategias de seguridad de red El desarrollo de estrategias de seguridad que pueden proteger todas las partes de una red complicada teniendo un efecto limitado en la facilidad de uso e interpretación es una de las tareas más importantes y difíciles relacionadas para conectar diseño de red. El diseño de seguridad es desafiado por la complejidad y la naturaleza porosa de redes modernas que incluyen a servidores públicos para el comercio electrónico, extranet conexiones para socios de negocio, y servicios de acceso remoto para usuarios que alcanzan la red de casa, sitios de cliente, cuartos del hotel, cafeterías de Internet, etcétera. Para ayudarle a manejar las dificultades inherentes en el diseño de la seguridad de red para redes complejas, este capítulo enseña un acercamiento sistemático, top down que se concentra en planificación y desarrollo de política antes de la selección de productos de seguridad.

El objetivo de este capítulo es ayudarle a trabajar con sus clientes el diseño de red en el desarrollo de estrategias de seguridad eficaces, y ayudarle a seleccionar las técnicas correctas para poner en práctica las estrategias. El capítulo describe los pasos para desarrollar una estrategia de seguridad y cubre algunos principios de seguridad básicos. El capítulo presenta un acercamiento modular al diseño de seguridad que le dejará aplicar soluciones acodadas que protegen una red desde muchos puntos de vista. Las secciones finales describen métodos para asegurar los componentes de una red de empresa típica que son la más que estan en peligro, incluso coinexiones de Internet, redes de acceso remoto, y red de servicios de usuario, y redes inalámbricas.

La seguridad debería ser considerada durante muchos pasos del proceso de diseño de red top down. Este no es el único capítulo que cubre la seguridad. El capítulo 2, "Analizando Objetivos Técnicos y Restricciones," activos de red hablados que se identifican, analizando riesgos a la seguridad, y desarrollando requerimientos de seguridad. El capítulo 5, "Diseñando una Topología de Red," topologías de red seguras cubiertas. Este capítulo se concentra en estrategias de seguridad y mecanismos.

Diseño de Seguridad de la Red Después de desarrollar los pasos del set estructurado

y poniendo en práctica la

seguridad de red le ayudará a dirigirse a las preocupaciones variadas que juegan una parte en el diseño de seguridad. Muchas estrategias de seguridad han sido desarrolladas de un modo desordenado y han dejado de asegurar realmente activos y encontrar los objetivos primarios de un cliente para la seguridad. La demolición del proceso del diseño de seguridad en los pasos siguientes le ayudará con eficacia a planear y ejecutar una estrategia de seguridad: 1. Identifique activos de red. 2. Analice riesgos a la seguridad.

Marcos Huerta S.

166


3. Analice los requerimientos de seguridad y restricciones. 4. Desarrolle un plan de seguridad. 5. Defina una política de seguridad. 6. Desarrolle procedimientos para aplicar políticas de seguridad. 7. Desarrolle una estrategia de realización técnica. 8. Consiga la compra - desde usuarios, gerentes, y personal técnico. 9. Entrene a usuarios, gerentes, y personal técnico. 10. Ponga en práctica la estrategia técnica y procedimientos de seguridad. 11. Pruebe la seguridad y actualícelo si algún problema es encontrado. 12. Mantenga la seguridad programando auditorías independientes periódicas, leyendo los logs de auditoría, respondiendo a incidentes, leyendo literatura corriente y alarmas de agencia, siguiendo probando y entrenarse, y actualizando el plan de seguridad y política.

La seguridad de red debería ser un proceso perpetuo. Los riesgos se cambian con el tiempo y la seguridad también . Los expertos de seguridad de Cisco usan la rueda de seguridad de término para ilustrar aquella realización, escucha, pruebas, y el mejoramiento de la seguridad es un proceso interminable. Muchos ingenieros de seguridad agotados por tanto trabajo podrían estar relacionados con el concepto de rueda. Continuamente la actualización de mecanismos de seguridad para mantenerse al corriente de los últimos ataques puede hacer a veces una sensación de administrador un poco como un hámster en una rueda de formación.

La Identificación de Activos y Riesgos de Red La parte 2 se ha hablado de los objetivos de un cliente para seguridad de red. Se ha hablado en La parte 2, el análisis de objetivos implica identificar activos de red y el riesgo que aquellos activos podrían ser saboteados o inapropiadamente tenidos acceso. Esto también implica analizar las consecuencias de riesgos.

Los activos de red pueden incluir a hosts de red (incluso sistemas operativos de los hosts, aplicaciones, y datos), dispositivos de funcionamiento entre redes (como routers e switches), y conectar a la red datos que cruzan la red. Menos obvio, pero todavía muy importante, los activos incluyen propiedad intelectual, secretos de fabricación, y reputación de una compañía.

Los riesgos pueden extenderse de intrusos hostiles a usuarios inexpertos que descargan aplicaciones de Internet que tienen virus. Los intrusos hostiles pueden robar datos, cambiar datos, y hacer que el servicio sea negado a usuarios legítimos. (Desmentido de servicio los ataques se han hecho cada vez más comunes en los pocos

Marcos Huerta S.

167


años pasados.) Ver La parte 2 para más detalles contra análisis de riesgo y reunión de requerimientos.

Análisis de Restricciones de Seguridad Según RFC 2196, "la Guía de Sitios de Seguridad:" Un viejo truismo en la seguridad es que el costo de protección usted mismo contra una amenaza debería ser menos que el costo de recuperación si la amenaza fuera golpearle. El costo en este contexto debería ser recordado para incluir pérdidas expresadas en verdadero dinero, reputación, honradez, y otras medidas menos obvias.

Como es el caso con la mayoría de los requerimientos de tecnicas de diseño, consiguiendo medios de objetivos de seguridad que hacen restricciones. Las restricciones deben ser hechas entre objetivos de seguridad y objetivos para accesibilidad financiera, utilidad, performance, y disponibilidad. También, la seguridad añade hasta un total del trabajo de dirección porque la entrada al sistema de usuario IDs, contraseñas, y logs de auditoría debe ser mantenida.

La seguridad también afecta la performance de red. Las caracteristicas de seguridad como filtros de paquete y codificación de datos consumen el poder de CPU y la memoria en hosts, routers, y servidores. La codificación puede usar hasta un maximo del 15 por ciento del poder de CPU disponible en un router o servidor. La codificación puede ser puesta en práctica en dispositivos dedicados en vez de routers compartidos o servidores, pero hay todavía un efecto en la performance de red debido a la tardanza que experimenta el paquete mientras ellos están siendo codificados o descifrados.

Otra restricción es que la seguridad puede reducir la redundancia de red. Si todo el tráfico debe pasar por un dispositivo de codificación, por ejemplo, el dispositivo empieza en un simple punto de falla

. Este lo hace con fuerza para encontrar objetivos de

disponibilidad.

La seguridad también puede hacer más difícil de ofrecer el equilibrio de carga. Algunos mecanismos de seguridad requieren que el tráfico tome siempre el mismo camino de modo que los mecanismos de seguridad puedan ser aplicados uniformemente. Por ejemplo, un mecanismo que aleatoriza números de secuencia TCP (de modo que los hackeres no puedan adivinar los números) no trabajará si algunos segmentos de TCP para una sesión toman un camino que evita la función que aleatoriza debida de cargar el equilibrio.

Marcos Huerta S.

168


El desarrollo de un Plan de Seguridad Uno de los primeros pasos en el diseño de seguridad es desarrollar un plan de seguridad. Un plan de seguridad es un documento de alto nivel que propone lo que una organización va a hacer para encontrar requerimientos de seguridad. El plan especifica el tiempo, la gente, y otros recursos que se requerirá para desarrollar una política de seguridad y conseguir la realización técnica de la política. Como diseñador de red, usted puede ayudar a su cliente a desarrollar un plan que es práctico y pertinente. El plan debería estar basado en los objetivos del cliente y el análisis de activos de red y riesgos.

Un plan de seguridad debería referirse a la topología de red e incluir una lista de servicios de red que serán proporcionados (por ejemplo, FTP, web, correo electrónico, etcétera). Esta lista debería especificar quién proporciona los servicios, quién tiene el acceso a los servicios, como el acceso es proporcionado, y quién administra los servicios.

Como diseñador de red, usted puede ayudar al cliente a evaluar qué servicios son definitivamente necesarios, basados en los objetivos comerciales y técnicos del cliente. A veces los nuevos servicios son añadidos innecesariamente, simplemente porque ellos son la última tendencia. La adición de servicios podría requerir que nuevos filtros de paquete en routers y firewall protegieran los servicios, o procesos de autenticación de usuario adicionales para limitar el acceso con los servicios, añadiendo la complejidad a la estrategia de seguridad. Las estrategias de seguridad demasiado complejas deberían ser evitadas porque ellos pueden ser contraproducentes. Las estrategias de seguridad complicadas son difíciles de poner en práctica correctamente sin introducir agujeros de seguridad inesperados.

Uno de los aspectos más importantes del plan de seguridad es una especificación de la gente que debe estar implicada en la realización de la seguridad de red: Ø

¿ Se contrato especialistas de administradores de seguridad?

Ø

¿Cómo estarán implicados los usuarios finales y sus gerentes?

Ø

¿Cómo van los usuarios finales, gerentes, y personal técnico ser entrenados en políticas de seguridad y procedimientos?

Ya que una seguridad planean ser útiles, esto tiene que tener el apoyo de todos los niveles de empleados dentro de la organización. Es sobre todo importante que la dirección corporativa totalmente apoye el plan de seguridad. El personal técnico en oficina central y sitios remotos debería compactarse en el plan, como deben los usuarios finales.

Marcos Huerta S.

169


El desarrollo de una Política de Seguridad Según RFC 2196, "la Guía de Sitios de Seguridad:" Una política de seguridad es una declaración formal de las reglas por cual la gente a quien dan el acceso a la tecnología de una organización y los activos de información deben soportar.

Una política de seguridad informa a usuarios, gerentes, y personal técnico de sus obligaciones para proteger tecnología y activos de información. La política debería especificar los mecanismos por los cuales estas obligaciones pueden ser encontradas. Como era el caso con el plan de seguridad, la política de seguridad debería tener la atención - en los empleados, gerentes, ejecutivos, y personal técnico.

El desarrollo de una política de seguridad es el trabajo de administradores de red y seguridad. Los administradores son introducidos de gerentes, usuarios, diseñadores de red e ingenieros, y posiblemente asesor legal. Como un diseñador de red, usted debería trabajar estrechamente con los administradores de seguridad para entender como las políticas podrían afectar el diseño de red.

Después de que una política de seguridad ha sido desarrollada, con el compromiso de usuarios, personal, y dirección, debería ser explicado a todos por la dirección superior. Muchas empresas requieren que el personal firme una declaración que indica que ellos han leído, han entendido, y han consentido en cumplir con una política.

Una política de seguridad es un documento vivo. Como las organizaciones constantemente se cambian, las políticas de seguridad deberían ser con regularidad actualizadas para reflejar nuevas direcciones comerciales y cambios tecnológicos. Los riesgos se cambian con el tiempo también y afectan la política de seguridad.

Componentes de una Política de Seguridad En general, una política debería incluir al menos los artículos siguientes: Ø

Una política de acceso que define derechos de acceso y privilegios. La política de acceso debería proporcionar pautas para conectar redes externas, conectando dispositivos a una red, y añadiendo el nuevo software a sistemas. Una política de acceso también podría dirigirse como los datos son clasificados (por ejemplo, secreto confidencial, interno, y superior.)

Ø

Una política de responsabilidad que define las responsabilidades de usuarios, personal de operaciones, y dirección. La política de responsabilidad debería especificar una capacidad de auditoría, y proporcionar el incidente que maneja pautas que especifican que hacer y quien ponerse en contacto si una intrusión posible es descubierta.

Marcos Huerta S.

170


Ø

Una política de autenticación que establece la confianza por una política de contraseña eficaz, y establece pautas para la autenticación de posición remota.

Ø

Una política de intimidad que define expectativas razonables de la intimidad en cuanto a la escucha de correo electrónico, el registro de pulsaciones, y acceso a los archivos de los usuarios.

Ø

Las pautas adquisitivas de la tecnología de computadora que especifican las exigencias para adquisición, configuración, y revisión de sistemas de computadora y redes para la conformidad con la política.

Desarrollo de Procedimientos de Seguridad Los procedimientos de seguridad ponen en práctica políticas de seguridad. Los procedimientos definen configuración, entrada al sistema, auditoría, y procesos de mantenimiento. Los procedimientos de seguridad deberían ser escritos para usuarios finales, administradores de red, y administradores de seguridad. Los procedimientos de seguridad deberían especificar como manejar incidentes (es decir que hacer y quien ponerse en contacto si una intrusión es descubierta). Los procedimientos de seguridad pueden ser comunicados a usuarios y administradores en clases de formación conducidas por instructor y autodidácticas.

Mecanismos de Seguridad Esta sección describe algunos ingredientes típicos de diseños de red seguros. Usted puede seleccionar de estos ingredientes diseñando soluciones para desafíos de seguridad

comunes,

que

son

descritos

en

el

"Diseño

de

Seguridad

de

Modularización"sección más tarde en este parte.

Seguridad Física La seguridad física se refiere a la limitación del acceso a recursos de red claves guardando los recursos detrás de una puerta cerrada con llave. La seguridad física puede proteger una red de mal usos involuntarios del equipo de red por empleados inexpertos y contratistas. Esto también puede proteger la red de hackeres, competidores, y terroristas que andan en de la calle y cambian configuraciones de equipo.

Según el nivel de protección, la seguridad física puede proteger una red de terrorista y acontecimientos biohazard, incluso bombas, caídas radiactivas, etcétera. La seguridad física también puede proteger recursos de catástrofes como inundaciones, fuegos, tormentas, y terremotos.

Según su cliente el diseño de una red particular, la seguridad física debería ser instalada para proteger routers core, puntos de demarcación, tendido de cables, módems,

Marcos Huerta S.

171


servidores, hosts, almacenaje de backup, etcétera. Trabajo con su cliente durante las etapas tempranas del proyecto de diseño de red de asegurarse el equipo será colocado en cuartos de computadora que tienen acceso de llave de tarjeta y/o guardias de seguridad. Los cuartos de computadora también deberían ser equipados con suministros de energía uninterruptible, alarmas de incendios, mecanismos de disminución de fuego, y sistemas de retiro de agua. Para proteger el equipo de terremotos y vientos fuertes durante tormentas, el equipo debería ser instalado en rack que atan al suelo o pared.

Como la seguridad física es un requerimiento tan obvio, es fácil olvidar de planear para ello, pero nunca debería ser pasado por alto o considerado menos importante que otros mecanismos de seguridad. Como mencionado en el "Topologías de Diseño de Red Seguras"sección de La parte 5, usted debería comenzar a trabajar con su cliente el diseño a principios del proyecto del diseño de asegurarse que el equipo crítico será protegido. La planificación para la seguridad física debería comenzar durante las fases tempranas del proceso de diseño top down por si haya tiempos de criticos para construir o instalar mecanismos de seguridad.

Autenticación La autenticación se identifica quién solicita servicios de red. El termino autenticación por lo general se refiere a la autenticación de usuarios, pero esto puede referirse a la autenticación de dispositivos o procesos de software también. Por ejemplo, algunos protocolos de enrutamiento soportan la autenticación de ruta, por lo cual un router debe pasar algunos criterios antes de que otro router acepte sus actualizaciones de enrutamiento.

La mayor parte de políticas de seguridad declaran que para tener acceso a una red y sus servicios, un usuario debe entrar un login ID y password que estos seran autenticados por un servidor de seguridad. Para maximizar la seguridad, las contraseñas (dinámicas) one-time pueden ser usadas. Con sistemas de contraseña onetime, la contraseña de un usuario siempre se cambia. Este a menudo es llevado a cabo por una tarjeta de seguridad, también llamada un Smartcard. Una tarjeta de seguridad es un dispositivo físico de tamaño de una tarjeta de crédito. El usuario escribe a máquina un número de identificación personal (PIN) en la tarjeta. (El PIN es un nivel inicial de la seguridad que simplemente da el permiso al usuario de usar la tarjeta.) la tarjeta proporciona una contraseña one-time que es usada para tener acceso a la red corporativa durante un tiempo limitado. La contraseña es sincronizada con un servidor central de tarjeta de seguridad que reside en la red. Las tarjetas de seguridad son comúnmente usados por teleoperadores y usuarios móviles. Ellos no son por lo general usados para el acceso de LAN.

Marcos Huerta S.

172


La autenticación está tradicionalmente basada en una de tres pruebas: Ø

Algo el usuario sabe. Este por lo general implica el conocimiento de un secreto único que es compartido por los partidos de autenticación. A un usuario, este secreto aparece como una contraseña clásica, un número personal de identificación, o una llave criptográfica privada.

Ø

Algo el usuario tiene. Este por lo general implica la posesión física de un artículo que es único al usuario. Los ejemplos incluyen tarjetas de token de contraseña, tarjetas de seguridad, y llaves de hardware.

Ø

Algo el usuario es. Este implica la verificación de una característica física única del usuario, como una huella digital, modelo de retina, voz, o cara.

Muchos sistemas usan dos factores de autenticación, que requiere que un usuario tenga dos pruebas de la identidad. Un ejemplo es un sistema de control de acceso que requiere una tarjeta de seguridad y una contraseña. Con la autenticación de dos factores, un compromiso de un factor no conduce a un compromiso del sistema. Un atacante podría aprender una contraseña, pero la contraseña es inútil sin la tarjeta de seguridad. A la inversa, si la tarjeta de seguridad es robada, no puede ser usado sin la contraseña.

Autorización Mientras que la autenticación controla quién puede tener acceso a recursos de red, la autorización dice lo que ellos pueden hacer después de que ellos han tenido acceso a los recursos. La autorización concede privilegios a procesos y usuarios. La autorización deja una partes de control de administrador de seguridad de una red (por ejemplo, directorios y archivos en servidores).

La autorización varía de usuario a usuario, en parte según departamento de un usuario o función de trabajo. Por ejemplo, una política podría declarar que los empleados de Recursos Humanos solo deberían ver archivos de sueldo para la gente que ellos no manejan.

Los expertos de seguridad recomiendan el uso del principio de menor parte de privilegio en la realización de la autorización. Este principio está basado en la idea que deberían dar a cada usuario sólo los derechos minimos necesarios de realizar una cierta tarea. Por lo tanto, un mecanismo de autorización debería dar a un usuario sólo los permisos de acceso mínimos que son necesarios. Explícitamente el listado de las actividades autorizadas de cada usuario con respecto a cada recurso es difícil, entonces las

Marcos Huerta S.

173


técnicas son usadas para simplificar el proceso. Por ejemplo, un administrador de la red puede crear grupos de usuario para usuarios con los mismos privilegios.

Contabilizando (de Revisión) Para analizar con eficacia la seguridad de una red y responder a incidentes de seguridad, los procedimientos deberían ser establecidos para coleccionar datos de actividad de red. El recogimiento de datos es llamado contabilizando o revisando.

Para redes con políticas de seguridad estrictas, los datos de auditoría deberían incluir todas las tentativas de conseguir la autenticación y la autorización por cualquier persona. Es sobre todo importante registrar "anónimo" o acceso "de invitado" a servidores públicos. Los datos también deberían registrar todas las tentativas por usuarios para cambiar sus derechos de acceso.

Los datos collectados deberían incluir nombres de host y usuario para entrada al sistema y tentativas de procedimiento de logout, y previos y nuevos derechos para un cambio de derechos de acceso. Cada entrada en el log audit debería ser registrada.

El proceso de auditoría no debería guardar contraseñas. El recogimiento de contraseñas crea un potencial para una violación de seguridad si tienen acceso incorrectamente a los archivos de auditoría. (Ni las contraseñas correctas ni incorrectas deberían ser guardadas. Una contraseña incorrecta a menudo se diferencia de la contraseña válida por sólo un carácter solo o la transposición de carácteres.)

Una extensión adicional de la revisión es el concepto de la evaluación de seguridad. Con la evaluación de seguridad, la red es examinada desde dentro por profesionales, entrenados en las vulnerabilidades explotadas por invasores de red. La parte de cualquier política de seguridad y procedimiento de auditoría debería ser evaluaciones periódicas de las vulnerabilidades en una red. El resultado debería ser un plan específico para corregir carencias, que pueden ser tan simples como el reciclaje del personal.

Encriptación de Datos La encriptación es un proceso que rmueve datos para protegerlo de ser leído por alguien. Un dispositivo de encriptación encripta datos antes de colocarlo en una red. Un dispositivo de desencriptación descifra los datos antes de pasarlo a una aplicación. Un router, el servidor, el sistema final, o el dispositivo dedicado pueden actuar como el dispositivo de desciframiento o una encriptación. Los datos que son encriptados son llamados datos cifrados (o datos simplemente criptografiados). Los datos que no son encriptados son llamados el texto sin formato o el texto claro.

Marcos Huerta S.

174


La encriptación es una caracteristica de seguridad útil para proporcionar la confidencialidad de datos. Esto también puede ser usado para identificar al remitente de datos. Aunque la autenticación y la autorización también debieran proteger la confidencialidad de datos e identificar a remitentes, la codificación es una caracteristica de seguridad bueno para poner en práctica por si los otros tipos de la seguridad fallen.

Hay restricciones de performance asociadas con la encriptación, sin embargo, como mencionado en "la sección" de Restricciones de Seguridad de Análisis. La encriptación debería ser usada cuando un cliente ha analizado los riesgos de seguridad y ha identificado consecuencias severas si los datos no son confidenciales y la identidad del remitentes de datos no es garantizada. En redes internas y redes que usan el Internet simplemente para browsing de web, correo electrónico, y transferencia de archivo, la encriptación no es por lo general necesaria. Para organizaciones que conectan sitios privados vía el Internet, usando redes privada virtual (VPN), se recomienda que la encriptación proteja la confidencialidad de los datos de la organización.

La encriptación tiene dos partes: Ø

Un algoritmo de encriptación es un juego de instrucciones para revolver y no revolver datos.

Ø

Una llave de encriptación es un código usado por un algoritmo para revolver y no revolver datos.

Los niños a veces juegan con la encriptación usando un algoritmo simple como "el hallazgo la letra en la fila superior y usan la letra en la fila de fondo en cambio," y una llave que podría parecer algo como la tabla nro. 17 siguiente:

Tabla Nro.17

En este ejemplo, LISA es encriptada como WTFI. La llave muestra sólo mayúsculas, pero hay muchas otras posibilidades también, incluso minúsculas, dígitos, etcétera. La mayor parte de algoritmos son más complejos que el que en el ejemplo de niños para evitar necesidad mantener una llave que incluye un valor para cada carácter posible.

El objetivo de encriptar es que aun si el algoritmo es conocido, sin la llave apropiada, un intruso no puede interpretar el mensaje. Este tipo de llave es llamado una llave secreta. Cuando tanto el remitente como receptor usan la misma llave secreta, es llamado una llave simétrica. El Estándar de Encriptación de Datos (DES) es el mejor ejemplo

Marcos Huerta S.

175


conocido de un sistema clave simétrico. La encriptación de DES está disponible para la mayor parte de routers y muchas realizaciones de servidor.

Aunque las llaves secretas sean razonablemente simples de poner en práctica entre dos dispositivos, como el número de dispositivos aumentan, el número de llaves secretas aumentan, que pueden ser difíciles de poder manejra. Por ejemplo, una sesión entre Estación A y Estación B usa una llave diferente que una sesión entre Estación A y Estación C, o una sesión entre Estación B y Estación C, etcétera. Las llaves asimétricas pueden solucionar este problema.

Encriptación de Clave Pública/privada La encriptación de clave pública/privada es el mejor ejemplo conocido de un sistema clave asimétrico. Con sistemas claves públicos/privados, cada estación segura en una red tiene una llave pública que es abiertamente publicada o fácilmente determinada. Todos los dispositivos pueden usar la llave pública de una estación para encriptar datos para enviar a la estación.

La estación de recepción descifra los datos usando su propia llave privada. Como ningún otro dispositivo tiene la llave privada de la estación, ningún otro dispositivo puede descifrar los datos, entonces la confidencialidad de datos es mantenida. (Los matemáticos y los informáticos han escrito programas de computadora que identifican números especiales para usar para las llaves de modo que el mismo algoritmo pueda ser usado tanto por el remitente como por receptor, aunque las llaves diferentes sean usadas.) la Figura Nro. 32 muestra un sistema clave público/privado para la confidencialidad de datos.

Figura Nro.32. Sistema Clave Público/privado para Contrato de un seguro de Confidencialidad de Datos

Los

sistemas

claves

públicos/privados

proporcionan

tanto

caracteristicas

de

autenticación como confidencialidad. Usando llaves asimétricas, un recipiente puede verificar que un documento realmente vino del usuario o host del cual parece venir. Por ejemplo, suponga que usted envía sus declaraciones de renta a la Hacienda Pública

Marcos Huerta S.

176


(IRS). El IRS tiene que saber que las vueltas vinieron de usted y no de un tercero hostil que quiere hacerlo parecer a usted deben más que usted.

Usted puede codificar su documento o una parte de su documento con su llave privada, que resulta en lo que es conocido como una firma digital. El IRS puede descifrar el documento, usando su llave pública, como mostrado en la Figura Nro.33. Si el desciframiento es acertado, entonces el documento vino de usted porque nadie más debería tener su llave privada.

Figure Nro.33. Public/Private Key System for Sending a Digital Signature

La caracteristica de firma digital de llaves asimétricas puede ser usado junto con la caracteristica para la confidencialidad de datos. Después de codificar su documento con su llave privada, usted también puede codificar el documento con la llave pública del IRS. El IRS descifra el documento dos veces. Si el resultado es datos de texto sin formato, el IRS sabe que el documento vino de usted y que usted pensó para el documento ir al IRS y no alguien más.

Algunos ejemplos de sistemas claves asimétricos incluyen el Rivest, Shamir, y Adleman (RSA) estándar, el algoritmo clave público Diffie-Hellman, y el Estándar de Firma Digital (DSS). El Cisco Systems, Inc usa el estándar DSS para certificar routers de puntos durante el sistema de una sesión criptografiada. Los routers de punto usan el algoritmo Diffie-Hellman para enviar la información en una llave secreta para usar y codificar datos. Los datos actuales son codificados usando el algoritmo DES y la llave secreta.

Filtros de Paquete Los filtros de paquete pueden ser establecidos en routers, firewall, y servidores para aceptar o negar paquetes de direcciones particulares o servicios. El paquete filtra autenticación de aumento y mecanismos de autorización. Ellos ayudan a proteger recursos de red de uso no autorizado, robo, destrucción, y desmentido de servicio (DoS) ataques.

Una política de seguridad debería declarar si los filtros de paquete ponen en práctica un o las otras de las políticas siguientes:

Marcos Huerta S.

177


Ø

Niegue tipos específicos de paquetes y acepte todo lo demás

Ø

Acepte tipos específicos de paquetes y niegue todo lo demás

La primera política requiere un entendimiento cuidadoso de amenazas de seguridad específicas y puede ser difícil de poner en práctica. La segunda política es más fácil para poner en práctica y más seguro porque el administrador de seguridad no tiene que predecir futuros ataques para los cuales los paquetes deberían ser negados. La segunda política es también más fácil para probar porque hay un juego finito de usos aceptados de la red. Hacer un trabajo bueno que pone en práctica la segunda política requiere un entendimiento bueno de exigencias de red. El diseñador de red debería trabajar con el administrador de seguridad para determinar que tipos de paquetes deberían ser aceptados.

Cisco pone en práctica la segunda política en sus filtros de paquete, que Cisco llama listas de control de acceso (ACLs). Un ACL en un router o switch que dirige el Sistema Operativo de redes Cisco (IOS) que el Software siempre hace que un implícito niegue toda la declaración al final. Específico aceptan declaraciones son tratados antes de que los implícitos nieguen - toda la declaración. (La declaración es implícita porque el administrador realmente no tiene que entrar en ello, aunque esto sea una idea buena de entrar en ello para hacer el comportamiento de la lista más obvio.)

Los ACLs le dejan controlar si el tráfico de red es enviado o bloqueado en las interfaces en un router o switch. Las definiciones de ACL proporcionan criterios que son aplicados a paquetes que entran o salen de una interfaz. Los criterios típicos son la dirección de fuente de paquete, la dirección de destino de paquete, o el protocolo de capa superior en el paquete.

Como Cisco IOS Software prueba un paquete contra cada declaración de criterios en la lista hasta que uno sea encontrado, ACLs debería ser diseñado con cuidado para proporcionar una buena interpretación.

Estudiando el flujo de tráfico, usted puede diseñar la lista de modo que la mayor parte de paquetes emparejen las condiciones más tempranas. Menos condiciones de comprobar por paquete significan el mejor rendimiento. El consejo bueno para ACLs debe pedir la lista con la mayor parte de declaraciones generales encima y las declaraciones más específicas en el fondo, con la última declaración que es general, implícito niegan - toda la declaración.

Marcos Huerta S.

178


Firewalls Como dr ha hablado en la Parte 5, un firewall es un dispositivo que hace cumplir políticas de seguridad en el límite entre dos o más redes. Un firewall puede ser un router con ACLs, una caja de hardware dedicada, o software que corre en un ordenador personal o sistema UNIX. Los firewall son sobre todo importantes en el límite entre la red de empresa y el Internet.

Un firewall tiene un conjunto de reglas que especifican qué tráfico debería ser permitido o negado. Un firewall con filtro de paquete estático mira paquetes individuales y es optimizado para simplicidad de configuración y velocidad. Un firewall stateful puede rastrear sesiones de comunicación y más con inteligencia permitir o negar el tráfico. Por ejemplo, un firewall stateful puede recordar que un cliente protegido inició una petición para descargar datos de un servidor de Internet y permitir datos de regreso para aquella conexión. Un firewall stateful también puede trabajar con protocolos, como activo (modo de puerto) FTP, que requieren que el servidor abra también una conexión al cliente.

Otro tipo de firewall es un firewall por poderes. Los firewall por poderes son el tipo más avanzado del firewall sino también el menos común. Un firewall por poderes actúa como un intermediario entre hosts, interceptando unos o todo el tráfico de aplicación entre clientes locales y servidores exteriores. Los firewall por poderes examinan paquetes y soportan el rastreo de stateful de sesiones. Estos tipos de firewall pueden bloquear el tráfico malévolo así como el contenido que es juzgado inaceptable.

Sistemas de Detección de Intrusión Un sistema de detección de intrusión (IDS) descubre acontecimientos malévolos y notifica a un administrador, usando el correo electrónico, la paginación, o el registro del acontecimiento. El IDSs también puede funcionar estadístico y análisis de anomalía. Algún IDSs puede hacer un informe a una base de datos central que correlaciona la información de sensores múltiples para dar a un administrador una vista total de la seguridad de tiempo real de una red.

Algunos avances de los dispositivos IDS también pueden bloquear dinámicamente el tráfico añadiendo reglas a un firewall. (Esta caracteristica es algo peligroso y probablemente debería ser evitado porque los atacantes podrían comprometer el IDS y cambiar las reglas en el firewall para permitir su tráfico.)

Hay dos tipos de IDSs: reciba IDSs y conecte a la red IDSs. Un host IDS reside en un host individual y monitorea aquel host. IDS de red supervisa todo el tráfico de red que esto puede ver, mirando para firmas predefinidas de acontecimientos malévolos. IDS de red a menudo es colocado en una subred que está directamente relacionada con un

Marcos Huerta S.

179


firewall de modo que esto pueda supervisar el tráfico que ha sido permitido y busca la actividad sospechosa.

Diseño de Seguridad de Modularizada Los expertos de seguridad promueven la defensa de seguridad en principio de profundidad. Este principio declara que la seguridad de red debería ser multicapas con muchas técnicas diferentes usadas para proteger la red. Ningún mecanismo de seguridad puede ser garantizado para resistir cada ataque. Por lo tanto, cada mecanismo debería tener un mecanismo de reserva. Este es a veces llamado el acercamiento de cinturón-y-ligas. Tanto un cinturón como las ligas son usados para asegurar aquella permanencia de pantalón. Un ejemplo conectado a una red debe usar un firewall dedicado para limitar el acceso con recursos y un router que filtra paquete que añade otra línea de la defensa.

Como la parte de poner en práctica defensa de seguridad en profundidad, el diseño de seguridad debería ser modular. Métodos múltiples deberían ser diseñados y aplicados a partes diferentes de la red, si ello pueden ser la conexión a Internet, la infraestructura inalámbrica, o el componente de acceso remoto. Los Sistemas de Cisco proveen un acercamiento modular con su SAFE Blueprint. El SAFE Blueprint proporciona un diseño de seguridad de mejores prácticas y pautas de realización para cada módulo en el Modelo de Red de Compuesto de Empresa Cisco que fue descrito en La parte 5. Para más información en el SAFE Blueprint, refiérase a http://www.cisco.com/warp/public/779/largeent/issues/security/safe.html.

En general, la utilización de un acercamiento modular al diseño de seguridad es un modo bueno de ganar un entendimiento de los tipos de soluciones que deben ser seleccionadas para poner en práctica la defensa de seguridad en profundidad. Las siguientes secciones cubren la seguridad para los módulos siguientes o componentes de una red de empresa: Ø

Conexiones de Internet.

Ø

Acceso remoto y redes privadas virtuales (VPNs).

Ø

Servicios de red y dirección.

Ø

El servidor de granja y servicios de usuario.

Ø

Redes inalámbricas.

El desarrollo de estrategias de seguridad que pueden proteger todas las partes de una red complicada teniendo un efecto limitado en la facilidad de uso e performance es una de las tareas más importantes y difíciles relacionadas para conectar al diseño de red. El diseño de seguridad es desafiado por la complejidad y la naturaleza porosa de redes modernas que incluyen a servidores públicos para el comercio electrónico, extranet

Marcos Huerta S.

180


conexiones para socios de negocio, y servicios de acceso remoto para usuarios que alcanzan la red de casa, sitios de cliente, cuartos del hotel, cafeterías de Internet, etcétera. Para ayudarle a manejar las dificultades inherentes en el diseño de la seguridad de red para redes complejas, esta sección enseña un acercamiento sistemático, top down que se concentra en planificación y desarrollo de política antes de la selección de productos de seguridad.

El objetivo de esta sección es ayudarle a trabajar con sus clientes de diseño de red en el desarrollo de estrategias de seguridad eficaces, y ayudarle a seleccionar las técnicas correctas para poner en práctica las estrategias. Esta sección describe los pasos para desarrollar una estrategia de seguridad y cubre algunos principios de seguridad básicos.

La sección presenta un acercamiento modular al diseño de seguridad que le dejará aplicar soluciones acodadas que protegen una red desde muchos puntos de vista. Las secciones finales describen métodos para asegurar los componentes de una red de empresa típica que son más un peligro, incluso conexiones de Internet, redes de acceso remoto, servicios de usuario, y redes inalámbricas.

La seguridad debería ser considerada durante muchos pasos del proceso de diseño de red top dwon. Este no es la unica sección que cubre la seguridad. La parte 2, "Analizando Objetivos Técnicos y Restricciones," activos de red hablados que se identifican, analizando riesgos a la seguridad, y desarrollando requerimientos de seguridad. La sección 5, "Diseñando una Topología de Red," topologías de red seguras.

Asegurar Conexiones de Internet Las conexiones de Internet deberían ser aseguradas con un conjunto de mecanismos de seguridad que se superponen, incluso firewall, filtros de paquete, seguridad física, troncos de auditoría, autenticación, y autorización. Los routers de Internet deberían ser equipados con filtros de paquete para prevenir DoS y otros ataques. Estos filtros deberían ser sostenidos con filtros adicionales colocados en dispositivos de firewall. La conexión de Internet debería ser con cuidado supervisada.

La red y el host IDSs deberían supervisar subredes, routers, y servidores Accesibles a Internet para descubrir signos de ataque o actividad de red malévola e identificar violaciones acertadas en la red protegida.

Una regla buena para redes de empresa consiste en que la red debería tener salida bien definida y puntos de entrada. Una organización que tiene sólo una conexión de Internet puede manejar problemas de seguridad de Internet más fácilmente que una organización que tiene muchas conexiones de Internet. Algunas organizaciones muy

Marcos Huerta S.

181


grandes requieren más de una conexión de Internet para performance y motivos de despido, sin embargo. Este es fino mientras las conexiones son manejadas y supervisadas. Los departamentos o los usuarios que añaden conexiones de Internet sin la coordinación de ingenieros de red corporativos no deberían ser tolerados.

Un riesgo común asociado con la conexión de Internet es amenazas de reconocimiento del Internet, por lo cual un atacante intenta sondear la red y sus hosts para descubrir redes accesibles, hosts, y servicios que corren en hosts expuestos, y desarrollar un mapa. Para manejar el riesgo de tentativas de reconocimiento, los routers y los dispositivos de firewall de la primera línea deberían bloquear todas las conexiones entrantes, excepto aquellos necesarias para alcanzar servicios específicos de servidores públicos o completar una transacción comenzada por un cliente confiado. Los routers y los firewall también deberían bloquear paquetes típicamente usados para amenazas de reconocimiento, como sonidos metálicos.

Seleccionando la encaminamiento de protocolos para la unión de Internet y para gestores de tráfico que inyectan rutas de Internet en la red interior, usted debería seleccionar un protocolo que ofrece la autenticación de ruta como el Protocolo de Enrutamiento de Información (RIP) la versión 2, el Primero la Ruta libre mas Corta (OSPF), Protocolo de Enrutamiento de Gateway Interior Mejorado(EIGRP), o Protocolo de Entrada Fronterizo, la versión 4 (BGP4). Estático y encaminamiento por defecto es también una opción buena porque con estático y enrutamiento por defecto no hay ningunas actualizaciones de enrutamiento que podrían estar comprometidas.

Asegurando la conexión de Internet, la Traducción de Dirección de Red (NAT) puede ser usada para proteger el esquema de direccionamiento de la red interna. Como se ha hablado en la Parte 6, NAT esconde números de red internos desde fuera de redes. NAT traduce números de red internos cuando fuera del acceso es requerido

Asegurando Servidores Públicos La mayor parte de compañías tienen una necesidad de servidores públicos que son accesibles desde el Internet. Éstos incluyen el World Wide Web, Protocolo de Transferencia de Archivos (FTP), Sistema de Nombre de Dominio (DNS), correo electrónico, y servidores de e-comercio. Los servidores públicos deberían ser colocados en una zona de red desmilitarizada (DMZ) que es protegida de otras redes vía firewall. Se hablaron de redes de DMZ más detalladamente en la Parte5.

Proteger servidores públicos de ataques DoS, los administradores de servidor deberían usar sistemas operativos confiables y aplicaciones que han sido parchadas con la seguridad más reciente fija. La Adición del Interfaz de Gateway Común (CGI) u otros

Marcos Huerta S.

182


tipos de scripts para servidores debería ser hecha con gran cuidado. Los scripts deberían ser a fondo probadas para evitar una baja seguridad. Los servidores públicos deberían correr el software de firewall y ser configurados para la protección de DoS. Por ejemplo, el servidor debería ser configurado para limitar el número de conexiones que pueden ocurrir en un margen de tiempo particular. Los servidores también deberían dirigir el software que puede examinar el contenido llevado por protocolos de aplicación de modo que el software pueda explorar, y posiblemente eliminar, contenido peligroso como virus o código móvil. (El código móvil es el software que puede ser transmitido a través de una red y ejecutado en otro dispositivo.)

Si un cliente puede permitirse a dos servidores separados, los expertos de seguridad recomiendan que servicios de FTP no corran en el mismo servidor de servicios web. Los usuarios de FTP tienen más oportunidades de leer y posiblemente cambiar archivos que los usuarios de web. Un hacker podría usar el FTP para dañar las páginas Web de una compañía, así dañando la imagen de la compañía y posiblemente comprometiendo el comercio electrónico a base de web y otras aplicaciones. Los expertos de seguridad no recomiendan nunca por permitir el acceso de Internet al Protocolo de Transferencia de Archivos Trivial (TFTP) servidores, porque TFTP no ofrece ningunos caracteristica de autenticación.

Los servidores de correo electrónico han sido mucho tiempo una fuente para robos de intruso,

probablemente

porque

los

protocolos

de

correo

electrónico

y

las

implementaciones tienen alrededor mucho tiempo y los hackeres pueden entenderlos fácilmente estos. También, en su misma naturaleza, un servidor de correo electrónico debe permitir el acceso de forastero. Para asegurar servidores de correo electrónico, los administradores de red deberían quedarse informado en conocer los huecos y agujeros de seguridad suscribiéndose a una listas de direcciones dedicadas a la información de seguridad.

Los servidores DNS deberían ser controlados con cuidado y supervisados. La resolución de nombre a dirección es crítica a la operación de cualquier red. Un atacante que puede controlar con éxito o hacerse pasar por un servidor DNS puede causar estragos en una red. Los servidores de DNS deberían ser protegidos de ataques de seguridad por filtros de paquete en routers y versiones del software DNS que incorporan caracteristicas de seguridad.

Tradicionalmente, DNS no tenía ningunas capacidades de seguridad. En particular, no había ningún modo de verificar la información devuelta en una respuesta DNS a una pregunta. Un hacker podría secuestrar la pregunta y devolver una correlación de nombre a dirección falsificada. Las firmas digitales y otras caracteristicas de seguridad están

Marcos Huerta S.

183


siendo añadidos al protocolo para dirigirse a esta cuestión y otras preocupaciones de seguridad. Refiérase a RFC 2535, "Extensiones de Seguridad de Sistema de Nombre de Dominio," para más información.

Asegurando Acceso Remoto y Redes Privadas Virtuales Para soportar a usuarios móviles, muchas redes de empresa incluyen a servidores de acceso de dialup, acceso remoto VPN concentradores, y entradas sitio a sitio de VPN. Dialup y las conexiones VPN son transportados sobre redes públicas, como la Red Telefónica Conmutada (PSTN) y el Internet, así protegiendo estos componentes de escuchar a escondidas es importante. La identidad spoofing de clientes remotos o sitios es también posible, donde un atacante se hace pasar por un cliente legítimo y entra al sistema de la red. Este puede pasar si un atacante roba las credenciales legitimas de un usuario (como un dialup username y par de contraseña) o aprende las llaves de autenticación usadas en una conexión VPN.

Asegurando Redes Privadas Virtuales Las organizaciones que usan VPNs para conectarse a sitios privados y usuarios finales vía una red pública como el Internet deberían usar NAT, firewall, fuertes autenticación, y encriptación de datos. Los sistemas operativos de cliente que se conectan vía el VPN deberían usar el firewall personal y el software de protección de virus. Es importante proteger contra el compromiso de un cliente o sitio remoto que permite que un atacante ataque con éxito la red de empresa sobre el VPN. Un ejemplo es un cliente VPN que ha estado comprometido por un Caballo de Troya que convierte el sistema de cliente en un relevo. Tal ataque podría significar que cuando el cliente está conectado con la red de la empresa vía un acceso remoto de Internet VPN, el atacante puede conectarse al cliente sobre el Internet, y luego el cliente se conecta a la red de la empresa protegida.

En topologías VPN, viajan los datos privados a través de una red pública, entonces la encriptación es obligatoria. La solución más común para la encriptación es usar el Protocolo de Seguridad IP (IPSec), que es un Internet Engineering Task Force (IETF) estándar que proporciona la confidencialidad de datos, la integridad de datos, y la autenticación entre puntos participantes en la capa IP. El IPSec proporciona un camino seguro entre usuarios remotos y un VPN concentrador, y entre sitios remotos y un gateway de sitio a sitio VPN.

Numerosos RFCs tratan con IPSec, así como muchos esbozos de Internet. Para aprender IPSec mejor, las principales RFCs que usted debería leer son las que sigue: Ø

RFC 2401, "Arquitectura de Seguridad para el Protocolo de Internet".

Ø

RFC 2402, "Cabecera de Autenticación IP".

Ø

RFC 2406, "IP Encapsulación de Carga útil de Seguridad (ESP)".

Marcos Huerta S.

184


Ø

RFC 2408, "Asociación de Seguridad de Internet y Protocolo de Dirección Clave (ISAKMP)".

El IPSec permite a un sistema seleccionar protocolos de seguridad y algoritmos, y establecer llaves criptográficas. El Cambio de Llave de Internet (IKE) protocolo proporciona la autenticación de puntos de IPSec. Esto también negocia llaves IPSec y asociaciones de seguridad. IKE usa las tecnologías siguientes: Ø

DES. Codifica datos de paquete.

Ø

Diffie-Hellman. Establece un compartido, secreto, la llave de sesión.

Ø

Resumen de Mensaje 5 (MD5). Un algoritmo de autenticación que certifica datos del paquete.

Ø

Algoritmo de Hash Seguro (SHA). Un algoritmo de autenticación que certifica datos de paquete.

Ø

El RSA encripta nonces. Proporciona el rechazo.

Ø

Firmas de RSA. Proporciona no rechazo

Asegurando Servicios de Red y Dirección de Red Para proteger servicios de red internas, es importante proteger dispositivos de funcionamiento entre redes internas, como routers e switches. Usted debería tratar cada dispositivo de red como un host de valor alto y endurecer (fuerza) ello contra intrusiones posibles. Este implica prácticas comunes como el correr sólo los servicios necesarios mínimos y establecimiento de la confianza sólo con compañeros auténticos. Por ejemplo, un router no debería aceptar actualizaciones de enrutamiento de un router que no ha sido certificado. Los protocolos de enrutamiento que soportar la autenticación deberían ser seleccionados, incluso la versión 2 de RIP, OSPF, EIGRP, y BGP4. Estático y rutas por defecto son también una opción buena porque ellos eliminan la necesidad de aceptar actualizaciones de enrutamiento.

Los login IDs al sistema y las contraseñas deberían ser requeridos para tener acceso a routers e switches, si el usuario tiene acceso al dispositivo vía un puerto de consola o vía la red. Una contraseña de primer nivel puede ser usada para administradores que simplemente tienen que comprobar el estado de los dispositivos. Una contraseña del segundo nivel debería ser usada para administradores que tienen el permiso de ver o cambiar configuraciones. Evite usar un protocolo no seguro como Telnet para tener acceso a routers e switches sobre una red. Una mejor opción es la Shell Segura (SSH).

Cuando los administradores (o hackeres que se hacen pasar por administradores) se conectan a un router o switch, ellos no deberían ver el típico conectar mensaje, que a menudo dice que algo simple como "Bienvenidos a este router." En cambio, un router o el switch deberían mostrar advertencias sobre el uso autorizado y la monitorear de toda

Marcos Huerta S.

185


la actividad en el dispositivo. Muchos expertos de seguridad recomiendan por conseguir la ayuda de un abogado escribiendo el conectar mensaje.

Si el acceso de módem a los puertos de consola de dispositivos de funcionamiento entre redes es permitido, los módems deben ser asegurados como la marcación interna estándar de módems de usuario, y los números de teléfono deberían ser no inscritos y sin relaciones al número (s) principal de la organización. Los números de teléfono también deberían ser cambiados cuando hay volumen de ventas de personal.

Para clientes con numerosos routers e switches, un protocolo como el Terminal de Acceso Sistema de Control de Acceso (TACACS) puede ser usado para manejar números grandes del routers y cambiar al usuario IDs y contraseñas en una base de datos centralizada. El TACACS también ofrece caracteristicas de revisión, que pueden ser provechosos cuando un administrador de red inexperto trata de evitar la responsabilidad de un misconfiguration que condujo a un incidente de seguridad.

Para proteger contra el misconfiguration de dispositivos por hackeres (o administradores de red inexpertos), usted puede hacer cumplir la autorización en órdenes de configuración específicas. El TACACS y otros métodos de autorización pueden ser configurados para permitir a administradores sólo específicos entrar a los comandos arriesgados, como comandos de cambiar direcciones de IP o listas de control de acceso. El uso de un proceso de control de cambio, centralizado también es recomendado.

La limitación del uso del Protocolo de Dirección de Red Simple (SNMP) debería ser considerada en redes de empresa para las cuales los objetivos de seguridad pesan más que objetivos de manejabilidad. Una de las cuestiones principales con SNMP es el conjunto de operaciónes , que permite que una estación remota cambie datos de configuración y la dirección. Si SNMPv3 es usado, este no es como una preocupación grande, porque SNMPv3 soporta la autenticación para el uso con el conjunto

de

operaciónes y otras operaciones SNMP.

Los sistemas de dirección de red deberían ser sobre todo protegidos porque ellos reciben sumamente datos confidenciales sobre red y configuración de dispositivo de seguridad. Además, los sistemas de dirección de red están a veces relacionados con otros dispositivos sobre una red de dirección (de cinta) separada, que, sin el diseño cuidadoso, podría proporcionar un camino alrededor de mecanismos de seguridad como firewalls.

Marcos Huerta S.

186


Para minimizar el riesgo, los sistemas de dirección de red deberían ser colocados en su propio DMZ detrás de un firewall. Ellos deberían correr un sistema operativo endurecido que ha sido parchado con la última seguridad fija. Todos los servicios innecesarios deberían ser desabilitados.

Como es el caso con routers e switches, los sistemas de dirección de red deben ser protegidos de la personificación de administradores, donde un atacante roba las credenciales (usernames o contraseñas) de un administrador. Para manejar el riesgo de la personificación de administrador,

provea

al administrador mecanismos de

autenticación fuertes. Un ejemplo bueno es un sistema de contraseña de dos factores, one-time basado en tarjetas de seguridad.

Asegurando a Servidor de Granja El servidor de granja archivo de host, print, base de datos, y servidores de aplicación dentro de redes de campus y sucursales. Estos servidores a menudo contienen la información más sensible de una empresa, entonces ellos deben ser protegidos. Como servidores tiene acceso un número grande de usuarios, la performance de red es por lo general una cuestión crítica, que puede limitar la opción de mecanismos de protección. Sin embargo, los métodos deberían ser desplegados para proteger contra el compromiso de aplicaciones expuestas y acceso no autorizado a datos. La red y el host IDSs deberían ser desplegados para supervisar subredes y servidores individuales para descubrir signos de ataques y confirmar violaciones acertadas.

Cuando los servidores de una granja de servidor están comprometidos, los atacantes pueden usar a aquellos servidores para atacar a otros servidores. Para manejar este riesgo, configure filtros de red que limitan la conectividad del servidor. En muchos casos, un servidor no tiene ninguna necesidad de iniciar conexiones. Los establecimientos de conexión generalmente vienen del cliente. Hay numerosas excepciones, sin embargo, que puede ser programado en filtros. Por ejemplo, con activo (modo de puerto) FTP, el servidor inicia una conexión. También varias direcciónes de red, el nombramiento, la posición de recurso, y la autenticación y los protocolos de autorización pueden requerir que el servidor inicie una conexión. Como la parte de la red top down diseñan el proceso, usted debería haber analizado el presente de protocolos en posiciones de granja de servidor. (Ver Parte 3, "Caracterizando las redes Existentes" y Parte 4, "Caracterizando el Tráfico de Red" para más información.) los datos que usted juntó pueden ayudarle a determinar qué protocolos un servidor tendrá que permitir.

Maximizar la seguridad, tanto servidor como software de usuario final debería ser con cuidado seleccionado y mantenido. Debería requerirse que servidor y administradores de escritorio se quede corriente en cuanto a las últimas bromas de hacker y virus. Los

Marcos Huerta S.

187


bugs de seguridad conocidos en sistemas operativos deberían ser identificados y fijados. Además, el software de aplicación debería ser seleccionado basado en parte en su adhesión a prácticas de programación modernas, seguras. Con la creación de lenguajes de programación de alto nivel safer y conciencia de programador creciente de cuestiones

de

seguridad,

muchas

aplicaciones

están

disponibles

que

son

razonablemente seguros. La mayor parte de software de reserva, que todavía es usado por muchos negocios, es vulnerable a ataques simples para derrotar su seguridad, sin embargo.

Para clientes con requerimientos de seguridad rigurosas, las aplicaciones de servidor podrían incorporar la encriptación. Este es además de cualquier encriptación de cliente/servidor usada para proteger datos que viajan a través de una red. Para proteger contra el uso no autorizado de datos, los métodos criptográficos pueden proteger datos en una unidad de disco. Por ejemplo, los datos en unidades de disco pueden ser encriptados de modo que pueda ser leído sólo por la aplicación apropiada.

Los archivos y otros servidores deberían proporcionar caracteristicas de autorización y autenticación. Las políticas de seguridad y los procedimientos deberían especificar prácticas aceptadas en cuanto a contraseñas: cuando ellos deberían ser usados, como ellos deberían ser formateados, y como ellos pueden ser cambiados. En general, las contraseñas deberían incluir tantas letras como números, ser al menos seis carácteres, no ser una palabra común, y ser cambiar a menudo.

En servidores, el conocimiento de contraseña de raíz (o el equivalente non-UNIX) debería ser limitado con unas personas. El invitado considera debería ser evitado de ser posible. Los protocolos que apoyan el concepto de confianza en otros hosts deberían ser usados con la precaución. (Los ejemplos incluyen rlogin y rsh en sistemas UNIX.) los hosts que permiten cuentas de invitado y soporte confiaron que los hosts deberían ser aislados de otros hosts de ser posible.

El Kerberos es un sistema de autenticación que proporciona la seguridad de usuario a hosts para protocolos de nivel de aplicación como el FTP y Telnet. De ser solicitado por la aplicación, Kerberos también puede proporcionar la encriptación. El Kerberos confía en una base de datos clave simétrica que usa un centro de distribución clave (KDC) en un servidor Kerberos.

Asegurando Servicios de Usuario Una política de seguridad debería especificar qué aplicaciones son permitidas correr en ordenadores personales conectados a una red y restringir descargar de aplicaciones desconocidas del Internet u otros sitios. La política de seguridad también debería

Marcos Huerta S.

188


requerir que los ordenadores personales tengan el firewall personal y el software de antivirus instalado. Los procedimientos de seguridad deberían especificar como este software es instalado y guardado corriente.

Los usuarios deberían ser animados a salir de sus sesiones con los servidores cuando se retiran de sus escritorios durante períodos largos del tiempo, y apagar sus máquinas dejando el trabajo, proteger contra la gente no autorizada que se acerca a un sistema y tiene acceso a servicios y aplicaciones. Los procedimientos de fin de registro automáticos también pueden ser desplegados automáticamente el procedimiento de fin de registro una sesión que no ha tenido ninguna actividad para el periodo del tiempo.

Un otro aspecto de asegurar la parte de usuario final de una red asegura que los usuarios conecten computadoras sólo permitidas u otros dispositivos a los interfaces de LAN en sus oficinas. En particular, una área que concierne al usuarios que conecta puntos de acceso inalámbricos que no son correctamente asegurados. Estos puntos de acceso no autorizados son a veces llamados puntos de acceso de pícaro. La seguridad para redes inalámbricas, se hablan más detalladamente en la siguiente sección, no debería ser dejada a usuarios finales. Debería ser con cuidado planeado y puesto en práctica y no comprometido por usuarios que instalan sus propios puntos de acceso inalámbricos.

Cisco y otros vendedores soportan un estándar IEEE llamado 802.1X, que proporciona la seguridad a base de puerto en puertos de switches. Con 802.1X permite en un puerto de switch, ningún dispositivo puede conectarse a la red sin la primera utilización 802.1X para certificar. Este es un método para asegurar que un usuario no instala un dispositivo desconocido, como un punto de acceso inalámbrico. (Con este uso de 802.1X, esto es el punto de acceso que es certificado. Otro uso de 802.1X debe certificar dispositivos de cliente inalámbricos, como ordenadores portátiles. Cuando una infraestructura inalámbrica legítima está en el lugar, 802.1X es ya no necesario en los puertos que conectan puntos de acceso conocidos, pero esto puede ser usado para certificar a usuarios inalámbricos, como fue hablado más tarde en el "802.1X con la sección" de Protocolo de Autenticación Extensible de este capítulo.)

Asegurando Redes Inalámbricas Las redes inalámbricas ganan la popularidad extendida en redes de campus de empresa, en sucursales, y en Ministerios de los asuntos interiores. La mayor parte de organizaciones soportan los aumentos de productividad y satisfacción de empleado que ofertas conectadas a una red inalámbricas, pero al mismo tiempo están preocupados por los riesgos a la seguridad, que ellos pueden ser. En años recientes, los agujeros deslumbrantes han sido descubiertos en los métodos típicos usados para la seguridad

Marcos Huerta S.

189


inalámbrica, causando el desarrollo de nuevos métodos y modelos para proporcionar la seguridad en redes inalámbricas. Esta sección cubre algunas pautas de diseño totales primero y luego incluye la información en los dos temas siguientes: Ø

Autenticación en redes inalámbricas

Ø

Privacidad de datos en redes inalámbricas

Como mencionado en la Parte 5, es mejor colocar LANs inalámbricos (WLANs) en su propia subred y su propio VLAN. Este simplifica la dirección para estaciones que vagan y también mejora la dirección y la seguridad. El cuidado de todos los clientes inalámbricos en su propia subred hace más fácil para establecer filtros de tráfico para proteger a clientes cableados de un ataque lanzado en la red inalámbrica. Para maximizar la flexibilidad vagabunda, todo WLANs puede ser una simple VLAN y la subred de IP, de modo que no haya ninguna necesidad de recuperar una nueva dirección de IP moviendo de una área al otro. Para maximizar la seguridad, sin embargo, puede ser más sabio subdividir el WLAN en VLANs múltiple y subredes de IP.

Tenga en mente que los requerimientos de seguridad para usuarios inalámbricos varían con el tipo de usuario. Los invitados que visitan una empresa pueden necesitar el acceso fácil al Internet, pero deberían ser impedidos tener acceso a la red de empresa. No puede esperarse que estos invitados sepan una llave de encriptación o tengan el software VPN instalado. Este es diferente de los empleados que quieren el acceso inalámbrico almorzando en la cafetería o encontrando en salas de conferencias privadas. Podría esperarse que aquellos usuarios supieran una llave o tuvieran el software de VPN corporativo-aprobado instalado. El uso de VLANs comienza a ser practico aquí. Cuando usted entiende los tipos de usuario diferentes y donde ellos podrían navegar, usted puede dividir el WLAN en VLANs múltiple y aplicar políticas de seguridad por separado para cada VLAN.

Usted debería poner en práctica listas de control de acceso en puntos de acceso inalámbricos y en switches conectados y routers que llevan el tráfico que provino de una red inalámbrica. Las listas de control de acceso deberían permitir protocolos sólo específicos, de acuerdo con políticas de seguridad.

Debería requerirse que todos ordenadores portatiles inalámbricos (y cableados) tengan el antivirus y el software de firewall personal. Ellos también deberían ser con regularidad actualizados con los parches de seguridad de sistema operativo más recientes. Según requeremientos de seguridad, usted también puede querer requerir que usuarios de ordenador portátil inalámbricos corporativos usaran el software VPN para tener acceso a la red de empresa. La sección final en este capítulo, "Usando el Software de VPN en

Marcos Huerta S.

190


Clientes Inalámbricos," habla la utilización IPSec VPN software como una opción de seguridad para redes inalámbricas

Resumen Esta parte proporcionó la información para ayudarle a seleccionar métodos para encontrar los objetivos de un cliente para la seguridad de red. La seguridad es una preocupación principal por la mayor parte de clientes debido al aumento de conectividad de Internet y aplicaciones de Internet, y porque más usuarios tienen acceso a redes de empresa de sitios remotos y dispositivos inalámbricos. También, al mismo tiempo aquellas empresas se han hecho más dependientes de sus redes, el número de ataques contra redes ha aumentado.

Las tareas envuelta con la seguridad diseñar en paralelo las tareas implicadas con el diseño de red total. Es importante analizar requerimientos, desarrollar políticas, y pensar que restricciones antes de seleccionar tecnologías actuales y productos encontraban las necesidades de seguridad de varios usuarios de una red de empresa. La red debería ser considerada un sistema modular que requiere la seguridad para muchos componentes, incluso conexiones de Internet, redes de acceso remoto, servicios de red, servicios de usuario final, y redes inalámbricas. Para proteger la red, usted debería desarrollar estrategias multicapas, procedimientos, y realizaciones que proporcionan la defensa de seguridad en profundidad.

Parte 9. Desarrollando Estrategias de manejo de red Esta sección concluye la discusión del diseño de red lógico. El manejo de red es uno de los aspectos más importantes del diseño de red lógico. El manejo menudo es pasada por alto durante el diseño de una red porque es considerado una cuestión operacional más bien que una cuestión de diseño. Sin embargo, si usted considera el manejo al principio, usted puede evitar escalabilidad y problemas de performance que ocurren cuando el manejo es añadida a un diseño después de que el diseño es completo.

Un diseño de manejo de red bueno puede ayudar a una organización a conseguir disponibilidad, performance, y objetivos de seguridad. Los procesos de manejo de red eficaces pueden ayudar a una medida de organización como bien diseñan objetivos están siendo encontrados y ajustan parámetros de red si ellos no están siendo encontrados. El manejo de red también facilita encontrar objetivos de escalabilidad porque esto puede ayudar a una organización a analizar el comportamiento de red corriente, aplicar mejoras apropiadamente, y soluciones a fallas de cualquier problema con mejoras. El objetivo de esta sección es ayudarle a trabajar con su cliente el diseño

Marcos Huerta S.

191


de red en el desarrollo de estrategias de manejo, y ayudarle a seleccionar los instrumentos correctos y productos para poner en práctica las estrategias.

Diseño de Manejo de Red Esto es una idea buena de acercarse al diseño de manejo de red del mismo modo usted se acerca a cualquier proyecto de diseño. Piense en escalabilidad, modelos de tráfico, formatos de datos, y compensaciones de costo/ventaja. Los sistemas de manejo de red pueden ser muy caros. Ellos también pueden tener un efecto negativo en la performance de red.

Preste la atención al principio de incertidumbre Heisenberg, que declara que el acto de observación de algo puede cambiar lo que es observado. Algunos sistemas de manejo de red causan colas en estaciones remotas en una base regular. La cantidad de tráfico causado por la cola puede ser significativa. Usted debería analizar los requerimientos de su cliente para colas temporizadores y no arbitrariamente usar las faltas de un sistema de manejo de red.

El trabajar con su cliente para entender que los recursos deberían ser monitoreados y la métrica para usar midiendo la performance de los dispositivos. Elija los datos para reunirse con cuidado. El ahorro de demasiados datos puede causar un requerimiento para una supercomputadora para tratar y almacenar los datos. Por otra parte, procure no tirar tantos datos que usted es incapaz de usar los datos restantes para manejar la red.

Planee el formato en el cual los datos deberían ser salvados con cuidado. Usted debería tratar de usar formatos de datos de uso general. Asuma que los datos que usted colecciona podrían ser usados para aplicaciones diferentes que estos que usted está pensando. Cuando Kathryn Cramer dice en sus Caminos de libro a Casa: Siete Caminos a la Sabiduría de la Mitad de la vida:

Permanezca abierto a posibilidades además de lo que ha sido imaginado.

Manejo de Red Preventiva Cuando ayude a su cliente a diseñar estrategias de manejo de red, usted debería animar la práctica de majeo de red preventivo. Cuando más compañías reconocen la importancia estratégica de sus redes, ellos ponen más énfasis en el manejo preventivo. El medio de manejo preventivo que comprueba la salud de la red durante la operación normal para reconocer problemas potenciales, optimize la performance, y planee mejoras.

Marcos Huerta S.

192


Las compañías que práctican manejo preventiva colecciona la estadística y conduce pruebas, como medidas de tiempo de respuesta, en una base rutinaria. La estadística y los resultados de prueba pueden ser usados para comunicar tendencias y conectar a la red la salud a manejar y usuarios. Los administradores de red pueden escribir informes mensuales o trimestrales que documentan la calidad del servicio de red que ha sido entregado en el período pasado, medido contra objetivos de servicio. (Los objetivos de servicio son definidos por el diseño de red: disponibilidad, tiempo de respuesta, rendimiento, utilidad, etcétera.)

Si su cliente de diseño de red planea implementar el manejo de red preventiva, que usted debería animar, considere este objetivo diseñando una estrategia de manejo de red para su cliente. El manejo de red preventiva es deseable, pero puede requerir que instrumentos de manejo de red y procesos para ser más sofisticados que con el manejo de red reactiva.

Procesos de Manejo de Red La parte 2, "Analizando Objetivos Técnicos y Restricciones," habló del análisis de los objetivos de un cliente para la manejabilidad de una red. En general, la mayor parte de los clientes tienen una necesidad de desarrollar procesos de manejo de red que pueden ayudarles a manejar la realización y la operación de la red, diagnosticar y fijar problemas, optimizar la performance, y planear actualizaciones.

La Organización Internacional para la Estandarización (ISO) define cinco tipos de procesos de manejo de red: Ø

Manejo de performance.

Ø

Manejo de fallas.

Ø

Manejo de configuración.

Ø

Majeno de seguridad.

Ø

Manejo de la contabilidad.

Manejando la Performance Según la ISO, el manejo de performance permite la medida del comportamiento de la red y eficacia. El manejo de performance incluye examinar la aplicación de red y el comportamiento de protocolo, análisis de la accesibilidad, medición de tiempo de respuesta, y grabación de cambios de ruta de red. El manejo de performance facilita optimizar una red, encontrando acuerdos de nivel de servicio, y planeando para la expansión. Monitorear el performance implica coleccionar datos, procesando algunos o todos los datos, mostrando los datos procesados, y archivando algunos o todos los datos.

Marcos Huerta S.

193


Dos tipos de performance deberían ser supervisados: Ø

El manejo de performance de punta a punta mide la performance a través de unas redes. Esto puede medir disponibilidad, capacidad, utilización, tardanza, variación de tardanza, rendimiento, accesibilidad, tiempo de respuesta, errores, y el burstiness del tráfico.

Ø

El componente de performance mide la performance de enlaces individuales o dispositivos. Por ejemplo, el rendimiento y la utilización en un segmento de red particular pueden ser medidos. Además, los routers y los switches pueden ser supervisados para el rendimiento (paquetes por segundo), memoria y uso de CPU, y errores.

El manejo de performance a menudo implica colas remotas de la red para probar accesibilidad y tiempos de respuesta medida. Las medidas de tiempo de respuesta consisten en enviar un paquete de ping y medir el tiempo de ida y vuelta (RTT) para enviar el paquete y recibir una respuesta. El paquete de ping es realmente un Protocolo de Mensaje de Control de Internet (ICMP) paquete de eco.

En redes muy grandes, la accesibilidad y los estudios de RTT pueden ser poco prácticos. Por ejemplo, en una red con 10,000 dispositivos, algunos sistemas de manejo de red comercialemente disponibles toman horas para colas de dispositivos, causa el tráfico de red significativamente, y salva más datos que un humano puede tratar. El trabajo con su cliente para reducir objetivos para hacer accesibilidad y RTT estudia si los objetivos son poco realistas.

Otro proceso de manejo de performance usa analizadores de protocolo o instrumentos SNMP para registrar cargas de tráfico entre fuentes importantes y destinos. El objetivo es documentar los megabytes por segundo entre puntos de sistemas autónomos, redes, hosts, o aplicaciones. La documentación de carga de tráfico de fuente/destino es útil para planificación de capacidad, solución, y entendimiento qué routers deberían ser puntos en el protocolo de enrutamiento que usan mirando detenidamente el sistema, como el Protocolo de Entrada Fronterizo (BGP). Los datos de carga de tráfico de fuente/destino son también útiles si un acuerdo de nivel de servicio incluye requerimientos de rendimiento.

El manejo de performance puede incluir procesos para registrar cambios de rutas entre estaciones. El rastreo de cambios de ruta puede ser útil para solución de accesibilidad y problemas de performance. Un camino de documentar cambios de ruta es usar paquetes de eco de ICMP con la opción de ruta de registro IP encendida. Esté consciente que encendiendo la opción de ruta de registro podría sesgar medidas RTT,

Marcos Huerta S.

194


sin embargo. La opción de ruta de registro hace que cada router ponga su dirección en el campo de opciones de cabecera IP, que puede causar el tiempo extra de procesamiento. ¡(No olvide el principio de incertidumbre Heisenberg!) Planean hacer estudios de cambio de ruta por separado de análisis de RTT. Otro modo de estudiar cambios de ruta es con el IP traceroute la orden. El Traceroute es algo no fiable, sin embargo.

Manejo de Fallas El manejo de fallas se refiere a descubrimiento, aislamiento, diagnosticar, y corrección de problemas. Esto también incluye procesos para relatar problemas a usuarios finales y gerentes, y rastrear tendencias relacionadas con problemas. En algunos casos, medios de manejo de fallas que desarrollan workarounds hasta que un problema puede ser resuelto.

Los usuarios de red esperan la rapida y confiable resolución de fallas. Ellos también esperan ser guardados en informes sobre problemas en curso y ser dado un margen de tiempo para la resolución. Después de que un problema es resuelto, ellos esperan que el problema sea probado y luego documentado en alguna clase de la base de datos que rastrea problema. Una variedad de instrumentos existe para encontrar estos requerimientos de manejo de fallas, incluso el monitoreo de instrumentos que alertan a gerentes a problemas, analizadores de protocolo para resolución de fallas, y software de punto de ayuda para documentar problemas y alertar a usuarios de problemas. Los instrumentos que supervisan están a menudo basados en el SNMP y Monitoreo Remoto (de RMON) estándares, que son cubiertos más detalladamente más tarde en esta sección.

La mayor parte de los sistemas operativos proporcionan un significado para el sistema y corren procesos para reportar fallas a un administrador de red. Los dispositivos de Cisco producen mensajes syslog a consecuencia de acontecimientos de red. Cada mensaje syslog contiene un sello de tiempo, el nivel, y la instalación. Los niveles de Syslog son como sigue: Ø

La emergencia (nivelan 0, el nivel más severo)

Ø

La alarma (nivelan 1)

Ø

Crítico (nivelan 2)

Ø

El error (nivelan 3)

Ø

Advirtiendo (nivelan 4)

Ø

Notificando (nivele 5)

Ø

Informativo (nivelan 6)

Ø

Eliminando fallas (nivelan 7)

Marcos Huerta S.

195


Los mensajes de Syslog son enviados por defecto al router Cisco o switch de consola. Los dispositivos de red pueden ser configurados para enviar mensajes syslog a una estación de manejo de red o un host de red remoto en el cual un analizador syslog es instalado. Un analizador syslog aplica filtros y envía sólo un subconjunto predefinido de todos los mensajes syslog a una estación de manejo de red. Este salva el ancho de banda y también reduce la cantidad de información que un administrador de red debe analizar.

Manejo de Configuración El manejo de configuración ayuda a un administrador de la red a guardar la pista de dispositivos de red y mantener la información en como los dispositivos son configurados. Con el manejo de configuración, un administrador de la red puede definir y salvar una configuración por defecto de dispositivos similares, modificar la configuración por defecto para dispositivos específicos, y cargar la configuración en dispositivos.

El manejo de configuración también deja a un gerente mantener un inventario de activos de red, y hacer el registro de versión. El registro de versión se refiere a la pista que se conserva de la versión de sistemas operativos o aplicaciones que corren en los dispositivos de red. El inventario de activos de red también puede incluir la información en la configuración de hardware de dispositivos, como la cantidad de RAM, el tamaño de la memoria de Destello, y el tipo de tendido de cables que los dispositivos usan.

El manejo de configuración facilita el manejo de cambio. En el pasado, los administradores de red han gastado mucho tiempo la mayor parte de su tiempo manejando configuraciones para nuevos empleados y cambios de configuración para empleados que se movieron. Anime a su cliente de diseño de red a usar protocolos de configuración dinámicos e instrumentos, como el Protocolo de Configuración de Hosts Dinámico (DHCP), liberar el tiempo de manejo para más tareas estratégicas que movimientos, añadir, y cambios. Un protocolo como el VLAN Trunking Protocolo (VTP) es también beneficioso, porque esto automáticamente actualiza switches con la información VLAN.

Manejo de Seguridad El manejo de seguridad deja a un administrador de la red mantener y distribuir contraseñas y otra autenticación e información de autorización. El manejo de seguridad también incluye procesos para generación, distribución, y almacenaje de llaves de encriptación. Esto también puede incluir instrumentos e informes para analizar un grupo de routers y configuraciones de switches para la conformidad con estándares de seguridad de sitio.

Marcos Huerta S.

196


Un aspecto importante del manejo de seguridad es un proceso para recogimiento, almacenaje, y examen de logs de audit de seguridad. Los logs de audit deberían documentar entradas al sistema y procedimientos de fin de registro (pero no salvar contraseñas) y las tentativas por la gente para cambiar su nivel de la autorización.

El recogimiento de datos de audit puede causar una acumulación rápida de datos. El almacenaje requerido puede ser minimizado guardando datos durante un período corto del tiempo y resumiendo los datos. Un inconveniente al cuidado de menos datos, sin embargo, consiste en que hace más difícil de investigar incidentes de seguridad. La compresión de los datos, en vez de guardar menos datos, es a menudo una mejor solución. Esto es también una idea buena de encriptar los logs de audit. Un hacker que tiene acceso a los logs de audit puede causar mucho daño a una red si el logs de audit no es encriptado. El hacker puede cambiar el logs sin ser descubierto y también depurar la información sensible de logs.

Una variedad de instrumentos existe para mantenimiento de logs de seguridad, incluso el Event Viewer en las maquinas de Windows 2000, syslog en UNIX y Cisco IOS dispositivos, y revisión de C2 para informes de auditoría detallada en sistemas UNIX. El Departamento de defensa estadounidense definió la seguridad C2, incluso la revisión, como la parte de sus pautas para la seguridad de computadora en los años 1980.

Manejo de Contabilidad El manejo de la contabilidad facilita la facturación a base de uso, por lo cual los departamentos individuales o los proyectos son cobrados para servicios de red. Incluso en casos donde no hay ningún cambio de dinero, la contabilidad del uso de red puede ser útil para agarrar departamentos o individuos que "abusan" de la red. El abuso podría ser intencional, por ejemplo, un empleado descontento o empleado antiguo que causa problemas de red, o el abuso podría ser involuntario. (La gente que juega juegos de red no tiene la intención de dañar la red, pero podría causar el tráfico excesivo sin embargo.) una razón práctica de rastrear crecimiento de tráfico inesperado es de modo que el tráfico pueda ser considerado durante la siguiente fase que planea capacidad.

Arquitecturas de manejo de Red Esta sección habla de algunas decisiones típicas que deben ser hechas seleccionando una arquitectura de manejo de red. Una arquitectura de manejo de red consiste en tres componentes principales: Ø

Un dispositivo manejado es un nodo de red que colecciona y almacena la información de manejo. Los dispositivos manejados pueden ser routers, servidores, switches, puentes, hubs, sistemas finaesl, o impresoras.

Marcos Huerta S.

197


Ø

Un agente es el software de manejo de red que reside en un dispositivo manejado. Un agente rastrea la información de manejo local y usa un protocolo como SNMP para enviar la información a NMSs.

Ø

Un sistema de manejo de red (NMS) las aplicaciones de carreras para mostrar datos de manejo, monitor y control manejaron dispositivos, y comunicarse con agentes. Un NMS es generalmente una estación de trabajo poderosa que ha sofisticado gráfica, memoria, almacenaje, y capacidades de procesamiento.

Figura Nro. 34 muestra la relación entre dispositivos manejados, agentes, y NMSs.

Figura Nro.34. Una Arquitectura de Dirección de Red

Una arquitectura de manejo de red consiste en dispositivos manejados, agentes, y NMSs arreglado en una topología que cabe en la topología de redes. Las tareas para diseñar una arquitectura paralela de manejo de red de las tareas para diseñar unas redes. El flujo de tráfico y la carga entre NMSs y dispositivos manejados deberían ser considerados. Una decisión debería ser tomada en cuanto a si el tráfico de manejo fluye en cinta (con otro tráfico de red) o fuera de cinta (fuera del flujo de tráfico normal). Una topología redundante debería ser considerada. Una decisión debería ser tomada en cuanto a una topología de manejo centralizada o distribuida.

En Cinta Contra Escucha de Cinta Con la escucha en cinta, manejar la red de datos que viaja en las redes usando los mismos caminos que el tráfico de usuario. Este hace la arquitectura de manejo de red mas fácil para desarrollarse, pero el resultado en este dilema que manejar la red de datos son afectados por problemas de la red, haciéndolo más difícil a para solucionar los

Marcos Huerta S.

198


problemas. Es beneficioso ser capaz de usar instrumentos de manejo aun cuando las redes son congestionadas, defectosas, o esta bajo un ataque de seguridad.

Con la escucha de cinta, monitoree a la red de datos de caminos diferentes que datos de usuario. El NMSs y los agentes son enlazados vía los circuitos que son separados de las redes. El circuito puede usar dialup, ISDN, el Frame Relay, u otras tecnologías. El separar circuito puede ser usado todo el tiempo o ellos pueden usarlo como la backup sólo cuando el camino de redes primario está roto.

La escucha de cinta hace diseñar la red más compleja y cara. Para contener el costo, el análogo dialup líneas a menudo es usado para la reserva, más bien que ISDN o circuitos de Frame Relay. Otra restricción con la escucha de cinta es que hay riesgos a la seguridad asociados con la adición de enlaces suplementarios entre NMSs y agentes. Para reducir los riesgos, los enlaces deberían ser con cuidado controlados y añadidos sólo de ser absolutamente necesario. Para enlaces de módem análogos, el agente debería usar un mecanismo de rellamada después de que el NMS llama el agente.

Centralizado Contra Monitoreo Distribuido En una arquitectura de monitoreo centralizado, todos NMSs residen en una área de la red, a menudo en un centro de operaciones de red corporativo (NOC). Los agentes son distribuidos a través de las redes y envían datos como ping y los SNMP responden a NMSs centralizado. Los datos son enviados vía caminos de cinta o en cinta.

El monitoreo distribuido significa que NMSs y los agentes son extendidos a través de las redes. Un arreglo distribuido jerárquico puede ser usado por cual se distribuyó NMSs envían datos a sofisticado centralitas NMSs usando un gerente de gerentes (MoM) arquitectura. Un sistema centralizado que maneja NMSs distribuido es llamado a veces paraguas NMS.

En una arquitectura de MoM distribuida, NMSs puede filtrar datos antes de enviarlo a las estaciones centralizadas, haciendo reducir la cantidad de datos de manejo de red que fluyen en las redes. Otra ventaja con el manejo distribuido consiste en que los sistemas distribuidos a menudo pueden juntar datos aun cuando las partes de las redes fallan.

La desventaja con el manejo distribuido es que la arquitectura es compleja y difícil de manejar. Es más difícil controlar la seguridad, contener la cantidad de datos que son coleccionados y almacenados, y guardar la pista de dispositivos de manejo. Una arquitectura de manejo de red simple que no complica el trabajo de manejar la red es generalmente una mejor solución.

Marcos Huerta S.

199


La Selección de Protocolos para el Manejo de Red Después de que usted ha hablado de procesos de manejo de red de alto nivel con su cliente, y ha desarrollado una arquitectura de manejo de red, usted puede tomar algunas decisiones en cual protocolos de manejo de red recomendar a su cliente. Usted puede encontrar las necesidades de la mayor parte de clientes recomendando a SNMP y RMON. El Protocolo de Descubrimiento de Cisco (CDP) es también provechoso.

Protocolo de Manejo de Red Simple El SNMP es apoyado por la mayor parte de NMSs comercial así como muchos dispositivos conectados a una red incluso switches, routers, servidores, y estaciones de trabajo. El SNMP ha ganado la popularidad extendida debido a su simplicidad y porque es fácil poner en práctica, instalar, y usar. También, cuando usado con sensatez, SNMP no coloca la carga excesiva en la red. La interoperabilidad entre realizaciones SNMP de vendedores diferentes puede ser conseguida con el esfuerzo mínimo porque SNMP es tan simple.

El SNMPv3 debería suplantar gradualmente las versiones 1 y 2 porque esto ofrece la mejor seguridad, incluso la autenticación para proteger contra la modificación de información, y operaciones de juego seguras para la configuración remota de dispositivos SNMP-manejados.

El SNMPv2 fue introducido en 1993 y actualizado en 1996. El SNMPv2 añadió una operación de poner-bulto para la recuperación eficiente de un bloque de parámetros cuando datos crecientes de una tabla de parámetros. Sin embargo, ni SNMPv1 ni SNMPv2 proporcionan caracteristicas de seguridad. Sin la autenticación, es posible para usuarios no autorizados para ejercer funciones de manejo de red de SNMP. Es también posible para usuarios no autorizados para escuchar a escondidas la información de manejo cuando esto pasa de sistemas manejados a un NMS. El SNMPv3 proporciona caracteristicas de seguridad para ayudar a aliviar estos problemas. A causa de su seguridad, SNMPv3 puede ser usado para más que supervisar sólo la estadística de red. También puede ser usado para aplicaciones de control. La mayor parte de vendedores apoyan SNMPv3. El Cisco comenzó a apoyar SNMPv3 en IOS 12.0 (3) T.

El SNMP es especificado en tres juegos de documentos: Ø

El RFC 2579 define mecanismos para describir y llamar parámetros que son manejados con SNMP. Los mecanismos son llamados la estructura de la información manejada o SMI.

Ø

El RFC 1905 define operaciones de protocolo para SNMP.

Marcos Huerta S.

200


Ø

Las Bases de Información de Dirección (MIBs) definen parámetros de dirección que son accesibles vía SNMP. Varios RFCs definen MIBs de tipos diferentes. El juego principal de parámetros para la suite de Internet de protocolos es llamado MIB II y es definido en RFC 1213. Los vendedores también pueden definir MIBs privado.

El SNMP tiene siete tipos de paquetes: Ø

Consiga la Petición. Enviado por un NMS a un agente para coleccionar un parámetro de dirección.

Ø

Petición Después conseguiré. Enviado por un NMS para coleccionar el siguiente parámetro en una lista o tabla de parámetros.

Ø

Petición de Poner-bulto. Enviado por un NMS para recuperar bloques grandes de datos, como filas múltiples en una mesa (no en SNMPv1).

Ø

Respuesta. Enviado por un agente a un NMS en respuesta a una petición.

Ø

Petición de Juego. Enviado por un NMS a un agente para configurar un parámetro en un dispositivo manejado.

Ø

Trampa. Enviado autónomamente (no en respuesta a una petición) por un agente a un NMS para notificar el NMS de un acontecimiento.

Ø

Informar. Enviado por un NMS para notificar otro NMS de la información en una vista de MIB que es remota a la aplicación de recepción (no en SNMPv1, arquitecturas de MoM de apoyos)

Bases de Información de Manejo (MIBs) Un MIB almacena la información juntada por el agente de dirección local en un dispositivo manejado. Cada objeto en un MIB tiene un identificador único. Las aplicaciones de manejo de red usan el identificador para recuperar un objeto específico. El MIB es estructurado como un árbol. Los objetos similares son agrupados bajo la misma rama del árbol MIB. Por ejemplo, varios mostradores de interfaz son agrupados bajo la rama de Interfaces del MIB II (RFC 1213) árbol.

El MIB II define los grupos siguientes de objetos manejados para redes de TCP/IP: Ø

The System group

Ø

The Interfaces group

Ø

The Address Translation group

Ø

The IP group

Ø

The ICMP group

Ø

The TCP group

Ø

The UDP group

Ø

The EGP group

Ø

The Transmission group

Marcos Huerta S.

201


Ø

The SNMP group

Además de MIBs estándar, como MIB II para objetos de TCP/IP, hay definiciones MIB específicas de vendedor. Los vendedores pueden obtener su propia rama para la definición privada de un subárbol MIB y crear los objetos manejados de costumbre bajo aquella rama. Para usar definiciones privadas de objetos manejados, un administrador de red debe importar las definiciones en un NMS. Un router Cisco apoya MIB estándar II objetos y objetos manejados privados introducidos por Cisco en una sección privada del árbol

MIB.

El

Cisco

MIB

definiciones

puede

ser

obtenido

en

http://www.cisco.com/public/mibs.

Monitoreo Remoto (RMON) El RMON MIB fue desarrollado por el IETF a principios de los años 1990 para dirigirse a defectos en MIBs estándar, que careció de la capacidad de proporcionar la estadística a enlace de datos y parámetros de capa físicos.

El IETF al principio desarrolló el RMON MIB para proporcionar la estadística de tráfico de Ethernet y el diagnóstico de falla. En 1994, las estadísticas de Token Ring fueron añadidas.

Los agentes de RMON juntan la estadística a la comprobación por redundancia cíclica (CRC) errores, colisiones de Ethernet, errores de software de Token Ring, distribución de tamaño de paquete, el número de paquetes, y el ratio de paquetes de broadcast. El grupo de alarma de RMON deja a unos umbrales de juego de administrador de la red para parámetros de red y configurar a agentes para entregar automáticamente alarmas a NMSs. El RMON también apoya paquetes de captura (con filtros de ser deseados) y envío de los paquetes capturados a un NMS para el análisis de protocolo.

El RMON entrega la información en nueve grupos de parámetros. Muestran en los grupos para redes de Ethernet Mesa 9-1.

Marcos Huerta S.

202


Table 9-1. RMON Ethernet Groups Group

Description

Statistics

Tracks packets, octets, packet-size distribution, broadcasts, collisions, dropped packets, fragments, CRC/alignment errors, jabbers, and undersized and oversized packets.

History

Almacena muestras múltiples de valores del grupo de Estadística para la comparación del comportamiento corriente de una variable seleccionada a su interpretación durante el período especificado.

Alarms

Permite umbrales que se ponen e intervalos de muestreo en cualquier estadística crear una condición despertadora. Los valores de umbral pueden ser un valor absoluto, una rebelión o el valor decreciente, o un valor de delta

Hosts

Proporciona una tabla para cada nodo activo que incluye una variedad de la estadística de nodo incluso paquetes y octetos en y, multicast y paquetes de broadcast, y cuentas de error.

Host Top

Amplía la tabla de host para ofrecer un estudio definido por

N

usuario de la estadística de host clasificada. La Cumbre de host N es calculada en la localidad por el agente, a la baja de reducir el tráfico de red y tratar en el NMS.

Matrix

Muestra la cantidad de tráfico y el número de errores que ocurren entre pares de nodos dentro de un segmento.

Filters

Deja al usuario definir filtros de partido de paquete específicos y hacer que ellos sirvan como una parada o mecanismo de principio para la actividad de captura de paquete.

Packet

Los paquetes que pasan los filtros son capturados y almacenados

Capture

para el análisis adicional. Un NMS puede solicitar que la captura almacene en un buffer y analice los paquetes.

Events

Deja al usuario crear entradas en un backbone de monitor o generar

trampas

de

SNMP

del

agente

al

NMS.

Los

acontecimientos pueden ser iniciados por un umbral cruzado en un contador o por una cuenta de partido de paquete.

Marcos Huerta S.

203


Para redes Token Ring hay nueve grupos que son realzados para incluir la capacidad de rastrear, purgar, el error de software, y otro Control de Acceso de Medios (MAC) de paquetes. Los grupos de Token Ring dejan a un manejador determinar el estado de toque, qué estación es el monitor activo, un dominio que falla, y una lista de estaciones en la orden de toque. El grupo de Control de Configuración de Estación de Toque deja al manejador quitar estaciones de un anillo usando la 802.5 quitar-estación paquete de MAC.

El RMON provee a administradores de la red de la información sobre la salud y la performance del segmento de red en el cual el agente RMON reside. El RMON proporciona una vista de la salud del segmento entero, más bien que la información específica de dispositivo que muchos non-RMON SNMP agentes proporcionan. Las ventajas de RMON son obvias, pero el alcance de la versión 1 (RMON1) RMON es limitado porque esto se concentra en enlace de datos y parámetros de capa físicos. El IETF trabaja actualmente en un estándar RMON2 que se mueve más allá de la información de segmento para suministrar la información en la salud y la performance de aplicaciones de red y comunicaciones de punta a punta. El RMON2 es descrito en 2021 RFC. Mesa 9-2 muestra los grupos en RMON2.

Table 9-2. RMON2 Groups Group

Description

Protocol

Proporciona una lista de protocolos apoyados por el

Directory

dispositivo

Protocol

Contiene la estadística de tráfico para cada protocolo

Distribution

apoyado

Address

Contiene la capa de red a la correlación de dirección de

Mapping

capa MAC

Network

Layer

Host Network

Contiene la estadística para el tráfico de capa de red a o de cada host

Layer

Contiene la estadística de tráfico de capa de red para

Matrix

conversaciones entre pares de hosts

Application

Contiene la estadística para el tráfico de capa de aplicación

Layer Host

a o de cada host

Application

Contiene la estadística de tráfico de capa de aplicación para

Layer Matrix

conversaciones entre pares de hosts

User

Contiene muestras periódicas de variables especificadas de

Marcos Huerta S.

History

204


Table 9-2. RMON2 Groups Group

Description

Collection

usuario

Probe

Proporciona un camino estándar de configurar remotamente

Configuration

parámetros de los sonda como atrapan el destino y la dirección de cinta

Protocolo de Descubrimiento de Cisco Como mencionado en El capítulo 3, "Caracterizando las redes Existentes," CDP especifica un método para routers Cisco e switches para enviar la información de configuración el uno al otro en una base regular. Aunque algunos expertos de seguridad recomiendan por desabilitar CDP porque un hacker podría usar la información para aprender sobre configuración de una red y topología, muchos administradores de la red se olvidan habilitado CDP debido a su utilidad. El CDP es habilitado por defecto.

Con el comando show cdp neighbors detail, usted puede mostrar la información detallada sobre routers vecinos e switches, incluso cuales protocolos estan habilitados, las direcciones de red para protocolos permitidos, el número y tipos de interfaces, el tipo de plataforma y sus capacidades, y la versión del Sistema Operativo de redes Cisco (IOS) Software que corre en el vecino.

El CDP es un medio - y protocolo - independiente protocolo. El CDP corre en la capa de enlace de datos, permitiendo a dos sistemas que soportan protocolos de capa de red diferentes para comunicarse. Los paquetes de CDP usan un Protocolo de Acceso de Subred (SNAP) encapsulation y son enviados a la dirección 01-00-0C-CC-CC-CC de multicast de Cisco. Aunque los switches por lo general envian paquetes de multicast, los switches de Cisco no envian paquetes de CDP. Los routers también no envian paquetes de CDP. Los paquetes de CDP son enviados cada 60 segundos en ausencia, aunque usted pueda cambiar este con el comando cdp timer.

Los marcos de CDP son enviados con un holdtime de 180 segundos en ausencia. El Holdtime específica la cantidad de tiempo que un dispositivo de recepción debería sostener la información antes de desecharlo. Cuando un interfaz es caida, CDP envía un paquete con el juego de holdtime en cero. Usted puede configurar holdtime con el comando cdp holdtime. El envío de un paquete CDP con un holdtime de cero permite que un dispositivo de red descubra rápidamente a un vecino perdido.

Marcos Huerta S.

205


La Estimación de Tráfico de Red Causado por Manejo de Red Después de que usted ha determinado qué protocolos de manejo serán usados, usted puede estimar la cantidad de tráfico causado por el manejo de red. Probablemente el protocolo de manejo principal será SNMP, aunque otras opciones existan, como CDP, ping, IP traceroute, etcétera.

Después de seleccionar protocolos de manejo, usted debería determinar que conectan a la red y las características de dispositivo serán manejadas.

El objetivo es determinar que datos NMS solicitará del dispositivos manejados. Estos datos podrían consistir en información de accesibilidad, medidas de tiempo de respuesta, información de dirección de capa de red, y datos del RMON MIB u otro MIBs. Después de que usted ha determinado que características serán juntadas del dispositivos manejados, usted debería determinar entonces con que frecuencia el NMS solicita los datos. (Este es llamado el intervalo de cola.)

Para calcular una estimación de la carga de tráfico, multiplique el número de características de dirección por el número de dispositivos manejados y divídase por el intervalo de cola. Por ejemplo, si una red tiene 200 dispositivos manejados y cada dispositivo es supervisado para 10 características, el número que resulta de peticiones es como sigue:

200 * 10 = 2000 El número que resulta de respuestas es también 200 * 10 = 2000

Si el intervalo de cola es cada 5 segundos y asumimos que cada petición y respuesta son un paquete de 64 bytes solo, la cantidad del tráfico de red es como sigue:

(4000 peticiones y respuestas) * 64 bytes * 8 trozos/bytes = 2,048,000 trozos cada 5 segundos o 409,600 bps

En este ejemplo, en Ethernet 10-Mbps compartida, los datos de dirección de red usarían el 4 por ciento del ancho de banda de red disponible, que es significativa, pero probablemente aceptable. Una regla básica buena es que el tráfico de manejo debería usar menos del 5 por ciento de la capacidad de una red.

Marcos Huerta S.

206


La Selección de Instrumentos para el Manejo de Red Para asegurar la disponibilidad alta de red, los instrumentos de manejo deberían soportar numerosas caracteristicas que pueden ser usadas para performance, falla, configuración, seguridad, y manejo de la contabilidad.

Lo minimo para, una solución de manejo de red debería incluir instrumentos para aislamiento, diagnosticar, y reportar problemas para facilitar la reparación rápida y la recuperación. Idealmente, el sistema también debería incorporar la inteligencia para identificar tendencias que pueden predecir un fallo potencial, de modo que un administrador de red pueda tomar medidas antes de que una condición de falla ocurra.

Seleccionando instrumentos de manejo, considere la flexibilidad de los instrumentos y los auditorios variados que pueden el interfaz con ellos. Los instrumentos de manejo de red deberían proporcionar un interfaz de usuario intuitivo que puede reaccionar rápidamente a la introducción de datos por el usuario. En muchos casos, teniendo tanto un interfaz navegador como el interfaz de línea de orden (CLI) son beneficiosos.

Si los instrumentos permiten la configuración dinámica de dispositivos, los cambios de configuración deberían entrar en vigor sin requerir reboot al dispositivo, si el dispositivo soporta esto, porque la interrupción del servicio para un dispositivo es crítico podría afectar potencialmente a miles de usuarios. El software de manejo también debería ser capaz de comprobar la validez de cualquier cambio de configuración, y automáticamente restaurar la operación a la última configuración conocida o imagen de software en caso del error. El software de manejo que soporta la configuración dinámica de dispositivos debería requerir que la autenticación evite a un usuario no autorizado que hace cambios.

Instrumentos de Cisco Ya que su red esta diseñada a clientes que tienen numerosos productos Cisco, Cisco ofrece una amplia variedad de instrumentos de manejo. El CiscoWorks y Cisco la familia de productos de Seguridad consolida y automatiza tareas de manejo comunes. Estos productos soportan el dispositivo y el manejo de infraestructura, la seguridad y el manejo de identidad, la dirección de telefonía IP, y la dirección de tráfico crítica. Los instrumentos de CiscoWorks incluyen el CiscoWorks QoS Manejo de Política, Manejo de Voz de CiscoWorks para Entradas de Voz, CiscoWorks Pequeña Solución de Manejo de Red, CiscoWorks Motor de Solución de LAN Inalámbrico, y CiscoWorks Azul.

Incluso para clientes de diseño de red que no usan exclusivamente productos Cisco, un entendimiento de dos tecnologías de Cisco claves (NetFlow y Agente de Aseguramiento de Servicio) puede ayudarle a reconocer los tipos de datos que se conectan a la red

Marcos Huerta S.

207


sistemas de manejo debería juntar y analizar. Por esta razón, estos dos instrumentos son cubiertos más detalladamente en las secciones siguientes.

Cisco NetFlow Contabilidad Como mencionado en la Parte 3, Cisco IOS NetFlow tecnología es una parte integrante de Cisco IOS Software que colecciona y mide datos cuando esto entra a las interfaces del switch o routers. La información juntada permite a un administrador de la red caracterizar la utilización de red y recursos de aplicación. Esto también puede ser usado para diseñar la calidad del servicio (QoS). Un flujo de red es definido como una secuencia unidireccional de paquetes entre una fuente y destino endpoint.

Un flujo endpoint es identificado tanto por la dirección de IP como por el número de puerto de capa de transporte. El NetFlow también identifica flujos por el tipo de protocolo IP, la clase del servicio (Compañías), y un identificador de interfaz de entrada.

Los datos de NetFlow de reconocimiento dejan a un administrador de red visualizar modelos de tráfico de modo que el descubrimiento del problema preventivo sea posible. Esto también permite que un administrador de l red ponga en práctica la contabilidad de utilización de recurso. Los proveedores de servicio pueden usar la información NetFlow para emigrar lejos de honorarios solos, facturación de tipo fijo, a mecanismos de cobro más flexibles basados en tiempo de día, uso de ancho de banda, uso de aplicación, QoS, etcétera. Los administradores de red de empresa pueden usar la información para la recuperación de costo departamental y costear la asignación para la utilización de recurso.

La Reunión de datos de NetFlow también permite que un administrador de la red gane una vista detallada, a base de tiempo del uso de aplicación. El contenido y los proveedores de servicio pueden usar esta información para planear y asignar red y recursos de aplicación de encontrar demandas de cliente. Por ejemplo, un proveedor contento puede decidir la capacidad y la posición de servidores de web, basados en datos NetFlow. Los datos de NetFlow, o la información sacada de ello, pueden ser almacenados para recuperación posterior y análisis, en apoyo de mercadotecnia preventiva y programas de servicio de cliente (por ejemplo, para determinar qué aplicaciones y servicios están siendo usados por usuarios internos y externos y apuntan para mejorar el servicio).

El Cisco recomienda un despliegue NetFlow con cuidado planeado, con servicios NetFlow activados en routers estratégicamente localizados, por lo general routers en el borde de una red. Aunque NetFlow tenga un impacto de performance en routers de tráfico, el impacto es mínimo y es menos que el impacto de RMON. Las ventajas de la

Marcos Huerta S.

208


reunión de información NetFlow, cuando comparado a SNMP y RMON, incluyen el mayor detalle de datos coleccionados, el timestamping de datos, apoyo a datos diferentes juntados en las diferentes interfaces, y mayor escalabilidad. También, con NetFlow, un probador de RMON externo no es requerido.

El Agente de Aseguramiento de Servicio Cisco (SAA) Como NetFlow, el Agente de Aseguramiento de Servicio Cisco (SAA) es el software que es incorporado a la mayor parte de plataformas de Cisco. El SAA apoya la escucha de performance de red activa. La escucha activa significa que el tráfico es generado y analizado para medir la performance entre dispositivos de Cisco o entre dispositivos de Cisco y servidores. Un administrador de la red puede usar SAA para medir la salud de red, verificar acuerdos de nivel de servicio, asistir con solución de red, y mejoras de red de plan.

El SAA puede generar UDP, TCP, y paquetes de prueba de ICMP y medir la métrica del performance basada en respuestas a los paquetes. Una caracteristica clave de SAA es la capacidad de marcar los paquetes de prueba con el valor de Compañías IP apropiado. La marca de paquetes deja a una performance de prueba de administrador de red cuando QoS está siendo puesto en práctica.

El SAA puede supervisar mucha métrica, de la capa IP a la capa de aplicación, como sigue: Ø

Interpretación de transferencia de archivo para el Protocolo de Transferencia de Archivos (FTP)

Ø

Disponibilidad de sitio Web y tiempo de respuesta, usando el Protocolo de Transferencia de Hipertexto (HTTP)

Ø

Interpretación de UDP como tardanza de ida y vuelta, inquietud, latencia de dirección única, y pérdida de paquete

Ø

Medidas de salto por salto usando la operación de Eco de Camino ICMP

Resumen Uno de sus objetivos como diseñador de red debería ayudar a su cliente a desarrollar algunas estrategias y procesos para poner en práctica la dirección de red. Usted también debería ayudar a su cliente a escoger los instrumentos y productos a poner en práctica las estrategias y procesos.

Esta Fase II proporcionó la información para ayudarle a seleccionar los procesos correctos e instrumentos para encontrar los objetivos de un cliente para la manejabilidad de red. Las tareas implicadas con la dirección diseñan tareas paralela implicadas con el diseño de red total: análisis de requerimientos y objetivos, fabricación de restricciones,

Marcos Huerta S.

209


caracterización de flujo de tráfico de dirección de red, y desarrollo de una topología apropiada.

La administración a menudo es pasada por alto durante el diseño de una red porque es considerado una cuestión operacional más bien que una cuestión de diseño. Sin embargo, considerando la administración de red, en vez de clavarlo con tachuelas al final de proceso de diseño o después de que la red es operacional, su diseño será más escalable y robusto.

Fase III: Diseño de la red física Seleccion de Tecnología y Dispositivos de Red de Campus El diseño de red físico implica la selección de la tecnologia LAN y WAN para campus y empresarial. Durante esta fase del proceso de diseño de red top down, las opciones son hechas en cuanto a tendido de cables, físico y protocolos de capa de enlace de datos, y dispositivos de funcionamiento entre redes (como hubs, switches, routers, y puntos de acceso inalámbricos). Un diseño lógico, que cubre laParte II, "El diseño de Red Lógico," forma la fundación para un diseño físico. Además, los objetivos comerciales, los requerimientos técnicos, caracteristicas de trafico de red, y flujos de tráfico, se hablaron en toda la Parte I, "Identificando Necesidades de Su Cliente y Objetivos," que influyen en un diseño físico.

Un diseñador de red tiene muchas opciones para LAN y WAN. Ninguna tecnología sola o dispositivo estan con capacidad de responder todas las circunstancias. El objetivo de La parte III debe darle la información sobre la escalabilidad, performance, accesibilidad financiera, y características de manejabilidad de opciones típicas, ayudarle a hacer las correctas selecciones para su cliente.

Este capítulo cubre tecnologías para diseños de red de campus. Una red de campus es un juego de segmentos de LAN y redes de construcción en un área que tiene unas millas de diámetro. El siguiente capítulo cubre tecnologías para una red de empresa que incluye WAN y servicios de acceso remoto.

Un proceso de diseño eficaz debe desarrollar soluciones de campus primero, seguido de acceso remoto y soluciones WAN. Después de que usted ha diseñado las redes de campus de un cliente, usted puede seleccionar más con eficacia la WAN y tecnologías de acceso remoto basadas en el ancho de banda y las exigencias de requerimiento de tráfico que fluye de un campus al otro.

Este capítulo comienza con una discusión del diseño de tendido de planta de cables de LAN, incluso el tendido de cables de opciones para redes de campus y edificio. El Marcos Huerta S.

210


capítulo entonces proporciona la información sobre tecnologías de LAN como Ethernet y Modo de Transferencia Asincrónico (ATM). La sección " Seleccion de Tecnología y Dispositivos de Red de Campus" proporciona algunos criterios de selección que usted puede usar seleccionando hubs, switches, routers, y puntos de acceso inalámbricos para un diseño de campus.

Diseño del Cableado LAN Como el tendido de cables es más una cuestión de realización que una cuestión de diseño, no es cubierto detalladamente en este libro. Sin embargo, la importancia de desarrollar una infraestructura de tendido de cables buena no debería ser rebajada.

Mientras que otros componentes de un diseño de red generalmente tienen una vida de unos años antes de que los cambios de tecnología, la infraestructura de tendido de cables a menudo debiera durar durante muchos años. Es importante diseñar y poner en práctica la infraestructura de tendido de cables con cuidado, teniendo presente disponibilidad y objetivos de escalabilidad, y la vida esperada del diseño.

En muchos casos, su diseño de red debe adaptarse al tendido de cables existente. El capítulo 3, "Caracterizando las Redes Existentes," se habla del proceso para documentar el tendido de cables ya en uso en un edificio y redes de campus, incluso lo siguiente: ü

Topologias de tendido de cableado de Campus y Empresarial.

ü

Los tipos y longitudes de cableado entre edificios.

ü

La posición de armarios de telecomunicaciones e interconecta cuartos dentro de edificios.

ü

Los tipos y longitudes de cables para tendido de cableado vertical.

ü

Los tipos y longitudes de cables para tendido de cableado horizontal.

ü

Los tipos y longitudes de cables para tendido de cableado de área de trabajo que va de armarios de telecomunicaciones a estaciones de trabajo.

Topologia de Cableado Las compañías como AT&T, la IBM, Digital Equipment (DEC), Hewlett-Packard, y Telecomunicaciones del Norte han publicado todas especificaciones de tendido de cables y pautas para desarrollar una topología de tendido de cables. Además, la Asociación

de

Industria

de

Electrónica

y

la

Asociación

de

Industria

de

Telecomunicaciones publican las pautas EIA/TIA para el par trenzado no blindado (UTP) de tendido de cables e instalación.

Marcos Huerta S.

211


Aunque las pautas de las organizaciones diferentes se diferencien ligeramente, el objetivo principal de todos ellos es ayudar a un ingeniero de red a desarrollar un sistema de tendido de cables estructurado que es manejable y escalable.

Sin entrar en detalle contra la topologia de tendido de cables, una generalización puede ser hecha de esto dos tipos de esquemas de cableado que son posibles: ü

Un esquema de cableado centralizado es mas popular de todas las carreras de cableado en un área de ambiente de diseño. Una topología de estrella es un ejemplo de un sistema centralizado.

ü

Un esquema de tendido de cables distribuido es mas popular de todas las carreras de cableado en un área de ambiente de diseño. El anillo, el bus, y las topologías de árbol son ejemplos de sistemas distribuidos.

Topologías de cableado de edificio Dentro de un edificio, una arquitectura centralizada o distribuida puede ser usada, según el tamaño del edificio. Para pequeños edificios, es posible un esquema centralizado con todos los cables que terminan en un cuarto de comunicaciones, como mostrado en el lado izquierdo de La figura 10-1. Un esquema centralizado ofrece la manejabilidad buena, pero no escala. Para edificios más grandes, una topología distribuida es más apropiada. Muchas tecnologías de LAN hacen una asunción que las estaciones de trabajo son no más de 100 metros de un armario de telecomunicaciones donde los hubs o los switches residen. Por esta razón, en edificio altos y grandes, una topología distribuida es más apropiada, como mostrado en el lado derecho de La figura 10-1.

Marcos Huerta S.

212


La figura 10-1. Ejemplos de Topologías Centralizadas y Distribuidas de cableado de edificios

Topologías de cableado-campus El tendido de cableado que une edificios es expuesto a más riesgos físicos que el tendido de cables dentro de edificios. Un obrero de la construcción podría cavar una zanja entre edificios y por descuido cortar el cableado. La inundación, las tormentas de hielo, los terremotos y otros catástrofes también pueden causar problemas, como pueden los desastres artificiales como ataques terroristas. Además, los cables podrían cruzar propiedades fuera del control de la organización, haciéndolo dificil de encontrar la falla y reparar el problema. Por estos motivos, el cableado y las topologías de tendido de cables deberían ser seleccionados con cuidado.

Un esquema distribuido ofrece la mejor disponibilidad que un esquema centralizado. La parte superior de La figura 10-2 muestra una topología centralizada. La parte de fondo de La figura 10-2 muestra una topología distribuida. La topología centralizada en La figura 10-2 experimentaría una pérdida de toda la comunicación de interedificio si el bulto de cable entre Edificios A y B fuera cortado. Con la topología distribuida, interconstruyendo la comunicación podría continuar si un cable cortó entre Edificios A y B ocurrió.

Marcos Huerta S.

213


La figura 10-2. Ejemplos de Topologías Centralizadas y Distribuidas de Cableado de Campus

En algunos ambientes, debido a la prioridad resulta con obstrucciones ambientales como rios o pantanos, no podría ser práctico tener conductos de cable múltiples en el campus, como mostrado en la topología en la parte de fondo de La figura 10-2. En este caso, usted puede recomendar una tecnología inalámbrica (por ejemplo, láser, lmicroonda, o 802.11 enlace puente entre Edificios A y D).

Una desventaja de un esquema distribuido es que el manejo puede ser más difícil que con un esquema centralizado. Los cambios en un sistema de tendido de cables distribuido con mayor probabilidad requerirán que un técnico camine de edificio a edificio para implementar los cambios. La disponibilidad contra objetivos de manejabilidad debe ser considerada.

Tipos de Cables Tres tipos principales de cables son usados en la implementación de red de campus: ü

El cable de cobre protegido, incluso el par trenzado protegido (STP), coaxial (coax), y gemelo-axial (twinax) cables.

Marcos Huerta S.

214


ü

El cable de Cobre no protegido (típicamente UTP).

ü

Cables de Fibra Óptica.

El tendido de cables de STP fue extensamente usado en redes de Token Ring en los años 1980 y años 1990. La Mayor parte de redes de Token Ring han sido sustituidas por redes de Ethernet estos días. Ethernet generalmente usa UTP y el tendido de cables de fibra óptica, aunque sea posible hacer que trabaje Ethernet en el tendido de cables de STP. (El hecho que Ethernet puede correr con el tendido de cables de STP puede aliviar la migración del Token Ring a Ethernet para cualquier instalación que ha estado poco dispuesta a emigrar debido a la necesidad percibida de recablear de nuevo la red.)

El cable coax era popular en las primeras LANs. Ethernet gruesa (10BASE5) usa una doble-protección, 50 ohmios el cable coax que era aproximadamente 0.4 pulgadas de diámetro, y Ethernet delgada (10BASE2 o "Cheapernet") cable de RG-58 estándar usado que era aproximadamente la mitad aquel tamaño. 75 ohmios usados en terminales de IBM el cable coax, o, en algunos casos, twinax cables. El tendido de cables era por lo general instalado en una topología de bus y era difícil de poder hacer gramdes instalaciones sin repetidores de multipuerto. Con la introducción de estándares para dirigir protocolos de LAN en cables UTP (como Ethernet 10BASE-T), el cable coax se hizo menos popular. Coax y otros tipos del tendido de cables de cobre protegido no son generalmente recomendados para nuevas instalaciones, excepto quizás para cable cortos entre dispositivos en un armario de telecomunicaciones o cuarto de computadora, o en casos donde la seguridad específica y las necesidades protección existen.

El UTP es el cableado típico encontrado en la mayor parte de edificios estos días. Es generalmente lo mas barato de los tres tipos de cables. Este también tiene las capacidades de transmisión más bajas porque es sujeto a diafonía, ruido, e interferencia electromagnética. La adhesión para distancias limitadas minimiza los efectos de estos problemas.

Hay numerosas categorías del tendido de cables de UTP, incluyendo los siguientes: ü

La categoría 1 y 2 no es recomendada para transmisiones de información debido a su carencia del apoyo a exigencias de ancho de banda altas.

ü

La categoría 3 es probada a 16 MHz. La categoría 3 a menudo es llamada el tendido de cables de grado de voz, pero es usado para la transmisión de información también, en particular es antigua Ethernet 10BASE-T y redes de Token Ring 4-Mbps.

Marcos Huerta S.

215


ü

La categoría 4 es probada en 20 MHz, permitiéndolo dirigir el Token Ring 16-Mbps con un mejor margen de seguridad que la Categoría 3. La categoría 4 no es común, habiendo sido hecho obsoleto por la Categoría 5.

ü

La categoría 5 es probada en 100 MHz, permitiéndolo correr protocolos rápidos como Ethernet 100-Mbps y FDDI. Cuando cuatro pares son usados, Categoría 5 soporta Gigabit Ethernet.

ü

La categoría 5 mejorada (Categoría 5e) es conveniente para Ethernet 100-Mbps, Gigabit Ethernet, y ATM. Muchas compañías venden la Categoría de 350 MHz 5e cableado, aunque el estándar para el tendido de cables (Apéndice 5 a TIA/EIA-568A) declare 100 MHz.

ü

La categoría 6 es conveniente para Ethernet 100-Mbps, Gigabit Ethernet, y ATM. El estándar para el tendido de cables (ANSI/TIA/EIA-568-B.2-1) declara 200 MHz, aunque los vendedores apoyen ancho de banda más altas.

Las nuevas instalaciones deberían correr como mínimo la Categoría 5e. Aunque la Categoría 5e cueste un poco más que la Categoría 5, lo merece. Desde esta escritura, El cableado de Categoría 6 no es extensamente desplegado, pero puede ser pronto. La Asociación de Industria de Telecomunicaciones (TIA) recomienda que la Categoría 6 debe ser instalado para apoyar futuras aplicaciones que exigirán la ancho de banda alta. La categoría 6 mejora características de performance como la pérdida de introducción, diafonía de extremo cercano (NEXT), pérdida de retorno, y el nivel igual lejos termina la diafonía (ELFEXT). Estos realces proporcionan una relación señal/ruido más alta.

Los cables de fibra óptica se hacen rápidamente un estándar para nuevas instalaciones. Como los precios para cables y conexiones de dispositivos de unión, se hace práctico instalar el tendido de cables de fibra óptica para el cableado vertical y horizontal entre armarios de telecomunicaciones. Algunas compañías también usan el tendido de cables de fibra óptica para el cableado de área de trabajo, pero el coste de las trajetas de interfaz de red (NICs) con el soporte de fibra óptica es todavía alto, de modo que no es común aún. El cableado de fibra óptica ha sido usado entre edificios durante muchos años.

El cableado de fibra óptica no es afectado por diafonía, ruido, e interferencia electromagnética, entonces esto tiene la capacidad más alta de los tres tipos de cables. Con las nuevas tecnologías, como la multiplexión de división de onda (WDM), un hilo solo del cableado de fibra óptica puede manejar una capacidad de 40 gigabits por segundo y más allá.

Una desventaja con el cableado de fibra óptica es que puede ser difícil instalar, que puede añadir un alto costo de despliegue. Cuando conecte una fuente optica de fibra o

Marcos Huerta S.

216


cuando dos o mas fibras se juntan, hasta una pequeña desviación de la posición ideal del conector puede causar mala alineación y la pérdida de señal inaceptable. Algunos conectores introducen más pérdida que otros. Seleccionando conectores, investigue su facilidad del uso y el decibelio (dB) pérdida asociada con los conectores.

Los conectores de fibra óptica también pueden introducir el ruido de reflexión reflejando la luz atrás en la fuente óptica. El ruido de reflexión es reducido por el índice que empareja geles, el contacto físico pule las capas de antireflexión. Cuando seleccione conectores, el ruido de reflexión es de los parámetro que usted debería investigar.

El cableado de fibra óptico es monomodo o multimodo. "Un modo" significa un camino aceptable para la luz para viajar abajo una fibra. Con la fibra de multimodo, hay modos múltiples o caminos que la luz puede seguir. Algunos caminos son más largos que otros, el que significa que el tiempo que esto toma para la luz para viajar abajo cada camino se diferencia, causando la dispersión intermodal de la luz cuando esto sale el cable de fibra. La dispersión intermodal limita el ancho de banda de multimodo.

La fibra de monomodo tiene un diámetro principal más pequeño que la fibra de multimodo. El pequeño core asegura que sólo un camino es tomado que elimina la dispersión intermodal y significa que la fibra de monomodo soporta altos ancho de banda sobre distancias más largas que la fibra de multimodo. El diámetro más pequeño hace más difícil de conectar la fuente óptica suficiente en la fibra, sin embargo, que añade un costo de fabricación e instalación de conectores. Los interfaces de monomodo para switches, routers de tráfico, y estaciones de trabajo son también más caros que interfaces de multimodo.

Tecnologia LAN Esta sección cubre tecnologías de capa de enlace de datos que están disponibles para LANs. Recomiendan a Ethernet para la mayor parte de redes de campus porque esto proporciona la escalabilidad superior, la manejabilidad, y la accesibilidad financiera. ATM es también escalable, pero es más complejo y caro que Ethernet y más difícil de configurar y manejar. Sin embargo, el ATM es apropiado para algunos diseños de red de campus debido a sus métodos deterministas para proporcionar la calidad del servicio (QoS). Aunque unos vendedores vendan productos de Token Ring 100-Mbps, hay muchas opciones de producto para alta-velocidad Ethernet comparada con alta-velocidad Token Ring. Había también la conversación hace unos años sobre FDDI de la nueva generación que soportaria velocidades de gigabits por segundo (Gbps), pero la conversación nunca materializada en estándares o productos. Aunque Token Ring y las

Marcos Huerta S.

217


instalaciones FDDI todavía existan, Ethernet es más escalable y manejable que el Token Ring o FDDI y debería ser recomendada para nuevos diseños de red y mejoras. Cuando un nuevo diseño de red debe combinarse con un diseño existente, que es el caso para la mayor parte de diseños de red, las tecnologías más viejas deben ser consideradas. Por ejemplo, un cliente podría indicar que un nuevo diseño debe aprovechar la existencia de concentradores FDDI en redes de backbone de edificio para evitar gastar el dinero para un nuevo equipo. Sin embargo, como un diseñador de red, usted debería animar a sus clientes a mejorar de tecnologías más viejas que se harán más difíciles de apoyar cuando los productos se hacen menos disponibles. El capítulo 1, "Analizando Objetivos Comerciales y Restricciones," el análisis de las restricciones comerciales siguientes, todo de las cuales tiene un efecto en las tecnologías LAN que usted debería recomendar: •

Tendencias (religión de tecnología).

•

Políticas en cuanto a tecnologías aprobadas o vendedores.

•

La tolerancia del cliente para arriesgar.

•

Maestría técnica del personal y proyectos para educación de personal.

•

Elaboración de un presupuesto y programación.

Los objetivos técnicos, hablado en El capítulo 2, "Analizando Objetivos Técnicos y Restricciones," también tienen un impacto grande en selecciones de tecnología. Las siguientes secciones de este capítulo se manifiestan aquellas tecnologías de LAN varían en como bien ellos pueden encontrar escalabilidad, disponibilidad, manejabilidad, adaptabilidad, accesibilidad financiera, y otros objetivos técnicos. El capítulo 2 recomendó por hacer una lista de los objetivos técnicos principales de un cliente. En este punto en el proceso de diseño, usted debería referirse a aquella lista para asegurarse que sus selecciones de tecnología son apropiadas para su cliente de diseño de red. Usted también debería mirar a la Tabla 2-3, "las Aplicaciones de Red Exigencias Técnicas," determinar si su cliente tiene exigencias estrictas en cuanto a rendimiento, tardanza, y variación de tardanza para alguna aplicación de red. Usted también debería considerar los tipos de aplicaciones que el cliente planea dirigir en la red. Las aplicaciones que permiten que usuarios compartan imágenes, archivos animados, videos, etcétera, son más ancho de banda y la tardanza sensible que aplicaciones a base de texto. La tabla 4-4, "las Características de Tráfico de Aplicaciones de Red," también pueden ayudarle a seleccionar las tecnologías correcta para su cliente. En aquella tabla Marcos Huerta S.

218


usted documentó ancho de banda y requerimientos de QoS para aplicaciones. Las siguientes secciones le ayudarán a determinar qué soluciones son apropiadas para aplicaciones con los requerimientos de ancho de banda y requerimientos de QoS. Ethernet Ethernet es de la capa física y la capa de enlace de datos para la transmisión de frames en un LAN. Desde su invención en los años 1970 por la Corporación de Xerox, Ethernet ha ganado la popularidad extendida y se ha adaptado a nuevas demandas de capacidad, fiabilidad, y precios bajos. El costo de un puerto de Ethernet en una estación de trabajo o dispositivo de redes es muy bajo comparado a otras tecnologías. Muchos ordenadores personales y los vendedores de estación de trabajo incorporan Ethernet en la placa madre de la computadora de modo que no sea necesario comprar NIC separado. Ethernet es una opción de tecnología apropiada para clientes preocupados por disponibilidad y manejabilidad. Un LAN de Ethernet que es exactamente aprovisionado para encontrar requerimientos de ancho de banda y equipado con componentes de alta calidad, incluso NICs, cables, y dispositivos de funcionamiento entre redes, puede encontrar hasta las demandas más rigurosas de la disponibilidad. Muchos instrumentos de solución, incluso probadores de cable, analizadores de protocolo, y aplicaciones de dirección de red, están disponibles para aislar los problemas ocasionales causados por rupturas de cable, interferencia electromagnética, puertos malogrados, o fallas de NICs. Ethernet y IEEE 802.3 DEC, Intel, y Xerox publicaron la Versión 2.0 de la especificación de Ethernet en 1982. La versión 2.0, también conocida como el Estándar de DIX o Ethernet II, forma la base para el trabajo que el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) hizo en el estandar 802.3, que fue finalizado en 1983. Desde entonces, 802.3 ha evolucionado para soportar UTP y cableado de fibra óptica, y velocidades de transmisión más rápidas. Aunque haya algunas diferencias menores entre las dos tecnologías, los términos Ethernet y 802.3 son generalmente usados sinónimamente. En la capa física, 802.3 es el de facto estándar. En la capa de enlace de datos, ambas realizaciones de la Versión 2.0 y 802.3 de Ethernet son comunes.

Marcos Huerta S.

219


Figura 10-3. Ethernet Version 2.0 y IEEE 802.3 Formato Frame

Opciones de Tecnología de Ethernet Ethernet es una tecnología escalable que se ha adaptado a requerimientos de capacidad crecientes. Las opciones siguientes para poner en práctica redes de Ethernet están disponibles: •

Half - y dúplex total Ethernet

•

10-Mbps Ethernet.

•

100-Mbps Ethernet.

•

1000-Mbps (1-Gbps o Gigabit) Ethernet.

•

10-Gbps Ethernet.

•

Metro Ethernet.

•

Ethernet del alcance largo (LRE).

•

Cisco EtherChannel.

Cada una de estas tecnologías es una posibilidad para el acceso, distribución, o capas principales de una topología de campus, aunque por lo general las velocidades más altas, como Gigabit Ethernet, sean reservadas para la capa core. La opción de una tecnología de Ethernet para la capa de acceso depende de la posición y el tamaño de comunidades de usuario, ancho de banda y requerimientos de QoS para aplicaciones, broadcast y otro comportamiento de protocolo, y flujo de tráfico, hablado en El capítulo 4, "Caracterización de Tráfico de Red." La opción de una tecnología de Ethernet para la capa de distribución y capa core depende de la topología de red, la posición de almacen de datos, y flujo de tráfico.

Marcos Huerta S.

220


Half-Duplex y Full-Duplex Ethernet Ethernet fue al principio definida para un medio compartido con estaciones usando el sentido de portador de descubrimiento de acceso/colisión múltiple (CSMA/CD) algoritmo para regular el envío de frames y el descubrimiento de colisiones cuando dos estaciones envían al mismo tiempo. Con Ethernet compartida, una estación escucha antes de que esto envíe datos. Si el medio está ya en el uso, la estación aplaza su transmisión hasta que el medio sea libre. Ethernet compartida es half duplex, en el sentido que una estación transmite u o recibe el tráfico, pero no ambos inmediatamente. Un Ethernet de punto a punto soporta simultaneamente la transmisión y la recepción, lo cual es llamada full dúplex Ethernet. En un enlace entre un puerto de switch y una estación sola, por ejemplo, tanto el switch como la estación pueden transmitir al mismo tiempo. Este es sobre todo beneficioso si la estación es un servidor que trata peticiones de muchos usuarios. El switch puede transmitir la siguiente petición al mismo tiempo el servidor envía una respuesta a una petición anterior. La operación de full dúplex es también común en enlaces de switch a switch, permitiendo a ambos switches transmitir el uno al otro al mismo tiempo. La ventaja de full dúplex Ethernet es que el precio de transmisión es teóricamente doble lo que es en un enlace half duplex. 10-Mbps Ethernet Aunque Ethernet 100-Mbps comience a sustituir Ethernet 10-Mbps, Ethernet 10-Mbps todavía puede desempeñar un papel en su diseño de red, en particular en la capa de acceso. Para algunos clientes la capacidad 10-Mbps es suficiente. Para clientes que tienen necesidades de amplitud de banda bajas y un pequeño presupuesto, Ethernet 10Mbps es una solución apropiada si la red no tiene que escalar a 100-Mbps en el futuro próximo. NOTA: Muchas aplicaciones comerciales no se benefician de una mejora a Ethernet compartida 100-Mbps. Las aplicaciones ineficaces que envían muchos pequeños marcos generan más colisiones en Ethernet 100-Mbps, realmente disminuyendo el rendimiento. Las pruebas han mostrado una disminución del 9 por ciento en el rendimiento cuando un LAN con aplicaciones ineficaces fue emigrado de Ethernet 10-Mbps compartida a Ethernet 100-Mbps compartida. De ser 100-Mbps es requerido en la capa de acceso, entonces el dúplex total, cambiado Ethernet 100-Mbps debería ser desplegado.

Marcos Huerta S.

221


Ethernet 10-Mbps puede correr en lisonjean, UTP, o tendido de cables óptico de fibra. (Lisonjee el cable es raramente usado más). Ethernet 10-Mbps apoya tanto redes cambiadas como compartidas. En una red compartida, todos los dispositivos compiten por la misma amplitud de banda y están en el mismo esfera de amplitud de banda (también conocido como el Esfera de colisión de Ethernet). Los repetidores de capa físicos y los cubos unen cables y usuarios, pero no segmentan la esfera de colisión. Un interruptor, por otra parte, segmenta una esfera de colisión en esferas múltiples. Cada puerto en un interruptor define una esfera. La decisión si hay que usar arquitecturas compartidas o cambiadas depende de amplitud de banda y exigencias de interpretación y limitaciones de distancia. Una de las reglas de diseño más significativas para Ethernet es que la tardanza de propagación de ida y vuelta de una esfera de colisión no debe exceder el tiempo esto toma a un remitente para transmitir 512 trozos, que es 51.2 microsegundos para Ethernet 10-Mbps. Una esfera de colisión sola debe ser limitada en el tamaño para asegurarse que una estación que envía a un marco mínimo clasificado (64 bytes o 512 trozos) puede descubrir una colisión que refleja atrás del lado opuesto de la red mientras la estación todavía envía el marco. Por otra parte, la estación sería terminada enviando y no escuchando para una colisión, así perdiendo la eficacia de Ethernet para descubrir una colisión y rápidamente transmitir de nuevo el marco. Para encontrar esta regla, la distancia más apartada entre dos sistemas de comunicación debe ser limitada. El número de repetidores (cubos) entre los sistemas también debe ser limitado, porque los repetidores añaden la tardanza. Las limitaciones para Ethernet 10-Mbps en lisonjean y tendido de cables de UTP son mostrado en Mesa 10-1. Las limitaciones para Ethernet 10-Mbps en el multimodo tendido de cables óptico de fibra son mostradas en Mesa 10-2.

Marcos Huerta S.

222


Tabla 10-1. Restricciones de Escalabilidad para 10-Mbps Coax y Ethernet UTP 10BASE5

10BASE2

10BASE-T

Topologia

Bus

Bus

Estrella

Tipo de cableado

Thick coax

Thin coax

UTP

Longitud de cable

500

185

100 de hub a estación

100

30

2 (hub y estación o

máxima (en metros) Número máximo de accesorios por

hub y hub)

cable Dominio de colisión

2500

2500

2500

Topología máxima

5 segmentos, 4

5 segmentos, 4

5 segmentos, 4

de un dominio de

repetidores, sólo 3



colisión

segmentos pueden

segmentos pueden

segmentos pueden

tener sistemas de final



máxima (en metros)

Tabla 10-2. Restricciones de Escalabilidad para Multimodo 10-Mbps Ethernet Fibra Optica 10BASE-

10BASE-FB

10BASE-FL

Old FOIRL

Backbone o

Enlace de

Enlace de

sistema de

repetidor-

repetidor-

repetidor

repetidor

repetidor

FP Topología

Estrella

Longitud de cable máxima

500

2000

2000

1000

Sí

No

No

No

No

Sí

No

No

2500

2500

2500

2500

(en metros) ¿Permite

uniones

de

sistema de final? ¿Permite repetidores

en

cascada? Dominio colisión

de máxima

(en metros)

Marcos Huerta S.

223


La especificación original para correr Ethernet en el multimodo cable de fibra óptica fue llamada especificación de Enlace de Inter-repetidor de fibra optica (FOIRL). El nuevo 10BASE-F especificación está basado en la especificación FOIRL. Esto incluye 10BASE-FP, 10BASE-FB, 10BASE-FL, y un estándar FOIRL revisado. Nuevo FOIRL se diferencia del viejo en el cual esto permite uniones de sistema finales además de repetidores y hub. Tabla 10-2 restricciones de escalabilidad de espectáculos para dirigir 10-Mbps en cableado multimodo de cables de fibra óptica. 100-Mbps Ethernet Ethernet 100-Mbps, también conocida como Fast Ethernet y 100BASE-T Ethernet, fue al principio estandarizada en el IEEE 802.3u especificación y es combinada ahora en la edición 2002 de IEEE 802.3. Es muy similar a Ethernet 10-Mbps, que es uno de los motivos de su popularidad. Ya que los ingenieros de red quiénes tienen la experiencia con Ethernet 10-Mbps, Ethernet 100-Mbps es fácil para entender, instalar, configurar, y reparar. Con algunas excepciones, Ethernet 100-Mbps es Ethernet estándar, sólo 10 veces más rápido. En la mayor parte de casos, los parámetros de diseño para Ethernet 100-Mbps son el mismo como Ethernet 10-Mbps, sólo multiplicada o dividida en 10.

Ethernet 100-Mbps es definida para cuatro implementaciones físicas: ü

100BASE-TX. Dos pares de Categoría 5 (o mejor) cableado UTP

ü

100BASE-T2. Dos pares de Categoría 3 (o mejor) cableado UTP

ü

100BASE-T4. Cuatro pares de Categoría 3 (o mejor) cableado UTP

ü

100BASE-FX. Dos multimodo fibras ópticas

El 100BASE-TX es la forma más popular de Ethernet 100-Mbps. Las redes de 100BASE-TX son fáciles para diseñar e instalar porque ellos usan el mismo par de cables y fijan configuraciones que 10BASE-T. Las estaciones están conectados con repetidores (hubs) o switches usando la Categoría 5, Categoría 5e, o Categoría 6 de cableado UTP.

El IEEE diseñó 100BASE-T4 para manejar la base instalada grande de la Categoría 3 de cableado. El 100BASE-T4 usa cuatro pares (ocho hilos) de la Categoría 3, 4, o 5 cables. El 100BASE-T4 envía una señal en tres pares de hilos y usa el cuarto par para el descubrimiento de colisión. Después de liberar 100BASE-T4, IEEE liberó 100BASET2, que usa un método señalado más avanzado de modo que sólo dos pares de UTP sean requeridos. (100BASE-T4 usa la señalización de 8B/6T, mientras que 100BASE-T2 usa la Modulación de Amplitud de Pulso 5, o PAM 5.)

Marcos Huerta S.

224


NOTA: 100BASE-T4 requiere que cuatro pares (ocho alambres) esten conectados entre un hub y una estación. En alguna instalaciones de Categoría 3, sólo dos pares (cuatro hilos) unen hubs y estaciones, porque la infraestructura de tendido de cables fue diseñada para 10BASE-T, que sólo usa dos pares. Este hace difícil de usar 100BASE-T4 con el tendido de cables de existencia.

Como mencionado, la tardanza de propagación de ida y vuelta de un dominio de colisión de Ethernet no debe exceder el tiempo esto toma a un remitente para transmitir 512 bits, que es sólo 5.12 microsegundos en Ethernet 100-Mbps. Para hacer el trabajo de Ethernet 100-Mbps, hay limitaciones de distancia más severas que aquellos requeridos para Ethernet 10-Mbps. La regla general consiste en que Ethernet 100-Mbps tiene un diámetro máximo de 205 metros cuando use el tendido de cables de UTP, mientras que Ethernet 10-Mbps tiene un diámetro máximo de 2500 metros.

Las limitaciones de distancia para Ethernet 100-Mbps dependen del tipo de repetidores (hubs) que son usados. En el IEEE 100BASE-T especificación, dos tipos de repetidores son definidos: ü

La clase I repetidores tiene una latencia de 0.7 microsegundos o menos. Sólo un salto de repetidor es permitido.

ü

La clase II repetidores tiene una latencia de 0.46 microsegundos o menos. Un o dos saltos de repetidor son permitidos.

Tabla 10-3 muestra el tamaño máximo de un dominio de colisión para Ethernet 100Mbps dependiendo del tipo de repetidor (es) en uso y el tipo de cableado. Aunque no muestra en la tabla, la fibra de monomodo es también posible. Usted debería comprobar con repetidor y fabricantes de cableado para limitaciones de distancia exactas para la fibra de monomodo. La mayor parte de vendedores especifican que cuando la fibra de monomodo es usada en una unión de full dúplex de switch a switch, la longitud de cable máximo es 10,000 metros o aproximadamente 6 millas. El hecho que una distancia tan larga es permitida hace la fibra de monomodo atractiva (aunque caro) para las redes de campus grandes.

Marcos Huerta S.

225


Tabla 10-3. Domino de Colisión Máximas para Ethernet 100BASE-T

Cobre

Fibra de Multimodo y Cobre Variada

Fibra de Multimodo

DTE-DTE (o switch a switch)

100 metros

NA

412 metros (2000 si dúplex total)

Una Clase I repetidor

200 metros

260 metros

272 metros

Una Clase II repetidor

200 metros

308 metros

320 metros

Dos Clase II repetidores

205 metros

216 metros

228 metros

NOTA: Las especificaciones IEEE acerca de Clase I y Clase II repetidores 100-Mbps no son relevantes para muchos diseños de red. Un diseño típico debe unir cada dispositivo a un puerto de switch y no usar a repetidores (o hubs). Estos días, es difícil comprar a un repetidor 100-Mbps o el hub, aun si usted quisiera hacerlo. La mayor parte de vendedores venden switches que dividen dominio de colisión. Incluso cuando un hub o el repetidor son usados, esto es por lo general el único repetidor en el dominio de colisión, entonces las preocupaciones por la reducción al mínimo de saltos de repetidor a fin de minimizar colisiones son irrelevantes.

Gigabit Ethernet

Gigabit Ethernet fue al principio definido en el estandar IEEE 802.3z y es combinado ahora en la edición 2002 de IEEE 802.3. Esto funciona esencialmente como Ethernet 100-Mbps, salvo que es 10 veces más rápido. Esto usa CSMA/CD con el soporta a un repetidor por dominio de colisión, y se maneja tanto half - como full dúplex. Esto usa el estandar 802.3 formato de frame y el tamaño de frame.

Para evitar la necesidad de reducir el tamaño de half-duplex Gigabit de redes de 1/10th el tamaño de una red de Ethernet 100-Mbps, Gigabit Ethernet incluye algunos cambios menores en la capa MAC. Es provechoso comparar los cambios de estándares hechos cuando ellos fueron introducidos 100-Mbps Ethernet en los cambios ellos hicieron cuando ellos presentaron Ethernet Gigabit.

Con half-duplex 10- y 100-Mbps Ethernet, el tamaño de frame mínimo es igual a la tardanza de propagación de ida y vuelta máxima de la red (menos una concesión para

Marcos Huerta S.

226


sobrelleno, sincronización, etcétera). Para asegurar que un remitente todavía envía si una colisión ocurre en el lado opuesto de la red más grande posible, un remitente debe llamar al tiempo esto toma 512 bits (64 bytes) para viajar al lado opuesto de la red y regresar. Este asegura que el envío Ethernet NIC reconocerá la colisión, regresara, y transmitirá de nuevo.

Para asegurar que el reconocimiento de colisión trabaja correctamente en 100-Mbps Ethernet, donde los remitentes pueden enviar 10 veces tan rápido como ellos pueden con Ethernet 10-Mbps, los estandares desarrollados redujeron el tamaño de red máximo a aproximadamente 1/10th el tamaño máximo para 10-Mbps Ethernet. La utilización de tal acercamiento con Ethernet Gigabit half-duplex habría causado pequeñas redes impracticables sin embargo. En cambio, el frame mínimo es mantenido en 512 bits (64 bytes), pero se requiere que el remitente llame al tiempo esto toma 4096 bits (512 bytes) para viajar al lado opuesto de la red y regresar.

Los frame que son más cortos que 4096 bits son artificialmente ampliados añadiendo un campo de extensión de portador de modo que los frame sean exactamente 4096 bits en la longitud. Los contenido del campo de extensión de portador son símbolos de no datos. Aumentando el tiempo mínimo una estación envía, los estándares pueden apoyar una topología de red máxima más grande.

La extensión de portador podría causar la degradación de performance para algunas aplicaciones, aunque los desarroladores incluyeran un workaround en los estándares para evitar problemas. Considere una aplicación que intenta a la salida muchos pequeños frame en un rate rápido, por ejemplo una aplicación de voz sobre IP (VoIP). ¿Si el interfaz añade bits para alcanzar 4096 bits, será capaz la aplicación de enviar en el rate apropiado? ¿Cuándo la aplicación es terminada y libera el control del medio, va otro aplicación

salta havia adentro, haciendo la primera aplicación aplazar? Los

diseñadores de Ethernet Gigabit se dirigieron a estos problemas permitiendo a un remitente enviar frames múltiples.

Una estación de Ethernet Gigabit puede decidir reventar frames si hay un frame en su transmisión de cola cuando esto ha terminado de enviar su primer frame (más la extensión, si uno fuera necesario). La estación puede enviar otra vez sin competir por el uso del canal. Durante el hueco de interframe, la estación envía símbolos de no datos. Sólo el primer frame requiere una extensión de portador. La estación puede comenzar la transmisión de frame para hasta un burstLength. El IEEE define el parámetro burstLength como 8192 bytes.

Marcos Huerta S.

227


El Gigabit Ethernet es la mayor parte apropiado para edificio y redes de backbone de campus. Esto puede actuar como una red de tronco, teóricamente agregando el tráfico de hasta diez segmentos de 100-Mbps Ethernet. A pesar de la extensión de portador y las caracteristicas de la half-duplex Ethernet, Gigabit Ethernet por lo general usa el modo de full-dúplex y une un switch a otro switch o un switch a un router de tráfico. Ethernet de Gigabit también es usada en servidores de alto rendimiento que requieren una cantidad grande de ancho de banda.

El estándar 802.3 para Ethernet Gigabit especifica el multimodo y el monomodo cableado de fibra óptico, cableado UTP, y blindado twinax cableado de cobre.Tabla 10-4 muestra las variaciones de Ethernet Gigabit.

Tabla 10-4. Especificaciones de Gigabit Ethernet 1000BASE-SX Tipo de cableado

Fibra de multimodo de longitud de onda de 850 nanómetros

Limitaciones de 220-550, según el distancia (en cable metros)

1000BASE-LX

1000BASE-CX

1000BASE-T

1300 multimodo de longitud de onda de nanómetro y fibra de monomodo

Twinax

UTP

550 para multimodo y 5000 para monomodo

25

100 entre un hub y estación; un diámetro de red total de 200 metros

El 1000BASE-SX, también conocido como la especificación de longitud de onda corta (de ahí el S del nombre), es apropiado para el cableado horizontal multimodo y redes de backbone. El 1000BASE-LX usa una longitud de onda más larga (de ahí el L del nombre), y soporta tanto el cableado de monomodo como multimodo. El 1000BASE-LX es apropiado para edificio y redes de backbone de campus. El 1000BASE-CX es apropiado para un armario de telecomunicaciones o cuarto de computadora donde la distancia entre dispositivos es 25 metros o menos. El 1000BASECX atropella 150 ohmios equilibrados, protegidos, twinax cable. El 1000BASE-T es requerido para horizontal y área de trabajo Categoria 5 o mejor cableado UTP. El 1000BASE-T soporta la transmisión más de cuatro pares del cable de UTP y cubre una distancia de tendido de cables de hasta 100 metros, o un diámetro de red de 200 metros. Sólo permiten a un repetidor. 10-Gbps Ethernet Uno de los motivos que Ethernet es una opción tan buena para diseños de red de campus es que esto sigue creciendo con demandas de ancho de banda crecientes. En

Marcos Huerta S.

228


2002, el IEEE estandarizó Ethernet 10-Gbps en la especificación 802.3ae. Ethernet 10Gbps se diferencia de algunos modos importantes de las otras realizaciones de Ethernet, pero es también notable que similar a las otras realizaciones. El formato de frame y otra especificaciones de Capa 2 permanecen el mismo lo que significa que las aplicaciones que usan Ethernet no tienen que cambiarse.

En el futuro próximo, Ethernet cumplirá con su nombre. (El nombre Ethernet viene del éther de término, el elemento enrarecido que los científicos antes creyeron llenó todo el espacio.) Ethernet estará en todas partes. Una transacción de Internet, por ejemplo, podría comenzar en un 100BASE-T a casa o red comercial, acercamiento a través de Ethernet metropolitana de fibra óptica hacia el ISP local, viaja Ethernet 10-Gbps WDM a un abastecedor más grande, y viaja a través de varios enlaces de Ethernet para alcanzar a un servidor de e-comercio que es amueblado por un Gigabit o Ethernet 10Gbps NIC. La transacción será encapsulada en un frame de Ethernet todo el tiempo entero.

Actualmente, los productos de Ethernet más 10-Gbps están en la forma de módulos o línea de tarjetas para switches de alta calidad y router, pero algunos vendedores también soportan interfaces de Ethernet 10-Gbps para servidores. Tanto el ISPs como las redes de empresa usan Ethernet 10-Gbps como una tecnología de backbone. Algunas redes de empresa también usan Ethernet 10-Gbps en granjas de servidor, redes de área de almacenaje (SANs), y estudios de vídeo digitales.

Ethernet 10-Gbps apoya la transmisión de full-dúplex sobre el tendido de cables fibra óptica. Esto no soporta el modo half-duplex o tendido de cables de cobre. Aplicaciones de LAN soportan 10-Gbps así como red de área metropolitana (MAN) y aplicaciones WAN. Cuando el cableado de fibra optica monomodo es usado, un enalce de Ethernet 10-Gbps puede extenderse en la distancia a 40 kilómetros (25 millas).

Como las otras realizaciones de Ethernet, Ethernet 10-Gbps soporta la transmisión consecutiva donde los bits son enviados uno tras otro, uno por uno en serie. Los expertos conectados a una red aprendieron hace mucho que la transmisión paralela (la parte de enfrente de la transmisión consecutiva) fue relegada a impresoras antiguas y protocolos de herencia a partir de los años 1970. ¡No más! La variedad 10GBASE-LX4 de Ethernet 10-Gbps simultáneamente lanza cuatro flujos de bit como cuatro longitudes de onda de la luz. Este es llamado la amplia multiplexión de división de longitud de onda, o WWDM, y es clasificado como un mecanismo de transmisión paralelo en IEEE 802.3ae.

Marcos Huerta S.

229


Además de 10GBASE-LX4, Ethernet 10-Gbps soporta 10GBASE-S, 10GBASE-L y 10GBASE-E, que usan la transmisión consecutiva. Tabla 10-5 mostramos las limitaciones de distancia para varias de 10-Gbps Ethernet, según la documentación Cisco. Tabla 10-5. Implementación de Ethernet 10-Gbps Longitud de Implementación onda Medio

Amplitud de Modal Mínima

banda Funcionamiento Distancia

10GBASE-LX4

1310 nm

62.5 •m 500 MHz/kilómetros MMF

2 ms a 300 ms

10GBASE-LX4

1310 nm

50 •m 400 MHz/kilómetros MMF

2 ms a 240 ms

10GBASE-LX4

1310 nm


2 ms a 300 ms

10GBASE-LX4

1310 nm

10 •m — SMF

2 kilómetros a 10 kilómetros

10GBASE-S

850 nm


2 ms a 26 ms

10GBASE-S

850 nm


2 ms a 33 ms

10GBASE-S

850 nm


2 ms a 66 ms

10GBASE-S

850 nm


2 ms a 82 ms

10GBASE-S

850 nm


2 ms a 300 ms

10GBASE-L

1310 nm

10 •m — SMF

2 kilómetros a 10 kilómetros

10GBASE-E

1550 nm

10 •m — SMF

2 kilómetros a 30 kilómetros[*]

de

[*] El estándar permite longitudes de 40 kilómetros si la atenuación del enlace es bastante baja. Metro Ethernet Metro Ethernet es un servicio ofrecido por abastecedores y portadores que tradicionalmente tenían sólo ofrecimientos WAN clásicos, como dialup, T1, y Frame Relay. Metro Ethernet mezcla las capacidades y el comportamiento de tecnologías WAN con aquellos de Ethernet. Los portadores ofrecen a Metro Ethernet a clientes que buscan un método rentable de interconectar redes de campus y tener acceso al Internet.

Una de muchas ventajas del Metro que Ethernet es que el cliente puede usar un estándar 10/100-Mbps interfaz de Ethernet, o un Gigabit o interfaz 10-Gbps, tener

Marcos Huerta S.

230


acceso a la red del abastecedor de servicio. El cliente puede establecer el recorrido virtual para alcanzar otros sitios y alcanzar un ISP. El metro Ethernet soporta una interfaz de cobre u fibra óptico, pero usa el tendido de cables de fibra óptico dentro de la red del abastecedor. Esto puede usar una variedad de protocolos de transporte, incluso SONET, ATM, multiplexión de división de onda de modo denso (DWDM), y Etiqueta de Multiprotocolo que Cambia (MPLS).

El metro abastecedores de servicio de Ethernet permite que suscriptores añadan el ancho de banda como necesario. Comparado a la adición del ancho de banda WAN, añadiendo el ancho de banda a un Metro el servicio de Ethernet puede pasar rápidamente, a veces tan rápidamente como unos minutos o horas. El metro abastecedores de Ethernet ofrece una amplia variedad de opciones de ancho de banda. Además de las velocidades de Ethernet estándares, muchos abastecedores ofrecen un servicio 1-Mbps y permiten que clientes añadan el ancho de banda en incrementos 1Mbps.

Algunas realizaciones de Metro Ethernet usan lo que es llamado Ethernet el recorrido virtual (EVC). En El capítulo 11, "Seleccionando Tecnologías y Dispositivos para Redes de Empresa," aprenderá usted sobre el Relevo de Frame el recorrido virtual permanente (PVCs). Un EVC usa el mismo concepto. Un EVC es una asociación de dos o más interfaces de red de usuario (UNIs), donde un UNI es un interfaz de Ethernet estándar en el sitio de un cliente. Dos tipos de EVCs son apoyados: punto a punto, y multipunto a multipunto. Hay también dos tipos de servicio básicos: ü

El servicio de línea de Ethernet (servicio de E-línea) proporciona un punto a punto EVC entre dos UNIs.

ü

El servicio de LAN de Ethernet (servicio de E-LAN) proporciona la conectividad de multipunto. Esto puede unir dos o más UNIs.

El metro Ethernet es una mezcla de WAN y tecnologías de LAN. Esto apoya el recorrido virtual como un WAN y también proporciona el apoyo a un rate de información comprometido (CIR), tamaño de estallido cometido, rate de información máximo (PIR), y el tamaño de estallido máximo, como un WAN a menudo hace. En una manera similar a un LAN, Metro Ethernet también apoya VLANs, 802.1X autenticación de puerto, y el Protocolo de Spanning Tree.

Metro Ethernet es usado para unir sitios de extranet e intranet. Los ISPs también comienzan a usar el Metro Ethernet. El ISP típicamente multiplexores suscriptores múltiples sobre Ethernet rápida UNI. El cliente de un ISP usa un EVC para unirse al punto local del ISP de la presencia (POP).

Marcos Huerta S.

231


El método más común para usar Metro Ethernet para el acceso de Internet dedicado es usar el servicio de E-línea. Si el cliente quiere usar mismo UNI para soporta tanto acceso de Internet como un intranet o unión extranet, este es también posible con el uso de EVCs separado. Un cliente también puede usar EVCs múltiple para tener acceso a ISPs múltiple por dedundancia, así la unión de Internet multihoming.

Metro Ethernet no se ha dado cuenta de un modo grande desde esta escritura, pero esto sostiene muchas promesas y probablemente se dará cuenta en una forma o el otro. Aunque pueda ser llamado algo más en el futuro por algunos abastecedores, está claro que el MAN de Ethernet y las tecnologías WAN proporcionan muchas ventajas, incluso interoperabilidad, amplitud de banda alta, y bajo costo. Para más información sobre el Metro

Ethernet,

ver

el

Metro

el

sitio

Web

del

Foro

de

Ethernet

en

www.metroethernetforum.org. Ethernet de alcance largo Metro Ethernet no debería ser aturdida con otro LAN y tecnología de MAN, llamada Ethernet del Alcance largo (LRE), que puede ser usado para unir edificios y cuartos dentro de edificios en redes de campus. El LRE proporciona un enlace de punto a punto que puede entregar un simétrico, de full-dúplex, la velocidad de transferencia de datos cruda de 11.25 Mbps sobre distancias de hasta 1 milla (1.6 kilómetros).

El LRE permite el uso de Ethernet sobre la existencia, no condicionada, hilos de par trenzado de cobre de grado de voz que es ubicuo en muchas ciudades y áreas hasta rurales, habiendo sido instalado y mejorado durante muchos años por compañías telefónicas. Los dueños de estructuras de multiunidad como hoteles, bloques de pisos, complejos comerciales, y agencias del gobierno pueden usar LRE para proporcionar la conectividad de Ethernet a clientes aunque el edificio que alambra usa tendido de cables viejos Categoría 1, 2, o 3.

El LRE permite que transmisiones de LAN de Ethernet coexistan con teléfono, ISDN, o Cambio de Rama Privado (PBX) servicios señalados sobre un par de hilos de cobre ordinarios. Codificación de usos de tecnología de LRE y técnicas de modulación digitales de la Línea de Suscriptor Digital (DSL) mundo junto con Ethernet, el protocolo de LAN más popular. El capítulo 11 cubre DSL más detalladamente. Cisco EtherChannel Las tres secciones anteriores emigraron en el reino de aplicaciones de MAN. Regresando a redes de campus más pequeñas, una tecnologia que es una parte de la mucha caja de herramientas de diseñadores de red de opciones de LAN es Cisco EtherChannel tecnología. El EtherChannel es una tecnología trunking que el full-dúplex Marcos Huerta S.

232


de grupos que 802.3 Ethernet une juntos de modo que los enlaces puedan proporcionar muy altas velocidades, soporta carga compartida, y sostienen el uno al otro si un enlace falla. El EtherChannel fue primero introducido por Kalpana en sus switches a principios de los años 1990. Cisco ha ampliado la tecnología, permaneciendo compatible con el estandar IEEE 802.3.

El EtherChannel puede ser usado entre routers de tráfico, switches, y servidores en enlaces de punto a punto que requieren más ancho de banda que un enlace de Ethernet solo puede proveer. Cisco proporciona puertos EtherChannel para muchos de sus switches de alta calidad y routers de tráfico. Intel y otros vendedores hacen EtherChannel NICs para servidores.

Con EtherChannel rápido, hasta cuatro enlaces de Ethernet Rápidos pueden ser agrupados para proporcionar un ancho de banda agregada máxima de 800 Mbps (fulldúplex). Con Gigabit EtherChannel, hasta cuatro enlaces de Ethernet Gigabit pueden ser agrupados para proporcionar un ancho de banda agregada máxima de 8 Gbps. Con Ethernet 10-Gbps, hasta cuatro enlaces de Ethernet 10-Gbps pueden ser agrupados para proporcionar un ancho de banda agregada máxima de 80 Gbps.

El EtherChannel distribuye unicast, broadcast, y el tráfico a través de los enlaces en un canal, proporcionando un alto performance de carga que comparte y redundancia. En caso que falle un enlace, el tráfico es desviado a enlaces restantes sin la intervención de usuario.

NOTA El EtherChannel selecciona un enlace dentro de un canal realizando una operación XOR en últimos dos bits de las direcciones de destino y fuente en un frame. La operación XOR puede causar uno de cuatro valores de que trazan un mapa a los cuatro enlaces posibles. (Si sólo dos enlaces son usados, entonces la operación XOR es hecha usando sólo el último bits de cada dirección.) Este método puede no equilibrar regularmente el tráfico si una mayoría de tráfico está entre dos anfitriones, como dos routers de tráfico o dos servidores. Sin embargo, para el tráfico de red típico con una mezcla de remitentes y receptores, EtherChannel proporciona el equilibrio de carga de alto rendimiento.

Diseñando troncos de

EtherChannel, usted puede

aumentar

su

eficacia de

caracteristicas redundantes agrupando enlaces que corren en cables en partes diferentes de una red de campus. La figura 10-4 muestra una topología donde el diseñador de red aumentó el ancho de banda entre un centro de datos y un armario de cableado a un conjunto de 800 Mbps (full-dúplex) y también usó la diversidad física de la planta de fibra para disminuir las posibilidades de una interrupción de red.

Marcos Huerta S.

233


La figura 10-4. Redundancia de EtherChannel

La conexión EtherChannel consiste en cuatro enlaces de Fast Ethernet. Dos carreras de fibra en los barrios este de Nueva York del edificio proporcionan 400 Mbps, y dos carreras de fibra en el lado de Oeste del edificio proporcionan el restante 400 Mbps. En este ejemplo, en caso de una fibra cortan en un lado del edificio, el lado restante recogerá el tráfico en menos de 1 segundo y los clientes de armario del cableado no notarán probablemente hasta el cambio.

Redes de ATM de campus

El ATM puede ser usado en WAN y redes de campus. Este capítulo habla de redes de campus de ATM; El capítulo 11 habla del ATM redes WAN. En una red de campus, un diseñador puede seleccionar el ATM como una tecnología de backbone para unir LANs. El diseñador también tiene la opción de recomendación que las estaciones de trabajo ser equipado con el ATM NICs y protocolo apilen.

A mediados de los años 1990 algunos expertos conectados a una red pensaron que el ATM sustituiría muchas instalaciones de LAN debido a su escalabilidad y apoyo a requerimientos de QoS. Cuando han mostrado a Ethernet para ser escalables también, y el trabajo ha sido hecho para soportar QoS en redes de LAN IP / redes WAN, el ATM en redes de campus ha perdido el favor con algunos expertos. No hay ninguna respuesta "correcta", sin embargo. El ATM es la opción correcta para algunos clientes y no para otros. Muchas organizaciones han puesto en práctica redes de ATM de campus y sido satisfechas por los resultados. Otras organizaciones han conducido lejos del ATM debido a su complejidad y el costo relativamente alto de componentes de ATM.

Marcos Huerta S.

234


El ATM es una opción buena para videoconferencia, representación médica, telefonía, aprendizaje de distancia, y otras aplicaciones que mezclan datos, el vídeo, y la voz, y requieren de ancho de banda alta, bajo retardo, y poca o ninguna inquietud de tardanza.

El ATM soporta de punta a punta garantías de QoS (mientras la red entera está basada en ATM y las estaciones de trabajo usan una pila de protocolo de ATM, más bien que un IP u otra pila de protocolo). Con ATM, un sistema de final puede establecerse un recorrido virtual con otro dispositivo de ATM al otro lado del ATM conectan a la red y especifican parámetros QoS como lo siguiente: ü

Precio de célula máximo (PCR)

ü

Precio de célula sostenible (SCR)

ü

Tamaño de estallido máximo (MBS)

ü

Proporción de pérdida de célula (CLR)

ü

Tardanza de transferencia de célula (CTD)

Las redes de LAN / las redes WAN generalmente no pueden soportar de punta a punta la funcionalidad de QoS, aunque el progreso esté siendo hecho en este para redes de IP. Los protocolos como el Protocolo de Reservación de Recurso (RSVP) y otro trabajo que el IETF grupo de funcionamiento de Servicios Integrado hace causarán redes de IP que ofrecen de punta a punta la funcionalidad de QoS. El capítulo 4, "Caracterizando el Tráfico de Red," se habló la funcionalidad QoS desarrollada por el grupo de funcionamiento de Servicios Integrado.

El ATM a veces ofrecido como superior a Ethernet porque esto soporta más ancho de banda. El ATM soporta OC-192 (10 Gbps) y puede escalar hasta más allá de aquella velocidad cuando las nuevas tecnologías como WDM se hacen comunes. En el ambiente de Ethernet, Gigabit Ethernet es común para redes de backbone, pero 10Gbps Ethernet comienza ahora mismo a ser usada. Las versiones de Nuevos Ethernet serán probablemente desarrolladas aquel que soporte velocidades aún más altas.

Una desventaja del ATM es el sobrecalentamiento para transmitir datos de ATM es mucho más alto que el sobrecalentamiento para transmitir datos de LAN tradicionales. Los 5 bytes de cabecera requerido en cada célula de ATM de 53 bytes iguala el 9.4 por ciento de sobrecalentamiento. Cuando la segmentación y la nueva sesión y la Capa de Adaptación de ATM (AAL) la funcionalidad es añadida, el sobrecalentamiento puede crecer a 13 bytes o el 24.5 por ciento.

Un otro factor para considerar antes de seleccionar el ATM es que la seguridad puede ser difícil de poner en práctica. Un switch de ATM que sólo entiende células, y no

Marcos Huerta S.

235


paquetes, no puede examinar paquetes para comprobar direcciones y números de puerto para poner en práctica filtros de paquete. Los filtros de paquete son un método típico de proteger una red de uso ilegal y acceso, como hablado en El capítulo 8, "Desarrollando Estrategias de Seguridad de Red." Un router de tráfico o el Firewall que entiende paquetes son necesarios poniendo en práctica la seguridad con filtros de paquete.

Seleccionar para el diseño de redes de campus los dispositivos de redes En este punto en el proceso de diseño de red, usted ha desarrollado una topología de red y debería tener una idea de cual de los segmentos serán compartidos con hubs o repetidores, puente con puentes o switches, o ruteando usando routers. Tabla 10-6 proporciona una revisión de las diferencias principales entre hubs (repetidores), puentes, switches, y routers.

Tabla 10-6. Comparación de Hubs, Puentes, Switches, y Routers OSI Capas Puestas en práctica

Como Domino de ancho de banda Son Segmentadas

Como dominio de Emisión Son Despliegue Segmentadas Típico

Todos los puertos están en la misma dominio de ancho de banda.

Todos los puertos están en la misma dominio de emisión.

Puente 1–2

Cada puerto delinea un dominio de ancho de banda.

Todos los Une redes puertos están en la misma dominio de emisión.

Filtración de paquete configurada por usuario

Switch

1–2

Cada puerto delinea una dominio de ancho de banda.

Todos los puertos están en la misma dominio de emisión.

Une dispositivos individuales o redes

Filtración, capacidades de ATM, procesamiento de conexión directa, multimedia (multimolde) caracteristicas

Router 1–3

Cada puerto delinea un dominio de ancho de banda.

Cada puerto delinea un dominio de emisión.

Une redes

Filtración, firewalling, enlaces WAN rápidos, compresión, formación de una cola de espera avanzada y transporte de mercancías de procesos, multimedia (multimolde) caracteristicas

Hub

1

Une dispositivos individuales en pequeños LANs

Caracteristicas Adicionales Típicos La autodivisión para aislar nodos descarriados

Después de que usted ha diseñado una topología de red y ha tomado algunas decisiones en cuanto a la colocación y alcance de compartido, cambiado, y segmentos

Marcos Huerta S.

236


de red, usted debería recomendar entonces hubs actuales, switches, puentes, y routers de varios vendedores. Esta sección cubre criterios de selección que usted puede usar tomando decisiones. Los criterios para seleccionar dispositivos de funcionamiento entre redes en general incluyen lo siguiente: ü

El número de puertos.

ü

Procesamiento de velocidad.

ü

La cantidad de memoria.

ü

La cantidad de latencia introdujo cuando el dispositivo transmite datos.

ü

Rendimiento en paquetes por segundo (o células por segundo para ATM).

ü

LAN y tecnologías WAN apoyadas.

ü

Autodetección de velocidad (por ejemplo, 10 o 100 Mbps).

ü

Autodescubrimiento de medio - contra operación de full-dúplex.

ü

Medios (tendido de cables) apoyado.

ü

Facilidad de configuración.

ü

Manejabilidad (por ejemplo, soporte para el Protocolo de Dirección de Red Simple [SNMP] y escucha remota [RMON], indicadores de estado).

ü

Costo.

ü

Tiempo medio entre fracaso (MTBF) y tiempo medio de reparación (MTTR).

ü

El soporte de paquete filtro y otras medidas de seguridad.

ü

Apoyo a componentes calientes-swappable.

ü

Apoyo a suministros de energía redundantes.

ü

Apoyo a caracteristicas de QoS.

ü

Disponibilidad y calidad de soporte técnico.

ü

Disponibilidad y calidad de documentación.

ü

Disponibilidad y calidad de entrenarse (para switches complejos y routers.)

ü

Reputación y viabilidad del vendedor.

ü

La disponibilidad de resultados de prueba independientes que confirman la interpretación del dispositivo.

Para switches y puentes (incluso puentes inalámbricos), los criterios siguientes pueden ser añadidos a la primera lista de bulleted en esta sección: ü

Tendiendo un puente sobre tecnologías apoyadas (tender un puente transparente, algoritmo de spanning tree, tender un puente remoto, etcétera).

ü

Caracteristicas de soporte de spanning tree avanzados (reconfiguración rápida de spanning tree [802.1w] y árboles múltiples que atraviesan [802.1s]).

ü

El número de direcciones de MAC que el switch o el puente pueden aprender

ü

Soporte a seguridad de puerto (802.1X).

ü

Soporte a conmutación de conexión directa.

ü

Soporte a conmutación de conexión directa adaptable.

Marcos Huerta S.

237


ü

Tecnologías de VLAN soportadas, como el Protocolo Trunking Virtual (VTP), Enlace de Inter-switch (ISL) protocolo, e IEEE 802.1Q

ü

Apoyo a aplicaciones de multimolde (por ejemplo, la capacidad de participar en el Protocolo de Dirección de Grupo de Internet [IGMP] para controlar la extensión de paquetes de multicast).

ü

La cantidad de memoria disponible para cambiar tablas, tablas de enrutamiento (si el switch tiene un módulo de encaminamiento), y la memoria usada por rutinas de protocolo.

ü

Disponibilidad de un módulo de encaminamiento.

Para routers (e switches con un módulo de encaminamiento), los criterios siguientes pueden ser añadidos a la primera lista de bulleted en esta sección: ü

Protocolos de capa de red soportado.

ü

Encaminamiento de protocolos soportado.

ü

Soporta aplicaciones de multicast.

ü

Soporta formación de una cola de espera avanzada, conmutación, y otras caracteristicas de optimización.

ü

Soporta la compresión (e performance de compresión si es soportado).

ü

Soporta a la codificación (e performance de codificación si es soportado).

Para puntos de acceso inalámbricos y puentes, los criterios siguientes pueden ser añadidos a la primera lista de bulleted en esta sección: ü

Velocidades inalámbricas soportada (11 Mbps, 5.5 Mbps, y 54 Mbps)

ü

Velocidad de puerto de Ethernet uplink.

ü

Soporta Protocolo de Configuración de Anfitrión Dinámico (DHCP), Traducción de Dirección de Red (NAT), y encaminamiento de IP.

ü

Soporta a VLANs.

ü

Soporta poder inline sobre Ethernet si el punto de acceso con poca probabilidad será montado cerca de salidas de poder.

ü

Variedad de antena y apoyo a accesorios de antena de final más alto.

ü

Transmita el poder y reciba la sensibilidad.

ü

La capacidad de templar el poder transmitir.

ü

Disponibilidad de un modelo rugoso para uso exterior.

ü

Soporta a certificar dispositivos de cliente por dirección de MAC.

ü

Soporta autenticación de usuario con 802.1X y el Protocolo de Autenticación Extensible (EAP).

ü

Soporta a la autenticación mutua, que permite que un cliente esté seguro que esto comunica con el servidor de autenticación intencionado.

ü

Una opción para incapacitar servicio puso el identificador (SSID) emisiones

ü

Soporta 128 bits o mejor codificación.

Marcos Huerta S.

238


ü

Soporta llaves dinámicas, llaves únicas para cada usuario, keying por paquete, y un control de integridad de mensaje (MIC).

ü

Soporta contraseñas antiguas o naipes simbólicos.

ü

Soporta en Público Asegura el Paquete que Expide (a PSPF).

ü

Soporta realces de seguridad especificados por Wi-Fi Acceso Protegido (WPA), Red de Seguridad Robusta (RSN), o 802.11i.

Caracteristicas de Optimización en Dispositivos de Funcionamiento entre redes de Campus El capítulo 13, "Optimizando Su Diseño de Red," cubre la optimización y QoS más detalladamente, pero vale la pena mencionar aquí que la optimización y las caracteristicas de QoS son más importantes en diseños de red de campus que muchos diseñadores podrían esperar. No sólo QoS es requerido en el WAN, donde el ancho de banda disponible es inferior que en el campus, pero los requerimientos rigurosos para tardanza baja conducen la necesidad de QoS en switches de LAN y router también. Incluso en redes de campus, la demanda de ancho de banda en la red a menudo excede el ancho de banda disponible. Las caracteristicas de QoS deberían ser considerados seleccionando dispositivos de funcionamiento entre redes para redes de campus.

En la mayor parte de redes, al menos algunos elementos son sobresuscritos y por lo tanto requieren caracteristicas de QoS. Las caracteristicas de QoS el más a menudo son requeridos en uplinks de la capa de distribución a la capa core de un diseño de red jerárquico. A Veces el QoS es requerido en uplinks de la capa de acceso a la capa de distribución también. La suma de las velocidades en todos los puertos en un switch donde los dispositivos de final están relacionados es por lo general mayor que aquel del puerto uplink. Cuando los puertos de acceso son totalmente usados, la congestión en el puerto uplink es inevitable.

Los switches de capa de acceso por lo general proveen QoS basado sólo en la Capa 2 información, si en absoluto. Por ejemplo, los switches de capa de acceso pueden basar decisiones QoS en el puerto de entrada para el tráfico. El tráfico de un puerto particular puede ser definido como el tráfico prioritario en un puerto uplink. El mecanismo de programación en el puerto de salida de un switch de capa de acceso asegura que el tráfico de tales puertos es servido primero. El tráfico de entrada puede ser marcado para asegurar el servicio requerido cuando el tráfico pasa por distribución e switches de capa principales.

La distribución y los switches de capa core pueden proveer QoS basado en la Capa 3 información, incluso fuente y destino direcciones de IP, números de puerto, y bits QoS

Marcos Huerta S.

239


en un paquete IP. El QoS en distribución e switches de capa core debe ser proporcionado en ambas direcciones del flujo de tráfico. Ver El capítulo 13 para más información en QoS y optimización.

Fase IV: Testeo, optimización y documentación de la red Las pruebas de su diseño de red son un paso importante en el proceso de diseño que permite que usted confirme que su diseño encuentra los objetivos comerciales y técnicos. Probando su diseño, usted puede verificar que las soluciones que usted ha desarrollado proporcionarán la performance y QoS que su cliente espera.

Este capítulo presentó un acercamiento de análisis de sistemas de pruebas que incluyen objetivos de prueba de concretas, criterios de aceptación verificables, escrituras de prueba, y pruebas de logs. El capítulo también proporcionó la información en diseño e instrumentos de pruebas, incluso instrumentos de Sistemas Cisco, WANDL, OPNET, Agilent, NetIQ, y NetPredict.

Testear el diseño de red "Probando, Optimizando, y Documentando Su Diseño de Red," del Diseño Top Down cubre los pasos finales en el diseño de red: pruebas, optimización, y documentación de su diseño. Este capítulo habla de las pruebas de su diseño, que es un paso crítico en un acercamiento de análisis de sistemas para conectar a la red el diseño. Las pruebas le ayudarán a demostrar a usted y su diseño de red al cliente que su solución encuentra objetivos comerciales y técnicos.

Este capítulo usando la industria prueban para predecir la performance de los componentes de la red. Esto también cubre edificio y pruebas de un sistema de prototipo, y utilización de dirección de red y modelado de instrumentos para anticipar la performance de punta a punta y la calidad del servicio (QoS) que su diseño proporcionará.

Las pruebas de un diseño de red son un amplio sujeto. Este libro cubre el tema en un nivel alto. Los libros completos podrían ser escritos en pruebas de diseño de red. De hecho, dos libros recomendados que son relevantes para conectar a la red pruebas de diseño incluyen a Raj Jain el Arte del Análisis de Performance de Sistemas de Computadora y Robert Buchanan el Arte de Probar Sistemas de Red (ambos publicados por el John Wiley and Sons, Inc).

Note que tanto Jain como Buchanan usan el arte de palabra en los títulos de sus libros. Las pruebas de un sistema de red, y prediciendo y midiendo su performance, son desde muchos puntos de vista un arte más bien que una ciencia. En primer lugar, cada sistema

Marcos Huerta S.

240


es diferente, tan seleccionado los métodos de pruebas correctas y los instrumentos requieren que conciencia técnica, creatividad, ingenio, y un entendimiento cuidadoso del sistema sea evaluada. Ninguna metodología sola o instrumento son correctos para cada proyecto, o para cada diseñador de red.

La selección de los procedimientos de pruebas correctas e instrumentos depende de sus objetivos para el proyecto de pruebas, que típicamente incluyen lo siguiente: ü

La verificación que el diseño encuentra los objetivos comerciales y técnicos claves.

ü

La convalidación de LAN y tecnología WAN y selecciones de dispositivo.

ü

La verificación que un abastecedor de servicio proporciona el convenido servicio.

ü

La identificación de cualquier cuello de botella o problemas de conectividad.

ü

Las pruebas de redundancia de la red.

ü

El análisis de los efectos en la performance de la red de enlaces que fallan.

ü

La determinación de técnicas de optimización que serán necesarias para encontrar la performance y otros objetivos técnicos.

ü

El análisis de los efectos en la performance de mejorar los enlaces de red o dispositivos.

ü

Demostrando que su diseño es mejor que un diseño del competidor (en casos donde un cliente planea seleccionar un diseño de ofertas proporcionadas por vendedores múltiples o asesores).

ü

El paso "de una prueba de aceptación" que le da la aprobación de ir adelante con la realización de red (y posiblemente ser pagado para completar la fase de diseño del proyecto).

ü

El convencimiento de los gerentes y los compañeros de trabajo que su diseño es eficaz.

ü

La identificación de cualquier riesgo que podría impedir la implementación y planes para contingencias.

ü

La determinación cuantas pruebas adicionales podrían ser requeridas. Por ejemplo, quizás usted decidirá que el nuevo sistema debería ser primero desplegado como un piloto y someterse a más pruebas antes de ser implementado a todos los usuarios.

Utilización de Pruebas de Industria Los vendedores, los laboratorios de prueba independientes, y los boletines comerciales a menudo publican la información en las pruebas que ellos han completado para verificar las caracteristicas y la performance de dispositivos de red particulares o guiones de diseño de red.

Marcos Huerta S.

241


Algunos laboratorios de pruebas respetados, independientes incluyen lo siguiente: ü

El Laboratorio de Interoperabilidad en la Universidad de Nuevo Hampshire (IOL). Refiérase a www.iol.unh.edu para más información.

ü

Laboratorios de ICSA. Refiérase a www.icsalabs.com para más información.

ü

Laboratorios de Miercom. Refiérase a www.miercom.com para más información.

ü

KeyLabs. Refiérase a www.keylabs.com para más información.

ü

Tolly Group. Refiérase a www.tollygroup.com para más información.

A veces, para diseños de red simples, usted puede confiar en resultados de prueba de vendedores, laboratorios independientes, o boletines comerciales para demostrar a su cliente que su diseño funcionará como ha querido. Por ejemplo, si usted ha propuesto un diseño de red de campus basado únicamente en la tecnología de conmutación de un vendedor

particular,

y

un

boletín

comercial

independiente

ha

verificado

las

caracteristicas y la performance de los productos del vendedor, los resultados de pruebas del diario podrían convencer suficientemente a su cliente de la eficacia de su diseño. Para diseños de red más complejos, usted generalmente debería hacer sus propias pruebas, además de la presentación a su cliente estudios independientes que le ayude a vender su caso.

Los resultados de prueba publicados por vendedores o partidos independientes, como boletines comerciales o laboratorios de pruebas, pueden ser informativos, pero ellos también pueden engañar. En primer lugar, los vendedores obviamente hacen todo lo posible para asegurar que sus productos parecen funcionar mejor que los productos de sus competidores. Tenga presente que algunos boletines comerciales y los laboratorios están también poco dispuestos a publicar resultados negativos sobre los productos de los vendedores porque la ayuda de vendedores paga sus cuentas. (Los vendedores pagan a laboratorios para dirigir pruebas y publicar la publicidad en boletines comerciales.)

Además,

la

mayor

parte

de

pruebas

dirigidas

por

vendedores,

laboratorios

independientes, y boletines comerciales son pruebas de componentes, más bien que pruebas de sistema. Las pruebas componentes no son generalmente suficientes para medir la performance de un diseño de red. Además, la configuración de prueba usada por el vendedor o laboratorio de pruebas casi seguramente no empareja su configuración actual. Este significa que los resultados de pruebas pueden no ser relevantes a su diseño particular. Para entender como los componentes de red se comportarán en su configuración con sus aplicaciones, tráfico de red, y las exigencias únicas, construyendo un sistema de prototipo o el modelo de la red son por lo general necesarias. El prototipo o el modelo le

Marcos Huerta S.

242


dejarán ir más allá de pruebas componentes y estimar la performance probable del diseño, incluso tardanza de punta a punta, rendimiento, y disponibilidad.

Construyendo y Testeando un Prototipo de Sistema de Red El objetivo de esta sección es ayudarle a hacer una lista de las tareas de construir un prototipo que verifica y demuestra el comportamiento de un sistema de red. Un objetivo secundario es ayudarle a determinar cuanto de un sistema de red debe ser puesto en práctica en un prototipo para verificar el diseño.

Un prototipo es una realización inicial de un nuevo sistema que proporciona un modelo en el cual la realización final será modelada. Un prototipo permite que un diseñador valide la operación y la performance de un nuevo sistema. Debería ser funcional, pero no tiene que ser una realización de tamaño natural del nuevo sistema. Esto debería resultar, sin embargo, de un análisis cuidadoso de necesidades como de una revisión de diseño con el cliente de final.

Determinando el Alcance de un Sistema de Prototipo Basado en un entendimiento claro de los objetivos de su cliente, usted debería determinar cuánto del sistema de red usted debe poner en práctica para convencer a su cliente que el diseño encontrará exigencias. Como no es generalmente práctico poner en práctica un sistema completo, de tamaño natural, usted debería aislar qué aspectos de un diseño de red son los más importantes para su cliente. Su prototipo debería verificar capacidades importantes y funciones que no podrían funcionar suficientemente. Las

funciones arriesgadas

pueden

incluir funciones

complejas, intrincadas

e

interacciones componentes, así como funciones donde el diseño era bajo la inflluencia de coacciones comerciales o técnicas, y compensaciones con objetivos contrarios.

El alcance de un prototipo de red puede depender de objetivos técnicos como en no técnicos. Preste la atención a factores no técnicos, como tendencias de su cliente, estilo comercial, e historia con proyectos de red. Quizás el cliente ya rechazó un diseño de red debido a su carencia de manejabilidad y caracteristicas de utilidad y tan podría ser predispuesto para buscar estos problemas en su sistema. Si es así, un objetivo de su prototipo debería ser de desarrollar una demostración que la manejabilidad de escaparates y la utilidad benefician.

Su capacidad de poner en práctica un prototipo depende de recursos disponibles. Los recursos incluyen a la gente, el equipo, el dinero, y el tiempo. Usted debería usar recursos suficientes de producir una prueba válida sin requerir tantos recursos que empujes probadores el proyecto sobre el presupuesto, lo retrasa, o negativamente afecta a usuarios de red.

Marcos Huerta S.

243


Un prototipo puede ser puesto en práctica y probado de tres modos: ü

Como una red de prueba en un laboratorio.

ü

Integrado en una red de producción, pero probado durante fuera de horas.

ü

Integrado en una producción conectada a la red y probado durante horas de oficina normales.

Esto es una idea buena de poner en práctica al menos la parte de un sistema de prototipo en una red de prueba antes de ponerlo en práctica en una red de producción. Esto permitirá que usted calcule bugs sin afectar la productividad de trabajadores que dependen de la red. Una red de prueba también le ayuda a evaluar capacidades de producto, desarrollar configuraciones de dispositivo iniciales, y el modelo predijo la performance de red y QoS. Usted también puede usar una red de prueba para demostrar su diseño y productos seleccionados a un cliente.

Después de que un diseño ha sido aceptado en una base provisional, es importante probar una realización inicial del diseño en una red de producción para identificar cuellos de botella posibles u otros problemas que el verdadero tráfico puede provocar. Las pruebas iniciales pueden ser hechas durante fuera de hora para minimizar problemas posibles, pero las pruebas finales deberían ser hechas durante horas de oficina normales para evaluar la performance durante la carga normal.

Unas pautas claves para tener presente planeando una prueba "viva" son como sigue: ü

Advierta a los usuarios de antemano sobre el cronometraje de pruebas entonces ellos pueden esperar un poco de degradación de performance, pero pedir a los usuarios trabajar cuando ellos típicamente hacen para evitar invalidar la prueba por el comportamiento anormal.

ü

Advierta a administradores de red y otros diseñadores de antemano de evitar la posibilidad que ellos podrían dirigir pruebas al mismo tiempo.

ü

Advierta a administradores de la red de antemano, entonces ellos no son aturdidos en alarmas inesperadas en consolas de dirección de red, y entonces ellos pueden explicar el tráfico de prueba documentando estadística de disponibilidad y la carga.

ü

De ser posible, múltiplo dirigido, corto (menos que el 2 minuto) las pruebas para minimizar a usuario afectan y disminuyen los efectos en medidas de línea de fondo.

ü

Las pruebas dirigidas que comienzan con pequeño tráfico y cambios de configuración, y luego incrementalmente aumentan los cambios.

ü

Los resultados de prueba de monitor y los discontinúan cuando los objetivos de prueba son encontrados, o la red de producción es con severidad afectada o falla.

Marcos Huerta S.

244


La escritura de un Plan de Prueba para el Sistema de Prototipo Después de que usted ha decidido el alcance de su prototipo, escriba un plan que describe como usted probará el prototipo. El plan de prueba debería incluir cada uno de los temas siguientes, que las pocas siguientes secciones de este capítulo describen más detalladamente: ü

Objetivos de prueba y criterios de aceptación.

ü

Los tipos de pruebas que serán dirigidas.

ü

Equipo de red y otros recursos requeridos.

ü

Escrituras de prueba.

ü

El objetivo y variaciones para el proyecto de pruebas.

El Desarrollo de Objetivos de Prueba y Criterios de Aceptación El primer paso y más importante por escrito es un plan de prueba y debe poner los objetivos en una lista de la prueba (s). Los objetivos deberían ser específicos y concretos, y deberían incluir la información en la determinación si la prueba pasa o falla. Lo siguiente es algunos ejemplos de objetivos específicos y criterios de aceptación que fueron escritos para un cliente particular: ü

Mida el tiempo de respuesta para la aplicación XYZ durante horas de uso máximas (entre 10 y a las 11h00). El criterio de aceptación, por oferta de diseño de red, es que el tiempo de respuesta debe ser medio segundo o menos.

ü

Mida el rendimiento de la aplicación XYZ durante horas de uso máximas (entre 10 y a las 11h00). El criterio de aceptación, por oferta de diseño de red, es que el rendimiento debe ser al menos 2 Mbps.

ü

Mida la cantidad de tiempo que esto toma para un usuario de la nueva voz sobre IP (VoIP) el sistema para oír un tono de marcación después de recoger un microteléfono telefónico. El criterio de aceptación es que la cantidad (media) media del tiempo debe ser menos que o igual a la cantidad media del tiempo para un usuario del Cambio de Rama Privado (PBX) sistema telefónico corporativo. El desacuerdo del promedio también debe ser igual o más pequeño.

Los objetivos y los criterios de aceptación deberían estar basados en los objetivos comerciales y técnicos de un cliente para el diseño de red, pero pueden ser más formalmente o expresamente definidos. Los criterios para declarar que una prueba pasó o falló deben estar claros y convenidos por el probador y el cliente. Usted debería evitar un problema común, en el cual la prueba es completada, los probadores y los clientes convienen en resultados, pero discrepan en el resultado de la performance.

A pesar de que el objetivo subyacente de su prototipo podría ser de mostrar que su sistema es mejor que un competidor, usted debería evitar incorporar tendencias o

Marcos Huerta S.

245


nociones preconcebidas sobre resultados en objetivos de prueba (y escrituras de prueba).

El objetivo de prueba debería ser simplemente medir el resultado, no demostrar que el resultado está en su favor; y, debería estar basado tanto como posible en estándares de industria para todas las tecnologías relevantes y servicios (por ejemplo, VoIP y estándares de admisibilidad de voz ITU).

Los objetivos y los criterios de aceptación pueden referirse a una medida de línea de fondo para la red corriente. Por ejemplo, un objetivo podría ser medir la comprobación por redundancia cíclica (CRC) índice de errores en un segmento WAN y comparar los resultados a una medida de línea de fondo. El criterio de aceptación podría ser que deben haber el 20 por ciento menos errores que hay hoy. Para ser capaz de determinar si el criterio haya sido encontrado, una medida de línea de fondo debe existir, como fue hablado en El capítulo 3, "Caracterizando las Interredes Existentes." El capítulo 3 también incluye una Lista de comprobación de Salud de Red que puede ayudarle a escribir criterios de aceptación y objetivos.

La determinación de los Tipos de Pruebas para Correr En general, las pruebas deberían incluir performance, tensión, y análisis de fracaso. El análisis de performance debería examinar el nivel de servicio que el sistema ofrece en términos de rendimiento, tardanza, variación de tardanza, tiempo de respuesta, y eficacia.

El análisis de tensión debería examinar cualquier degradación del servicio debido a la carga ofrecida aumentada en la red. El análisis de fracaso debería calcular la disponibilidad de red y la exactitud, y analizar las causas de cualquier interrupción de red.

Según los objetivos comerciales y técnicos de un cliente, otras pruebas que podrían ser necesarias son manejabilidad, utilidad, adaptabilidad, y pruebas de seguridad. Los tipos específicos de pruebas para correr contra su prototipo particular dependen de objetivos de prueba. Las pruebas típicas incluyen lo siguiente: ü

Tiempo de respuesta de aplicación probando. Este tipo de la prueba mide la performance del punto de vista de un usuario y evalúa cuanto tiempo un usuario debe esperar ejecutando operaciones típicas aquella actividad de red de causa. Estas operaciones incluyen el comienzo de la aplicación, que cambia entre pantallas/formas/campos dentro de la aplicación, y el archivo se abre, lee, escribe, búsquedas y finales. Con este tipo de pruebas, el probador mira a usuarios actuales, o simula el comportamiento de usuario con un instrumento de simulación. La prueba

Marcos Huerta S.

246


debería comenzar con un número predeterminado de usuarios y acciones, entonces gradualmente aumentar el número de usuarios y acciones para exponer cualquier aumento en el tiempo de respuesta debido a red adicional o carga de servidor. ü

Pruebas de rendimiento. Este tipo de la prueba mide el rendimiento para una aplicación particular y/o rendimiento para aplicaciones múltiples en kilo-bytes o megabytes por segundo. Esto también puede medir el rendimiento en términos de paquetes por segundo por un dispositivo de conmutación (por ejemplo, un switch o router). Como en el tiempo de respuesta probando, las pruebas de rendimiento deberían comenzar con varios usuarios y acciones que son gradualmente aumentadas.

ü

Pruebas de disponibilidad. Con pruebas de disponibilidad, las pruebas son dirigidas contra el sistema de prototipo durante 24 a 72 horas, bajo el medio a la carga pesada. El precio de errores y fracasos es supervisado.

ü

Pruebas de regresión. Las pruebas de regresión se aseguran que el nuevo sistema no rompe ninguna aplicación o componentes que eran conocidos trabajar y funcionar a un cierto nivel antes de que el nuevo sistema fuera instalado. Las pruebas de regresión no prueban nuevas caracteristicas o mejoras. En cambio, esto se concentra en aplicaciones existentes. Las pruebas de regresión deberían ser completas, y son por lo general automatizadas para facilitar este completa.

La Documentación de Equipo de Red y Otros Recursos Un plan de prueba debería incluir un dibujo de topología de red y una lista de dispositivos que serán requeridos. El dibujo de topología debería incluir dispositivos principales, direcciones, nombres, enlaces de red, y alguna indicación de capacidades de enlaces. El dibujo de topología también debería documentar alguna WAN o enlace de LAN que deben unirse a la red de producción o al Internet.

La lista de dispositivos debería incluir hubs, repetidores, switches, routers, estaciones de trabajo, servidores, simuladores de equipo telefónico, puntos de acceso inalámbricos, firewalls, cables, etcétera. La lista debería documentar números de versión para hardware y software, e información de disponibilidad. A veces las pruebas requieren el nuevo equipo que no podría estar disponible aún, o equipo que por otros motivos tiene un tiempo de plomo largo para la consecución. Si es así, debería ser notado en el plan de prueba.

En la adición para conectar a la red equipos, un plan de prueba debería incluir una lista de instrumentos de pruebas requeridos. El "Instrumentos para Probar un Diseño de Red" en la sección más adelante en este capítulo describiremos los instrumentos útiles para probar un diseño de red. Los instrumentos típicos incluyen la dirección de red y la

Marcos Huerta S.

247


escucha de instrumentos, instrumentos de generación de tráfico, modelando e instrumentos de simulación, e instrumentos de dirección de nivel de servicio y QoS.

El plan de prueba también debería poner cualquier aplicación en una lista que aumentará la eficacia de pruebas, por ejemplo aplicaciones de distribución de software o programas de mando a distancia que facilitan la configuración y la nueva configuración de nodos durante una prueba.

NOTA En Microsoft el ambiente de Windows, si sus pruebas requieren nuevas aplicaciones de software que cargan o versiones en sistemas múltiples, Servidor de Dirección de Sistemas de Microsoft (SMS) software puede ser una adición útil al ambiente de pruebas.

El plan de prueba debería documentar cualquier otro recurso que usted necesitará, incluso lo siguiente: ü

Tiempo previsto en un laboratorio en su sitio o el sitio del cliente.

ü

La fuente de poder, el aire acondicionado, el espacio, y otros recursos físicos.

ü

Ayuda de compañeros de trabajo o personal de cliente.

ü

Ayuda de usuarios para probar aplicaciones.

ü

La red se dirige y nombres.

Escrituras de Prueba Para cada prueba, escriba una escritura de prueba que pone los pasos en una lista para ser tomados para realizar el objetivo de prueba. La escritura debería identificarse qué instrumento es usado para cada paso, como el instrumento es usado para hacer medidas relevantes, y que información debería ser registrada durante pruebas. La escritura debería definir valores iniciales para parámetros y como variar aquellos parámetros durante pruebas. Por ejemplo, la escritura de prueba podría incluir un valor de carga de tráfico inicial y aumentos incrementales para la carga.

Lo siguiente es un ejemplo de una escritura de prueba simple para el ambiente de prueba de red mostrado en La figura 12-1. ü

Objetivo de prueba. Tasa la capacidad del firewalls de bloquear el tráfico de ABECÉ de Aplicación, tanto durante la luz como durante condiciones de carga moderadamente pesadas.

ü

Criterio de aceptación. El firewalls debería bloquear el TCP SYN petición de cada estación de trabajo en la Red que intenta establecer una sesión de ABECÉ de

Marcos Huerta S.

248


Aplicación con el Servidor 1 en la Red B. El firewalls debería enviar a cada estación de trabajo un TCP RST paquete (reinicializado).

La figura 12-1. El Ambiente de Prueba para la Escritura de Prueba de Ejemplo

Pasos para la Prueba: 1. Comience a capturar el tráfico de red en el analizador de protocolo en la Red A. 2. Comience a capturar el tráfico de red en el analizador de protocolo en la Red B. 3. ABECÉ de Aplicación Dirigido en una estación de trabajo localizada en Red A y Servidor de acceso 1 en Red B. 4. Deje de capturar el tráfico de red en los analizadores de protocolo. 5. Los datos de demostración en la Red el analizador de protocolo de A y verifica que el analizador capturó un TCP SYN paquete de la estación de trabajo. Verifice que la dirección de destino de capa de red es el Servidor 1 en la Red B, y el puerto de destino es el puerto 1234 (el número de puerto para el ABECÉ de Aplicación). Verifice que el firewalls respondió a la estación de trabajo con un TCP RST el paquete. 6. Los datos de demostración en la Red el analizador de protocolo de B y verifica que el analizador no capturó ningún tráfico de ABECÉ de Aplicación de la estación de trabajo. 7. Registre los resultados de la prueba en el archivo histórico de proyecto. 8. Salve los archivos de rastro de analizador de protocolo al directorio de archivo de rastro de proyecto. 9. Gradualmente aumente la carga de trabajo en el firewalls, aumentando el número de estaciones de trabajo en la Red uno por uno, hasta que 50 estaciones de trabajo dirijan el ABECÉ de Aplicación e intenten alcanzar al Servidor 1. Repita Pasos 1 a 8 después de que cada estación de trabajo es añadida a la prueba.

La documentación del Objetivo de Proyecto Para proyectos de pruebas complejos, el plan de prueba debería documentar el objetivo de proyecto, incluso el principio y fecha de fin para el proyecto, y variaciones principales. El objetivo debería poner tareas principales en una lista y la persona que

Marcos Huerta S.

249


ha sido adjudicada a cada tarea. La lista siguiente muestra tareas típicas, incluso algunas tareas que deberían haber sido completadas ya cuando el plan de prueba es escrito: v Escriba objetivos de prueba y criterios de aceptación. v Diseñe la topología de red para el ambiente de pruebas. v Determine que hardware conectado a una red y el software serán necesarios. v Coloque un orden de compra para el hardware y software si es necesario. v Determine qué pruebas de instrumentos serán necesarias. v Coloque un orden de compra para los instrumentos de pruebas si es necesario. v Determine otros recursos que serán necesarios y harán los arreglos para su disponibilidad. v Escriba escrituras de prueba. v Instale y configure el hardware y el software. v Pruebas de principio. v Registre los resultados de las pruebas. v Revise y analize los resultados. v Reduzca datos de resultados (si es necesario). v Presente resultado al cliente. v Archive los resultados.

Implementando el Plan de Prueba La implementación de un plan de prueba es seguir las prueba de scripts y documentar su trabajo.Sin embargo, a veces las pruebas de scripts no puede ser seguido exactamente, porque es difícil precisar todas las dificultades y problemas ha considerar cuando escribe un scripts. Por esta razón, es importante mantener logs, electrónicamente o en un cuaderno de notas. (Un logs electrónico son preferible porque esto permite buscar más fácil la información más tarde.)

Además de mantener los logs documentados que se recogieron en las pruebas de datos y resultados de prueba, esto es una buena idea de conservar la actividad diaria y registrar aquel progreso y cualquier cambio hecho en las configuraciones de equipo o pruebas de scripts. El logs de actividad diario también puede registrar cualquier problema que fue encontrado y teorías sobre causas. Estas teorías podrían ser provechosas más tarde analizando resultados (y ellos podrían ayudar con futuros proyectos de pruebas).

Instrumentos para Probar un Diseño de Red Esta sección habla de los tipos de instrumentos que pueden ser usados para probar un diseño de red. La sección también recomienda algunos instrumentos específicos.

Marcos Huerta S.

250


Tipos de Instrumentos En general, los tipos de instrumentos que usted puede usar para probar su diseño de red incluyen lo siguiente: v Network-management and monitoring tools v Traffic-generation tools v Modeling and simulation tools v QoS and service-level-management tools

Network-management and monitoring tools son por lo general usadas en un ambiente de producción para alertar a administradores de la red de problemas y acontecimientos de red significativos, pero ellos también ayudan a probar un diseño de red. Networkmanagement applications, como CiscoWorks ofrecido por Cisco System o CV OpenView de Hewlett-Packard, pueden alertarle de problemas en su red de prueba. Estos tipos de instrumentos por lo general corren en estación de red dedicada (NMS).

Network-management and monitoring software también pueden incluir aplicaciones que residen en dispositivos de red. Por ejemplo, algunos sistemas operativos de red incluyen el software que supervisa la CPU del servidor y el uso de la memoria, que puede ser útil aislando problemas de performance en un nuevo diseño de red. Como otro ejemplo, mucho Sistema Operativo de Netrwork Cisco (IOS) los comandos son instrumentos útiles para comprobar la performance de routers Cisco e switches en un ambiente de prueba.

Traffic-generation tools usted también puede usar un analizador de protocolo para supervisar su nuevo diseño. Un analizador de protocolo puede ayudarle a analizar comportamiento de tráfico, errores, utilización, eficacia, y ratios de los paquetes broadcast y multicast. Usted también puede usar un analizador de protocolo para generar el tráfico. Si es poco práctico comprar, instalar, y configurar todos los dispositivos requeridos desarrollar un prototipo en gran escala, usted puede comprar un subconjunto de los dispositivos y generar el tráfico para inducir la carga que estaría presente si todos los dispositivos fueran instalados. Este le dará una aproximación del comportamiento del nuevo sistema.

Dependiendo del paquete de prueba para la red del proyecto, en vez de usar un analizador de protocolo para generar tráfico, usted puede usar generadores de tráfico de multipuerto poderosos. Estos instrumentos pueden enviar corrientes múltiples del tráfico de red, emular protocolos, y analizar la performance y la conformidad a especificaciones de estándares.

Marcos Huerta S.

251


Modeling and simulation tools para un modelo sofisticado del nuevo sistema de red, usted puede usar instrumentos de simulación y modelado. La simulación es el proceso de usar software y modelos matemáticos para analizar el comportamiento de una red sin requerir una red actual. Un instrumento de simulación le deja desarrollar un modelo de una red, estimar la performance de la red, y comparar alternativas para poner en práctica la red. Un instrumento de simulación, de ser exacto, es a menudo preferible a realización y medición de un sistema de prototipo extenso porque esto permite que alternativas sean más fácilmente comparadas.

Un instrumento de simulación bueno es un buen desarrollo para comprender la gestión de redes de computadora, análisis estadístico y tecnicas de modelado. Como una simulación completa de un sistema requeriría que el simulador fuera más poderoso que la suma de los componentes que esto modela, un instrumento de simulación sofisticado permite el desarrollo de un modelo que los factores en sólo aquellos aspectos de la red que tienen un impacto significativo en la performance. El desarrollo de instrumentos de simulación buenos es un arte que requiere la gran conciencia de como las verdaderas redes y los componentes trabajan y se relacionan.

Los instrumentos de simulación eficaces incluyen bibliotecas de dispositivo que modelan el comportamiento de los dispositivos conectados a una red (por ejemplo, switches y routers). Como las limitaciones de performance de switches y routers a menudo provienen del camino procesos, buffers, y las colas son puestas en práctica, el switch y los modelos de router deberían tener la arquitectura en cuenta del dispositivo.

El modelado de switche y router puede ser desafiante, sin embargo, porque cada vendedor tiene numerosas técnicas de optimización y opciones de configuración. Una solución con este problema consiste en que un instrumento de simulación puede incorporar medidas del tráfico de red actual, más bien que confiar únicamente en bibliotecas de dispositivo que modelan el comportamiento de dispositivo teórico. Este acercamiento no sólo soluciona el problema de modelar dispositivos complejos, sino también permite que el instrumento calibre asunciones hechas sobre carga de tráfico y características. Hay menos confianza en el diseñador de red para predecir exactamente la carga de tráfico, y más confianza en verdaderas medidas.

QoS and Service-level-management tools analizan la performance de punta a punta para aplicaciones de red. NetPredictor del NetPredict, Inc, es el instrumento de dirección de nivel de servicio y un QoS. Algunos instrumentos, como el software VitalSuite de Tecnologías Lucent, supervisan la performance de aplicación de tiempo real. Otros instrumentos predicen la performance de nuevas aplicaciones antes de que ellos sean

Marcos Huerta S.

252


desplegados. El NetPredictor combina las capacidades de escucha y predicción. El NetPredictor es descrito más detalladamente en la siguiente sección.

Instrumentos Específicos para Probar un Diseño de Red Esta sección recomienda algunos instrumentos específicos que pueden ser usados para probar su diseño de red. Además de los instrumentos puestos en una lista aquí usted también puede usar muchos de los instrumentos hablados en el Capítulo 3, "Caracterizando las Interredes Existentes," y el Capítulo 9, "Desarrollando Estrategias de Manejo de Red."

CiscoWorks Internetwork Performance Monitor El capítulo 3 mencionó el CiscoWorks Internetwork Performance Monitor (IPM), que es un instrumento de administración de red que localiza cuellos de botella, mide el tiempo de respuesta, y diagnostica problemas de latencia. El IPM está disponible como un componente del CiscoWorks Solución de Administración de Ruteo WAN. Trabajando con caracteristicas del Cisco IOS Software, IPM puede identificar los caminos posibles entre dos dispositivos y mostrar la performance para cada uno de los saltos en los caminos. El IPM tiene tres componentes: v El software procesa en el Cisco IOS Software que realizan medidas de tiempo de respuesta (SAA). v Una aplicación gráfica que corre en un NMS y colecciona y almacena datos en varios formatos de base de datos relacional estándares de industria. v El software que corre en un ordenador central que tiene medidas de tiempo de respuesta de un router en la red al ordenador central.

WANDL's Network-Planning and Analysis Tools WANDL, Inc, desarrollado la suite de software NPAT para ayudar a clientes para manejar el diseño, planificación, y manejo de WANs en gran escala. Los clientes del WANDL, que incluyen a portadores, Fortuna 500 compañías, y organizaciones del gobierno, usan NPAT para planear y analizar redes que se extienden en el tamaño de 30 a más de 300 nodos de backbone.

Los instrumentos WANDL soportan capacidad de planificación, pruebas de red, y optimización. Ellos permiten que un usuario pruebe la redundancia de una red y analice los efectos de interrupciones de red. Ellos facilitan analizar alternativas para tecnologías WAN con sofisticado y sin instrumentos de análisis. Una caractersitica único de los instrumentos WANDL es la capacidad de estimar gastos de tarifa mensuales para el recorrido WAN.

Marcos Huerta S.

253


OPNET Technologies El software de Tecnologías de OPNET empotra el conocimiento experto sobre como los dispositivos de red, los protocolos, las aplicaciones, y los servidores funcionan. Esta inteligencia permite a usuarios optimizar la performance y la disponibilidad de sus redes y aplicaciones. El Modelador de OPNET es un ambiente de desarrollo de tecnología de red que permite que usuarios diseñen y estudien sistemas de red. El modelador orientado por objeto modelando acercamiento y editores gráficos refleja la estructura de redes actuales y componentes de red. El OPNET IT el Gurú es otro producto de OPNET que modela Cisco y las configuraciones de dispositivo de otros vendedores e incluye instrumentos para tomar datos capturados y analizar qué componentes son los cuellos de botella.

Agilent's RouterTester Agilent’s RouterTester es un sistema de prueba poderoso y flexible para generar corrientes de tráfico y probar el diseño de red y enrutar la escalabilidad. El sistema RouterTester puede generar IPv4 y IPv6, la señalización, el multicast, y la construcción de un túnel del tráfico de protocolo sobre una amplia variedad del Paquete sobre SONET (POS), ATM, e interfaces de Ethernet. Esto tiene la capacidad de manejar hasta 2000 corrientes individuales por puerto. Esto también incluye instrumentos para enviar corrientes de tráfico realistas, construyendo configuraciones de prueba grandes, realizando QoS y medidas de performance, y verificando la realización de protocolo correcta.

NetIQ Voice and Video Management Solution El NetIQ tiene numerosos productos para planear mejoras de red y probar diseños de red. Los productos de NetIQ que ayudan a un diseñador de red a tasar si una red puede manejar voz y aplicaciones de vídeo son sobre todo provechosos. El Asesor Vivinet de NetIQ, en particular, puede ayudarle a determinar rápidamente y fácilmente como bien trabajara VoIP en una red antes del despliegue. El Asesor de Vivinet predice la calidad de llamada total que usted puede esperar de la red y genera informes que detallan la preparación VoIP de la red.

NetPredict's NetPredictor NetPredictor es para performance y el instrumento de manejo de nivel de servicio que predice y supervisa el QoS proporcionado por una red, cuando sería percibido por un usuario. El NetPredictor analiza los efectos interrelacionados en aplicaciones de red de latencia de punta a punta, carga, y pérdida de paquete. Esto basa su análisis en modelos tanto de red como de comportamiento de protocolo que son automáticamente calibrados por dirección de red actual y datos de analizador de protocolo. El NetPredictor facilita las tareas de diseño siguientes:

Marcos Huerta S.

254


v La determinación que red y los recursos de servidor son necesarios para entregar un nivel de QoS requerido. v La predicción de performance de punta a punta antes de despliegue de nuevas aplicaciones o tecnologías. v El desarrollo de acuerdos de nivel de servicio (SLAs) basado en predicciones de performance verificables. v La escucha de performance actual y comparándolo con expectativas o SLAs.

El NetPredictor le deja modelar una red existente y luego simular la sustitución dispositivos existentes con otros componentes de red para determinar como la performance cambiará. El modelo puede estar basado en el conocimiento sobre la red y aplicaciones que usted proporciona, e información de una biblioteca de dispositivo. El modelo automáticamente se adapta a datos que NetPredictor captura de la red actual.

La aproximación de adaptación modela han sido usados extensivamente en muchas otras industrias (por ejemplo, las industrias que tratan sustancias químicas y aeroespaciales). El NetPredictor es el primer producto basado en un acercamiento de adaptación modela para el manejo de red.

Optimizar el diseño de red La optimización es un paso de diseño crítico para organizaciones que usan alto ancho de banda y aplicaciones sensibles a la tardanza. Para conseguir los objetivos comerciales, estas organizaciones esperan que sus redes usen el ancho de banda eficazmente, controlen la tardanza y la inquietud, y soporten el servicio preferente para aplicaciones esenciales. Los vendedores de funcionamiento entre redes, como Cisco System, y estándares, como el Instituto de los Eléctricos e Ingenieros Electrónicos (IEEE) y el Internet Engineering Task Force (IETF), ofrecen numerosas opciones para encontrar estas expectativas.

En este punto del proceso de diseño de red top down, usted debería tener un entendimiento sólido de la topología lógica y física de su red. Usted debería saber sobre cualquier enlace que será compartido por aplicaciones con exigencias diferentes, y usted debería haber testeo una implementación piloto del diseño de red para determinar qué enlaces están en la mayor parte de necesidad de técnicas de optimización.

Este capítulo cubre soluciones de optimización. Esto asume que usted ha analizado ya requerimientos, sobre todo de requerimientos de aplicación para tardanza baja o rendimiento alto. Como mencionado en el Capítulo 4, "Caracterizando el Tráfico de Red," durante las fases tempranas de un proyecto de diseño, usted debería trabajar con su

Marcos Huerta S.

255


cliente para clasificar aplicaciones de red en categorías de servicio de modo que usted pueda determinar qué optimización y las opciones de calidad del servicio (QoS) que las aplicaciones requerirán. Después de que usted ha clasificado una aplicación, usted debería rellenar "la columna" de Exigencias de QoS en la Tabla 4-4, "Características de Tráfico de Aplicaciones de Red." Como mencionado en el Capítulo 2, "Analizando Objetivos Técnicos y Compensaciones," usted también debería rellenar rendimiento de aplicación y objetivos de tardanza en la Tabla 2-3, "Aplicaciones de Red Exigencias Técnicas."

El capítulo comienza con una discusión de técnicas de IP multicast que minimizan la utilización de ancho de banda para aplicaciones multimedia. Reducir la tardanza es también importante para aplicaciones multimedia que son sensibles para tardar, como voz y vídeo. "La sección" de Tardanza de Adaptación que Reduce describe algunos métodos para asegurar que la tardanza es minimizada.

El capítulo sigue con una discusión de métodos para optimizar la performance de red para encontrar requerimientos de QoS. Estos métodos permiten que aplicaciones informen al router de su carga y requerimientos de latencia, y dejen al router compartir la información de QoS entre sí y con servidores de política. Más tarde en este capítulo, una sección llamada "Caracteristicas de Sistema Operativo de redes de Cisco para Optimizar Performance de Red" describe una surtida técnicas de optimización ofrecidas por Cisco, incluso conmutación avanzada, formación de cola de espera, y técnicas que forman tráfico.

La Optimización del Uso de Anchode banda con Tecnologías de IP Multicast Una de las principales razones de optimizar las técnicas en redes es el uso creciente del alto ancho de banda, usuario múltiple, aplicaciones multimedia. Tales aplicaciones como aprendizaje de distancia, videoconferencia, e informática de colaboración tienen una necesidad de enviar corrientes de datos a usuarios múltiples, sin usar cantidades excesivas del ancho de banda o causar problemas de performance en muchos sistemas.

El IETF ha desarrollado varios estándares de IP de multicast que optimizan la transmisión de multimedia y otros tipos del tráfico a través de unas redes. Los estándares identifican el multicast dirigiéndose a técnicas que evitan el tráfico suplementario causado por mucho punto a punto unicast o transmiten corrientes de tráfico. Ellos también especifican como los routers aprenden ha conectarse a los segmentos de red que debería recibir corrientes de multicast y como los routers enrutan el trafico multiechó.

Marcos Huerta S.

256


Las aplicaciones multimedia más viejas que no usan tecnologías de multicast, para instancia la aplicación que aprende distancia discutido en el ejemplo de Centro Universitario de Valle Errante en el Capítulo 10, "Seleccionando Tecnología y Dispositivos para Redes de Campus," envían una corriente de datos a cada usuario. Tales aplicaciones usan un método de punto a punto unicast de manejar el tráfico multimedia que ancho de banda.

Una alternativa a corrientes de punto a punto múltiples debe enviar una corriente sola y el uso una dirección de destino de broadcast. La desventaja obvia con esta técnica es que la corriente de datos va a todos los dispositivos, hasta dispositivos para los cuales ninguna aplicación es instalada para manejar la corriente. Este acercamiento tiene un efecto negativo en la performance para cada dispositivo que recibe la corriente, incluso estaciones de trabajo, switches, y routers.

Con tecnologías de IP multicast, por otra parte, una corriente de datos sola es enviada a sólo aquellas estaciones que solicitan la corriente, así optimizando el uso de ancho de banda y reduciendo problemas de performance en estaciones finales y dispositivos de funcionamiento entre redes.

Los negocios, las universidades, y otras organizaciones usan tecnologías de IP multicast para muchas aplicaciones de diseminación de información, incluso clases de formación en línea, reuniones virtuales, y noticiarios electrónicos. Además, las tecnologías de IP multicast son usadas en aplicaciones de simulación de computadora. Un ejemplo es simuladar escenarios militares. Como es poco práctico prepararse para batallas en gran escala con el verdadero equipo, alguna conducta de instituciones militar que entrena ejercicios con miles de aviones simulados, tanques, tropas, satélites meteorológicos, y otros dispositivos. Un avión o el tanque pueden registrarse para recibir el tiempo y la información de topografía para su posición corriente afiliándose a un grupo de IP multicast para aquella posición. Como los movimientos planos, esto abandona y se afilia a nuevos grupos. De estos camino el avión puede evitar recibir la información en el tiempo y topografía para todas las áreas (que sería aplastante), y en cambio reciba la información relevante sólo a su posición corriente. Este tipo de la aplicación debe soportar la dirección de multicast y el ingreso de grupo de multicast dinámico, de que hablaremos en las siguientes secciones.

IP Multicast Addressing El direccionamiento IP Multicast transmite datos IP a un grupo de host que son identificados por una Clase D de dirección IP. En la nota punteada decimal, reciba la variedad de direcciones de grupo de 224.0.0.0 a 239.255.255.255. Las estaciones de

Marcos Huerta S.

257


red reconocen una dirección como es una Clase D dirección porque primeros cuatro trozos deben ser 1110 en el binario.

Un grupo de multicast también es identificado por una dirección de multicast de capa MAC. La utilización de una dirección de multicast de capa MAC optimiza la performance de red permitiendo a la interfaz de red (NICs) que no son la parte de un grupo no para hacer caso de una corriente de datos que no es para ellos.

Las Autoridades de Números Adjudicadas del Internet (IANA) poseen un bloque de direcciones de capa MAC que son usadas para direcciones de grupo multicast. La variedad de direcciones para Ethernet es 01:00:5E:00:00:00 a 01:00:5E:7F:FF:FF. Cuando una estación envía un paquete a un grupo IP que es identificado por una dirección Clase D, la estación inserta la orden baja 23 bits de la Clase D dirección en la orden baja 23 bits de la dirección de destino de capa MAC. Los 9 primeros bits de la dirección de Clase D no son usados. Los 25 primeros bits de la dirección de MAC son 01:00:5E seguido de 0, o, en el binario, lo siguiente:

00000001 00000000 01011110 0

El Protocolo de Dirección de Grupo de Internet El Protocolo de Dirección de Grupo de Internet (IGMP) permite que un host se afilie a un grupo e informe al router de la necesidad de recibir una corriente de datos particular. Los hosts de IP usan IGMP para reportar su grupo de multicast memberships a los router de vecinos multicast inmediatamente.

Cuando un usuario (o proceso de sistema) comienza una aplicación que requiere que un host se afilie a un grupo de multicast, el host transmite un mensaje de informe de ingreso para informar al router en el segmento que el tráfico para el grupo debería ser multiechado al segmento del host. Aunque sea posible que el router envíe ya datos para el grupo al segmento del host, la especificación declara que un host debería enviar un mensaje de informe de ingreso por si sea el primer miembro del grupo en el segmento de red.

Además del permiso de hosts de afiliarse a grupos, IGMP especifica que un router de multicast envía una pregunta de IGMP a cada interfaz con regularidad para ver si algún host pertenece al grupo. Un host responde enviando a un mensaje de informe de ingreso IGMP para cada grupo en el cual esto es todavía un miembro (basado en las aplicaciones que corren en el anfitrión).

Marcos Huerta S.

258


Para disminuir la utilización de ancho de banda, los hosts ponen un temporizador arbitrario antes de responder a preguntas. Si el host ve a otro host responder para un grupo al cual el host pertenece, entonces el host anula su respuesta. El router no tiene que saber cuantos o qué hosts específicos en un segmento pertenecen a un grupo. Esto sólo tiene que reconocer que un grupo tiene a al menos un miembro en un segmento, de modo que esto envíe el tráfico a aquel segmento usando el IP y direcciones de multicast de MAC para el grupo.

El RFC 2236 define una nueva versión de IGMP: IGMPv2. La caracteristica general de IGMPv2 es la capacidad para un router de aprender más rápidamente el último host ha abandonado un grupo, que es importante para grupos de multicast de alto ancho de banda y subredes con el ingreso de grupo muy volátil. El IGMPv2 soporta un nuevo mensaje, el mensaje de grupo de permiso, que un host puede usar para abandonar explícitamente un grupo. El router puede enviar entonces una pregunta de ingreso para determinar si hay algún host restante en el segmento que es miembros de grupo para el grupo de multicast en particular.

En ausencia, un switch de capa de enlace de datos inunda de paquetes de multicast a cada puerto. El Protocolo de Dirección de Grupo Cisco (CGMP) y el IETF IGMP métodos que fisgonean permite que switches participen en el proceso de determinación qué segmentos tienen a hosts en un grupo de multicast en particular. El CGMP es un método Cisco-patentado que deja a un router enviar un mensaje a switches para decir a los switches sobre informe de ingreso y mensajes de grupo de permiso que ocurren en sus segmentos. El IGMP fisgonear es un estándar IETF que no causa ningún tráfico suplementario, pero permite que un switch aprenda de los mensajes IGMP enviados a los routers.

Protocolos de Enrutamiento de Multicast Además de la determinación qué segmentos de red locales deberían recibir el tráfico para grupos de multicast particulares, un router también debe aprender como enruta el tráfico de multicast en las redes. El protocolo de enrutamiento multicast proporciona esta función.

Mientras que un estándar de protocolo de enrutamiento unicast aprende caminos a redes de destino, un protocolo de enrutamiento multicast aprende caminos para multiechar direcciones de destino. El protocolo de enrutamiento multicast ayuda a los routers a aprender qué interfaces deberían enviar cada corriente de multicast. Esta sección cubre dos protocolos de enrutamiento multicast: Protocolo Multicast el Camino Abierto más Corto Primero (MOSPF) y Protocolo Multicast Independiente (PIM).

Marcos Huerta S.

259


Multicast Open Shortest Path First El MOSPF, que es definido en RFC 1584, es un protocolo de enrutamiento multicast para ambientes OSPF. El MOSPF complementa la capacidad del OSPF de desarrollar una base de datos de estado de enlace que describe una topología de red. El MOSPF complementa la base de datos con un tipo adicional del registro de estado de enlace para el grupo memberships.

Un router que corre MOSPF calcula un árbol de camino más corto a todos los destinos dentro de su área, y luego usa la información de ingreso de grupo anunciada para "prune" las ramas del árbol que no conducen a ningún miembro de grupo. Este proceso permite que el router envie paquetes de multicast sólo a aquellos interfaces que pertenecen al árbol de multicast pruned. El resultado final es la cantidad de tráfico que cruza unas interredes también es "pruned".

El MOSPF es optimizado para un sistema autónomo que tiene un número limitado de grupos (aunque cada grupo pueda ser como grande si es necesario). El MOSPF requiere que un router realice el cálculo de camino más corto para cada nueva combinación de grupo de destino y remitente. Si hay muchas combinaciones, la CPU de un router puede ser sobrecargada por el número de cálculos.

Una otra advertencia con MOSPF tiene que ver con el soporte del OSPF a dividir un sistema autónomo en áreas. La ventaja de áreas, como se hablo en El capítulo 7, "La selección de Conmutación y Encaminamiento de Protocolos," es que ningún router tiene que entender la topología completa de un sistema autónomo. Una compensación es que la encaminamiento multicast es ineficaz en algunos casos.

Si una fuente del tráfico de multicast no está en el área de un router, el router puede construir árboles de camino más corto sólo incompletos entre destinos de grupo y la fuente. La información en cuanto al camino exacto entre el router y la fuente está aproximada, basada en datos de publicación del enlace sumario OSPF (o publicación del enlace externo si la fuente está en un sistema autónomo diferente).

El MOSPF no es conveniente para redes de multiárea grandes o para redes con muchos remitentes de corrientes de multicast. El MOSPF también no es soportado por muchos vendedores de router, incluso Cisco. Por estos motivos, es importante que usted también aprenda sobre PIM, que es cubierto en la siguiente sección.

Protocol-Independent Multicast (PIM) El PIM es otra opción para el encaminamiento de multicast. Como MOSPF, PIM trabaja en el tándem con IGMP; esto también trabaja con un protocolo de

Marcos Huerta S.

260


encaminamiento unicast, como OSPF, Protocolo de Enrutamiento de Información (RIP), Cisco Protocolo Mejorado Interior Realzada que Derrota el Protocolo (EIGRP), etcétera.

El PIM tiene dos modos: modo denso y modo escaso. Los adjetivos densos y escasos se refieren a la densidad de miembros de grupo. Los grupos densos tienen a muchos miembros. Un ejemplo de un grupo denso es empleados en una corporación que escuchan a la compañía el informe trimestral presidencial cuando es multicast en el intranet corporativo. Un grupo escaso podría ser un grupo mucho más pequeño de empleados que se han contratado para un curso particular que aprende distancia.

o

Protocolo de Modo Denso Multicast Independiente PIM de modo denso es similar a un protocolo de modo denso más viejo, el Multicast de Vector de distancia que Derrota el Protocolo (DVMRP), que es descrito en RFC 1075 y es un derivado del RIP. Ambos protocolos usan un camino inverso que expide (a RPF) mecanismo para calcular el camino (inverso) más corto entre una fuente y todos los recipientes posibles de un paquete. PIM de modo denso es más simple que DVMRP, sin embargo, porque esto no requiere el cálculo de derrotar tablas.

Si un router que dirige el modo denso PIM recibe paquetes multicast de una fuente a un grupo, ello primero verifica en el estándar unicast la encaminamiento de la tabla que el interfaz entrante es el que que este usa para enviar paquetes unicast hacia la fuente. Si no es así, este desecha el paquete y devuelve un mensaje nuevo. Si esto es el caso, el router expide una copia del paquete en todos los interfaces para los cuales esto no ha recibido un mensaje nuevo para el par de destino de fuente/grupo. Si no hay tales interfaces, este devuelve un mensaje nuevo.

El primer paquete para un grupo es inundado a todas las interfaces. Después de que este ha ocurrido, sin embargo, los routers escuchan los mensajes pruned para ayudarles a desarrollar un mapa de la red que les envia en paquetes de multicast sólo a aquellas redes que deberían recibir los paquetes. Los mensajes prune también dejan a los routers evitar loops que harían que más de un router enviara un paquete de multicast a un segmento.

El Modo denso PIM trabaja mejor en ambientes con grupos de grandes multicast y una probabilidad alta que cualquier LAN dado tiene a un miembro de grupo, que limita a los router de enviar mensajes pruned. A causa de la

Marcos Huerta S.

261


inundación del primer paquete para un grupo, el modo denso no tiene sentido en ambientes donde unos usuarios escasamente localizados quieren participar en una

aplicación

de

multicast.

En

este

caso,

modo

escaso

multicast

independiente, que es descrito en la siguiente sección, es la mejor solución.

o

Protocolo de Modo Escaso Multicast Independiente El Modo escaso PIM es completamente diferente del modo denso PIM. Más bien que permitir tráfico para ser enviado en todas partes y luego regresa el pruned donde no es necesario, modo escaso PIM define un punto de cita. El punto de cita proporciona un servicio de registro para un grupo de multicast.

PIM de modo escaso confía en IGMP, que deja a un host afiliarse a un grupo enviando un mensaje de informe de ingreso, y separar de un grupo enviando un mensaje de permiso. Un router designado para un segmento de red revisa los reportes y mensajes de permiso en su segmento, y periódicamente envía la juntura y mensajes pruned PIM al punto de cita. La juntura y pruned mensajes son tratados por todos los routers entre el router designado y el punto de cita. El resultado es un árbol de distribución que alcanza a todos los miembros de grupo y es centrado en el punto de cita.

El árbol de distribución para un grupo de multicast es al principio usado para cualquier fuente, pero el modo escaso la especificación de PIM, RFC 2362, también proporciona un mecanismo para dejar al punto de cita desarrollar árboles de la fuente específicos delante de prunning del tráfico de red.

Cuando una fuente al principio envía datos a un grupo, el router designado en la red de la fuente unicasts registra los mensajes al punto de cita con los paquetes de datos de la fuente encapsulados dentro del. Si la velocidad de transferencia de datos es alta, el punto de cita puede enviar join/prune mensajes de regreso hacia la fuente. Este permite a los paquetes de datos de la fuente seguir un árbol de camino más corto de la fuente específica, y elimina la necesidad de los paquetes para ser encapsulados en mensajes de registro. Si los paquetes llegan encapsulados o no, el punto de cita envia

los paquetes de datos

desencapsulados de la fuente bajo el árbol de distribución hacia miembros de grupo.

Reducir Tardanza de Adaptación En enlaces WAN lentos, el tiempo a la salida de un paquete grande es significativo. El tiempo a la salida de un paquete es llamado la tardanza de transmisión o la tardanza de adaptación. La tardanza de adaptación se hace una cuestión cuando un

Marcos Huerta S.

262


enlace WAN es usado por aplicaciones que envían paquetes grandes, como transferencia de archivo, y aplicaciones que son la tardanza sensible, como voz, vídeo, y aplicaciones interactivas como Telnet. Las soluciones con este problema incluyen el uso de la fragmentación de la capa de enlace e intercalando (LFI) y el uso de compresión para la cabecera del paquete multimedia. Esta sección cubre estas soluciones.

o

Fragmentación de Capa de enlace e Intercalar El LFI reduce la tardanza en enlaces WAN lentos rompiendo paquetes grandes e intercalando los pequeños paquetes que resultan con paquetes para aplicaciones que son la tardanza sensible. PPP, Frame Relay, ATM, y otras tecnologías WAN pueden beneficiarse todos de LFI en enlaces de velocidad baja, como 56-Kbps Frame Relay o ISDN 64-Kbps B canales.

El LFI para PPP es definido por el Protocolo de Punto a Punto de Multienlaces (MPPP) estándar, que es 1990 RFC. El LFI para PPP es relativamente simple. Los grandes paquetes encpasulados por el multienlace se ha basado durante 1990 RFC y fragmentar a paquetes de un tamaño bastante pequeño para satisfacer las exigencias de tardanza del tráfico sensible a tardanza. Los pequeños paquetes sensibles a tardanza no son el encapsulado multienlace, pero son intercalados entre fragmentos de los paquetes grandes.

El MPPP permite que los paquetes para ser enviados al mismo tiempo sobre punto a punto múltiple unan para la misma dirección remota. Enlaces múltiples subieron en respuesta a un umbral de carga que usted define. La carga puede ser calculada en tráfico entrante, tráfico que va hacia fuera, o en tampocos, como necesario para el tráfico entre sitios específicos. El MPPP proporciona el ancho de banda a petición y reduce la tardanza en enlaces WAN.

Cuando usted configura MPPP en un router Cisco, los paquetes llegando a un interfaz de salida son clasificados en colas basadas en clasificaciones que usted define. Después de que los paquetes son hechos cola, los paquetes grandes son fragmentados en paquetes más pequeños en la preparación para intercalar con paquetes sensibles a tiempo. Si la feria ponderada que hace cola (WFQ) es configurada para un interfaz, los paquetes de cada cola son intercalados y programados (justamente y basados en su peso) para la transmisión en la cola de interfaz de salida. Para asegurar la orden correcta de transmisión y nueva sesión, LFI añade a la cabecera de multienlace los fragmentos de paquete después de que los paquetes son preparados y listo a ser enviado.

Marcos Huerta S.

263


Además de soportar LFI para usos de MPPP clásicos, como canales de ISDN agregados, Cisco también soporta LFI para Frame Relay y circuitos virtuales ATM. Esta caracteristica pone en práctica LFI que usa MPPP sobre Frame Relay y ATM. El LFI para Frame Relay y ATM soporta Frame Relay de velocidad baja y circuito virtual ATM y Frame Relay/ATM de redes (FRF.8). El LFI para Frame Relay y ATM trabaja simultáneamente con y en el mismo camino de conmutación que otras caracteristicas de QoS, incluso el tráfico de Frame relay que forma (FRTS), latencia baja haciendo cola (LLQ), y ponderada a base de clase que hace cola (CBWFQ).

El Cisco también soprota los tres métodos siguientes para realizar la fragmentación de Frame Relay: v De Punta a punta fragmentación de Frame Relay de acuerdo con el estándar FRF.12. v Fragmentación de Frame Relay de trunk de acuerdo con el Anexo de FRF.11 C estándar. v Cisco fragmentación patentada para encapsulación de voz.

Para más información sobre métodos de fragmentación de Frame relay, refiérase al "Cisco IOS Amplia área que Conecta a la red la Guía de Configuración" y el "Cisco IOS Voz, Vídeo, y Mande por fax la Guía de Configuración."

o

Compresión del Protocolo de Tiempo Real El Protocolo de Tiempo Real (RTP), que es definido en 1889 RFC, proporciona de punta a punta funciones de transporte de red convenientes para transmitir datos de tiempo real sobre multicast o servicios de red de unicast. Las aplicaciones típicamente dirigen RTP encima del Protocolo de Datagrama de Usuario (UDP) para hacer el uso de multiplexión del UDP y servicios de suma de control. Trabajando juntos con UDP, RTP pone en práctica la Capa 4 funcionalidad (de transporte). (UDP no es requerido. El RTP puede ser usado con otra red subyacente conveniente o protocolos de transporte, pero es más usado a menudo con UDP.)

La cabecera de paquete RTP incluye varios campos que especifican los atributos de los datos llevados en el paquete RTP: v El tipo de carga útil indica el formato de la carga útil (por ejemplo, MPEG datos de audio o de vídeo, vídeo de JPEG, una corriente de vídeo H.261).

Marcos Huerta S.

264


v El número de secuencia indica la posición del paquete en la corriente de datos. Los incrementos de número de secuencia por uno para cada paquete de datos RTP enviado, pueden ser usados por el receptor para descubrir la pérdida de paquete y restaurar la secuencia de paquete. v El sello de tiempo refleja el instante de prueba del primer byte en el paquete de datos. v El campo de fuente de sincronización (SSRC) identifica la fuente de una corriente de paquetes RTP (por ejemplo, un micrófono o cámara de vídeo). Todos los paquetes de una parte de forma de fuente de sincronización del mismo cronometraje y secuencia numeran el espacio, entonces unos paquetes de grupos de receptor por SSRC para la repetición. v La lista fuente contribuyente (CSRC) identifica fuentes que han contribuido a la carga útil en el paquete. Una aplicación de ejemplo es audioconferencia, donde el campo de CSRC indica a todos los habladores cuyo discurso fue combinado para producir el paquete saliente.

La cabecera RTP añade la funcionalidad importante que es usada por aplicaciones multimedia, incluso vídeo y voz sobre IP (VoIP). La desventaja de RTP es que esto añade bytes a cada paquete, que puede ser una cuestión cuando un objetivo de diseño es reducir la tardanza de adaptación y minimizar el uso de ancho de banda. La compresión decabecera de RTP reduce la tardanza y salva el ancho de banda de red comprimiendo la cabecera RTP/UDP/IP de 40 bytes a 2 a 4 bytes en un paquete típico. Este es sobre todo beneficioso para enlaces lentos y pequeños paquetes (como el tráfico VoIP), donde

la

compresión

puede

reducir

la

tardanza

de

adaptación

considerablemente.

La Optimización de Performance de Red para Encontrar Calidad de Servicio Además de la optimización del uso de ancho de banda añadiendo el multicast de IP, LFI, y la caracteristica compresión de un diseño de red, usted puede determinar que la optimización también es necesaria para encontrar requerimientos de QoS. "La Calidad de Caracterización de Calidad de Servicios" sección del Capítulo 4 se habló de la especificación del QoS que requiere una aplicación. Esta sección cubre algunas técnicas para encontrar aquellas exigencias.

NOTA El foco de esta sección encuentra los requerimientos de QoS en redes TCP/IP. Para más información en QoS en un ambiente de ATM, ver "la Calidad de ATM de la sección" de Especificaciones de Servicio en el Capítulo 4.

Marcos Huerta S.

265


Como se hablo en el Capítulo 4, el grupo de funcionamiento de Servicios Integrado define dos tipos de servicios que ofrecen aseguramientos QoS más allá del servicio de mejor esfuerzo (que no ofrece ningunos aseguramientos QoS): v El servicio de controlar-carga. Provee un flujo de datos de cliente de QoS que estrechamente se acerca al QoS que el flujo recibiría en una red descargada. El servicio de controlar-carga es requerido para aplicaciones que son muy sensibles para condiciones de sobrecargar. v El servicio garantizado. Proporciona límites firmes en tardanzas de punta a punta que hacen cola paquete. El servicio garantizado es requerido para aplicaciones que necesitan una garantía que un paquete no llegará más tarde del tiempo después de que fue transmitido por su fuente.

Muchas opciones de optimización están disponibles para acomodar aplicaciones con exigencias de garantizar-servicio o controlar-carga. Las siguientes secciones describen algunas de estas opciones, que comienzan con uno que ha estado disponible durante muchos años: la precedencia y funcionalidad de tipo de servicio incorporada al paquete IP.

o

Precedencia de IP y Tipo de Servicio Aunque las caracteristicas especializadas para apoyar QoS se han hecho recientemente un tema caliente de la conversación entre ingenieros de red y diseñadores, el concepto que una red debe soportar aplicaciones con requerimientos variantes para el servicio. De hecho, los creadores de IP que el soporte incorporado a niveles diferentes de precedencia y tipos del servicio en el paquete IP formatea cuando IP fue primero desarrollado en los años 1970. La figura 13-1 muestra los campos en la cabecera de la versión 4 (IPv4) IP, con un énfasis en el byte de tipo de servicio cerca del principio de la cabecera.

Figure 13-1. The Internet Protocol (IP) Header

Marcos Huerta S.

266


El byte de tipo de servicio IP especifica tanto precedencia como el tipo del servicio. La precedencia ayuda a un router a determinar que paquete enviar cuando varios paquetes son hechos cola para la transmisión al mismo interfaz de salida. El tipo del servicio ayuda a un router a seleccionar un camino de encaminamiento cuando caminos múltiples están disponibles.

El byte de tipo de servicio es dividido en dos campos, (que son seguidos de un poco que siempre es puesto al cero): El campo de precedencia de 3 bits soporta ocho niveles de la prioridad. El campo de tipo de servicio de 4 bits soporta cuatro tipos del servicio.

El Campo de Precedencia IP Una aplicación puede usar el campo de precedencia para especificar la importancia de un paquete. La importancia puede extenderse de la prioridad rutinaria (los bits son puestos a 000) a la prioridad alta (los bits son puestos a 111).

Uno de los usos originales previstos para el campo de precedencia era el control de congestión. Dando a paquetes de control de congestión una precedencia de 7 (111 en el binario), una aplicación puede especificar que los paquetes de control de congestión son más importantes que paquetes de datos, así facilitando la eficacia del mecanismo de control de congestión. Seleccionando una precedencia de 7, la aplicación con esperanza asegura que los paquetes de control de congestión no son afectados por la congestión que ellos tratan de controlar.

La precedencia valora 6 y 7 son reservados para red y paquetes de control de redes. Los valores 0 a 5 pueden ser usados para datos de usuario y aplicaciones. Algunos abastecedores de servicio ofrecen un servicio superior que usa el campo de precedencia para marcar el tráfico de un cliente como datos prioritarios. Muchos routers, y algunos hots, soporta que configura la precedencia para aplicaciones. El valor de precedencia es típicamente puesto a 5 para VoIP y otras aplicaciones de tiempo real.

El Campo de Tipo de servicio IP El objetivo del campo de tipo de servicio es ayudar a un router a seleccionar una ruta de un juego de rutas con características diferentes. El encaminamiento de protocolos intenta determinar "la mejor" ruta a un destino, pero hay varias definiciones "de mejor": el más barato, el más rápido, el más confiable, etcétera.

Marcos Huerta S.

267


En la teoría, un protocolo de encaminamiento debería ser capaz de seleccionar una ruta basada en el tipo de servicio que una aplicación especifica. El campo de tipo de servicio dentro del byte de tipo de servicio en una cabecera IP tiene cuatro bits (ver la Figura 13-1): El bit de tardanza (D). Dice a routers minimizar la tardanza El bit de rendimiento (T). Dice a routers maximizar el rendimiento El bit de fiabilidad (R). Dice a routers maximizar la fiabilidad El bit de coste (C). Dice a routers minimizar el coste monetario

Según RFC 1349, que clarificó el uso del byte de tipo de servicio (pero es obsoleto ahora), una aplicación puede poner un (y sólo un) de los cuatro bits de tipo de servicio decir al router el camino al destino como manejar el paquete. Un host también puede usar los bits de tipo de servicio para decidirse que firman con las iniciales el camino a un router local para seleccionar. Si todos cuatro bits son cero, el servicio rutinario es implicado.

En la práctica, el encaminamiento de protocolos y routers nunca tenía métodos buenos para dirigirse las necesidades de aplicaciones que ponen los bits de tipo de servicio. Seleccionando un camino basado en el ajuste del D, T, R, o bits de C resultó ser poco práctico. Aunque las versiones tempranas del Camino Abierto más Corto Primero (OSPF) y Protocolo de Entrada Fronterizo (BGP) encaminamiento de protocolos soporta especifica a los bits, las nuevas versiones del OSPF y especificaciones BGP no requieran el soporte basadas en el ajuste de los bits.

El Servicio Diferenciado IP de Campo El RFC 1349 fue declarado obsoleto con la publicación de RFC 2474, "Definición del Campo de Servicios Diferenciado (Campo de DS) en el IPv4 y Cabecera IPv6," y RFC 2475, "una Arquitectura para Servicios Diferenciados." Por estos nuevos RFCs, el byte de tipo de servicio se hizo los Servicios Diferenciados (DS) campo. Los bits 0 por 5 de aquel campo son llamados los servicios diferenciados codepoint (DSCP), como mostrado en la Figura 13-2. (Por RFC 2481, los bits 6 y 7 son designados como el campo de Notificación de Congestión Explícito, que está más allá del alcance de esta discusión.)

Marcos Huerta S.

268


Figure 13-2. The Differentiated Services (DS) Field

El DSCP tiene esencialmente el mismo objetivo que el campo de precedencia, que debe influir en formación de una cola de espera y decisiones que dejan caer paquete para paquetes IP en un interfaz de salida de un router. El RFC 2474 se refiere a estas decisiones comportamientos como por salto (PHBs). El DSCP puede tener 1 de 64 valores posibles, cada uno de los cuales perfila un PHB. El campo de DSCP es hacia atrás compatible con el campo de precedencia. Ninguna tentativa fue hecha para retener la compatibilidad con el campo de tipo de servicio, sin embargo.

La Versión 6 de IP QoS El IPv6 realza la capacidad de hosts y routers para poner en práctica niveles variantes de QoS para flujos de tráfico diferentes por la inclusión en la cabecera IPv6 un campo de etiqueta de flujo que identifica flujos de paquete individuales. Un host de la fuente adjudica una etiqueta de flujo a cada flujo de aplicación. Un router IPv6-compatible puede tratar teóricamente la cabecera IPv6 de cada paquete y mantener un escondite de la información de flujo, puesta índice por la dirección de la fuente y fluir la etiqueta. Este proceso facilita un router que pone en práctica caracteristicas de QoS para flujos de tráfico individuales.

Además, la cabecera IPv6 incluye un campo de clase de tráfico de 8 bits. Este campo toma la responsabilidad de los bits de precedencia IP de la cabecera IPv4. El campo de clase de tráfico está disponible para el uso originando nodos o expidiendo a routers para identificarse y distinguirse entre clases diferentes o prioridades de paquetes IPv6. Las definiciones detalladas de la sintaxis y la semántica de los bits de clase de tráfico IPv6 no están todavía disponibles, pero hay alguna esperanza que el IETF y los vendedores encontrarán el campo útil para poner en práctica QoS.

El Protocolo de Reservación de Recurso El Protocolo de Reservación de Recurso (RSVP) complementa el tipo de servicio IP, precedencia, DSCP, y capacidades de clase de tráfico inherentes en una cabecera IP. El RSVP soporta mecanismos más sofisticados para hosts para especificar requerimientos QoS para flujos de tráfico individuales. El RSVP

Marcos Huerta S.

269


puede ser desplegado en LANs y empresa WANs para soportar aplicaciones multimedia u otros tipos de aplicaciones con requerimientos de QoS estrictas.

Tanto las capacidades de tipo de servicio de cabecera IP como RSVP son ejemplos de protocolos de QoS señalados. La señalización de QoS es un medio de entregar requerimientos de QoS a través de una red. El byte de tipo de servicio en la cabecera IP ofrece la señalización en cinta, significando que los bits dentro de la cabecera del paquete hacen señas a routers como el paquete debería ser manejado. El RSVP ofrece la señalización de cinta, significando que los hosts envían paquetes adicionales, más allá de paquetes de datos, indicar que un cierto servicio QoS es deseado para un flujo de tráfico particular.

El RSVP es un protocolo de sistema usado por un host para solicitar calidades específicas del servicio de la red para corrientes de datos de aplicación particulares o flujos. El RSVP también es usado por routers para entregar peticiones de QoS a otros routers a lo largo del camino de un flujo. El RSVP funciona encima de la versión 4 o 6 IP, ocupando el lugar de un protocolo de transporte en la pila de protocolo (aunque esto no transporte datos de aplicación).

El RSVP no es un protocolo de encaminamiento; esto funciona en el tándem con

unicast

y

multicast

protocolos.

Mientras

que

un

protocolo

de

encaminamiento determina donde los paquetes son enviados, RSVP está preocupado por el QoS que aquellos paquetes reciben. El RSVP consulta unicast local o el multicast que la base de datos para obtener rutas. En el caso de multicast, por ejemplo, un host envía mensajes IGMP para afiliarse a un grupo de multicast y luego envía mensajes RSVP para reservar recursos a lo largo del camino de entrega [s] para aquel grupo.

Según la especificación RSVP, un receptor es responsable de solicitar QoS específico, no una fuente. La puesta de la responsabilidad en el receptor deja a RSVP más fácilmente acomodar grupos grandes, ingreso de grupo dinámico, y requerimientos de receptor heterogéneas.

Una aplicación que reside en un host de receptor pasa una petición de QoS al proceso de RSVP local. El protocolo RSVP entonces lleva la petición a todos los nodos (routers y hosts) a lo largo del camino (s) de datos inverso a la fuente (s) de datos (sólo por lo que el router localizó donde el camino de datos del receptor se afilia al árbol de distribución de multicast). Las peticiones de RSVP deberían causar recursos reservados en cada nodo a lo largo del camino.

Marcos Huerta S.

270


El RSVP proporciona una instalación general para crear y mantener la información en reservaciones de recurso a través de una malla de unicast o caminos de entrega de multicast. El RSVP transfiere parámetros QoS, pero no define los parámetros o los tipos diferentes de servicios que una aplicación puede solicitar. El RSVP simplemente pasa parámetros a los módulos de control de política y control de tráfico apropiados para la performance. Como se hablo en el Capítulo 4, el grupo de funcionamiento de Servicios Integrado describe servicios en RFCs 2210 a 2216.

Como la parte de la fase de análisis de requerimientos de la red diseñan el proceso, usted debería haber identificado aplicaciones que pueden beneficiarse de RSVP. Usted también debería haber seleccionado routers para poner en práctica el diseño durante la fase de diseño física. En este punto en el proceso de diseño, analice sus selecciones y tome otra mirada a la topología de red para asegurarse routers que soporta RSVP están disponibles a las aplicaciones que lo necesitan. Para RSVP para ser eficaz, cada router en el camino de un receptor a una fuente debe soportar RSVP, incluso routers en caminos redundantes que pueden entrar en el servicio durante interrupciones de red o cuando la carga de tráfico es alta.

NOTA Recuerde, conecte a la red el diseño es un proceso iterativo que permite que usted ajuste sus proyectos cuando usted considera los detalles y ramificaciones de opciones hechos hasta ahora.

Considerando RSVP, estar seguro para leer RFC 2208 (o cualquier actualización publicada después de publicación de este libro). RFC 2208, "la Declaración de Aplicabilidad de la Versión 1 de Protocolo de Reservación de Recurso," indica los problemas con el correr de RSVP en un router de backbone que agrega el tráfico de muchas redes. Los requerimientos de almacenaje y procesamiento para dirigir RSVP en un router aumentan proporcionalmente con el número de sesiones separadas y reservaciones RSVP. Apoyar RSVP en un router de backbone crítico que maneja muchas corrientes de datos puede agravar en exceso en el router, y es poco aconsejable.

Las técnicas están siendo desarrolladas lo que agregará corrientes que requieren un servicio específico en "el borde" de un backbone. Dentro del backbone, varios acercamientos menos costosos pueden ser usados entonces para poner recursos aparte para una corriente agregada. Hasta que estas

Marcos Huerta S.

271


técnicas sean desarrolladas, RSVP debería ser desplegado en LANs y empresa WANs donde no hay ninguna necesidad de ningún router para tratar numerosas reservaciones.

El RSVP es más satisfecho para el intranet privado que el Internet u otras redes públicas que cruzan los dominos de abastecedores de servicio múltiples. No sólo hay cuestiones de escalabilidad asociadas con la cantidad de información que los routers deben mantener para cada sesión RSVP, hay también las preocupaciones económicas. Un abastecedor de servicio podría querer proporcionar recursos (ancho de banda y bajo retardo, por ejemplo) que otro abastecedor de servicio no es equipado para ofrecer. Un abastecedor no podría tener la capacidad para ofrecer los servicios o los procedimientos para facturar a clientes para ellos.

Además, RSVP es mejor satisfecho para flujos largos, como aquellos presentan en aplicaciones de vídeo. Aproximadamente el 60 por ciento del tráfico de Internet hoy consiste en flujos de duración corta. Por estos motivos, RSVP es más apropiado para redes privadas que para el Internet (aunque este pueda cambiarse del futuro como aplicaciones en el cambio de Internet y más progreso es hecho en métodos para abastecedores para cooperar).

o

El Protocolo de Servicio de Política Abierto Común Como mencionado en la sección anterior, RSVP simplemente transporta peticiones de QoS y proporciona técnicas para routers para mantener la información sobre el estado de reservaciones de recurso. Para RSVP para ser eficaz, esto necesita el soporte de protocolos adicionales que entienden servicios actuales y políticas en cuanto a los servicios. Un tal protocolo es el Servicio de Política Abierto Común (PILLA) el protocolo, que es especificado en RFC 2748.

COPS define un modelo de cliente/servidor simple para soportar el control de política con QoS protocolos señalados como RSVP. El COPS la especificación describe un protocolo de pregunta-y-respuesta básico que puede estar acostumbrada a la información de política cambiaria entre un servidor de política y sus clientes, que serán típicamente routers RSVP.

El COPS llamada las especificaciónes de un servidor de política un punto de decisión de política, o PDP. Llama un cliente un punto de imposición de política, o PEP. El protocolo deja a una PEP enviar peticiones, actualizaciones, y suprime a PDP remoto, y deja a las decisiones de vuelta de PDP a la PDP. En

Marcos Huerta S.

272


esta manera, los routers RSVP-basados pueden intercambiar la información con servidores centralizados que almacenan las políticas QoS de una red, y aprenden a manejar correctamente flujos para los cuales los recursos han sido reservados. Los soportes de Cisco COPS en muchos de sus routers también proporcionan el software de servidor llamado Cisco QoS Gerente de Política.

o

Clasificación del Tráfico LAN El IEEE especifica un método para etiquetar paquetes de LAN con una clase de servicio (COS) en su 802.1 documento, "Estándar para la Red de Área Local MAC (Control de Acceso de Medios) Puentes." Las COPS para paquetes de LAN fueron al principio publicadas como un suplemento a 802.1 que fue llamado 802.1p. La mayor parte de vendedores todavía se refieren a la tecnología como 802.1p, y este libro sigue llamándolo 802.1p. 802.1p especifica mecanismos para switches para acelerar la entrega del tráfico crítico de tiempo y limitar el grado del tráfico de multicast de ancho de banda alta dentro de un LAN cambiado.

El IEEE 802.1p proporciona QoS en cinta el método señalado para clasificar tráfico sobre la base de MAC enmarca la información. Esto también especifica un mecanismo de protocolo opcional en switches para soportar estaciones de final que dinámicamente se registran para la entrega de paquetes crítico de tiempo o filtran servicios. Los protocolos opcionales entre switches para comunicar información de registro en un LAN cambiado también son soportados.

El IEEE 802.1p soporta ocho clases del servicio. Un valor de 0 servicio de rutina de medios (en otras palabras, ninguna prioridad). Los switches diferentes dentro de un LAN, y puertos hasta diferentes en switches, pueden ser configurados para un número diferente de niveles de prioridad. Un switch debería tener una cola separada para cada nivel de prioridad usado por un puerto.

NOTA Podría ser argumentado que las LANs no necesitan caracteristicas de QoS. Las LANs que han sido emigrados a tecnologías cambiadas y altas velocidades, como Ethernet 100-Mbps y Gigabit, a menudo tienen la capacidad excedente. Sin embargo, cuando las redes de backbone y los segmentos de uplink a capas superiores de una topología jerárquica son considerados, se hace claro que los métodos de QoS son necesarios en redes de empresa así como LANs. Cuando las nuevas multimedia conectados a una red y las aplicaciones de voz se hacen una parte central de prácticas comerciales normales, las LANs de campus

Marcos Huerta S.

273


cambiados pueden aprovechar 802.1p capacidades, además de las otras capacidades ya cubiertas en este capítulo.

Caracteristicas de Sistema Operativo de Redes Cisco para Optimizar la Performance de Red El Software del Sistema Operativo de redes Cisco (IOS) proporciona una caja de herramientas técnicas de optimización para ayudarle a encontrar los desafíos relacionados con demandas de tráfico crecientes en redes de empresa y campus. Las técnicas incluyen servicios avanzados conmutadores y que hacen cola para mejorar el rendimiento y ofrecer la funcionalidad QoS.

o

Técnicas de Conmutación Además del correr el protocolos de enrutamiento para desarrollar una topología de encaminamiento, el trabajo principal de un router debe cambiar paquetes de interfaces entrantes a interfaces salientes. La conmutación implica recibir un paquete, determinando como enviar el paquete basado en la topología de enrutamiento y QoS y reuqerimiento de política, y conmutación del paquete al interfaz saliente o interfaces. La velocidad en la cual un router puede realizar esta tarea es un factor principal en la determinación de la performance de red en una red ruteada. Cisco soporta muchos métodos de conmutación, con velocidades variantes y comportamientos. Esta sección describe algunos de estos métodos de conmutación.

En general, usted debería usar el método de conmutación más rápido disponible para un tipo de interfaz y protocolo. La utilización de un modo de conmutación rápido es sobre todo importante en backbone y routers de empresa principales. Según la versión del Software IOS usted corre, el modo más rápido podría tener que ser configurado. (Es no siempre la falta.) Usted también puede tener que mirar el uso de memoria. Los métodos de conmutación más rápidos usan más memoria, entonces después de permitir a uno de ellos, estar seguros para supervisar la memoria libre en el router durante un breve tiempo después.

NOTA Ver la documentación Cisco para más información sobre los métodos apoyados para varias plataformas de routers, protocolos, e interfaces. La documentación para productos Cisco está disponible en línea en:

www.cisco.com/univercd/home/home.htm.

Marcos Huerta S.

274


Esta sección comienza describiendo los más viejos, pero todavía usado, tecnologías para la Capa 3 conmutación, llamada los métodos clásicos para la conmutación, y sigue con dos tecnologías nuevas: conmutación de NetFlow y Expreso de Cisco que envia (a CEF).

o

Métodos Clásicos de Conmutación de Paquete para la Capa 3 La conmutación de proceso es la más lenta de los métodos de conmutación. Con la conmutación de proceso, cuando un procesador de interfaz recibe un paquete entrante, esto transfiere el paquete a la memoria de entrada/salida en el router. El procesador de interfaz también genera, recibe y interrumpe el procesador central. El procesador central determina el tipo de paquete y lo coloca en la cola de entrada apropiada. Por ejemplo, si esto es un paquete IP, el procesador central coloca el paquete en la cola de ip_input. La próxima vez que Cisco IOS, nota el paquete en la cola de entrada, y programa el proceso apropiado para correr. Por ejemplo, para un paquete IP, este programa el proceso de ip_input para correr.

El proceso de entrada, después de que el planificador lo dice correr, mira en la tabla de enrutamiento para determinar el interfaz de salida que debería ser usado para la Capa 3 dirección de destino en el paquete. El proceso vuelve a escribir el paquete con la cabecera de capa de enlace de datos correcto para aquel interfaz y copia el paquete al interfaz. Este también coloca una entrada en el escondite rápido que cambia de modo que los paquetes subsecuentes para el destino puedan usar rápido la conmutación.

Note que la decisión de transporte de mercancías es tomada por un proceso programado por el Cisco IOS planificador. Este proceso corre como un par a otros procesos que corren en el router, como el protocolo de enrutamiento. Los procesos que normalmente corren en el router no son interrumpidos al switch de procesar un paquete. Este hace el proceso que sea lento.

La conmutación rápida permite el rendimiento más alto cambiando un paquete usando una entrada en el escondite rápido que fue creado cuando un paquete anterior al mismo destino fue tratado. Con la conmutación rápida, un paquete es manejado inmediatamente. El procesador de interfaz genera, recibe y interrumpe. Durante esta interrumpción, el procesador central determina el tipo de paquete y luego comienza a cambiar el paquete. El proceso que actualmente corre en el procesador es interrumpido para cambiar el paquete. Los paquetes son cambiados a petición, más bien que cambiados sólo cuando el proceso de transporte de mercancías puede ser programado. Basado en la información en

Marcos Huerta S.

275


el escondite rápido que cambia, la cabecera de capa de enlace de datos es vuelto a escribir y el paquete es enviado al interfaz saliente esto atiende el destino.

NOTA Si usted usa la carga compartida a través de interfaces múltiples con la conmutación rápida permitida, la carga no puede ser equilibrada igualmente si una parte grande del tráfico va a sólo un destino. Los paquetes para un destino dado siempre salen el mismo interfaz aun si soporta interfaces múltiples. En otras palabras, rápidos cambios de usos de carga por destino que comparte. Si este es un problema, usted debería usar CEF. El CEF soporta tanta carga por destino como por paquete que comparte. Además, con CEF, la carga por destino que comparte está basada en pares de fuente/destino más bien que simplemente la dirección de destino, que puede proporcionar un mejor equilibrio que la conmutación rápida.

La conmutación autónoma está disponible en routers Cisco 7000 de tráfico de serie y usa un escondite autónomo que cambia, localizado en los procesadores de interfaz. La conmutación autónoma proporciona la conmutación de paquete más rápida permitiendo al regulador de Bus Cisco cambiar paquetes independientemente, sin necesidad interrumpir el procesador de sistema.

La conmutación de silicio es similar a la conmutación autónoma, pero acelera la conmutación autónoma por el uso de un escondite que cambia silicio localizado en el Procesador de Interruptor de Silicio (SSP) en algúnos routers de la serie Cisco 7000.

La conmutación óptima es similar a la conmutación rápida, pero es más rápida, debido a un algoritmo caching realzado, y la estructura optimizada del escondite que cambia grado óptimo. La conmutación óptima está disponible sólo en routers equipados con un Procesador de Ruta/Switch (RSP).

La conmutación distribuida es soportada en routers que incluyen el Procesador de Interfaz Versátil (personaje muy importante) u otros de interfaz que pueden recibir la información de ruta del maestro RSP para tomar sus propias decisiones de conmutación autónomas, de múltiples capas. La conmutación distribuida soporta el rendimiento muy rápido porque el proceso de conmutación ocurre en la tarjeta de interfaz.

Marcos Huerta S.

276


o

Conmutación de NetFlow La conmutación de NetFlow es optimizada para ambientes donde los servicios deben ser aplicados a

paquetes

para

poner

en

práctica

seguridad,

caracteristicas de QoS, y contabilidad de tráfico. Un ejemplo de tal ambiente es el límite entre una red de empresa y el Internet.

La conmutación de NetFlow identifica flujos de tráfico entre hosts, y luego rápidamente cambia paquetes en estos flujos al mismo tiempo que esto aplica servicios. El NetFlow que cambia también deja a un administrador de red coleccionar datos del uso de red para permitir la planificación de capacidad y facturar a usuarios basados en red y utilización de recurso de aplicación. La estadística puede ser coleccionada sin hacer más lento el proceso de conmutación.

Para maximizar la escalabilidad de red, una práctica de diseño buena debe usar conmutación NetFlow de periferia de una red para permitir caracteristicas como contabilidad de tráfico, funcionalidad de QoS, y seguridad, y usar un modo de conmutación aún más rápido en el core de la red. En el core de la red, el modo de conmutación debería enviar paquetes basados en la información fácilmente accesible en paquete, y generalmente no debería pasar el tiempo aplicando servicios. El siguiente modo de conmutación cubierto en esta sección, Expreso de Cisco que Envia (a CEF), es optimizado para el core de una red para proporcionar la alta performance, la previsibilidad, la escalabilidad, y la resistencia.

o

Envio Cisco Express El CEF es una técnica Cisco-patentada para cambiar paquetes muy rápidamente a través de redes de backbone grandes y el Internet. Más bien que confiar en las técnicas caching usadas por el clásico que cambia métodos, CEF depende de una base de información de transporte de mercancías (FIB). EL FIB permite que CEF sea mucho menos intensivo de procesador que otro metodo de conmutación de Capa 3 porque las tabla de FIB contienen la información de transporte de mercancías para todas las rutas en las tabla de enrutamiento (mientras que un escondite contiene sólo un subconjunto de información de enrutamiento).

El CEF evolucionó para acomodar aplicaciones a base de web y otras aplicaciones interactivas que son caracterizadas por sesiones de duración corta a direcciones de destino múltiples. El CEF se hizo necesario cuando se hizo

Marcos Huerta S.

277


claro que un sistema a base de escondite no es optimizado para estos tipos de aplicaciones.

Considere una aplicación que hace navega por la web, por ejemplo. Cuando un usuario pasa a un nuevo sitio Web, TCP abre una sesión con una nueva dirección de destino. Es improbable que el nuevo destino está en el escondite del router, a menos que resulte ser un destino el usuario, u otros usuarios, visitados recientemente. Este significa que el primer paquete es el proceso cambiado, que es lento. También, la CPU del router es considerablemente afectada si hay muchos paquetes a nuevos destinos. El CEF mejora la velocidad de conmutación, y evita ser elevado asociado con un escondite que continuamente se cambia, por el uso del FIB, que refleja los contenido enteros de la tabla de enrutamiento IP.

La tecnología de CEF aprovecha la arquitectura distribuida de los routers Cisco de alta calidad, como el Cisco 7500. Distribuido CEF (el DCEF) proporciona cada uno de los Cisco 7500 personajes muy importante con una copia en tarjeta idéntica de la base de datos de FIB que los permite realizar autónomamente CEF y por lo tanto considerablemente aumentar el rendimiento agregado.

Como mencionado en "los Métodos Clásicos para la Capa 3 Paquete que Cambia" la sección, CEF soporta tanto carga compartida por destino como por paquete. La carga compartida por destino es la falta, que significa que los paquetes para un par de fuente/destino dado son garantizados para salir al mismo interfaz. El tráfico para pares diferentes tiende a tomar caminos diferentes. A menos que el tráfico consista en flujos para un pequeño número de pares de fuente/destino, el tráfico tiende a ser igualmente distribuido a través de caminos múltiples con la carga compartido por destino CEF.

El CEF también soporta la carga compartida por paquete. La carga compartida por paquete permite que un router envíe paquetes de datos sucesivos sobre caminos sin hacer caso de direcciones de destino y fuente. Carga compartida por paquete usa un método de retorno al punto de origen de seleccionar el interfaz de salida para un paquete. Cada paquete toma el siguiente interfaz que el enrutamiento permite. La carga compartida por paquete proporciona un mejor equilibrio del tráfico sobre enlaces múltiples. Usted puede usar la carga compartida por paquete para ayudar a asegurar que un camino para un par de fuente/destino solo no se hace sobrecargado.

Marcos Huerta S.

278


Aunque la utilización de camino con la carga compartida por paquete sea optimizada, los paquetes para un par de hosts de fuente/destino dado podrían tomar

caminos

diferentes,

que

podrían

hacer

que

paquetes

llegaran

estropeados. Por esta razón, la carga compartida por paquete es inadecuada para ciertos tipos del tráfico de datos, como VoIP, que dependen de paquetes llegando al destino en la secuencia.

o

Servicios de cola Las técnicas de conmutación rápidas ya habladas en las secciones anteriores sólo van hasta ahora en la optimización de una red que experimenta la congestión. Los métodos inteligentes y rápidos que hacen cola son también necesarios. La formación de una cola de espera permite que un dispositivo de red maneje un desbordamiento de tráfico. El Cisco IOS software soporta los métodos siguientes que hacen cola: v Primero en entrar primero en salir (FIFO) formación de una cola de espera v Formación de una cola de espera de prioridad v Formación de una cola de espera de encargo v Feria ponderada que hace cola (WFQ) v WFQ a base de Clase (CBWFQ) v Latencia baja haciendo cola (LLQ)

o

Cola Primero en entrar primero en salir (FIFO) La formación de una cola FIFO proporciona la funcionalidad basica de almacenar-y-enviar. Esto implica almacenar paquetes cuando la red esta saturada y transporte de mercancías de ellos en la orden ellos llegaron cuando la red es ya esta libre. El FIFO tiene la ventaja que esto es por defecto que hace cola el algoritmo en algunos casos, no requiere ninguna configuración. El FIFO tiene la desventaja que esto no toma ninguna decisión sobre la prioridad de paquete. La orden de llegada determina la orden un paquete es tratado y salida. NOTA Con la formación de una cola de espera de FIFO, hay muchos paquetes que esperan la transmisión, un nuevo paquete que llega experimenta la tardanza de de transmisión. Usted puede haber experimentado esto en la tienda de comestibles. ¿Se ha preguntado alguna vez usted si usted debería usar la línea de comprobación de express de FIFO aun cuando es más largo que las líneas de comprobación de no expreso de FIFO?

El FIFO no proporciona ninguna funcionalidad de QoS y ninguna protección contra una aplicación usando recursos de red en un camino que negativamente

Marcos Huerta S.

279


afecta la performance de otras aplicaciones. Las fuentes de Bursty pueden causar tardanzas altas de la entrega del tráfico de aplicación sensible a tiempo, y potencialmente aplazar control de red y mensajes señalados. Los paquetes largos pueden causar tardanzas injustas para aplicaciones que usan paquetes cortos. Por estos motivos, Cisco ha desarrollado algoritmos avanzados que hacen cola que proporcionan más caracteristicas que la formación de una cola de espera de FIFO básica, incluso formación de una cola de espera de prioridad, formación de una cola de espera de encargo, y feria ponderada que hace cola (WFQ). Estos algoritmos son descritos en las pocas siguientes secciones.

o

Prioridad de Cola La formación de una cola de espera de prioridad asegura que el tráfico importante es tratado primero. Fue diseñado para dar la prioridad estricta con una aplicación crítica, y es en particular útil para protocolos sensibles a tiempo como la Arquitectura de Red de Sistemas (SNA). Los paquetes pueden estar priorizados basado en muchos factores, incluso protocolo, interfaz entrante, tamaño de paquete, y dirección de destino o fuente. La formación de una cola de espera de prioridad es sobre todo apropiada en casos donde los enlaces WAN son congestionados de vez en cuando. Si los enlaces WAN son constantemente congestionados, el cliente debería investigar protocolo e ineficiencias de aplicación, pensar en usar la compresión, o posiblemente mejorar a más el ancho de banda. Si los enlaces WAN nunca son congestionados, la formación de una cola de espera de prioridad es innecesaria. Como la formación de una cola de espera de prioridad requiere procesamiento extra y puede causar problemas de performance para el tráfico de prioridad baja, no debería ser recomendado a menos que sea necesario.

La formación de una cola de espera de prioridad tiene cuatro colas: alto, medio, normal, y bajo. La cola prioritaria siempre es vaciada antes de que las colas de prioridad inferior sean atendidas, como mostrado en la Figura 13-3. La formación de una cola de espera de prioridad es análoga a una línea de primera clase en un aeropuerto donde todos los oficinistas sirven aquella línea primero hasta los envases de línea.

Marcos Huerta S.

280


Figure 13-3. The Behavior of Priority Queuing

o

Cola de Encargo La formación de una cola de espera de encargo fue diseñada para permitir que una red fuera compartida entre aplicaciones con ancho de banda mínima diferente o requerimientos de latencia. La formación de una cola de espera de encargo adjudica cantidades diferentes del espacio de cola a protocolos diferentes y maneja las colas en la manera de retorno al punto de origen. Un protocolo particular puede ser priorizado adjudicándolo más espacio de cola. La formación de una cola de espera de encargo es más "feria" que la formación de una cola de espera de prioridad, aunque la formación de una cola de espera de prioridad sea más poderosa para priorizar una aplicación crítica sola.

Usted puede usar cola de costumbre para proveer garantizada ancho de banda en un punto de congestión potencial. La formación de una cola de espera de encargo le deja asegurar que cada tráfico especificado escribe a máquina una parte fija del ancho de banda disponible, mientras al mismo tiempo evitan cualquier aplicación que consigue más que una proporción predeterminada de la capacidad cuando el enlace está bajo la tensión. La formación de una cola de espera de encargo es análoga a una línea de primera clase en un aeropuerto donde los oficinistas sirven aquella línea primero hasta un punto. Después de un número de juego de pasajeros de primera clase han sido servidos, el movimiento de oficinistas a la otra gente. Marcos Huerta S.

281


Sitios que hacen cola de mensaje en 1 de 17 colas. Los servicios de router hacen cola 1 a 16 en la orden de retorno al punto de origen. (La cola 0 mensajes de sistema de asimientos, como keepalive y mensajes señalados, es vaciada primero.) un administrador de red configura el tamaño de ventana de transmisión de cada cola en bytes. Después de que el número apropiado de paquetes ha sido transmitido de una cola tal que el tamaño de ventana de transmisión ha sido alcanzado, la siguiente cola es comprobada, como mostrado en la Figura 13-4.

Figure 13-4. The Behavior of Custom Queuing

Muchos negocios usan la costumbre que hace cola para el tráfico SNA. Como SNA es la tardanza sensible, uno puede poner alguna parte aparte del ancho de banda, a menudo el 40 a 50 por ciento, para el tráfico SNA para usar durante tiempos de congestión.

o

Cola Justa Ponderada El WFQ es un juego sofisticado de algoritmos diseñados para reducir la variabilidad de tardanza y proporcionar el rendimiento previsible y el tiempo de respuesta para flujos de tráfico. Un objetivo de WFQ es ofrecer el servicio uniforme para encenderse a usuarios de red pesados igualmente. El WFQ asegura que el tiempo de respuesta para aplicaciones de volumen bajo es consecuente con el tiempo de respuesta para aplicaciones de volumen alto. Las aplicaciones que envían pequeños paquetes son bastante privadas de comida de ancho de banda por aplicaciones que envían paquetes grandes. El ancho de banda es dividida equitativamente de un modo automatizado.

Marcos Huerta S.

282


El WFQ es un algoritmo a base de flujo que hace que la cola que reconoce un flujo para una aplicación interactiva y programa el tráfico de aquella aplicación al frente de la cola para reducir el tiempo de respuesta. Se permite que corrientes de tráfico de volumen bajo para aplicaciones interactivas, que incluye un porcentaje grande de las aplicaciones en la mayor parte de redes, transmitan sus cargas ofrecidas enteras en una manera oportuna. Las corrientes de tráfico de volumen alto comparten la capacidad restante.

A diferencia de costumbre y formación de una cola de espera de prioridad, WFQ se adapta automáticamente al tráfico de red que se cambia condiciona y requiere poca o ninguna configuración. Esto es la falta que hace cola el modo en la mayoría de las interfaces consecutivas configuradas para correr en o debajo de velocidades E1 (2.048 Mbps).

Para aplicaciones que usan el campo de precedencia IP en la cabecera IP, WFQ puede asignar el ancho de banda basada en la precedencia. El algoritmo asigna más ancho de banda a conversaciones con la precedencia más alta, y se asegura que aquellas conversaciones son servidas más rápidamente cuando la congestión ocurre. El WFQ adjudica un peso a cada flujo, que determina el orden que transmitira por paquetes colocados en fila. Las ayudas de precedencia de IP determinan el factor de ponderación.

El WFQ también trabaja con RSVP. El RSVP usa WFQ para asignar espacio de buffer, paquetes de lista, y ancho de banda garantízada basada en reservaciones de recurso. Además, WFQ entiende el bit de elegibilidad de descarte (DE), y la notificación de congestión explícita avanzada (FECN) y notificación de congestión hacia atrás explícita (BECN) mecanismos en una red de Frame Relay. Después de que la congestión ha sido identificada, los pesos usados por WFQ son cambiados de modo que una conversación que encuentra la congestión transmita con menos frecuencia.

o

Cola Justa Ponderada a Base de Clase El CBWFQ combina los mejores elementos de prioridad, costumbre, y formación de una cola de espera ponderada justa. El CBWFQ causa una configuración más compleja que los otros métodos que hacen cola, pero la complejidad añade la flexibilidad no encontrada en los otros métodos. El CBWFQ le deja definir clases de tráfico basadas en criterios de partido como protocolos, tener acceso a listas de control, e introducir interfaces. Los paquetes que satisfacen los criterios para una clase constituyen el tráfico para aquella clase. Una cola de

Marcos Huerta S.

283


FIFO es reservada para cada clase, y el tráfico que pertenece a una clase es dirigido a la cola para aquella clase.

Después de que una clase ha sido definida, usted puede adjudicarle características como el ancho de banda y el número máximo de paquetes que pueden ser hechos cola para la clase, llamada el límite de cola. El ancho de banda adjudicada una clase es el ancho de banda garantizada entregada a la clase durante la congestión. El límite de cola para la clase es el número máximo de paquetes permitidos acumularse en la cola para la clase. Para optimizar como los paquetes son descartados si ellos exceden el límite de cola, usted puede permitir el descubrimiento temprano arbitrario ponderado (WRED), que es cubierto más tarde en este capítulo.

La clasificación de flujo para CBWFQ está basada en WFQ. Es decir los paquetes con la misma dirección de IP de la fuente, destino dirección de IP, TCP de la fuente o puerto UDP, y destino TCP o puerto UDP son clasificados como perteneciendo al mismo flujo. El WFQ asigna una parte igual de ancho de banda a cada flujo. WFQ a base de Flujo también es llamado la formación de una cola de espera de feria porque todos los flujos son igualmente ponderados.

Cuando CBWFQ es permitido, los paquetes que llegan a un interfaz de salida son clasificados según los criterios de partido que usted definió. El peso para un paquete que pertenece a una clase específica es sacado del ancho de banda que usted adjudicó a la clase cuando usted lo configuró. En este sentido, el peso para una clase es configurado por el usuario. Después de que el peso para un paquete es adjudicado, el paquete es colocado en la cola apropiada. El CBWFQ usa los pesos adjudicados a los paquetes colocados en fila asegurar que la cola de clase es atendida justamente.

o

Latencia Baja de Cola El LLQ combina la prioridad que hace cola con CBWFQ y fue al principio llamado PQ-CBWFQ, pero hasta Cisco reconoció que las siglas sólo pueden ser así mucho antes de que ellos pierdan su valor memónico. El LLQ trae la prioridad estricta que hace cola CBWFQ. La formación de una cola de espera de prioridad estricta permite que datos confidenciales de tardanza como la voz sean enviados antes de que los paquetes en otras colas sean enviados.

Sin LLQ, CBWFQ provee WFQ basado en clases definidas sin la cola de prioridad estricta disponible para el tráfico de tiempo real. Como mencionado en la sección precedente, CBWFQ permite que usted defina clases de tráfico y

Marcos Huerta S.

284


luego adjudicar características a cada clase. Por ejemplo, usted puede especificar el ancho de banda mínima entregada a una clase durante la congestión. Cuando usted usa CBWFQ, el peso para un paquete que pertenece a una clase específica es sacado del ancho de banda que usted adjudicó a la clase cuando usted lo configuró. Por lo tanto, el ancho de banda adjudicada a los paquetes de una clase determina la orden en la cual los paquetes son enviados. Todos los paquetes son atendidos basados en el peso, y ninguna clase de paquetes es concedida la prioridad estricta. Este esquema plantea problemas para el tráfico de voz que es intolerante de tardanza y variación en la tardanza (inquietud).

El LLQ permite el uso de una sola cola de prioridad estricta dentro de CBWFQ en el nivel de clase, permitiéndole dirigir el tráfico que pertenece a una clase la cola de prioridad estricta CBWFQ. Aunque sea posible colocar varios tipos del tráfico de tiempo real en la cola de prioridad estricta, Cisco fuertemente recomienda que usted dirija sólo el tráfico de voz a la cola. El tráfico de voz requiere aquella tardanza ser no variable. El tráfico de tiempo real como el vídeo podría introducir la variación en la tardanza, así frustrando la firmeza de tardanza requerida para la transmisión de voz acertada. El LLQ es un instrumento esencial para diseñadores de red que planean transmitir el tráfico de voz en enlaces de ancho de banda baja que también llevan otros tipos del tráfico.

o

Detección Aleatorio Temprana Los mecanismos que hacen cola hablados en las secciones anteriores son esencialmente técnicas de dirección de congestión. Aunque tales técnicas sean necesarias para controlar la congestión, ellos no faltan de evitar la congestión antes de que esto ocurra. Una nueva clase de algoritmos de evitación de congestión gana la popularidad.

Un algoritmo es el descubrimiento temprano arbitrario (RED). Los trabajos RED monitorean la carga de tráfico en puntos en una red y al azar descartan paquetes si la congestión comienza a aumentar. El resultado es que los nodos de la fuente descubren el tráfico descartado y reducen la marcha de su precio de transmisión. RED es diseñado principalmente para trabajar con aplicaciones basadas en el Protocolo de Control de Transmisión (TCP).

Sobre la pérdida de paquete, una sesión TCP disminuye su transmitir el tamaño de ventana, con eficacia reduciendo la marcha de su precio de transmisión. Esto entonces gradualmente aumenta el tamaño de ventana hasta que la congestión

Marcos Huerta S.

285


ocurra otra vez. El término porpoising a veces es usado para referirse al cierre y volver a abrir la ventanas.

La experiencia muestra que si los routers no aplican alguna clase de randomización al desechar paquetes, sesiones TCP múltiples tienden a reducir la marcha de su precio de transmisión simultáneamente. (Las sesiones toman una zambullida de marsopa sincronizada, que en más términos técnicos a menudo es llamada la sincronización global.) aplicaciones Múltiples bajan y aumentan su precio de transmisión simultáneamente, que significa que el ancho de banda no es usada con eficacia. Cuando aplicaciones múltiples reducen la velocidad, el ancho de banda es gastada. Cuando ellos aumentan su precio, ellos tienden a aumentar la utilización de ancho de banda al punto donde la congestión ocurre otra vez.

La ventaja de los RED consiste en que esto aleatoriza el descarte de paquetes, a la baja de reducir el potencial para sesiones múltiples que sincronizan su comportamiento. RED es una solución buena para un router de sitio central en una topología "hub and spoke". RED distribuye la caída de paquetes a través de muchas redes spoke y evita causar problemas de congestión para sesiones de aplicación múltiples de un sitio.

o

Detección Temprana Arbitraria Ponderado El WRED es la realización de Cisco de RED. El WRED combina las capacidades del algoritmo RED estándar con la precedencia IP. Esta combinación asegura el tráfico preferente que se maneja paquetes de prioridad más alta. Esto selectivamente desecha el tráfico de prioridad inferior cuando un interfaz comienza a ser congestionada, más bien que usar simplemente un método arbitrario. El WRED también puede ajustar su comportamiento basado en reservaciones RSVP. Si una aplicación registra para controlar-carga de grupo de funcionamiento de Servicios Integrada el servicio de QoS, WRED es consciente de este hecho y ajusta su paquete que desecha en consecuencia.

Cisco también soporta el descubrimiento temprano arbitrario ponderado distribuido (D-WRED), una versión rápida de WRED que dirige en los Procesadores de Interfaz Versátiles (personajes muy importante) en routers Cisco 7500 . Otra caracteristica de Cisco es WRED a base de flujo, que obliga WRED a permitirse la mayor imparcialidad a todos los flujos en un interfaz cuando los paquetes son descartados.

Marcos Huerta S.

286


WRED a base de Flujo clasifica el tráfico entrante en flujos basados en parámetros como destino y direcciones de la fuente y puertos. WRED a base de Flujo usa esta clasificación e información estatal para asegurar que cada flujo no consume más que su parte permitida de los recursos de buffer de salida. WRED a base de Flujo determina qué flujos monopolizan recursos y más pesadamente castiga estos flujos.

o

Formación de Tráfico Otro instrumento que está disponible a los diseñadores para conectar a la red que usan equipo de Cisco es la formación de tráfico. La formación de tráfico le deja manejar y controlar el tráfico de red para evitar cuellos de botella y encontrar requerimientos de QoS. Esto evita la congestión reduciendo el tráfico que va hacia fuera para un flujo a una velocidad binaria configurada, haciendo cola de tráfico para aquel flujo. En topologías con routers y enlaces de capacidades variantes, el tráfico puede ser formado para evitar aplastar un enlace del router downstream.

La formación de tráfico es configurada en una base por interfaz. El administrador de router usa listas de control de acceso para seleccionar el tráfico a formar. Tráfico que forma trabajos con una variedad de Capa 2 tecnologías, incluso Frame Relay, ATM, Servicio de Datos de Multimegabit Cambiado (SMDS), y Ethernet.

En un interfaz de Frame Relay, usted puede configurar la formación de tráfico para adaptarse dinámicamente al ancho de banda disponible usando el mecanismo BECN. Además, Cisco tiene una caracteristica específica para redes de Frame Relay llamada el tráfico de Frame Relay que soporta técnicas de optimización específicas para Enmarcar el Frame. Para más información, refiérase "a la sección" de Frame Relay de Configuración de la documentación de Cisco.

o

Ratio de Acceso Comprometido Cisco también soporta una caracteristica llamado el ratio de acceso cometido (CAR) que permite que usted clasifique y tráfico de policía en un interfaz entrante.

El CAR soporta la especificación de políticas en cuanto a como el tráfico que excede una cierta asignación de ancho de banda debería ser manejado. El CAR mira el tráfico recibido en una interfaz (o un subconjunto de aquel tráfico seleccionado por una lista de control de acceso), compara su precio máximo

Marcos Huerta S.

287


configurado, y luego toma medidas basado en el resultado. Por ejemplo, esto puede descartar paquete o cambiar los bits de precedencia IP en el paquete para indicar que el paquete debería ser manejado con la prioridad inferior.

3.5.5.3 Documentar el diseño de red Este capítulo comienza proporcionando consejo en responder a la petición de un cliente de la oferta (RFP), y concluye con la información en la escritura de un documento de diseño cuando ningún RFP existe. La sección "los Contenido de un Documento de Diseño de Red" proporciona un contorno de un documento de diseño típico, y especifica los temas que deberían ser incluidos en cada parte del documento. La sección sirve como un resumen para el Diseño de Top Down porque esto se refiere a cada uno de los pasos principales de la metodología de diseño Top Down presentada en esta metodologia.

En este punto del proceso de diseño, usted debería tener un diseño completo que está basado en un análisis de los objetivos comerciales y técnicos de su cliente, e incluye tanto componentes lógicos como físicos que han sido probados y optimizados. El siguiente paso en el proceso debe escribir un documento de diseño.

Un documento de diseño describe los requerimientos de su cliente y explica como su diseño encuentra aquellos requerimientos. Esto también documenta la red existente, el diseño lógico y físico, y el presupuesto y gastos asociados con el proyecto.

Es también importante que un documento de diseño contenga proyectos para poner en práctica la red, midiendo el éxito de la realización, y desarrollando el diseño de red cuando los nuevos requerimientos de aplicación se levantan. El trabajo del diseñador de red nunca es completa. El proceso de analizar requerimientos y desarrollar soluciones de diseño comienza otra vez tan pronto como un diseño es puesto en práctica. La figura 14-1 muestra la naturaleza cíclica del proceso de diseño de red Top Down.

Figure 14-1. Diseño de Red y Ciclo de Implementación

Marcos Huerta S.

288


Como mencionado en capítulos más anteriores, además de ser cíclico, el diseño de red es también iterativo. Algunos pasos ocurren durante multiples fases de un diseño. Las pruebas ocurren durante la fase de validación de diseño y también durante la realización.

La optimización ocurre finalizando el diseño y también después de la realización durante la fase que supervisa red. La documentación es un esfuerzo en curso. La documentación que es completada antes de la etapa de realización puede facilitar el proceso de aprobación para un diseño y ayuda a acelerar el rollout de nuevas tecnologías y aplicaciones.

Responder la Propuesta de Requerida de un Cliente Un RFP pone los requerimientos de diseño de un cliente en una lista y los tipos de soluciones que un diseño de red debe incluir. Las organizaciones envían RFPs a vendedores y diseñan a asesores y usan las respuestas que ellos reciben para arrancar a proveedores que no pueden encontrar requerimientos. Las respuestas de RFP ayudan a organizaciones a comparar diseños competidores, capacidades de producto, fijación de precios, y servicio y alternativas de soporte.

Cada RFP es diferente, pero típicamente un RFP incluye unos o todos los temas siguientes: v Objetivos comerciales para el proyecto. v Alcance del Proyecto. v Información en la red existente y aplicaciones. v Información en nuevas aplicaciones. v Las exigencias técnicas, incluso escalabilidad, disponibilidad, conectan a la red la performance, la seguridad, la manejabilidad, la utilidad, la adaptabilidad, y la accesibilidad financiera. v Requerimientos de garantía para productos. v Las restricciones ambientales o arquitectónicas que podrían afectar la realización. v La formación y requerimientos de apoyo. v Lista preliminar con cambios y deliverables. v Términos contractuales legales y condiciones.

Algunas organizaciones especifican el formato requerido para la respuesta RFP. Si es así, su documento de diseño inicial debería seguir el formato prescribido del cliente y la estructura exactamente. Las organizaciones que especifican un formato pueden rechazar leer respuestas que no siguen el formato solicitado. En algunos

Marcos Huerta S.

289


casos, el cliente puede solicitar un documento de continuación donde usted puede proporcionar la información más detallada en su diseño de red lógico y físico.

Algunos RFPs están en la forma de un cuestionario. En este caso, las preguntas deberían conducir la organización de la oferta. Los adornos que se concentran en requerimientos claves y los puntos de venta de su diseño pueden ser a veces añadidos, a menos que el RFP expresamente declare que ellos no deberían ser añadidos.

Aunque cada organización maneje RFPs ligeramente diferentemente, típicamente un RFP declara que la respuesta debe incluir unos o todos los temas siguientes: v Una topología de red para el nuevo diseño. v La información en los protocolos, tecnologías, y productos que forman el diseño. v Un plan de realización. v Un plan de implementación v Un plan de entrenamiento. v Soporte e servicio de información. v Precios y opciones de pago. v Clasificación del vendedor que responde o proveedor. v Las recomendaciones de otros clientes para

quien el proveedor ha

proporcionado una solución. v Términos contractuales legales y condiciones.

A pesar de que una respuesta a un RFP debe quedarse dentro de las pautas especificadas por el cliente, usted debería usar sin embargo el ingenio para asegurar que su respuesta destaca las ventajas de su diseño. Basado en un análisis de objetivos comerciales y técnicos de su cliente, y el flujo y características del tráfico de red.

Escribiendo la respuesta, esta seguro para considerar el concurso. El intento de predecir lo que otros vendedores o diseñadores de asesores podría proponer entonces usted puede llamar la atención a los aspectos de su solución que probablemente serán superiores a diseños competidores. Además, preste la atención "al estilo comercial de su cliente." La Fase I, "Analizando Objetivos Comerciales y Restricciones," cubrió la importancia de entender tendencias de su cliente y cualquier "política de oficina" o historia de proyecto que podría afectar la percepción de su diseño.

Marcos Huerta S.

290


Documente el Contenido del Diseño de Red Cuando su documento de diseño no tiene que seguir un formato dictado de un RFP, o cuando un cliente solicita un documento de continuación a una respuesta RFP básica, usted debería escribir un documento de diseño que totalmente describe su diseño de red. El documento debería incluir los componentes lógicos y físicos del diseño, información en tecnologías y dispositivos, y una oferta para poner en práctica el diseño. Las secciones siguientes describen los temas que deberían ser incluidos en un documento de diseño completo.

o

Resumen Ejecutivo Un documento de diseño completo puede ser muchas páginas de longitud. Por esta razón, es esencial que usted incluya a principios del documento un Resumen Ejecutivo que sucintamente declara los puntos principales del documento. El Resumen Ejecutivo debería ser no más que una página y debería ser apuntado hacia los gerentes y participantes que decidirán si hay que aceptar su diseño.

Aunque el Resumen Ejecutivo pueda incluir alguna información técnica, esto no debería proporcionar detalles técnicos. El objetivo del resumen es vender a los funcionarios con poder de decisión en las ventajas comerciales de su diseño. La información técnica debería ser resumida y organizada por orden de los objetivos de prioridad más alta del cliente para el proyecto de diseño.

o

Objetivo del Proyecto Esta sección debería declarar el objetivo primario para el proyecto de diseño de red. El objetivo debería ser el negocio orientado y relacionado con un objetivo total que la organización tiene que hacerse más acertada en su negocio principal. La sección de Objetivo de Proyecto debería ser no más que un párrafo; a menudo puede ser escrito como una oración sola. La escritura de ello con cuidado le dará una posibilidad para hacerlo obvio hacia los funcionarios con poder de decisión que leen el documento que usted entiende el objetivo primario y la importancia del del diseño del proyecto de red. Un ejemplo de un objetivo de proyecto que fue escrito para un cliente de diseño actual sigue: El objetivo de este proyecto es desarrollar una red de area amplia (WAN) que soportara nuevo alto ancho de banda y aplicaciones de multimedia de tardanza baja. Las nuevas aplicaciones son claves a la realización acertada de nuevos programas de formación para el personal de ventas. El nuevo WAN debería facilitar el objetivo de aumentar ventas en los Estados Unidos en el 50 por ciento en el próximo año fiscal.

Marcos Huerta S.

291


o

Alcance del Proyecto La sección de Alcance de Proyecto proporciona la información en el grado del proyecto, incluso un resumen de los departamentos y redes que serán afectadas por el proyecto. La sección de Alcance de Proyecto especifica si el proyecto es para una nueva red o modificaciones a una red existente. Esto indica si el diseño es para un segmento de red solo, un juego de LANs, un edificio o red de campus, un juego de WAN o redes de acceso remoto, o posiblemente la red de empresa entera.

Un ejemplo de una sección de Alcance de Proyecto sigue: El alcance de este proyecto debe actualizar la existencia WAN que une todas las oficinas de ventas principales en los Estados Unidos a la oficina central corporativa. Al nuevo WAN le tendrán acceso las ventas, la mercadotecnia, y los empleados que se entrenan. Está más allá del alcance de este proyecto de actualizar cualquier LAN que estos empleados usan. Está también más allá del alcance de este proyecto de actualizar las redes en satélite y oficinas de telecomunicaciones.

El alcance del proyecto no podría cubrir intencionadamente algunos asuntos. Por ejemplo, la fijación de problemas de performance con una aplicación particular podría estar intencionadamente más allá del alcance del proyecto. Declarando presentan las asunciones que usted hizo sobre el alcance del proyecto, usted puede evitar cualquier percepción que su solución por descuido deja de dirigirse a ciertas preocupaciones.

o

Requerimientos del Diseño Mientras que la sección de Objetivo de Proyecto es generalmente muy corta, la sección de Requerimientos de Diseño es su oportunidad de poner todos los requerimientos comerciales y técnicas principales en una lista para el diseño de red. La sección de Requerimientos de Diseño debería poner los objetivos en una lista en orden de prioridad. Los objetivos críticos deberían ser marcados como tal. Para examinar algunos ejemplos de requerimientos de diseño, ver los estudios del caso en el Capítulo 10, "Seleccionando Tecnología y Dispositivos para Redes de Campus," el Capítulo 11, "Seleccionando Tecnologías y Dispositivos para Redes de Empresa," y el Capítulo 12, "Probando Su Diseño de Red."

Marcos Huerta S.

292


o

Objetivos del Negocio Los objetivos del negocio explican el papel que el diseño de red jugará en la ayuda de una organización a proporcionar mejores productos y servicios a sus clientes. Los ejecutivos que leyeron el documento de diseño con mayor probabilidad aceptarán el diseño de red si ellos reconocen de la sección de Objetivos Comercial que el diseñador de red entiende la misión comercial de la organización.

Muchos diseñadores de red tienen un tiempo duro escribiendo la sección de Objetivos Comercial porque ellos están más interesados en objetivos técnicos. Sin embargo, es crítico que usted enfoca su documento de diseño de red en la capacidad de su diseño de ayudar a un cliente a solucionar problemas comerciales verdaderos mundiales.

Como hablado en la Fase I, la mayor parte de negocios emprenden un proyecto de diseño de red para ayudarles a aumentar el ingreso, reducir gastos operacionales e ineficiencias, y mejorar comunicaciones corporativas. Otros objetivos típicos incluyen sociedades de edificio con otras compañías y ampliación en mercados mundiales. En este punto en el proceso de diseño de red, usted debería tener un entendimiento completo de los objetivos comerciales de su cliente y ser capaz de ponerlos en una lista en el documento de diseño en el orden de prioridad.

o

Objetivos Técnicos La sección de Objetivos Técnicos documenta los objetivos siguientes hablados en el Fase II, "Analizando Objetivos Técnicos y Compensaciones:" v Escalabilidad. Cuanto crecimiento un diseño de red debe soportar. v Disponibilidad. La cantidad de tiempo una red está disponible a usuarios, a menudo expresados como un tiempo de operación de por ciento, o como un tiempo medio entre el fracaso (MTBF) y tiempo medio de reparación (MTTR). La documentación de disponibilidad también puede incluir cualquier información juntada en el coste monetario asociado con el tiempo de indisponibilidad de red. v Interpretación de red. Los criterios del cliente para aceptar el nivel de servicio de una red, incluso su rendimiento, exactitud, eficacia, tardanza, retrasan la variación (inquietud), y tiempo de respuesta. Los requerimientos de rendimiento específicas para dispositivos de funcionamiento entre redes, en

paquetes

por

segundo,

también

pueden

ser

declaradas.

Los

requerimientos de rendimiento específicas para aplicaciones deberían ser incluidas en la sección de Aplicaciones.

Marcos Huerta S.

293


v Seguridad. Objetivos generales y específicos para proteger la capacidad de la organización de conducir negocio sin interferencia de intrusos que inapropiadamente tienen acceso o equipo perjudicial, datos, u operaciones. Esta sección también debería poner varios riesgos a la seguridad en una lista que el cliente identificó durante la fase de análisis de exigencias del proyecto de diseño. v Manejabilidad. Objetivos generales y específicos para performance, falta, configuración, seguridad, y dirección de la contabilidad. v Utilidad. La facilidad con la cual los usuarios de red pueden tener acceso a la red y sus servicios. Esta sección puede incluir la información en objetivos para simplificar tareas de usuario relacionadas para conectar a la red la dirección, el nombramiento, y el descubrimiento de recurso. v Adaptabilidad. La facilidad con la cual un diseño de red y la realización pueden adaptarse para conectar a la red ante fallas, cambiando modelos de tráfico, requerimientos comerciales o técnicas adicionales, nuevas prácticas comerciales, y otros cambios. v Accesibilidad financiera. La información general en la importancia de contener los gastos se asoció con compra y funcionamiento de equipo de red y servicios. La información de presupuesto específica debería ser incluida en la sección de Presupuesto de Proyecto.

La sección de Objetivos Técnicos también debería describir cualquier compensación que el cliente quiere hacer. Por ejemplo, algunos clientes podrían indicar que la accesibilidad financiera puede ser sacrificada para encontrar objetivos de disponibilidad estrictos, o la utilidad puede ser sacrificada para encontrar objetivos de seguridad estrictos. Como hablado en la Fase II, incluso una carta que clasifica los pesos relativos de objetivos puede ayudar a los lectores de un documento de diseño de red a entender algunas opciones de diseño que fueron hechas.

o

Comunidades de Usuario y Almacenes de Datos Esta sección pone comunidades de usuario principales en una lista, incluso sus tamaños, posiciones, y las aplicaciones principales que ellos usan. Usted puede usar la Tabla 4-1, "Comunidades de Usuario," resumir la información sobre comunidades de usuario. Esta sección también debería poner tiendas de datos principales en una lista (servidores y hosts) y sus posiciones. La Tabla de Uso 42, "los Datos Almacenan," resumir la información sobre tiendas de datos.

Marcos Huerta S.

294


o

Aplicaciones de Red La sección de Aplicaciones de Red pone en una lista y caracteriza las aplicaciones de red nuevas y existentes. La información sobre aplicaciones puede ser resumida en "Requerimientos Tecnicos de Aplicaciones de Red" carta mostrada en la Mesa 2-3, y en "la carta" de Características de Tráfico de Aplicaciones de Red mostrada en la Tabla 4-4. Si usted quiere, usted puede combinar estas dos tablas de modo que haya sólo una fila para cada aplicación.

Los estudios del caso en la Fase III y IV proporcionan ejemplos buenos de la información en cuanto a aplicaciones de red, comunidades de usuario, y tiendas de datos que deberían ser incluidas en un documento de diseño.

o

Estado Actual de la Red Esta sección brevemente describe la estructura y la performance de la red existente. Esto debería incluir un mapa de alto nivel que identifica la posición de dispositivos de funcionamiento entre redes principales, informática y sistemas de almacenaje, y segmentos de red. El mapa de alto nivel debería documentar los nombres y direcciones de dispositivos principales y segmentos e indicar los tipos y longitudes de segmentos de red principales. Para redes muy grandes, dos o tres mapas de alto nivel podrían ser necesarios. Los mapas detallados, sin embargo, deberían ser colocados en el Apéndice más bien que en esta sección. Los mapas deberían incluir componentes lógicos así como físicos (por ejemplo, la posición y alcance de cualquier red privada virtual (VPNs), LANs virtuales (VLANs), segmentos de firewall, servidor de cluster, etcétera). Los mapas también deberían caracterizar la topología lógica de las redes y las redes que arreglan las redes. Los dibujos de red, o el texto asociado con dibujos, deberían indicar si las redes son jerárquicas o planas, estructuradas o no estructuradas, acodadas o no, etcétera. Ellos también deberían indicar la geometría de red (por ejemplo, estrella, anillo, bus, hub y spoke, o malla). La documentación del estado corriente de la red también brevemente describe cualquier estrategia o estándares sus usos de cliente para dirección de red y nombramiento de dispositivo. Si el cliente usa (o planea usar) las técnicas de direcciónsumarizada, por ejemplo, este debería ser indicado en el documento de diseño.

Una parte principal del Estado Corriente de la sección de Red del documento de diseño de red debería ser dedicada a un análisis de la salud y la performance de la red presente. Ver la Fase III, "Caracterizando las redes Existentes," para más información en la documentación usted debería juntarse sobre la red existente.

Marcos Huerta S.

295


Los informes detallados (por ejemplo, cartas de utilización de red de 1 minuto) pueden ser colocados en el Apéndice del documento de diseño para evitar abrumar al lector con demasiada información en esta etapa. Es importante que el lector ''es capaz de alcanzar rápidamente el Diseño Lógico y secciones de Diseño Físicas del documento, porque aquellas secciones contienen la esencia de su oferta de diseño.

o

Diseño Lógico La sección de Diseño Lógica documenta los aspectos siguientes de su diseño de red: v La topología de red, incluso uno o varios dibujos que ilustran la arquitectura lógica de la nueva red. v Un modelo para dirigirse a red segmentada y dispositivos. v Un modelo para llamar dispositivos de red. v Una lista del enrutamiento, y conmutación de protocolos que han sido seleccionados para poner en práctica el diseño, y cualquier recomendación de realización específica asociada con aquellos protocolos. v Mecanismos de seguridad recomendados y productos, incluso un resumen de políticas de seguridad y procedimientos. (Si un plan de seguridad detallado fuera desarrollado como la parte del diseño de red, puede ser presentado como un apéndice al documento de diseño.) v Arquitecturas de dirección de red recomendadas, procesos, y productos v La razón fundamental de diseño, perfilando por qué varias opciones fueron hechas, en la luz de los objetivos del cliente y el estado corriente de la red.

NOTA No todos los diseños incluyen todos estos componentes. Basado en los requerimientos de su cliente, usted debería reconocer si es necesario dirigirse a todas las cuestiones incluidas en la lista precedente en su documento de diseño de red.

o

Diseño Físico La sección de Diseño Físico describe las caracteristicas y usos recomendados para las tecnologías y dispositivos que usted seleccionó para poner en práctica el diseño. Esto puede incluir la información para redes de campus y acceso remoto y redes de area amplia. Esta sección también puede incluir la información sobre cualquier abastecedor de servicio seleccionado.

De ser asignado, la sección de Diseño Físico debería incluir la información en la fijación de precios para dispositivos de red y servicios. A veces la fijación de

Marcos Huerta S.

296


precios es negociable y no es apropiada para incluir en el documento de diseño. En la mayor parte de casos, sin embargo, los clientes esperan ver el producto y la fijación de precios de servicio en el documento de diseño.

La sección de Diseño Físico también debería contener la información en la disponibilidad de productos. Si su diseño recomienda productos que transportan todavía, usted debería documentar una fecha de barco predicha, conforme al vendedor de producto.

o

Resultados de Pruebas de Diseño de Red Esta sección describe los resultados de las pruebas que usted hizo para verificar su diseño de red. Esto es una de las partes más importantes del documento de diseño porque esto le da una posibilidad para demostrar a su cliente

que

su

diseño

encontrará

probablemente

requerimientos

para

performance, seguridad, utilidad, manejabilidad, etcétera. Usted puede describir cualquier prototipo o pilotear sistemas que usted puso en práctica y los componentes de pruebas siguientes: v Objetivos de prueba. v Criterios de aceptación de prueba. v Pruebas de instrumentos. v Escrituras de prueba. v Resultados y observaciones.

En los Resultados y segmento de Observaciones, estar seguro para incluir cualquier técnica de optimización usted recomienda ser aplicado al diseño para asegurar que esto encuentra los requerimientos. Basado en los resultados de sus pruebas, usted podría recomendar mecanismos para minimizar los broadcast y el tráfico multicast, caracteristicas avanzadas para encontrar los requerimientos de calidad del servicio (QoS), y sostificados servicios de conmutación de router y que hacen cola. Ver la Fase IV para más información en técnicas de optimización.

o

Plan de Implementación El Plan de Implementación incluye sus recomendaciones para desplegar el diseño de red. El nivel de detalle en esta sección varía del proyecto de proyectar, y depende de su relación con su cliente.

Si usted es un miembro de unos Sistemas de Información (ES) el departamento que es responsable del diseño y la realización de la nueva red, entonces esta sección debería ser completamente detallada. Si usted es un ingeniero de

Marcos Huerta S.

297


ventas para un vendedor de productos conectados a una red, por otra parte, su papel debe recomendar probablemente soluciones, pero no ponerlos en práctica, entonces esta sección debería ser corta. (Usted debería evitar aparecer como si usted dice a sus clientes como hacer sus empleos.)

Los temas siguientes son convenientes para la sección de Plan de Implementación: v Una lista de proyecto. v Proyectos con vendedores o abastecedores de servicio para la instalación de enlaces, equipo, o servicios. v Proyectos o recomendaciones para externalizar la realización o dirección de la red. v Un plan para comunicar el diseño a usuarios finales, conecte a la red a administradores, y dirección. Esta sección también puede explicar como el progreso de implementación será comunicado (posiblemente vía reuniones de estado con regularidad previstas o mensajes de correo electrónico). v Un plan de formación para administradores de red y usuarios finales. v Un plan para medir la eficacia del diseño después de que ha sido puesto en práctica. v Una lista de riesgos conocidos que podrían retrasar el proyecto. v Un recurso planea si la realización de red falla. v Un plan para desarrollar el diseño de red como nuevos requerimientos de aplicación y objetivos se levanta.

o

Plan de Desarrollo del Proyecto El Plan de Implementación debería incluir una lista de proyecto o el objetivo. El nivel de detalle que usted incluye en una lista depende de su papel en el proyecto. En general, la lista debería incluir al menos las fechas y deliverables para las modificaciones principales. La Tabla 14-1 espectáculos un ejemplo de una lista de alto nivel que fue desarrollada por un ingeniero de ventas para un cliente actual.

Marcos Huerta S.

298


Table 14-1. La lista de alto nivel desarrollada para una red diseña al cliente. Fecha de Finalización

Actividad

El 1 de junio

El diseño completado y una versión de beta del documento de diseño distribuido a ejecutivos claves, gerentes, conecta a la red a administradores, y usuarios finales

El 15 de junio

Comentarios del documento de diseño

El 22 de junio

Documento de diseño final distribuido

El 25 de junio

Instalación de líneas arrendadas entre todos los edificios completados por abastecedor de servicio WAN

El 28-29 de junio Conecte a la red a administradores entrenados en el nuevo sistema 30 julio de junio 1

Los usuarios finales se entrenaron en el nuevo sistema

El 6 de julio

Implementación piloto completada en Edificio 1

El 20 de julio

Reacción recibida en piloto de administradores de red y usuarios finales

El 27 de julio

Implementación completada en Edificios 2–5

El 10 de agosto

La reacción recibió en Edificios 2–5 realización de administradores de red y usuarios finales

El 17 de agosto

Implementación completada en el resto de los edificios

En curso

El nuevo sistema supervisó para verificar que esto encuentra objetivos o

Presupuesto de Proyecto La sección de Presupuesto de Proyecto debería documentar los fondos que el cliente tiene disponible para compras de equipo, mantenimiento y acuerdos de soporte, contratos de servicio, licencias de software, formación, y proveer de personal. El presupuesto también puede incluir honorarios consultores y gastos de externalización.

o

Retorno de la Inversión En muchos casos el mejor modo de vender a un cliente en un nuevo diseño de red es convencer al cliente que el diseño pagará para sí en un período de tiempo razonable. El documento de diseño de red puede incluir un retorno de inversión (ROI) análisis que explica como rápidamente el diseño o el nuevo equipo se pagara por si mismo.

Lo siguiente es un ejemplo de un Retorno de Inversión que fue completado para un cliente actual, ABC de Cliente. El objetivo de este análisis Retorno de Inversión era demostrar al cliente que el equipo de conmutación WAN recomendado se pagará por si mismo muy rápidamente porque esto permitirá que el cliente para disminuir el número de líneas T1 requeridas, y a la baja de reduzca el costo de arrendar aquellas líneas de la compañía telefónica local.

Marcos Huerta S.

299


o

Análisis de Retorno de la Inversión para ABC de Cliente El ABC de cliente piensa gastar 1 millón de dólar para el nuevo equipo de conmutación WAN. Si el ABC de Cliente no gasta 1 millón de dólar para el equipo y en cambio pone el dinero en otras inversiones durante 5 años, el ABC de Compañía puede ganar el interés aproximadamente del 5 por ciento, y 1 millón de dólar original valdría 1.05 millones de dólares. Este significa que la inversión en el equipo realmente debería ser considerada 1.05 millones de dólares.

Una asunción fue hecha esto el equipo de conmutación WAN tendrá una vida útil de 5 años antes de que sea obsoleto. De este modo, el coste por año para poseer el equipo fue calculado como 1.05 millones de dólares divididos en 5, o 210,000 dólares. El coste por mes para poseer el equipo es 210,000 dólares divididos en 12, o 17,500 dólares.

El coste mensual debe ser comparado al costo de poseer los multiplexores de división de tiempo existentes (TDMs) que comprenden el diseño corriente. Aquel coste es 0 porque los TDMs son viejos y totalmente pagados para y se depreciaron.

Sin embargo, el costo de hacer funcionar la vieja red debe ser comparado al costo de hacer funcionar la nueva red. El nuevo diseño lo hará posible para el ABC de Cliente de usar 8 líneas T1 en vez de las 20 líneas T1 requeridas en el viejo diseño. Cada línea cuesta a ABC de Cliente 1500 dólares por mes. Este significa que 20 líneas cuestan 30,000 dólares por mes, y 8 líneas cuestan 12,000 dólares por mes. Los ahorros al ABC de Cliente con el nuevo diseño de red son 30,000 dólares – 12,000 dólares, o 18,000 dólares por mes. Considerando que el costo para el nuevo equipo es aproximadamente 17,500 dólares por mes, una conclusión puede ser sacada que el equipo pagará por si mismo. o

Apéndice del Documento de Diseño La mayor parte de documentos de diseño incluyen uno o varios apéndices que presentan la información suplemental sobre el diseño y realización. La información suplemental puede incluir mapas de topología detallados, configuraciones de dispositivo, dirección de red y nombramiento de detalles, y resultados completos de las pruebas del diseño de red.

Usted también puede incluir la información comercial como una lista de contactos en el sitio del cliente y en su organización, incluso direcciones de Marcos Huerta S.

300


correo electrónico, números de teléfono, números de buscapersonas, y direcciones físicas. La información en donde transportar equipo y cualquier requerimiento de embarque especial o procedimientos es una adición útil en algunos casos.

Si es necesario, el Apéndice puede incluir la información exacta en opciones de pago y fijación de precios. A veces las copias de órdenes de compra son incluidas. El Apéndice también puede contener términos legales y contractuales y condiciones, y acuerdos de no divulgación.

Algunos documentos de diseño incluyen la información sobre la compañía que presenta la oferta de diseño, incluso páginas de informes anuales, catálogos de producto, o comunicados de prensa recientes favorables a la compañía. El objetivo de este tipo de información es asegurarse que el lector entiende que la compañía es calificada para desarrollar y poner en práctica el diseño de red propuesto. De ser asignado, esta sección puede incluir recomendaciones de otros clientes para quien la compañía ha proporcionado una solución.

Marcos Huerta S.

301

2. Metodología Top Down - español.pdf

Recommend Documents