Si hay un protocolo de enrutamiento que gobierna el Internet global de hoy, este es BGP. Pero en otro tiempo, hubo un backbone central llamado NSFNET que evolucionó hacia el Internet descentralizado actual. BGP hizo posible este cambio. Hoy día, organizaciones medianas y grandes lo utilizan. Veamos los fundamentos de su funcionamiento y una implementación básica con GNU/linux...

Introducción

Las necesidades de routing de una organización, dependen en gran medida de su tamaño. De esta manera se pueden clasificar las organizaciones a efectos de routing en las siguientes categorías:
SOHO (Small Office/Home Office)
Enterprise (empresa)
Service Provider (ISP = Proveedor de servicios de interconexión)

Esta clasificación, no me la he inventado yo, sino Cisco, probablemente el mayor fabricante mundial de routers y equipamiento para networking. Obviamente, los routers que necesita un proveedor de servicios de internet como Telefónica, requieren unas prestaciones que son muy superiores a las que un consumidor final necesita en su casa para conectar su portátil a internet. Por supuesto, esta diferencia se refleja en el precio: unos pocos euros para un routercillo casero, pero decenas de miles de euros para una máquina de gran capacidad.

¿Qué papel juega GNU/linux en este mercado? GNU/linux no es una solución válida para manejar grandes volúmenes de tráfico TCP/IP, como las que necesita un ISP ó una gran empresa. Este tipo de organizaciones necesita de hardware muy especializado con una enorme capacidad de conmutación (Terabits por segundo) con sistemas operativos en tiempo real como el Cisco IOS optimizado para correr en tales plataformas. Sin embargo, una máquina GNU/linux con la configuración adecuada y corriendo sobre un hardware adecuado, puede proporcionar unas prestaciones de routing suficientes para cubrir las necesidades de negocios e incluso empresas medianas... y lo que es más interesante a un coste reducido. Es decir, una máquina GNU/linux puede convertirse en un router de prestaciones medias.

Justificación al uso de BGP

El aspecto más básico en el manejo del enrutamiento IP en una máquina GNU/linux, viene dado por  el paquete para GNU/linux net-tools ó el más moderno iproute. En estos paquetes podemos encontrar comandos de red para insertar rutas estáticamente en la tabla de enrutamiento, ó examinarlas. Pero a medida que la red crece, el esquema de enrutamiento estático configurado de forma manual, puede convertirse en una fuente de errores y trabajo extra. Para evitarlo, se usan los protocolos de enrutamiento: RIP para redes pequeñas y OSPF para redes grandes. Gracias a estos protocolos de enrutamiento, las rutas dentro de nuestra red se actualizarán dinámicamente y nos ahorraremos disgustos. RIP y OSPF son protocolos de enrutamiento interior (IGP), porque manejan el enrutamiento dentro de nuestro sistema autónomo (AS). En el RFC 1771 (A Border Gateway Protocol 4 (BGP-4). Y. Rekhter & T. Li. March 1995) se define sistema autónomo (AS) como un conjunto de routers que están bajo una administración técnica única. El concepto de sistema autónomo juega un papel fundamental en lo que a BGP se refiere.
¿Pero qué sucede cuando el tráfico necesita salir fuera de nuestro AS hacia internet, por ejemplo? La solución más habitual y más que suficiente en la mayoría de las ocasiones, es disponer de un router conectado a internet a través de un proveedor de servicios de internet (ISP). En este router se configura una ruta por defecto hacia el ISP. Esta ruta por defecto se difundirá al resto de routers de nuestra red mediante el protocolo de red interno que hayamos elegido (RIP ó OSPF) y asunto arreglado.

Cuando usar BGP

Sin embargo, hay casos especiales en los que la ruta por defecto no es la mejor solución. ¿Qué casos son esos? Supongamos que, debido a las necesidades de su negocio, no puede usted permitirse ningún corte en su servicio de acceso a internet. Para obtener redundancia en su acceso, usted puede contratar la interconexión de su red a internet con dos operadoras diferentes. Surgen diferentes posibilidades de configuración. Supongamos, por ejemplo, que le interesa balancear la carga de tráfico entre ambos enlaces, pero si se cae uno de ellos, quiere que el enlace que queda en pie asuma la carga de ambos. ¿Como se hace esto? Una posibilidad es utilizar un protocolo de enrutamiento exterior (EGP) como por ejemplo BGP, que enrute nuestros paquetes hacia otros sistemas autónomos, típicamente un ISP.
Supongamos ahora el siguiente escenario alternativo. Dispone de dos enlaces de distintas características (uno mejor que otro), y quiere reservar el enlace 'VIP' para sus mejores clientes y que el resto, vayan por el enlace 'normal'. ¿Cómo hacer que el tráfico descargado de internet hacia los clientes VIP vaya por el enlace VIP y el tráfico de los clientes normales vaya por el enlace “normal”? Una solución a este problema nos la proporciona una adecuada configuración del protocolo de enrutamiento BGP.
También se recomienda el uso de BGP cuando se pretende que nuestro sistema autónomo haga de “tránsito” para paquetes de datos entre distintos sistemas autónomos. Este es el caso típico de un ISP.

Cuando no usar BGP

Voy a incidir nuevamente en la idea de partida de que BGP sólo es una solución válida en ciertos casos “especiales”. En nuestro sistema autónomo deberíamos aplicar como solución predilecta las rutas por defecto, sobre todo en caso de que nos conectemos a internet a través de un único enlace con un ISP. Si sólo disponemos de un enlace al exterior BGP no tiene sentido.
Tampoco es recomendable usar BGP si los enlaces al exterior son inestables ó de baja capacidad, ya que BGP introduce mucha sobrecarga (la  “Internet routing table” que maneja el BGP de un ISP ocupa muchos megas que deben atravesar nuestro enlace hasta llegar a nuestros routers).
También hay que tener especial cuidado con la capacidad de procesamiento de nuestros routers. Si la máquina que hace de router frontera va pillada de CPU, el proceso BGP (que es costoso en términos de procesamiento) podría acabar de rematarla. Tampoco es despreciable el consumo de memoria, dado que la  “Internet routing table” ocupa muchos megas (y crece día a día). A día de hoy, hay más de 33.333 ASes presentes en la “Internet Routing Table” y el número de prefijos anunciados supera los 333.333. La tabla de rutas de internet supera los 33 MB.
Tampoco recomiendo usar BGP en situaciones en las que a pesar de ser la mejor opción, el gestor de red no disponga de un entendimiento suficiente de lo que se trae entre manos... En ese caso, ¡¡¡ ahórrese disgustos !!!
Por último y no por ello menos importante tenga en cuenta lo que dice la documentación de Quagga al respecto del demonio bgpd:

Quien tenga ojos para ver, que vea y quien tenga oídos para oír que oiga... :-)

Introducción a BGP

BGP son las siglas de Border Gateway Protocol, cuya última versión es la 4 y se referencia como BGP-4. Se trata de un protocolo de pasarela exterior (EGP), estándar de facto desde 1994 como protocolo entre dominios. Se describe en la RFC1771, A Border Gateway Protocol 4 (BGP-4), al que se han añadido múltiples extensiones, como el soporte multiprotocolo en la RFC2858.
Como se ha comentado, el concepto de Sistema autónomo juega un papel clave en la comprensión del protocolo BGP. Un sistema autónomo es un conjunto de routers bajo una administración técnica única, que utiliza protocolos de pasarela interior (un IGP como ospf, rip, etc...) para enrutar paquetes dentro del sistema autónomo y un protocolo de pasarela exterior (un EGP como BGP) para enrutar paquetes a otros sistemas autónomos. Un sistema autónomo debe presentar una imagen coherente de los destinos que son alcanzables a través de el y todos los destinos dentro de un mismo AS deben estar interconectados, es decir, no puede haber destinos que hayan quedado aislados. La misión de BGP es proporcionar un sistema de enrutamiento entre ASes que impida la formación de bucles (ruta cerrada de paquetes que dan vueltas en círculo y que por lo tanto nunca llegan su destino).
Cada sistema autónomo, tanto si es alcanzable públicamente desde internet ó sólo disponible a nivel privado, debe disponer de un número identificador de sistema autónomo a efectos de implementar BGP. Se trata de un número de 16 bits, cuyo rango va de 1 a 65535. En el RFC 1930 encontraremos recomendaciones sobre la asignación de estos números. En este documento se especifica que la Internet Assigned Numbers Authority (IANA) ha reservado un bloque de números de AS para uso privado (no publicados en el Internet Global). Este rango va desde 64512 a 65535. Para el ejemplo que veremos en este artículo usaremos números de AS en el rango privado.
Otra clasificación para los protocolos de enrutamiento se establece entre protocolos por “estado del enlace”, ó protocolos por “vector de distancias”. BGP es un protocolo del tipo “vector distancia”, al igual que RIP. Los routers que implementan BGP envían a sus vecinos los destinos alcanzables a través del AS al que pertenecen, expresados como vectores con una métrica de manera similar a como hace RIP (aunque muy mejorada). Cada vector especifica una red de destino y contiene una serie de atributos que definen la ruta a esa red en cuestión a través del AS que remite la información. Uno de los atributos más relevantes, es la lista de los ASes que se atravesarán para llegar al destino. Para evitar los bucles de enrutamiento, un AS descartará las rutas que ya incluyan su número de AS.
Los atributos de ruta se catalogan en dos clases: “bien conocidos” y “opcionales”. Los bien conocidos son aquellos atributos que todas las implementaciones de BGP deben conocer, mientras que los opcionales podrían no estar implementados. Dentro de los atributos “bien conocidos” algunos deben figurar obligatoriamente en la ruta (los “obligatorios”) y otros no (los “discrecionales”). El “atributo de ruta de AS”, especifica la lista de ASes que se atraviesan para llegar a un destino y es del tipo bien conocido y obligatorio. Otros atributos disponibles son:

• atributo de próximo salto: dirección IP del próximo salto para alcanzar el destino

• atributo de preferencia local: indica qué ruta es la preferida para salir del AS. Sólo se intercambia esta información con routers del mismo AS.

• atributo MED (discriminador de salida múltiple): indica a los vecinos de OTRO AS, la ruta preferida a nuestro AS.

• atributo de origen de la ruta: indica cómo se conoció la ruta (IGP, EGP ó desconocido).

Los intercambios de información de enrutamiento BGP se realizan a través de sesiones BGP, en las que un par de routers denominados “vecinos” se conectan mediante una conexión TCP (puerto 179). El hecho de que la información se intercambie a través de una sesión TCP es relevante, puesto que al tratarse de una conexión con control de errores, una vez transmitida el grueso de la tabla de rutas BGP, no será necesario volver a enviarla, siendo suficiente actualizaciones incrementales. Estos dos vecinos pueden vivir en el mismo AS, con lo que se denomina BGP “interno” (IBGP) ó pueden vivir en diferente AS, por lo que se denomina BGP “externo” (EBGP). Cada router sólo publicará a sus vecinos rutas que el mismo pueda utilizar. Es decir, aunque le pidamos a BGP que anuncie la red 192.168.0.0/24, si el router no sabe cómo llegar a ella, no la anunciará. Los procesos BGP mantienen una tabla de rutas BGP separada de la tabla de rutas que el router utiliza para enrutar los paquetes.

Software

Las configuraciones que aquí se especifican, han sido probadas sobre una distribución GNU/Linux Fedora 12 sobre una máquina con arquitectura x86_64 y un partner Cisco IOS 12.2(15)T11 sobre un router Cisco 2610. La versión de quagga utilizada es 0.99.12

Introducción a Quagga

El software utilizado para implementar el protocolo BGP sobre GNU/Linux ha sido Quagga (www.quagga.net). Quagga es un paquete de software avanzado que provee un conjunto de protocolos de routing unicast basados en TCP/IP; tales como RIP, OSPF y BGP. En el sitio web de Quagga podrá consultar la lista exhaustiva de RFC's soportados. Quagga implementa los protocolos de enrutamiento antes mencionados, y con la información obtenida a través de ellos, actualiza la tabla de rutas del kernel. La configuración de los distintos protocolos puede ser modificada sobre la marcha, y la tabla de rutas visualizada desde una interfaz de terminal. Cabe destacar también el sistema de administración del sistema Quagga. Mientras en la operación normal de un administrador de red sobre GNU/linux es usual necesitar privilegios de root para ejecutar los clásicos comandos ifconfig, route ó netstat, Quagga presenta dos modos de usuario: modo “normal” y modo “enabled”. Mediante el modo normal, el usuario podrá consultar el estado del sistema; mientras que con el modo “enabled” habilitado, podrá además modificar la configuración del sistema. Para el administrador de red, esta independencia de la cuenta UNIX le hará la vida más fácil.
Quagga es una bifurcación del proyecto GNU Zebra (www.zebra.org). Zebra es un gestor de enrutamiento IP: actualiza la tabla de rutas del kernel, provee las interfaces lookups, y redistribuye las rutas entre los distintos protocolos.

Arquitectura de quaggua

Quaggua se basa en una colección de diferentes demonios (específicos para los distintos protocolos de red: ripd, ripngd, ospfd, ospf6d, bgpd; más el demonio gestor zebra) que trabajan juntos para construir la tabla de rutas. El demonio bgpd soporta el protocolo BGP-4; mientras que el demonio zebra gestiona la tabla de rutas del kernel. Cada demonio dispone de su propio fichero de configuración, e interfaz de terminal, e incluso podrían estar ubicados en máquinas diferentes. Así, una ruta estática debe introducirse en el fichero de configuración del demonio zebra, mientras que la configuración BGP debe introducirse en el fichero de configuración del demonio bgpd. Para simplificar la problemática de gestionar varios ficheros de configuración diferentes, Quagga dispone de una interfaz de usuario integrada denominada vtysh, la cual se comunica con el demonio apropiado actuando como un proxy para las entradas de usuario.

Instalaciones

Como puede verse en el listado 1, la instalación de Quagga con yum es muy sencilla. Con el comando “yum info quagga” obtenemos la información del paquete. Con el comando “yum install quagga” lo instalamos.

En el listado 2, podemos observar el directorio que contiene los ficheros de instalación de quagga: /etc/quagga ; así como los nombres de esos ficheros.

Como en cualquier proyecto GNU, la instalación de Quagga, también puede realizarse descargando el código fuente y compilándolo en nuestra propia máquina. Una descripción detallada de este proceso puede encontrarse en la documentación de quagga (http://www.quagga.net/docs/quagga.html#SEC9)

Habilitar el reenvío de paquetes IP

Para que una máquina GNU/linux realice las funciones de un router, se debe habilitar el reenvío de paquetes IP. En Fedora, puede hacerse con el siguiente comando.

Sin embargo, si la máquina se reinicia, esta configuración se perderá. Si queremos que el reenvío  sobreviva a los reinicios, deberemos modificar una línea en el fichero /etc/sysctl.conf así:

Y a continuación utilizar el comando /sbin/sysctl, que configura los parámetros del kernel en tiempo de ejecución:

Descripción del ejemplo

En el siguiente gráfico puede observarse el sencillo ejemplo que vamos a implementar.

Como puede observarse los dos routers “vecinos” BGP serán por un lado un router Cisco 2610 corriendo un sistema operativo IOS (versión 12.2(15)T11) y por otro un portátil GNU/linux (Fedora 12) ejecutanto los demonios quagga (zebra y bgpd).
El router frontera cisco pertenece al sistema autónomo 65.222 (perteneciente al rango privado) y está conectado a cuatro redes. Las cuatro IP que le conectan a esas redes son: 10.2.2.2 , 10.3.3.3 , 10.4.4.4 y 172.16.0.2
Por su parte, el router Quagga pertenece al AS 65.111 (también del rango privado) y está conectado a dos redes, con IP: 10.1.1.1 y 172.16.1.1
Como los dos routers pertenecen a sistemas autónomos diferentes se trata de BGP externo (EBGP). Se configurará el protocolo BGP para que ambos routers intercambien información sobre las redes 10.*.*.*

Ficheros de configuración en quagga

En Fedora los ficheros de configuración se encuentran en el directorio /etc/quagga. Para realizar el ejemplo antes descrito, modificaremos los siguientes ficheros de configuración: zebra.conf, vtysh.conf y bgpd.conf. Una explicación precede a cada uno de los comandos  mediante una línea de comentario.

vtysh.conf

El listado 3, contiene la configuración del terminal virtual desde el que acceder a todos los demonios Quagga activos. Vtysh actúa como un proxy para el acceso telnet.

Zebra.conf

En el listado 4, puede verse el fichero donde se configuran los parámetros de funcionamiento del demonio zebra: /etc/quagga/zebra.conf
Se le asigna el nombre “Router” y la palabra clave “zebra” para el caso de que queramos acceder diréctamente al demonio zebra mediante una sesión “telnet localhost 2601” (el demonio zebra corre sobre el puerto 2601). La clave “zebra” se asigna tanto para el modo normal como para el privilegiado. Se asigna el fichero para registro de eventos /var/log/quagga/zebra.log , que por defecto tendrá el nivel “debugging”. Los niveles de registro disponibles son: emergencies, alerts, critical, errors, warnings, notifications, information y debugging. Se configuran los interfaces eth y lo con las IPs descritas en el ejemplo. Se crea una lista de acceso donde se permite la máquina localhos (127.0.0.1/32) y se rechaza el resto. Esta lista se aplica al acceso telnet. Por último se habilita el encaminamiento de paquetes.

bgpd.conf

En el listado 5, puede verse el fichero donde se configuran los parámetros de funcionamiento del demonio bgpd: /etc/quagga/bgpd.conf
Se le asigna el nombre “bgpd-router” al promt del terminal virtual. El demonio bgpd corre sobre el puerto (bien conocido) TCP 2605, por lo que para acceder a el ejecutamos “telnet localhost 2605”. Se le asigna la palabra clave “bgpd”. Se configura el registro en la salida estandar “stdout”. Por último se configura el proceso BGP. Se asigna el AS local 65111 y el identificador de router local como “172.16.0.1”. Se ha elegido igual que la IP del interfaz que comunica con el vecino, aunque puede elegirse otro diferente (cualquiera en realidad). Se especifica que se registren cambios en el estado de los vecinos. Es útil para la resolución de incidencias. Se anunciará la red 10.1.1.0/24 a través del BGP. Se especifica el vecino (el router Cisco) 172.16.0.2 perteneciente al AS 65222.

Propietarios de los archivos de configuración

A continuación nos aseguraremos de que tienen asignados el usuario y grupo adecuado:

Arrancar los demonios en la máquina GNU/linux

Arrancarmos zebra el primero con el comando:

A continuación, arrancar bgpd:

Para detener la ejecución de cualquiera de los demonios, sustituimos “start” por “stop”. Si lo que queremos es reinciarlos, utilizaremos “restart”.

Configuración del router vecino cisco

La configuración del listado 6, se introduce en el router Cisco por la línea de comandos. Símplemente nos conectamos a la consola de equipo (si no tiene claro cómo, al final del artículo se describe el proceso de acceso a la consola Cisco), entramos en modo “enabled”, ejecutamos el comando “configure terminal”, pegamos la configuración tal cual y salimos del terminal de configuación con “end”. Si queremos que las modificaciones se hagan persistentes al reinicio, usaremos el comando “write”.
La configuración es simple.  Se configuran cuatro interfaces en el router. Las tres de loopback son las que se anunciarán en BGP al vecino conectado a la interfaz ethernet 0/0. Nótese que es necesario que el router Cisco sepa alcanzar las redes que anunciará en BGP (network ...). De otro modo no las anunciará. Es una consecuencia del paradigma de enrutamiento salto a salto. (¡¡¡ Contrariamente a lo que cabría esperar el router Quagga envía la ruta por la sesión BGP aunque no sepa como llegar al destino !!!).

Monitorización del demonio zebra y bgpd

Para acceder al terminal virtual (la ventanilla única :-) desde donde configurar los demonios zebra y bgpd conjuntamente ejecute el comando:

Desde este  interface centralizado vtysh, pueden ejecutarse los siguietes comandos de monitorización:

show version

Se observa que la versión de Quagga ejecutada es la 0.99.12

sh ip route

El listado 7 muestra la salida del comando “sh ip route” en el router quagga.
Con este comando visualizamos las rutas disponibles en la tabla de rutas. Podemos observar las rutas que hemos obtenido gracias a la sesión BGP establecida, que son las marcadas con una “B”. Los rutas marcadas con una “C” son las directamente conectadas. El propio comando nos indica al inicio los códigos de los distintos tipos de rutas.
Una vez que visualice estas rutas BGP en el router Quagga, podrá acceder por ping a las direcciones 10.2.2.2, 10.3.3.3 y 10.4.4.4 del router Cisco:

show interface

El listado 8 muestra la salida del comando “sh interface” en el router quagga. Muestra los interfaces conectados al router

show ip forwarding

Visualiza si la función de encaminamiento de paquetes está activada o no.

sh ip bgp  summary

El listado 9 muestra la salida del comando “show ip bgp summary” en el router quagga.
Obtenemos un informe resumido del estado de las sesiones BGP. Podemos ver nuestro indentificador de sesión BGP  (172.16.0.1), así como nuestro número de sistema autónomo 65.111.  Hay siete entradas en la Routing Information Base que ocupan 672 bytes. Tenemos un vecino BGP con identificador 172.17.0.2 que ejecuta la versión 4 del protocolo BGP y cuyo AS es 65222. Nos ha remitido tres prefijos (los que hemos visto marcados con una “B” en “show ip route”) y la sesión BGP con este vecino lleva 2 minutos 16 segundos establecida.

sh ip bgp

El listado 10 muestra la salida del comando “show ip bgp” en el router quagga.
Gracias a este comando podemos visualizar las rutas con los atributos que describíamos en la introducción a BGP. En concreto vemos la red de destino con el atributo “next hop”, es decir el próximo salto para alcanzar el destino. Vemos el atributo “Metric”, descrito en la introducción como MED. El atributo “LocPrf”, descrito como Local preference. El atributo “ruta de AS”, con la lista de ASes hasta el destino (en este caso sólo AS 65222). Por último el código de origen de la ruta, “i” the IGP. El asterisco marca las rutas válidas.

sh ip bgp neighbors

Información detallada de cada una de las sesiones BGP establecidas con los vecinos.

clear  ip bgp  *

Cambios de configuración en tiempo de ejecución

A través de la consola vtysh se pueden modificar las configuraciones, tanto del demonio bgpd como el zebra en tiempo real en la máquina GNU/linux de la misma manera que se haría en un router cisco.
Por ejemplo podemos eliminar la red 10.1.1.0/24 como directamente conectada, borrando la configuración del “interface lo”.

Para ver la configuración resultante “write terminal”. Para hacerla persistente, solo “write”. Una vez eliminada la IP del interface el router Cisco no podrá alcanzarla con ping:

Conclusión

En este artículo se han revisado los fundamentos para el uso del protocolo de enrutamiento BGP-4. En particular, se ha ensayado una sencilla sesión BGP  entre un router con sistema operativo GNU/linux y un router vecino cisco-2610.  Se ha expuesto que como norma general, el uso de rutas por defecto es preferible al uso de BGP, que es recomendable solo en ciertos casos especiales. Se ha hecho una introducción a Quagga, un sofware GNU que provee varios protocolos de enrutamiento entre los que se encuentra BGP. Se ha habilitado una máquina GNU/linux para reenvío de paquetes y se ha introducido el protocolo BGP. Se han presentado los ficheros de configuación para un ejemplo sencillo de uso de BGP sobre Quagga y su configuración correspondiente en el router cisco. Se han comentado los ficheros de configuación de los demonios zebra y bgpd. Se han visto comandos de monitorización del enrutamiento sobre el terminal virtual de Quagga, así como el modo de efectuar cambios de configuración en tiempo real.

GLOSARIO

AS Autonomous System ó Sistema Autónomo
ASes Sistemas Autonomos
EGP Exterior Gateway Protocol
GNU GNU is Not Unix
IGP Internal Gateway Protocol
IP Internet Protocol
ISP Internet Server Provider; por ejemplo una operadora como Telefónica
RFC Request For Comments
RIP Routing Information Protocol

NOTA SOBRE EL AUTOR

Francisco Ramón Torrado Bea es ingeniero superior de telecomunicaciones con especialidad en telemática.
Certificado Cisco CCNP y master en Gestión de Empresas de Telecomunicaciones.
Trabajó como soporte y configuración de red de datos en las principales operadoras españolas.
En la actualidad es director técnico de TopazioWeb.com