12. Parte práctica

12. Parte práctica
En este apartado se pretende dar una visión de las distintas posibilidades
prácticas que existen en el mercado para hacer uso del protocolo BGP de una forma
profesional. Para ello, se van a implementar dos escenarios de ejemplo distintos en los
cuales se explica la configuración realizada y se analizan los resultados obtenidos tras
monitorizar las tablas de encaminamiento y los mensajes capturados.
En el primer escenario se muestra la posibilidad del uso de software de routing
para implementar PC routers con las funciones de encaminamiento dinámico. En
concreto, se ha elegido el paquete software Zebra, el cual es de libre distribución y se
ejecuta bajo el sistema operativo Linux. Este software de routing soporta el protocolo
BGPv4, así como las funciones de filtrado (listas de acceso) y modificación de los
atributos (route maps) de las rutas tanto anunciadas como recibidas.
Debido a las limitaciones en la configuración física de la arquitectura de red del
laboratorio, en este primer escenario no se ha podido llevar a cabo una configuración
compleja. De este modo, las pruebas realizadas muestran sólo un funcionamiento básico
del protocolo BGP, ya que no se ha podido configurar una red con varios niveles
jerárquicos (sólo se tiene una subred interna por cada PC router conectado a la red
backbone), por lo que en este caso sería también factible la configuración de rutas
estáticas a mano. Sin embargo, en redes más complejas y extensas la necesidad del
encaminamiento dinámico es innegable.
El segundo escenario se basa en el uso de routers Cisco, cuyo hardware soporta
las diferentes funciones del protocolo BGPv4. En este escenario se lleva a cabo una
configuración de los diferentes routers tal y como se haría en un caso real con routers
Cisco. Dicha configuración se corresponde a un caso real de uso de BGP para la
conexión de un AS cliente a varios ISPs que forman Internet.
Normalmente, para adquirir un router se debe contactar con un fabricante que se
dedique a desarrollar su propio software propietario compatible con un hardware
especialmente hecho para las funciones de encaminamiento. Este es el caso de
fabricantes como Cisco Systems (IOS), Nortel Networks o Juniper Networks (JUNOS).
En este caso se ha elegido una configuración para routers Cisco por la enorme cuota de
mercado que ocupa dicho fabricante y por la abundancia de manuales y casos prácticos
disponibles para estos routers.
12.1.
Configuración de BGP mediante Zebra
12.1.1. Sofware de routing
Con el rápido crecimiento de Internet y el incremento de demandas de accesos,
muchas organizaciones están teniendo dificultades para cubrir las necesidades de
hardware y software que requieren los servicios demandados. Para el caso de
organizaciones pequeñas que no puedan afrontar la adquisición de dispositivos de red
para la conexión a Internet existe una solución a corto e incluso a largo plazo. Esta
consiste en convertir PCs en routers mediante la instalación de software de routing, lo
cual supone un ahorro en costes considerable.
Existen diversos paquetes software que sólo necesitan correr sobre un sistema
operativo (GNU/Linux, por ejemplo), disponer de varias interfaces de red y tener
activado el soporte de encaminamiento en el kernel. Esta solución resulta factible para
redes locales o redes con un tráfico limitado en las que el tiempo de convergencia de los
algoritmos no es crítico.
Entre los paquetes software de routing más usados cabe destacar soluciones de
libre distribución como Zebra, Quagga o Radvd, así como aplicaciones propietarias
tales como ZebOs y Gated. El software radvd (Router Advertisement Daemon) es de
libre distribución y se implementa como un módulo del sistema operativo Linux capaz
de escuchar y anunciar rutas con direcciones IPv6. Por su parte, Zebra y Quagga
soportan los protocolos de encaminamiento RIPv1 (RFC1058), RIPv2 (RFC2453),
OSPFv2 (RFC2328) y BGPv4 (RFC1771). Además, estas herramientas también
soportan protocolos de encaminamiento para IPv6 como RIPng (RFC2080), OSPFv3
(RFC2740) y extensiones BGPv4 (RFC2545).
La principal ventaja que proporcionan Zebra y Quagga es que son herramientas
software de libre distribución (bajo la Licencia General Pública GNU) que implementan
protocolos de encaminamiento no propietarios extensamente difundidos y utilizados.
Otra ventaja es que este software permite un aprendizaje importante sobre la
configuración de routers y puesta en práctica del encaminamiento dinámico, ya que los
comandos utilizados para la configuración de los protocolos de encaminamiento son
muy similares a que los que se utilizan para configurar equipos routers de proveedores
como Cisco.
Sin embargo, para la configuración de este software se requiere mayor
especialización, ya que no sólo es necesario prestar atención a las funciones de
encaminamiento, sino que también es necesario gestionar el sistema operativo del PC
router. Además, el hecho de disponer de pocas interfaces limita sus aplicaciones
prácticas a redes con pocos enlaces.
En Zebra/Quagga, se tiene un demonio de routing para la gestión de cada
protocolo de encaminamiento dinámico. De este modo, se tienen los demonios ripd,
ospfd y bgpd que soportan los protocolos RIP o RIPv2, OSPFv2 y BGP-4,
respectivamente. A su vez, todos se comunican con el demonio gerente (demonio
zebra), el cual interacciona con el sistema operativo para la configuración general de las
interfaces y para poner al día las tablas de encaminamiento del kernel. Esta arquitectura
multiproceso modular permite que el sistema Zebra y Quagga sea más fácilmente
extensible y gestionable.
Zebra/Quagga se pueden configurar, por un lado, mediante una serie de ficheros
de configuración y, por otro, pasándole comandos a los demonios en una conexión
telnet al puerto en el que escucha cada demonio, el cual puede encontrarse en la misma
máquina (localhost) o en una máquina remota. Por ejemplo, para configurar BGP una
vez se haya arrancado el demonio bgpd se puede ejecutar: telnet localhost bgpd.
Cada demonio tiene su propio fichero de configuración. Así, para configurar una
interfaz de red o una ruta estática se utiliza el fichero de configuración de zebra
(usr/local/etc/zebra.conf por defecto), mientras que para configurar un protocolo de
encaminamiento en concreto se debe configurar el fichero correspondiente del demonio
de routing. Por ejemplo, en el caso de bgpd el nombre del fichero de configuración por
defecto es bgpd.conf.
12.1.2. Plan de direccionamiento
En este escenario se ha elegido una estructura de red basada en la estructura ya
existente en el laboratorio en el que se tiene una serie de PCs interconectados mediante
conmutadores de nivel 2 o switch. Estos PCs funcionarán como PC routers con dos
interfaces activas: eth0 y eth1. La interfaz eth0 estará conectada al resto de PC routers
mediante un switch, mientras que la interfaz eth1 servirá para conectarse al PC cliente.
Así, cada PC router servirá de conmutador para un PC cliente, el cual tendrá su interfaz
eth0 desactivada y su interfaz eth1 conectada al PC router. De este modo, se tienen dos
niveles jerárquicos con una red de PC routers en todo el laboratorio y una subred interna
por cada PC router.
Cada PC router va a representar a un ISP (Proveedor de servicio de Internet), el
cual dará servicio a una serie de AS clientes (se probará con un solo cliente por ISP en
la práctica). El PC router establecerá una sesión peering con el PC cliente y con el resto
de PC routers, filtrará las rutas anunciadas por el cliente y realizará la agregación de
rutas. Los números de sistemas autónomos que se van a utilizar serán 65X2 para los
clientes y 65X1 para los PC routers (siendo X un número de dos dígitos distintos para
cada PC router).
La siguiente figura muestra la configuración de red utilizada en el caso de dos
PC routers con sus dos clientes correspondientes:
192.44.26.1
PC_router
192.44.80.26
192.44.26.2
PC_cliente
192.44.28.2
192.44.28.1
PC_router
PC_cliente
192.44.80.28
En este escenario se va a implementar el siguiente esquema de direccionamiento:
•
La red interna que interconecta el PC router X a la estación que emula los
clientes tendrá como prefijo 192.44.X.0/24. La interfaz eth1 del equipo PC
router X tendrá como dirección IP 192.44.X.1, mientras que la interfaz eth1
del PC cliente correspondiente tendrá como IP 192.44.X.2.
•
La red GIX (Global Internet Exchange) que interconecta todos los PC routers
tendrá como prefijo 192.44.80.0/24. La interfaz eth0 de cada PC router X en
esta red tendrá como dirección 192.44.80.X.
12.1.3. Configuración del demonio zebra
Zebra es el demonio gestor capaz de interactuar con las funciones del kernel. De
este modo, zebra se encarga de actualizar las tablas de encaminamiento del kernel a
partir de las informaciones proporcionadas por los demás demonios, de la configuración
de las distintas interfaces (dirección IP, máscara, rutas estáticas,…) y de la
redistribución de rutas entre los diferentes demonios que gestionan los protocolos de
encaminamiento.
Para la configuración de las interfaces zebra se dispone de los siguientes
comandos (añadiendo no al mismo comando se desactiva el comando):
•
interface nombre_interfaz: Con este comando se accede a la interfaz
indicada para su configuración. Para ello se debe estar antes en el modo de
configuración (configure terminal). Una vez ejecutado el comando
interface se pueden ejecutar ejecutar el resto de comandos para configurar
la interfaz determinada.
•
shutdown (no shutdown): activa (desactiva) la interfaz actual.
•
ip address @IP/prefijo: Configura la dirección IPv4 de la interfaz, junto
con su máscara (en notación CIDR). Este comando es el equivalente al
comando ifconfig del shell Linux: ifconfig interfaz @IP netmask
mascara.
•
ip6 address @IPv6/prefijo: Configura la dirección IPv6 de la interfaz,
junto con su máscara (en CIDR).
Por otro lado, además de la configuración de las interfaces, zebra también permite
configurar el encaminamiento estático, para lo cual se debe estar en el modo de
configuración (configure terminal). Esta configuración es sencilla ya que sólo
consiste en indicar al encaminador la interfaz o el router pasarela (gateway) hacia el que
debe reenviar un paquete que tiene una dirección IP destino determinada.
Adicionalmente, se puede indicar una pasarela (gateway) por defecto a la cual enviar en
el caso de que la dirección IP de destino no coincida con ninguna de las entradas de la
tabla de encaminamiento.
Para la configuración del encaminamiento estático en zebra se utiliza el comando ip
route red puerta_de_enlace. Este comando sirve para añadir una nueva ruta a la
tabla de encaminamiento, lo cual consiste en indicar al router que si le llega un paquete
con una dirección IP de destino que no pertenece a las redes conectadas directamente,
éste debe redirigirlo hacia otro router por una de las interfaces. El parámetro red indica
la red destino y puede seguir dos notaciones diferentes: formato CIDR (A.B.C.D/M) o
formato decimal (A.B.C.D mascara).
El parámetro puerta_de_enlace indica el router al cual enviar el paquete cuya
dirección IP destino coincida con el parámetro red anterior. La puerta de enlace sigue el
formato A.B.C.D (sin máscara de red), y en su lugar también se puede indicar el nombre
de la interfaz. En los siguientes ejemplos se pueden ver las distintas notaciones posibles:
•
ip route 10.0.0.0/8 10.0.0.2: Se define una ruta estática a la red
10.0.0.0/8 a través de la puerta de enlace 10.0.0.2.
•
ip route 192.168.14.0 255.255.255.0 eth0: Se define la ruta estática
a la red 192.168.14.0/24 utilizando una máscara, a través de la interfaz
eth0.
•
ip route 0.0.0.0 255.255.255.255 eth1: Se define la ruta por defecto
hacia la interfaz eth1.
Una vez explicados los comandos para la configuración del demonio zebra se
van a adjuntar las configuraciones utilizadas tanto para el PC cliente como para el PC
router. En primer lugar, se va a realizar la configuración del PC cliente. Para ello se
deben seguir los siguientes pasos:
•
Se crean cuatro interfaces dummy en Linux, que simularán una serie de redes
internas que forman parte del mismo AS que el PC cliente. Para esto se debe
cargar el módulo dummy y configurar cada interfaz mediante el comando
ifconfig:
/sbin/modprobe
/sbin/modprobe
/sbin/modprobe
/sbin/modprobe
/sbin/ifconfig
/sbin/ifconfig
/sbin/ifconfig
/sbin/ifconfig
•
-o dummy0 --ignore-install dummy
-o dummy1 --ignore-install dummy
-o dummy2 --ignore-install dummy
-o dummy3 --ignore-install dummy
dummy0 10.0.0.X netmask 255.255.255.0 up
dummy1 10.0.1.X netmask 255.255.255.0 up
dummy2 200.0.X.2 netmask 255.255.128.0 up
dummy3 200.X.X.2 netmask 255.128.0.0 up
Se debe situar el fichero de configuración de zebra en el directorio
correspondiente y, posteriormente, se puede lanzar el demonio zebra mediante
service zebra start. En el fichero de configuración de zebra se asignan las
direcciones IP y las máscaras a las interfaces dummy y a la interfaz eth1 del
cliente (192.44.X.2/24, siendo X el número de dos dígitos asignado al PC
router correspondiente). A continuación se muestra el contenido del fichero
zebra.conf:
!
! Fichero de configuracion de zebra en PC_cliente BGP
!
hostname PcClient
password zebra
enable password admin
service password-encryption
!
interface lo
!
interface eth1
ip address 192.44.X.2/24
!
interface dummy0
ip address 10.0.0.X/24
!
interface dummy1
ip address 10.0.1.X/24
!
interface dummy2
ip address 200.0.X.2/23
!
interface dummy3
ip address 200.X.X.2/9
!
ip route 0.0.0.0/0 192.44.X.1
!
log file /var/log/quagga/zebra.log
!
end
Una vez que se ha configurado el PC cliente, se va a pasar a la configuración del
demonio zebra en el PC router, para lo cual se utilizara el fichero zebra.conf siguiente:
!
! Fichero de configuracion de zebra en PC_router BGP
!
hostname PCrouter
password zebra
enable password admin
service password-encryption
!
debug zebra events
debug zebra packet
debug zebra kernel
!
interface lo
!
interface eth0
ip address 192.44.80.X/24
no shutdown
!
interface eth1
ip address 192.44.X.1/24
no shutdown
!
ip forwarding
!
log file /var/log/quagga/zebra.log
!
end
12.1.4. Configuración del demonio bgpd
Para activar el proceso bgpd en el router se utiliza el comando router bgp asn.
En este comando se indica el número del sistema autónomo (ASN) al que pertenece el
router, lo que permite al proceso bgpd detectar si una sesión BGP es interna o externa.
El valor de asn está entre 1 y 65535, siendo los ASN del 64512 al 65535 privados. Los
ASN privados no deben anunciarse nunca en Internet.
El comando bgp router-id id_router sirve para especificar el identificador
del router en BGP a mano. El id_router se obtiene por defecto a partir de la
información de las interfaces del demonio zebra, tomando como identificador la
dirección de mayor numeración de todas las interfaces. Sin embargo, cuando el demonio
zebra no está habilitado, bgpd no puede obtener la información de las interfaces y el
identificador se fija a 0.0.0.0, siendo necesario configurarlo a mano.
Una vez activado el demonio se introducen los comandos para la configuración
básica de BGP: los comandos neighbor y network. Las sesiones BGP se establecen
utilizando el comando neighbor peer remote-as asn. El valor de peer puede ser
una dirección IPv4 ó IPv6 e indica la dirección del vecino con el que se establece la
sesión BGP. Este vecino pertenecerá al AS cuyo número sea asn, de tal modo que si los
números de AS de los dos routers son iguales se establece una sesión I-BGP, mientras
que se establecerá una sesión E-BGP en caso contrario.
Dos vecinos que pertenezcan a dos AS diferentes deberán pertenecer a la misma
red local. En cambio, en el caso de I-BGP cada router pasarela establece una sesión IBGP con el resto de pasarelas del mimo AS aunque no exista conectividad física
directamente, ya que se puede encontrar un camino indirecto entre ellos gracias al resto
de routers del AS, los cuales utilizan un protocolo IGP para el encaminamiento.
Las pasarelas de un mismo AS no establecerán sesiones I-BGP mediante las
interfaces físicas, sino mediante interfaces virtuales (loopback), para lo cual se utiliza el
comando neighbor [@IP/peer-group] update-source loopback0. Para esto, será
necesario definir antes la interfaz virtual: interface loopback 0, ip address [@IP]
[mascara]. El protocolo I-BGP se encargará de indicar a una pasarela cómo alcanzar la
dirección virtual del otro extremo.
Por otro lado, el comando network prefijo [mask] [mascara] activa el
anuncio de la red indicada. El prefijo se puede introducir en notación CIDR
(A.B.C.D/M) o, por el contrario, mediante una máscara en decimal
(255.255.255.0) con la opción mask, si la red introducida no es de clases.
De este modo, en el fichero de configuración bgpd.conf se configuran el número
del AS cliente, se activan las redes a anunciar con el comando network y se
establece una sesión BGP con el PC router con el comando neighbor. (El valor de
X coincide con el número de dos dígitos del PC router correspondiente).
!
! Fichero de configuracion de bgpd en PC_cliente
!
hostname BGPDClient
password zebra
enable password admin
service password-encryption
!
router bgp 65X2
bgp router-id 192.44.X.2
network 10.0.0.X/24
network 10.0.1.X/24
network 200.0.X.2/23
network 200.X.X.2/9
neighbor 192.44.X.1 remote-as 65X1
!
log file /var/log/quagga/bgpd.log
!
end
A continuación, se muestra el fichero de configuración de bgpd en el PC router.
En esta configuración, el PC router se configura para que anuncie las rutas a las que está
conectado y para que acepte el peering con el PC cliente y con otro PC router (cuyo
número de dos cifras correspondiente será Y).
!
! Fichero de configuracion de bgpd en PC_router
!
hostname bgpdd
password zebra
enable password admin
service password-encryption
!
router bgp 65X1
bgp router-id 192.44.X.1
network 192.44.X.0/24
network 192.44.80.0/24
neighbor 192.44.X.2 remote-as 65X2
neighbor 192.44.80.Y remote-as 65Y1
!
log file /var/log/quagga/bgpd.log
!
end
En la configuración anterior se anuncian rutas con IPs privadas entre PC routers,
lo cual no es válido en el escenario similar a Internet que se está simulando. Por ello,
sería necesario filtrar las rutas con prefijo 10.0/8 para que no sean exportadas a otros
PC routers, lo cual debe hacerse antes de realizar el peering entre los PC routers. Las
reglas de filtrado necesarias se podrían implementar mediante un route-map que se
aplicaría en el peering con el PC cliente:
route-map map1 permit 10
match ip address 1
access-list 1 deny 10.0.0.0 0.255.255.255
access-list 1 permit any
!
router bgp 65X1
neighbor 192.44.X.2 route-map map1
Para ver los mensajes intercambiados se puede utilizar el modo debug: debug
bgp updates y debug bgp keepalive (comando opuesto con no y el mismo comando
para desactivarlo). De esta forma, se puede ver cómo el PC cliente anuncia sus
interfaces dummy al PC router, el cual las exportará cuando no se utilicen reglas de
filtrado y las rechazará cuando se implemente el filtrado de rutas. Los resultados
obtenidos en la puesta en práctica de este escenario se analizan en el siguiente apartado.
12.1.5. Resultados obtenidos
Una vez activados los demonios bgpd y zebra configurados tanto en el PC cliente
como en el PC router, se pueden visualizar las rutas de la tabla de encaminamiento del
PC router mediante el comando show ip route en la sesión telnet con zebra (las rutas
con la letra B en la primera columna han sido aprendidas por BGP y el valor [20/0]
indica la métrica de la ruta).
PCrouter# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
B>*
B>*
C>*
C>*
B>*
C>*
B>*
B>*
B>*
10.0.0.0/24 [20/0] via 192.44.26.2, eth1, 00:09:08
10.0.1.0/24 [20/0] via 192.44.26.2, eth1, 00:09:08
127.0.0.0/8 is directly connected, lo
192.44.26.0/24 is directly connected, eth1
192.44.28.0/24 [20/0] via 192.44.80.28, eth0, 00:03:19
192.44.80.0/24 is directly connected, eth0
200.0.0.0/9 [20/0] via 192.44.26.2, eth1, 00:09:08
200.0.26.0/23 [20/0] via 192.44.26.2, eth1, 00:09:08
200.0.28.0/23 [20/0] via 192.44.80.28, eth0, 00:03:19
A partir de la sesión telnet con el demonio bgpd se puede ejecutar el comando
show ip bgp, el cual permite ver las rutas aprendidas por el demonio, así como los
parámetros asociados a éstas como el origen (interno o externo), la métrica, el camino
(path) y el siguiente nodo para llegar al destino de la ruta (next hop). En este caso se
muestra la información obtenida mediante este comando en el PC router X=26:
bgpd# show ip bgp
BGP table version is 0, local router ID is 192.44.26.1
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
* 10.0.0.0/24
65282 i
*>
* 10.0.1.0/24
65282 i
*>
*> 192.44.26.0
*> 192.44.28.0
* 192.44.80.0
*>
Next Hop
192.44.80.28
Metric LocPrf Weight Path
0 65281
192.44.26.2
192.44.80.28
0
192.44.26.2
0.0.0.0
192.44.80.28
192.44.80.28
0.0.0.0
0
0
0
0
0
0 65262 i
0 65281
0
32768
0
0
32768
65262 i
i
65281 i
65281 i
i
* 200.0.0.0/9
65282 i
*>
*> 200.0.26.0/23
*> 200.0.28.0/23
65282 i
192.44.80.28
0 65281
192.44.26.2
192.44.26.2
192.44.80.28
0
0
0 65262 i
0 65262 i
0 65281
Total number of prefixes 8
Además de la información anterior, se levó a cabo una captura de mensajes entre
los que cabe destacar los siguientes:
•
Mensajes OPEN (establecimiento de sesión E-BGP entre el PC router
192.44.80.26 y el PC router 192.44.80.28):
No.
Time
4 0.000577
Message
Source
192.44.80.26
Destination
192.44.80.28
Protocol Info
BGP OPEN
Frame 4 (111 bytes on wire, 111 bytes captured)
Ethernet II, Src: 3Com_97:56:2b (00:04:76:97:56:2b), Dst: 3Com_97:77:f8
(00:04:76:97:77:f8)
Internet Protocol, Src: 192.44.80.26 (192.44.80.26), Dst: 192.44.80.28
(192.44.80.28)
Transmission Control Protocol, Src Port: 32880 (32880), Dst Port: bgp (179),
Seq: 1, Ack: 1, Len: 45
Border Gateway Protocol
No.
Time
6 0.003525
Message
Source
192.44.80.28
Destination
192.44.80.26
Protocol Info
BGP OPEN
Frame 6 (111 bytes on wire, 111 bytes captured)
Ethernet II, Src: 3Com_97:77:f8 (00:04:76:97:77:f8), Dst: 3Com_97:56:2b
(00:04:76:97:56:2b)
Internet Protocol, Src: 192.44.80.28 (192.44.80.28), Dst: 192.44.80.26
(192.44.80.26)
Transmission Control Protocol, Src Port: bgp (179), Dst Port: 32880 (32880),
Seq: 1, Ack: 46, Len: 45
Border Gateway Protocol
•
No.
Mensajes KEEPALIVE (mantenimiento de la sesión entre los PC routers):
Time
11 0.004898
KEEPALIVE Message
Source
192.44.80.28
Destination
192.44.80.26
Protocol Info
BGP
Frame 11 (85 bytes on wire, 85 bytes captured)
Ethernet II, Src: 3Com_97:77:f8 (00:04:76:97:77:f8), Dst: 3Com_97:56:2b
(00:04:76:97:56:2b)
Internet Protocol, Src: 192.44.80.28 (192.44.80.28), Dst: 192.44.80.26
(192.44.80.26)
Transmission Control Protocol, Src Port: bgp (179), Dst Port: 32880 (32880),
Seq: 65, Ack: 65, Len: 19
Border Gateway Protocol
No.
Time
12 0.004923
KEEPALIVE Message
Source
192.44.80.26
Destination
192.44.80.28
Protocol Info
BGP
Frame 12 (85 bytes on wire, 85 bytes captured)
Ethernet II, Src: 3Com_97:56:2b (00:04:76:97:56:2b), Dst: 3Com_97:77:f8
(00:04:76:97:77:f8)
Internet Protocol, Src: 192.44.80.26 (192.44.80.26), Dst: 192.44.80.28
(192.44.80.28)
Transmission Control Protocol, Src Port: 32880 (32880), Dst Port: bgp (179),
Seq: 65, Ack: 84, Len: 19
Border Gateway Protocol
•
Mensajes UPDATE (intercambio de informació entre los PC routers):
No.
Time
Source
13 0.005045
192.44.80.28
UPDATE Message, UPDATE Message
Destination
192.44.80.26
Protocol Info
BGP
Frame 13 (180 bytes on wire, 180 bytes captured)
Ethernet II, Src: 3Com_97:77:f8 (00:04:76:97:77:f8), Dst: 3Com_97:56:2b
(00:04:76:97:56:2b)
Internet Protocol, Src: 192.44.80.28 (192.44.80.28), Dst: 192.44.80.26
(192.44.80.26)
Transmission Control Protocol, Src Port: bgp (179), Dst Port: 32880 (32880),
Seq: 84, Ack: 84, Len: 114
Border Gateway Protocol
Border Gateway Protocol
No.
Time
15 1.004865
UPDATE Message
Source
192.44.80.26
Destination
192.44.80.28
Protocol Info
BGP
Frame 15 (122 bytes on wire, 122 bytes captured)
Ethernet II, Src: 3Com_97:56:2b (00:04:76:97:56:2b), Dst: 3Com_97:77:f8
(00:04:76:97:77:f8)
Internet Protocol, Src: 192.44.80.26 (192.44.80.26), Dst: 192.44.80.28
(192.44.80.28)
Transmission Control Protocol, Src Port: 32880 (32880), Dst Port: bgp (179),
Seq: 84, Ack: 198, Len: 56
Border Gateway Protocol
12.2. Configuración de BGP en Routers Cisco
En este apartado se explican en primer lugar las bases de utilización y los
comandos generales de los routers Cisco. Posteriormente, se analiza la configuración de
BGP en un escenario formado por la interconexión de diferentes routers Cisco.
12.2.1. Estructura interna de un router Cisco
En general, todos los routers Cisco tienen en común una estructura interna cuyos
componentes fundamentales son los siguientes:
•
Memoria RAM/DRAM: Este memoria es volátil y, por lo tanto, almacena la
información provisional como la tabla de encaminamiento, tablas de valores de
los distintos procesos, configuración actual (running-config),…
•
Memoria NVRAM: Es un tipo de RAM no volátil, en la cual se guarda la
configuración definitiva o de arranque (startup-config).
•
Memoria ROM: Esta memoria contine el programa de arranque del router y un
pequeño sistema de monitorea para detectar problemas de funcionamiento en el
router.
•
FLASH: Es un tipo especial de ROM programable, en la cual se guarda una
copia del sistema operativo del router Cisco.
•
INTERFACES: Son los dispositivos capaces de enviar y recibir paquetes de
datos de los diferentes protocolos soportados. Existen distintos tipos de
interfaces físicas (Ethernet, FastEthernet, Serial,…)
•
PORT CONSOLE: Consiste en el mecanismo principal de control del router
mediante el cual se introduce la configuración. Para ello se utiliza un PC externo
conectado al PORT CONSOLE mediante un puerto serie, y un software
emulador de terminal capaz de entenderse con el router para la introducción de
los comandos en éste.
El acceso al router se hace a partir de cualquier emulador de terminal (como
minicom sobre Linux, reflexion VT o Hyper Terminal sobre Windows). En el caso de un
PC con Linux, una vez conectados el PORT CONSOLE con el puerto serie del PC se
puede lanzar el programa minicom (minicom –s para ejecutarlo sin configuración por
defecto). Será entonces necesario elegir una serie de parámetros para la transmisión de
los comandos (baudios, bits de datos, control de paridad, puerto serie
correspondiente,…)
12.2.2. Modos de trabajo
En un router Cisco se puede operar en tres modos de trabajo:
•
USER EXEC MODE: Éste es el modo de comienzo tras el arranque del router. En
este modo se puede monitorizar un conjunto limitado de informaciones sobre el
estado de la configuración actual del router y no se tiene permitido modificar ni
borrar la configuración. Cuando se está en este modo aparece el símbolo “>”
después del hostname (Router>). Para salir del modo usuario se utiliza el comando
logout.
•
PRIVILEGED EXEC MODE: En este modo es posible ejecutar los mismos
comandos que en el modo usuario más los comandos que permiten monitorizar
todas las informaciones sobre el estado de configuración del router. Además, en el
modo administrador también se pueden ejecutar comandos para depurar la
configuración actual. Para pasar del modo usuario al modo administrador es
necesario introducir el comando enable desde el emulador de terminal, pudiendo
proteger dicho acceso mediante una password. A su vez, para salir de este modo se
utiliza el comando disable.
•
CONFIGURATION MODE: En este modo se pueden usar los comandos necesarios
para modificar, borrar o agregar parámetros a la configuración global del router
(interfaces, filtros, password,…). Para entrar en este modo desde el modo
administrador es necesario ejecutar el comando configure terminal, mientras
que para salir se pueden utilizar las órdenes exit, Ctrl-Z o Ctrl-C.
En todos los modos es posible conocer la lista de comandos disponibles gracias a
la orden ?. Además, en lugar de teclear un comando completo se puede utilizar una
abreviación de éste si no supone ninguna ambigüedad, completándose dicha abreviación
mediante el uso de la tecla TAB.
12.2.3. Monitorización del estado
El sistema operativo Cisco permite utilizar una serie de comandos para la
monitorización del estado del router, entre los que cabe destacar los siguientes:
•
show version: Muestra la configuración del hardware del sistema, la versión del
software, nombres y orígenes de los archivos de configuración y de la imagen de
arranque.
•
show processes: Muestra la información acerca del proceso activo.
•
show protocols: Muestra los protocolos configurados.
•
show mem: Muestra estadísticas sobre la memoria del router.
•
show ip route: Muestra las entradas en la tabla de encaminamiento.
•
show flash: Muestra información sobre el controlador de la memoria flash.
•
show running-config: Muestra los parámetros de la configuración activa.
•
show
startup-config: Muestra la configuración del archivo que guarda la
configuración definitiva utilizada en el inicio del sistema.
•
show interfaces: Muestra estadísticas para todas las interfaces configuradas en el
router.
•
show lines: Muestra el estado de todas las líneas disponibles en el router.
•
show users: Muestra el estado de las líneas que están siendo usadas por otros
usuarios incluyendo la local.
•
show clock: Muestra la hora y fecha configuradas en el router.
12.2.4. Carga de la configuración mediante TFTP
Se ha visto anteriormente que se podían modificar los parámetros de la
configuración del router manualmente al pasar al modo de configuración desde el modo
privilegiado mediante el comando configure terminal. Por otro lado, otra opción
para modificar la configuración consiste en descargar un fichero con los parámetros a
introducir en la memoria del router desde un servidor TFTP. Para ello se pueden utilizar
los comandos siguientes:
•
copy
tftp:
running-config: Carga un fichero de configuración desde un
servidor TFTP a la RAM del router.
•
copy tftp: startup-config: Carga un archivo de configuración desde un
servidor TFTP directamente a la memoria NVRAM del router.
Una vez introducidos los comandos anteriores se solicita el nombre del servidor
(o su dirección IP) y el nombre del fichero dentro de esa máquina. Cuando se cargan
los archivos de configuración a la RAM o a la NVRAM, el router actúa como un
compilador y va traduciendo línea por línea el archivo.
Del mismo modo, si se pretende enviar y guardar una configuración en el
servidor se puede utilizar el comando copy running-config tftp:, para lo cual es
necesario de nuevo indicar el nombre del servidor y el nombre del fichero (el cual debe
existir anteriormente en el servidor y tener permiso de escritura).
Por otra parte, también será necesario configurar el servidor TFTP. Para el caso
de un servidor bajo Linux, lo primero que debe hacerse es editar el fichero
/etc/xinetd.d/tftp.conf o /etc/inetd.d indicando la opción disable: no. A
continuación, es necesario verificar que el directorio /tftpboot existe (o el directorio
especificado en el fichero de configuración del servicio). Además, se debe comprobar
que existen los ficheros en el directorio /tftpboot y que los permisos son los correctos
para poder ser descargados (es aconsejable dar todos los permisos mediante chmod 777
* para evitar problemas).
Otro aspecto a comprobar es que las direcciones IP de las interfaces del router y
del servidor Linux sean las correctas (en la misma subred, por ejemplo) y que existe
conexión (comando ping). Finalmente, una vez comprobado todo lo anterior se puede
arrancar de nuevo el servicio TFTP mediante service xinetd restart para que se
cargue la nueva configuración.
12.2.5. Configuración general de un router Cisco
Una de las primeras acciones en la configuración de un router es asignarle un
nombre. Para ello se usa el comando hostname, el cual debe ejecutarse desde el modo
de configuración global (enable y config terminal). El nombre del router es
mostrado en el prompt del sistema operativo (por defecto aparece el nombre Router) y
sirve para ayudar a los administradores a la identificación de los diferentes
componentes de la red.
Al igual que el router, las interfaces también pueden ser identificadas por un
nombre, para lo cual se utiliza el comando description seguido del nombre o
descripción. Previamente se debe acceder a la interfaz específica mediante el comando
interface seguido del tipo (Ethernet o serial, por ejemplo) y del número de puerto
(que depende de la cantidad de slots o interfaces instaladas).
En la configuración de las interfaces se utilizan una serie de comandos entre los
que destacan los siguientes:
•
ip address: Sirve para asignar una dirección IP y una máscara a la interfaz
determinada.
•
bandwith: Para asignar un ancho de banda determinado a la interfaz.
•
no keepalive: Este comando sirve para desactivar el mecanismo de advertencia
activo por defecto en el router que se encarga de enviar alarmas al administrador
para indicarle algún problema.
•
clock rate: Sirve para ajustar la velocidad del reloj de una línea serial (sólo para
dispositivos funcionando como DCE).
•
shutdown (no shutdown): Para activar (desactivar) la interfaz indicada.
Opcionalmente, también es posible proteger el acceso al modo administrador del
router mediante el uso de una password. Esta protección es útil sobre todo para
proteger el router de una modificación realizada de forma remota por una persona no
autorizada, ya que en realidad siempre es posible reconfigurar el router si se dispone
de un acceso físico a éste. La contraseña elegida se guarda en la configuración global
en claro o encriptada, según se utilice el comando enable secret o enable passwd,
respectivamente.
Finalmente, otro aspecto importante en el manejo básico de los routers Cisco es
el hecho de poder guardar los cambios efectuados en la configuración actual, los cuales
se encuentran en memoria RAM volátil y se perderían al apagar el dispositivo. Por
esto, una vez que la configuración se considera definitiva es preciso grabarla en
memoria NVRAM. Para esto se utiliza el comando copy running-config startupconfig, de forma que al arrancar el router la configuración cargada será la
configuración que se guardó.
Para hacer que la startup-config sea la configuración actual se utiliza el
comando reload. Además, también se puede borrar la configuración de memoria
NVRAM y cargar una configuración de base almacenada en memoria FLASH
mediante el comando erase startup-config. En este caso la configuración del
router volverá a sus valores de fábrica.
12.2.6. Ejemplo de configuración de un AS multihomed
En este apartado se va a ir explicando paso a paso la configuración de ejemplo
elegida en la cual se aplican diversas funcionalidades de BGP estudiadas a lo largo de
este proyecto. Además, se van a mostrar los resultados obtenidos y se van a analizar los
contenidos de las tablas de encaminamiento, así como de las tablas de los procesos
BGP.
A continuación se muestra el esquema de la topología implementada:
En primer lugar, se va a llevar a cabo una primera configuración de todos los
routers en la cual se supone que el AS 100 es un sistema autónomo cliente conectado a
dos ISPs (AS 200 y AS 300) vía EBGP. El resto de sistemas autónomos se consideran
también ISPs que forman la red Internet.
En el AS 100 será necesario establecer una sesión IBGP entre los routers de
borde RTA y RTB, de modo que se tenga un mejor control de las rutas aprendidas del
exterior. Por otra parte, será también necesario el uso de un protocolo de
encaminamiento IGP en todos los routers del AS 100 (RTA, RTB y RTF) para el
intercambio de rutas interno, para lo cual se utilizará el protocolo OSPF.
En la configuración de OSPF aparecen el comando router ospf num_proceso,
(el cual sirve para arrancar el proceso OSPF) y el comando network 203.250.0.0
0.0.255.255 area 0. La porción de área de la sentencia network especifica el área en
la que se colocarán las interfaces que coincidan con la sentencia. En este caso sólo se
define un área por lo que ésta debe tener el número de identificación 0 (área backbone).
El comando network tiene las tres funciones siguientes:
•
•
•
Anuncia las rutas pertenecientes a la red específica basada en clases.
Se escuchan todas las actualizaciones en todas las interfaces pertenecientes a la
red basada en clases.
Se envían actualizaciones en todas las interfaces pertenecientes a la red basada
en clases.
De este modo, las redes que se deben anunciar se indican con el comando
network. No se trata de dar todas las redes que el PC router conoce, o a las cuales está
conectado, sino de definir las interfaces sobre las cuales se va a ejecutar el proceso de
encaminamiento. De este modo, para una red basada en clases las interfaces cuyas
direcciones corresponden a los prefijos definidos por este comando podrán participar en
el proceso de encaminamiento. En este caso se activa automáticamente el protocolo
OSPF en todas las interfaces cuyas direcciones estén dentro del rango indicado
(203.250.0.0) y se anuncian las subredes dentro de ese rango a las cuales esté
conectado el PC router (203.250.14.0 y 203.250.15.0).
En un principio, la configuración quedaría de la siguiente forma (no es definitiva):
RTA#
hostname RTA
ip subnet-zero
interface Loopback0
ip address 203.250.13.41 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Serial0
ip address 128.213.63.1 255.255.255.252
router ospf 10
network 203.250.0.0 0.0.255.255 area 0
router bgp 100
network 203.250.0.0 mask 255.255.0.0
neighbor 128.213.63.2 remote-as 200
neighbor 203.250.15.2 remote-as 100
neighbor 203.250.15.2 update-source Loopback0
RTF#
hostname RTF
ip subnet-zero
interface Ethernet0
ip address 203.250.14.2 255.255.255.0
interface Serial1
ip address 203.250.15.1 255.255.255.252
router ospf 10
network 203.250.0.0 0.0.255.255 area 0
RTB#
hostname RTB
ip subnet-zero
interface Serial0
ip address 203.250.15.2 255.255.255.252
interface Serial1
ip address 192.208.10.6 255.255.255.252
router ospf 10
network 203.250.0.0 0.0.255.255 area 0
router bgp 100
network 203.250.15.0
neighbor 192.208.10.5 remote-as 300
neighbor 203.250.13.41 remote-as 100
RTC#
hostname RTC
ip subnet-zero
interface Loopback0
ip address 128.213.63.130 255.255.255.192
interface Serial2/0
ip address 128.213.63.5 255.255.255.252
!
interface Serial2/1
ip address 128.213.63.2 255.255.255.252
router bgp 200
network 128.213.0.0
neighbor 128.213.63.1 remote-as 100
neighbor 128.213.63.6 remote-as 400
RTD#
hostname RTD
ip subnet-zero
interface Loopback0
ip address 192.208.10.174 255.255.255.192
interface Serial0/0
ip address 192.208.10.5 255.255.255.252
!
interface Serial0/1
ip address 192.208.10.2 255.255.255.252
router bgp 300
network 192.208.10.0
neighbor 192.208.10.1 remote-as 500
neighbor 192.208.10.6 remote-as 100
RTE#
hostname RTE
ip subnet-zero
interface Loopback0
ip address 200.200.10.1 255.255.255.0
interface Serial0
ip address 195.211.10.2 255.255.255.252
interface Serial1
ip address 128.213.63.6 255.255.255.252
clockrate 1000000
router bgp 400
network 200.200.10.0
neighbor 128.213.63.5 remote-as 200
neighbor 195.211.10.1 remote-as 500
RTG#
hostname RTG
ip subnet-zero
interface Loopback0
ip address 195.211.10.174 255.255.255.192
interface Serial0
ip address 192.208.10.1 255.255.255.252
interface Serial1
ip address 195.211.10.1 255.255.255.252
router bgp 500
network 195.211.10.0
neighbor 192.208.10.2 remote-as 300
neighbor 195.211.10.2 remote-as 400
En esta primera configuración se utiliza el comando network para inyectar las
rutas a anunciar por EBGP en lugar de la redistribución de rutas IGP en BGP, ya que de
esta forma se asegura el anuncio de estas rutas de una forma más sencilla. Además, en
este caso se supone que la interfaz serial S1 del router RTB está desactivada (shutdown)
y que no existe el enlace entre los routers RTB y RTD. De esta forma, la tabla del
proceso BGP para el router RTB sería la siguiente:
RTB#sh ip bgp
table version is 4, local router ID is 203.250.15.2 Status
codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric LocPrf Weight Path
*i128.213.0.0
128.213.63.2
0
100
0 200 i
*i192.208.10.0
128.213.63.2
100
0 200 400 500
300 i
*i195.211.10.0
128.213.63.2
100
0 200 400 500
i
*i200.200.10.0
128.213.63.2
100
0 200 400 i
*>i203.250.13.0
203.250.13.41
0
100
0 i
*>i203.250.14.0
203.250.13.41
0
100
0 i
*>203.250.15.0
0.0.0.0
0
32768 i
La letra “i” al principio de una entrada significa que dicha entrada se aprendió de
un vecino BGP. En cambio, la letra “i” al final indica que el origen de la entrada ha sido
un protocolo IGP. Por otra parte, se puede ver cómo la ruta 128.213.0.0 se encuentra
en el AS 200 (PATH=200) y se llega a ella a partir de la dirección 128.213.63.2,
según se indica en el atributo NEXTHOP que no ha sido modificado por la sesión IBGP
de RTB con RTA. Cabe destacar que cualquier entrada generada localmente al AS,
como la red 203.250.15.0, tiene un valor del NEXTHOP igual a 0.0.0.0.
El símbolo “>” indica que el proceso BGP ha elegido dicha entrada como la
mejor ruta hacia el destino indicado según los criterios de decisión. Esto implica que
dicha ruta será añadida a la tabla de encaminamiento y será anunciada al resto de
vecinos BGP. La tabla de encaminamiento correspondiente a esta configuración en el
router RTB sería la siguiente:
RTB#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate
default
Gateway of last resort is not set
203.250.13.0 255.255.255.255 is subnetted, 1 subnets
203.250.13.41 [110/75] via 203.250.15.1, 02:50:45, Serial0
203.250.15.0 255.255.255.252 is subnetted, 1 subnets
203.250.15.0 is directly connected, Serial0
203.250.14.0 [110/74] via 203.250.15.1, 02:50:46, Serial0
O
C
O
En esta tabla de encaminamiento se puede ver que no se ha añadido ninguna de
las entradas que aparecen en la tabla BGP. Esto es debido a dos problemas:
•
Problema 1: El NEXTHOP para la entrada 128.213.63.2 es inalcanzable. Esto
es debido a que no se tiene ninguna forma de alcanzar la dirección
128.213.63.2 mediante el protocolo IGP (OSPF). Como solución, se puede
configurar el router RTA para que anuncie la red 128.213.0.0 y pasivar la
interfaz serial S0 en RTA (comando passive-interface) para que no se
difundan las actualizaciones indicadas por el comando network en dicha
interfaz. La configuración del router RTA quedaría de la siguiente forma:
RTA#
hostname RTA
ip subnet-zero
interface Loopback0
ip address 203.250.13.41 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Serial0
ip address 128.213.63.1 255.255.255.252
router ospf 10
passive-interface Serial0
network 203.250.0.0 0.0.255.255 area 0
network 128.213.0.0 0.0.255.255 area 0
router bgp 100
network 203.250.0.0 mask 255.255.0.0
neighbor 128.213.63.2 remote-as 200
neighbor 203.250.15.2 remote-as 100
neighbor 203.250.15.2 update-source Loopback0
De este modo, la tabla BGP del router RTB cambiaría al indicar las rutas
seleccionadas con el símbolo “>”:
RTB#show ip bgp
BGP table version is 10, local router ID is 203.250.15.2
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*>i128.213.0.0
*>i192.208.10.0
300 i
*>i195.211.10.0
i
*>i200.200.10.0
*>i203.250.13.0
*>i203.250.14.0
*> 203.250.15.0
Next Hop
128.213.63.2
128.213.63.2
Metric LocPrf Weight Path
0
100
0 200 i
100
0 200 400 500
128.213.63.2
128.213.63.2
203.250.13.41
203.250.13.41
0.0.0.0
100
0
0
0
100
100
100
0 200 400 500
0
0
0
32768
200 400 i
i
i
i
Del mismo modo, la tabla de encaminamiento del router RTB también
cambiaría:
RTB#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is not set
203.250.13.0 255.255.255.255 is subnetted, 1 subnets
203.250.13.41 [110/75] via 203.250.15.1, 00:04:46, Serial0
203.250.15.0 255.255.255.252 is subnetted, 1 subnets
203.250.15.0 is directly connected, Serial0
203.250.14.0 [110/74] via 203.250.15.1, 00:04:46, Serial0
128.213.0.0 255.255.255.252 is subnetted, 1 subnets
128.213.63.0 [110/138] via 203.250.15.1, 00:04:47, Serial0
O
C
O
O
•
Problema 2: Según puede verse en la tabla de encaminamiento, aunque la red
128.213.63.0 es alcanzable todavía no aparecen las entradas seleccionadas.
Esto es debido a un problema de sincronización, ya que el proceso BGP no
añade las entradas seleccionadas en la tabla de encaminamiento ni las envía en
las actualizaciones porque no está sincronizado con el protocolo OSPF. La
sincronización implica que todos los routers del AS 100 tengan constancia de la
existencia de las rutas que se van a anunciar por EBGP. En este caso el router
RTF no conoce la rede 192.208.10.0 o la red 195.211.10.0 porque en la
configuración de BGP no se ha indicado que dichas rutas sean redistribuidas en
OSPF.
En este escenario se podría indicar la opción synchronization off de manera que
las rutas aprendidas por BGP aparecerían en la tabla de encaminamiento del router
RTB, pero la conectividad para llegar a esos destinos no estaría asegurada ya que no
se podría pasar por el router RTF.
RTB#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is not set
B
B
B
O
B
C
O
B
O
200.200.10.0 [200/0] via 128.213.63.2, 00:01:07
195.211.10.0 [200/0] via 128.213.63.2, 00:01:07
192.208.10.0 [200/0] via 128.213.63.2, 00:01:07
203.250.13.0 is variably subnetted, 2 subnets, 2 masks
203.250.13.41 255.255.255.255
[110/75] via 203.250.15.1, 00:12:37, Serial0
203.250.13.0 255.255.255.0 [200/0] via 203.250.13.41, 00:01:08
203.250.15.0 255.255.255.252 is subnetted, 1 subnets
203.250.15.0 is directly connected, Serial0
203.250.14.0 [110/74] via 203.250.15.1, 00:12:37, Serial0
128.213.0.0 is variably subnetted, 2 subnets, 2 masks
128.213.0.0 255.255.0.0 [200/0] via 128.213.63.2, 00:01:08
128.213.63.0 255.255.255.252
[110/138] via 203.250.15.1, 00:12:37, Serial0
Por lo tanto, si se desactiva la sincronización en el router RTB, la tabla de
encaminamiento del router RTB sería la adecuada, aunque no existiría conectividad
debido a que el router intermedio RTF no sabría cómo llegar a esos destinos. La tabla de
encaminamiento del router RTF sería la siguiente:
RTF#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is not set
O
C
C
O
203.250.13.0 255.255.255.255 is subnetted, 1 subnets
203.250.13.41 [110/11] via 203.250.14.1, 00:14:15, Ethernet0
203.250.15.0 255.255.255.252 is subnetted, 1 subnets
203.250.15.0 is directly connected, Serial1
203.250.14.0 is directly connected, Ethernet0
128.213.0.0 255.255.255.252 is subnetted, 1 subnets
128.213.63.0 [110/74] via 203.250.14.1, 00:14:15, Ethernet0
De este modo, la desactivación de la sincronización en el router RTB no
resuelve este problema, por lo que será necesario redistribuir las rutas BGP en OSPF
(con una métrica de 2000 por ejemplo). La configuración del router RTA para
solucionar este segundo problema es la siguiente:
RTA#
hostname RTA
ip subnet-zero
interface Loopback0
ip address 203.250.13.41 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Serial0
ip address 128.213.63.1 255.255.255.252
router ospf 10
redistribute bgp 100 metric 2000 subnets
passive-interface Serial0
network 203.250.0.0 0.0.255.255 area 0
network 128.213.0.0 0.0.255.255 area 0
router bgp 100
network 203.250.0.0 mask 255.255.0.0
neighbor 128.213.63.2 remote-as 200
neighbor 203.250.15.2 remote-as 100
neighbor 203.250.15.2 update-source Loopback0
En la tabla de encaminamiento del router RTB desaparecerían entonces las
entradas BGP porque éstas se obtienen a partir de OSPF con un coste menor (110) que
en el caso de BGP (200).
RTB#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is not set
O E2 200.200.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
O E2 195.211.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
O E2 192.208.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0
203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O
203.250.13.41 255.255.255.255
[110/75] via 203.250.15.1, 00:00:15, Serial0
O E2
203.250.13.0 255.255.255.0
[110/2000] via 203.250.15.1, 00:00:15, Serial0
203.250.15.0 255.255.255.252 is subnetted, 2 subnets
C
203.250.15.8 is directly connected, Loopback1
C
203.250.15.0 is directly connected, Serial0
O
203.250.14.0 [110/74] via 203.250.15.1, 00:00:15, Serial0
128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2
128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1,
00:00:15,Serial0
O
128.213.63.0 255.255.255.252
[110/138] via 203.250.15.1, 00:00:16, Serial0
Sin embargo, en la configuración final se va a desactivar la sincronización en el
router RTA para anunciar la ruta 203.250.15.0 ya que no va a existir problema con
OSPF debido a la diferencia de máscaras. Por la misma razón, también se va a
desactivar la sincronización en el router RTB para anunciar la ruta 203.250.13.0.
Además, también se va a activar la interfaz S1 en RTB para habilitar OSPF en ésta y se
va a pasivar dicha interfaz para que RTA aprenda cómo llegar al NEXTHOP
192.208.10.5 mediante IGP. Así, las configuraciones de los routers RTA y RTB
quedarían como sigue:
RTA#
hostname RTA
ip subnet-zero
interface Loopback0
ip address 203.250.13.41 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Serial0
ip address 128.213.63.1 255.255.255.252
router ospf 10
redistribute bgp 100 metric 2000 subnets
passive-interface Serial0
network 203.250.0.0 0.0.255.255 area 0
network 128.213.0.0 0.0.255.255 area 0
router bgp 100
no synchronization
network 203.250.0.0 mask 255.255.0.0
neighbor 128.213.63.2 remote-as 200
neighbor 203.250.15.2 remote-as 100
neighbor 203.250.15.2 update-source Loopback0
RTB#
hostname RTB
ip subnet-zero
interface Serial0
ip address 203.250.15.2 255.255.255.252
interface Serial1
ip address 192.208.10.6 255.255.255.252
router ospf 10
redistribute bgp 100 metric 1000 subnets
passive-interface Serial1
network 203.250.0.0 0.0.255.255 area 0
network 192.208.0.0 0.0.255.255 area 0
router bgp 100
no synchronization
network 203.250.15.0
neighbor 192.208.10.5 remote-as 300
neighbor 203.250.13.41 remote-as 100
Las tablas BGP que resultan en los routers RTA y RTB tras poner en marcha la
configuración anterior serían las siguientes:
RTA#show ip bgp
BGP table version is 117, local router ID is 203.250.13.41
Status codes: s suppressed, d damped, h history, * valid, > best,
i -internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*> 128.213.0.0
*>i192.208.10.0
*>i195.211.10.0
*
i
*> 200.200.10.0
*> 203.250.13.0
*> 203.250.14.0
*>i203.250.15.0
Next Hop
128.213.63.2
192.208.10.5
192.208.10.5
128.213.63.2
128.213.63.2
0.0.0.0
0.0.0.0
203.250.15.2
Metric LocPrf Weight Path
0
0 200 i
0
100
0 300 i
100
0 300 500 i
0 200 400 500
0
0
0
100
0
32768
32768
0
200 400 i
i
i
i
RTB#show ip bgp
BGP table version is 12, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best,
i -internal Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*>i128.213.0.0
*
Next Hop
128.213.63.2
192.208.10.5
Metric LocPrf Weight Path
0
100
0 200 i
0 300 500 400
200 i
*> 192.208.10.0
*> 195.211.10.0
*>i200.200.10.0
*
i
*>i203.250.13.0
*>i203.250.14.0
*> 203.250.15.0
192.208.10.5
192.208.10.5
128.213.63.2
192.208.10.5
0
203.250.13.41
203.250.13.41
0.0.0.0
0
0
0
100
100
100
0
0
0
0
300
300
200
300
i
500 i
400 i
500 400
0 i
0 i
32768 i
Después de haber solucionado el problema de la conexión entre routers BGP, el
intercambio de rutas y la accesibilidad de los destinos, el siguiente aspecto a tener en
cuenta es la forma en que el AS cliente (AS 100) accede a Internet a través de los dos
ISPs (AS 200 y AS 300). Una posibilidad es utilizar uno de los ISP para el acceso
primario y mantener el otro como backup, es decir, como ISP auxiliar para el caso de
que falle el ISP primario.
La política de encaminamiento elegida consiste en que el AS 100 reciba
anuncios de rutas de cualquier otro AS a través del router RTA y sólo rutas locales
pertenecientes al AS 300 a través del router RTB, de manera que el tráfico dirigido
hacia el exterior con destino diferente a una ruta interna del AS 300 sólo pase por el
router de borde RTA. Además, tanto RTA como RTB generan rutas por defecto con
destino hacia el exterior (RTA hacia la ruta 200.200.0.0 y RTB hacia la ruta
192.208.10.0) dentro del AS 100 mediante OSPF, dando mayor preferencia a RTB
para su ruta por defecto (métrica menor). De este modo, para el tráfico de salida por
defecto se utiliza el ISP 300, mientras que para el tráfico con destino las rutas
aprendidas del exterior mediante EBGP se utiliza el ISP conectado al router de borde
RTA.
Un posible problema podría ser que el tráfico que salga del AS 100 por RTA
reciba respuesta por el router RTB, lo cual provocaría una situación de asimetría. Esto
podría ocurrir en el caso de que se utilizase la misma supernet en las direcciones que las
interfaces que ambos routers de borde tienen con el exterior del AS. De esta manera, la
agregación de rutas provocaría que ambos puntos de acceso si viesen del mismo modo
desde el exterior. Sin embargo, en esta configuración se han utilizado direcciones
diferentes para las subredes que sirven para unir cada router de borde del AS 100 con
cada ISP.
Se ha visto que todo el tráfico saliente del AS 100 (excepto el tráfico por defecto
que se envía hacia la dirección 192.208.10.0) va a pasar por el router RTA y por el AS
200. Esto se consigue modificando el atributo LOCAL_PREF de los anuncios recibidos
desde el exterior, de forma que los anuncios recibidos por RTA tengan preferencia con
respecto a los anuncios recibidos por RTB. Sin embargo, en el router RTB sólo va a
modificarse el atributo LOCAL_PREF de las actualizaciones recibidas que no se
correspondan con anuncios de redes internas del AS 300. De esta forma, para alcanzar
las redes con origen en el AS 300 sí se va a preferir pasar por el router RTB.
La configuración final del router RTA se muestra a continuación:
RTA#
hostname RTA
ip subnet-zero
interface Loopback0
ip address 203.250.13.41 255.255.255.0
interface Ethernet0
ip address 203.250.14.1 255.255.255.0
interface Serial0
ip address 128.213.63.1 255.255.255.252
router ospf 10
redistribute bgp 100 metric 2000 subnets
passive-interface Serial0
network 203.250.0.0 0.0.255.255 area 0
network 128.213.0.0 0.0.255.255 area 0
default-information originate metric 2000
router bgp 100
no synchronization
network 203.250.13.0
network 203.250.14.0
neighbor 128.213.63.2
neighbor 128.213.63.2
neighbor 203.250.15.2
neighbor 203.250.15.2
remote-as 200
route-map setlocalpref in
remote-as 100
update-source Loopback0
ip classless
ip default-network 200.200.0.0
route-map setlocalpref permit 10
set local-preference 200
En la configuración anterior de RTA, el atributo LOCAL_PREF de las rutas que
se reciben a través del AS 200 se modifica con un valor de 200. Como candidata a ruta
por defecto se establece la red 200.200.0.0 mediante el comando ip defaultnetwork. Además, para poder inyectar la ruta por defecto anterior en el dominio OSPF,
es necesario utilizar el comando default-information originate, lo cual no es necesario
en otros protocolos IGP como RIP o IGRP al hacerse automáticamente.
La configuración definitiva de los routers RTF y RTB quedaría como sigue:
RTF#
hostname RTF
ip subnet-zero
interface Ethernet0
ip address 203.250.14.2 255.255.255.0
interface Serial1
ip address 203.250.15.1 255.255.255.252
router ospf 10
network 203.250.0.0 0.0.255.255 area 0
ip classless
RTB#
hostname RTB
ip subnet-zero
interface Loopback1
ip address 203.250.15.10 255.255.255.252
interface Serial0
ip address 203.250.15.2 255.255.255.252
!
interface Serial1
ip address 192.208.10.6 255.255.255.252
router ospf 10
redistribute bgp 100 metric 1000 subnets
passive-interface Serial1
network 203.250.0.0 0.0.255.255 area 0
network 192.208.10.6 0.0.0.0 area 0
default-information originate metric 1000
!
router bgp 100
no synchronization
network 203.250.15.0
neighbor 192.208.10.5 remote-as 300
neighbor 192.208.10.5 route-map localonly in
neighbor 203.250.13.41 remote-as 100
!
ip classless
ip default-network 192.208.10.0
ip as-path access-list 1 permit ^300$
route-map localonly permit 10
match as-path 1
set local-preference 300
En el router RTB se modifica el atributo LOCAL_PREF de los anuncios de las
rutas locales del AS 300 y que provienen de dicho AS. De este modo, para llegar al AS
300 se seleccionan dichas rutas por tener un valor del atributo LOCAL_PREF (300)
mayor que en el caso de las rutas con destino una red del AS 300 que llegan a RTB por
la sesión IBGP con RTA (con LOCAL_PREF igual a 200).
Por otro lado, los anuncios de rutas que lleguen a RTB con un AS_PATH
diferente al indicado mediante la expresión ^300$ (que empiecen y terminen por el ASN
300) serán descartados. De este modo, cualquier ruta que sea anunciada por RTB de
forma interna en el AS 100 y que tenga un AS_PATH distinto al valor 300 será
anunciada con un valor del atributo LOCAL_PREF igual a 100 (<200), por lo que se
preferirán las rutas provenientes de RTA. La tabla BGP del router RTB resultaría ser
como sigue:
RTB#sh ip bgp regexp ^300$
BGP table version is 14, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*> 192.208.10.0
Next Hop
192.208.10.5
Metric LocPrf Weight Path
0
300
0 300
A continuación se muestra la configuración definitiva del router RTC:
RTC#
hostname RTC
ip subnet-zero
interface Loopback0
ip address 128.213.63.130 255.255.255.192
interface Serial2/0
ip address 128.213.63.5 255.255.255.252
!
interface Serial2/1
ip address 128.213.63.2 255.255.255.252
router bgp 200
network 128.213.0.0
aggregate-address 128.213.0.0 255.255.0.0 summary-only
neighbor 128.213.63.1 remote-as 100
neighbor 128.213.63.1 distribute-list 1 out
neighbor 128.213.63.6 remote-as 400
ip classless
access-list 1 deny
195.211.0.0 0.0.255.255
access-list 1 permit any
En la configuración anterior, se han indicado las redes específicas para ser
anunciadas al AS 100 y se han agregado todas éstas en la dirección 128.213.0.0/16.
Por otra parte, también se ha añadido una lista de acceso para no anunciar a RTA las
redes 195.211.0.0 (pertenecientes al AS 500).
Las configuraciones definitivas de RTD y RTG son las siguientes:
RTD#
hostname RTD
ip subnet-zero
interface Loopback0
ip address 192.208.10.174 255.255.255.192
!
interface Serial0/0
ip address 192.208.10.5 255.255.255.252
!
interface Serial0/1
ip address 192.208.10.2 255.255.255.252
router bgp 300
network 192.208.10.0
neighbor 192.208.10.1 remote-as 500
neighbor 192.208.10.6 remote-as 100
RTG#
hostname RTG
ip subnet-zero
interface Loopback0
ip address 195.211.10.174 255.255.255.192
interface Serial0
ip address 192.208.10.1 255.255.255.252
interface Serial1
ip address 195.211.10.1 255.255.255.252
router bgp 500
network 195.211.10.0
aggregate-address 195.211.0.0 255.255.0.0 summary-only
neighbor 192.208.10.2 remote-as 300
neighbor 192.208.10.2 send-community
neighbor 192.208.10.2 route-map setcommunity out
neighbor 195.211.10.2 remote-as 400
!
ip classless
access-list 1 permit 195.211.0.0 0.0.255.255
access-list 2 permit any
access-list 101 permit ip 195.211.0.0 0.0.255.255 host
255.255.0.0
route-map setcommunity permit 20
match ip address 2
!
route-map setcommunity permit 10
match ip address 1
set community no-export
En la configuración del router RTG se modifica el atributo COMMUNITY de
los anuncios de las rutas 195.211.0.0 anunciadas a RTD con el valor no-export. De
este modo, cuando el router RTD reciba dichas rutas de RTG, éste no las anunciará a
RTB. De todos modos, en la configuración de RTB no se aceptaban ninguna ruta que no
fuese local al AS 300.
A continuación aparece la configuración final del router RTE, en la que se hace
la agregación de las rutas con dirección dentro de 200.200.0.0/16:
RTE#
hostname RTE
ip subnet-zero
interface Loopback0
ip address 200.200.10.1 255.255.255.0
interface Serial0
ip address 195.211.10.2 255.255.255.252
interface Serial1
ip address 128.213.63.6 255.255.255.252
router bgp 400
network 200.200.10.0
aggregate-address 200.200.0.0 255.255.0.0 summary-only
neighbor 128.213.63.5 remote-as 200
neighbor 195.211.10.1 remote-as 500
ip classless
Finalmente, para la configuración final se adjuntan las tablas de encaminamiento
y las tablas BGP de los routers RTA, RTF y RTB:
RTA#show ip bgp
BGP table version is 21, local router ID is 203.250.13.41
Status codes: s suppressed, d damped, h history, * valid, >
best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*> 128.213.0.0
*>i192.208.10.0
*> 200.200.0.0/16
400 i
*> 203.250.13.0
*> 203.250.14.0
*>i203.250.15.0
Next Hop
128.213.63.2
192.208.10.5
128.213.63.2
0.0.0.0
0.0.0.0
203.250.15.2
Metric LocPrf Weight Path
0
200
0 200 i
0
300
0 300 i
200
0 200
0
0
0
100
32768 i
32768 i
0 i
RTA#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile,
B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter
area
E1 - OSPF external type 1, E2 - OSPF external type 2, E EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is 128.213.63.2 to network 200.200.0.0
192.208.10.0 is variably subnetted, 2 subnets, 2 masks
192.208.10.0 255.255.255.0
[110/1000] via 203.250.14.2, 00:41:25, Ethernet0
O
192.208.10.4 255.255.255.252
[110/138] via 203.250.14.2, 00:41:25, Ethernet0
C
203.250.13.0 is directly connected, Loopback0
203.250.15.0 is variably subnetted, 3 subnets, 3 masks
O
203.250.15.10 255.255.255.255
[110/75] via 203.250.14.2, 00:41:25, Ethernet0
O
203.250.15.0 255.255.255.252
[110/74] via 203.250.14.2, 00:41:25, Ethernet0
B
203.250.15.0 255.255.255.0 [200/0] via 203.250.15.2,
00:41:25
C
203.250.14.0 is directly connected, Ethernet0
128.213.0.0 is variably subnetted, 2 subnets, 2 masks
B
128.213.0.0 255.255.0.0 [20/0] via 128.213.63.2,
00:41:26
O E2
C
128.213.63.0 255.255.255.252 is directly connected,
Serial0
B*
200.200.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:02:38
RTF#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile,
B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter
area
E1 - OSPF external type 1, E2 - OSPF external type 2, E EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is 203.250.15.2 to network 0.0.0.0
192.208.10.0 is variably subnetted, 2 subnets, 2 masks
192.208.10.0 255.255.255.0
[110/1000] via 203.250.15.2, 00:48:50, Serial1
O
192.208.10.4 255.255.255.252
[110/128] via 203.250.15.2, 01:12:09, Serial1
203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O
203.250.13.41 255.255.255.255
[110/11] via 203.250.14.1, 01:12:09, Ethernet0
O E2
203.250.13.0 255.255.255.0
[110/2000] via 203.250.14.1, 01:12:09, Ethernet0
203.250.15.0 is variably subnetted, 2 subnets, 2 masks
O
203.250.15.10 255.255.255.255
[110/65] via 203.250.15.2, 01:12:09, Serial1
C
203.250.15.0 255.255.255.252 is directly connected,
Serial1
C
203.250.14.0 is directly connected, Ethernet0
128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2
128.213.0.0 255.255.0.0
[110/2000] via 203.250.14.1, 00:45:01, Ethernet0
O
128.213.63.0 255.255.255.252
[110/74] via 203.250.14.1, 01:12:11, Ethernet0
O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.14.1,
00:03:47,
Ethernet0
O*E2 0.0.0.0 0.0.0.0 [110/1000] via 203.250.15.2, 00:03:33,
Serial1
O E2
En la tabla de encaminamiento anterior se puede comprobar que RTF alcanza las
redes locales del AS 300 (por ejemplo, la red 192.208.10.0) pasando por el router
RTB. El resto de redes externas conocidas (como la red 200.200.0.0, por ejemplo) son
alcnazables por RTF a través de RTA. Por otra parte, la ruta por defecto pasa por RTB,
cambiando a pasar por RTA en caso de fallo del router RTB.
Las tablas BGP y de encaminamiento del router RTB aparece a continuación:
RTB#show ip bgp
BGP table version is 14, local router ID is 203.250.15.10
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric LocPrf Weight Path
*>i128.213.0.0
*> 192.208.10.0
*>i200.200.0.0/16
*>i203.250.13.0
*>i203.250.14.0
*> 203.250.15.0
128.213.63.2
192.208.10.5
128.213.63.2
203.250.13.41
203.250.13.41
0.0.0.0
0
0
0
0
0
200
300
200
100
100
0
0
0
0
0
32768
200 i
300 i
200 400 i
i
i
i
RTB#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * candidate default
Gateway of last resort is 192.208.10.5 to network 192.208.10.0
*
B*
C
192.208.10.0 is variably subnetted, 2 subnets, 2 masks
192.208.10.0 255.255.255.0 [20/0] via 192.208.10.5, 00:50:46
192.208.10.4 255.255.255.252 is directly connected, Serial1
203.250.13.0 is variably subnetted, 2 subnets, 2 masks
O
203.250.13.41 255.255.255.255
[110/75] via 203.250.15.1, 01:20:33, Serial0
O E2
203.250.13.0 255.255.255.0
[110/2000] via 203.250.15.1, 01:15:40, Serial0
203.250.15.0 255.255.255.252 is subnetted, 2 subnets
C
203.250.15.8 is directly connected, Loopback1
C
203.250.15.0 is directly connected, Serial0
O
203.250.14.0 [110/74] via 203.250.15.1, 01:20:33, Serial0
128.213.0.0 is variably subnetted, 2 subnets, 2 masks
O E2
128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:46:55,
Serial0
O
128.213.63.0 255.255.255.252
[110/138] via 203.250.15.1, 01:20:34, Serial0
O E2 200.200.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:05:42,
Serial0