Si has trabajado con BGP, te has percatado que existen dos tipos de comportamientos con este protocolo, el IBGP y EBGP. Se pueden tener algunas caracteristicas básicas de cada una:
IBGP: Las adyacencias de los neighbor pueden estar bien distantes, debido al TTL=255.
EBGP: Las adyacencias de los neighbor deben estar directamente conectados, debido al TTL=1 (existen ciertas excepciones con el neighbor ebgp-multihop).
Veamos este escenario:
Nota: Recordar que BGP depende generalmente de un protocol IGP o rutas estáticas, a menos que estén todos directamente conectados.
En este escenario utilizamos como protocolo base RIP. Las interfaces de las redes 10.0.0.0, 172.16.0.0, 1.0.0.0 y 2.0.0.0 están dentro del proceso BGP, por lo que todos tienen conectividad entre ellos.
Objetivo
Realizar adyacencia BGP entre el R1 y R2 basados en los sistemas autónomos AS 100 y AS 200, y que solamente sea utilizando sus enlaces directamente conectados (los dos seriales de las redes 10.0.0/30 y 10.0.0.4/30).
Para lograr este objetivo es posible realizar con dos adyacencias entre el R1 y R2, pero sería ineficiente debido a la duplicidad de paquetes en el proceso BGP.
La manera recomendable para realizar este escenario es realizar adyacencia entre loopback y que el balanceo lo realice el IGP por data y no por información de control.
como vamos a utilizar loopback, cuando intentamos realizar adyacencia con los valores por defecto nos percatamos que no levanta la sesión de BGP:
R1
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 update-source Loopback0
no auto-summary
R1#show ip bgp summ
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 200 0 0 0 0 0 never Idle
R2
router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback0
no auto-summary
R2#show ip bgp summ
BGP router identifier 2.2.2.2, local AS number 200
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 100 0 0 0 0 0 never Idle
Muchos pensarían que sería una razón sencilla debido al TTL=1 y se disminuye ya que sospechamos que la loopback lo disminuye y no completa.
Lo primero que se nos viene a la mente es utilizar el comando neighbor ebgp-multihop con un número igual a 2:
R1
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 update-source Loopback0
neighbor 2.2.2.2 ebgp-multihop 2
no auto-summaryR1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 200 5 5 1 0 0 00:01:23 0
R2
router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 ebgp-multihop 2
no auto-summary
R2#show ip bgp summ
BGP router identifier 2.2.2.2, local AS number 200
BGP table version is 1, main routing table version 1Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 4 4 1 0 0 00:00:36 0
Con esto logramos el objetivo que utilice los enlaces directamente conectados:
R1#show ip route 2.2.2.2
Routing entry for 2.0.0.0/8
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 10.0.0.6 on Serial0/1, 00:00:07 ago
Routing Descriptor Blocks:
10.0.0.6, from 10.0.0.6, 00:00:07 ago, via Serial0/1
Route metric is 1, traffic share count is 1
* 10.0.0.2, from 10.0.0.2, 00:00:21 ago, via Serial0/0
Route metric is 1, traffic share count is 1
Realicemos la prueba, dando de baja a los dos seriales directamente conectados. Con esto las sesiones de BGP no deberían levantar.
R1#show ip int b
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset administratively down down
Serial0/0 10.0.0.1 YES manual administratively down down
FastEthernet0/1 unassigned YES unset administratively down down
Serial0/1 10.0.0.5 YES manual administratively down down
Serial0/2 172.16.0.1 YES manual up up
Serial0/3 unassigned YES unset administratively down down
Serial0/4 unassigned YES unset administratively down down
Serial0/5 unassigned YES unset administratively down down
Loopback0 1.1.1.1 YES manual up up
R1#show 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/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
R 2.0.0.0/8 [120/2] via 172.16.0.2, 00:00:15, Serial0/2
172.16.0.0/30 is subnetted, 2 subnets
R 172.16.0.4 [120/1] via 172.16.0.2, 00:00:15, Serial0/2
C 172.16.0.0 is directly connected, Serial0/2
R1#clear ip bgp *
R1#
*Mar 1 00:42:43.247: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Down User reset
*Mar 1 00:42:45.599: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
R1#traceroute 2.2.2.2
Type escape sequence to abort.
Tracing the route to 2.2.2.2
1 172.16.0.2 56 msec 72 msec 88 msec
2 172.16.0.6 60 msec 208 msec *
R1#
La sesion BGP levanta tambien por el enlace a través de R3, incluso colocando solo un ebgp-multihop 2.
Diagnostico y Solución
Veamos la razón por la cual levanta el enlace indirecto:
R1#show ip bgp neighbor 2.2.2.2 | inc TTL
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2
R1#
R2#show ip bgp neighbor 1.1.1.1 | inc TTL
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2
R2#
El mínimo TTL que se acepta en una sessión BGP es de 0. Este parámetro no es modificable bajo ningún comando y esta es la razón por la cual levanta.
La pregunta sería ¿Por qué si tengo TTL=1 de salida no realizan adyacencias las loopback?. La respuesta es un paso adicional que realiza el proceso BGP, verificación de enlaces directamente conectados, escenario que solamente ocurre cuando el TTL=1.
En nuestro ejemplo en la primera parte, cuando la loopback 1.1.1.1 trataba realizar adyacencia con el 2.2.2.2, encontraba el TTL=1 y busca en la tabla FIB (show ip route) encontraba que la loopback no era una interfaz directamente conectada y NUNCA realiza el intento de comenzar la adyacencia, es decir, nunca R1 y R2 se enviaron paquetes (quizas un par de debug confirman esta explicación u observando el show ip bgp summary, con el estado idle y no active).
No es posible modificar el TTL=0 aceptado, pero si es posible deshabilitar la verificación de los enlaces directamente conectados con el comando neighbor disable-connected-check
R2
router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 disable-connected-check
neighbor 1.1.1.1 update-source Loopback0
no auto-summaryR2#show ip bgp neighbor | inc TTL
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
R2#
R2#SHOW ip bgp neighbors 1.1.1.1 | inc 180
Last read 00:02:54, last write 00:00:54, hold time is 180, keepalive interval is 60 seconds
R2#SHOW ip bgp neighbors 1.1.1.1 | inc 180
Last read 00:02:57, last write 00:00:57, hold time is 180, keepalive interval is 60 seconds
R2#SHOW ip bgp neighbors 1.1.1.1 | inc 180
Last read 00:02:58, last write 00:00:58, hold time is 180, keepalive interval is 60 seconds
R2#SHOW ip bgp neighbors 1.1.1.1 | inc 180
Last read 00:02:59, last write 00:00:59, hold time is 180, keepalive interval is 60 seconds
R2#SHOW ip bgp neighbors 1.1.1.1 | inc 180
Last read 00:02:59, last write 00:00:00, hold time is 180, keepalive interval is 60 seconds
R2#SHOW ip bgp neighbors 1.1.1.1 | inc 180
Last read 00:03:00, last write 00:00:00, hold time is 180, keepalive interval is 60 seconds
R2#SHOW ip bgp neighbors 1.1.1.1 | inc 180
Last read 00:00:00, last write 00:00:00, hold time is 180, keepalive interval is 60 seconds
R2#
*Mar 1 01:04:23.731: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down BGP Notification sent
*Mar 1 01:04:23.735: %BGP-3-NOTIFICATION: sent to neighbor 1.1.1.1 4/0 (hold time expired) 0 bytes
R2#
R2#