BGP and attributes

Otra vez por aqu. Vamos a ver si podemos hacer una introduccin al protocolo por excelencia de las comunicaciones BGP ( Border Gateway Protocol ). Como una vez me dijo mi profesor de networking Podramos estar hablando de BGP durante das y das y aun nos faltara tiempo. Vamos a utilizar una topologa 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 adems de emular tambin mediante GNS3 routers Juniper. De esta manera tendremos una visin ms general de BGP y de su funcionamiento. A continuacin la topologa 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 Autnomos. Un Sistema Autnomo 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 caractersticas esenciales de BGP podemos enumerar las siguientes :

Utiliza TCP como mtodo de comunicacin y el puerto 179 Protocolo estandar Es un protocolo de vector de distancia Utiliza como mtrica los llamados path vectors que son unos parametros llamados Atributos Soporta VLSM La versin 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 pblico Del 64512 65535 son de uso privado

Y el Para establecer una relacin 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 travs de mensajes OPEN BGP.

KEEPALIVE Sistema Autonomo 65535 tambien esta reservado

RELACIONES DE VECINDAD BGP 1. : Son mensajes que se envan regularmente para mantener las sesiones entre los vecinos y la informacin del peer es almacenada a parte en una tabla de vecinos 2. NOTIFICATION : Mensaje utilizado cuando un peer es reseteado y se enva a los vecinos para indicar la finalizacin de la vecindad 3. UPDATE : Cuando se establece una relacin 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 relacin de vecindad solo se envaran este tipo de mensajes en caso de que se detecten cambios y en esta ocacin 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 sesin BGP.

CONNECT : BGP espera a que se complete la conexin del protocolo de transporte TCP mediante el puerto 179. En el caso de que la conexin se realice satisfactoriamente el estado pasa a la fase open sent y en caso contrario el estado cambiara a active

ACTIVE : Intenta establecer una relacin de vecindad iniciando la conexin a travs 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 conexin 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 nmero de Sistema Autonomo.

OPEN CONFIRM : Los routers esperan mensajes Keepalive. Si reciben estos mensajes de su vecino entonces la sesin 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 ms teorica del protocolo vamos a realizar las configuraciones bsicas BGP y a continuacin hablaremos de eBGP y la mtrica que utiliza llamada atributos con la que manipula el trfico de diferente manera. CONFIGURACIN BSICA 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

CONFIGURACIN BSICA R2 R2> en R2# conf t R2(config)# router bgp 62300 R2(config-router)# neighbor 200.10.50.82 remote-as 61003 CONFIGURACIN BSICA 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 CONFIGURACIN BSICA 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 direccin 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 CONFIGURACIN BSICA 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 CONFIGURACIN BSICA 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 COMPROBACIN DE ADYACENCIA Para corroborar que los peers han establecido sesin 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 10.0.0.2 10.0.0.3 V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 99 105 322 419 322 356 338 440 124 0 124 0 124 0 124 0 0 00:00:30 0 00:04:22 0 00:05:06 0 03:26:26 3 3 4 4 4 61003 4 61003

96.130.5.129 4 62300 200.10.50.81 4 62300

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 inet.0 Peer 43.11.10.57 198.80.90.21 Tot Paths Act Paths Suppressed 16 AS 8 InPkt 0 0 OutPkt 153 160 130 130 History Damp State 0 0 Pending

OutQ Flaps Last Up/Dwn 0 0 0 0 58:10 0/8/8/0 58:10 8/8/8/0 0/0/0/0 0/0/0/0

State|#Active/Received/Accepted/Damped 61003 61003

root@JUN3> show bgp neighbor Peer: 43.11.10.57+63894 AS 61003 Local: 43.11.10.58+179 AS 2300 Type: External Last Error: None Export: [ rip-routes ] Options: <Preference PeerAS Refresh> Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 5.5.5.5 Keepalive Interval: 30 Local ID: 172.32.32.1 Peer index: 0 Active Holdtime: 90 State: Established Flags: <ImportEval Sync> Last State: OpenConfirm Last Event: RecvKeepAlive

Ahora que tenemos la configuracin mnima 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 comunicacin y tambien en los routers Juniper hay que activar la propagacin de BGP. Esto lo explicaremos ms adelante pero no os preocupeis porque es normal. ATRIBUTOS BGP

Hablando vulgarmente podramos decir que los atributos BGP son la mtrica que utiliza BGP para distribuir rutas, informar del mejor camino Vamos a nombrar los atributos ms 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 seccin 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 *> 1.1.1.1/32 *> 2.2.2.2/32 *> 3.3.3.3/32 r>i4.4.4.4/32 r>i5.5.5.5/32 Next Hop 96.130.5.129 200.10.50.81 0.0.0.0 10.0.0.2 10.0.0.3 Metric 0 0 0 100 100 LocPrf Weight 0 0 32768 0 0 Path 62300 i 62300 i i i 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 direccin ip de siguiente salto que vamos a utilizar para alcanzar una red destino. Podemos ver sus propiedades en la seccin 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 *> 1.1.1.1/32 *> 2.2.2.2/32 *> Next Hop 96.130.5.129 200.10.50.81 96.130.5.129 Metric LocPrf Weight Path 0 0 0 0 0 0 0 0 62300 i 62300 i 62300 ? 62300 ?

* 178.100.10.32/27 200.10.50.81

* 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 veramos 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 *> 1.1.1.1/32 *> 2.2.2.2/32 Next Hop 96.130.5.129 200.10.50.81 Metric LocPrf Weight Path 0 0 0 0 0 0 62300 i 62300 i 62300 ?

*> 75.1.10.16/28 96.130.5.129 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 > via em1.0 75.1.10.16/28 *[BGP/170] 00:02:09, localpref 100 *[Direct/0] 02:27:13

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. El valor ms 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 *> 1.1.1.1/32 *> 2.2.2.2/32 *> 3.3.3.3/32 r>i4.4.4.4/32 r>i5.5.5.5/32 Next Hop 96.130.5.129 200.10.50.81 0.0.0.0 10.0.0.2 10.0.0.3 Metric 0 0 0 100 100 LocPrf Weight 0 0 32768 0 0 Path 62300 i 62300 i i i 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 especficas. Esto ayuda a preservar ms 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 redistribucin. Se suele utilizar los llamados route-maps en Cisco y para Juniper utilizaremos los policy options . Las communities ms 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 ningn peer local-as: Enva esta ruta a otros peers en otros subsistemas autnomos dentro de la misma confederacin local

MULTI_EXIT_DISC El atributo MED, tambin conocido como mtrica, 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 ms bajo sea el valor es ms preferible. Ac ontinuacin 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 *> 1.1.1.1/32 *> 2.2.2.2/32 WEIGHT Weight es un atributo especfico de Cisco y no se propaga a otros routers, dado que se define a nivel local del router. Los valores del weight estn 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 seleccin del path a los peers externos de BGP. La diferencia principal es que el weight no se enva entre peers y la local preference se enva entre peers iBGP. Podemos ver el valor actual del weight de la siguiente forma : Next Hop 96.130.5.129 200.10.50.81 Metric 0 0 LocPrf Weight 0 0 Path 62300 i 62300 i

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 *> 1.1.1.1/32 *> 2.2.2.2/32 *> 3.3.3.3/32 Next Hop 96.130.5.129 200.10.50.81 0.0.0.0 Metric 0 0 0 LocPrf Weight 0 0 32768 Path 62300 i 62300 i i

Ahora procederemos a poner en practica los atributos en nuestra topologa :

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 cado se descarta el path. 2. Si el path es interno, la sincronizacin 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 ASPath ms 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 ms pequeo. 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 ms 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 . CONFIGURACIN IGP R3 R3(config)# router rip R3(config-router)# ver 2 configuramos la versin 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 CONFIGURACIN 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 poltica que sera aceptarlas : root@JUN1# set policy-options policy-statement rip-routes term 1 then accept Exportamos la polcy 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 CONFIGURACIN 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 poltica que sera aceptarlas : root@JUN2# set policy-options policy-statement rip-routes term 1 then accept Exportamos la polcy 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 43.11.10.56/29 224.0.0.9/32 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 MultiRecv R3# show ip route rip 4.0.0.0/32 is subnetted, 1 subnets R R 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 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 198.80.90.20 [120/1] via 10.0.0.2, 00:00:17, Ethernet0/0 *[RIP/100] 16:12:54, metric 1 *[RIP/100] 16:59:38, metric 2, tag 0 loopback de JUN2 > to 10.0.0.3 via em1.0 *[RIP/100] 16:59:38, metric 2, tag 0 Interfaz connectada de JUN2 *[RIP/100] 16:10:23, metric 1 > to 10.0.0.3 via em1.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 redistribucin por BGP. As los dems 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 B B B B B B 85.8.2.9/32 [20/1] via 96.130.5.129, 01:06:32 85.8.2.8/29 [20/0] via 200.10.50.81, 01:06:32 1.1.1.1 [20/0] via 96.130.5.129, 01:06:32 2.2.2.2 [20/0] via 200.10.50.81, 01:06:32 178.100.10.32 [20/0] via 96.130.5.129, 01:06:32 75.1.10.16/28 [20/0] via 96.130.5.129, 01:06:32 75.1.10.17/32 [20/1] via 200.10.50.81, 01:06:32

1.0.0.0/32 is subnetted, 1 subnets 2.0.0.0/32 is subnetted, 1 subnets 178.100.0.0/27 is subnetted, 1 subnets 75.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

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 *> 1.1.1.1/32 *> 2.2.2.2/32 *> 3.3.3.3/32 r>i4.4.4.4/32 r>i5.5.5.5/32 * i10.0.0.0/25 *i *> r>i43.11.10.56/29 *> 75.1.10.16/28 *> 75.1.10.17/32 *> 85.8.2.8/29 *> 85.8.2.9/32 *> 178.100.10.32/27 * r>i198.80.90.20/30

Next Hop 96.130.5.129 200.10.50.81 0.0.0.0 10.0.0.2 10.0.0.3 10.0.0.2 10.0.0.3 0.0.0.0 10.0.0.3 96.130.5.129 200.10.50.81 200.10.50.81 96.130.5.129 96.130.5.129 200.10.50.81 10.0.0.2

Metric LocPrf 0 0 0 0 0 100 100 100 100 0 100 0 1 0 1 0 0 100

Weight

Path 62300 i 62300 i

32768 0 0 0 0 32768 0 0 0 0 0 0 0 0

i i i i i i i 62300 ? 62300 ? 62300 ? 62300 ? 62300 ? 62300 ? 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 hablara 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 nexthop-self los peers iBGP no pueden ver las redes del AS 62300 : Salida comando JUN2 CONFIGURACIN 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 AS path: I > to 10.0.0.1 via em1.0 5.5.5.5/32 [BGP/170] 23:51:15, localpref 100 *[BGP/170] 00:02:41, MED 0, localpref 100

AS path: I > to 10.0.0.3 via em1.0 10.0.0.0/25 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 AS path: I > to 10.0.0.3 via em1.0 75.1.10.16/28 AS path: 62300 ? > to 10.0.0.1 via em1.0 75.1.10.17/32 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 : *[BGP/170] 00:02:41, MED 1, localpref 100 *[BGP/170] 00:02:41, MED 0, localpref 100 [BGP/170] 23:51:15, localpref 100 [BGP/170] 00:02:41, MED 0, localpref 100

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 *> 1.1.1.1/32 *> 3.3.3.3/32 *> 4.4.4.4/32 *> 5.5.5.5/32 *> 10.0.0.0/25 *> 43.11.10.56/29 *> 75.1.10.16/28 *> 85.8.2.9/32 *> 172.16.0.0/24 *> 172.32.32.0/25 *> 172.64.64.0/26 *> 178.100.10.32/27 Next Hop 0.0.0.0 96.130.5.130 96.130.5.130 96.130.5.130 96.130.5.130 96.130.5.130 0.0.0.0 178.100.10.34 96.130.5.130 96.130.5.130 96.130.5.130 0.0.0.0 0 0 1 0 Metric 0 0 LocPrf Weight 32768 0 0 0 0 0 32768 32768 0 0 0 32768 0 Path i 61003 i 61003 i 61003 i 61003 i 61003 i ? ? 61003 2300 i 61003 2300 i 61003 2300 i ? 61003 i

*> 198.80.90.20/30 96.130.5.130

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 *> 1.1.1.1/32 *> 3.3.3.3/32 *> 4.4.4.4/32 *> 5.5.5.5/32 *> 10.0.0.0/25 *> 43.11.10.56/29 *> 75.1.10.16/28 *> 85.8.2.9/32 *> 172.0.0.0/9 *> 178.100.10.32/27 Next Hop 0.0.0.0 96.130.5.130 96.130.5.130 96.130.5.130 96.130.5.130 96.130.5.130 0.0.0.0 178.100.10.34 96.130.5.130 0.0.0.0 0 0 1 0 Metric 0 0 LocPrf Weight 32768 0 0 0 0 0 32768 32768 0 32768 0 Path i 61003 i 61003 i 61003 i 61003 i 61003 i ? ? 61003 2300 i ? 61003 i

*> 198.80.90.20/30 96.130.5.130

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 topologa 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 CONFIGURACIN AS_PATH JUN2 Creamos una policy para hacer match de la subred 85.8.2.8/29 y sus derivadas con prefijos ms largos : root@JUN2# set policy-options policy-statement AS-PATH-PREPEND term 1 from route-filter 85.8.2.8/29 orlonger Vamos a engaar a los peers y anunciaremos que tienen que realizar un salto ms. Es decir, antes tenan que para ir por el enlace de JUN3 a JUN2 : 61003 62300 , ahora si aadimos un AS de ms veremos que hay un salto ms y sera : 61003 61003 62300 : root@JUN2# set policy-options policy-statement AS-PATH-PREPEND term 1 then aspath-prepend 61003 accept Creamos otra policy para hacer match de la subred 75.1.10.16/28 y sus derivadas con prefijos ms 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 aadiremos en lugar de un salto, dos y quedara 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 poolticas 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 . CONFIGURACIN 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 aspath-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 aadido un salto ms > 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 queramo hacer match con la subred en concreto y los prefijos ms largos, esto lo hicimos porque como para esta subred hemos utilizado una direccin 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 aadimos un salto de ms 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 aadido un AS de ms > to 198.80.90.21 via em0.0 Efectivamente se ha aadido. 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 topologa 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 *> 1.1.1.1/32 *> 2.2.2.2/32 *> 3.3.3.3/32 r>i4.4.4.4/32 r>i5.5.5.5/32 * i10.0.0.0/25 *i *> r>i43.11.10.56/29 *> 75.1.10.16/28 *> 75.1.10.17/32 *> 85.8.2.8/29 *> 85.8.2.9/32 *>i172.0.0.0/9 *i * 178.100.10.32/27 *> r>i198.80.90.20/30 Next Hop 96.130.5.129 200.10.50.81 0.0.0.0 10.0.0.2 10.0.0.3 10.0.0.2 10.0.0.3 0.0.0.0 10.0.0.3 96.130.5.129 200.10.50.81 200.10.50.81 96.130.5.129 198.80.90.22 43.11.10.58 200.10.50.81 96.130.5.129 10.0.0.2 0 0 100 0 1 0 1 100 100 0 100 0 0 0 0 0 0 0 0 0 0 Metric LocPrf 0 0 0 100 100 100 100 0 0 32768 0 0 0 0 Weight Path 62300 i 62300 i i i i i i 32768 i i 62300 ? 62300 ? 62300 ? 62300 ? 2300 i 2300 i 62300 ? 62300 ? 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 ms grande para la salida del AS 61003. CONFIGURACIN 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 *> 1.1.1.1/32 *> 2.2.2.2/32 *> 3.3.3.3/32 r>i4.4.4.4/32 r>i5.5.5.5/32 * i10.0.0.0/25 *i *> r>i43.11.10.56/29 *> 75.1.10.16/28 *> 75.1.10.17/32 *> 85.8.2.8/29 *> 85.8.2.9/32 *>i172.0.0.0/9 * 178.100.10.32/27 *> r>i198.80.90.20/30 Next Hop 96.130.5.129 200.10.50.81 0.0.0.0 10.0.0.2 10.0.0.3 10.0.0.3 10.0.0.2 0.0.0.0 10.0.0.3 96.130.5.129 200.10.50.81 200.10.50.81 96.130.5.129 43.11.10.58 200.10.50.81 96.130.5.129 10.0.0.2 0 0 100 0 1 0 1 250 0 250 Metric 0 0 0 100 250 250 100 0 0 0 0 32768 0 0 0 0 0 0 0 0 0 LocPrf Weight Path 0 0 62300 i 62300 i 32768 i i i i i i i 62300 ? 62300 ? 62300 ? 62300 ? 2300 i 62300 ? 62300 ? 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 * 1.1.1.1/32 * 2.2.2.2/32 * 3.3.3.3/32 5.5.5.5/32 10.0.0.0/25 B 170 100 P Prf Metric 1 Metric 2 Next hop B 170 B 170 B 170 B 170 B 170 0 100 100 100 250 250 >10.0.0.1 250 100 100 100 100 250 100 0 0 1 0 1 0 0 0 >10.0.0.1 >10.0.0.1 >10.0.0.1 >10.0.0.3 >10.0.0.3 I >10.0.0.3 >10.0.0.1 >10.0.0.1 >10.0.0.1 >10.0.0.1 >10.0.0.3 >10.0.0.1 I 62300 ? 62300 ? 62300 ? 62300 ? 2300 I 62300 ? AS path 62300 I 62300 I I I I

43.11.10.56/29 B 170 * 75.1.10.16/28 B 170 * 75.1.10.17/32 B 170 * 85.8.2.8/29 * 85.8.2.9/32 * 172.0.0.0/9 B 170 100 B 170 B 170 B 170

>198.80.90.22 2300 I

* 178.100.10.32/27 B 170

Queremos aplicar el atributo MED, Multi Exit Discriminator. En nuestra topologa 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 dems subredes entraran al AS por el enlace entre R3 y R2. CONFIGURACIN 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 CONFIGURACIN 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 dems 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 CONFIGURACIN 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 ms 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 * 1.1.1.1/32 *> * 2.2.2.2/32 *> *> 3.3.3.3/32 r>i4.4.4.4/32 r>i5.5.5.5/32 * i10.0.0.0/25 *i *> r>i43.11.10.56/29 *> 75.1.10.16/28 *> 75.1.10.17/32 *> 85.8.2.8/29 *> 85.8.2.9/32 Next Hop Metric LocPrf 200.10.50.81 96.130.5.129 96.130.5.129 200.10.50.81 0.0.0.0 10.0.0.2 10.0.0.3 10.0.0.3 10.0.0.2 0.0.0.0 10.0.0.3 96.130.5.129 10 200.10.50.81 200.10.50.81 5 5 250 5 10 10 5 0 0 0 0 0 100 250 250 100 0 0 0 0 0 0 0 0 0 0 Weight Path 62300 ? 62300 i 62300 ? 62300 i 32768 i i i i i 32768 i i 62300 ? 62300 ? 62300 ? 62300 ?

96.130.5.129 10

*>i172.0.0.0/9 *> 178.100.10.32/27 * r>i198.80.90.20/30

43.11.10.58 96.130.5.129 5 200.10.50.81 10 10.0.0.2

250

0 0 0

2300 i 62300 ? 62300 ? i

100

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 ms 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 ms grande tiene ms prioridad. El objetivo es que las rutas con origen 10.0.0.2, que es JUN1 que tengan ms peso que todas las dems rutas que nos lleguen de 10.0.0.3. CONFIGURACIN WEIGHT R3 Configuramos WEIGHT 500 para las subredes que lleguen de JUN1 : R3(conifg-router)# neighbor 10.0.0.2 weigh 500 Las dems 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 * 1.1.1.1/32 *> * 2.2.2.2/32 *> *> 3.3.3.3/32 Next Hop 200.10.50.81 96.130.5.129 96.130.5.129 200.10.50.81 0.0.0.0 Metric LocPrf 5 10 10 5 0 0 0 0 0 32768 Weight Path 62300 ? 62300 i 62300 ? 62300 i i

r>i4.4.4.4/32 r>i5.5.5.5/32 * i10.0.0.0/25 *i *> r>i43.11.10.56/29 *> 75.1.10.16/28 *> 75.1.10.17/32 *> 85.8.2.8/29 *> 85.8.2.9/32 *>i172.0.0.0/9 * r>i198.80.90.20/30

10.0.0.2 10.0.0.3 10.0.0.2 10.0.0.3 0.0.0.0 10.0.0.3 96.130.5.129 200.10.50.81 200.10.50.81 96.130.5.129 43.11.10.58 5 10 200.10.50.81 10.0.0.2 10 5 5 10

100 250 100 250 0 250 0 0 0 0 250 0 0 100

500 325 500 325 32768 325

i i i i i i 62300 ? 62300 ? 62300 ? 62300 ?

325

2300 i 62300 ? 62300 ?

*> 178.100.10.32/27 96.130.5.129

500

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 : CONFIGURACIN 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 dems 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 tendra 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 tendramos que pasarle los parametros de la siguiente forma : R1(config-router)# neighbor 156.20.25.1 send-community Y el AS 250 ya no podra ver la red 3.3.3.3/32. Este artculo 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.