Sumarización: rutas resumen y enrutamiento*

Spread the love

Ya antes me pareció constructivo describir la diferencia entre VLSM, sumarización y CIDR, sin embargo, eso en palabras es un poco difícil de observar, así que en esta entrada voy a describir un poco la relación y voy a hacer algunos ejemplos de uso que aclaran más aún las similitudes y diferencias entre estos importantes conceptos de enrutamiento. Disfrútenlo.


Primero, hay que hablar un poco sobre éstos tres conceptos que siempre están relacionados aunque uno no implique al otro. Vlsm es una técnica de diseño de esquemas de direccionamiento que ya he descrito bastante, consiste en definir subredes sin considerar los límites de clase A, B o C tradicionales, de tal manera que se optimiza el espacio de direcciones (caben más dispositivos por subred), por otro lado, la sumarización o creación de resumenes consiste en configurar en los enrutadores rutas especiales que representan varias subredes que están en otro enrutador, es como aplicar vlsm para crear una red virtual (superred) que representa a varias redes «reales». Finalmente, CIDR es el mecanismo por medio del cual los protocolos de enrutamiento pueden transportar información de subredes que usan vlsm y resúmenes. Como mencioné en el primer párrafo, una cosa no implica la otra, sin embargo CIDR es un concepto general que, use o no a los otros dos, los asume como si lo fueran, es decir es el más general de todos. Por otro lado, aplicar vlsm no implica ni resúmenes ni CIDR y eso es lo que vamos a mirar ahora. Primero hagamos un esquema de direccionamiento usando vlsm y veamos cómo funciona sin usar resumenes ni CIDR. Si yo tengo la red 192.168.0.0/24 y tengo que crear subredes para 3 redes de 20 hosts c/u, 3 de 2 hosts c/u y una de 50 hosts, tengo obligatoriamente que usar vlsm y el esquema resultante podría ser el siguiente:

  • 50 hosts: 192.168.0.0/26 con broadcast 192.168.0.63
  • 20 hosts: 192.168.0.64/27 con broadcast 192.168.0.95
  • 20 hosts: 192.168.0.96/27 con broadcast 192.168.0.127
  • 20 hosts: 192.168.0.128/27 con broadcast 192.168.0.159
  • 2 hosts: 192.168.0.160/30 con broadcast 192.168.0.163
  • 2 hosts: 192.168.0.164/30 con broadcast 192.168.0.167
  • 2 hosts: 192.168.0.168/30 con broadcast 192.168.0.171

Éste es un esquema de direccionamiento de máscara variable porque como se ve las máscaras no respetan los límites de clase y son diferentes según la capacidad de hosts que albergará cada subred. Ahí aplicamos vlsm, sin embargo podríamos poner a funcionar ésta red usando rutas estáticas o RIPv1, en ninguno de los dos casos se usaría CIDR (no hay transporte de máscaras en las actualizaciones de enrutamiento). La sumarización puede suceder en cualquiera de los dos casos, pero sólo si nosotros lo permitimos.  En el caso de las rutas estáticas, habría que calcular si es posible hacer resúmenes y dónde se podrían configurar, en el caso de RIPv1 se haría resumen automático de clase donde se envíen actualizaciones con dirección de clase distinta a la usada. No vamos a usar ninguno para ilustrar que una cosa no implica a la otra (directamente). A continuación, les muestro la topología de ejemplo y la configuración necesaria.
[IMAGEN y CONFIGURACIÓN]

Ahora, vamos a ver cómo sería usando CIDR. Ésta tecnología se basa en una cosa: transportar la máscara en las actualizaciones. Si una actualización de rutas llega a un enrutador y no contiene la máscara, sólo puede usar la clase para suponer qué máscara se usa, por lo tanto cuando se envía la máscara las operaciones de comparación, actualización de la tabla de enrutamiento, etc. son mucho más precisas.

Con sólo cambiar el enrutamiento a RIPv2 tenemos CIDR. Aunque en ésta topología tan simple no hay mayor impacto, el que tuvo en Internet fue muy grande en su momento. Para nosotros tendría más sentido si podemos crear una ruta resumen y ver que CIDR puede transportar incluso las rutas de resumen.

Agreguemos una nueva red y reasignemos las subredes existentes. Ahora tenemos un conjunto de subredes que pertenecen al mismo enrutador y que se pueden resumir en un sólo prefijo que las representen a todas. Ahora el protocolo debe transportar esa información en vez de la información específica. La gracia es que para los otros enrutadores no es necesario saber toda la información para hacer que su tráfico se dirija a ellas.

* Infortunadamente ésta es una entrada que tenía en el tintero y se me fue sin revisar, hasta acá la escritura está bien, falta terminarla. Estén pendientes, en los próximos días les publico el resto.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.