Compreenda a importância do atributo de trajeto do peso BGP em cenários de failover da rede

Introdução

Este documento descreve a importância do atributo de trajeto do peso do Border Gateway Protocol (BGP) em cenários de failover da rede. O BGP é de uso geral anunciar os prefixos de rede à rede de área macilento (WAN) recebida uma vez através de um Interior Gateway Protocol (IGP) da rede de área Lan (LAN) e vice-versa. Sem a configuração correta no lugar, o BGP pode não restaura o caminho de roteamento original sobre WAN depois que a rede recupera de uma falha do link.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Border Gateway Protocol (BGP)
• Redistribução dos protocolos de roteamento
• Roteador Cisco que executa o ^{® do} Cisco IOS

Componentes Utilizados

A informação neste documento é baseada em um roteador Cisco com versão do Cisco IOS 15.6(2)

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

O Roteadores distribuído nos cenários de failover pode ter as rotas coladas que podem causar a uma reorientação do tráfego sobre o cargo do caminho backup um evento de rede da falha e da recuperação. Isto pode acontecer devido à natureza do atributo de trajeto do peso BGP.

Após uma falha de rede ocorre (geralmente com o link MACILENTO) a rede pode convirgir e usar o caminho backup disponível recebido através do IGP.

Contudo, em cima da recuperação do caminho principal, o roteador pode ainda usar o caminho backup e não restaurar a rota original sobre o link MACILENTO.

As consequências como trajetos assimétricos e do roteamento subótimo podem ser consideradas.

Em encenações da Redundância com dois WAN Router, estes podem executar o BGP para trocar prefixos de rede com WAN. Um IGP como o Enhanced Interior Gateway Routing Protocol (EIGRP) pode ser usado para trocar prefixos de rede com os dispositivos da rede de LAN. A redistribuição mútua entre estes protocolos é geralmente necessária para realizar a conectividade de rede completa.

Nota: Este documento utiliza o prefixo e a rota dos termos permutavelmente.

O projeto de nível elevado deste pode ser considerado no topolgy seguinte:

Grupo do atributo de trajeto do peso BGP em rotas localmente originadas

A encenação seguinte descreve o comportamento do atributo de trajeto do peso BGP na falha sobre casos.

Etapa 1. A rota é recebida através do BGP.

Segundo as indicações da imagem, o roteador nomeado WAN RTR recebe a rede 192.168.1.0/24 através do BGP.

Com uma distância administrativa (AD) de 20, a rota é-lhe instalada na tabela de roteamento.

Tabela de BGP:

WAN_RTR#show ip bgp
. . .
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.2.2                 0             0 2 i

A tabela de roteamento mostra a rota instalada pelo BGP:

WAN_RTR#show ip route
. . .
B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:42

Etapa 2. A rota é recebida através do EIGRP.

A sessão de BGP vai abaixo de devido à falha do link. Pela convergência de rede, a mesma rota 192.168.1.0/24 é recebida agora através do EIGRP.

O ponto chave é que o BGP pode anunciar ou redistribuir rotas de EIGRP na configuração do roteador. Se aquele é o caso, a rota de EIGRP está adicionada agora à tabela de BGP.

Nota: O atributo de trajeto do peso BGP está ajustado a 32768 à revelia quando o roteador localmente origina prefixos de rede.

Configuração de BGP:

WAN_RTR#show running-config | begin router bgp

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

Nota: A máscara 255.255.255.0 de 192.168.1.0 da rede do comando bgp pode mostrar os mesmos resultados.

Tabela de BGP:

WAN_RTR#show ip bgp
. . .

     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.3.3            156160         32768 ?

A tabela de roteamento mostra a rota instalada pelo EIGRP:

WAN_RTR#show ip route
. . .

D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:00:02, FastEthernet0/1
WAN_RTR#

Etapa 3. Rota recebida através do BGP outra vez.

Com a rota de EIGRP redistribuída agora no BGP e depois que a rota original é recebida através do BGP mais uma vez, há agora 2 entradas para a rede 192.168.1.0/24 na tabela de BGP.

Tabela de BGP:

WAN_RTR#show ip bgp
. . .

     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 ?

Na tabela de BGP:

 - A entrada criada em etapa 2 pela rota de EIGRP redistribuída no BGP pode ainda ser considerada.

 - A rota original é adicionada para trás por meio da sessão de BGP restabelecida.

Do ponto de vista da seleção de melhor caminho do BGP:

- O valor do atributo de trajeto do peso da rota de EIGRP redistribuída no BGP é ajustado a 32768 desde que é originado localmente no roteador do ponto de vista do BGP.

- O vaue do atributo de trajeto do peso da rota original recebida através da sessão de BGP com WAN é 0.

- A primeira rota tem o peso o mais alto e é elegida consequentemente como melhor na tabela de BGP.

- Isto faz com que a tabela de roteamento não convirja de volta ao estado original e mantenha a entrada da rota de EIGRP.

Nota: O atributo de trajeto do peso do BGP é o primeiro atributo de trajeto BGP verifica dentro a eleição do melhor caminho na tabela de BGP no Roteadores do Cisco IOS. O BGP prefere o trajeto para a entrada com o peso o mais alto. O peso é um parâmetro específico da Cisco e é somente localmente - significativo no roteador onde é configurado. Mais informação através do algoritmo de seleção de caminho do melhors BGP.

Tabela de roteamento:

WAN_RTR#show ip route
. . .
D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:08:55, FastEthernet0/1

Altere o atributo de trajeto do peso BGP

O valor padrão do atributo de trajeto do peso BGP pode ser alterado no configurado pelo bgp peer com o uso do comando weight ou de um mapa de rotas.

Os comandos set que seguintes o atributo de trajeto do peso a 40000 para todas as rotas recebeu do bgp peer.

Exemplo nenhum 1.

router bgp 1
 neighbor 10.1.2.2 weight 40000

Exemplo nenhuns 2.

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

Exemplo nenhuns 3.

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

Com o valor do peso o atributo de trajeto aumentou, as rotas originais recebidas através do BGP toma a precedência como visto no caso seguinte:

Etapa 1. A rota é recebida através do BGP.

A tabela de BGP mostra que as rotas recebidas através do BGP têm agora um valor do peso de 40000 em vez de zero.

Tabela de BGP:

WAN_RTR#show ip bgp
. . .

     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.2.2                 0         40000 2 i

WAN_RTR#

 Tabela de roteamento:

WAN_RTR#show ip route
. . .
B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:09:53

Etapa 2. A rota é recebida através do EIGRP.

As rotas localmente originadas ainda têm um valor de 32768 na tabela de BGP.

Tabela de BGP:

WAN_RTR#show ip bgp
. . .
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.3.3            156160         32768 ?

Tabela de roteamento:

WAN_RTR#show ip route
. . .
D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:01:41, FastEthernet0/1

Etapa 3. Rota recebida através do BGP outra vez.

Com peso 40000, as rotas recebidas através do BGP são elegidas agora sobre originam localmente. Isto faz a rede corretamente convirgir de volta a seu estado original.

Tabela de BGP:

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

Tabela de roteamento:

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

Cenário de caso real

Tomada como um exemplo a encenação seguinte:

Etapa 1. Estado da rede original.

O 3 Switch da camada central recebe a rota 192.168.1.0/24 através do EIGRP de WAN RTR A e de WAN RTR B. O trajeto sobre WAN RTR A é elegido.

A saída seguinte mostra como o switch central mantém uma adjacência EIGRP com ambos os WAN Router e que WAN RTR A está elegido para alcançar a rede 192.168.1.0/24.

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
. . .
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)
. . .
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

Etapa 2. Falha do enlace de WAN principal.

Em caso de uma falha do link, o switch central instala agora a rota através do trajeto do segundo melhor EIGRP que é WAN RTR B.

CORE#show ip route
. . .
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)
. . .
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
        via 10.1.3.3 (281856/2816), FastEthernet0/1

Etapa 3. Restauração do enlace de WAN principal.

O enlace de WAN principal foi restaurado. Contudo, do switch central as rotas ainda sobre o caminho backup como visto na saída seguinte:

CORE#show ip route
. . .
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)
. . .
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
        via 10.1.3.3 (281856/2816), FastEthernet0/1

A razão deste comportamento encontra-se no atributo de trajeto do peso BGP como foi discutido.

No estado atual, WAN RTR A mostra que a rota na tabela de Roting através do EIGRP e na tabela de BGP redistribuída do EIGRP devido ao valor o mais alto do atributo de trajeto do peso ganha sobre o valor do peso da rota recebida através do BGP do link MACILENTO restabelecido.

WAN_RTR_A#show ip bgp
. . .
    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 bgp summary
BGP router identifier 2.2.2.2, local AS number 2
. . .
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 route
. . .
D EX  192.168.1.0/24 [170/284416] via 10.1.2.1, 00:08:22, FastEthernet0/0

O comportamento coberto neste documentado foi considerado extensamente no campo. As topologias de rede e os sintomas da inicial podem diferir do exemplo coberto. Contudo, a causa de raiz pode ser e é frequentemente como descrito neste documento. É importante verificar se as configurações e a encenação encontram as variáveis para que esta circunstância elevare em sua distribuição de rede.