30 de agosto de 2010

Modelos de implementación de QoS

Calidad de Servicio (QoS) es un requerimiento creciente en las redes actuales. La presencia de tráfico de VoIP y crecientemente de video o multicast en la misma infraestructura que se utiliza para el tráfico de datos requiere de la implementación de QoS a fin de asegurar una correcta prestación de cada uno de los servicios.
Por esto me ha parecido conveniente ir introduciendo algunos conceptos relacionados con este tema. Y en primer lugar, referirme a los diferentes modelos de implementación.


Modelos de implementación de QoS
En la actualidad hay 3 modelos de aplicación de calidad de servicios para redes de datos:
  • Best-Effort.
    No se discrimina ningún tipo de tráfico y se brinda el mejor soporte posible desde la infraestructura.
  • IntServ.
    Las aplicaciones cuyo tráfico requieren tratamiento diferencial señalizan la red para requerir y garantizar los recursos necesarios para el adecuado funcionamiento de la aplicación.
    Garantiza las condiciones de operación de cada una de las sesiones que se establecen.
  • DiffServ.
    La infraestructura de la red es la que reconoce los diferentes tipos de tráfico y aplica políticas diferenciadas para cada clase de tráfico.
    Es más escalable y flexible en su implementación.
Best Effort
Es el modelo aplicado en Internet, y el que aplica por defecto toda red que no tiene políticas explícitamente definidas.
No garantiza ningún tratamiento o recurso específico a ningún flujo de información. Todo paquete es tratado de igual forma; no hay tratamiento preferencial.
Las principales características del modelo son:
  • Altamente escalable.
  • No requiere mecanismos o configuraciones especiales.
  • No garantiza recursos ni diferencia ningún tipo de servicio.
IntServ
Modelo de implementación de servicio bajo demanda. Tiene como objetivo garantizar recursos disponibles a lo largo de una ruta para una aplicación específica.
Antes de iniciarse propiamente la sesión de la aplicación se señaliza la ruta para verificar la disponibilidad de los recursos necesarios para un adecuado desarrollo de la misma .Una vez que la aplicación realiza la reserva de recursos la misma se mantiene aún cuando la aplicación no la esté utilizando, hasta tanto se levante la reserva de recursos. Permite garantizar las condiciones de operación de aplicaciones críticas.
Sus características más importantes son:
  • Negocia condiciones específicas de calidad de servicio antes de que se inicie la comunicación propiamente dicha.
  • Una vez hecha la reserva, la aplicación cuenta con los recursos reservados más allá de la situación de tráfico de la red.
  • Puede adecuarse a demandas específicas y diferentes de cada tipo de tráfico o aplicación.
  • La reserva de recursos se realiza para cada flujo de información en particular. No se reservan recursos en función de la aplicación genéricamente.
  • Cuando se asocia a desarrollos de telefonía IP, da una aproximación orientada a la conexión para este tipo de servicios. Cada dispositivo a lo largo de la ruta configura y mantiene la operación de cada comunicación individualmente.
  • Utiliza los servicios de RSVP (Resource Reservation Protocol).
  • No es escalable en grandes redes o implementaciones muy complejas.
DiffServ
Modelo de implementación de recursos garantizados de modo genérico y no por flujos o sesiones. Permite garantizar diferentes condiciones de servicio para diferentes tipos de tráfico, de modo escalable y efectivo, a través de toda la red.
  • No requiere señalización previa.
  • No permite garantizar condiciones de tráfico extremo a extremo.
  • Es muy flexible y escalable.
  • Divide el tráfico en clases en función de los requerimientos de la organización.
  • Cada paquete recibe el tratamiento que se ha definido para la clase a la cual ese paquete pertenece.
  • A cada clase se le puede asignar un diferente nivel de servicio y con ello diferentes recursos.
  • La asignación de recursos se hace salto por salto en cada dispositivo de la red y no para una ruta específica.
  • El mecanismo de implementación es relativamente complejo.
Para consultar:
¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

22 de junio de 2010

IEEE 802.3ba - hasta 100 Gbps Ethernet

La IEEE ha ratificado el 17 de junio pasado el estándar 802.3ba para conexiones Ethernet de 40 y 100 Gbps. Es la etapa final para la aprobación del estándar Ethernet de 100 Gbps con el que han estado proveyendo equipamiento de alta performance tanto Cisco como Juniper.
Como su nombre lo indica, permite establecer servicios Ethernet de 40 y de 100 Gbps tanto en implementaciones LAN como WAN. Inicialmente se ha pensado en los desarrollo de 40 Gbps para conexiones de alta velocidad de servidores y switches de core; de 100 Gbps para enlaces troncales de transporte de Internet y video sobre IP. Ambas opciones son aplicables sobre redes de transporte de fibra óptica.
Por supuesto que como en casos anteriores, se mantiene compatibilidad hacia atrás con el resto de la familia Ethernet.

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

18 de junio de 2010

Resolvamos un ejercicio de subredes

Las ejercicios de subredes que suelen plantearse pueden tener diferentes metodologías de resolución. Yo mismo he presentado en este blog algunos procedimientos que pueden servir para estos temas.
Sin embargo, cuando nos iniciamos en el tema, siempre resulta difícil encarar los enunciados y llevar adelante el cálculo. Es por esto que me pareció útil para todos los que consultan por el tema de subredes, trabajar sobre un ejemplo.
Para esto elegí un ejemplo que me acercó Belu como comentario hace unos días:


Dada la red 65.0.0.0/8. Se necesitan definir 934 subredes. 
  • Indique que máscara deberia ser utilizada. 
  • Indique cual seria la subred numero 817 indicando el rango de direcciones asignables, dirección de red y broadcast.
Bien, vayamos por partes.

Cálculo de la máscara de subred
Nuestro punto de partida es la red 65.0.0.0/8
Es una red clase A, en consecuencia, la máscara de subred por defecto es 255.0.0.0
Se requieren 934 subredes.
  • Debemos buscar la primer potencia de 2 que sea mayor al número de subredes requeridas. Esto es 1024 (si tomamos las potencias de 2: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024). 1024 = 2 elevado a la décima potencia.
  • Esto significa que la máscara de subred deberá tomar 10 bits para definir las subredes, con lo que nuestra máscara de subred será 8 + 10 = 18
    8 por la máscara por defecto.
    10 para generar las 934 subredes requeridas.
  • La máscara de subred es entonces 255.255.192.0 (8 bits + 8 bits + 2 bits = 11111111.11111111.11000000.00000000)
  • Como consecuencia de esto, quedan 14 bits para el identificador del nodo. Así, cada subred puede tener un total de 2 a la 14 direcciones IP = 16384 direcciones IP en cada subred.
Calculando la subred 817
Hay varias formas de desarrollar este cálculo, desarrollaré el que creo más adecuado para este caso concreto.
  • Nuestra máscara de subred tiene 10 bits (8 del segundo octeto y 2 del tercero) para identificar las subredes.
  • Si esto lo ponemos de un modo más gráfico: RRRRRRRR.SSSSSSSS.SSnnnnnn.nnnnnnnn donde R son los bits que identifican la red 65.0.0.0, S los bits que identican la subred y n los bits que identifican el nodo.
  • Como primer paso, convertimos el ID de la red que estamos buscando a nomenclatura binaria.
    817 = 1100110001
  • Distribuimos los 10 bits en las posiciones que corresponden a la máscara de subred dentro de nuestra estructura: RRRRRRRR.11001100.01nnnnnn.nnnnnnnn
    Lo que equivale en nuestro ejemplo a: 65.11001100.01nnnnnn.nnnnnnnn
  • Para obtener el ID de subred reemplazamos todas las posiciones de bits que corresponden al nodo por ceros (la dirección reservada de subred se caracteriza porque todas las posiciones de los bits de nodo están en cero).
    65.11001100.01000000.00000000
  • Convertimos ahora los octetos 2, 3 y 4 a nomenclatura decimal:
    65.204.64.0
Respuesta entonces. La subred 817 es la subred 65.204.64.0/18

¿Qué direcciones IP quedan dentro de esta subred?
Ahora que tenemos identificada nuestra subred, lo que nos queda es un cálculo de subredes tradicional.
  • La máscara de subred nos indica que utilizamos 6 bits del tercer octeto, y 8 del cuarto para el ID de nodo.
  • La dirección reservada de subred, es la que tiene estos últimos 14 bits en cero:
    65.11001100.01
    000000.00000000
    65.204.64.0
  • La dirección reservada de broadcast, es la que tiene estos últimos 14 bits en uno:
    65.11001100.0
    1111111.11111111
    65.204.127.255
  • Consecuentemente, el rango de direcciones IP útiles, o direcciones de nodo es:
    65.204.64.1 a 65.204.127.254
Bien, espero que esto sirva de orientación para resolver este tipo de cálculos.
Pero no desesperen... se acerca IPv6, y con ella desaparecen las subredes. Claro, que tendremos algunas complejidades nuevas.
Por suerte, siempre hay algo nuevo que estudiar.

Otros artículos para consultar en el blog:
Bibliografía sugerida:
Cuadernillo: Subredes IPv4 - Oscar Gerometta
¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

5 de junio de 2010

¿Cómo accedo a los libros?

Frecuentemente recibo consultas referentes a los libros que he publicado o estoy preparando para su publicación. Por este motivo me pareció adecuado hacer un post sintetizando todo los referente a las publicaciones.
  • Ante todo.
    En este momento no hay publicaciones en formato electrónico (e-book o pdf). Editorial Libronauta que era con la que tenía firmado el contrato dejó de operar. Estoy en búsqueda de un nuevo sistema de publicaciones electrónicas, pero por el momento no hay nada definido. Cuando lo tenga, estará publicado aquí.
  • Por el momento entonces, el único formato disponible es impreso en papel.
    La impresión, distribución y comercialización de los libros está a cargo de
    Ediciones Edubooks.
    Para cualquier consulta al respecto, por favor, diríjanse a libros.networking@gmail.com Ellos son los que tienen toda la información respecto de costos, envío, costo del envío, etc.
  • Ediciones Edubooks cuenta ya con distribuidores locales en Bolivia y Chile. Para el resto del mundo, la distribución se hace directamente desde Argentina.
    La información de contacto en cada caso es:
    Ediciones Edubooks libros.networking@gmail.com

    En
    Bolivia
    libros.networking.bolivia@gmail.com

    En
    Chile
    libros@networkers.cl
Títulos publicados hasta el momento:
Introducciones:
  • Introducción a la conmutación Ethernet y el enrutamiento IP.
    Formato de bolsillo (20x14 cm.)
     Manual introductorio que desarrolla una primera aproximación a la temática de las redes Ethernet/IP y que considera elementos de configuración básicos.
    En todos los casos he utilizado configuración por interfaces gráficas, reservando el conocimiento de la línea de comando para los manuales más avanzados.
    Si requiere de información más detallada, procedimientos de configuración de nivel más avanzado o conocimiento de la línea de comando de Cisco IOS sugiero Principios Básicos de Networking para Redes Cisco IOS.
    Mayor información aquí.
  • Introducción a las redes Wireless LAN.
    Formato de bolsillo (20x14 cm.)
    Manual introductorio que desarrollan  una primera aproximación a las tecnologías WLAN (IEEE 802.11) y las configuración básica de access points.
    Presenta, siempre que resulta posible, la configuración por interfaces gráficas, reservando el conocimiento de la línea de comando para los manuales más avanzados. Las secciones de configuración están desarrolladas sobre la base del AP de los routers Linksys WRTG54G y los access point Cisco Aironet 1130 y sus interfaces gráficas.
    Este manual contempla una completa introducción a las tecnologías y estándares actualmente en uso, incluyendo los estándares IEEE 802.11a/b/g/n y 802.11i.
    Mayor información aquí.
Nivel CCNA:
  • Principios Básicos de Networking v.3.1
    Manual creado para responder a las necesidades de información de quienes trabajan en el área de infraestructura de redes de datos y voz, particularmente redes Cisco.
    Incluye, además de una descripción inicial de cada tecnología o protocolo, procedimientos, diagramas de flujo, tips y trips de configuración, capturas de comandos, etc.
    Sin ser una guía de estudio para el examen de certificación, cubre todos los objetivos del examen CCNA 640-801, y agrega muchos temas suplementarios.
    Mayor información aquí.
  • Apunte Rápido CCN v.4.0Síntesis de los contenidos de estudio comprendidos en el examen de certificación CCNA 640-802 (versión actual de esta certificación).
    Está concebido como un complemento de la Guía de Preparación para el Examen de Certificación CCNA, como una ayuda para el proceso de estudio de quienes se encuentran estudiando para presentar su examen de certificación.
    Está orientado al examen CCNA 640-802.

    Mayor información aquí.
  • Guía de Preparación para el Examen de Certificación CCNA v.4.0
    Manual de estudio pensado, diseñado y escrito para ayudar a los estudiantes a preparar su examen de certificación. Es un texto pensado específicamente para quienes desean preparar su examen de certificación CCNA 640-802 y buscan una herramienta de estudio, consulta y trabajo que les permita cubrir los objetivos de la certificación.
    Incluye recomendaciones prácticas, metodología de estudio, mapas conceptuales, desarrollo de cada tema, síntesis temáticas, cuestionarios y ejercicios de simulación.
    Sin dudas, esta Guía contiene todos lo necesario para preparar el examen de certificación. No es sólo un manual de estudio, es una guía diseñada y pensada de modo didáctico para orientar todo el proceso de preparación del candidato a rendir su certificación CCNA.
    Está específicamente orientada al examen CCNA 640-802.
    Mayor información aquí.
Nivel CCNP:
  • Enrutamiento BGP Básico.
    Manual introductorio que permite un aprendizaje gradual en la complejidad y características del protocolo de enrutamiento BGP en su implementación en redes empresariales.
    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.
    Mayor información aquí.
Muchas gracias a todos aquellos que con su aporte alientan y sostienen esta tarea.

    4 de abril de 2010

    Redistribución de rutas.


    Para que dos dispositivos (routers o switches capa 3) intercambien información de enrutamiento es preciso, en principio, que ambos dispositivos utilicen el mismo protocolo, sea RIP, EIGRP, OSPF, BGP, etc. Diferentes protocolos de enrutamiento, o protocolos configurados de diferente forma (p.e. diferente sistema autónomo en EIGRP) no intercambian información.
    Sin embargo, cuando un dispositivo aprende información de enrutamiento a partir de diferentes fuentes (p.e. rutas estáticas o a través de diferentes protocolos) Cisco IOS permite que la información aprendida por una fuente sea publicada hacia otros dispositivos utilizando un protocolo diferente. Por ejemplo, que una ruta aprendida a través de RIP sea publicada hacia otros dispositivos utilizando OSPF.
    Esto es lo que se denomina "Redistribución" de rutas. Utilizar un protocolo de enrutamiento para publicar rutas que son aprendidas a través de otro medio (otro protocolo, rutas estáticas o directamente conectadas).
    El mecanismo de redistribución es propietario de Cisco IOS. Este mecanismo establece algunas reglas:
    • La ruta a redistribuir debe estar presenta en la tabla de enrutamiento.
    • No se redistribuyen rutas que están presentes en tablas topológicas de los protocolos pero no en la tabla de enrutamiento.
    • La ruta redistribuida será recibida por el dispositivo vecino con la métrica raíz del protocolo en el que se redistribuye.
    ¿Para qué se utiliza?
    En principio es deseable que una red utilice un único protocolo de enrutamiento.
    Sin embargo, en algunos casos puede requerirse el uso de redistribución: fusiones de empresas, diferentes departamentos de una misma empresa administrados por diferentes equipos de personal, entornos multi-vendor, migraciones, etc.
    Al momento de abordar una redistribución de rutas se deben tener presentes algunos aspectos particulares del enrutamiento: las diferentes métricas, las distancias administrativas de cada protocolo, las capacidades de enrutamiento classful y classless, y la topología de la red.


    Las métricas
    Cada protocolo de enrutamiento utiliza una métrica diferente. Esto hace que al redistribuir rutas se pierda la métrica original del protocolo y sea redefinida en los términos del nuevo protocolo. Por ejemplo, si se redistribuye una ruta OSPF con una métrica de 1642 en RIP, RIP le asignará una métrica en cantidad de saltos (entre 1 y 15).
    La métrica con la que un protocolo recibe las rutas aprendidas por otro, se denomina métrica raíz.
    Cada protocolo utiliza una métrica raíz por defecto:
    • RIP - métrica raíz por defecto: infinito.
    • EIGRP - métrica raíz por defecto: infinito.
    • OSPF - métrica raíz por defecto: 20.
    Esta mética raíz por defecto también puede ser modificada utilizando el comando default metric.


    Los comandos básicos
    Al configurar redistribución debemos indicar al protocolo qué información de enrutamiento redistribuir, y con qué métrica deseamos se redistribuyan esas rutas. Si no indicamos nada, las rutas son redistribuidas con la métrica por defecto.


    Router(config)#router rip
    Router(config-router)#network 129.100.0.0
    Router(config-router)#redistribute ospf 1 metric 2


    En este ejemplo indicamos a RIP que redistribuya la información de enrutamiento aprendida a través del proceso 1 de OSPF que se encuentra en la tabla de enrutamiento, con una métrica de 2 saltos.


    Redistribución en EIGRP
    Al redistribuir información de enrutamiento utilizando EIGRP, es preciso tener presente que la métrica por defecto es infinito. Por lo tanto, si no especificamos métrica, las rutas redistribuidas no aparecerán en la tabla de enrutamiento del dispositivo vecino.
    Por otra parte, al definir la métrica es preciso indicar: bandwidth, delay, reliability, load y MTU.
    Un ejemplo:


    Router(config)#router eigrp 100
    Router(config-router)#redistribute static
    Router(config-router)#redistribute rip
    Router(config-router)#default-metric 10000 100 255 1 1500


    Redistribución en OSPF
    La métrica por defecto que utiliza OSPF es de 20, por lo que no exige que especifiquemos una métrica para que la ruta sea aprendida por los dispositivos adyacentes. Sin embargo, cuando hay múltiples subredes de una misma red y se desea publicar rutas para cada subred, es preciso indicarlo pues de lo contrario OSPF sumarizará todas las subredes al límite de la clase y publicará una sola ruta.
    Un ejemplo:


    Router(config)#router ospf 1
    Router(config-router)#redistribute static metric 200 subnets
    Router(config-router)#redistribute eigrp 100 metric 500 subnets


    Redistribución en RIP
    Como en EIGRP, al redistribuir en RIP el protocolo utiliza una métrica por defecto de infinito, con lo que es necesario especificar una métrica diferente para que el router vecino incorpore la información de enrutamiento en su tabla.
    Un ejemplo:


    Router(config)#router rip
    Router(config-router)#redistribute static metric 1
    Router(config-router)#redistribute ospf 1 metric 2


    Enlaces de referencia:


    Espero que el post te haya resultado útil.
    ¿Tenés alguna información o referencia adicional para aportar en este tema....?
    Perfecto!!!! agregá un comentario con el detalle.
    Muchas gracias.

    Oscar Gerometta.