Entender a importância do atributo de caminho de peso BGP

Introdução

Este documento descreve a importância do atributo de caminho de Peso do Border Gateway Protocol (BGP) em cenários de failover de rede. 

Pré-requisitos

Requisitos

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

• Protocolo de gateway de borda (BGP)
• Redistribuição de protocolos de roteamento
• Roteador Cisco que executa o Cisco IOS^®

Componentes Utilizados

As informações neste documento são baseadas em um Cisco Router com Cisco IOS® versão 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 BGP é comumente usado para anunciar os prefixos de rede para a Rede de Área de Wan (WAN) uma vez recebida através de um Interior Gateway Protocol (IGP) da Rede de Área de Lan (LAN) e vice-versa. Sem a configuração correta no lugar, o BGP pode falhar em restaurar o caminho de roteamento original sobre a WAN depois que a rede se recuperar de uma falha de link.

Os roteadores implantados em cenários de failover podem ter rotas travadas, o que pode causar um redirecionamento do tráfego no caminho de backup após um evento de rede de falha e recuperação. Isso pode acontecer devido à natureza do atributo de caminho BGP Weight.

Depois que ocorre uma falha de rede (geralmente com o link WAN), a rede pode convergir e usar o caminho de backup disponível recebido através do IGP.

No entanto, na recuperação do caminho principal, o Roteador ainda pode usar o caminho de backup e não restaurar a rota original no link da WAN.

Consequências como caminhos de roteamento assimétricos e subótimos podem ser vistas.

Em cenários de redundância com dois roteadores WAN, eles podem executar o BGP para trocar prefixos de rede com a WAN. Um IGP como o Enhanced Interior Gateway Routing Protocol (EIGRP) pode ser usado para trocar prefixos de rede com os dispositivos de rede LAN. A redistribuição mútua entre esses protocolos geralmente é necessária para obter conectividade de rede completa. 

Observação: este documento utiliza os termos prefixo e rota de forma intercambiável.

O projeto de alto nível disso pode ser visto na próxima topologia:

Atributo de caminho de peso BGP definido em rotas originadas localmente

O próximo cenário descreve o comportamento do atributo BGP Weight Path em casos de failover.

Etapa 1. A rota é recebida via BGP.

Como mostrado na imagem, o Roteador chamado WAN RTR recebe a rede 192.168.1.0/24 através do BGP.

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

Tabela BGP:

WAN_RTR#show ip bgp
<snip>
     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
<snip>
B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:42

Etapa 2. A rota é recebida via EIGRP.

A sessão BGP fica inativa devido a uma falha de link. Por 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 EIGRP (com a ajuda da próxima configuração do Roteador). Se esse for o caso, a rota EIGRP é agora adicionada à tabela BGP. 

Observação: o atributo de caminho BGP Weight é definido como 32768 por padrão quando o Roteador origina prefixos de rede localmente.

Configuração de BGP:

WAN_RTR#show running-config | begin router bgp
<snip>
router bgp 1
 redistribute eigrp 1
 neighbor 10.1.2.2 remote-as 2
!

Observação: o comando BGP network 192.168.1.0 mask 255.255.255.0 pode mostrar os mesmos resultados.

Tabela de BGP:

WAN_RTR#show ip bgp
<snip>

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

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

Etapa 3. Rota recebida via BGP novamente.

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

Tabela de BGP:

WAN_RTR#show ip bgp
<snip>

     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 BGP:

 A entrada criada na etapa 2 pela rota EIGRP redistribuída no BGP ainda pode ser vista.

 - A rota original é adicionada de volta por meio da sessão BGP restabelecida.

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

- O valor do atributo de caminho Weight da rota EIGRP redistribuída no BGP está definido como 32768, pois é originado localmente no Roteador do ponto de vista do BGP.

- O valor do atributo de caminho Weight da rota original recebida através da sessão BGP com a WAN é 0.

- A primeira rota tem o peso mais alto e, portanto, é eleita como a melhor na tabela BGP.

- Isso faz com que a Tabela de Roteamento não convirja de volta para o estado original e mantenha a entrada da rota EIGRP.

Observação: o atributo BGP Weight Path é o primeiro atributo de caminho que o BGP verifica na eleição do melhor caminho na tabela BGP em Cisco IOS Routers. O BGP prefere o caminho para a entrada com o peso mais alto. O peso é um parâmetro específico da Cisco e é significativo apenas localmente no Roteador em que está configurado. Mais informações através do algoritmo de seleção de melhor caminho BGP.

Routing Table:

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

Modificar o atributo de caminho de peso BGP

O valor padrão do atributo de caminho BGP Weight pode ser modificado no configurado por peer BGP com o uso do comando weight ou de um mapa de rota.

Os próximos comandos definem o atributo de caminho Weight como 40000 para todas as rotas recebidas do peer BGP.

Exemplo 1

router bgp 1
 neighbor 10.1.2.2 weight 40000

Exemplo 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 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 atributo de caminho Weight aumentado, as rotas originais recebidas via BGP têm precedência como visto no próximo caso:

Etapa 1. A rota é recebida via BGP.

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

Tabela de BGP:

WAN_RTR#show ip bgp
<snip>

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

WAN_RTR#

 Routing Table:

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

Etapa 2. A rota é recebida via EIGRP.

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

Tabela de BGP:

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

Routing Table:

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

Etapa 3. Rota recebida via BGP novamente.

Com o peso 40000, as rotas recebidas via BGP são agora eleitas sobre as originadas localmente. Isso faz com que a rede converja corretamente de volta ao seu estado original.

Tabela de BGP:

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

Routing Table:

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

Cenário real

Tome como exemplo o próximo cenário:

Etapa 1. Estado original da rede.

O Switch CORE de Camada 3 recebe a rota 192.168.1.0/24 via EIGRP do RTR A e do RTR B da WAN. O caminho sobre WAN RTR A é escolhido.

A próxima saída mostra como o switch CORE mantém uma adjacência EIGRP com ambos os roteadores WAN e que o WAN RTR A é eleito para acessar 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
<snip>
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(10.10.10.10)
<snip>
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 link WAN principal.

Em caso de falha de link, o Switch CORE agora instala a rota através do segundo melhor caminho EIGRP, que é WAN RTR B.

CORE#show ip route
<snip>
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(10.10.10.10)
<snip>
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 link WAN principal.

O enlace principal da WAN foi restaurado. No entanto, o switch CORE ainda roteia o caminho de backup como visto na próxima saída:

CORE#show ip route
<snip>
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(10.10.10.10)
<snip>
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 para esse comportamento está no atributo de caminho BGP Weight, como foi discutido.

No estado atual, o RTR de WAN A mostra a rota na Tabela de Roteamento via EIGRP e na tabela BGP redistribuída do EIGRP devido ao valor mais alto do atributo de caminho Weight ganha sobre o valor Weight da rota recebida via BGP do link WAN restabelecido.

WAN_RTR_A#show ip bgp
<snip>
    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 10.20.20.20, local AS number 2
<snip>
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
<snip>
D EX  192.168.1.0/24 [170/284416] via 10.1.2.1, 00:08:22, FastEthernet0/0

O comportamento abordado neste documento tem sido amplamente visto no campo. As topologias de rede e os sintomas iniciais podem diferir do exemplo abordado. No entanto, a causa raiz pode ser e é frequentemente como descrito neste documento. É importante verificar se as configurações e o cenário atendem às variáveis para que essa condição surja em sua implantação de rede.