Impedir rotas para ficar preso com BGP em cenários de failover.

Introdução
O objetivo deste documento é explicar um cenário em que implantações de rede prontas para failover podem enfrentar uma situação em que algumas
rotas podem ficar "presas" após um evento de falha e recuperação. Depois que ocorre uma falha na rede (geralmente em direção à WAN), a rede deve
usar o caminho de backup disponível. No entanto, após a recuperação do caminho primário, o encaminhamento pode não convergir correctamente voltar
ao respectivo estado original.

Dependendo do projeto da rede, algumas conseqüências podem ser:

 Encaminhamento assimétrico.
 Caminhos sub-ótimos.
É comum e desejável ter redundância em redes atuais. Para esse fim, há pelo menos 2 Border Routers que muitas vezes executar BGP para trocar
prefixos de rede com o lado WAN e um 'IGP' como EIGRP para trocar prefixos de rede com o lado LAN. Redistribuição mútua entre protocolos é
geralmente necessária para realizar a conectividade de rede completa.

Neste documento abordaremos um cenário comum que pode levar a pelo menos uma das conseqüências acima mencionadas.

Prova de conceito
Vamos começar explicando o conceito de núcleo que desencadeia o comportamento de roteamento indesejável. Para demonstrá-lo, estamos analisando
o resultado da Seleção de Caminho em uma parte do Roteador de um cenário específico.

 Fase 1) Os links primários e de espera estão ativos.

 Fase 2) Falha do circuito primário.
 Fase 3) Recuperação do circuito primário.
WAN_RTR # recebe a rota 192.168.1.0/24 via eBGP , que deve ser eleito como o caminho principal. A
decisão Routing está correta desde BGP é inserido na tabela de roteamento.

RIB or Routing Table

WAN_RTR#show ip route
<OMITTED FOR BREVITY>
B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:42
WAN_RTR#

BGP Table

WAN_RTR#show ip bgp
<OMITTED FOR BREVITY>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.2.2 0 0 2 i
WAN_RTR#

Saídas da Fase 1

Uma falha de link faz com que a adjacência BGP desça no Roteador. Agora WAN_RTR # recebe o mesmo
prefixo exato via EIGRP de algum caminho alternativo.

Neste cenário, BGP é redistribuir EIGRP como visto na configuração do roteador. Como o prefixo
perdido foi inserido na Tabela de Roteamento via EIGRP, a declaração de redistribuição agora adiciona
a rota na tabela BGP. Esse é um comportamento esperado mesmo quando não há vizinhos BGP.

WAN_RTR's BGP configuration

WAN_RTR#sh running-config | begin router bgp

router bgp 1
bgp log-neighbor-changes
redistribute eigrp 1
neighbor 10.1.2.2 remote-as 2
!

RIB or Routing Table

WAN_RTR#show ip route
<OMITTED FOR BREVITY>
D 192.168.1.0/24 [90/156160] via 10.1.3.3, 00:00:02, FastEthernet0/1
WAN_RTR#

BGP Table

WAN_RTR#show ip bgp
<OMITTED FOR BREVITY>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.3.3 156160 32768 ?
WAN_RTR#

Fase 2 saídas

IMPORTANTE: Cisco IOS define o WEIGHT atributo caminho para 32768 por padrão quando o próprio
roteador origina localmente o anúncio.
O peering de BGP é restabelecido e nós estamos esperando a entrada de BGP para fazer exame sobre. No
entanto, devemos notar que na tabela BGP , o WEIGHT caminho atributo é menor para a rota recebidas
através do BGP peer original do que para a entrada criada com o comando 'redistribuir eigrp'. Como
consequência, a BGP UPDATE perde a BGP Best path Selection.Agora, o roteador ainda está escolhendo
EIGRP como o melhor caminho.

RIB or Routing Table

WAN_RTR#show ip route
<OMITTED FOR BREVITY>
D 192.168.1.0/24 [90/156160] via 10.1.3.3, 00:08:55, FastEthernet0/1

BGP Table

WAN_RTR#show ip bgp
<OMITTED FOR BREVITY>
Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 10.1.2.2 0 0 2 i
*> 10.1.3.3 156160 32768 ?
WAN_RTR#

Saídas da Fase 3

Estamos de volta para a Fase 1 cenário. Desta vez, a tabela BGP tem 2 entradas para o mesmo destino,
marcando como melhor (confira o " > sinal de '), o que tem o maior weight .

A tabela de roteamento, que é o que informa CEF o caminho de encaminhamento, mantém a rota
EIGRP. Portanto, roteamento não foi restaurado corretamente para seu estado original.

Como resolvê-lo.
Vimos o WEIGHT caminho atributo é o que está causando a rota para não recuar ao seu estado original na Fase 3. A fim de resolver este cenário,
devemos fazer o BGP recebeu rota para conquistar a rota redistribuído EIGRP quando comparado pela Processo de seleção do melhor caminho BGP na
tabela BGP.

Como solução, o WEIGHT atributo de caminho pode ser modificado quando recebeu do peer BGP. Podemos configurá-lo para qualquer valor maior
que 32768. Por exemplo:

router bgp 1
neighbor 10.1.2.2 weight 40000

ou

route-map FROM-ISP permit 10

set weight 40000
!
router bgp 1
neighbor 10.1.2.2 route-map FROM-ISP in
!
clear ip bgp * soft in

ou
ip prefix-list NETWORKs permit 192.168.1.0/24
!
route-map FROM-ISP permit 10
match ip address prefix NETWORKS
set weight 40000
route-map FROM-ISP permit 100
!
router bgp 1
neighbor 10.1.2.2 route-map FROM-ISP in
!
clear ip bgp * soft in

Abordagens diferentes de configuração pode ser usado, mais uma vez, a idéia principal é aumentar o weight atributo de caminho para a rota BGP
entrada ou rotas.

Vamos passar pela Prova de Conceito processo mais uma vez, mas desta vez, uma das configurações acima mencionadas foram adicionados ao Router.

WAN_RTR#show ip bgp
<OMITTED FOR BREVITY>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.2.2 0 40000 2 i
WAN_RTR#

WAN_RTR#show ip route
<OMITTED FOR BREVITY>
B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:09:53
WAN_RTR#

Saídas da Fase 1

WAN_RTR#show ip bgp
<OMITTED FOR BREVITY>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.3.3 156160 32768 ?
WAN_RTR#

WAN_RTR#show ip route
<OMITTED FOR BREVITY>
D 192.168.1.0/24 [90/156160] via 10.1.3.3, 00:01:41, FastEthernet0/1
WAN_RTR#

Saídas da Fase 2

WAN_RTR#show ip bgp
<OMITTED FOR BREVITY>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.2.2 0 40000 2 i
WAN_RTR#

WAN_RTR#show ip route

<OMITTED FOR BREVITY>

B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:25
WAN_RTR#

Fase 3 saídas

As decisões de roteamento computados na Fase 1 e Fase 3 são agora o mesmo.

BGP WEIGHT Atributo do caminho.

Ao receber vários caminhos para o mesmo destino, o BGP compara seus atributos de caminho um a um até encontrar um par que não ligue.
Tabela de atributos de caminho BGP.
O próximo hop é acessível? Se sim, continue
WEIGHT Maior ganha a eleição
LOCAL PREFERENCE Maior ganha a eleição
Mais informações através do link abaixo ...
O documento Cisco, o que explica em detalhes o processo de seleção Caminho BGP, podem ser encontrados através de:
- BGP melhor caminho Selection Algorithm

Uma vez que BGP decide a rota não deve ser ignorado (mais informações no documento acima) o primeiro atributo de caminho a ser comparado é
WEIGHT. Quando o atributo path WEIGHT não é um empate, a entrada com o maior atributo WEIGHT Path é eleita.

Distância Administrativa

Os roteadores Cisco usam a Distância Administrativa como uma medida de confiabilidade da origem da rota. A Fonte com o valor mais baixo é
escolhida quando mais de uma fonte diferente está disponível.

Tabela de distância administrativa.

EBGP 20
EIGRP Interno
90

EIGRP Externo
170

Mais informações através do link abaixo ...

O documento Cisco, o que explica em detalhes o processo Route Selection, podem ser encontrados através de:
- Route Selection em roteadores Cisco

A expectativa usual é ver a entrada eBGP na tabela de roteamento. Isto porque AD do eBGP é mais baixo quando comparado com o AD de um 'IGP'
como EIGRP. Isso é comumente verdade, no entanto, não estamos levando em consideração que o processo eleitoral acontece no nível BGP. Em outras
palavras, a Ordem das Operações.

Ordem de operações

Como visto nos " Fase 3 saídas ' na Prova de Conceito seção , a tabela BGP inesperadamente termina com 2 entradas, que são correspondentes a
ambos, o BGP e os pares EIGRP.

BGP Table

WAN_RTR#show ip bgp
<OMITTED FOR BREVITY>
Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 10.1.2.2 0 0 2 i
*> 10.1.3.3 156160 32768 ?
WAN_RTR#
Saídas da Fase 3

Portanto, o ponto-chave para reproduzir esse comportamento é a inserção do prefixo 'IGP' na tabela BGP. Isso geralmente é feito com qualquer um, o
BGP 'redistribuição' ou o comando "rede" uma vez que a entrada é na tabela de roteamento não via BGP. Ambos os comandos definem o WEIGHT para
32768 ao adicionar a rede na tabela BGP. Do ponto de vista do BGP, é "originado localmente".

router bgp 1
redistribute eigrp 1

ou

router bgp 1
network 192.168.1.0 mask 255.255.255.0

Ordem de operações

Podemos concluir que, para esse cenário, duas variáveis devem ser atendidas:
1. O roteador deve adicionar o prefixo perdido BGP na tabela de roteamento através de um IGP diferente.
2. Depois de preenchido o ponto 1, o processo BGP deve incluí-lo na tabela BGP.

Cenário de caso real.

Veremos agora como o comportamento de roteamento indesejável afeta uma rede com redundância no lugar.

Estamos focando principalmente no dispositivo CORE # para este exemplo.

O estado inicial da rede consiste no switch CORE # que envia o tráfego para WAN_RTR_A # ao se comunicar com a rede remota 192.168.1.0/24

CORE # está recebendo rotas EIGRP de ambos, WAN_RTR_A # & WAN_RTR_B # como visto na tabela de topologia EIGRP.

Ele está preferindo o caminho fornecido pelo WAN_RTR_A # uma vez que o EIGRP está calculando uma métrica melhor para ele devido a um valor
ligeiramente maior de "atraso" configurado na interface Fa0 / 1 do CORE #.

CORE#show ip eigrp neighbors

EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.2.2 (WAN_RTR_A) Fa0/0 10 00:05:15 79 1066 0 10
1 10.1.3.3 (WAN_RTR_B) Fa0/1 12 00:06:22 76 456 0 5

CORE#show ip route
<OMMITED FOR BREVITY>
D EX 192.168.1.0/24 [170/28416] via 10.1.2.2, 00:00:32, FastEthernet0/0

CORE#show ip eigrp topology

EIGRP-IPv4 Topology Table for AS(1)/ID(1.1.1.1)
<OMMITED FOR BREVITY>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
via 10.1.2.2 (28416/2816), FastEthernet0/0
via 10.1.3.3 (281856/2816), FastEthernet0/1

Fase 1. Saídas CORE #.

Em caso de falha do circuito que liga WAN_RTR_A # a WAN_1, a adjacência BGP irá diminuir. CORE # deve manter a comunicação com a rede
remota usando o caminho de backup através de WAN_RTR_B # e WAN_2.

É muito importante perceber que agora, WAN_RTR_A # está encontrando as variáveis para acertar o comportamento de roteamento indesejável.

Assim que o problema de circuito for resolvido, Routing não será restaurado para seu estado original.

CORE#show ip eigrp neighbor

EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.2.2 (WAN_RTR_A) Fa0/0 11 00:04:55 50 300 0 12
1 10.1.3.3 (WAN_RTR_B) Fa0/1 13 00:14:48 77 462 0 5

CORE#show ip route
<OMMITED FOR BREVITY>
D EX 192.168.1.0/24 [170/281856] via 10.1.3.3, 00:00:05, FastEthernet0/1

CORE#show ip eigrp topology

EIGRP-IPv4 Topology Table for AS(1)/ID(1.1.1.1)
<OMMITED FOR BREVITY>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
via 10.1.3.3 (281856/2816), FastEthernet0/1

Fase 2. Saídas CORE #.

Depois que o circuito para WAN_1 for restaurado, observe como o CORE # mantém o roteamento do tráfego em direção ao caminho de backup. A
razão é sua Tabela de Roteamento nunca foi atualizada com a entrada EIGRP para apontar para WAN_RTR_A # quando o link surgiu.

Esta não é a falha de CORE #. Ele ainda não recebeu nenhuma atualização EIGRP de WAN_RTR_A #.

Ao examinar mais de WAN_RTR_A #, vemos que sua tabela de roteamento ficou presa com a rota do EIGRP. Assim, BGP nunca foi redistribuído em
EIGRP novamente.

O roteamento deve ser corrigido em WAN_RTR_A #

CORE#show ip eigrp neighbor

EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.2.2 (WAN_RTR_A) Fa0/0 14 00:11:49 58 348 0 14
1 10.1.3.3 (WAN_RTR_B) Fa0/1 12 00:21:41 71 426 0 5

CORE#show ip route
<OMMITED FOR BREVITY>
D EX 192.168.1.0/24 [170/281856] via 10.1.3.3, 00:06:09, FastEthernet0/1

CORE#show ip eigrp topology

EIGRP-IPv4 Topology Table for AS(1)/ID(1.1.1.1)
<OMMITED FOR BREVITY>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
via 10.1.3.3 (281856/2816), FastEthernet0/1

Fase 3. Saídas CORE #.

WAN_RTR_A#show ip bgp summary

BGP router identifier 2.2.2.2, local AS number 2
<OMMITED FOR BREVITY>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.2.4.4 4 4 12 12 16 0 0 00:03:54 (UP) 4

WAN_RTR_A#show ip bgp
<OMMITED FOR BREVITY>
Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 10.2.4.4 0 0 4 i
*> 10.1.2.1 284416 32768 ?

WAN_RTR_A#show ip route
<OMMITED FOR BREVITY>
D EX 192.168.1.0/24 [170/284416] via 10.1.2.1, 00:08:22, FastEthernet0/0
WAN_RTR_A#

Fase 3. WAN_RTR_A # saídas.

Resumo
O comportamento de roteamento inesperada cobriam o documentada tem sido amplamente visto em muitos ambientes de produção. Topologias de rede
e sintomas iniciais podem diferir, no entanto, a causa raiz é geralmente a explicada. É importante verificar se as configurações e o cenário atendem às
variáveis para que esse problema possa surgir. Eu recomendaria para verificar em qualquer Router / L3 Switch redistribuindo entre BGP e qualquer IGP
se é suspeito que a rede está atingindo esse cenário. Além disso, é sempre uma boa prática para testar o failover funciona como pretendido
(preferencialmente, durante uma janela de manutenção). É uma parte da operação de rede que geralmente é tomada para concedido, especialmente,
quando a rede está em produção por muito tempo.

Eu tenho o mesmo problema, também eu gostaria de acrescentar que depois de executar a fase 1, onde eu tenho as duas ligações para cima e executar a
redistribuição mútua, notei no meu CORE # que quando eu faço um show eigrp topologia 192.168.1.0, It Somente mostra o caminho do link primário.

Então eu executar a fase 2 e 3, depois que o meu roteador CORE foi capaz de aprender as rotas em ambos os links.

Eu não sei por que ele não aprender as rotas a partir do link de backup na fase 1, mas ele aprende a rota na fase 2.