Mostrando entradas con la etiqueta Conceptos. Mostrar todas las entradas
Mostrando entradas con la etiqueta Conceptos. Mostrar todas las entradas

lunes, 28 de diciembre de 2009

Introducción al Multicast (Parte I)

Actualmente y debido a la nueva ola del video sobre IP algunas tecnologías se ponen de moda, incluso aquellas que siempre fueron conocidas por su nombre y se mencionan habitualmente sin que la mayoría de los involucrados tenga una idea más o menos clara de los conceptos fundamentales.

Puntualmente estoy hablando del afamado multicast, y la idea es que mediante un escueto post podamos explicar algunos de esos conceptos fundamentales que nos aclaren un poco el panorama.

Lamentablemente, la mejor manera que conozco para definir este concepto es mostrando primero que cosa no es, dado que ejemplificando se logra comprender rápidamente lo básico.

Conocemos la forma del paquete IP tradicional, en donde algunos de los campos más relevantes en los encabezados son la source address (dirección del dispositivo originante del paquete) y la destination address (dirección del destinatario del paquete). Ambos son de 32 bits y deben estar correctamente dispuestos para que se realice correctamente la entrega de los datos.


Ahora bien, seguramente conocemos a las dos formas estrella de la entrega de paquetes:

Unicast:

Un equipo quiere transmitir uno o varios paquetes a un único destino, por lo que completa los campos del encabezado de capa 3 con su dirección IP en el source address y la dirección IP del destinatario en el destination address. Con esto se logra una comunicación entre dos equipos en forma de un stream de datos en un solo sentido.
El ejemplo más claro de esto es cuando usamos el correo postal, en donde tenemos un único remitente y un único destinatario de la carta en cuestión.
Cuando el destinatario me quiera responder, utilizará otro sobre y cambiará las direcciones de remitente y destinatario de manera acorde para que el nuevo mensaje pueda volver al origen, creando finalmente la comunicación de dos vías.



Broadcast:


Demasiado hablamos en la academia de networking sobre este tema... el broadcast es una comunicación desde uno a todos, en donde los encabezados del paquete IP son completados con una serie de unos binarios en la parte de host (donde la máscara de red es 0 en formato binario) y los dispositivos intermediarios comprenden que deben reenviar dicho paquete a todos los puertos activos dentro del dominio de broadcast al que pertenece el remitente.

Esto tiene como contrapartida la necesidad de que todos los hosts que reciben el mensaje deban procesarlo debido a que en la dirección de destino no existe un único destinatario, sino una suerte de código que se interpreta como "A quien corresponda".
Un ejemplo de lo cotidiano sería una persona que quiere hacer publicidad y va por la calle arrojando panfletos que anuncian su negocio. Sus empleados van dejando copias en cada puerta de cada casa, y cualquier persona que ve un papel puede llegar a entender que es el destino del mensaje, por lo que deberá desdoblarlo, leerlo e interpretarlo y posiblemente eliminarlo al ver que es propaganda o bien interesarse por el aviso y llamar para pedir el producto o el servicio en cuestión.
Más allá de cualquiera de estos casos, debemos tener en cuenta que muchos papeles desperdigados en la calle o en las casas es basura, y aunque finalmente existan algunos interesados en recibir dicha información, generalmente muchos otros integrantes de la ciudad (el dominio de broadcast) tuvieron que perder tiempo agachándose a juntar el papel, leyéndolo, entendiéndolo y descartándolo.

Por esto queda claro que mientras menos broadcast exista en la red, mejor va a ser la performance, y cuando hablo de dominios de broadcast me refiero a la ciudad en el ejemplo real (a nadie le va a interesar una propaganda de un servicio que se ofrece solo en otra ciudad) y de los routers en el ejemplo de networking (los routers no transmiten broadcast entre sus interfases).



Ahora bien, ¿qué es multicast?...

Multicast:


Como se imaginarán, Multicast es una mezcla de los dos ejemplos anteriores, en donde un mensaje se transmite entre un origen y un grupo de destinos que activamente solicitaron recibir dicha información.

En su ejemplo más básico, un equipo que forma parte de una subred de n equipos en total quiere transmitir cierta información a un grupo de m equipos (m =< n-1) que utilizan un protocolo llamado IGMP para avisar a los equipos intermediarios que quieren unirse a ese grupo de escucha para recibir dicha información.

En un ejemplo muy malo se podría decir que ese grupo de m equipos se ponen la misma dirección IP (una dirección IP especial de clase D, llamada IP de grupo) y entonces logran recibir los datos destinados a esa dirección.

La ventaja de esto es que el host de origen envía una única copia de la información y son los dispositivos intermedios (routers, switches, etc) los que se encargan de copiar esos paquetes a todos los puertos en el camino de los dispositivos que enviaron mensajes de IGMP.

Con esto se logra que el emisor no deba mantener una conversación de dos vías con cada receptor, y se logra efectivamente una comunicación de tipo uno a muchos e incluso que podría ser de muchos a muchos donde (como siempre aclaramos) muchos pueden no ser todos.


En el próximo post vamos a ver como se logra este cometido más a fondo.

Saludos!

lunes, 9 de marzo de 2009

Conceptos de EIGRP Parte I.

Mucho hemos hablado últimamente del tema del famoso EIGRP y sus bondades.

En diversos materiales de Cisco he leído que EIGRP es el protocolo de enrutamiento que más rapido converge, a la vez de que posee muchas variables para establecer el cálculo de la métrica a cada destino y que no consume tanta memoria ni recursos de CPU como los algoritmos de estado enlace. Sumado a esto proporciona balanceo de carga en enlaces desiguales, por lo que resulta una opción más que interesante para evaluar al momento de elegir un protocolo de enrutamiento para nuestra red.

Vamos a ver algunos detalles de los puntos que mencionamos anteriormente:

Antes que nada es necesario aclarar que nos encontramos ante un protocolo que está patentado por Cisco Systems, por lo que sólo podrá ser usado si es que tenemos una red en donde poseemos equipos de esa marca en los puntos donde debe haber enrutamiento. Para los que no tengan todos los equipos de la marca o bien vengan con una línea de pensamiento de estandarización y tecnologías abiertas, mejor vayan por alguno de los otros protocolos.

Una vez aclarado esto, podemos decir que no se sabe a ciencia cierta como está desarrollado el protocolo, aunque se sabe que toda la magia está centrada en su núcleo  DUAL (Diffusing Update ALgorithm), que se encarga de calcular las mejores rutas libres de loops hacia cada destino en particular.
Hay un paper que describe brevemente el algoritmo y puede ser visto aquí.

EIGRP es catalogado en la mayoría de los libros como un protocolo de vector distancia mejorado  y en otros como un híbrido. La cantidad de saltos que se debe atravesar se encuentra presente en la información de cada ruta, pero este dato no interviene en el cálculo de la métrica.
Tengamos en cuenta que el límite de saltos para una ruta que se aprende por EIGRP es 224, y 255 para su antecesor: el viejo IGRP.

El dato anterior no es un detalle menor (dado que casi nadie publica esta información) pero a estas si tenemos un destino que está detrás de más de 224 saltos estamos teniendo un problema grave o bien estamos haciendo todo mal, por lo que estas distancias máximas permitidas por el protocolo son por demás de aceptables.

Otras bondades del protocolo son:
  • Dado que envía la máscara de red en las actualizaciones, soporta VLSM.
  • Soporta el envío de actualizaciones parciales hacia los vecinos.
  • Soporta varios protocolos de capa tres mediante la inclusión de los módulos PDM (Protocol Dependent Modules).
  • Tiene su propio protocolo de transporte de información, llamado RTP (Reliable Transport Protocol).
  • Detecta a sus vecinos intercambiando mensajes de saludos al igual que los protocolos de estado enlace.
  • Es relativamente fácil de configurar.
  • Puede definirse administrativamente la cantidad de ancho de banda que se utilizará en las actualizaciones.
  • Detecta automáticamente las redes NBMA (multiacceso sin broadcast) tales como las topologías de frame-relay multipunto.


    • Estas topologías son un dolor de cabeza a la hora de configurar los otros protocolos.



  • Sus métricas son de 32 bits, por lo que ofrece una gran granularidad.

Tiene diversos componentes para evaluar la métrica, y estos pueden ser activados según las necesidades del administrador:
  • Ancho de banda.
  • Retraso.
  • Confiabilidad.
  • Carga del enlace.
  • MTU(*).

El cálculo de la métrica se define según la siguiente ecuación:




No me voy a detener en este post a explicar cada una de estos puntos, sino que voy a hablar puntualmente de por qué el protocolo converge más rápido que el resto:

Supongamos que tenemos esta topología:




Tengamos en cuenta que los costos del camino están simplificados a fin de que se entienda mejor la explicación.

Nuestra PC está conectada al Router Oeste, que posee tres enlaces hacia el Router Este que contiene la red de destino, 192.168.90.0/24.

Debido a que los tres enlaces son de diferentes ISP, los anchos de banda y el delay (variables K1 y K3 habilitadas por defecto) de cada uno nos generan una distinta métrica.

Analicemos ahora las distancias para llegar hacia la red 192.168.90.0/24:
  • 30 (20+10) para llegar mediante el router Norte.
  • 20 (10+10) para llegar mediante el router Centro.
  • 275 (20+255) para llegar mediante el router Sur.

Es evidente que el mejor camino es pasando por el router Centro, por lo que esa es la ruta que EIGRP instalará en nuestra tabla de enrutamiento.
A esta ruta la llamaremos Ruta Sucesora.

Observemos también que las otras dos rutas son válidas, dado que  representan caminos sin bucles (loops).

Para esto, vamos a seguir definiendo términos:

El Router Oeste cuenta con datos como una Distancia Factible (Feasible Distance, FD) que es la distancia calculada por Oeste hasta la red remota, que en este caso es de 20 pasando por Router Centro que a su vez,  le "reporta" al Router Oeste que su distancia hacia la red remota (la distancia desde el Router Centro) es de 10.

A esta distancia se la llama Distancia Reportada (Reported Distance, RD).

O sea que el Router Oeste cuenta con los siguientes datos para calcular la FD hacia la red 192.168.90.0/24:
Tengo una distancia de 20 hacia Router Norte, el me reporta una distancia de 10 hacia la red 192.168.90.0/24, por lo que la distancia factible (FD) a través de el es 30.

Tengo una distancia de 10 hacia Router Centro, el me reporta una distancia de 10 hacia la red 192.168.90.0/24, por lo que la distancia factible (FD) a través de el es 20.

Tengo una distancia de 20 hacia Router Sur, el me reporta una distancia de 255 hacia la red 192.168.90.0/24, por lo que la distancia factible (FD) a través de el es 275.

Instalaré en la tabla de enrutamiento una entrada calculada mediante DUAL pasando por Router Centro para llegar a la red 192.168.90.0/24.

EIGRP va a guardar los otros caminos en su tabla de topología, y prestará extrema atención a aquellos que cumplan con la llamada Condición de Factibilidad que define lo siguiente:
Serán rutas de backup o alternas llamadas Sucesoras Factibles (Feasible Successors) las rutas que tengan una distancia reportada (RD) menor que la distancia factible (FD).

Por esto, si analizamos el diagrama según el punto de vista del Router Oeste:
  • La ruta a través de Centro es la sucesora, por lo que no la analizamos.
  • La ruta a través de Norte tiene una RD de 10, que es menor que mi FD hacia la red 192.168.90.0/24. Esta ruta cumple la condición de factibilidad. La instalo como sucesora factible en mi tabla de topología.
  • La ruta a través de Sur tiene una Distancia Reportada (RD) de 255, que es mayor que la distancia factible (FD) igual a 20. Esta ruta no cumple la condición de factibilidad, por lo que no la considero como backup.





En caso de que se caiga el enlace entre Router Oeste y Router Centro, la ruta sucesora factible será automáticamente promovida a Sucesora, sin tener que recalcular nada.
Esto es lo que hace extremádamente rápido al protocolo en términos de velocidad de convergencia.




En caso de que la nueva sucesora falle, Router Oeste no va a tener otra ruta backup, por lo que va a mandar consultas acerca de 192.168.90.0/24 a todos los vecinos que estén disponibles.

En este momento, EIGRP va a calcular activamente cómo llegar a la red destino, por lo que las rutas que sean inalcanzables aparecerán como A (Ruta Activa).




Acto seguido realizará un Query (consulta) a sus vecinos activos para ver si alguno de ellos tiene una ruta sin bucles hasta la red de destino.




El router Sur va a responder diciendo que conoce una ruta para llegar a la red en cuestión y se lo informa a Oeste.




Ahora el único camino hacia la red remota es vía el Router Sur, por lo que se transforma en sucesor.




Esto es parte de lo que debería saber cualquier CCNA. En la siguiente entrega veremos como realizar el bendito balanceo de carga con enlaces desiguales.

Salud!