Conexiones directas. disable-connected-check

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:

ebgp-multihop.JPG

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

R1#show ip bgp summary
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 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 1

Neighbor 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-summary

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

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License