Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Desarrollo:
En el Anexo 1 se encuentran los diagramas representando el detalle de cada uno de los sistemas
autónomos, en el Anexo 2 se incluyen las direcciones IPv4 e IPv6 necesarias para configurar las
sesiones BGP. En el Anexo 3 se listan los prefijos IPv4 e IPv6 asignados a cada uno de los sistemas
autónomos, en el Anexo 4 se listan las interfaces de monitoreo, en el Anexo 5 se describe el
procedimiento para generar la copia de la configuración para la entrega, y por último en el Anexo 6
figura una cartilla de comandos BGP para poder configurar el Quagga y realizar el laboratorio.
Figura 1
Procedimiento IPv4:
1. Configurar las sesiones eBGP entre el Sistema Autónomo (AS) 65001 (R1-1) y AS 65005
(R5-1), el AS 65002 (R2-1) y AS 65005 (R5-2), el AS 65005 (R5-3) y el AS 65006 (R6-1),
AS 65005 (R5-4) y el AS 65008 (R8-1). Capture mediante tcpdump el establecimiento de
una de ellas.
Verificar que la sesión se establezca y que recibe prefijos, utilizar los siguientes comandos.
Recordar que una sesión establecida debe encontrarse en el estado “established”.
show ip bgp summary
show bgp ipv4 unicast
show ip bgp neighbors W.X.Y.Z advertised-routes
show ip bgp neighbors W.X.Y.Z received-routes
Indique la salida del primer comando para el enrutador R5-1, y la cantidad de prefijos que indica
haber aprendido el segundo comando.
Detenga la captura en el tcpdump, y mediante wireshark identifique los diferentes mensajes BGP
(OPEN, UPDATE, Keepalive). Observe los distintos campos de cada uno de ellos.
Verificar que las sesiones se establezcan y que se reciben prefijos. Utilizar los siguientes
comandos:
3. Desde el router R5-4 dentro del AS 65005. ¿Es posible ver rutas hacia todos los AS en BGP
(show ip bgp)?. De acuerdo a la Figura 1, ¿Podría haber mejores caminos a algún destino?
¿Está R5-4 utilizando las rutas aprendidas por BGP (show ip route)?
Investigue por qué hay caminos no visibles en el AS 65005 y por qué el enrutador no está
utilizando las rutas aprendidas. Corrija los errores encontrados. En particular verificar:
i. si hay full-mesh iBGP (lo que se aprende por iBGP, no se propaga por iBGP).
ii. los próximos saltos. Puede utilizar “next-hop-self” en las sesiones de iBGP (se requiere
una ruta al next-hop diferente de la default).
Nota: La sincronización esta deshabilitada como opción por defecto en los enrutadores
modernos por lo que este no es un problema.
4. Configurar las sesiones iBGP dentro del AS 65005 asumiendo que los router R5-1 y R5-2
son los reflectores, y los routers R5-3 y R5-4 clientes.
5. Realice las configuraciones necesarias para que en los AS 65005 y AS 65008 se generen los
anuncios correspondientes a las tablas “Rangos a Publicar” del Anexo 3. Para el AS 65005
genere los anuncios en R5-1 y R5-2.
Realizar un ping y un traceroute desde R8-1 a la loopback de R7-1 (ver lista de loopback
Anexo 2).
¿Cuál es la IP de origen del ping o traceroute desde R8-1?
Verificar en los routers del AS 65005 cual es la ruta para alcanzar ese origen.
Habilitar ospf dentro del AS 65005, defina el área cero a la cual pertenezcan las redes de
todas las interfaces. En la configuracion de ospf, utilizar passive-interface ifname en las
interfaces lo y las wanes hacia otros sistemas autónomos (no se escucha ospf por la interfaz,
pero se propaga la red dentro de ospf).
Indique:
ii. Desde R8-1, el camino a la loopback R1-1 (ver lista de loopback Anexo 2)
iii. Desde R8-1, el camino a la loopback R4-1 (ver lista de loopback Anexo 2)
Procedimiento IPv6:
Cada interfaz de los equipos del laboratorio tiene configurado dual-stack (una dirección IPv4 y una
dirección IPv6), el objetivo de esta segunda parte es familiarizarse con la configuración de BGP en
IPv6.
En cada caso, la sesión IPv4 (configurada previamente) se utiliza para intercambiar prefijos IPv4, y
la sesión IPv6 (a configurar de acuerdo a los detalles listados a continuación) sólo se utiliza para
intercambiar los prefijos IPv6.
1. Configurar las sesiones eBGP IPv6 entre el AS 65001 (R1-1) y AS 65005 (R5-1), el AS
65002 ( R2-1) y AS 65005 (R5-2), el AS 65005 (R5-3) y el AS 65006 (R6-1), 65005 (R5-
4) y el AS 65008 (R8-1).
Verificar que la sesión se establezca y que recibe prefijos, utilizar los siguientes comandos.
Indique la salida del primer comando para el enrutador R5-1, y la cantidad de prefijos que indica
haber aprendido el segundo comando.
Verificar que la sesión se establezca y que recibe prefijos, utilizar los siguientes comandos.
Dentro del AS 65005, definir como reflectores de sesiones iBGP para prefijos IPv6 a los
routers R5-1 y R5-2.
3. Realice las configuraciones necesarias para que en los AS 65005 y AS 65008 se generen los
anuncios IPv6 correspondientes a las tablas “Rangos a Publicar” del Anexo 3.
4. Habilitar ospf6 dentro del AS 65005, defina el área cero a la cual pertenezcan las redes IPv6
de todas las interfaces. En la configuración de ospf6, utilizar passive-interface ifname en
las interfaces lo y las wanes hacia otros sistemas autónomos.
Realizar ping ipv6 y traceroute ipv6 desde R8-1 a todas las loopback IPv6 de los equipos
del laboratorio.
ANEXO 1 – Diagramas
AS 130004
AS 65003
eth0
eth1
BGP LAN34 R4-1
eth2 eth0
R3-1
LAN13
LAN23
eth1 AS 65002
eth3
LAN12
AS 65001 eth2 eth2 eth0
eth0
R1-1 eth1 R2-1
AS 65001
BGP AS 65002
LAN15
eth1
5
eth0 N2
R5-1 LA
eth1
eth0 LAN25
R5-2
AS 65005
LAN5
eth0
R6-1
eth0 eth1
eth1 eth2
LAN56
R5-3
LAN6
AS 65006
eth2 R5-4
eth2
eth0 R6-2
eth0
LAN58
LAN67
eth0
eth0
R8-1
R7-1
AS 65008
ANEXO 4 - Monitores
Como en otros laboratorios se crea una máquina monitor que permite realizar tcpdump en cada una
de las redes locales de los diagramas del Anexo 2. El monitor tiene una interfaz en cada una de las
LAN.
Para realizar una traza se debe realizar “tcpdump -i ifname -s 0 -w filename.cap”, donde la interface
a utilizar se selecciona dependiendo de la LAN (sesión BGP) que se desea monitorear.
2) Bajo el directorio “labs” realizar "cp -r bgp bgp.bkp". Esto realiza una copia del directorio bgp en
bgp.bkp
De esta forma trabajamos sobre una copia y no sobre las configuraciones de trabajo.
Se debe utilizar exactamente bgp.bkp como directorio copia, ya que los scripts que facilitan la tarea
asumen este nombre.
3) Recordar que cuando se realiza por primera vez lstart, se copian las diferencias en configuración
de las máquinas virtuales a los directorios que luego utiliza la virtualización.
Las modificaciones en las configuraciones del quagga se salvan a disco utilizando "write memory".
Estas modificaciones no actualizan los directorios base, si se realiza un lclean, perdemos todos
los cambios.
En el directorio bgp.bkp, para copiar los cambios de configuración de quagga, realizar el siguiente
procedimiento:
a) poner a funcionar el laboratorio con lstart
b) en cada enrutador ejecutar el siguiente comando:
Realizar esta tarea en cada una de las doce máquinas que corren quagga.
c) detener el laboratorio con lhalt
network A.B.C.D/X: este comando genera un anuncio de la red A.B.C.D/X via bgp (siempre y
cuando exista en la tabla de ruteo)
neighbor A.B.C.D remote-as ASN: establece una sesión BGP con el peer A.B.C.D y la sesión será
IBGP o EBGP dependiendo del parámetro ASN (número de AS) coincida no con el AS definido en
router bgp ASN.
neighbor A.B.C.D route-map routeMapPrueba out: este comando permite modificar los
atributos de los anuncios hacia el neighbor A.B.C.D a través de un route-map, en el ejemplo
cambiando el next-hop (ver debajo).
neighbor A.B.C.D ebgp-multihop: comando que permite generar una sesión ebgp multihop con el
peer A.B.C.D. Si la sesión eBGP con el neighbor A.B.C.D va a ser multihop este comando debe
incluirse necesariamente al configurar el peer. Por defecto las sesiones en eBGP no son multihop.
neighbor A.B.C.D next-hop-self: comando que indica que el next-hop para las redes anunciadas al
peer A.B.C.D es uno mismo (el enrutador que estamos configurando). Esto es similar al caso
anterior donde se hizo a través de un route-map.
neighbor A.B.C.D route-reflector-client Opcional. Indica para un peer BGP interno, que éste es un
cliente de reflector, o sea que el enrutador “reflejará” las rutas internas desde y hacia este vecino.
Es posible la aplicación de route-map en las redistribuciones entre protocolos con el fin de filtrar los
prefijos a redistribuir.
neighbor A.B.C.D shutdown: permite poner en shutdown la sesión con el peer A.B.C.D
neighbor A.B.C.D update-source: comando que permite indicar cual será la IP que origina los
anuncios que se envían al peer A.B.C.D
neighbor A.B.C.D default-originate: permite inyectarle al peer A.B.C.D una ruta por defecto aún
cuando ésta no exista en mi tabla BGP.
neighbor A.B.C.D maximum-prefix number: comando que permite controlar el máximo número
de prefijos que se manejarán en la sesión
Políticas de ruteo:
Recordar que, luego de realizar cualquier cambio en la política de ruteo, la o las sesiones BGP
involucradas se deben resetear. Para ello, siguiendo lo visto en el teórico, realizar clear ip bgp <IP
del vecino> soft [in/out]. Si no se indica in o out, se realizará en ambas direcciones.
Filtrado básico
Para realizar un filtrado básico, dependiendo solamente del as-path y/o de los prefijos anunciados,
se pueden utilizar las access-lists, las prefix-list, y las as-path access-list
La palabra “seq”, seguida de un entero, permite ordenar las entradas de la prefix-list. Si uno no
indica la secuencia, el router automáticamente suma 5 al último número de secuencia utilizado
La palabra “ge”, opcional, indica “todas las subredes del prefijo dado con igual o más bits de
máscara que los indicados
La palabra “le”, opcional, indica “todas las subredes del prefijo dado con igual o menos bits de
máscara que los indicados
El nombre agrupa distintas entradas de la misma as-path access-list, permit o deny indica si los
prefijos cuyo as-path sea seleccionado por la expresión regular serán “aceptados” o “rechazados”
Tanto las prefix-list como las as-path access-list pueden aplicarse en la dirección “in” o “out”. “in”
significa que se aplicará para seleccionar qué prefijos aceptaré de los que me publica un vecino.
“out” significa que se aplicará para seleccionar cuáles de los prefijos que conozco publicaré hacia
un determinado vecino.
_ : Matchea entre otras cosas con el inicio o final de una línea, o con espacios entre elementos del
AS_PATH
La forma de realizar filtros más avanzados, así como de modificar los atributos asociados a un
prefijo, es mediante route-maps. Referirse a las notas del teórico o a las referencias.
Aplicación de un route-map
router bgp <as>
address-family ipv4
neighbor <IP> route-map <nombre> <in|out>
Aplica el route-map dado por <nombre> al vecino dado por <IP> en la dirección in o out
Un route-map está conformado por uno o más bloques con la siguiente sintaxis:
route-map <nombre> <permit|deny> <numero>
match <condiciones>
set <cambios de atributos>
El bloque match es el que indica bajo qué criterios se seleccionarán los prefijos para aplicarles la
acción. Puede estar vacío, en cuyo caso se seleccionan todos los prefijos. Si hay más de un “match”
en el mismo bloque del route-map, deben matchear todos. Si no hay ningún “match” significa
“cualquiera”
El bloque set es el que indica la acción a realizar. Puede haber más de uno en un bloque, en cuyo
caso se aplicarán todos. Si no hay ningún set se aceptan los prefijos sin realizar modificaciones de
atributos.
Manejo de comunidades
Por defecto, Cisco no propaga el atributo “community”. Para permitir trabajar con comunidades, se
debe habilitar explícitamente su envío a los vecinos
Para modificar las comunidades asociadas a una ruta, se debe utilizar un route-map, como se vió en
el teórico.
route-map <nombre> permit <numero>
match <criterio>
set community [additive] <numero de comunidad>
o
set comm-list <numero> delete
La primer forma setea una o varias comunidades a los prefijos seleccionados por el route-map. La
palabra “additive”, que es opcional, indica que se agreguen las comunidades dadas sin borrar las
que ya tuviera el prefijo.
La segunda forma se utiliza para borrar comunidades, donde el número indica una community-list
Para actuar en base a una comunidad, se puede seleccionar dentro de un route-map basándose en
una community-list.
Configuración de Route-Reflector:
Configuración que se debe realizar en los reflectores. Del lado de los clientes la configuración se
realiza como una sesión clásica de iBGP.
router bgp ASN
bgp cluster-id A.B.C.D
neighbor F.G.H.I remote-as ASN
neighbor F.G.H.I route-reflector-client
Ejemplo de configuración:
La configuración con direccionamiento IPv6 no es muy diferente a cómo se configura BGP en IPv4,
solo hay que tener algunas precauciones.
El envío de direcciones IPv6 se realiza mediante las extensiones de BGP, utilizando una nueva
familia de direcciones. Esto implica que debemos activar el peer BGP para intercambiar direcciones
IPv6.
address-family ipv6
neighbor S:R:T:U:V:W:X:Y:Z activate
Si se desea que el peer BGP IPv6 no intercambie prefijos IPv4, hay que deshabilitarlo
específicamente para que no lo realice. Dentro de router bgp ASN,
router bgp ASN
no neighbor S:R:T:U:V:W:X:Y:Z activate
Todos los comandos que referencien a una sesion BGP para intercambiar prefijos IPv6, son
similares a los de IPv4, solo que deben configurarse dentro del bloque address-family ipv6.
address-family ipv6
network S:R:T:U:V:W:X:Y:Z/M
redistribute <rip/connected/static>
neighbor <IPv6> prefix-list <nombre> <in|out>
neighbor <IPv6> filter-list <nombre> <in|out>
neighbor <IPv6> route-map <nombre> <in|out>
neighbor <IPv6> default-originate
neighbor <IPv6> send-comunity
Los comandos show vistos previamente siguen siendo válidos con la salvedad de modificar ip por
ipv6.
Nota. Observar que los atributos CLUSTER-ID y ROUTER-ID son los mismos que en IPv4, por lo
tanto siguen siendo números de 32 bits.