Laboratorio Routing Guadalajara

Laboratorio de routing en
Guadalajara, el día 25 de Mayo de

2002
Alberto Fernández (Lieven)
GuadaWireless.net
lieven@terra.es
Prácticas de routing en laboratorio realizadas en Guadalajara, el 25 de Mayo de 2002, entre

miembros de GuadaWireless, LeganesWireless, RedLibre y MadridWireless. Resultados y
conclusiones.
1. Copyright
v0.1, 13 de Junio de 2002.
Copyright Alberto Fernández y otros. Se otorga permiso para copiar, distribuir y/o modificar este
documento bajo los términos de la Licencia de Documentación Libre GNU, Versión 1.1 o cualquier otra
versión posterior publicada por la Free Software Foundation. Puede consultar una copia de la licencia en:
http://www.gnu.org/copyleft/fdl.html
Conversión a DocBook, Andrés Seco, AndresSH@alamin.org.
Esquemas de David González, divadis@terra.es.
Revisión del texto por
La información y otros contenidos en este documento son lo mejor de nuestros conocimientos. Sin
embargo, hemos podido cometer errores. Así que deberías determinar si deseas seguir las instrucciones
que se encuentran en este documento.
1
Laboratorio de routing en Guadalajara, el día 25 de Mayo de 2002
Nadie es responsable de cualquier daño en sus ordenadores y cualquier otra pérdida por el uso de la
información contenida aquí.
LOS AUTORES, CONTRIBUIDORES Y MANTENEDORES NO SON RESPONSABLES DE

CUALQUIER DAÑO INCURRIDO A CAUSA DE ACCIONES TOMADAS EN BASE A LA
INFORMACIÓN CONTENIDA EN ESTE DOCUMENTO.
Por supuesto, estamos abiertos a todo tipo de sugerencias y correcciones sobre el contenido de este
documento.
2. Introducción
2.1. Objetivos
Este manual es el resultado de la experiencia de los grupos de GuadaWireless, LeganesWireless,

RedLibre, MadridWireless y revisado por dichos integrantes que asistieron a tal evento.
Dicho laboratorio fue realizado en día 25 de Mayo de 2002con la colaboración de los integrantes de
dichos grupos wireless, para experimentar con routing dinámico en redes wireless y bajo nodos con
implementación de sistemas UNIX BSD y GNU/Linux.
El objetivo de este manual no es mas que servir de referencia para otros grupos wireless y punto de salida
para siguientes desarrollos en la red wireless. Con la presente pretendemos que como estos laboratorios,
surjan nuevos laboratorios para experimentar con nuevas tecnologías y mejorar la implantación de la Red
Libre en España.
Con esto queremos animar a los diferentes grupos locales para seguir investigando y documentar nuevas
experiencias y notificarlo a los otros grupos para facilitar su desarrollo.
2.2. Conceptos Generales
El principal objetivo de las comunidades wireless ha sido y esta siendo en estos momentos implementar
una red con un número de nodos elevado, sin sobrecargar mucho las tareas de administración,
mantenimiento y reconfiguración de la red.
Hasta el momento la solución a corto plazo para redes pequeñas ha sido la utilización de routing estático,
y basado por el número de saltos (rutas estáticas, RIP)
Dicha solución no ha sido demostrada como "escalable" dada a su limitación de número de saltos, 15 en
el caso de RIP, de tal forma nuestro backbone se limitaría enormemente en el crecimiento y ampliación.
2
Estas circunstancias han obligado a las comunidades wireless mas ambiciosas a enfocar su atención a
otros protocolos de internetworking dinámicos y basados en el estado de enlace como pueden ser OSPF
(Open Shortest Path First) y BGP Versión 4 (Border Gateway Protocol).
Dichos protocolos vienen con la limitación que es difícil encontrar hardware y software "libre" que lo
soporte, dado a que la solución es ofrecida por multinacionales como Cisco Systems y Juniper Network
que dominan el mercado de " backbones " a nivel mundial.
La solución que se está dando es apoyarse en hardware común, como cualquier PC casero y un software
de routing GNU como puede ser Zebra sobre sistemas GNU/Linux o BSD (OpenBSD, FreeBSD,
NetBSD).
El panorama actual es de máquinas bastante capacitadas para realizar dicho trabajo, no lo suficiente
como una máquina comercial como por ejemplo un Cisco 12000 pero enormente mas económico (20
millones de pesetas menos). Ustedes eligen.
2.3. Breve descripción del laboratorio utilizado
En el laboratorio hemos utilizado el siguiente material:
16 PC
Distribución Debian woody a fecha 23 de Mayo de 2002 (prácticamente estable)
Núcleo Linux 2.4.18 (del paquete Debian kernel-image-2.4.18-586tsc)
Tarjetas Ethernet simulando conexiones WLAN (enlaces punto a punto)
Cables de red (todos cruzados, uniendo PCs)
Paquete de routing para sistemas Linux, BSD "Zebra" www.zebra.org, versión 0.92a del paquete
Dicho laboratorio fue diseñado y cableado por Andrés Seco y alumnos del curso de redes en la Academia
Cervantes de Guadalajara, con material de la propia academia y parte prestado por Caja de Guadalajara.
La implementación de los paquetes de Zebra hemos considerado hacerlos bajo soporte IPV4 teniendo en
consideración el actual direccionamiento de Red Libre www.redlibre.net
2.4. Zebra, instalación y configuración
Podríamos considerar a Zebra como una "suite" de demonios de routing que trabaja bajo sistemas UNIX-
Linux.
Dicho paquete es el recurso para el que no tiene una fortuna para implementar su red con routers
convencionales y bastante mas caros.
3
La página oficial de Zebra es http://www.zebra.org, allí está la guía de referencia de Zebra, desde la cual
también se puede subscribir a la listas de correo de Zebra, donde se divulga los diversos problemas de
configuración, además de los Bug encontrados, etc.
Advertimos a los que se adentren en el tema de routing por primera vez que intenten leer algo de
topologías de redes y conceptos generales de OSPF y BGP4 (en la pagina http://www.cisco.com hay
bastantes manuales sobre el funcionamiento de dichos protocolos de routing).
Los pasos a seguir para la instalación y correcta configuración de Zebra son:
1.- Bajar el paquete de Zebra disponible:
En sistemas BSD:
cd /usr/ports/net/zebra; make install clean
En linux :
* Se puede bajar el archivo directamente desde y compilarlo:
ftp://ftp.zebra.org/pub/zebra/zebra-0.92a.tar.gz
* O bajar directamente el RPM de Internet:
http://rpmfind.net/linux/rpm2html/search.php?query=zebra
* O bajar directamente el DEB en Debian:
apt-get install zebra
2.- Instalar los paquetes y configurar de la siguiente manera:
/etc/zebra
Fichero daemons:
# Daemons are: bgpd zebra ospfd ospf6d ripd ripngd
zebra=yes
bgpd=yes
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
4
y luego
/etc/zebra/zebra.conf
/etc/zebra/ospfd.conf
/etc/zebra/bgpd.conf
y para reiniciarlo:
/etc/init.d/zebra restart
Otros comandos interesantes son:
Para parar el demonio:
/etc/init.d/zebra stop
Para arrancar el demonio:
/etc/init.d/zebra Start
NOTA: En sistemas como el BSD se puede activar directamente los servicios en la ventana de
configuración que nos salta al instalar el paquete.
3.- Arrancar los servicios oportunos:
Nos aseguraremos que los demonios están corriendo en nuestra máquina, el demonio de zebra es vital
que este corriendo para que corran los demás.
GuadaWireless#zebra -d
GuadaWireless#ospfd -d
GuadaWireless#bgpd -d
3. Configuración de la red
En este apartado describiremos las configuraciones de nuestro nodo uno por uno tanto en la configuración
de nuestra conectividad por LAN como de los demonios de routing implementados en el paquete Zebra.
Para la realización de este laboratorio hemos simulado un escenario de 16 nodos basándonos en el

siguiente esquema de red: (ver mapa de red)
5
Figura 1. Esquema general de la red
6
Las direcciones "visibles" en la red wlan son las de clientes wireless y de enlaces. Las redes "internas" de
cada nodo son "privadas" no visibles para routing.
Direcciones de redes de cada nodo:
192.168.0.0/16> "privadas" no visibles en la red wireless. En este rango de direccionamiento hemos

usado 192.168.numero_de_nodo.1 para cada nodo.
10.0.0.0/8 clientes wireless, utilizables para el routing. En este rango de direccionamiento hemos usado
10.zona.nodo.1 para cada nodo
172.16.0.0/30 enlaces internos entre nodos. Utilizables para routing
172.17.0.0/30 usamos 172.15+zona.nodo.1 y 2 (nodo menor) y 172.15.zona_nodo+10.1 y 2 si hay dos

enlaces.
172.18.0.0/30
172.20.1.0/30 enlace externo entre W1 y W2, para BGP, utilizable para routing.
172.21.1.0/30 enlace externo entre W2 y W3, para BGP, utilizable para routing.
Las interfaces de clientes wireless son dummy0. Las interfaces de redes privadas internas de cada nodo
son dummy1. Los interfaces de enlaces son eth0, eth1 y eth2.
ZONA W1:
Redes de clientes wireless:
Nodo n04 10.1.41/27 nodo wlan

10.1.4.2 a 30 clientes wlan
Nodo n05 10.1.5.1/27 nodo wlan
7
Enlaces:
n04 a n05 : 172.16.4.1 y 172.16.4.2 respectivamente /30

ZONA W2:
n01, 10.2.1.1/27 nodo wlan

n02, 10.2.2.1/27 nodo wlan
n03, 10.2.3.1/27 nodo wlan
n16, 10.2.16.1/27 nodo wlan
Enlaces:
n01-n02 172.17.1.1 y 172.17.1.2 /30

n02-n03 172.17.2.1 y 172.17.2.2 /30
n02-n16 172.17.12.1 y 172.17.12.2 /30
ZONA W3:
n10, 10.3.10.1/27 nodo wlan

n11, 10.3.11.1/27 nodo wlan
n12, 10.3.12.1/27 nodo wlan
n13, 10.3.13.1/27 nodo wlan
n14, 10.3.14.1/27 nodo wlan
n15, 10.3.15.1/27 nodo wlan
Enlaces :
n10-n11 172.18.10.1 y 2 /30

n11-n13 172.18.11.1 y 2 /30
n12-n13 172.18.12.1 y 2 /30
n13-n15 172.18.13.1 y 2 /30
n14-n15 172.18.14.1 y 2 /30
8
ENLACES INTERZONA W1-W2-W3:
n03-n05 172.20.1.1 y 2, /30

n03-n15 172.21.1.1 y 2 /30
3.1. Configuración de direccionamiento ethernet
Vamos a describir las tarjetas ethernet utilizadas en cada nodo por ifconfig:
Aquí hemos configurado unos interfaces virtuales denominados dummy0 y dummy1 con
comportamiento igual que a un interfaz físico, hemos considerado en el laboratorio de routing poner
estos interfaces en passive ya que no nos interesa que se negocie acuerdos por OSPF con estos interfaces,
de hecho los clientes no van a tener configurado OSPF, así también evitamos posibles ataques al simular
pertenecer cualquier cliente al área 0 de OSPF.
Hay nodos que debido a la topología utilizada necesitan mas direcciones Ethernet, un claro ejemplo del
nodo
NODO 01:
dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00

inet addr:10.2.1.1 Bcast:10.2.1.31 Mask:255.255.255.224
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:1416 (1.3 KiB)

RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth1 Link encap:Ethernet HWaddr 00:4F:49:04:DC:CC

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX bytes:205813 (200.9 KiB) TX bytes:763365 (745.4 KiB)
Interrupt:12 Base address:0xe400
lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0
9
UP LOOPBACK RUNNING MTU:16436 Metric:1

NODO 02:


eth0 Link encap:Ethernet HWaddr 00:05:1C:03:97:95

Interrupt:10 Base address:0x2000
eth1 Link encap:Ethernet HWaddr 00:05:1C:02:2B:1A

eth2 Link encap:Ethernet HWaddr 00:4F:49:05:32:43

Interrupt:14 Base address:0xdc00

inet addr:127.0.0.1 Mask:255.0.0.0
10

NODO 03:


eth0 Link encap:Ethernet HWaddr 00:05:1C:02:C2:C2

Interrupt:10
eth1 Link encap:Ethernet HWaddr 00:4F:49:04:F6:6A

eth2 Link encap:Ethernet HWaddr 00:4F:49:04:DC:C0


inet addr:127.0.0.1 Mask:255.0.0.0
11

NODO 04:


eth0 Link encap:Ethernet HWaddr 00:05:1C:02:E0:6D

Interrupt:11

inet addr:127.0.0.1 Mask:255.0.0.0
NODO 05:


12

eth0 Link encap:Ethernet HWaddr 00:05:1C:02:B2:13

Interrupt:10
eth1 Link encap:Ethernet HWaddr 00:4F:49:08:99:B3

eth2 Link encap:Ethernet HWaddr 00:A0:24:7E:3D:4E


inet addr:127.0.0.1 Mask:255.0.0.0
NODO 06:


13

eth0 Link encap:Ethernet HWaddr 00:05:1C:02:EF:EB

Interrupt:10
eth1 Link encap:Ethernet HWaddr 52:54:00:DF:57:66


inet addr:127.0.0.1 Mask:255.0.0.0
NODO 07:


eth0 Link encap:Ethernet HWaddr 00:05:1C:03:57:87

14

Interrupt:14
eth1 Link encap:Ethernet HWaddr 00:4F:49:06:F7:E9

eth2 Link encap:Ethernet HWaddr 00:20:AF:F7:32:07


inet addr:127.0.0.1 Mask:255.0.0.0
NODO 08:


eth0 Link encap:Ethernet HWaddr 00:05:1C:08:5A:E7

15

Interrupt:11

inet addr:127.0.0.1 Mask:255.0.0.0
NODO 09:


eth0 Link encap:Ethernet HWaddr 00:05:1C:00:3D:E0

Interrupt:11

inet addr:127.0.0.1 Mask:255.0.0.0
NODO 10:

16


eth0 Link encap:Ethernet HWaddr 00:05:1C:02:45:DF

Interrupt:11

inet addr:127.0.0.1 Mask:255.0.0.0
NODO 11:


eth0 Link encap:Ethernet HWaddr 00:05:1C:08:14:C2

17

Interrupt:10
eth1 Link encap:Ethernet HWaddr 00:4F:49:08:B4:55


inet addr:127.0.0.1 Mask:255.0.0.0
NODO 12:


eth0 Link encap:Ethernet HWaddr 00:05:1C:03:9B:A8


inet addr:127.0.0.1 Mask:255.0.0.0
18

NODO 13:


eth0 Link encap:Ethernet HWaddr 00:05:1C:02:61:E2

Interrupt:14
eth1 Link encap:Ethernet HWaddr 00:4F:49:04:A7:2D

eth2 Link encap:Ethernet HWaddr 00:A0:24:53:DC:20


inet addr:127.0.0.1 Mask:255.0.0.0
19

NODO 14:


eth0 Link encap:Ethernet HWaddr 00:05:1C:04:9C:BF

Interrupt:10

inet addr:127.0.0.1 Mask:255.0.0.0
NODO 15:


20

eth0 Link encap:Ethernet HWaddr 00:05:1C:00:9D:3F

Interrupt:10
eth1 Link encap:Ethernet HWaddr 52:54:00:DF:52:6A

eth2 Link encap:Ethernet HWaddr 00:20:AF:F7:32:1E


inet addr:127.0.0.1 Mask:255.0.0.0
RX bytes:2525117 (2.4 MiB) TX bytes:2525117 (2.4 MiB)
NODO 16:


21

eth0 Link encap:Ethernet HWaddr 00:05:1C:08:7D:C1

Interrupt:10

inet addr:127.0.0.1 Mask:255.0.0.0
3.2. Configuración de Zebra en el laboratorio
Según pudimos descubrir la configuración del direccionamiento de interfaces no era imprescindible en la

configuración del demonio de Zebra, ya que este direccionamiento era conocido a través del
direccionamiento aprendido por el kernel de la máquina en cuestión.
Adjuntamos la configuración de cada uno de los equipos del laboratorio en cuanto al demonio de Zebra
se refiere:
NOTA: las admiraciones al principio de las lineas son la forma de indicar comentarios en los
NODO N01:
!
! Zebra configuration saved from vty
! 2002/05/25 15:47:47
!
hostname n01-zebra
password zebra
enable password zebra
log file /var/log/zebra/zebra.log
!
interface lo
!
interface eth0
!
interface dummy0
!
22
interface eth1
!
interface dummy1
!
line vty
!
NODO N02:
! -*- zebra -*-

!
! zebra sample configuration file
!
! $Id: zebra.conf.sample,v 1.14 1999/02/19 17:26:38 developer Exp $
!
hostname n02-zebra
password zebra
!
! Interface’s description.
!
!interface lo
! description test of desc.
!
!interface sit0
! multicast
!
! Static default route sample.
!
!ip route 0.0.0.0/0 203.181.89.241
!
!log file zebra.log

NODO N03:
! -*- zebra -*-

!
!
!
hostname n03-zebra
password zebra
!
! Interface’s description.
!
!interface lo
23
! description test of desc.

!
!interface sit0
! multicast
interface dummy0
description client network 10.2.3.0/?
interface dummy1
description private network 192.168.0.0/?
interface eth0
description red 172.20.2.0/30
interface eth1
interface eth2
!
! Static default route sample.
!
!ip route 0.0.0.0/0 203.181.89.241
!
!log file zebra.log

NODO 04:
!
! 2002/05/25 14:55:58
!
hostname n04-zebra
password zebra
!
interface lo
!
interface eth0
!
interface dummy0
!
interface dummy1
!
line vty
!
NODO 05:
24
!
! 2002/05/25 15:07:56
!
hostname n05-zebra
password zebra
!
interface lo
!
interface eth0
!
interface eth1
!
interface dummy0
!
interface eth2
!
interface dummy1
!
line vty
!
NODO 06:
!
! 2002/05/25 12:52:53
!
hostname n06-zebra
password zebra
!
interface lo
!
interface eth0
!
interface dummy0
!
interface eth1
!
interface dummy1
!
line vty
!
NODO 07:
!
! 2002/05/25 13:00:14
!
25
hostname n07-zebra
password zebra
!
interface lo
!
interface eth0
!
interface dummy0
!
interface eth1
!
interface eth2
!
interface dummy1
!
line vty
!
NODO 08:
!
! 2002/05/25 12:50:52
!
hostname n08-zebra
password zebra
!
interface lo
!
interface eth0
!
interface dummy0
!
interface dummy1
!
line vty
!
NODO 09:
! -*- zebra -*-

!
!
!
hostname n09-zebra
password zebra
interface dummy0
interface dummy1
26
interface eth0
!log file zebra.log

NODO 10:
!
! 2002/05/25 12:39:26
!
hostname n10-zebra
password zebra
!
interface lo
!
interface eth0
!
interface dummy0
!
interface dummy1
!
line vty
!
NODO 11:
!
! 2002/05/25 12:29:07
!
hostname n11-zebra
password zebra
!
interface lo
!
interface eth0
!
interface dummy0
!
interface eth1
!
interface dummy1
!
line vty
!
NODO 12:
27
!
! 2002/05/25 13:42:39
!
hostname n12-zebra
password zebra
!
interface lo
!
interface dummy0
!
interface eth0
!
interface dummy1
!
line vty
!
NODO 13:
!
! 2002/05/25 12:49:17
!
hostname n13-zebra
password zebra
!
interface lo
!
interface eth0
!
interface dummy0
!
interface eth1
!
interface eth2
!
interface dummy1
!
line vty
!
NODO 14:
!
! 2002/05/25 12:54:42
!
hostname n14-zebra
password zebra
28
!
interface lo
!
interface eth0
!
interface dummy0
!
interface dummy1
!
line vty
!
NODO 15:
!
! 2002/05/25 12:54:48
!
hostname n15-zebra
password zebra
!
interface lo
!
interface eth0
!
interface eth1
!
interface dummy0
!
interface eth2
!
interface dummy1
!
line vty
!
NODO 16:
!
! 2002/05/25 11:42:16
!
hostname nodo16zebra
password zebra
!
interface lo
!
interface eth0
ip address 172.17.12.2/30
!
29
interface dummy0
!
interface eth1
!
interface dummy1
!
line vty
!
Como se puede comprobar no todos los demonios de los ordenadores del laboratorio tenían el
direccionamiento metido en la configuración de Zebra, no obstante corrían igual. Este direccionamiento
era aprendido por Zebra a través del Kernel del sistema.
3.3. Configuración de OSPF en el laboratorio
En este apartado nos surgieron diversas dudas sobre todo en el direccionamiento entre áreas W1-W2-W3,
ya que no conseguíamos llegar a la zona W2 desde cualquier de las zonas restantes en cambio entre
clientes de W1 a clientes de W3 si llegábamos. Lo que nos hizo suponer que al poner en passive
interfaces los enlaces entre áreas no conocíamos el direccionamiento Ethernet entre áreas. Se solucionó
poniendo un network a la red que englobaba la conexión entre áreas y conservando el passive-interface.
NODO 01:
!
! 2002/05/25 12:52:05
!
hostname n01-ospf
password zebra
log file /var/log/zebra/ospfd.log
!
!
!
interface lo
!
interface eth0
!
interface dummy0
!
interface eth1
!
interface dummy1
!
router ospf
passive-interface dummy0
network 10.2.1.0/27 area 0
network 172.17.1.0/30 area 0
area 0 range 10.2.0.0/16
area 0 range 172.17.0.0/16
30
!
line vty
!
NODO 02:
!
! 2002/05/25 11:42:50
!
hostname n02-ospf
password zebra
!
!
!
interface lo
!
interface dummy0
!
interface eth0
!
interface eth1
!
interface eth2
!
interface dummy1
!
router ospf
network 172.17.1.0/30 area 0
network 172.17.2.0/30 area 0
network 172.17.12.0/30 area 0
area 0 range 10.2.0.0/16
area 0 range 172.17.0.0/16
!
line vty
!
NODO 03:
!
! 2002/05/25 16:26:58
!
hostname n03-ospf
password zebra
!
!
31
!
interface eth0
description interface 172.17.2.0/30 (enlazado con W2-n02)
!
interface eth1
!
interface eth2
!
interface dummy0
description client interface (no publicar
!
interface dummy1
description private interface
!
interface lo
!
router ospf
redistribuye bgp
passive-interface eth1
network 172.17.2.0/30 area 0
network 172.20.1.0/30 area 0
network 172.21.1.0/30 area 0
area 0 range 10.2.0.0/16
area 0 range 172.17.0.0/16
area 0 range 172.20.1.0/30
area 0 range 172.21.1.0/30
!
line vty
!
NODO 04:
!
! 2002/05/25 14:58:07
!
hostname n04-ospfd
password zebra
!
!
!
interface lo
!
interface eth0
!
interface dummy0
32
!
interface dummy1
!
router ospf
network 172.16.4.0/30 area 0
area 0 range 10.1.0.0/16
area 0 range 172.16.0.0/16
!
line vty
!
NODO 05:
!
! 2002/05/25 16:21:43
!
hostname n05-ospfd
password zebra
!
!
!
interface lo
!
interface eth0
!
interface eth1
!
interface dummy0
!
interface eth2
!
interface dummy1
!
router ospf
redistribute bgp
network 172.16.4.0/30 area 0
network 172.16.5.0/30 area 0
network 172.20.1.2/32 area 0
area 0 range 10.1.0.0/16
area 0 range 172.16.0.0/16
area 0 range 172.20.1.2/32
!
line vty
!
33
NODO 06:
!
! 2002/05/25 12:57:17
!
hostname n06-ospf
password zebra
!
!
!
interface lo
!
interface eth0
!
interface dummy0
!
interface eth1
!
interface dummy1
!
router ospf
network 172.16.6.0/30 area 0
network 172.16.16.0/30 area 0
area 0 range 10.1.0.0/16
area 0 range 172.16.0.0/16
!
line vty
!
NODO 07:
!
! 2002/05/25 13:03:27
!
hostname n07-ospf
password zebra
!
interface eth0
!
interface dummy0
!
interface eth1
!
interface eth2
!
34
interface dummy1
!
router ospf
network 172.16.5.0/30 area 0
network 172.16.6.0/30 area 0
network 172.16.7.0/30 area 0
area 0 range 10.1.0.0/16
area 0 range 172.16.0.0/16
!
line vty
!
NODO 08:
!
! 2002/05/25 13:36:35
!
hostname n08-ospf
password zebra
!
!
!
interface lo
!
interface eth0
!
interface dummy0
!
interface dummy1
!
router ospf
network 172.16.16.0/30 area 0
area 0 range 10.1.0.0/16
area 0 range 172.16.0.0/16
!
line vty
!
NODO 09:
!
! 2002/05/25 12:03:41
!
hostname n09-ospf
35
password zebra
!
debug ospf event
!
interface dummy0
!
interface eth0
!
router ospf
network 172.16.7.0/30 area 0
area 0 range 10.1.0.0/16
area 0 range 172.16.0.0/16
!
line vty
!
NODO 10:
!
! 2002/05/25 13:20:04
!
hostname n10-ospf
password zebra
!
!
!
interface lo
!
interface eth0
!
interface dummy0
!
interface dummy1
!
router ospf
network 172.18.10.0/30 area 0
area 0 range 10.3.0.0/16
area 0 range 172.18.0.0/16
!
line vty
!
NODO 11:
36

! 2002/05/25 13:16:37
!
hostname n11-ospf
password zebra
!
!
!
interface lo
!
interface eth0
!
interface dummy0
!
interface eth1
!
interface dummy1
!
router ospf
network 172.18.10.0/30 area 0
network 172.18.11.0/30 area 0
area 0 range 10.3.0.0/16
area 0 range 172.18.0.0/16
!
line vty
!
NODO 12:
!
! 2002/05/25 13:43:51
!
hostname n12-ospf
password zebra
!
!
!
interface lo
!
interface dummy0
!
interface eth0
!
interface dummy1
!
router ospf
37
network 172.18.12.0/30 area 0
area 0 range 10.3.0.0/16
area 0 range 172.18.0.0/16
!
line vty
!
NODO 13:
!
! 2002/05/25 12:57:32
!
hostname n13-ospfd
password zebra
!
!
!
interface lo
!
interface eth0
!
interface dummy0
!
interface eth1
!
interface eth2
!
interface dummy1
!
router ospf
network 172.18.11.0/30 area 0
network 172.18.12.0/30 area 0
network 172.18.13.0/30 area 0
area 0 range 10.3.0.0/16
area 0 range 172.18.0.0/16
!
line vty
!
NODO 14:
!
! 2002/05/25 12:57:06
!
hostname n14-ospfd
38
password zebra
!
!
!
interface lo
!
interface eth0
!
interface dummy0
!
interface dummy1
!
router ospf
network 172.18.14.0/30 area 0
!
line vty
!
NODO 15:
!
! 2002/05/25 16:23:35
!
hostname n15-ospfd
password zebra
!
!
!
interface eth0
description interface 172.18.14.0/30 (nodo 13)
!
interface eth1
description interface 172.18.13.0/30 (nodo 14)
!
interface eth2
description interface 172.21.1.0/30 (enlace con n03 (W2)
!
interface dummy0
description client interface
!
interface dummy1
description client interface
!
interface lo
!
router ospf
redistribute bgp
39
network 172.18.13.0/30 area 0
network 172.18.14.0/30 area 0
network 172.21.1.2/32 area 0
!
line vty
!
NODO 16:
!
! 2002/05/25 12:55:22
!
hostname ospfd
password zebra
!
!
!
interface dummy0
!
interface eth0
!
interface lo
!
interface eth1
!
interface dummy1
!
router ospf
network 172.17.12.0/30 area 0
area 0 range 10.2.0.0/16
area 0 range 172.17.0.0/16
!
line vty
!
3.4. Configuración de BGP en el laboratorio
Las intenciones en el LAB eran de solo configurar un router BGP por area, así de esta forma hemos
considerado que solo tendrían implementado el protocolo BGP los nodos N05, N03 y N15.
40
El BGP ID se ha creado oportuno de momento considerar el direccionamiento Ethernet, pero a largo

plazo no es una solución escalable así que se mirará la posibilidad de incorporar interfaces lógicas al
routing con Zebra para implementar balanceo de cargas por BGP.
Esta es la relación de nodos con Sistemas Autónomos configurados:
N05= AS 1
N03= AS 2
N15= AS 3
El BGP solo está configurado en dichos nodos ya que no se ha visto necesario la configuración de un full
mesh BGP con iBGP por cada sistema autónomo ya que la red no es lo suficientemente grande. En caso
de que la red crezca se podrá replantear la posibilidad de establecer sesiones iBGP entre todos los
integrantes de un mismo Area.
Otra de las posibilidades para siguientes LAB es eliminar de la configuración de los router bordes las
opciones de redistribute connected y redistribute ospf, ya que según hemos observado en otras
implementaciones de routing BGP no haría falta de inyectar las rutas manualmente.
NODO 05:
!
! 2002/05/25 16:13:27
!
hostname n05-bgp
password zebra
log file /var/log/zebra/bgpd.log
!
router bgp 1
bgp router-id 172.20.1.2
redistribute connected
redistribute ospf
neighbor 172.20.1.1 remote-as 2
neighbor 172.20.1.1 ebgp-multihop 255
!
line vty
!
NODO 03:
Tendrá dos sesiones eBGP establecidas contra el nodo 5 y el nodo 15 con direccionamiento 172
!
41
! 2002/05/25 16:20:36
!
hostname bgpd
password zebra
!
router bgp 2
redistribute ospf
!
line vty
!
NODO 15:
El nodo 15 es el perteneciente al AS 3 y tendrá sesión eBGP contra el nodo 3 que pertenece a
!
! 2002/05/25 16:15:20
!
hostname n15-bgp
password zebra
!
router bgp 3
redistribute ospf
!
line vty
!
3.5. Solución de problemas en el laboratorio, comando útiles
En este apartado vamos a comentar los diferentes comandos útiles para un correcto diagnóstico de la red,
y realizar resolución de problemas apoyándonos en los comandos básicos de Linux y Zebra.
42
3.5.1. Comandos en Linux
Reiniciar zebra: /etc/init.d/zebra restart
Ver los logs en tiempo real: tail -f /var/log/zebra/*.log
3.5.2. Comandos en Zebra
NOTA: Para realizar este apartado nos hemos basado en los comandos de salida de un Cisco 12012/GRP
(R5000). Comandos que prácticamente no deben variar al ser utilizados en Zebra.
Los datos plasmados en este manual son aleatorios, cualquier coincidencia con datos de empresas
afectadas es pura coincidencia.
COMO CONOCER LAS REDES QUE SABEMOS POR BGP:
B> - nos indica que es aprendida por BGP.
/24 - la mascara de red.
[200/200] - términos de métricas de redes.
vía - a través de quien conocemos la red.
3w4d - desde cuando la conocemos.
zebra-bgp>show ip route bgp

B xxx.xxx.xxx.xxx/24 [200/200] via xxx,xxx,xxx,xxx 3w4d
B xxx.xxx.xxx.xxx/24 [200/200] via xxx.xxx.xxx.xxx, 1w3d
B xxx.xxx.xxx.xxx/24 [200/200] via 192.168.0.1, 1w3d
B xxx.xxx.xxx.xxx/24 [200/50] via 192.168.0.5, 19:59:41
COMO SABER LOS VECINOS BGP CONFIGURADOS Y SU ESTADO ACTUAL:
zebra-bgp>show ip bgp summary

BGP router identifier xxx.xxx.xxx.xxx, local AS number XXXXX
BGP table version is 394523949, main routing table version 394523949
126358 network entries and 644473 paths using 35584112 bytes of memory
71823 BGP path attribute entries using 4027072 bytes of memory
53 BGP rrinfo entries using 1272 bytes of memory
38825 BGP AS-PATH entries using 987022 bytes of memory
1067 BGP community entries using 57186 bytes of memory
18624 BGP route-map cache entries using 297984 bytes of memory
43
35570 BGP filter-list cache entries using 426840 bytes of memory

Dampening enabled. 75 history paths, 8 dampened paths
1 received paths for inbound soft reconfiguration
BGP activity 417007/33881310 prefixes, 29096388/28451915 paths, scan interval 15 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

xxx.xxx.xxx.xxx 4 6535 5716468 153119 394523906 0 0 11w3d 109177
xxx.xxx.xxx.xxx 4 6535 404635 18986 0 0 0 10w5d Idle (Admin)
xxx.xxx.xxx.xxx 4 4543 112460 1737689 394523912 0 0 4d03h 14
xxx.xxx.xxx.xxx 4 4543 72755973 5052446 394523912 0 0 11w1d 121188
xxx.xxx.xxx.xxx 4 4543 74571913 5035364 394523912 0 0 11w1d 121186
COMO SABER LAS RUTAS ACEPTADAS Y APRENDIDAS A TRAVÉS DE UN VECINO BGP:
zebra-bgp>show ip bgp neighbors xxx.xxx.xxx.xxx routes

BGP table version is 394526830, local router ID is xxx.xxx.xxx.xxx
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

* 3.0.0.0 192.168.0.1 80 0 4563 2323 8 i
*> 4.0.0.0 192.168.0.1 80 0 4563 1 i
COMO SABER LAS RUTAS ANUNCIADAS A UN VECINO BGP:
ZEBRA-BGP>show ip bgp neighbors xxx.xxx.xxx.xxx advertised-routes

BGP table version is 394528289, local router ID is xxx.xxx.xxx.xxx
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

*>4.0.0.0/18 192.168.0.1100 100 0 4926 10718 10718 10718 10718 10718 i
COMO CONOCEMOS UNA RED:
zebra>show ip route 10.10.10.10

Routing entry for 10.10.10.10/8
Known via "bgp 10121", distance 200, metric 50
Tag 3352, precedence priority (1), type internal
Last update from 192.168.0.1 3d04h ago
Routing Descriptor Blocks:
*10.10.10.10, from192.168.0.1, 3d04h ago
Route metric is 50, traffic share count is 1
AS Hops 1, BGP network version 0
44
4. Conclusiones
4.1. Resultado del laboratorio
Según observamos con pruebas de conectividad y de routing, las redes de cada uno de los sistemas
autónomos eran visibles entre ellos y sabián llegar los paquetes ICMP correctamente.
Los anuncios eBGP se realizaban según lo esperado y las sesiones BGP en todo momento permanecieron
establecidas, anunciando a los diferentes vecinos BGP las rutas aprendidas por OSPF y por kernel.
La sobre carga de memoria no fue un impedimento en el laboratorio, para desmentir rumores de

ocupación alta de procesos en las máquinas que corren Zebra, no obstante hemos trabajado en un
escenario relativamente pequeño con un numero de prefijos de red limitado, 40.
4.1.1. Dificultades encontradas en la realización del laboratorio
La redistribución en BGP harria que limitarla en las configuraciones, ya que debido a ciertos problemas
de anuncios de redes del sistema autónomo W2 nos vimos limitados a utilizarlas. No obstante se podrían
prescindir de dichas configuraciones en próximos laboratorios.
4.2. Propuestas para un nuevo laboratorio
Al finalizar el laboratorio de routing del día 25 de mayo, el principal éxito de esta reunión es que
diferentes grupos como Leganés Wireless (http://www.leganeswireless.net), Red Libre
(http://www.redlibre.net), Madrid Wireless (http://www.madridwireless.net) y Guada Wireless
(http://www.guadawireless.net) han encontrado el punto de salida para lo que puede ser una red global en
cuanto a comunicación sin cables se refiere.
Las diferentes propuestas surgidas a raíz del evento han sido las siguientes:
Encontrar la forma de reunirse de forma esporádica los grupos locales wireless. Ya que de esta forma se
adelantan años luz de trabajos conjuntos en relación con la comunicación mediante listas de correo.
Posibilidad de exprimir el potencial de Zebra como paquete de routing, ya sea por aplicación de
comunidades, QoS, RSVP, filtrado, métricas, etc.
Realización de balanceo de carga por eBGP y la posibilidad de utilización de interfaces virtuales en

routing para la correcta realización de este punto.
45
5. Agradecimientos
Ante todo queremos agradecer al entusiasmo y colaboración por cada uno de los integrantes que
acudieron al Laboratorio de Routing del 25 de Mayo en Guadalajara. No recordamos todos los nombres,
pero entre ellos, Simon J. Mudd, Luis Romeral, Alberto Fernández, Jorge Ortiz, Andrés Seco, y otros
muchos.
A la Academia Cervantes de Guadalajara por ofrecer sus medios para la realización de este evento y a
Caja de Guadalajara por el equipamiento de red extra que utilizamos para la instalación de la maqueta.
A los grupos locales GuadaWireless, LeganesWireless, MadridWireless y RedLibre.
Al equipo de coordinación de RedLibre por hacer que RedLibre trate de ser un punto de encuentro y
coordinación de esfuerzos entre diferentes grupos wireless.
A los canales IRC del irc-hispano: #guadawireless, #redlibre, #wireless.
A todos los grupos locales por formar parte de esta experiencia inalámbrica y aportar las suyas propias
para desarrollar un proyecto que cada vez esta más cerca: Una Red Libre para todos.
A todos, gracias.
6. Diccionario
Zebra
Paquete de software de routing en el cual estamos apoyándonos la mayoría de los grupos wireless, consta
de una serie de demonios de los cuales los principales son: zebra bgpd ospfd ripd
http://www.zebra.org
Ethernet
Ethernet es la capa física más popular la tecnología LAN usada actualmente. Otros tipos de LAN
incluyen Token Ring, Fast Ethernet, FDDI, ATM y LocalTalk. Ethernet es popular porque permite un
buen equilibrio entre velocidad, costo y facilidad de instalación. Estos puntos fuertes, combinados con la
amplia aceptación en el mercado y la habilidad de soportar virtualmente todos los protocolos de red
populares, hacen a Ethernet la tecnología ideal para la red de la mayoría los usuarios de la informática
actual. La norma de Ethernet fue definida por el Instituto para los Ingenieros Eléctricos y Electrónicos
46
(IEEE) como IEEE Standard 802.3. Adhiriéndose a la norma de IEEE, los equipo y protocolos de red
pueden interoperar eficazmente.
Punto de acceso:
Dispositivo que transporta datos entre una red inalámbrica y una red cableada (infraestructura).
IEEE802.X:
Conjunto de especificaciones de la redes LAN dictadas por el IEEE (the Institute of Electrical and
Electronic Engineers). La mayor parte de las redes cableadas cumplen la norma 802.3, especificación
para las redes ethernet basadas en CSMA/CD, o la norma 802.5, especificación para las redes Token
Ring. Existe un comité 802.11 trabajando en una normativa para redes inalámbricas de 1 y 2 Mbps. La
norma tendrá una única capa MAC para las siguientes tecnologías: Frequency Hopping Spread Spectrum
(FHSS), Direct Sequence Spread Spectrum (DSSS) e infrarrojos. Se están desarrolando borradores de las
normas.
Red independiente:
Red que proporciona (normalmente temporalmente) conectividad de igual a igual sin depender de una
infraestructura completa de red.
Infraestructura de red:
Red inalámbrica centrada en un punto de acceso. En este entorno los puntos de acceso no solo
proporcionan comunicación con la red cableada sino que también median el tráfico de red en la vecindad
inmediata.
Microcélula:
El espacio físico en el que un número de dispositivos de redes inalámbricas pueden comunicarse. Puesto
que es posible tener células solapándose así como células aisladas los saltos entre células están
establecidos por alguna regla.
Multipath:
La variación de la señal causada cuando las señales de radio toman varios caminos desde el transmisor al
receptor.
Términos de radio frecuencia: GHz, MHz, Hz.
47
La unidad internacional de medida de frecuencia es el Hertzio (Hz) el cual es equivalente a la unidad

antigua de ciclos pos segundo. Un MHz es un millón de Hertzios y un GHz son mil MHz (mil millones
de Hz). Como referencia: La frecuencia eléctrica utilizada en Europa son 50 Hz y en EEUU son 60 Hz.
La banda de frecuencia de radiodifusión AM es 0.55 - 1.6 MHz. La banda de frecuencia de radiodifusión
FM es 88 - 108 MHz. Los hornos microondas típicamente operan a 2.45 GHz.
Roaming:
Movimiento de un nodo inalámbrico entre dos microcélulas. Roaming se da normalmente en

infraestructuras de redes construidas con varios puntos de acceso.
Nodo inalámbrico:
Ordenador de usuario con una tarjeta de red inalámbrica (adaptador).
Rutas dinámicas y protocolos de enrutamiento:
El enrutamiento dinámico se basa en un protocolo de enrutamiento que distribuye la información sobre

las diferentes rutas.
Dicho protocolo define las reglas que rigen la comunicación entre un router y sus vecinos: que se manda,
cuando se manda, etc. Algunos protocolos de enrutamiento típicos son:
RIP (routing information protocol)
IGRP ( interior gateway routing protocol)
OSPF (open shortest path first )
Estos son los protocolos típicos, y que veremos más adelante, que se utilizan para intercambiar
información dentro de un mismo sistema autónomo, esto es, un conjunto de redes bajo el mismo dominio
administrativo. Para enrutar entre distintos sistemas autonomos, existen otro tipo de protocolos, mas
complejos, llamados EGPs (Exterior Gateway Protocols), siendo el mas conocido el BGP (Border
Gateway Protocol).
La distancia administrativa es una medida de nivel de confianza de la fuente de una ruta. Según una ruta
haya sido aprendida de una fuente u otra, tendrá una valor diferente. Cuando menor sea el valor, mayor
confianza se tendrá en esa ruta, y por tanto, mayor probabilidad tendrá de ser usada. Así, para un
determinado destino, el router almacenará en la Tabla de Enrutamiento aquella ruta cuya distancia
administrativa sea menor. Los valores de distancia administrativa varían entre 0 y 255. Si estamos
48
conectados directamente a una maquina, la distancia administrativa será 0, mientras que si la ruta ha sido
aprendida mediante el protocolo IGRP por ejemplo, la distancia administrativa valdrá 100.
Protocolos de Enrutamiento de Tipo Vector-Distancia:
Dentro de los algoritmos IGP (para enrutar dentro de un mismo sistema autonomo ) podemos encontrar 3
calificaciones:
Vector distancia. Funcionan determinando la direccion (vector) y la distancia a cualquier enlace de la red.
Estado de enlaces. Tratan de recrear la topología exacta de la red (o de la zona mas cercana al router)
Hibridos. Combinan aspectos de los dos tipos anteriores.
A continuación vamos a ver mas en detalle el funcionamiento de los protocolos vector-distancia (también
llamados de Bellman-Ford). Estos protocolos se basan en intercambiar preiodicamente las tablas de
enrutamiento entre routers vecinos. Cuando a un router le llega la tabla de un vecino, añade su distancia a
su vector de distancia correspondiente, y la pasa a su vecino, que a su vez hará lo mismo. De esta forma,
se acumulan las distancias en la red a los destinos que no están directamente conectados a un router.
Las métricas que se utilizan para la distancia, varian de un sistema a otro. Las más importantes, y que se
utilizan solas o de manera combinada, son: número de saltos (el número de veces que un paquete
atraviesa un router), ticks (55 milisegundos), ancho de banda (valor de la capacidad de un enlace).
Cada cierto tiempo, los routers se envian actualizaciones de sus rutas. Cuando un router recibe
informacion sobre una ruta, añade su distancia (según la metrica utilizada) y si la ruta resultante es
mejor, actualiza su tabla de enrutamiento.
Protocolos de enrutamiento de tipo de estado de enlaces e híbridos
Los protocolos de estado de enlaces tambien se conocen como "primero el salto más corto" (shortest path
first). Estos protocolos utilizan paquetes de estado de enlaces (Link-State Packets ) para intercambiar
información. Mantienen una base de datos capaz de almacenar la topología de la red, un árbol SPF, y una
tabla de enrutamiento con rutas y puertos a cada red. Estos protocolos son muy útiles a medida que las
redes aumentan de tamaño, ya que sólo mandan actualizaciones cuando hay un cambio en la topología, y
estas se producen cada más tiempo que en los protocolos de tipo vector-distancia. Además, pueden
segmentarse, limitándose sólo a determinadas áreas.
Los protocolos híbridos usan vectores de distancia para determinar las mejores rutas a los destinos, pero,
en vez de enviar actualizaciones en determinados periodos de tiempo (como los protocolos
vector-distancia), lo hacen sólo cuando hay cabios en la topología. Las métricas utilizadas son más
49
exactas que en los protocolos vector-distancia, y los recursos de memoria, ancho de banda y
procesamiento son menores que los de los protocolos de estado de enlaces.
Como configurar los protocolos de enrutamiento dinamico
En primer lugar hay que seleccionar el protocolo de enrutamiento a utilizar. Desde el Modo de
configuración Global, teclearemos : router {protocolo}. Por ejemplo : router rip, para establecer RIP
como protocolo de enrutamiento,
A continuación, debemos especificar cuál es la red, directamente conectada, a la que enviaremos nuestras
actualizaciones.
Esto se hace tecleando network {red}. Mediante este comando, también se inicia el proceso de
enrutamiento, y el router comienza a mandar actualizaciones.
Balanceo de carga en BGP:
Estas referencias han sido tomadas de la página web de Cisco y de las intenciones de los miembros de
listas de correo de zebra, nodos de Red Libre y Guadalajara . Ante la posibilidad de un futuro establecer
sesiones redundantes entre vecinos BGP y balancear carga entre ellos.
Para este punto tiene que ser resuelta la posibilidad de utilizar un interfaz lógico que permita utilizarse en
routing y así poder emular las funciones de una Loopback 0 de un router Cisco.
El balanceo de carga es un concepto que permite a un router distribuir el tráfico entrante y saliente a
través de caminos múltiples. Los caminos son mostrados entre protocolos estáticos o con protocolos
dinámicos, tanto como RIP, EIGRP, OSPF y IGRP. Por defecto, BGP (Border Gateway Protocol)
selecciona solo un mejor camino y no habilita balanceo de carga. Este documento muestra como habilitar
balanceo de carga
BALANCEO DE CARGA USANDO LA DIRECCION DE LOOPBACK COMO UN VECINO BGP.
Figura 2. Balanceo de carga
50
Este escenario es el que pretendemos realizar para nuestro siguiente laboratorio. Seria posible en
escenarios cuando existen multiples enlaces con igual metrica (contando que el máximo para balancear
sería 6) y son terminados en un router con un AS y en otro router con otro AS.
Aquí mostramos las configuraciones recomendadas por Cisco, reseñamos que aunque ponga direciones
serial nosotros podemos adoptar cualquier otra, ya sea de Wlan Ethernet etc.
ROUTER A:
Aquí mostramos la configuracion del router A
interface loopback 0
ip address 1.1.1.1 255.255.255.0
interface serial 0
ip address 160.20.20.1 255.255.255.0
no ip route-cache
interface serial 1
ip address 150.10.10.1 255.255.255.0
no ip route-cache
router bgp 11
neighbor 2.2.2.2 update-source loopback 0
neighbor 2.2.2.2 ebgp-multihop
router eigrp 12
network 1.0.0.0
network 150.10.0.0
network 160.20.20.0
ROUTER B:
Aquí mostramos la configuracion necesaria para el router B:
interface loopback 0
ip address 2.2.2.2 255.255.255.0
interface serial 0
ip address 160.20.20.2 255.255.255.0
no ip route-cache
interface serial 1
ip address 150.10.10.2 255.255.255.0
no ip route-cache
51
router bgp 10
neighbor 1.1.1.1 update-source loopback 0
neighbor 1.1.1.1 ebgp-multihop
router eigrp 12
network 2.0.0.0
network 150.10.0.0
network 160.20.20.0
NOTA: Tenemos que utilizar rutas estaticas dependiendo del protocolo de routing (EIGRP en este caso)
para introducir dos iguales caminos y con igual coste para alcanzar a su destino que será la direccion de
Loopback.
7. Notas finales
Ahora que ha pasado un tiempo desde estas pruebas que realizamos ya el 25 de Mayo (hoy es dia 10 de
Julio) sabemos algo más de ospf y bgp. Las siguientes notas simplifican la configuración. Queda mucho
por hacer, establecer filtros de rutas aceptadas, filtros de rutas anunciadas, autentificación entre routers...
En la configuración de OSPF, parece adecuado anunciar con "network" las subredes a las que estamos
conectados y que queremos que formen parte de las tablas de rutas de los demás encaminadores. Las
instrucciones "area X" sirven para resumir la tabla de rutas, normalmente solo en el area 0 ospf o en
encaminadores que usen BGP.
router ospf
network 172.18.14.0/30 area 0
! area 0 network 172.18.0.0/24 - solo se usará para resumir rutas anunciadas, hay que usarlo
En BGP hay que hacer exactamente lo mismo, incluso con la interfaz de conexión entre los routers BGP,
que de otra forma no sería anunciada nunca, ya que no se intercambian las rutas locales con las tablas de
rutas de encaminadores también remotos.
redistribute connected es siempre peligroso, y debería ir acompañado de filtro de subredes anunciadas.

ebgp-multihop no es necesario en principio, con una única conexión bgp entre dos AS, y la instrucción
neighbor permite establecer el equipo contra el que hay que intercambiarse esa tabla de routas.
router bgp 3
! redistribute connected
redistribute ospf
! neighbor 172.21.1.1 ebgp-multihop 255
network 172.18.14.0/30 area 0
52
8. Enlaces, referencias y otras fuentes utilizadas
RED LIBRE: http://www.redlibre.net/
LEGANES WIRELESS: http://www.leganeswireless.net
MADRID WIRELESS: http://www.madridwireless.net
GUADA WIRELESS: http://www.guadawireless.net
BGP: http://www.cisco.com http://www.bgpbook.com/bookindex.html
Linux Advanced Routing & Traffic Control HOWTO http://lartc.org/HOWTO/cvs/2.4routing/lartc.html"
53

Laboratorio Routing Guadalajara

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Laboratorio Routing Guadalajara

Cargado por

Copyright:

Formatos disponibles

Laboratorio de routing en

Guadalajara, el día 25 de Mayo de

Prácticas de routing en laboratorio realizadas en Guadalajara, el 25 de Mayo de 2002, entre

v0.1, 13 de Junio de 2002.

Conversión a DocBook, Andrés Seco, AndresSH@alamin.org.

Esquemas de David González, divadis@terra.es.

Revisión del texto por

LOS AUTORES, CONTRIBUIDORES Y MANTENEDORES NO SON RESPONSABLES DE

Este manual es el resultado de la experiencia de los grupos de GuadaWireless, LeganesWireless,

2.2. Conceptos Generales

2.3. Breve descripción del laboratorio utilizado

En el laboratorio hemos utilizado el siguiente material:

2.4. Zebra, instalación y configuración

Los pasos a seguir para la instalación y correcta configuración de Zebra son:

1.- Bajar el paquete de Zebra disponible:

cd /usr/ports/net/zebra; make install clean

* Se puede bajar el archivo directamente desde y compilarlo:

* O bajar directamente el RPM de Internet:

* O bajar directamente el DEB en Debian:

apt-get install zebra

2.- Instalar los paquetes y configurar de la siguiente manera:

Otros comandos interesantes son:

Para parar el demonio:

Para arrancar el demonio:

3.- Arrancar los servicios oportunos:

Para la realización de este laboratorio hemos simulado un escenario de 16 nodos basándonos en el

Figura 1. Esquema general de la red

Direcciones de redes de cada nodo:

192.168.0.0/16> "privadas" no visibles en la red wireless. En este rango de direccionamiento hemos

172.16.0.0/30 enlaces internos entre nodos. Utilizables para routing

172.17.0.0/30 usamos 172.15+zona.nodo.1 y 2 (nodo menor) y 172.15.zona_nodo+10.1 y 2 si hay dos

Redes de clientes wireless:

Nodo n04 10.1.41/27 nodo wlan

n04 a n05 : 172.16.4.1 y 172.16.4.2 respectivamente /30

Redes de clientes wireless:

n01, 10.2.1.1/27 nodo wlan

n01-n02 172.17.1.1 y 172.17.1.2 /30

Redes de clientes wireless:

n10, 10.3.10.1/27 nodo wlan

n10-n11 172.18.10.1 y 2 /30

ENLACES INTERZONA W1-W2-W3:

n03-n05 172.20.1.1 y 2, /30

3.1. Configuración de direccionamiento ethernet

dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00

dummy1 Link encap:Ethernet HWaddr 00:00:00:00:00:00

eth1 Link encap:Ethernet HWaddr 00:4F:49:04:DC:CC

lo Link encap:Local Loopback

UP LOOPBACK RUNNING MTU:16436 Metric:1

dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00

dummy1 Link encap:Ethernet HWaddr 00:00:00:00:00:00

eth0 Link encap:Ethernet HWaddr 00:05:1C:03:97:95

eth1 Link encap:Ethernet HWaddr 00:05:1C:02:2B:1A

eth2 Link encap:Ethernet HWaddr 00:4F:49:05:32:43

lo Link encap:Local Loopback

UP LOOPBACK RUNNING MTU:16436 Metric:1

dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00

dummy1 Link encap:Ethernet HWaddr 00:00:00:00:00:00

eth0 Link encap:Ethernet HWaddr 00:05:1C:02:C2:C2

eth1 Link encap:Ethernet HWaddr 00:4F:49:04:F6:6A

eth2 Link encap:Ethernet HWaddr 00:4F:49:04:DC:C0

lo Link encap:Local Loopback

UP LOOPBACK RUNNING MTU:16436 Metric:1

dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00