“Prefijos denegados de política local” en la salida 'show ip bgp neighbour'

Estuve pasando la última semana más o menos resolviendo algunos problemas (quizás relacionados, pero probablemente no) con Quagga. Tengo un enrutador de prueba - 7204VXR-NPEG2 con 12.4 (24) T6 - con una sola sesión de BGP a un host Quagga. La única sesión de BGP en el 7204 es con la caja Quagga. Esta es una sesión de eBGP. Literalmente, hay una política cero configurada en ambos lados, pero obtengo esto sin fallas en la show ip bgp neighbor x.x.x.xsalida:

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Bestpath from this peer:          19270        n/a
    Total:                            19270          0

Casualmente (¿o tal vez no?) Este número siempre es el mismo que el número de prefijos que estoy recibiendo del compañero ( show ip bgp summary) Hay un par de razones por las que esto es realmente desconcertante:

1) Como dije, no hay una política. Esta es mi configuración de BGP / vecino:

router bgp XXXXX
 no synchronization
 bgp router-id X.X.X.X
 no bgp enforce-first-as
 bgp log-neighbor-changes
 neighbor X.X.X.X remote-as XXXXX
 neighbor X.X.X.X next-hop-self
 neighbor X.X.X.X soft-reconfiguration inbound
 no auto-summary

2) El 7204 no anuncia nada, solo está destinado a recibir prefijos.

¿Alguien quiere arrojar algo de luz sobre lo que esto significa? ¿Es esta salida normal / esperada? Una búsqueda en Google solo me proporcionó un dato de información extraída de CCO:

Bestpath de este par
Muestra negaciones entrantes porque el bestpath proviene del enrutador local.

Esto tendría sentido ... para entrante. ¿Qué pasa con outbound? Puedo ver fácilmente que se trata de un error estúpido, pero pensé que me acercaría a otras personas para ver si habían visto esto antes.

bgp cisco-commands cisco-ios-12

— John Jensen
fuente

¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.

— Ron Maupin

Respuestas:

Esto se debe probablemente a que se inició el horizonte dividido EBGP ... es decir, el enrutador 7204 recibe esos prefijos de Quagga, selecciona la mejor ruta e intenta anunciarlos. Dado que el único vecino es el vecino del que se recibió la mejor ruta, filtra los anuncios. El contador de arriba muestra eso.

— Pradosh Mohapatra
fuente

Creo que esta es una buena sugerencia, pero con esta lógica, todos los pares de eBGP tendrían este incremento de contador para cada sesión de eBGP que tengan, ¿no?

— John Jensen el

No. Si tiene dos sesiones eBGP que reciben 100 prefijos únicos de cada una (para un total de 200 prefijos únicos), y está originando un único prefijo, entonces anunciaría exactamente 101 prefijos a cada par BGP. En su ejemplo, tiene un solo par eBGP y no está originando nada. Por lo tanto, ese par es el mejor camino para todos los prefijos. Por lo tanto, el horizonte dividido filtrará todos los anuncios salientes a ese par.

— Ryan

Si puede encontrarme documentación oficial que confirme sus afirmaciones, publique una respuesta y estaremos encantados de aceptarla.

— John Jensen el

(O aceptaré esta respuesta ya que su respuesta sería esencialmente la misma que la de Pradosh)

— John Jensen

También agregaré una cosa más porque me doy cuenta de que mis comentarios pueden parecer groseros, pero en realidad es solo por mi frustración por la falta de comprensión de esto. Al principio pensé que no bgp enforce-first-asera el culpable, pero después de recrear el escenario que @Ryan describe sin tener esa perilla apagada, ciertamente me dejó con más preguntas que comprensión, y la falta de documentación sobre este comportamiento también se suma a la frustración.

— John Jensen el

Asumiré que está ejecutando IBGP, nunca envía un prefijo que recibió a través de IBGP a un vecino de IBGP, también habría un horizonte dividido (no envíe una ruta a la persona que se lo envió). Dado que este cuadro solo tiene un vecino y no está originando ninguna ruta por sí mismo, no enviará ninguna ruta, por lo que la política es implícita, pero existe.

— fredpbaker
fuente

Esta es en realidad una sesión de eBGP, debería haber aclarado eso en mi pregunta: buena captura. Lo editaré para aclarar. Y con respecto a la regla de horizonte dividido de iBGP, creo que esto si la razón no fuera "bestpath from this peer", el mismo documento en el enlace que encontré muestra una razón separada para el horizonte dividido de iBGP: "* Bestpath from iBGP peer Deploys denegaciones entrantes porque el mejor camino proviene de un vecino de iBGP ". - ver groupstudy.com/archives/ccielab/200511/msg00629.html

— John Jensen