27 de noviembre de 2006

Infraestructura escalable con 10Gb Ethernet

Cuando abordamos el tema de la disponibilidad de ancho de banda de nuestras redes de datos muchas veces tengo la sensación de que estamos hablando de automovilismo. El concepto general es : cuando más rápido, mejor.

Y es que la realidad de nuestras redes ha sido esa: en la década de los '90 el estándar eran redes Ethernet de 10Mbps, y las redes Token Ring de 16 Mbps y FDDI de 100Mbps (sobre fibra óptica) se veían como "redes muy rápidas". Ya hacia el fin del siglo, el estándar típico eran redes FastEthernet de 100Mbps sobre cobre. Hoy ya a nadie le admira escuchar hablar de enlaces de 1Gb Ethernet, lo que empieza a verse casi como una norma; y el estándar de !0Gb Ethernet ya está presente para quedarse.

Por lo tanto, si estamos encarando el proyecto de una nueva red, o de actualizar una infraestructura ya existente, se debe tener presente y asegurarse que sea fácilmente escalable a los nuevos estándares Ethernet. Esto significa cubrir una serie de requisitos que permitan incrementar la velocidad de la red (la tecnología está disponible, la infraestructura debiera permitirnos implementarla) de modo que sea posible implementar nuevas aplicaciones e incrementar el tráfico sin dificultades.

La necesidad de velocidad
¿Porqué habría que pensar en 10Gb Ethernet?

Aunque nuestras terminales de escritorio funcionan excelentemente con accesos FastEthernet de 100Mbps; y las terminales wireless operan a 54 Mbps o menos, hay una serie de puntos que se deben considerar seriamente:

  • El tamaño de nuestros archivos está creciendo diariamente de modo alarmante. Y transferir archivos de mayor tamaño requieren más tiempo completar la transmisión o aumentar la velocidad para reducir los tiempos.
  • Progresivamente en el ámbito empresarial se implementan cada vez más aplicaciones, especialmente algunas que trabajan en tiempo real, que requieren disponibilidad de abundante ancho de banda para trabajar adecuadamente. Y la proyección que se observa en cuanto al desarrollo de nuevas aplicaciones, va en el mismo sentido.
  • Hay que tener en cuenta que el ancho de banda total de los backbone es compartido por todos los usuarios. Y nuestras redes tienen cada vez más cantidad de usuario, que utilizan archivos de mayor tamaño y corren aplicaciones en tiempo real simultáneamente.
  • Se implementan switches de alta velocidad para administrar el tráfico que se recibe desde los escritorios hacia servidores que en términos generales tienden a trabajar a 1 Gbps.

Una recomendación que suele darse en diseño al momento de planificar una nueva red o una actualización de infraestructura existente, es que se estimen los requerimientos a corto plazo y se multipliquen al menos por cinco.

10Gbps sobre cobre
Ethernet opera en las capas 1 y 2 del modelo OSI, y ha sido definida en la IEEE 802.3. El estándar de 10Gbps Ethernet se encuentra definido en la IEEE 802.3ae, utilizando los mismos estándares que el Ethernet original (direccionamiento físico, estructura y tamaño de tramas, etc.); esto es lo que asegura la compatibilidad de todas las implementaciones Ethernet desde 10Mbps hasta 10Gbps, incluyendo las redes wireless LAN 802.11. La diferencia más significativa es que no utiliza CSMA/CD ya que sólo opera en arquitecturas full dúplex.

Inicialmente los estándares 10Gbps Ethernet operaban exclusivamente sobre fibra óptica, pero la fibra es aún, no sólo más costosa que el cobra, sino también y especialmente, de implementación más compleja. De allí los esfuerzos que se han realizado para lograr estándares que operen a 10Gbps sobre cableado de cobre.

Los nuevos estándares pueden trabajar sobre cableado UTP categoría 5e o 6 con distancias de hasta 55 metros. Una alternativa aún mejor es operar con cableado categoría 6e o 7, con lo que se obtienen distancias de hasta 100 metros ya que reducen los problemas de alien crosstalk (ATX). Varios fabricantes ya están ofreciendo soluciones de este tipo.

Estos mismos estándares permiten tendidos de hasta 40 kilómetros, con el mismo ancho de banda, sobre fibra óptica. De este modo ya es posible desarrollar backbones para redes de campus, MANs y WANs de 10Gbps Ethernet.

Consideraciones para el planeamiento
En principio, al ser un estándar que operaba solamente sobre fibra óptica, se concibió 10Gbps Ethernet como un estándar para redes de backbone; pero con la aparición de estándares sobre cobre, es ahora posible pensar en un estándar (en principio) para granja de servidores y redes de almacenamiento.

En cuanto a costo, siguen siendo los enlaces de mayor costo en la actualidad, pero mucho menos costosos que en el año 2003 cuando se aprobaran los primeros estándares.

Por lo tanto, si bien es posible que la red actual no requiera o no cuente con el presupuesto para implementar 10Gbps Ethernet, es muy posible que en pocos años más se plantee reemplazar los backbone actuales de 1Gbps, o los accesos en servidores de esa velocidad. Por lo tanto, si bien es posible que no se instalen dispositivos de 10Gbps hoy, sí es preciso prever que el nuevo cableado de red (especialmente el de backbone y data center) sea categoría 6 o 7 de modo de soportar a futuro un upgrade de este tipo.

10Gbps Ethernet se presenta hoy como la próxima generación Ethernet que se convertirá en un estándar de la industria. Por lo tanto, nuestras redes deben estar preparadas para esto.

¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

25 de noviembre de 2006

Controle las actualizaciones de los protocolos de enrutamiento

La administración del uso del ancho de banda de nuestros enlaces es un punto sensible en la tarea diaria del Administrador de la red.

En este punto es importante considerar el tráfico que generan los protocolos de enrutamiento que se implementan. Muchas veces carece de sentido el envío de actualizaciones de enrutamiento a través de interfaces a las que no hay conectados dispositivos que dialoguen utilizando ese mismo protocolo. En otras ocaciones, razones de seguridad hacen aconsejable no publicar el estado de nuestras redes a través de determinadas interfaces.

Filtrar el envío de actualizaciones de enrutamiento brinda 2 ventajas: optimiza el uso del ancho de banda de nuestros enlaces, a la vez que reduce el uso de la CPU de nuestros dispositivos.

Hay dos modos básicos de filtrar el envío de actualizaciones de enrutamiento: el pasivado de interfaces y el uso de listas de distribución. En este artículo he de centrarme en el pasivado de interfaces utilizando el comando passive-interface.

El comando passive-interface
Cuando se desea configurar apropiadamente un protocolo de enrutamiento, este es un comando que es necesario conocer.

Es un comando de configuración del protocolo de enrutamiento y se utiliza para indicar al protocolo que se está configurando que NO envíe actualizaciones de enrutamiento a través de una interfaz determinada.

  • Este comando está disponible para ser utilizado con todos los protocolos de enrutamiento excepto BGP.
  • En RIP, IGRP y EIGRP, indica simplemente que no se envían actualizaciones, pero la interfaz seguirá copiando las que reciba de sus colindantes.
  • En OSPF la interfaz pasivada no recibirá ni enviará actualizaciones de enrutamiento.
  • Y OSPF y EIGRP, suprime el envío de paquetes hello, por lo que se impide el establecimiento de relaciones de vecindad con los colindantes. Por este motivo, en estos protocolo la sugerencia es implementar listas de distribución.

Primera forma de implementación
La primera forma de implementar el pasivado de interfaces es indicar qué interfaces deben pasar al estado pasivo, o no han de enviar actualizaciones.

Un ejemplo de configuración:

Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 172.16.0.0
Router(config-router)#network 172.17.0.0
Router(config-router)#network 172.18.0.0
Router(config-router)#passive-interface fastethernet 0/0

De este modo, luego de activar el protocolo en todas las redes directamente conectado indicamos que no se publiquen actualizaciones de enrutamiento a través de la interfas FastEthernet 0/0, a la que, por ejemplo, está conectada nuestra red LAN.

Segunda forma de implementación
Otra forma de pasivar interfaces es pasivar todas las interfaces que están comprometidas en el proceso de enrutamiento y luego habilitar el envío solamente a través de las interfaces elegidas.

Volviendo a nuestro ejemplo:

Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 172.16.0.0
Router(config-router)#network 172.17.0.0
Router(config-router)#network 172.18.0.0
Router(config-router)#passive-interface default
Router(config-router)#no passive-interface serial 0/1

En este caso se está bloqueando el envío de actualizaciones de enrutamiento a través de todas las interfaces del dispositivo, excepto la interfaz serial 0/1.

¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

18 de noviembre de 2006

Configuración de hora y zona horaria en dispositivos

Cuando se configura un router o un switch, no es realmente necesario configurar la hora y la zona horaria del dispositivo para que este opere correctamente en la red. Realmente la configuración de hora en los dispositivos no es en nada necesario para que el dispositivo desarrolle sus tareas tal como se espera. Sin embargo, esto no significa que no sea necesario configurar la hora y el huso horario de los dispositivos. Algunos de los beneficios de realizarlo son:

  • Los archivos log y los mensajes debug mostrarán la fecha y hora correctos. Esto es de suma importancia de en las tareas de diagnóstico de fallos.
  • Configurar el uso horario correcto, hace posible establecer comparaciones entre la operación de dispositivos instalados en diferentes regiones.
  • Permite agendar la ejecución de comandos utilizado el feature kron de Cisco IOS.
Cisco IOS permite realizar este ajuste horario de 2 modos diferentes:
  • Configurando hora y huso horario en cada dispositivo individualmente.
    Es un modo adecuado para ajustar este recurso cuando se desea configurar solamente un grupo pequeño de dispositivos.
  • Implementar el uso de NTP (Network Time Protocol) en todos los dispositivos de la red.
    Este es el método ideal para establecer un indicador horario sincronizado en dispositivos que operan en redes de mediano o gran tamaño.
Configuración de hora y huso horario en dispositivos individualmente.
Si un dispositivo Cisco conserva su configuración horaria por defecto (no ha sido modificada por configuración), la fecha ha de estar fijada en el día lunes 1 de marzo de 1993:

Router#show clock
*02:37:22.871 UTC Mon Mar 1 1993
Router#


Si se obtiene este valor como respuesta a un show clock, esto nos indica que nadie a configurado una fuente de sincronía o una hora localmente.
Configuración del huso horario
El primer paso es configurar correctamente el huso o zona horaria. Si se configura primero la hora y luego el huso horario, al configurar el huso horario se reiniciará el reloj.

Para esta tarea, es necesario conocer como información previa la diferencia horaria respecto de Greenwich Mean Time (GMT). En el caso de Argentina, nuestro huso horario es GMT -3.
Para configurar el uso horario, debe utilizar el comando:
Router(config)#clock timezone AR -3
Router(config)#_

El comando permite asignar un nombre al huso horario que estamos configurando, de modo de identificarlo luego.
Debemos considerar también que hay países y regiones que modifican su huso horario de acuerdo a la estación del año con fines de ahorro de energía. En estos casos podemos indicar al dispositivo que debe cumplir con esta norma utilizando el comando:
Router(config)#clock summer-time AR recurring
Router(config)#_

De este modo se le indica que actúe de modo automático atrasando o adelantando el uso horario de AR (si bien este no es aplicable a Argentina) de acuerdo a las fechas estándar internacionalmente utilizadas (abril y octubre). También se puede establecer manualmente la fecha de cambio con este mismo comando pero con la variante date en lugar de recurring.
Configuración de la hora
El siguiente paso es configurar el reloj del dispositivo. Esta tarea se realiza desde el modo privilegiado, no desde el modo configuración global.

Esta tarea se realiza con el siguiente comando:
Router(config)#exit
Router#clock set 19:24:00 Nov 18 2006
Router#_

Tenga en cuenta las siguientes particularidades:
  • Se configura en modo privilegiado.
  • El comando requiere que se incorporen todos los elementos: la hora debe incluir segundos y la fecha debe ser completa.
  • El mes se ingreso utilizando las 3 primeras letra del mes en inglés.
Para ver la hora
Para visualizar la hora configurada utilice:

Router#show clock
19:27:38.311 Arg Sat Nov 18 2006
Router#_

Más allá de lo hasta aquí dicho, es preciso tener en cuenta que muchos dispositivos Cisco carecen de un reloj interno que almacene esta información. Por lo tanto, si el dispositivo es reiniciado se pierde la configuración de la hora local. La configuración de huso horario se mantiene pues se almacena con el archivo de configuración.
Otro inconveniente que presenta este comando, es que al configurar individualmente dispositivo por dispositivo, se dificulta la comparación de archivos log (registro de sucesos) de diferentes dispositivos. Muchas veces la tarea de diagnóstico de fallos requiere que se comparen sucesos ocurridos en múltiples dispositivos. En este caso es muy importante y altamente recomendable, que todos los dispositivos sincronicen sus relojes con una única fuente de modo que el registro horario de todos esté sincronizado.
Sincronización del reloj de los dispositivos utilizando NTPPara el diagnótico de fallos de una red es casi imperativo que los relojes de los dispositivos (inclídos también por ejemplo el de los servidores y firewalls) estén sincronizados entre sí. Con este propósito Cisco IOS implementa Network Time Protocol. En el caso de los dispositivos Cisco, la implementación de este protocolo permite superar la limitación que impone la falta de un reloj interno.
NTP es un protocolo diseñado específicamente para sincronizar los relojes de los procesadores que operan en una red. NTP versión 3 es un protocolo estándar definido en RFC 1305 que utiliza para su operación el puerto 123 de UDP.
Un cliente NTP sincroniza su fecha y hora con un servidor NTP. El servidor NTP ha de ser una fuente confiable de información horario, como puede ser un time server de Internet. Hay varios servicios públicos y gratuitos de este tipo. Uno ampliamente utilizado es el servicio basado en el reloj atómico del National Institute of Standards and Technology (NIST).
Para aplicar NTP a la red corporativa se puede implementar una fuente horaria propia, o utilizar un servicio libre de Internet. Para implementar una fuente propia se debe adquirir una fuente de clock que puede obtener la información precisa a través de GPS u otro método.
Para configurar NTP en dispositivos Cisco IOS, ante todo tenga en cuenta:
  • NTP es un protocolo lento por lo que formar una asociación NTP toma tiempo. Si desea verificar que se esté realizando la asociación con el servidor NTP puede utilizar el comando debug ntp.
  • Si se utiliza un servidor NTP de Internet (como en el ejemplo de abajo), asegúrese de que se puede abrir una sesión UDP a través del puerto 123 (verifique el firewall).
Una vez que se ha asegurado estos puntos, siga el siguiente procedimiento:
  1. Seleccione un servidor NTP a utilizar.
    Por ejemplo, en el caso de Argentina: tock.nap.com.ar
  2. Obtenga la dirección IP del servidor.
    En el caso de nuestro ejemplo: 200.49.40.15
  3. Configure el servidor NTP en el dispositivo.
  4. Verifique la configuración utilizando los comandos show ntp status y show ntp associations.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ntp server 200.49.40.15
Router(config)#_


¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

16 de noviembre de 2006

Índice de artículos sobre tecnologías

Este índice de artículos está siempre disponible en
la columna de la derecha del weblog; en el área titulada "Enlaces Útiles".
Consúltelo siempre que le resulte necesario.

Este es un listado de los artículo publicados hasta el momento en el weblog, referidos a tips de configuración, tecnologías, etc.

Cisco IOS
Comandos
Diagnóstico de Fallos
Routing
Seguridad
Subredes, VLSM, CIDR
Switching
Tecnologías Ethernet
VoIP
Wireless


13 de noviembre de 2006

Enrutamiento BGP Básico


¡¡Un nuevo título se suma a la colección!!

Cada día son más las empresas y organizaciones que optan por administrar sus propias políticas de enrutamiento hacia y desde Internet implementando BGP en el borde de su conexión con sus proveedores de servicio. También son cada vez más las redes corporativas que están implementando MPLS sobre BGP. Esto genera la necesidad de que los Administradores de estas redes estén adecuadamente capacitados en la administración de un protocolo de enrutamiento fascinante y complejo.
Este manual ha sido pensando específicamente para el entrenamiento del personal técnico de organizaciones o empresas que requieren implementar BGP versión 4 para su conexión a Internet a fin de administrar las políticas de enrutamiento con sus proveedores de servicios. Está desarrollado considerando específicamente las características y funcionalidades que ofrece CiscoIOS para la implementación de redes BGP4, dado que es la plataforma dominante en Internet en este momento.
Fecha de publicación: 1 de diciembre de 2006
Autor: Oscar A. Gerometta
Texto:
Se trata de un manual de estudio introductorio que permite una iniciación gradual en la complejidad y características del protocolo.

Supone conocimientos suficientes de los modelos teóricos de redes (modelos OSI y TCP/IP), de direccionamiento IP (subredes, VLSM, CIDR) del funcionamiento y características de Cisco IOS, y de la lógica y operatoria del enrutamiento IP. En términos generales es recomendable que quién desee abordar este tema antes haya cubierto los conocimientos comprendidos en el examen de certificación CCNA.
Contenidos:
  • Conceptos generales de enrutamiento IP
  • Implementación de Cisco IOS routing features
  • Introducción a BGP
  • EBGP e IBGP
  • Configuración de las operaciones básicas de BGP
  • Selección de una ruta BGP
  • Utilización de route-maps para manipular rutas BGP
  • Anexo: Comandos de configuración
  • Anexo: Ejemplos de configuración BGP
  • Anexo: Glosario de siglas y términos.
Cantidad de páginas: 186
Para ver una demo de este manual, ingrese aquí.
Fe de Erratas


Para la adquisición:
  • Para reservar tu ejemplar del texto impreso: solicitalo por correo electrónico a libros.networking@gmail.com y lo recibirás en Argentina por Correo Argentino contrareembolso; en el exterior por Correo Argentino y hacen el pago por Western Union.
  • El Manual de Enrutamiento BGP Básico en formato e-book  está disponible a través del blog de e-books de Ediciones EduBooks.
Como siempre, cualquier sugerencia que puedas hacer, será muy bien venida.Saludos.
Oscar A. Gerometta

Introducción a BGP4

Con el avance progresivo de los servicios de red, y particularmente de Internet, el acceso a la Red de Redes se ha vuelto un recurso indispensable en la operación de muchas empresas. Consecuentemente, la conexión con el Internet Service Provider (ISP), y la redundancia en la conexión a Internet se han convertido en recursos críticos para la operación de la empresa.
Veamos entonces cuáles son las caraterísticas generales de este protocolo de enrutamiento de gateway exterior (EGP).
Concepto esencial: Sistema Autónomo
BGP4 es un protocolo de enrutamiento específicamente desarrollado para administrar el intercambio de información de enrutamiento entre diferentes sistemas autónomos. ¿Qué es un Sistema Autónomo?

La RFC 4271 define al sistema autónomo como un conjunto de dispositivos bajo una misma administración técnica, que utilizan un IGP (protocolo de enrutamiento interior) y una métrica común para enrutar los paquetes dentro del propio sistema autónomo, y usan un IDRP (InterDomain Routing Protocol)para determinar cómo se enrutan los paquetes hacia otros sistemas autónomos.
Un sistema autónomo puede implementar más de un protocolo de enrutamiento interior. Lo realmente importante es que el sistema autónomo tenga un plan de enrutamiento coherente y convergente de modo tal que asegure que todas las partes del sistema autónomo se conectan correctamente entre sí.
Cada sistema autónomo es una unidad administrativa que se diferencia y reconoce a través de un ID de sistema autónomo. IANA (Internet Assigned Numbers Authority) es el organismo responsable de la asignación de los ID de sistemas autónomos.
El ID de sistema autónomo es un número de 16 bits, con un valor posible entre 1 y 65535. Su uso y asignación está orientado por la RFC 1930. Los sistemas autónomos 64512 a 65535 están reservados para uso privado
Características de BGP4:
Diseñado para el enrutamiento entre sistemas autónomos o dominios de enrutamiento.
BGP es un protocolo estándar definido en un conjunto de RFCs. Originalmente lanzado en 1989 a través del RFC 1105. La versión más actualizada es BGP4 y ha sido definida en 1995 a través de la RFC 4271.
BGP4 es el primer protocolo de enrutamiento exterior que soporta CIDR y sumarización de rutas.
Transporta la máscara de subred para cada red anunciada.
No busca la ruta más rápida. Es un protocolo basado en políticas de enrutamiento (PBR – Policy-Based Routing). Las rutas son seleccionadas no en función de métricas sino de reglas o políticas de enrutamiento. Esto le permite al sistema autónomo controlar el flujo de tráfico.
Distancia administrativa por defecto:
  • Para rutas entre sistemas autónomos (EBGP): 20
  • Para rutas internas del sistema autónomo (IBGP): 200
Es un protocolo de ruta-vector. Define una ruta como una secuencia de sistemas autónomo que deben ser atravesados para alcanzar la red destino.
La información de enrutamiento que intercambia está referida a la accesibilidad de las redes de destino, e incluye entre otros elementos:
  • La ruta expresada como la sucesión de sistemas autónomos que es necesario atravesar (salto por salto) para alcanzar la red de destino.
  • El listado de todas las redes accesibles al final de esa ruta de sistemas autónomos.
  • La dirección IP de la puerta de entrada al próximo sistema autónomo en la ruta.
  • Una serie de "atributos" que definen el modo en que será tratada la ruta: origen de la información de la ruta, peso de la ruta, preferencia local, MED.
Diferencias respecto de los protocolos de vector distanciaMuchas veces se menciona a BGP como un protocolo de vector distancia avanzado, sin embargo, tiene diferencias muy importantes que hacen a su eficiencia y funcionamiento.
Las características más importantes respecto de los protocolos de vector distancia son las siguientes:
  • Utiliza TCP como protocolo en la capa de transporte, lo que asegura una comunicación confiable orientada a la conexión. Utiliza el puerto 179 de TCP.
  • En el inicio de la conexión se intercambian las tablas de enrutamiento completas. A partir de ese punto se envían solamente los cambios (actualizaciones incrementales o disparadas por eventos).
  • Dado que no se requieren actualizaciones periódicas, BGP sólo envía mensajes de keepalive, cuya función es semejante a la de los mensajes hello en protocolos como OSPF y EIGRP.
  • El transporte de información sobre conexiones TCP confiables asegura mayor eficiencia para la comunicación de volúmenes importantes de información como son los que corresponden a la cantidad de rutas que requiere hoy Internet (170 a 250.000 rutas).
  • Las actualizaciones de enrutamiento pueden contener tanto información referida a nuevas rutas disponibles, como a rutas que han dejado de estar disponibles (withdraw).

Bibliografía sugerida:
Enrutamiento BGP Básico - Oscar Gerometta

¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

10 de noviembre de 2006

¿Qué es AutoQos?

Con el avance progresivo de las redes convergentes, y particularmente de algunos servicios como los de telefonía y video sobre IP (CoIP comunicaciones sobre IP) se ha introducido un concepto que es cada día más generalizado: Calidad de Servicio (QoS).

Paralelamente, y como ya nos tiene acostumbrados, Cisco marcha a la vanguardia de la introducción de estas nuevas tecnologías y propuestas. Cisco IOS implementa hoy varios métodos diferentes de implementación de QoS, tantos y tan complejos como para que se haya dedicado libros completos solamente al tema.

Pues bien, Cisco ha desarrollado una nueva forma de QoS denominada AutoQoS y que tiene como propósito facilitarle al Administrador de la red el seteo básico de los atributos de QoS.

Revisemos primero lo básico
QoS ofrece entre otros, estos beneficios:

  • Prioriza el tráfico que es sensible al delay; por ejemplo, para asegurarnos de que el tráfico de voz no sea afectado por un delay excesivo se le da prioridad al momento de reenviarlo.
  • Prioriza tráfico de modo tal que las aplicaciones no-críticas para la operación de la empresa no ralenticen o entorpezcan el tráfico que corresponde a aplicacíones críticas para el negocio de la empresa.
  • Prioriza tráfico para asegurar que tráfico indeseable en la red no sobrecargue el uso de ancho de banda.
  • Preservar el ancho de banda dilatando el reenvío de información no crítica para la empresa.

En dispositivos Cisco IOS se puede configurar QoS de diferentes modos. Las 4 opciones principales son:

  • Configurar QoS manualmente creando listas de acceso para identificar tráfico que luego es controlado con comandos específicos de QoS.
  • Utilizar el QoS Wizard de SDM (Security Device Manager) de Cisco para crear políticas QoS predefinidas que pueden ser editadas más tarde.
  • Utilizar AutoQoS para crear políticas basadas en el flujo de tráfico en tiempo real a través del router o switch.
  • Utilizar AutoQos para crear políticas predefinidas para el flujo de tráfico de VoIP a través de los dispositivos Cisco IOS.

Los beneficios de AutoQoS
AutoQoS se encuentra disponible en los routers Cisco IOS desde la serie 2600 hasta la serie 7200 y también en la mayoría de los routers Cisco que utilizan versiones de IOS 12.2(15)T y posteriores. AutoQoS ofrece los siguientes beneficios:

  • No requiere una comprensión avanzada de QoS del mismo modo que si se desea configurar desde la línea de comandos.
  • Se pueden modificar las políticas de QoS y reutilizarlas, del mismo modo que si se tratara de un template.
  • Se ahorra mucho tiempo de configuración.

Antes de ejecutar los comandos AutoQoS, se debe habilitar CEF utilizando el comando

Router(config)#ip cef

Adicionalmente se requiere la configuración de la declaración de ancho de banda en las interfaces ya que AutoQoS utiliza esta información cuando se configuran limitaciones de ancho de banda por protocolo para ser priorizados.

Router(config)#interface serial0/0
Router(config-if)#bandwidth 2000000

Si se modifica la configuración de este parámetro una vez que se activó AutoQoS, será necesario reiniciar AutoQoS. También es necesario tener presente no configurar AutoQoS en modo configuración global, sino en las interfaces.

Configuración de AutoQoS
Su configuración es muy simple y fácil, lo verdaderamente complicado es comprender qué es lo que se está configurando, modificar la configuración si es necesario, y probar lo hecho para ver si funciona como se esperaba. A modo de ejemplo configuremos AutoQoS para VoIP.

AutoQoS para VoIP opera sobre cierto tipo de interfaces. El ejemplo más simple es su activación en un enlace E1 punto a punto entre las interfaces seriales de 2 routers que utilizan este enlace para enviar tráfico de VoIP.

Para configurar AutoQoS, la secuencia de comandos en la interfaz que hace de origen del tráfico que deseamos controlar es:

Router(config)#interface serial0/0
Router(config-if)#auto qos voip

Con ese solo comando, Cisco IOS automáticamente genera una serie de comandos de configuración que se pueden verificar utilizando show running-config:

class-map match-any AutoQoS-VoIP-Remark
.match ip dscp ef
.match ip dscp cs3
.match ip dscp af31
class-map match-any AutoQoS-VoIP-Control-UnTrust
.match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
.match protocol rtp audio
.match access-group name AutoQoS-VoIP-RTCP
!
!
policy-map AutoQoS-Policy-UnTrust
.class AutoQoS-VoIP-RTP-UnTrust
..priority percent 70
..set dscp ef
.class AutoQoS-VoIP-Control-UnTrust
..bandwidth percent 5
..set dscp af31
.class AutoQoS-VoIP-Remark
..set dscp default
.class class-default
..fair-queue
!

interface Serial0/0
.auto qos voip
.service-policy output AutoQoS-Policy-UnTrust
!
ip access-list extended AutoQoS-VoIP-Control
.permit tcp any any eq 1720
.permit tcp any any range 11000 11999
.permit udp any any eq 2427
.permit tcp any any eq 2428
.permit tcp any any range 2000 2002
.permit udp any any eq 1719
.permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
.permit udp any any range 16384 32767


Calma... no es el objeto de este artículo analizar estas modificaciones :)
Si deseás comprenderlas, sugiero estudiar en serio QoS. Simplemente pretende que tomemos conciencia de lo que quise decir al afirmar que la configución de AutoQoS es fácil, y que lo complejo es comprender lo que se está haciendo y mucho más modificar este configuración.

Algunos elementos básicos para comprender lo que está haciendo:

  • Las listas de acceso definen cierto tipo de tráfico.
  • Los class-maps convierten ese tráfico en clases. El comando identifica el tráfico que debe colocar en cada clase a través de la lista de acceso.
  • El policy-map asigna prioridades a las clases.
  • Ese policy-map está aplicado a la interface, para afectar el tráfico que sale a través de ella.

Este mismo procedimiento debe aplicarse en la interfaz del otro extremo del enlace, Es altamente recomendable implementar primero este comando en un laboratorio de prueba, antes de utilizarlo en la red en producción.

Ir A la información sobre la Guía

Recursos en línea:

¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

6 de noviembre de 2006

Supernetting


Se llama Supernetting (también se suele denominar sumarización de rutas o route aggregation) a un procedimiento que aprovecha los principios de CIDR para direccionar hacia una cantidad de subredes IP utilizando una única ruta. A la ruta que se obtiene se la suele denominar ruta sumarizada o supernet.

Se comprende mejor a partir de un ejemplo:
Supongamos que en un switch multilayer confluyen 4 subredes:
  • 172.16.0.0/24
  • 172.16.1.0/24
  • 172.16.2.0/24
  • 172.16.3.0/24
Si deseamos sumarizar estas 4 subredes (que hipotéticamente requieren 4 rutas diferentes en los dispositivos vecinos) en una única red a publicar, podemos sintetizarlas en la supernet IP: 172.16.0.0/22.. Esta única supernet refiere a las 4 subredes iniciales:
Dirección IP....10101100.00010000.00000000.00000000
Máscara.........11111111.11111111.11111100.00000000

Obsérvese el tercer octeto:
  • Máscara.........11111100
  • Subred 0.........00000000
  • Subred 1.........00000001
  • Subred 2.........00000010
  • Subred 3.........00000011
Los bits resaltados en negrita son los que corresponden a la porción que identifican la red con una máscara de 22 bits. En este caso, las 4 subredes /24 tienen el mismo patrón binario, por lo que pueden sintetizarse en una única ruta.
Es preciso tener presente que para implementar supernetting es necesario utilizar protocolos de enrutamiento que soporte VLSM y CIDR como son: RIPv2, EIGRP, OSPF, IS-IS o BGP. Cuando se implementa algunos de estos protocolos, dependiendo del protocolo, Cisco IOS habilita o no por defecto la función de auto-sumarizar rutas a las fronteras de la clase. La sumarización también puede configurarse manualmente.
Esta es una práctica importante en redes corporativas grandes, por lo que significa en ahora de recursos de procesamiento y memoria la reducción de tamaño de las tablas de enrutamiento. En Internet en cambio, es una práctica esencial para poder mantener el tamaño de las tablas de enrutamiento dentro de límites admisibles.

Ir A la información sobre la Guía
Recursos sobre subnetting
¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

5 de noviembre de 2006

Fe de Erratas

El siguiente es un listado de los errores detectados en los diferentes títulos publicados:







Guía de Preparación para el Examen de Certificación CCNA

Guía de Preparación para el Examen de Certificación CCNA

pág. 81
En la síntesis de "Modelos teóricos de una red de datos - Modelo TCP/IP"
Donde dice: "Transmisión".
Debe decir: "Transporte".

pág. 93
En la pregunta 25
Se debe agregar al final de la pregunta "(elija 2)".

pág. 102
Bajo el título "Protocolo ARP"
Donde dice: "... Pero no tiene la dirección IP. Sin embargo, la dirección IP es necesaria..."
Debe decir: "... Pero no tiene la dirección MAC. Sin embargo, la dirección MAC es necesaria... "

pág. 137
Bajo el título "Sumarización de rutas"
Donde dice: "... ha entregado 8 redes clase C... "
Debe decir: "... ha entragado 8 redes clase B... "

Donde dice: "... se puede sumarizar las 8 rutas a cada red clase C..."
Debe decir: "... se pueden sumarizar las 8 rutas a cada red clase B..."

pag.233
Bajo el título "IGRP"
Donde dice: "... aprovechamiento del ancho de bando."
Debe decir: "... aprovechamiento del ancho de banda"

pag. 250
En el desarrollo de enrutamiento por vector distancia
Donde dice: "... desde la perspectiva de los vecino."
Debe decir: "... desde la perspectiva de los vecinos."

pag. 266
Pregunta 29
Donde dice: "(elija 3)"
Debe decir: "(elija 2)"

pag. 374
En los puntos finales de las Notas Previas
Donde dice: ".Hay que adquirir ..."
Se debe eliminar el punto inicial: "Hay que adquirir ..."

pag. 375
Bajo el título "Aplicación al cálculo de la máscara de wildcard"
Donde dice: "Tomo hicimos en el caso ..."
Debe decir: "Como hicimos en el caso..."

pag. 498
Pregunta 22
Donde dice: "... van de la 172.25.64.1 a la 172.25.95.255"
Debe decir: "... van de la 172.25.64.1 a la 172.25.95.254"

Si crees haber encontrado un error que no se encuentra en este listado,
por favor, hacelo llegar a
ogerometta@gmail.com
Lo evaluaré e incluiré en esta lista si es necesario.
Muchas gracias.
Oscar Gerometta







Enrutamiento BGP Básico

Curso de Enrutamiento BGP Básico

pag. 53
Donde dice: "En caso particular al pasivar interfaces lo constituyen..."
Debe decir: "Un caso particular al pasivar interfaces lo constituyen..."

Pag. 80
En la figura, en la nube superior en la que hay 2 números de AS.
Donde dice: "AS 39700"
Debe decir: "AS39710"

Pag. 82
En la figura, en la nube superior en la que hay 2 números de AS.
Donde dice: "AS 39700"
Debe decir: "AS39710"

Pag. 80
En la figura, en la nube superior en la que hay 2 números de AS.
Donde dice: "AS 39700"
Debe decir: "AS39710"

Pag. 102
En la figura, en la configuración que corresponde al router A.
Donde dice: "neighbor 10.1.1.5 remote-as"
Debe decir: "neighbor 10.1.1.5 remote-as 39700"

pag. 139
En la nota al título "Selección de rutas en BGP"
Donde dice: "BGP no soporta balanceo de carga."
Debe decir: "BGP, por defecto, no soporta balanceo de carga."

Si crees haber encontrado un error que no se encuentra en este listado,
por favor, hacelo llegar a
ogerometta@gmail.com
Lo evaluaré e incluiré en esta lista si es necesario.
Muchas gracias.
Oscar Gerometta