Ago 01 2010

CONTRA LA AUTOCONFIGURACIÓN (parte 2)

El uso de procesos automático de autoconfiguración como soporte y ayuda a las tareas diarias es muy importante hoy en día en muchas labores, siempre y cuando se haga con los debidos controles y vigilancias en los procesos y resultados.

En ingeniería de telecomunicaciones existen muchas rutinas, normas y protocolos apoyados en estándares industriales o en algoritmos propietarios que ayudan en los procesos de mantenimiento y funcionamiento de redes de datos, pero que su uso debería estar reevaluado o restringido según criterios de diseño estrictos para cada caso puntual del cliente, y no ser usados o implementados como norma general.

Es el caso de los Protocolos de enrutamiento de Nivel 3 en el modelo OSI como los que se encargan de escoger “la mejor ruta” para llegar a la red destino de un paquete IP específico.

La aplicación de ciertos protocolos de enrutamiento en nuestro medio entorno Colombiano y en muchos países del área latinoamericana debería estar muy detalladamente evaluado porque los ingenieros de telecomunicaciones que se encargan de configurar los equipos tienden a estudiar y a prepararse con material de clases con ejemplos académicos muy americanos en donde existen múltiples conexiones y múltiples backbones corriendo entre múltiples sedes. Algo que generalmente no es nuestro caso ya que en nuestros países lo más común es que la sede principal de la compañía esté ubicada en la capital del país, y esta tenga conexiones sencillas hacia las ciudades importantes, pero entre las ciudades difícilmente se dan conexiones y tráfico de mediano nivel.

El ingeniero novel que llega a sugerir equipos y a hacer configuraciones de “puesta en marcha” de redes, empieza con la idea de poner a operar el mejor protocolo de enrutamiento que tenga el fabricante del hardware en ese momento.

Para ingeniero que va a instalar equipos de marca CISCO es casi que obligatorio encender y dejar operando el protocolo EIGRP. Si el equipo es de otra marca se opta de forma automática por encender el protocolo OSPF o BGP.

En el siguiente dibujo vemos la típica conexión de oficina remota con un router de pequeña a mediana capacidad, destinada a atender a lo sumo de 10 a 15 hosts contado todo lo que use dirección IP en esa zona u oficina. (click para agrandar)

Este es el típico ejemplo de pequeña y mediana empresa en donde, antes que ser solución, la implementación de un protocolo de enrutamiento cualquiera pasa a perjudicar el desempeño promedio de los routers.

EIGRP es un protocolo Distance vector que se apoya en varios parámetros para calcular la ruta óptima del origen al destino del paquete y en últimas decide por cual puerto se debe enviar un paquete IP para llegar en la mejor forma a su destino. El cálculo compuesto de ruta sale de una ecuación similar a la de su antecesor IGRP que toma como parámetros el ancho de banda, el retardo, la carga del enlace y su disponibilidad. Este tipo de protocolos permiten la configuración de parámetros como cada cuanto se debe actualizar y prioridades específicas para hacer sintonía fina de sus tablas, y se recalcula con cada cambio dependiendo de la frecuencia de los paquetes de actualización que recibe.

Otro protocolo de enrutamiento comúnmente usado es OSPF (Open Shortest Path First) que funciona según el conocido algoritmo de Dijkstra para calcular por cual puerto debe salir el paquete a la red IP destino. El pseudocódigo para el cálculo del algoritmo Dijkstra, tomado de Wikipedia, es el siguiente:

  • function Dijkstra(Graph, source):
    • for each vertex v in Graph:
      • dist[v] := infinity ;
      • previous[v] := undefined ;
    • end for ;
    • dist[source] := 0 ;
    • Q := the set of all nodes in Graph ;
    • while Q is not empty:
      • u := vertex in Q with smallest dist[] ;
      • if dist[u] = infinity:
        • break ;
      • fi ;
      • remove u from Q ;
      • for each neighbor v of u:
        • alt := dist[u] + dist_between(u, v) ;
        • if alt < dist[v]:
          • dist[v] := alt ;
          • previous[v] := u ;
        • fi  ;
      • end for ;
    • end while ;
    • return dist[] ;
  • end Dijkstra.

En una red típica de mediana empresa es mucho menos lo que aportan este tipo de protocolos ya que como se puede ver fácilmente llevan a un desgaste extra en desempeño del router de borde que no es necesario y se puede resolver con una simple ruta estática.

Es muy importante reconocer la importancia de que los protocolos de enrutamiento no lleven el horizonte de la red a “infinito” y por tanto los datagramas circulen continuamente haciendo la red más lenta.

Los protocolos anteriormente mencionados son usualmente encendidos por parte del instalador de la red, sin evaluar si realmente se necesitan en estructuras como la del dibujo anteriormente expuesto en este artículo, y sin revisar si es mejor el implementar tablas de enrutamiento estático.

Muchas oficinas remotas solo tienen un canal de conexión a la oficina, y si mucho, tienen contingencia on demand para el caso de pérdida del enlace principal. Pero no más. Si un router única y exclusivamente tiene un solo puerto WAN y una única ruta posible para llegar a absolutamente todos los destinos, pregunto: ¿Qué sentido tiene encender un protocolo de enrutamiento? Cualquiera que sea el protocolo escogido, bastaría con una simple ruta estática que le diga cómo debe llegar (O para el caso, por que puerto) a las oficinas principales. Esto le va a ahorrar en desempeño bastante al router de oficina ya que por cada paquete IP no se tiene que poner a calcular rutas.

Se puede complicar un poco más el escenario expuesto en el dibujo anterior y pensar en una oficina remota con varias subredes IP que se deben “anunciar” en la oficina principal como es el moderno caso del uso de VLANs de oficina.

Evitando la usual tentación de encender el protocolo de enrutamiento de moda, para este caso puntual bastaría con un clásico diseño de “sumarización de rutas” e igualmente el resultado seria, y por mucho, mejor que encender cualquier protocolo en el router de borde.

Según Andrew S. Tanembaum en su magnífico libro de “Redes de computadoras” El proceso de switching o conmutación de paquetes es aquel que se encarga de mover el paquete de un puerto a otro, mientras que el proceso de enrutamiento (encaminamiento en la poco querida traducción del libro al español) es el proceso que se encarga de decidir por cual puerto debe salir el paquete.

Un router debe hacer estas dos tareas por cada paquete IP.

Si cuando estamos configurando e instalando el equipo, le podemos ahorrar algo de trabajo en la ejecución del algoritmo de enrutamiento y que se limite a la parte de conmutación, se está haciendo algo por mejorar el desempeño global de la red.

Yo puedo justificar la necesidad y la casi obligatoriedad del uso de los protocolos de enrutamiento en la frontera inter redes donde grandes números de rutas se deben anunciar a otras redes, pero el uso de protocolos de enrutamiento al interior de redes empresariales confinadas debería estar reevaluado a situaciones puntuales y específicas. No siempre es necesario y las tablas de rutas estáticas permiten un mejor control y conocimiento sobre el tránsito de paquetes IP en nuestra propia WAN.

Be Sociable, Share!

Enlace permanente a este artículo: http://www.leonelpedroza.com/2010/08/01/contra-la-autoconfiguracion-parte-2/

Deja un comentario