Un poco de BGP practico

El protocolo BGP-4 es un poco enredado en cuanto a que tiene muchas cosas que se han instaurado de facto, sin pensar en el Internet moderno que tenemos hoy en dia y eso dificulta enormemente cosas que decirlas resulta facil, pero que al tocar la configuración puedes liarla facilmente.

En primer lugar debemos pensar que el trafico que nosotros sacamos (OUT) lo decidimos nosotros, tenemos juego para hacer cosas,

pero el trafico que nos envían los demás, DECIDEN ellos por donde nos lo manda, y lo deciden en base a la información que tienen. Esto quiere decir que podemos INFLUIR, pero influir no es obligarles a enviarnoslo por donde nosotros queramos, ellos decidirán por donde nos lo mandan.

Voy a relatar los criterios de selección, pero no de forma tradicional, sino desde un punto de vista especialmente practico.

1. Weight – este solo sirve PARA decidir nosotros por donde enviamos, si lo usamos es el primer factor, mi consejo es que aplique un PESO 100 siempre de forma general y por route-map afines para ciertos destinos muy seleccionados. NUMERO MAYOR (ej.200) gana

2. LOCAL PREFERENCE. es como el weight, por defecto vale 100, el criteio igual que el WEIGHT, usa uno u otro.

3. Network or aggregate: este me lo salto,

4. Shortest AS_PATH : este es el criterio mas ampliamente utilizado, es en el que podemos influir mas en el trafico que nos envían los demás. en ocasiones sabemos que por la configuración que tenemos, por temas de puntos de intercambio u otras opciones “políticas” o para verificar algún mal funcionamiento de UPSTREAM que tengamos puede interesarnos alejarlo sin llegar a desconectarlo.

5. lowest origin TYPE. el IGP (protocolos interiores) gana al EGP (protocolos exteriores)

6. MED – valor bajo de MED gana a valor alto de MED, esto seria similar a los puntos 1 y 2, pero para deshacer empates, con esto podemos influir para deshacer los empates en lo que haya llegado hasta aqui.

7.eBGP over iBGP – generalmente es eBGP gana al iBGP, seguramente si la decisión llega hasta aqui ya nos da igual y lo mejor es deshacerse del paquete.

No me extiendo mas porque ya los demás son que el router tira los datos y por hay lo manda.

Ejemplo practico vyatta:

Definimos 2 route-map llamadas prepend1 y 2 para aplicar según convenga, donde pongo 65530 pondremos nuestro AS

vyatta@dut1# show policy route-map
route-map Prepend1 {
rule 10 {
action permit
set {
as-path-prepend “65530”
}
}
route-map Prepend2 {
rule 10 {
action permit
set {
as-path-prepend “65530”
}
}

Para los route-map de entrada mi consejo es definir uno por cada upstrem, en este caso como mi upstream esta bien conectado con telefonica pongo una regla para enviarle a el preferentemente lo que tiene conectado directamente y lo que sea de telefonica, de hay en la 3era acción le agrego el prepend, pero ojo esto afecta a lo que nosotros enviaremos.

policy {
as-path-list as3320 {
description dtag
rule 50 {
action permit
regex ^3320$
}
}
as-path-list telefonoca {
rule 50 {
action permit
regex _3352_
}
rule 60 {
action permit
regex _12956_
}
}

route-map rm3320in {
description dtag-in
rule 10 {
action permit
match {
as-path as3320
}
set {
local-preference 200
}
}
rule 20 {
action permit
match {
as-path telefonoca
}
set {
local-preference 200
}
}
rule 30 {
action permit
set {
as-path-prepend 65530
local-preference 100
}
}
}
}

Y lo siguiente es aplicarle el route-mapa nuestro vecino:

neighbor IP-DEL-VECINO {
nexthop-self
prefix-list {
export kaos # pro seguridad autolimitate lo que anuncias a tu prefijos
}
remote-as 3320
route-map {
export rm3320in
import prepend1
}
soft-reconfiguration {
inbound
}
weight 100
}