Visibilidade de rotas BGP e análise de caminhos

1. Demo BGP

A demo BGP gerada é carregada automaticamente. Contém 13 routers, 22 sessões BGP e dois refletores de rotas com capacidades BMP deliberadamente diferentes.

1. Confirme que a topologia demo gerada está presente; não é necessário importar dados nem carregar a demo manualmente.
2. Abra a Vista geral e confirme que a sobreposição BGP está visível. Está ativada por predefinição; o controlo permite ocultá-la e restaurá-la.
3. Localize os routers com Router ID 123.123.100.100 (RFC 7854) e 123.123.101.101 (RFC 7854 + RFC 9069 + RFC 8671). Estas RFC identificam as RIB que o Topolograph recebe através de BMP de cada refletor de rotas.

A topologia IGP permanece como grafo base. A sobreposição BGP adiciona sessões sem substituir a conectividade OSPF.

2. Sessões BGP

Use as duas representações: a tabela permite filtrar sessões BGP com precisão, enquanto a sobreposição gráfica mostra onde a sessão selecionada se encontra na topologia.

1. Abra Sessões BGP e filtre a coluna peer ip por 123.123.31.31.
2. Confirme que 123.123.31.31 (PE31) tem uma sessão BGP, com 123.123.100.100 (RR1), e nenhuma com 123.123.101.101 (RR2).
3. Volte à Vista geral e localize a mesma adjacência entre PE e 123.123.100.100 (RR1) na sobreposição BGP.

A tabela Sessões BGP filtrada demonstra concretamente a limitação da RFC 7854: 123.123.31.31 (PE31) tem uma sessão observada, com 123.123.100.100 (RR1).

Este PE31, com uma sessão BGP, demonstra a limitação da RFC 7854 utilizada mais adiante no runbook.

3. Vista RIB

Uma sessão BMP estabelecida com um refletor de rotas não fornece automaticamente uma vista da tabela de cada cliente do RR. Uma sessão BMP capaz de exportar Loc-RIB fornece a vista mais precisa do estado da tabela de encaminhamento. O Topolograph também pode trabalhar com pressupostos explícitos quando alguma informação não está disponível. Por exemplo, o estado RIB de um dispositivo pode ser inferido a partir do Adj-RIB-Out post-policy RFC 8671 de um speaker BMP vizinho dirigido a esse dispositivo, mesmo sem uma sessão BMP com o próprio dispositivo.

Cobertura das RFC BMP e significado para o cálculo de caminhos

Routers da rede demo e visibilidade da informação de encaminhamento

O RR2 exporta dados Adj-RIB-Out post-policy através de BMP apenas para vizinhos BGP selecionados. Isto é válido: a monitorização BMP Adj-RIB-Out é configurada por vizinho BGP e família de endereços, embora o BGP mantenha um Adj-RIB-Out para cada vizinho estabelecido.

4. Rotas BGP

Comece pela tabela Rotas BGP de todo o grafo antes de restringir a pesquisa a um router. Aqui pode inspecionar e filtrar os dados de rotas recolhidos para toda a demo.

1. Abra a tabela do grafo, selecione Rotas BGP e mantenha o modo Live.
2. Use as colunas prefix, bmp source, bmp ribs, peer ip e atributos de caminho para encontrar o conjunto de rotas que pretende investigar.

A tabela Live em ecrã inteiro apresenta as Rotas BGP de todo o grafo.

A tabela Rotas BGP mostra as rotas recolhidas para todo o grafo.

5. Vista de rotas no formulário do dispositivo

O número de rotas no formulário mostra a vista RIB desse router: a sua Loc-RIB recebida através de uma sessão BMP com o dispositivo ou o Adj-RIB-Out post-policy recebido através de uma sessão BMP com um dispositivo vizinho.

1. Clique em PE14 no grafo e localize a secção BGP no formulário do dispositivo.
2. Confirme que Routes é 4 e leia a explicação: o RR2 anunciou as rotas a este router através da RFC 8671.
3. Leia a divisão RIB. Adj-RIB-Out post-policy descreve a RIB exportada pelo RR2; da perspetiva do PE14, estes quatro anúncios são o seu Adj-RIB-In inferido.
4. A linha Adj-RIB-Out (post) 4 está incluída em Routes: é o Adj-RIB-Out do RR2 para o PE14, usado como Adj-RIB-In inferido do PE14.

Este formulário mostra a vista RIB do PE14: quatro rotas Adj-RIB-Out post-policy recebidas do RR2 através de BMP.

O formulário do PE14 mostra quatro rotas, fonte BMP RR2 e RIB Adj-RIB-Out post-policy. Routes não inclui rotas anunciadas pelo PE14 ao RR2 nem outras observações BMP não usadas na vista RIB do PE14.

6. Filtragem, ordenação e paginação das rotas de um nó

Abra a tabela de rotas a partir do formulário; a tabela mantém o âmbito RIB selecionado para o PE14.

1. Clique em Routes 4 no PE14. Confirme que o painel contém exatamente 100.30.0.0/24, 10.100.31.0/24, 2001:db8:123:123:30:30::/96 e 2001:db8:100:31::/64.
2. Filtre prefix por 100.30.0.0/24. As linhas correspondentes e o contador devem passar de 4 para 1.
3. Limpe o filtro e examine outros atributos separadamente: local pref = 250 deixa duas rotas VPN, afi = 2 deixa duas rotas IPv6 e med = 20 deixa duas rotas do PE30.
4. Limpe os filtros e confirme que as quatro rotas do PE14 regressam. Limpar um filtro não deve remover o âmbito do dispositivo definido pelo formulário.
5. Clique num cabeçalho ordenável, como prefix, nexthop, local pref ou med. Os cliques alternam entre ascendente, descendente e sem ordenação; as colunas de endereços usam ordenação de endereços, não de texto.
6. Use Rows per page para tabelas grandes. A demo tem apenas uma página neste exemplo, por isso os controlos anterior e seguinte permanecem desativados.

A tabela mantém o âmbito do PE14 e adiciona o filtro de prefixo, deixando uma rota.

A linha filtrada mostra o RR2 como fonte bmp e Adj-RIB-Out post-policy como RIB observada.

7. Seleção do melhor caminho

Para cada prefixo, a demo demonstra um critério de seleção. Comece por AS_PATH: compare os atributos candidatos, construa a rota a partir do RR2 e verifique o próximo salto BGP selecionado.

Exemplo inicial: AS_PATH vence

1. Filtre Rotas BGP por 198.18.2.0/24.
2. Compare os candidatos: ambos têm Local Preference 100, Origin IGP e MED 10. O PE30 anuncia AS_PATH 65010 65011 65012; o PE14 anuncia AS_PATH 65010.
3. Mude para o modo de caminho BGP / VPN. Defina Router como RR2, VPN or global table como global e To como 198.18.2.0/24; depois selecione Build a path.
4. Em Route resolution, confirme que a primeira linha é BGP no RR2 com próximo salto PE14. As restantes linhas resolvem esse próximo salto através de IGP.

Selecione o formulário BGP / VPN e introduza RR2, a tabela global e este prefixo.

Em Route resolution, a primeira linha mostra o RR2 a selecionar o PE14 como próximo salto BGP; as linhas seguintes são construídas com dados OSPF.

Os candidatos post-policy diferem no comprimento de AS_PATH, enquanto Local Preference, Origin e MED estão empatados. A rota a partir do RR2 seleciona o PE14 como próximo salto BGP; as linhas IGP mostram a acessibilidade até esse salto.

Outros exemplos de seleção do melhor caminho

Critérios adicionais de seleção

A demo mostra os seis critérios da tabela. Não demonstra a preferência de eBGP sobre iBGP, o custo IGP até ao próximo salto, a idade da rota, o comprimento de cluster-list nem o endereço do vizinho BGP.

8. Comparação do estado das rotas entre dois instantes

Live mostra o estado atual. Compare avalia o estado em T0 e T1.

1. Abra a tabela Rotas BGP de todo o grafo e mude de Live para Compare.
2. Mantenha a janela predefinida de uma hora entre T0 e T1 criada quando a demo é carregada e prima Run.
3. A tabela mostra uma rota adicionada, 100.14.210.0/24; changed at contém a hora da última alteração antes de T1.
4. added significa ausente em T0 e presente em T1; withdrawn, presente em T0 e ausente em T1; changed, presente nos dois instantes mas com atributos diferentes. Os eventos depois de T1 ficam fora da comparação.
5. Volte a Live para abrir o estado atual.

A comparação mostra a diferença entre os extremos da janela demo, não um registo cronológico de eventos.

No intervalo predefinido, 100.14.210.0/24 tem estado added e MED 80 em T1.

Eventos BGP individuais

Events usa o mesmo painel e intervalo temporal, mas mantém cada observação de rota e peer em vez de as reduzir a uma diferença T0-T1.

1. Mude de Compare para Events e mantenha uma janela que cubra as alterações da demo.
2. Prima Run e verifique uma rota adicionada, um evento peer down e uma alteração de rota para 100.14.210.0/24.
3. Use event, kind, prefix, peer source, peer target e at para distinguir alterações de rota de alterações do estado da sessão.

Events apresenta cronologicamente a rota adicionada, o evento peer-down e a rota alterada com MED 80.

Events mostra as três observações por ordem. Ao contrário de Compare, mantém eventos intermédios mesmo quando o estado final não muda.

9. Resolução do próximo salto BGP através de OSPF

O BGP escolhe a rota; o OSPF fornece acessibilidade ao próximo salto BGP selecionado. A vista mostra explicitamente essa transição.

1. No modo Standard / IGP, use o PE30 como origem e 100.14.0.0/24 como destino.
2. Inspecione a linha BGP selecionada e identifique o PE14 como próximo salto BGP.
3. Abra Route resolution e leia da esquerda para a direita: a primeira linha é BGP com distância administrativa 200 e próximo salto PE14.
4. Continue pelas cinco linhas IGP com distância administrativa 110 que resolvem fisicamente a acessibilidade do PE30 ao PE14.

A tabela separa a escolha da rota BGP dos saltos IGP que tornam o seu próximo salto acessível.

O próximo salto BGP aponta para o PE14; o resto da rota é construído com dados OSPF.

10. Vista sem possibilidade de construir um caminho

Filtre por PE31. O Topolograph mostra as rotas que o RR1 recebeu do PE31, mas a RFC 7854 por si só não revela a rota instalada pelo PE31 nem o que o RR1 lhe anunciou.

1. Abra Rotas BGP e filtre peer ip por PE31. Adj-RIB-In (pre) e (post) mostram as rotas que o RR1 recebeu do PE31, não a tabela do PE31.
2. Abra o formulário BGP / VPN e selecione Router PE31. O formulário avisa que a tabela não é observada e não permite construir um caminho com dados BGP.
3. Compare PE31 com PE15: para PE15, o Topolograph usa a Loc-RIB do RR2 e pressupõe explicitamente que o RR2 lhe anunciou a rota e que o PE15 aplicou a sua política de entrada.

O Topolograph não constrói um caminho quando os dados BMP disponíveis não descrevem a tabela do dispositivo selecionado. Para remover este limite, forneça a Loc-RIB do dispositivo através da RFC 9069 ou o seu Adj-RIB-Out post-policy por vizinho através da RFC 8671.