BGP and attributes
Otra vez por aquí. Vamos a ver si podemos hacer una introducción al
protocolo por excelencia de las comunicaciones BGP ( Border Gateway
Protocol ). Como una vez me dijo mi profesor de networking “Podríamos
estar hablando de BGP durante días y días y aun nos faltaría tiempo”.
Vamos a utilizar una topología donde podremos ver bastantes atributos
con los que se trata habitualmente con BGP y la practica la realizaremos
mediante un laboratorio hecho con routers Cisco de verdad además de
emular también mediante GNS3 routers Juniper. De esta manera
tendremos una visión más general de BGP y de su funcionamiento. A
continuación la topología que vamos a utilizar :
Para empezar diremos que BGP es un protocolo de routing de tipo EGP
( Exterior Gateway Protocol ). Este protocolo se encarga de realizar las
comunicaciones entre Sistemas Autónomos. Un Sistema Autónomo o
“AS” es un grupo de routers que hablan habitualmente un tipo de IGP
( Interior Gateway Protocol ), como pueda ser : RIP, OSPF, EIGRP … y que
utilizan un EGP para con otros Sistemas Autonomos.
Como características esenciales de BGP podemos enumerar las
siguientes :
Utiliza TCP como método de comunicación y el puerto 179
Protocolo estandar
Es un protocolo de vector de distancia
Utiliza como métrica los llamados “path vectors” que son unos
parametros llamados “Atributos”
Soporta VLSM
La versión actual para IPv4 es BGPv4 y para IPv6 es BGP+ o MPBGP
Establece relaciones de vecindad con los llamados “peers” o
vecinos
SISTEMAS AUTONOMOS
Existen 65535 Sistemas Autonomos. En la actualidad los encontramos en
lo que llamamos Internet, estos son asignados por registradores de
Internet o ISPs y se organizan de la siguiente manera :
El Sistema Autonomo 0 esta reservado
Del 1 – 64495 se asignan para uso público
Del 64512 – 65535 son de uso privado
Y el Para establecer una relación de vecindad mediante routers BGP
existen 4 tipos de mensajes :
OPEN : Es el mensaje que utiliza BGP para crear y mantener las
conexiones con sus peers, utilizando el puerto TCP 179 y a través de
mensajes OPEN BGP.
KEEPALIVE Sistema Autonomo 65535 tambien esta reservado
RELACIONES DE VECINDAD BGP
1. : Son mensajes que se envían regularmente para mantener las
sesiones entre los vecinos y la información del peer es almacenada
a parte en una tabla de vecinos
2. NOTIFICATION : Mensaje utilizado cuando un peer es reseteado y
se envía a los vecinos para indicar la finalización de la vecindad
3. UPDATE : Cuando se establece una relación de vecindad
por primera vez, los routers intercambian sus tablas de
enrutamiento por completo y utilizan este tipo de mensaje. Una vez
ya establecida la relación de vecindad solo se envíaran este tipo de
mensajes en caso de que se detecten cambios y en esta ocación
seran de manera incremental.
Para ver la tabla de vecinos mediante Routers Cisco, podemos utilizar el
comando :
RouterCisco# show ip bgp neighbors
Para ver la tabla de vecinos mediante Routers Juniper, podemos utilizar
el comando :
RouterJuniper> show bgp neighbor
Dentro del protocolo BGP podemos distinguir dos tipos de protocolo :
iBGP : ( Interior BGP ) Se utiliza BGP como si fuera un IGP y de esta
manera se pueden comunicar los routers dentro de un AS. Es
importante saber que para que iBGP funcione correctamente se es
necesario utilizar un IGP por debajo.
eBGP : ( Exterior BGP ) Se utiliza BGP como si fuera un EGP y de
esta manera se pueden comunicar los Sistemas Autonomos.
ESTADOS BGP
IDLE : En este estado los routers buscan a los vecinos y estan a la
espera de que empiece la fase llamada “start”. Este suceso se da
al establecer o resetear un administrador una sesión BGP.
CONNECT : BGP espera a que se complete la conexión del
protocolo de transporte TCP mediante el puerto 179. En el caso de
que la conexión se realice satisfactoriamente el estado pasa a la
fase “open sent” y en caso contrario el estado cambiara a “active”
ACTIVE : Intenta establecer una relación de vecindad iniciando la
conexión a través del protocolo de transporte TCP y el puerto 179.
En caso de que lo consiga pasará al siguiente estado, “open sent”.
Cuando el temporizador “connect retray” expira BGP lo reinicia y
vuelve al estado “connect”. Cuando un router permanece entre el
estado “connect” y “active” revela que la conexión TCP no se
puede establecer.
OPEN SENT : En este estado el router espera mensajes “open” del
vecino. Estos mensajes son comprovados para verificar que los
datos son correctos, así como las versiones BGP y el número de
Sistema Autonomo.
OPEN CONFIRM : Los routers esperan mensajes “Keepalive”. Si
reciben estos mensajes de su vecino entonces la sesión pasa al
siguiente estado.
ESTABLISHED : Es el estado final y el necesario para que BGP
comience a funcionar. En este estado se intercambian rutas,
actualizaciones o keepalives.
Despues de hablar de la parte más teorica del protocolo vamos a realizar
las configuraciones básicas BGP y a continuación hablaremos de eBGP y
la métrica que utiliza llamada “atributos” con la que manipula el tráfico
de diferente manera.
CONFIGURACIÓN BÁSICA R1
R1> en
R1# conf t
R1(config)# router bgp 62300 – Establecemos nuestro AS
Indicamos quien es nuestro vecino y en que AS se encuentra :
R1(config-router)# neighbor 96.130.5.130 remote-as 61003
CONFIGURACIÓN BÁSICA R2
R2> en
R2# conf t
R2(config)# router bgp 62300
R2(config-router)# neighbor 200.10.50.82 remote-as 61003
CONFIGURACIÓN BÁSICA R3
R3> en
R3# conf t
R3(config)# router bgp 61003
R3(config-router)# neighbor 96.130.5.129 remote-as 62300
R3(config-router)# neighbor 200.10.50.81 remote-as 62300
R3(config-router)# neighbor 10.0.0.2 remote-as 61003 – Indicamos
vecino iBGP
R3(config-router)# neighbor 10.0.0.3 remote-as 61003 – Indicamos
vecino iBGP
CONFIGURACIÓN BÁSICA JUN1
root@% cli
root@JUN1> edit
Establecemos nuestro AS :
root@JUN1# set routing-options autonomous-system 61003
Indicamos grupo y que tipo de BGP trabajaremos. En este caso
“external” es eBGP :
root@JUN1# set protocols bgp group ebgp type external
AS en el que se enuentra el peer vecino :
root@JUN1# set protocols bgp group ebgp peer-as 2300
IP del vecino eBGP :
root@JUN1# set protocols bgp group ebgp neighbor 198.80.90.22
Indicamos grupo y que tipo de BGP trabajaremos. En este caso “internal”
es iBGP :
root@JUN1# set protocols bgp group ibgp type internal
Indicamos cual es la dirección local para hablar iBGP :
root@JUN1# set protocols bgp group ibgp local-address 10.0.0.2
Indicamos las IPs de los vecinos iBGP
root@JUN1# set protocols bgp group ibgp neighbor 10.0.0.1
root@JUN1# set protocols bgp group ibgp neighbor 10.0.0.3
root@JUN1# commit
CONFIGURACIÓN BÁSICA JUN2
root@% cli
root@JUN2> edit
root@JUN2# set routing-options autonomous-system 61003
root@JUN2# set protocols bgp group ebgp type external
root@JUN2# set protocols bgp group ebgp peer-as 2300
root@JUN2# set protocols bgp group ebgp neighbor 43.11.10.58
root@JUN2# set protocols bgp group ibgp type internal
root@JUN2# set protocols bgp group ibgp local-address 10.0.0.3
root@JUN2# set protocols bgp group ibgp neighbor 10.0.0.1
root@JUN2# set protocols bgp group ibgp neighbor 10.0.0.2
root@JUN2# commit
CONFIGURACIÓN BÁSICA JUN3
root@% cli
root@JUN3> edit
root@JUN3# set routing-options autonomous-system 2300
root@JUN3# set protocols bgp group ebgp type external
root@JUN3# set protocols bgp group ebgp peer-as 61003
root@JUN3# set protocols bgp group ebgp neighbor 43.11.10.57
root@JUN3# set protocols bgp group ebgp neighbor 198.80.90.21
root@JUN3# commit
COMPROBACIÓN DE ADYACENCIA
Para corroborar que los peers han establecido sesión podemos utilizar
los siguientes comandos :
ROUTERS CISCO
Muestra los estados de las conexiones con los peers :
R3# show ip bgp summary
BGP router identifier 200.10.50.82, local AS number 61003
BGP table version is 124, main routing table version 124
12 network entries using 1212 bytes of memory
16 path entries using 768 bytes of memory
5 BGP path attribute entries using 300 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2328 total bytes of memory
BGP activity 21/9 prefixes, 116/100 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
10.0.0.2 4 61003 99 322 124 0 0
00:00:30 3
10.0.0.3 4 61003 105 356 124 0 0
00:04:22 3
96.130.5.129 4 62300 322 338 124 0 0
00:05:06 4
200.10.50.81 4 62300 419 440 124 0 0
03:26:26 4
Podremos ver tambien en la consola el siguiente mensaje que nos indica
la adyacencia con un vecino :
*Mar 1 10:30:27.960: %BGP-5-ADJCHANGE: neighbor
96.130.5.130 Up
R3# show ip bgp neighbors
BGP neighbor is 10.0.0.2, remote AS 61003, internal link
BGP version 4, remote router ID 4.4.4.4
BGP state = Established, up for 00:00:27 – Adyacencia correcta
Last read 00:00:27, hold time is 90, keepalive interval is 30 seconds
ROUTERS JUNIPER
Muestra los estados de las conexiones con los peers :
root@JUN3> show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State
Pending
inet.0 16 8 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped…
43.11.10.57 61003 153 130 0 0 58:10
0/8/8/0 0/0/0/0
198.80.90.21 61003 160 130 0 0 58:10
8/8/8/0 0/0/0/0
root@JUN3> show bgp neighbor
Peer: 43.11.10.57+63894 AS 61003 Local: 43.11.10.58+179 AS
2300
Type: External State: Established Flags: <ImportEval Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ rip-routes ]
Options: <Preference PeerAS Refresh>
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 5.5.5.5 Local ID: 172.32.32.1 Active Holdtime:
90
Keepalive Interval: 30 Peer index: 0
Ahora que tenemos la configuración mínima y las adyacencias entre
vecinos realizadas proseguiremos con la teoria. Es importante que sepais
que las adyacencias iBGP no se realizaran sin activar un IGP que será el
encargado de realizar la comunicación y tambien en los routers Juniper
hay que activar la propagación de BGP. Esto lo explicaremos más
adelante pero no os preocupeis porque es normal.
ATRIBUTOS BGP
Hablando vulgarmente podríamos decir que los atributos BGP son la
métrica que utiliza BGP para distribuir rutas, informar del mejor camino
… Vamos a nombrar los atributos más importantes :
AS_PATH –> Se incluye automaticamente en todos los mensajes
NEXT-HOP –> Se incluye automaticamente en todos los mensajes
ORIGIN –> Se incluye automaticamente en todos los mensajes
LOCAL_PREF –> Opcional
ATOMIC_AGGREGATE –> Opcional
AGGREGATOR –> Opcional
COMMUNITY –> Opcional
MULTI_EXIT_DISC –> Opcional
WEIGHT –> Opcional
AS_PATH
Es un atributo obligatorio y sirve para informar la lista de Sistemas
Autonomos que se deben atravesar para llegar a una ruta o destino.
Podemos ver sus propiedades en la sección “Path” del comando :
R3# show ip bgp
BGP table version is 42, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 96.130.5.129 0 0 62300 i
*> 2.2.2.2/32 200.10.50.81 0 0 62300 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
r>i4.4.4.4/32 10.0.0.2 100 0 i
r>i5.5.5.5/32 10.0.0.3 100 0 i
root@JUN3> show route
inet.0: 19 destinations, 27 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 00:00:39, localpref 100
AS path: 61003 62300 I
> to 198.80.90.21 via em0.0
[BGP/170] 00:00:14, localpref 100
AS path: 61003 62300 I
> to 43.11.10.57 via em1.0
NEXT-HOP
Es un atributo obligatorio e indica la dirección ip de siguiente salto que
vamos a utilizar para alcanzar una red destino. Podemos ver sus
propiedades en la sección “Next Hop” y se puede observar que para los
casos que existen varios caminos, el mejor se marca con el indicador ” >
“.
R3# show ip bgp
BGP table version is 275, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 96.130.5.129 0 0
62300 i
*> 2.2.2.2/32 200.10.50.81 0 0
62300 i
* 178.100.10.32/27 200.10.50.81 0 0
62300 ?
*> 96.130.5.129 0 0
62300 ?
* Vemos que por ejemplo para llegar a la subred 178.100.10.32/27,
tenemos dos siguientes saltos : 200.10.50.81 y 96.130.5.129, pero
nuestro siguiente salto es96.130.5.129, dado que esta marcado con ” >
“
En Juniper veríamos lo mismo en diferente formato :
root@JUN3> show route
inet.0: 19 destinations, 27 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 00:00:53, localpref 100
AS path: 61003 62300 I
> to 43.11.10.57 via em1.0
[BGP/170] 00:00:21, localpref 100
AS path: 61003 62300 I
> to 198.80.90.21 via em0.0
ORIGIN
Es un atributo obbligatorio que nos muestra el origen del camino para
llegar a un destino o como se ha originado. Viene indicado en el final del
AS_PATH y Existen tres posibles origenes :
1. Via IGP : Si la ruta se origina en el interior del AS y se propaga
como IGP se indica con una ” i “
2. Via EGP : Si la ruta es aprendida via EGP, que actualmente es un
protocolo en desuso y se marca con ” e “
3. Incompleto : Es una ruta desconocida o que se ha aprendido de
otra manera. Uusualmente es cuando se redistribuie demtro de BGP
otro protocolo de routing. Se comarca con ” ? “.
En routers cisco veremos lo siguiente :
R3# show ip bgp
BGP table version is 1128, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 96.130.5.129 0 0 62300 i
*> 2.2.2.2/32 200.10.50.81 0 0 62300 i
*> 75.1.10.16/28 96.130.5.129 0 0 62300 ?
En routers Juniper :
root@JUN3> show route
inet.0: 19 destinations, 27 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 00:02:09, localpref 100
AS path: 61003 62300 I – Via IGP
> to 43.11.10.57 via em1.0
[BGP/170] 00:00:24, localpref 100
AS path: 61003 62300 I
> to 198.80.90.21 via em0.0
43.11.10.56/29 *[Direct/0] 02:27:13
> via em1.0
75.1.10.16/28 *[BGP/170] 00:02:09, localpref 100
AS path: 61003 62300 ? – Via desconocida
> to 43.11.10.57 via em1.0
[BGP/170] 00:00:24, localpref 100
AS path: 61003 62300 ?
> to 198.80.90.21 via em0.0
LOCAL_PREF
El atributo Local Preference se utiliza a nivel local de los routers y se
utiliza para indicar a los routers de un Sistema Autonomo cual es el
camino preferido de salida. Se configura en un router y se intercambia
mediante iBGP. Este parametro se aplica de entrada. Elvalor más
alto es el escojido para la salida, siendo 100 el valor por defecto.
Podemos observar el valor de este atributo en la salida de los comandos
habituales, en la columna “LocPrf” :
R3# show ip bgp
BGP table version is 42, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 96.130.5.129 0 0 62300 i
*> 2.2.2.2/32 200.10.50.81 0 0 62300 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
r>i4.4.4.4/32 10.0.0.2 100 0 i
r>i5.5.5.5/32 10.0.0.3 100 0 i
root@JUN3> show route
inet.0: 19 destinations, 27 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 00:02:09, localpref 100
AS path: 61003 62300 I
> to 43.11.10.57 via em1.0
[BGP/170] 00:00:24, localpref 100
AS path: 61003 62300 I
> to 198.80.90.21 via em0.0
ATOMIC_AGGREGATE
Este atributo nos servirá para sumarizar subredes e informar a los peers
de rutas menos específicas. Esto ayuda a preservar más memoria y CPU,
dado que no se especifican tantas subredes y disminuye la routing table
de los routers.
AGGREGATOR
En este atributo se incluye la IP y AS del router que ha generado la ruta
sumarizada.
COMMUNITY
El atributo community proporciona una manera de agrupar los destinos a
los que se puede aplicar decisiones de enrutamiento como por ejemplo,
aceptar rutas, preferencia y redistribución. Se suele utilizar los llamados
route-maps en Cisco y para Juniper utilizaremos los ” policy options “.
Las communities más comunes son:
internet: Anuncia esta ruta a Internet, todos los routers
pertenecen a esta community
no-export: No anuncia esta ruta a otros peers eBGP
no-advertise: No anuncia esta ruta a ningún peer
local-as: Envía esta ruta a otros peers en otros subsistemas
autónomos dentro de la misma confederación local
MULTI_EXIT_DISC
El atributo MED, también conocido como métrica, indica a los peers de
eBGP el path preferido para entrar en el AS desde fuera. Por defecto el
valor del MED es 0 y cuanto más bajo sea el valor es más preferible. Ac
ontinuación podemos ver los valores de MED:
R3# show ip bgp
BGP table version is 42, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 96.130.5.129 0 0 62300 i
*> 2.2.2.2/32 200.10.50.81 0 0 62300 i
WEIGHT
Weight es un atributo específico de Cisco y no se propaga a otros
routers, dado que se define a nivel local del router. Los valores del
weight están en el rango 0 – 65535, por defecto para las rutas
informadas por el propio router el weight informado es 32768. Las rutas
a un destino con mayor weight son preferidas sobre otras.
El weight puede ser utilizado en lugar de la local preference para
influenciar en la selección del path a los peers externos de BGP. La
diferencia principal es que el weight no se envía entre peers y la local
preference se envía entre peers iBGP. Podemos ver el valor actual del
weight de la siguiente forma :
R3# show ip bgp
BGP table version is 42, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 96.130.5.129 0 0 62300 i
*> 2.2.2.2/32 200.10.50.81 0 0 62300 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
Ahora procederemos a poner en practica los atributos en nuestra
topología :
Ahora hablaremos de la prioridad de las rutas y como BGP toma las
decisiones en un orden de preferencia :
1. Si el next hop al path está caído se descarta el path.
2. Si el path es interno, la sincronización está habilitada, y el path no
está en IGP se descarta el path.
3. Se selecciona el path con mayor weight.
4. Si el weight es igual se selecciona la mayor local preference.
5. Si la local preference es igual se selecciona el path que haya sido
originado en el router local.
6. Si el path no ha sido originado por el router local se selecciona la
que tenga el AS-Path más corto.
7. Si todos tienen el AS-Path de la misma longitud se selecciona en
primer lugar los paths originados en el AS local.
8. Si los Origin Code son iguales se selecciona la que tenga el MED
más pequeño.
9. Si el MED es igual se prefiere el path eBGP antes que el iBGP.
10. Si los MED son iguales se prefiere el que tenga el vecino IGP más
cercano.
11. Para desempatar se elegirá el path con el vecino BGP con el RID
menor.
Nos falta definir en el AS 61003 un IGP que pueda transportar los
mensajes iBGP. Para ello empezaremos por R3 y pasaremos luego a JUN1
y JUN2 .
CONFIGURACIÓN IGP R3
R3(config)# router rip
R3(config-router)# ver 2 – configuramos la versión 2 de RIP
R3(config-router)# net 10.0.0.0 – publicamos la red interna
R3(config-router)# no auto-summary – obligamos a que RIP no
sumarize subredes
CONFIGURACIÓN IGP JUN1
Vamos a crear un grupo RIP e indicaremos en que interfaz hablaremos
con los vecinos :
root@JUN1# set protocols rip group ripAS61300 neighbor em1
Creamos una policy para advertir subredes directamente conectadas:
root@JUN1# set policy-options policy-statement rip-routes term 1
from protocol direct
Creamos otra regla dentro de la policy para advertir subredes recividas
mediante RIP :
root@JUN1# set policy-options policy-statement rip-routes term 1
from protocol rip
Ponemos la política que sera aceptarlas :
root@JUN1# set policy-options policy-statement rip-routes term 1
then accept
Exportamos la polícy al grupo RIP para que empiece a hablar rip con los
vecinos :
root@JUN1# set protocols rip group ripAS61300 export rip-routes
root@JUN1# commit
CONFIGURACIÓN IGP JUN2
Vamos a crear un grupo RIP e indicaremos en que interfaz hablaremos
con los vecinos :
root@JUN2# set protocols rip group ripAS61300 neighbor em0
Creamos una policy para advertir subredes directamente conectadas:
root@JUN2# set policy-options policy-statement rip-routes term 1
from protocol direct
Creamos otra regla dentro de la policy para advertir subredes recividas
mediante RIP :
root@JUN2# set policy-options policy-statement rip-routes term 1
from protocol rip
Ponemos la política que sera aceptarlas :
root@JUN2# set policy-options policy-statement rip-routes term 1
then accept
Exportamos la polícy al grupo RIP para que empiece a hablar rip con los
vecinos :
root@JUN2# set protocols rip group ripAS61300 export rip-routes
root@JUN2# commit
Si miramos en las tablas de routing veremos que encontramos las
subredes aprendidas mediante RIP :
root@JUN1# run show route protocol rip
inet.0: 17 destinations, 22 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
5.5.5.5/32 *[RIP/100] 16:59:38, metric 2, tag 0 — loopback
de JUN2
> to 10.0.0.3 via em1.0
43.11.10.56/29 *[RIP/100] 16:59:38, metric 2, tag 0 — Interfaz
connectada de JUN2
> to 10.0.0.3 via em1.0
224.0.0.9/32 *[RIP/100] 16:10:23, metric 1
MultiRecv
root@JUN2# run show route protocol rip
inet.0: 17 destinations, 22 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
4.4.4.4/32 *[RIP/100] 17:01:58, metric 2, tag 0 — loopback
de JUN1
> to 10.0.0.2 via em0.0
198.80.90.20/30 *[RIP/100] 17:01:58, metric 2, tag 0 — Interfaz
connectada de JUN1
> to 10.0.0.2 via em0.0
224.0.0.9/32 *[RIP/100] 16:12:54, metric 1
MultiRecv
R3# show ip route rip
4.0.0.0/32 is subnetted, 1 subnets
R 4.4.4.4 [120/1] via 10.0.0.2, 00:00:17, Ethernet0/0
5.0.0.0/32 is subnetted, 1 subnets
R 5.5.5.5 [120/1] via 10.0.0.3, 00:00:16, Ethernet0/0
198.80.90.0/30 is subnetted, 1 subnets
R 198.80.90.20 [120/1] via 10.0.0.2, 00:00:17, Ethernet0/0
43.0.0.0/29 is subnetted, 1 subnets
R 43.11.10.56 [120/1] via 10.0.0.3, 00:00:16, Ethernet0/0
Ahora vamos a publicar las redes del AS 62300 mediante redistribución
por BGP. Así los demás Sistemas Autonomos sabran como llegar a las IPs
del AS. Iremos a los Routers R1 y R2 y aplicaremos los cambios :
R1# conf t
R1(config)# router bgp 62300
R1(config-router)# redistribute ospf 1 metric 1
R2# conf t
R2(config)# router bgp 62300
R2(config-router)# redistribute ospf 1 metric 1
Ahora ya podemos ver que el AS 62300 esta publicando sus subredes
internas a los AS vecinos, en este caso al AS 61003. nos conectamos a
R3 para comprovarlo :
R3# show ip route bgp
85.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 85.8.2.9/32 [20/1] via 96.130.5.129, 01:06:32
B 85.8.2.8/29 [20/0] via 200.10.50.81, 01:06:32
1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [20/0] via 96.130.5.129, 01:06:32
2.0.0.0/32 is subnetted, 1 subnets
B 2.2.2.2 [20/0] via 200.10.50.81, 01:06:32
178.100.0.0/27 is subnetted, 1 subnets
B 178.100.10.32 [20/0] via 96.130.5.129, 01:06:32
75.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 75.1.10.16/28 [20/0] via 96.130.5.129, 01:06:32
B 75.1.10.17/32 [20/1] via 200.10.50.81, 01:06:32
Y en nuestra tabla BGP tambien veremos las entradas referidas a las
subredes internas publicadas por el AS 62300 :
R3# show ip bgp
BGP table version is 182, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight
Path
*> 1.1.1.1/32 96.130.5.129 0 0
62300 i
*> 2.2.2.2/32 200.10.50.81 0 0
62300 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
r>i4.4.4.4/32 10.0.0.2 100 0 i
r>i5.5.5.5/32 10.0.0.3 100 0 i
* i10.0.0.0/25 10.0.0.2 100 0 i
* i 10.0.0.3 100 0 i
*> 0.0.0.0 0 32768 i
r>i43.11.10.56/29 10.0.0.3 100 0
i
*> 75.1.10.16/28 96.130.5.129 0
0 62300 ?
*> 75.1.10.17/32 200.10.50.81 1
0 62300 ?
*> 85.8.2.8/29 200.10.50.81 0
0 62300 ?
*> 85.8.2.9/32 96.130.5.129 1
0 62300 ?
*> 178.100.10.32/27 96.130.5.129 0 0
62300 ?
* 200.10.50.81 0 0
62300 ?
r>i198.80.90.20/30 10.0.0.2 100 0
i
Vamos ahora a configurar el atributo NEXT-HOP-SELF que en este caso
nos interesará porque queremos que las rutas eBGP se puedan advertir a
los peers iBGP el Sistema Autonomo 61003 y tambien las rutas del AS
2300. Utilizamos este atributo porque por regla general un peer iBGP no
puede aceptar rutas de origen eBGP. Por eso este atributo cambia la IP
de seguiente salto por la del peer que utiliza el atributo, que este si que
hablaría iBGP. Nos sucede en el caso de R3 para advertir las rutas del AS
62300 y tambien nos sucede con JUN1 y JUN2 que advertiran de las
rutas del AS 2300.
Actualmente en nuestras tablas BGP de JUN1 y JUN2 vemos que como R3
no tiene el next-hop-self los peers iBGP no pueden ver las redes del AS
62300 :
Salida comando JUN2
CONFIGURACIÓN NEXT-HOP-SELF
R3(config)# router bgp 61003
R3(config-router)# neighbor 10.0.0.2 next-hop-self – le pasamos a
JUN1 el next-hop-self
R3(config-router)# neighbor 10.0.0.3 next-hop-self – le pasamos a
JUN2 el next-hop-self
R3(config-router)# ^Z
R3# wr
Creamos la policy next-hop-self y la aplicaremos bajo BGP :
root@JUN1# set policy-options policy-statement next-hop-self
term 1 from protocol bgp
Indicamos que haremos con las rutas BGP “next-hop sel” :
root@JUN1# set policy-options policy-statement next-hop-self
term 1 then next-hop self
Aplicamos la policy al grupo iBGP para que ya puedan ver las redes del
AS 2300, ya que
el next-hop lo hemos modificado :
root@JUN1# set protocols bgp group ibgp export next-hop-self
root@JUN1# commit
Creamos la policy next-hop-self y la aplicaremos bajo BGP :
root@JUN2# set policy-options policy-statement next-hop-self
term 1 from protocol bgp
Indicamos que haremos con las rutas BGP “next-hop sel” :
root@JUN2# set policy-options policy-statement next-hop-self
term 1 then next-hop self
Aplicamos la policy al grupo iBGP para que ya puedan ver las redes del
AS 2300, ya que
el next-hop lo hemos modificado :
root@JUN2# set protocols bgp group ibgp export next-hop-self
root@JUN2# commit
Ahora que ya hemos cambiado el next-hop del router eBGP ya podremos
ver las rutas del AS 62300 por los peers iBGP :
root@JUN1# run show route protocol bgp
inet.0: 17 destinations, 22 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 00:02:41, MED 0, localpref 100
AS path: 62300 I
> to 10.0.0.1 via em1.0
2.2.2.2/32 *[BGP/170] 00:02:41, MED 0, localpref 100
AS path: 62300 I
> to 10.0.0.1 via em1.0
3.3.3.3/32 *[BGP/170] 00:02:41, MED 0, localpref 100
AS path: I
> to 10.0.0.1 via em1.0
5.5.5.5/32 [BGP/170] 23:51:15, localpref 100
AS path: I
> to 10.0.0.3 via em1.0
10.0.0.0/25 [BGP/170] 00:02:41, MED 0, localpref 100
AS path: I
> to 10.0.0.1 via em1.0
[BGP/170] 23:51:15, localpref 100
AS path: I
> to 10.0.0.3 via em1.0
43.11.10.56/29 [BGP/170] 23:51:15, localpref 100
AS path: I
> to 10.0.0.3 via em1.0
75.1.10.16/28 *[BGP/170] 00:02:41, MED 0, localpref 100
AS path: 62300 ?
> to 10.0.0.1 via em1.0
75.1.10.17/32 *[BGP/170] 00:02:41, MED 1, localpref 100
AS path: 62300 ?
> to 10.0.0.1 via em1.0
85.8.2.8/29 *[BGP/170] 00:02:41, MED 0, localpref 100
AS path: 62300 ?
> to 10.0.0.1 via em1.0
85.8.2.9/32 *[BGP/170] 00:02:41, MED 1, localpref 100
AS path: 62300 ?
> to 10.0.0.1 via em1.0
178.100.10.32/27 *[BGP/170] 00:02:41, MED 0, localpref 100
AS path: 62300 ?
> to 10.0.0.1 via em1.0
Vamos a configurar ahora JUN3 para que publique sus redes internas
mediante eBGP. Para ello aplicaremos una policy que las publicara al
grupo eBGP:
root@JUN3# set policy-options policy-statement bgp-routes term
1 from protocol direct
root@JUN3# set policy-options policy-statement bgp-routes term
1 from protocol bgp
root@JUN3# set policy-options policy-statement bgp-routes term
1 then accept
root@JUN3# set protocols bgp group ebgp export bgp-routes
root@JUN3# commit
Ahora ya podremos ver como JUN3 publica sus redes :
R1# show ip bgp
BGP table version is 70, local router ID is 75.1.10.17
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 96.130.5.130 0 0
61003 i
*> 4.4.4.4/32 96.130.5.130 0
61003 i
*> 5.5.5.5/32 96.130.5.130 0
61003 i
*> 10.0.0.0/25 96.130.5.130 0 0
61003 i
*> 43.11.10.56/29 96.130.5.130 0
61003 i
*> 75.1.10.16/28 0.0.0.0 0 32768 ?
*> 85.8.2.9/32 178.100.10.34 1 32768 ?
*> 172.16.0.0/24 96.130.5.130 0
61003 2300 i
*> 172.32.32.0/25 96.130.5.130 0
61003 2300 i
*> 172.64.64.0/26 96.130.5.130 0
61003 2300 i
*> 178.100.10.32/27 0.0.0.0 0 32768 ?
*> 198.80.90.20/30 96.130.5.130 0
61003 i
Ahora vamos a ver que pasa cuando utilizamos el atributo AGGREGATE
para advertir de una red sumarizada mediante BGP. Esto lo vamos a
hacer en JUN3. Borraremos la policy que hizimos anteriormente para
configurar la red a sumarizar :
root@JUN3# delete policy-options policy-statement bgp-routes
root@JUN3# delete protocols bgp group ebgp export bgp-routes
root@JUN3# commit
root@JUN3# set policy-options policy-statement bgp-aggregate
term 1 from protocol aggregate
root@JUN3# set policy-options policy-statement bgp-aggregate
term 1 then accept
root@JUN3# set protocols bgp group ebgp export bgp-aggregate
root@JUN3# commit
Verificamos que ahora solo tendremos la red sumarizada en nuestra
tabla BGP :
R1# show ip bgp
BGP table version is 70, local router ID is 75.1.10.17
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 96.130.5.130 0 0
61003 i
*> 4.4.4.4/32 96.130.5.130 0
61003 i
*> 5.5.5.5/32 96.130.5.130 0
61003 i
*> 10.0.0.0/25 96.130.5.130 0 0
61003 i
*> 43.11.10.56/29 96.130.5.130 0
61003 i
*> 75.1.10.16/28 0.0.0.0 0 32768 ?
*> 85.8.2.9/32 178.100.10.34 1 32768 ?
*> 172.0.0.0/9 96.130.5.130 0
61003 2300 i
*> 178.100.10.32/27 0.0.0.0 0 32768 ?
*> 198.80.90.20/30 96.130.5.130 0
61003 i
Este atributo resulta muy interesante en caso de que podamos sumarizar
prefijos de las subredes de un Sistema Autonomo y nos ayudaran a
preservar CPU y memoria de los routers.
Pasaremos ahora configurar otro atributo como es AS_PATH. En nuestra
topología queremos que las rutas que van hacia el AS 62300 subred
85.8.2.8/29 y 75.1.10.16/28 pasen a traves del enlace entre JUN3 y JUN1
y para ello indicaremos a JUN3 que la cantidad de saltos por el enlace
entre JUN3 y JUN2 son elevados que por el enlace entre JUN3 y JUN1.
Tambien queremos que la subred 178.100.10.32/27 pase
obligatoriamente por el enlace entre JUN3 a JUN2, en lugar de ir por
JUN1.
Actual sistema de rutas de JUN3 hacia el AS62300 subredes 85.8.2.8/29,
75.1.10.16/28 y 178.100.10.32/27 :
root@JUN3# run show route protocol bgp
inet.0: 20 destinations, 28 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
…
75.1.10.16/28 *[BGP/170] 00:00:41, localpref 100
AS path: 61003 62300 ?
> to 43.11.10.57 via em1.0
[BGP/170] 00:00:41, localpref 100
AS path: 61003 62300 ?
> to 198.80.90.21 via em0.0
75.1.10.17/32 *[BGP/170] 00:00:41, localpref 100
AS path: 61003 62300 ?
> to 43.11.10.57 via em1.0
[BGP/170] 00:00:41, localpref 100
AS path: 61003 62300 ?
> to 198.80.90.21 via em0.0
85.8.2.8/29 *[BGP/170] 00:00:41, localpref 100
AS path: 61003 62300 ?
> to 43.11.10.57 via em1.0
[BGP/170] 00:00:41, localpref 100
AS path: 61003 62300 ?
> to 198.80.90.21 via em0.0
85.8.2.9/32 *[BGP/170] 00:00:39, localpref 100
AS path: 61003 62300 ?
> to 198.80.90.21 via em0.0
[BGP/170] 00:00:39, localpref 100
AS path: 61003 62300 ?
> to 43.11.10.57 via em1.0
178.100.10.32/27 *[BGP/170] 00:00:41, localpref 100
AS path: 61003 62300 ?
> to 43.11.10.57 via em1.0
[BGP/170] 00:00:41, localpref 100
AS path: 61003 62300 ?
> to 198.80.90.21 via em0.0
CONFIGURACIÓN AS_PATH JUN2
Creamos una policy para hacer match de la subred 85.8.2.8/29 y sus
derivadas con prefijos más largos :
root@JUN2# set policy-options policy-statement AS-PATH-
PREPEND term 1 from route-filter 85.8.2.8/29 orlonger
Vamos a engañar a los peers y anunciaremos que tienen que realizar un
salto más. Es decir, antes tenían que para ir por el enlace de JUN3 a JUN2
: 61003 62300 , ahora si añadimos un AS de más veremos que hay un
salto más y sería : 61003 61003 62300 :
root@JUN2# set policy-options policy-statement AS-PATH-
PREPEND term 1 then as-path-prepend “61003″ accept
Creamos otra policy para hacer match de la subred 75.1.10.16/28 y sus
derivadas con prefijos más largos :
root@JUN2# set policy-options policy-statement AS-PATH-
PREPEND2 term 1 from route-filter 75.1.10.16/28 orlonger
En este caso añadiremos en lugar de un salto, dos y quedaría así : 61003
61003 61003 62300 :
root@JUN2# set policy-options policy-statement AS-PATH-
PREPEND2 term 1 then as-path-prepend “61003 61003″ accept
Exportamos las poolíticas al group eBGP :
root@JUN2# set protocols bgp group ebgp export AS-PATH-
PREPEND
root@JUN2# set protocols bgp group ebgp export AS-PATH-
PREPEND2
Ahora haremos los mismo con JUN1 pero nos interesa solo augmentar los
saltos para la subred 178.100.10.32/27, por lo que esa ruta ira por el
enlace de JUN3 a JUN2, dado que tiene un salto menos .
CONFIGURACIÓN AS_PATH JUN1
root@JUN1# set policy-options policy-statement AS-PATH-
PREPEND term 1 from route-filter 178.100.10.32/27 orlonger
root@JUN1# set policy-options policy-statement AS-PATH-
PREPEND term 1 then as-path-prepend “61003″ accept
root@JUN1# set protocols bgp group ebgp export AS-PATH-
PREPEND
Comprovamos ahora si la cantidad de saltos se ha visto alterada en las
tablas de routing :
root@JUN3# run show route protocol bgp 85.8.2.8/29
inet.0: 20 destinations, 28 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
85.8.2.8/29 *[BGP/170] 00:01:05, localpref 100
AS path: 61003 62300 ? – Cojera este enlace porque tiene menos
saltos
> to 198.80.90.21 via em0.0
[BGP/170] 00:04:52, localpref 100
AS path: 61003 61003 62300 ? – Hemos añadido un salto más
> to 43.11.10.57 via em1.0
85.8.2.9/32 *[BGP/170] 00:01:05, localpref 100
AS path: 61003 62300 ?
> to 198.80.90.21 via em0.0
[BGP/170] 00:04:52, localpref 100
AS path: 61003 61003 62300 ?
> to 43.11.10.57 via em1.0
Anteriormente pusimo en el route-filter que queríamo hacer match con la
subred en concreto y los prefijos más largos, esto lo hicimos porque
como para esta subred hemos utilizado una dirección loopback el router
BGP R1 y R2 y estos publican las subredes y tambien el /32 de la
loopback. Para probar si es verdad haremos un traceroute de la red :
root@JUN3# run traceroute 85.8.2.9
traceroute to 85.8.2.9 (85.8.2.9), 30 hops max, 40 byte packets
1 198.80.90.21 (198.80.90.21) 2.838 ms 2.188 ms 1.444 ms
2 10.0.0.1 (10.0.0.1) 1.891 ms 1.561 ms 2.130 ms
3 96.130.5.129 (96.130.5.129) 13.525 ms 6.791 ms 7.161 ms
4 178.100.10.34 (178.100.10.34) 6.358 ms * 6.935 ms
Efectivamente vemos que se coje el camino con menos saltos el enlace
entre JUN3 y JUN1.
Vamos a ver que sucede con la subred 178.100.10.32/27 en la que en
JUN1 añadimos un salto de más para obligar a llegar a esa subred por el
enlace de JUN3 a JUN2:
root@JUN3# run show route protocol bgp 178.100.10.32/27
inet.0: 20 destinations, 28 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
178.100.10.32/27 *[BGP/170] 00:00:09, localpref 100
AS path: 61003 62300 ? – Utilizará el camino de JUN3 a JUN2
> to 43.11.10.57 via em1.0
[BGP/170] 00:04:02, localpref 100
AS path: 61003 61003 62300 ? - Ha añadido un AS de más
> to 198.80.90.21 via em0.0
Efectivamente se ha añadido. Ahora vamos a hacer el traceroute para
verificarlo :
root@JUN3# run traceroute 178.100.10.35
traceroute to 178.100.10.35 (178.100.10.35), 30 hops max, 40 byte
packets
1 43.11.10.57 (43.11.10.57) 1.248 ms 2.876 ms 2.753 ms
2 10.0.0.1 (10.0.0.1) 3.043 ms 2.728 ms 1.650 ms
3 96.130.5.129 (96.130.5.129) 12.926 ms 6.955 ms 6.718 ms
4 178.100.10.35 (178.100.10.35) 6.998 ms
Efectivamente vemos que coje el camino con menos saltos, el enlace
entre JUN3 y JUN2.
Vamos ahora configurar el atributo LOCAL_PREF. El local preference se
informa a los vecinos iBGP y sirve para establecer la salida del Sistema
Autonomo. En nuestra topología marcaremos con LOCAL_PREF 250 el
router JUN2 para que todos los origines salgan por ese router . El estado
actual de los valores LOCAL_PREF en el AS 61003 es el siguiente :
R3# show ip bgp
BGP table version is 223, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight
Path
*> 1.1.1.1/32 96.130.5.129 0 0
62300 i
*> 2.2.2.2/32 200.10.50.81 0 0
62300 i
*> 3.3.3.3/32 0.0.0.0 0
32768 i
r>i4.4.4.4/32 10.0.0.2 100
0 i
r>i5.5.5.5/32 10.0.0.3 100
0 i
* i10.0.0.0/25 10.0.0.2 100
0 i
* i 10.0.0.3 100
0 i
*> 0.0.0.0 0
32768 i
r>i43.11.10.56/29 10.0.0.3 100 0
i
*> 75.1.10.16/28 96.130.5.129 0 0
62300 ?
*> 75.1.10.17/32 200.10.50.81 1
0 62300 ?
*> 85.8.2.8/29 200.10.50.81 0
0 62300 ?
*> 85.8.2.9/32 96.130.5.129 1
0 62300 ?
*>i172.0.0.0/9 198.80.90.22 100
0 2300 i
* i 43.11.10.58 100
0 2300 i
* 178.100.10.32/27 200.10.50.81 0
0 62300 ?
*> 96.130.5.129 0 0
62300 ?
r>i198.80.90.20/30 10.0.0.2 100
0 i
Y desde el switch del AS 62300 haremos un traceroute contra una
subred que se encuentra en el AS 2300 :
swAS62300# traceroute 172.64.64.1
Type escape sequence to abort.
Tracing the route to 172.64.64.1
1 178.100.10.34 0 msec 0 msec 4 msec
2 200.10.50.82 12 msec 12 msec 16 msec
3 10.0.0.2 16 msec 12 msec 12 msec – Sale por JUN1
4 172.64.64.1 20 msec 20 msec 16 msec
Ahora vamos a configurar el local preference en JUN2 para que propague
por los vecinos iBGP que va a tener la prioridad más grande para la
salida del AS 61003.
CONFIGURACIÓN LOCAL_PREF JUN1
root@JUN1# set protocols bgp group ibgp local-preference 250
Ahora comprobaremos que nuestros vecions iBGP han actualizado sus
tablas BGP para saber por donde van a tener que salir :
R3# show ip bgp
BGP table version is 232, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 96.130.5.129 0 0
62300 i
*> 2.2.2.2/32 200.10.50.81 0 0
62300 i
*> 3.3.3.3/32 0.0.0.0 0
32768 i
r>i4.4.4.4/32 10.0.0.2 100 0 i
r>i5.5.5.5/32 10.0.0.3 250
0 i
* i10.0.0.0/25 10.0.0.3 250
0 i
* i 10.0.0.2 100 0 i
*> 0.0.0.0 0 32768 i
r>i43.11.10.56/29 10.0.0.3 250
0 i
*> 75.1.10.16/28 96.130.5.129 0 0
62300 ?
*> 75.1.10.17/32 200.10.50.81 1 0
62300 ?
*> 85.8.2.8/29 200.10.50.81 0 0
62300 ?
*> 85.8.2.9/32 96.130.5.129 1 0
62300 ?
*>i172.0.0.0/9 43.11.10.58 250 0
2300 i
* 178.100.10.32/27 200.10.50.81 0 0
62300 ?
*> 96.130.5.129 0 0
62300 ?
r>i198.80.90.20/30 10.0.0.2 100 0 i
Comprovaremos el funcionamiento de este atributo lanzando un
traceroute desde el switch del AS 62300 para ver que camino realizamos
:
swAS62300# traceroute 172.64.64.1
Type escape sequence to abort.
Tracing the route to 172.64.64.1
1 178.100.10.34 0 msec 0 msec 4 msec
2 200.10.50.82 12 msec 12 msec 16 msec
3 10.0.0.3 20 msec 16 msec 12 msec – Pasa por JUN2
4 172.64.64.1 20 msec 16 msec 16 msec
Para que veais como JUN1 tambien ha sido advertido del local-preference
os dejo tambien la salida equivalente al “show ip bgp” de Cisco pero en
Juniper :
root@JUN1# run show route terse protocol bgp
inet.0: 17 destinations, 22 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 1.1.1.1/32 B 170 100 0 >10.0.0.1 62300 I
* 2.2.2.2/32 B 170 100 0 >10.0.0.1 62300 I
* 3.3.3.3/32 B 170 100 0 >10.0.0.1 I
5.5.5.5/32 B 170 250 >10.0.0.3 I
10.0.0.0/25 B 170 250 >10.0.0.3 I
B 170 100 0 >10.0.0.1 I
43.11.10.56/29 B 170 250 >10.0.0.3 I
* 75.1.10.16/28 B 170 100 0 >10.0.0.1 62300 ?
* 75.1.10.17/32 B 170 100 1 >10.0.0.1 62300 ?
* 85.8.2.8/29 B 170 100 0 >10.0.0.1 62300 ?
* 85.8.2.9/32 B 170 100 1 >10.0.0.1 62300 ?
* 172.0.0.0/9 B 170 250 >10.0.0.3
2300 I
B 170 100 >198.80.90.22 2300 I
* 178.100.10.32/27 B 170 100 0 >10.0.0.1 62300 ?
Queremos aplicar el atributo MED, Multi Exit Discriminator. En nuestra
topología porque queremos que la entrada al Sistema Autonomo 62300
para la subred 178.100.10.32/27 se realice a traves del enlace entre R3
y R1 y las demás subredes entraran al AS por el enlace entre R3 y R2.
CONFIGURACIÓN MED R1
Creamos la Access-list que ara match con la subred 178.100.10.32/27 :
R1(config)# ip access-list standard match-med
R1(config)# permit 178.100.10.32 0.0.0.31
Creamos el route-map para marcar MED 5 a las subred que nos interesa
pase por el enlace entre R3 y R1 :
R1(config)# route-map MED-ATTRIB permit 10
R1(config-route-map)# match ip address match-med
R1(config-route-map)# set metric 5
R1(config-route-map)# exit
Marcamos las demas subredes con MED 10 para que pasen por el otro
enlace :
R1(config)# route-map MED-ATTRIB permit 20
R1(config-route-map)# set metric 10
R1(config-route-map)# exit
Aplicamos el atributo con el vecino eBGP y de salida “out” porque se
trata de advertir a los vecinos eBGP :
R1(config)# router bgp 62300
R1(config-router)# neighbor 96.130.5.130 route-map MED-ATTRIB
out
CONFIGURACIÓN MED R2
Creamos la Access-list que ara match con la subred 178.100.10.32/27:
R2(config)# ip access-list standard match-med
R2(config)# permit 178.100.10.32 0.0.0.31
Creamos el route-map para marcar MED 10 a la subred
178.100.10.32/27 que no nos interesa que pase por el enlace entre R3 y
R2 :
R2(config)# route-map MED-ATTRIB permit 10
R2(config-route-map)# match ip address match-med
R2(config-route-map)# set metric 10
A las demás subredes las marcamos con MED 5 porque queremos que
pasen por el enlace entre R3 y R2
R2(config)# route-map MED-ATTRIB permit 20
R2(config-route-map)# set metric 5
R2(config-route-map)# exit
Aplicamos el atributo con el vecino eBGP y de salida “out” porque se
trata de advertir a los vecinos eBGP :
R2(config)# router bgp 62300
R2(config-router)# neighbor 200.10.50.82 route-map MED-ATTRIB
out
CONFIGURACIÓN R3
Es importante configurar a R3 para que sepa que tiene que comparar los
MED recividos de sus vecinos del mismo AS para saber que MED tiene
que cojer con mejor camino.
R3(config)# router bgp 61003
R3(config-router)# bgp deterministic-med
Comprobamos el resultado del MED :
root@JUN3# run traceroute 178.100.10.35
traceroute to 178.100.10.35 (178.100.10.35), 30 hops max, 40 byte
packets
1 43.11.10.57 (43.11.10.57) 2.169 ms 2.028 ms 1.024 ms
2 10.0.0.1 (10.0.0.1) 1.259 ms 2.345 ms 1.662 ms
3 96.130.5.129 (96.130.5.129) 15.741 ms 6.584 ms 6.723 ms
4 178.100.10.35 (178.100.10.35) 6.614 ms * 6.804 ms
Podemos comprovar que pasa por el enlace entre R3 y R1. Ahora
veremos como organiza R3 su tabla BGP para escojer las rutas con el
MED más bajo :
R3# show ip bgp
BGP table version is 287, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
* 1.1.1.1/32 200.10.50.81 5 0
62300 ?
*> 96.130.5.129 10 0
62300 i
* 2.2.2.2/32 96.130.5.129 10 0
62300 ?
*> 200.10.50.81 5 0
62300 i
*> 3.3.3.3/32 0.0.0.0 0
32768 i
r>i4.4.4.4/32 10.0.0.2 100 0 i
r>i5.5.5.5/32 10.0.0.3 250 0 i
* i10.0.0.0/25 10.0.0.3 250 0 i
* i 10.0.0.2 100 0 i
*> 0.0.0.0 0
32768 i
r>i43.11.10.56/29 10.0.0.3 250 0 i
*> 75.1.10.16/28 96.130.5.129 10 0
62300 ?
*> 75.1.10.17/32 200.10.50.81 5 0
62300 ?
*> 85.8.2.8/29 200.10.50.81 5 0
62300 ?
*> 85.8.2.9/32 96.130.5.129 10 0
62300 ?
*>i172.0.0.0/9 43.11.10.58 250 0 2300
i
*> 178.100.10.32/27 96.130.5.129 5
0 62300 ?
* 200.10.50.81 10 0
62300 ?
r>i198.80.90.20/30 10.0.0.2 100 0 i
Si realizamos otra trazada vemos que cogeremos el enlace entre R3 y R2
:
root@JUN3# run traceroute 2.2.2.2
traceroute to 2.2.2.2 (2.2.2.2), 30 hops max, 40 byte packets
1 198.80.90.21 (198.80.90.21) 3.061 ms 2.809 ms 2.693 ms
2 10.0.0.1 (10.0.0.1) 2.384 ms 1.935 ms 2.960 ms
3 200.10.50.81 (200.10.50.81) 6.271 ms * 6.749 ms
Para el caso del atributo WEIGHT vamos a utilizar este atributo
propietario de Cisco para indicar que rutas tienen más preferencia que
otras para la salida del Sistema Autonomo por la parte de R3, ya que R3
es un equipo Cisco. Acordaros de que este atributo es a nivel local y lo
que hacemos es marcar las rutas recividas por los peers con un peso
prioritario que tendran para la salida. El peso más grande tiene más
prioridad.
El objetivo es que las rutas con origen 10.0.0.2, que es JUN1 que tengan
más peso que todas las demás rutas que nos lleguen de 10.0.0.3.
CONFIGURACIÓN WEIGHT R3
Configuramos WEIGHT 500 para las subredes que lleguen de JUN1 :
R3(conifg-router)# neighbor 10.0.0.2 weigh 500
Las demás subredes que nos lleguen de JUN2 les aplicamos WEIGHT
325 :
R3(conifg-router)# neighbor 10.0.0.3 weigh 325
Ahora comprobamos de nuevo la tabla BGP de R3 para ver si los cambios
se aplicaron :
R3# show ip bgp
BGP table version is 387, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i –
internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
* 1.1.1.1/32 200.10.50.81 5 0
62300 ?
*> 96.130.5.129 10 0 62300
i
* 2.2.2.2/32 96.130.5.129 10 0
62300 ?
*> 200.10.50.81 5 0 62300
i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
r>i4.4.4.4/32 10.0.0.2 100 500 i
r>i5.5.5.5/32 10.0.0.3 250 325 i
* i10.0.0.0/25 10.0.0.2 100 500 i
* i 10.0.0.3 250 325 i
*> 0.0.0.0 0 32768 i
r>i43.11.10.56/29 10.0.0.3 250 325 i
*> 75.1.10.16/28 96.130.5.129 10 0
62300 ?
*> 75.1.10.17/32 200.10.50.81 5 0
62300 ?
*> 85.8.2.8/29 200.10.50.81 5 0
62300 ?
*> 85.8.2.9/32 96.130.5.129 10 0
62300 ?
*>i172.0.0.0/9 43.11.10.58 250 325 2300 i
*> 178.100.10.32/27 96.130.5.129 5 0
62300 ?
* 200.10.50.81 10 0
62300 ?
r>i198.80.90.20/30 10.0.0.2 100 500 i
Solo nos queda hablar de COMMUNITY. Para ello utilizaremos un tipo de
community standard que será la ” no-export “, porque no nos interesa
publicar las subredes 3.3.3.3/32 , 4.4.4.4/32 y 5.5.5.5/32. Vamos a
configurar R3 para que transmita la community :
CONFIGURACIÓN R3 COMMUNITY
Hacemos match de la red que nos interesa :
R3(conifg)# ip prefix-list MATCH-COMM permit 3.3.3.3/32
Creamos un route-map que haga el match del prefix-list :
R3(config)# route-map COMMUNITY permit 10
R3(config-route-map)# match ip address prefix-list MATCH-COMM
Aplicamos la regla de no exportarlo
R3(config-route-map)# set community no-export
R3(config-route-map)# exit
Realizamos una segunda regla vacia para que las demás
no las marque como no-export
R3(config)# route-map COMMUNITY permit 20
Ahora pasaremos a los peers eBGP las community :
R3(config)# router bgp 61003
Le pasamos a R1 :
R3(config-router)# neighbor 96.130.5.129 send-community
R3(config-router)# neighbor 96.130.5.129 route-map COMMUNITY
out
Le pasamos a R2 :
R3(config-router)# neighbor 200.10.50.81 send-community
R3(config-router)# neighbor 200.10.50.81 route-map COMMUNITY
out
Ahora el AS 62300 tendría que pasar los parametros community a sus
vecinos para indicarles que la subred 3.3.3.3/32 no se publicara porque
es una community ” no export “. Imaginemos que R1 esta conectado al
AS 250 on la IP 156.20.25.1 . Solo tendríamos que pasarle los
parametros de la siguiente forma :
R1(config-router)# neighbor 156.20.25.1 send-community
Y el AS 250 ya no podría ver la red 3.3.3.3/32.
Este artículo espero que sirva para entender a nivel global el
funcionamiento de este gran protocolo y su forma de tratar las rutas con
los atributos. He querido integrar dos tipos de fabricantes de dispositivos
para que se vea realmente el funcionamiento, dado que al ser un
protocolo standard eso no pueda suponer ningun problema.