Conceptos previos

per Victor Carceler — darrera modificació 2020-04-06T12:06:37+01:00

En una red de paquetes es necesario encaminar la información a través de una ruta que conecte el emisor con el receptor. Cuando la red cambia, porque aparecen/desaparecen nodos y/o enlaces entre ellos, deben actualizarse dichas rutas. Normalmente se utilizan protocolos de encaminamiento dinámico que actualizan las tablas de rutas en los encaminadores, así no es necesario actuar sobre los encaminadores de manera manual. Los protocolos de encaminamiento dinámico como RIP u OSPF trabajan en un sistema autónomo, que es un conjunto de máquinas con una administración coherente. A estos protocolos se los conoce como de encaminamiento interno (IGP Interior Gateway Protocol). Los protocolos (como BGP) que se utilizan para intercambiar información de encaminamiento entre sistemas autónomos son sistemas de encaminamiento externo (EGP Exterior Gateway Protocol).

RIP es un protocolo que utiliza un algoritmo vector distancia para calcular la ruta más corta a partir de la métrica de cada enlace. OSPF utiliza un algoritmo que tiene en cuenta el estado de los enlaces para determinar la ruta a utilizar.

RIP es muy sencillo de implementar y configurar pero tiene ciertas limitaciones. Por ejemplo, cuando la red es grande, las difusiones de las tablas de rutas pueden generar un volumen de tráfico considerable. Por esta razón no es apto para redes con un gran número de encaminadores. OSPF es un protocolo que permite trabajar con un gran número de encaminadores sin saturar la red y además se adapta con rapidez a los cambios en la red.

En GNU/Linux es posible utilizar Zebra o Quagga para ejecutar entre otros RIP u OSPF.

Sobre OSPF

Algunas caracterísiticas de OSPF (Open Shortest Path First) son:

Es un protocolo de encaminamiento dinámico IGP (Interior Gateway Protocol)
Calcula la ruta a partir de un algoritmo enlace estado (Dijikstra LSA)
Utiliza un esquema de seguridad basado en MD5 para autentificar a los nodos antes de confiar en sus mensajes
Un sistema autónomo funcionando con OSPF está formado por diferentes áreas, existe un área denominada backbone o área 0 que comunica a todas las demás.
Los encaminadores OSPF envian mensajes para descubrir a sus vecinos e intercambiar información. Los mensajes de control no utilizan TCP ni UDP para su transporte, utilizan directamente el protocolo IP.

Sobre Zebra/Quagga

Zebra/Quagga es un conjunto de demonios que implementan diferentes protocolos de encaminamiento (RIP, RIPng, OSPF, BGP, etc...). Se trata de un sistema modular en el que existe un demonio de control Zebra o Quagga según la versión, y un demonio para implementar cada uno de los protocolos de encaminamiento. De esta manera una máquina que ejecuta el demonio Quagga y ospfd podrá intercambiar información de encaminamiento con otros encaminadores que implementen OSPF. Las rutas aprendidas pasan a modificar la tabla de rutas del núcleo, de la misma manera las rutas que el núcleo conoce son divulgadas a través de OSPF a otros encaminadores.

La tabla de rutas del núcleo va a determinar la decisión de encaminamiento para los paquetes que genere la estación o los paquetes que deba retransmitir.

Ejemplo 1: Red local y puerta de enlace por defecto

vcarceler@meara:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.100.0   *               255.255.255.0   U     0      0        0 eth1
default         192.168.100.1   0.0.0.0         UG    0      0        0 eth1
vcarceler@meara:~$
vcarceler@meara:~$ ip route
192.168.100.0/24 dev eth1  proto kernel  scope link  src 192.168.100.103
default via 192.168.100.1 dev eth1
vcarceler@meara:~$

Es posible consultar la tabla de rutas del núcleo con el comando route o bien con ip route. En este caso el núcleo sólo sabe:

Que la interfaz eth1 tiene una IP de la red 192.168.100.0/24, de manera que cualquier paquete para esa red no necesita puerta de enlace, es suficiente con transmitirlo por eth1 para que alcance a su destino.
Que la puerta de enlace por defecto es 192.168.100.1, por lo tanto para cualquier paquete cuyo destino no sea 192.168.100.0/24 se debe utilizar 192.168.100.1 como puerta de enlace.

Evidentemente la puerta de enlace por defecto debe ser una máquina que se pueda alcanzar de algún modo, en este caso es una máquina de la red 192.168.100.0/24 por lo tanto es una máquina con la que nos podemos comunicar sin utilizar ningún encaminador.

Ejemplo 2: Rutas aprendidas

[vcarceler@localhost vcarceler]$ /sbin/route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.107.36   *               255.255.255.252 U     0      0        0 tap8
172.16.107.32   *               255.255.255.252 U     0      0        0 tap7
172.16.107.44   *               255.255.255.252 U     0      0        0 tap10
172.16.107.20   *               255.255.255.252 U     0      0        0 tap4
172.16.107.16   *               255.255.255.252 U     0      0        0 eth1
172.16.107.24   *               255.255.255.252 U     0      0        0 tap5
172.16.107.4    *               255.255.255.252 U     0      0        0 tap1
172.16.107.0    *               255.255.255.252 U     0      0        0 tap0
172.16.107.12   *               255.255.255.252 U     0      0        0 tun3
172.16.107.8    *               255.255.255.252 U     0      0        0 tap2
10.35.144.0     *               255.255.255.224 U     0      0        0 eth1
10.35.144.96    172.16.107.5    255.255.255.224 UG    20     0        0 tap1
10.35.145.128   172.16.107.45   255.255.255.224 UG    20     0        0 tap10
10.34.248.0     *               255.255.255.224 U     0      0        0 eth1
10.35.145.64    172.16.107.37   255.255.255.224 UG    20     0        0 tap8
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         moria.tierramed 0.0.0.0         UG    0      0        0 eth0
[vcarceler@localhost vcarceler]$ /sbin/ip route
172.16.107.36/30 dev tap8  proto kernel  scope link  src 172.16.107.38
172.16.107.32/30 dev tap7  proto kernel  scope link  src 172.16.107.34
172.16.107.44/30 dev tap10  proto kernel  scope link  src 172.16.107.46
172.16.107.20/30 dev tap4  proto kernel  scope link  src 172.16.107.22
172.16.107.16/30 dev eth1  proto kernel  scope link  src 172.16.107.18
172.16.107.24/30 dev tap5  proto kernel  scope link  src 172.16.107.26
172.16.107.4/30 dev tap1  proto kernel  scope link  src 172.16.107.6
172.16.107.0/30 dev tap0  proto kernel  scope link  src 172.16.107.2
172.16.107.12/30 dev tun3  proto kernel  scope link  src 172.16.107.14
172.16.107.8/30 dev tap2  proto kernel  scope link  src 172.16.107.10
10.35.144.0/27 dev eth1  proto kernel  scope link  src 10.35.144.1
10.35.144.96/27 via 172.16.107.5 dev tap1  proto zebra  metric 20
10.35.145.128/27 via 172.16.107.45 dev tap10  proto zebra  metric 20
10.34.248.0/27 dev eth1  scope link
10.35.145.64/27 via 172.16.107.37 dev tap8  proto zebra  metric 20
192.168.0.0/24 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via 192.168.0.1 dev eth0  proto zebra
[vcarceler@localhost vcarceler]$

En este ejemplo, la estación tiene diferentes interfaces de red (eth0, tapX...) que le permiten entregar de forma local paquetes a diferentes destinos, y conoce la existencia de diferentes redes (10.35.144.96/27, 10.35.144.128/27 y 10.35.145.64/27) para las que debe utilizar determinada puerta de enlace (172.16.107.5, 172.16.107.45 y 172.16.107.37 respectivamente).

Para encaminar cualquier paquete que no coincida con uno de los destinos anteriormente listados se utilizará la puerta de enlace por defecto 192.168.0.1.

Retransmisión de paquetes

Un equipo que va a actuar como pasarela (puerta de enlace) para otros, no sólo debe utilizar su tabla de rutas para decidir el próximo salto de sus paquetes si no también para retransmitir los paquetes que otros le entregan. El núcleo Linux cuenta con un parámetro booleano que controla la retransmisión de los paquetes de otras estaciones. Se puede explorar el estado de dicho parámetro a través de la interfaz que proporciona el sistema de ficheros /proc.

En los siguientes ejemplos:

vcarceler@meara:~$ cat /proc/sys/net/ipv4/ip_forward
0
vcarceler@meara:~$

[vcarceler@localhost vcarceler]$ cat /proc/sys/net/ipv4/ip_forward
1
[vcarceler@localhost vcarceler]$

La primera estación no actuará como puerta de enlace para nadie, la segunda sí que lo hará.

Es posible cambiar el valor de este parámetro escribiendo en dicho fichero (si se es administrador)

root@meara:~# cat /proc/sys/net/ipv4/ip_forward
0
root@meara:~# echo 1 >/proc/sys/net/ipv4/ip_forward
root@meara:~# cat /proc/sys/net/ipv4/ip_forward
1
root@meara:~#

O bien definir en el fichero de configuración /etc/sysctl.conf el valor adecuado para este parámetro tras el arranque del sistema.

Ejemplo de uso de Quagga y OSPFd en la XEiLL

Es posible encontrar un ejemplo de uso de Quagga y ospfd en la XEiLL en el siguiente documento: http://iespuigcastellar.xeill.net/Members/vcarceler/misc/xeill/prototipo-para-la-instalacion-de-un-centro/quagga/index_html