BGP update-source y next-hop-self

eBGP-multihop next-hop-self cuando es necesario y como se usa

Para ello ponemos el siguiente ejemplo, dos sistemas autónomos, uno corre un IGP que es OSPF en el area 0 y el otro no usa protocolo de enrutamiento.

Primero estableceremos la relacion eBGP entre R1 y R2, para usar los dos caminos redundantes. Si la configuracion fuera tal que así

R1
router bgp 65000
 neighbor 1.1.1.1 remote-as 65001

R2
router bgp 65001
 neighbor 2.2.2.2 remot-as 65000

Nunca tendriamos relación puesto que R1 no tiene ruta a la loopback de R2 ni R2 tiene ruta a la loopback de R1 así que creamos rutas estáticas

R2#sh ip bgp summary
BGP router identifier 2.2.2.2, local AS number 65001
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4 65000      25      25        0    0    0 00:00:00 Active

en ambos sentidos (muestro solo R2)

ip route 1.1.1.1 255.255.255.255 10.0.0.1
ip route 1.1.1.1 255.255.255.255 10.0.0.5

aún así la sesión bgp no levanta ¿porque?, pues porque el TTL de bgp es 1, aunque sea un sólo salto si usas loopbacks el salto es 2, tenemos que usar el comando ebgp-multihp

router bgp 65001
 neighbor 1.1.1.1 remote-as 65000
 neighbor 1.1.1.1 ebgp-multihop 2
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary

router bgp 65000
 neighbor 2.2.2.2 remote-as 65001
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0

ahora ya son vecinos bgp, nos podemos centrar en la relacion IGP e IBGP entre R1 y R3


Para que la regla de la sincronización sea válidación las rutas de iBGP tenemos que usar una IGP

R4

router ospf 1
 log-adjacency-changes
 network 1.1.1.2 0.0.0.0 area 0
 network 192.168.0.0 0.0.0.255 area 0
 network 192.168.4.0 0.0.0.255 area 0

R1
router ospf 1
 log-adjacency-changes
 passive-interface default (para que no publique por los serial)
 no passive-interface FastEthernet1/0
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.0.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0

Ahora configuramos los peers iBGP

R4

router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 65000
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary

R1
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.0
 network 192.168.1.0
 neighbor 1.1.1.2 remote-as 65000
 neighbor 1.1.1.2 update-source Loopback0
 neighbor 2.2.2.2 remote-as 65001
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary

Vemos que si se ven pero las rutas no llegan a R4 vamos a hacer un debug ip bgp updates a ver porque no llegan las rutas de R2 hacia R4
Algunas llegan

*Mar  1 00:34:27.819: BGP(0): 1.1.1.1 rcvd UPDATE w/ attr: nexthop 1.1.1.1, origin i, localpref 100, metric 0
*Mar  1 00:34:27.823: BGP(0): 1.1.1.1 rcvd 192.168.1.0/24
*Mar  1 00:34:27.831: BGP(0): 1.1.1.1 rcvd 192.168.0.0/24
*Mar  1 00:34:27.835: BGP(0): Revise route installing 1 of 1 routes for 192.168.0.0/24 -> 1.1.1.1(main) to main IP table
*Mar  1 00:34:27.843: BGP(0): Revise route installing 1 of 1 routes for 192.168.1.0/24 -> 1.1.1.1(main) to main IP table
*Mar  1 00:34:27.947: BGP(0): Revise route installing 1 of 1 routes for 192.168.0.0/24 -> 1.1.1.1(main) to main IP table
*Mar  1 00:34:27.951: BGP(0): Revise route installing 1 of 1 routes for 192.168.1.0/24 -> 1.1.1.1(main) to main IP table

Pero otras no

*Mar  1 00:35:26.795: BGP(0): no valid path for 192.168.2.0/24
*Mar  1 00:35:26.799: BGP(0): no valid path for 192.168.3.0/24

¿porque?, veamos, esas rutas las publica R2, R4 no tiene forma de saber como llegar a R2 pero si a R1 por lo que haremos es qeu R2 reanuncie las rutas de R4 usando el comando next-hop-self

router bgp 65000
 neighbor 1.1.1.2 next-hop-self

ahora si llegan y se insertan en la tabla de rutas, podemos proceder a quitar el debug con undebug all

*Mar  1 00:37:24.915: BGP(0): Revise route installing 1 of 1 routes for 192.168.2.0/24 -> 1.1.1.1(main) to main IP table
*Mar  1 00:37:24.923: BGP(0): Revise route installing 1 of 1 routes for 192.168.3.0/24 -> 1.1.1.1(main) to main IP table.

Las configuraciones así como el archivo .NET os lo dejo en un enlace de megaupload por si quereis usarlo con el gns3, no os olveis de cambiar el IOS si no coincide, el idle PC y revisar el hipervisor ya que yo he usado dos para que uno solo no ralentizara la máquina. configs y archivo

BGP creando relaciones iBGP

Pongamos el siguiente ejemplo de dos routers que quieren intercambiar rutas por BGP.

El r-id (router id) se obtiene de la siguiente manera:
1.- con el comando bgp router-id «id router»
2.- ip de loopback mas alta
3.- ip física mas alta

Para iniciar bgp en el equipo haremos lo siguiente
router bgp «NUMERO AS»

Para anunciar una red
network «ip de red» mask «mascara de red»

Para establecer un vecino ibgp o ebgp (ibgp si usan el mismo sistema autonomo y ebgp si no lo comparten)
neighbor «ip del router vecino» remote-as «sistema autónomo del vecino»

Para cambiar la interfaz de la cual se establecen las relaciones
neighbor «ip del vecino» udpate-source «interfaz con la que queremos ser vercinos bgp»
ésto es recomendable porque si se cae una interfaz física puede que podamos llegar por otra física al destino, en cambio la loopback nunca cae. Tenemos que poder llegar a esa ip, ya sea con ruta estática, porque está directamente conectado o mediante algún protocolo de enrutamiento.

el vecino tiene que utilizar como destino del vecino la misma ip que en tu router hay en el «update-source»

La configuración de bgp de R1 es la siguiente:

router bgp 65000
 synchronization
 bgp log-neighbor-changes
 network 2.2.2.2 mask 255.255.255.255
 network 10.0.0.0 mask 255.255.255.0
 network 192.168.1.0
 neighbor 1.1.1.1 remote-as 65000
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary



La configuración de bgp de R2 es la siguiente:

router bgp 65000
 synchronization
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 network 10.0.0.0 mask 255.255.255.252
 network 192.168.2.0
 neighbor 2.2.2.2 remote-as 65000
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary


Vemos que establecemos peers con las loopbacks

R1#      sh ip bgp summary
BGP router identifier 2.2.2.2, local AS number 65000
BGP table version is 8, main routing table version 8
5 network entries using 585 bytes of memory
5 path entries using 260 bytes of memory
3/3 BGP path/bestpath attribute entries using 372 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 1217 total bytes of memory
BGP activity 10/5 prefixes, 10/5 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4 65000      23      23        8    0    0 00:11:31        3



Ahora si en R1 vemos la tabla de rutas

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
S       1.1.1.1 is directly connected, FastEthernet0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
     10.0.0.0/30 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet1/0


No aparecen las redes con BGP (las conectadas a cada switch). Para ver que redes recibe lo haremos con «show ip bgp»

R1#sh ip bgp
BGP table version is 7, local router ID is 2.2.2.2
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
r>i1.1.1.1/32       1.1.1.1                  0    100      0 i
*> 2.2.2.2/32       0.0.0.0                  0         32768 i
r>i10.0.0.0/30      1.1.1.1                  0    100      0 i
*> 192.168.1.0      0.0.0.0                  0         32768 i
* i192.168.2.0      1.1.1.1                  0    100      0 i


Vemos que la red 192.168.2.0/24 si se está recibiendo, la regla de la sincronización es la que nos impide obtener esa ruta, o deshabilitamos la sincronización o hablamos un IGP para que esa ruta se valide.
Ejecutamos «no synchronization» dentro de router bgp 65000

R2#sh ip bgp
BGP table version is 12, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       0.0.0.0                  0         32768 i
r>i2.2.2.2/32       2.2.2.2                  0    100      0 i
*> 10.0.0.0/30      0.0.0.0                  0         32768 i
*>i192.168.1.0      2.2.2.2                  0    100      0 i
*> 192.168.2.0      0.0.0.0                  0         32768 i


Ya vemos la ruta con la marca > que significa que a parte de ser válida es la mejor ruta para el destino, ahora si saldrá en la tabla de rutas.


R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     2.0.0.0/32 is subnetted, 1 subnets
S       2.2.2.2 [1/0] via 10.0.0.2
     10.0.0.0/30 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/0
B    192.168.1.0/24 [200/0] via 2.2.2.2, 00:04:48
C    192.168.2.0/24 is directly connected, FastEthernet1/0

La distancia administrativa de IBGP es 200 y la de EBGP es 20 (para prevenir bucles). También podemos observar en show ip bgp el valor «Weight» si es una ruta anunciada por el propio router es 32768 y si llega de otro siempre es 0.
Y el valor Path si es por el propio AS saldrá «i» si no saldrá el sistema autónomo por el cual llega el anuncio.

Atributos BGP

Los atributos de BGP se utilizan para elegir la mejor ruta hacia un destino. Es un protocolo muy flexible y soporta muchos atributos para comparar entre varias rutas para el mismo destino.

Los podemos dividir entre dos tipos de categorías, obligatorios y opcionales, los obligatorios han de ser soportados por cualquier router que se precie de correr BGP.

•     Origin
•     AS_PATH
•     NEXT_HOP
•     MULTI_EXIT_DISC
•     LOCAL_PREF
•     ATOMIC_AGGREGATE
•     AGREGATOR
•     COMMUNITY
•     ORIGINATOR_ID
•     CLUSTER_LIST
•     Multiprotocol Reachable NLRI (MP_REACH_NLRI)
•     Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI)

ORIGIN

Éste atributo indica el AS de origen, no es muy flexible, indica de donde se ha aprendido una ruta. Hay tres posibles valores.

    IGP (I)
    EGP (E)
    Desconocido (?)

Con EGP nos referimos a EGP no a un protocolo exterior como BGP, EGP es el antecesor de BGP, por eso el valor E no se suele ver porque el protocolo EGP está obsoleto, si no I ó ?.


AS_PATH

Éste parámetro lista de forma inversa por orden los sistemas autónomos por los que ha pasado un prefijo, siendo el último el que queda en primer lugar. Se utiliza para prevenir bucles de enrutamiento.

NEXT_HOPT

Indica la ip del siguiente salto para un prefijo determinado.
Si la ruta que se recibe está en la misma subred, el valor NEXT-HOP continua siendo el mismo, en el siguiente ejemplo si el AS 102 tiene la red 20.0.0.0/8 aunque el AS 100 tenga como BGP Peer el AS 101 utilizará como NEXT_HOP la IP del router del AS 102 con lo que se gana en eficiencia.

Ésta ventaja es un inconveniente en las redes NBMA Multipoint porque aunque apuntes a la ip de otro router el camino lo marca el pvc y físicamente pasará por otra ip antes que por la del NEXT_HOP.
Pongamos un ejemplo, si el AS 102 tiene la red 20.0.0.0/8 al estar en el mismo segmento de red el AS 101 utilizará la IP 192.168.1.3 como NEXT_HOP cuando no hay un PVC directo con esa IP de destino.

MULTI_EXIT_DISC

También llamado MED, no confundir con métrica.  Se utiliza para sugerir a un AS vecino con varios puntos de entrada/salida al mismo AS el camino a seguir. Es el ultimo atributo que se utiliza para calcular la métrica en BGP. Cuanto valor menos, mejor. Si seguimos la regla de BGP no le podemos decir a un AS vecino como enrutar su tráfico parece que no se cumple, por eso MED sugiere, no obliga.


Aquí ocurren varios casso:
Si la ruta se aprende por iBGP éste parámetro se quita antes de ser reenviada por eBGP.
Si la ruta sen inyecta por eBGP utilizando el comando network o redistribute de un IGP el valor MED es el mismo que la métrica del IGP
Si la ruta se inyecta por eBGP pero la ruta se encuentra directamente conectada el valro de MED es cero.
Si la ruta es inyectada usando el comando aggregate-address el valor MED no se utiliza.


LOCAL_PREF

Se utiliza por los vecinos iBGP para calcular el grado de preferencia de cada ruta externa. Cuanto más alto será el valor más preferencia a la hora de seleccionar ese camino. Éste valor se elimina cuando se pasa a eBGP.

Veamos un ejemplo:
El valor de LOCAL_PREF por defecto es 0, si aprendemos la red 20.0.0.0/8 de dos AS distintos (101 y 102), podemos cambiar la preferencia para utilizar la salida hacia el AS 102.

COMMUNITY

Una COMMUNITY es una etiqueta que se añade a una red o a unas redes que comparten la misma propiedad. Cada etiqueta ocupa 4 bytes y hay dos tipos de etiqeutas
Las bien conocidas especificadas en el RFC 1997, Cisco soporta las siguientes: NO_EXPORT, LOCAL_AS, NO_ADVERTISE, INTERNET.
Las privadas, cada AS o grupo de AS  se tienen que poner de acuerdo porque no están especificadas en ningún sitio.






ORIGINATOR_ID

Se utiliza en iBGP para prevenir bucles cuadno se utilizan Route Reflectors. Es el ID del router que envia la ruta, si un router vuelve a obtener una ruta con su mismo ORIGINATOR_ID ya sabe que se produce un bucle.


CLUSTER_LIST

Se utiliza para prevenir bucles desntro del mismo AS cuando se utilizan Route Reflectors. Es lo mismo que el ORIGINATOR_ID pero guarda varios valores: CLUSTER_ID y CLUSTER_LIST.


AGGREGATOR

Éste campo indica que router hizo una sumarización de una red.


ELECCION DE RUTA

Para hacer la elección final de la ruta se van comparando los atributos anteriores. La manera exacta en la que lo hace se puede encontrar en la web de Cisco.com http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

BGP Teoria

Historia

• Actualmente se utiliza la versión 4
  
• Es el sucesor de BGP 2/3 y sustituyó a EGP en los 90's
  
• Destinado a enrutar entre sistemas autónomos AS
  

Los Hechos

• Dos tipos de BGP: IBGP (actuando como IGP) y EBGP
  
• Utiliza el puerto TCP 179 y mantiene una relación de vecindad con otros routers.
  
• Por defecto busca el mejor camino a una red usando el mejor AS-PATH (es un atributo en BGP)
  
• Las políticas de enrutamientos (routing policies) se configuran usando los atributos de BGP
  
• BGP converge muy lentamente. IBGP manda actualizaciones cada 5 segundos y EBGP cada 30 segundos.
  

RFC 177
No tienes que decirle a un AS vecino como enrutar el tráfico que le llegue.


BGP Neighbors


Estados de una conexión BGP (los vecinos se configuran a mano, no hay auto descubrimiento)
IDLE -> esperando a un evento que inicie bgp
CONNECT -> sesión TCP completado
ACTIVE -> Intentando establecer vecindad
OPEN SENT -> Open enviado, esperando recibir open del vecino
OPEN CONFIRM -> esperando keepalive
ESTABLISHED -> bgp comienza a intercambiar rutas

Pongo un ejemplo al establecer una sesión EBGP entre los sistemas 100 y 101 de arriba

*Mar  1 00:22:35.083: BGP: 10.0.0.1 went from Idle to Active
*Mar  1 00:22:35.091: BGP: 10.0.0.1 open active delayed 28754ms (35000ms max, 28% jitter)
*Mar  1 00:22:59.099: BGP: 10.0.0.1 passive open to 10.0.0.2
*Mar  1 00:22:59.103: BGP: 10.0.0.1 went from Active to Idle
*Mar  1 00:22:59.103: BGP: 10.0.0.1 went from Idle to Connect
*Mar  1 00:22:59.111: BGP: 10.0.0.1 rcv message type 1, length (excl. header) 26
*Mar  1 00:22:59.111: BGP: 10.0.0.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar  1 00:22:59.115: BGP: 10.0.0.1 went from Connect to OpenSent
*Mar  1 00:22:59.115: BGP: 10.0.0.1 sending OPEN, version 4, my as: 101, holdtime 180 seconds
*Mar  1 00:22:59.115: BGP: 10.0.0.1 rcv OPEN w/ OPTION parameter len: 16
*Mar  1 00:22:59.115: BGP: 10.0.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  1 00:22:59.115: BGP: 10.0.0.1 OPEN has CAPABILITY code: 1, length 4
*Mar  1 00:22:59.119: BGP: 10.0.0.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  1 00:22:59.119: BGP: 10.0.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:22:59.119: BGP: 10.0.0.1 OPEN has CAPABILITY code: 128, length 0
*Mar  1 00:22:59.119: BGP: 10.0.0.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  1 00:22:59.119: BGP: 10.0.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:22:59.119: BGP: 10.0.0.1 OPEN has CAPABILITY code: 2, length 0
*Mar  1 00:22:59.123: BGP: 10.0.0.1 OPEN has ROUTE-REFRESH capability(new) for all address-families  BGP: 10.0.0.1 rcvd OPEN w/ remote AS 100
*Mar  1 00:22:59.123: BGP: 10.0.0.1 went from OpenSent to OpenConfirm
*Mar  1 00:22:59.123: BGP: 10.0.0.1 send message type 1, length (incl. header) 45
*Mar  1 00:22:59.239: BGP: 10.0.0.1 went from OpenConfirm to Established
*Mar  1 00:22:59.239: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up 

 
- Los mensajes hello se envían cada 60 segundos y el holdown timer es de 180 segundos
- Es capaz de autenticar un vecino mediante clave precompartida cifrada en MD5


Regla de sincronización

Las rutas aprendidas por BGP han de ser validadas por un IGP antes de anunciarlas a otros vecinos BGP.

Si el AS 101 enviá trafico hacia R1 porque el AS 100 tiene esa ruta, pero los rutes del AS 100 no saben como llegar a esa ruta (no está validada), BGP no habrá sincronizado luego R1 no enrutará si no hay un protocolo interior que maneje esas rutas (IBGP, EIGRP, RIP, OSPF), se pueden producir “black holes” no saber como enrutar los routers dentro del AS

Regla del Horizonte Dividido
Las rutas aprendidas por IBGP no se reenvían a otro vecino IBGP. Es decir, no mas de un salto IBGP, para que funcione correctamente tiene que ser “full mesh” o utilizar route reflectors.