“Prefixos negados pela política local” na saída 'show ip bgp neighbour'

Passei a última semana solucionando alguns problemas (talvez relacionados, mas provavelmente não) com o Quagga. Eu tenho um roteador de teste - 7204VXR-NPEG2 executando 12.4 (24) T6 - com uma única sessão BGP para um host Quagga. A única sessão do BGP no 7204 é com a caixa Quagga. Esta é uma sessão do eBGP. Há literalmente zero política configurada em ambos os lados, mas eu recebo isso sem falhas na show ip bgp neighbor x.x.x.xsaída:

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

Por coincidência (ou talvez não?), Esse número é sempre o mesmo que o número de prefixos que estou recebendo do par ( show ip bgp summary). Existem algumas razões pelas quais isso é realmente intrigante:

1) Como eu disse, não há política. Esta é minha configuração BGP / vizinha:

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) O 7204 não está anunciando nada - ele serve apenas para receber prefixos.

Alguém quer lançar alguma luz sobre o que isso significa? Essa saída é normal / esperada? Uma pesquisa no google só me rendeu um pedacinho de informações extraídas do CCO:

Caminho melhor deste ponto
Exibe negações de entrada porque o caminho melhor veio do roteador local.

Isso faria sentido ... para entrada. E quanto à saída? Eu posso ver facilmente que isso é um bug estúpido, mas achei que eu procuraria outras pessoas para ver se elas já haviam visto isso antes.

bgp cisco-commands cisco-ios-12

— John Jensen
fonte

Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.

— Ron Maupin

Respostas:

Provavelmente, isso ocorre porque o horizonte dividido do EBGP entra em ação ... ou seja, o roteador 7204 recebe esses prefixos do Quagga, seleciona o melhor caminho e tenta divulgá-los. Como o único vizinho é o vizinho do qual o melhor caminho foi recebido, ele filtra os anúncios. O contador acima mostra isso.

— Pradosh Mohapatra
fonte

Eu acho que essa é uma boa sugestão, mas com essa lógica, todos os pares do eBGP teriam esse incremento de contador para cada sessão do eBGP que eles tiverem, não teriam?

— John Jensen

Não. Se você tiver duas sessões de eBGP recebendo 100 prefixos exclusivos de cada (para um total de 200 prefixos exclusivos) e estiver originando um único prefixo, você anunciaria exatamente 101 prefixos para cada par de BGP. No seu exemplo, você tem um único par de eBGP e não está originando nada. Portanto, esse par é o melhor caminho para todos os prefixos. Portanto, o horizonte dividido filtrará todos os anúncios de saída de volta para esse ponto.

— Ryan

Se você puder me encontrar documentação oficial que confirme suas afirmações, poste uma resposta e terei prazer em aceitá-la.

— John Jensen

(Ou eu vou aceitar essa resposta desde a sua resposta seria essencialmente o mesmo que o do Pradosh)

— John Jensen

Também acrescentarei mais uma coisa, porque sei que meus comentários podem parecer grosseiros, mas na verdade é apenas por causa da minha frustração por falta de compreensão disso. No começo, pensei que no bgp enforce-first-asera o culpado, mas depois de recriar o cenário que o @Ryan descreve sem o botão desligado - isso certamente me deixou com mais perguntas do que compreensão, e a falta de documentação sobre esse comportamento também está aumentando a frustração.

— 9133 John Jensen #

Suponho que você esteja executando o IBGP, você nunca envia um prefixo recebido via IBGP para um vizinho do IBGP; também haverá um horizonte dividido (não envie uma rota de volta para a pessoa que a enviou). Como essa caixa tem apenas um vizinho e não está originando nenhuma rota por si só, ela não enviará nenhuma rota; portanto, a política está implícita, mas existe.

— fredpbaker
fonte

Esta é realmente uma sessão do eBGP - deveria ter esclarecido isso na minha pergunta - boa captura. Vou editá-lo para esclarecer. E com relação à regra de horizonte dividido do iBGP - eu acreditaria se o motivo não era "o melhor caminho desse ponto" - o mesmo documento no link encontrado mostra um motivo separado para o horizonte dividido do iBGP - "* O melhor caminho do ponto do iBGP é implantado negações de entrada porque o caminho melhor veio de um vizinho do iBGP ". - consulte groupstudy.com/archives/ccielab/200511/msg00629.html

— John Jensen