bgp and attributes

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

http://netandsec.xtrweb.com/wp-content/uploads/2011/12/BGP-BLOG-2.jpg

( 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


R2> en

R2# conf t

R2(config)# router bgp 62300



R3> en

R3# conf t




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# commit


root@% cli

root@JUN2> edit





root@JUN2# set protocols bgp group ibgp type internal

root@JUN2# set protocols bgp group ibgp local-address 10.0.0.3



root@JUN2# commit


root@% cli

root@JUN3> edit






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



internal,




*> 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 :




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



internal,




*> 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 :




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



internal,




*> 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




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



internal,




*> 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



internal,




*> 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.

http://netandsec.xtrweb.com/wp-content/uploads/2011/12/BGP-BLOG-ATTRIB1.jpg

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 :


from protocol rip

Ponemos la política que sera aceptarlas :


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:


from protocol direct

Creamos otra regla dentro de la policy para advertir subredes recividas

mediante RIP :


from protocol rip

Ponemos la política que sera aceptarlas :


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



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



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


R 5.5.5.5 [120/1] via 10.0.0.3, 00:00:16, Ethernet0/0


R 198.80.90.20 [120/1] via 10.0.0.2, 00:00:17, Ethernet0/0


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)# redistribute ospf 1 metric 1

R2# conf t


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


B 1.1.1.1 [20/0] via 96.130.5.129, 01:06:32


B 2.2.2.2 [20/0] via 200.10.50.81, 01:06:32


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



internal,



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)# 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” :


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 :


term 1 from protocol bgp

Indicamos que haremos con las rutas BGP “next-hop sel” :


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



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


AS path: 62300 I

> to 10.0.0.1 via em1.0


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


AS path: 62300 ?

> to 10.0.0.1 via em1.0


AS path: 62300 ?

> to 10.0.0.1 via em1.0


AS path: 62300 ?

> to 10.0.0.1 via em1.0


AS path: 62300 ?

> to 10.0.0.1 via em1.0


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


1 from protocol bgp


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



internal,




*> 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



internal,




*> 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



…

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 :


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 :


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 :


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


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


PREPEND term 1 from route-filter 178.100.10.32/27 orlonger


PREPEND term 1 then as-path-prepend “61003″ accept


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



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



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 :


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



internal,



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



internal,




*> 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



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 :




Aplicamos el atributo con el vecino eBGP y de salida “out” porque se

trata de advertir a los vecinos eBGP :


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)# match ip address match-med


A las demás subredes las marcamos con MED 5 porque queremos que

pasen por el enlace entre R3 y R2




Aplicamos el atributo con el vecino eBGP y de salida “out” porque se

trata de advertir a los vecinos eBGP :


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 deterministic-med

Comprobamos el resultado del MED :


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



internal,




* 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

:


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



internal,




* 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


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 :


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 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 :


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.

bgp and attributes

Documents