Comandos OSPF
| Fabricante | LSA1 | LSA2 | LSA5 | Opaque-area (TE) |
|---|---|---|---|---|
| Cisco | show ip ospf database router | show ip ospf database network | show ip ospf database external | — |
| Cisco NX-OS | show ip ospf database router detail | show ip ospf database network detail | show ip ospf database external detail | — |
| Fortinet | get router info ospf database router lsa | get router info ospf database network lsa | get router info ospf database external lsa | — |
| FRR/Quagga | show ip ospf database router | show ip ospf database network | show ip ospf database external | show ip ospf database opaque-area |
| Ruckus | show ip ospf database link-state router | show ip ospf database link-state network | show ip ospf database external-link-state | — |
| Juniper | show ospf database router extensive | no-more | show ospf database network extensive | no-more | show ospf database external extensive | no-more | — |
| Bird | show ospf state all | show ospf state all | show ospf state all | — |
| Nokia | show router ospf database type router detail | show router ospf database type network detail | show router ospf database type external detail | — |
| Mikrotik | /routing ospf lsa print detail file=lsa.txt | /routing ospf lsa print detail file=lsa.txt | /routing ospf lsa print detail file=lsa.txt | — |
| Huawei | display ospf lsdb router | display ospf lsdb network | display ospf lsdb ase | — |
| Paloalto | show routing protocol ospf dumplsdb | show routing protocol ospf dumplsdb | show routing protocol ospf dumplsdb | — |
| — | ||||
| Ubiquiti | show ip ospf database router | show ip ospf database network | show ip ospf database external | — |
| Allied Telesis | show ip ospf database router | show ip ospf database network | show ip ospf database external | — |
| Extreme | show ospf lsdb detail lstype router | show ospf lsdb detail lstype network | show ospf lsdb detail lstype as-external | — |
| Ericsson | show ospf database router detail | show ospf database network detail | show ospf database external detail | — |
| Obrigatoriedade | YES | YES | NO | Opcional (TE) |
Comandos OSPFv3
Visualização de topologia LSDB OSPFv3 (RFC 5340). Salve a saída do comando em um arquivo com extensão .txt ou .log e envie para o Topolograph.
| Fabricante | Comando | Suporte a API |
|---|---|---|
| Arista | show ipv6 ospf database detail | YES |
Salve a saída de pelo menos dois comandos OSPF (para obter LSA1 e LSA2) ou de um único comando IS-IS e envie para o Topolograph com extensão .txt ou .log.
Comandos IS-IS
| Fabricante | Comando | Suporte a API |
|---|---|---|
| Cisco | show isis database detail | YES |
| Juniper | show isis database extensive | YES |
| Nokia | show router isis database detail | YES |
| Huawei | display isis lsdb verbose | YES |
| FRR | show isis database detail* (router-isis#no hostname dynamic) | YES |
*O FRR mistura LSPIDs e nomes de host dinâmicos na LSDB IS-IS, por isso apenas a construção de topologia IS-IS sem nomes de host é suportada. «no hostname dynamic» desativa os nomes de host dinâmicos na LSDB IS-IS local.
Suporte a TLV IS-IS
| Nome do TLV | Número do TLV | Cisco | Juniper | Nokia | FRR | Huawei | ZTE |
|---|---|---|---|---|---|---|---|
| IS Reachability | 2 | YES | YES | YES | YES | YES | |
| Extended IS Reachability (new) | 22 | YES | YES | YES | YES | YES | YES |
| IPv4 Internal Reachability (old) | 128 | YES | YES | YES | YES | YES | |
| IPv4 External Reachability (old) | 130 | ||||||
| Extended IPv4 Reachability (new) | 135 | YES | YES | YES | YES | YES | YES |
| IPv6 Reachability | 2 | YES | YES | YES | YES | YES | YES |
Visão geral (GeneralView)
A rede de demonstração já está carregada para todos. Pressione «Load dynamic graph» para carregá-la. Após o carregamento, você verá a topologia; as linhas em negrito indicam links ECMP.
Pressione a linha em negrito para expandir o ECMP e ver todos os links aninhados.
Caminho mais curto. Como construir.
É possível construir o caminho mais curto a partir de um nó. Clique com o botão direito sobre um nó. A descrição com todos os nós e o custo do caminho fica disponível acima da topologia.
Após definir a origem e o destino, o caminho mais curto ficará destacado.
Todos os caminhos mais curtos para todos os nós. Árvore de caminhos mínimos.
Nova funcionalidade da versão v2.11. O MST permite ver todos os caminhos mais curtos para ou a partir de um nó. Ative-o por este seletor.
Nova funcionalidade da v2.11. Todos os caminhos mais curtos de entrada são construídos em direção ao nó.
Nova funcionalidade da v2.11. Todos os caminhos mais curtos de saída são construídos a partir do nó.
Nova funcionalidade da v2.13. Diferença entre os caminhos mais curtos de entrada e de saída do nó selecionado.
Busca do dispositivo de terminação de rede
Como saber quais redes são terminadas em um nó específico? Há duas formas. A primeira: comece a digitar o ID do nó no campo «Find node by RID/IP. Find network» e você verá todas as redes terminadas naquele nó.
O segundo método é clicar sobre um nó. Um formulário aparece com a lista de todas as redes com e sem backup. Uma rede é considerada com backup se estiver terminada em pelo menos dois nós.
Caminhos de backup. Emulação de falha de link.
Para encontrar o caminho de backup, pressione a aresta destacada. Você simulará uma falha de link e o caminho mais curto será reconstruído evitando a aresta «com falha».
Reconstrução do caminho mais curto alterando o custo OSPF dinamicamente
É possível alterar o custo OSPF de qualquer link. Clique com o botão direito sobre uma aresta e um formulário aparecerá. Digite o novo custo. Imagine que precisamos redirecionar o fluxo de tráfego do link 123.10.10.10 - 123.30.30.30 para outro link.
Clique com o botão direito na aresta destacada e defina 12. Obteremos um novo fluxo de tráfego com o novo custo OSPF.
Comparar o estado da rede em diferentes momentos
Ao realizar alterações de configuração (adicionar uma nova rede, redistribuir outro protocolo no OSPF ou alterar filtros em route-maps) é altamente recomendável verificar que os resultados correspondem ao esperado. Para isso, envie o estado da rede antes e depois das alterações e compare-os. Será mostrado:
- Nós novos/removidos
- Redes novas/removidas
- Links com custo OSPF novo/antigo
NetworkReactionOnFailure
Neste modo é possível simular a queda de um link ou roteador. A topologia será repintada com o fluxo de tráfego esperado evitando o elemento com falha.
Reação da rede quando um link cai. Simular queda de link.
Carregue um grafo se ainda não fez isso e pressione NetworkReactionOnFailure.
- Linhas azuis mostram o aumento de tráfego no link
- Linhas cinzas mostram a diminuição de tráfego no link
Como pode ser visto, a taxa de diminuição de tráfego do nó 123.30.30.30 para 123.123.30.30 e 123.123.31.31 difere da direção oposta [de 123.123.30.30 para 123.30.30.30] em até ~2 vezes. Isso ocorre por causa do caminho de tráfego assimétrico.
Também podemos ver o aumento esperado de tráfego na aresta pintada de azul.
Reação da rede quando um link cai em meio compartilhado.
O Topolograph constrói a topologia com base na adjacência OSPF e a conectividade física está oculta. Em alguns casos, podemos assumir que os vizinhos compartilham o mesmo meio. Por exemplo, se os vizinhos têm um DR comum, assumimos que estão conectados por meio físico compartilhado e ao emular a falha de uma aresta entre esses vizinhos, todas as arestas são emuladas como caídas.
Marcar todos os links de meio compartilhado (com DR comum) como habilitados
Reação da rede quando um link cai em meio dedicado.
Se os vizinhos não têm DR ou têm, mas apenas dois vizinhos estão no link, ao emular a falha de aresta é removido apenas o link entre esses dois vizinhos específicos.
Marcar todos os links de meio compartilhado (com DR comum) como desabilitados
Reação da rede quando um dispositivo cai. Simular queda de dispositivo.
Clique com o botão direito sobre um nó e escolha «shutdown this node». O algoritmo exclui esse nó.
A reação da rede ante a queda do nó 123.123.101.101.
Reação da rede a alterações de custo de link OSPF.
Na aba NetworkReactionOnFailure é possível ver a reação da rede a uma alteração de custo OSPF dinamicamente. Defina o novo custo OSPF no menu de contexto da aresta (clique com o botão direito).
Modo de design de rede
OSPF/IS-IS LSDB <-> YAML são intercambiáveis nos dois sentidos: permite projetar um domínio IGP do zero ou com base em uma LSDB carregada, adicionar novos links ou alterar custos, e verificar a reação da rede.
Topologia básica baseada em YAML.
Construa um grafo com nós e arestasdefinidos.
Atributos de nó
O nome do nó é obrigatório. Deve estar no formato de endereço IP. Para alterá-lo para outro valor, use label
As tags de nó são opcionais. Qualquer par chave (string): valor (str, int, float, dicionário, lista).
Há um grafo com 6 nós. Selecione todos os nós primários (ha_role: primary) no primeiro DC (dc1)
Atributos de aresta
src, dst são obrigatórios.
cost é opcional. O padrão é 1. Equivale ao custo OSPF/IS-IS.
directed é opcional. O padrão é false.
As tags de aresta são opcionais. Qualquer par chave (string): valor (str, int, float, dicionário, lista).
Selecione todas as arestas do ISP verizon entre 10.10.10.2 e 10.10.10.4
Reação da rede ao adicionar um novo link.
Vamos adicionar um novo link com custo 1 entre os dispositivos R3 (10.10.10.3) e R4 (10.10.10.4) e ver como a rede reage.
Claramente, o tráfego aumenta no link direto R3<->R4 e diminui para R2 (10.10.10.2) e R5 (10.10.10.5).
Análise
Neste modo é possível executar algoritmos para verificar sua rede OSPF.
Links unidirecionais e assimétricos.
Exibe todos os links unidirecionais (o número de links IN e OUT entre dois vizinhos não é igual)
A aresta está marcada em vermelho por ter métricas OSPF diferentes: custo 1 e custo 10
Caminhos assimétricos.
Exibe todos os caminhos assimétricos de diferentes pontos de vista.
Obtemos uma lista de nós com caminhos assimétricos. Ao analisá-los, é possível ver a diferença entre os caminhos de entrada e de saída.
Caminhos principais e de backup pelo mesmo ECMP.
Supomos que se vários links estão agrupados em ECMP e o link principal cai, o caminho de backup deve passar pelo segundo link do mesmo ECMP.
Verificação aprovada
Se o caminho de backup não passa pelo ECMP e escolhe uma rota completamente diferente, o relatório é considerado reprovado.
Verificação reprovada
Caminhos de backup por localizações de terceiros.
Este relatório verifica que, se duas localizações estão diretamente conectadas, os caminhos de backup devem ser apenas entre essas duas localizações e não passar por uma terceira como trânsito. Antes de executá-lo, é necessário criar grupos (~nomes de sites/localizações) e atribuir dispositivos aos grupos. Por exemplo, há duas localizações na França: a principal (EU_FRA) e a remota (EU_FRA1). O mesmo esquema com escritórios na Itália. Os escritórios principais da França e da Itália estão conectados entre si com um link principal (custo OSPF 10) e um de backup (custo OSPF 20).
Os escritórios remotos têm o link principal (custo OSPF 1) para seus escritórios principais e o link de backup (custo OSPF 10) para o escritório estrangeiro.
Verificação reprovada
Mapa de calor da rede
Na aba Analytics é possível ver quantas sub-redes terminadas têm backup mediante a terminação da mesma sub-rede em dispositivos diferentes.
Clique sobre um nó para descobrir quais redes têm backup e quais não têm.
Como pode ser visto, apenas o loopback do próprio dispositivo não tem backup, o que é normal.
Redes duplicadas [MPLS]
"Análise/Redes terminadas duplicadas. O problema que o MPLS tem com duplicações de IP na rede deve-se ao fato de que os rótulos são gerados com base em blocos IP, que podem ser duplicados. Como resultado, o mesmo bloco IP pode ser associado a rótulos diferentes. Isso faz com que o mesmo bloco, com rótulos distintos, se propague para outros roteadores, incluindo aquele com o IP duplicado. Torna-se problemático ao implementar MPLS Traffic Engineering (MPLS-TE) ou RSVP-TE, pois pode degradar o desempenho e causar erros de roteamento. Portanto, a duplicação de blocos é crítica em ambientes MPLS, principalmente pela geração de rótulos duplicados para o mesmo bloco. Nos roteadores, isso causa confusão ao recalcular caminhos TE ou RSVP-TE."
| Rede | Número de nós terminadores | Nomes dos nós |
|---|---|---|
| 10.0.0.0/24 | 4 | [172.16.1.2, 172.26.1.2], [172.30.2.1, 178.20.3.1] |
A rede 10.0.0.0/24 é terminada em quatro nós: 172.16.1.2 e 172.26.1.2 estão diretamente conectados, 172.30.2.1 e 178.20.3.1 estão diretamente conectados, mas não entre si.
API
Você pode usar sua ferramenta NetDevOps favorita (Ansible, netmiko, Nornir, Topolograph SDK, etc.) para enviar o grafo de rede OSPF para o Topolograph via requisição POST. Após o envio, você receberá a diferença em relação aos grafos enviados anteriormente, especificamente:
- adjacências OSPF novas/removidas (arestas no grafo)
- dispositivos novos/removidos na topologia OSPF
- número de sub-redes com e sem backup na topologia
Obter credenciais.
É necessário criar uma conta com email e senha na página Login/Registro, além de adicionar seu IP/rede de origem à lista de redes autorizadas na aba API.
Enviar topologia OSPF via API
Salve a saída dos comandos com LSA1, LSA2, LSA5 em um único arquivo - cisco_lsdb_output.txt
import requests
from pprint import pprint as pp
with open('cisco_lsdb_output.txt') as f:
lsdb_output = f.read()
r_post = requests.post('https://topolograph.com/api/graph', auth=('youraccount@domain.com', 'your-pass'),
json={'lsdb_output': lsdb_output, 'vendor_device': 'Cisco'})
pp(r_post.json())
Com Python lemos o conteúdo do arquivo e o enviamos (requisição POST) para o Topolograph.
A resposta contém:
>>> pp(r_post.json())
{'diff': {'compared_with_graph_time': '02Jun2021_21h18m04s_13_hosts',
'graphs_diff': {'all_edges_stats_ll': [{'dst_node': '123.123.110.110',
'link_cost': 10,
'link_status': 'old',
'src_node': '123.123.100.100'},
{'dst_node': '123.123.111.111',
'link_cost': 10,
'link_status': 'old',
'src_node': '123.123.101.101'},
{'dst_node': '123.123.100.100',
'link_cost': 10,
'link_status': 'old',
'src_node': '123.123.110.110'},
{'dst_node': '123.123.101.101',
'link_cost': 10,
'link_status': 'old',
'src_node': '123.123.111.111'}],
'new_nodes': [],
'old_nodes': []},
'networks_diff': {'new_subnets_attr_dd_ll': [{'rid': '123.30.30.30',
'subnet': '30.30.30.30/32'}],
'old_subnets_attr_dd_ll': [{'rid': '123.10.10.10',
'subnet': '1.2.3.0/30'}]}},
'graph_time': '08Jun2021_20h15m26s_13_hosts',
'hosts': {'count': 12},
'networks': {'backuped': 14,
'count': 38,
'notbackuped': 24,
'url_link': 'https://topolograph.com/api/network/08Jun2021_20h15m26s_13_hosts'},
'reports': {'asym_edges_pass_status': False},
'timestamp': '2021-06-8T20:15:26.265000'}
Diferença visual entre estados OSPF.
>>> pp(r_post.json())
{'diff': {'compared_with_graph_time': '02Jun2021_21h18m04s_13_hosts',
'graphs_diff': {'all_edges_stats_ll': [{'dst_node': '123.123.110.110',
'link_cost': 10,
'link_status': 'old',
'src_node': '123.123.100.100'},
{'dst_node': '123.123.111.111',
'link_cost': 10,
'link_status': 'old',
'src_node': '123.123.101.101'},
{'dst_node': '123.123.100.100',
'link_cost': 10,
'link_status': 'old',
'src_node': '123.123.110.110'},
{'dst_node': '123.123.101.101',
'link_cost': 10,
'link_status': 'old',
'src_node': '123.123.111.111'}],
'new_nodes': [],
'old_nodes': []},
'networks_diff': {'new_subnets_attr_dd_ll': [{'rid': '123.30.30.30',
'subnet': '30.30.30.30/32'}],
'old_subnets_attr_dd_ll': [{'rid': '123.10.10.10',
'subnet': '1.2.3.0/30'}]}},
'graph_time': '08Jun2021_20h15m26s_13_hosts',
'hosts': {'count': 12},
'networks': {'backuped': 14,
'count': 38,
'notbackuped': 24,
'url_link': 'https://topolograph.com/api/network/08Jun2021_20h15m26s_13_hosts'},
'reports': {'asym_edges_pass_status': False},
'timestamp': '2021-06-8T20:15:26.265000'}
Enviar múltiplos LSDBs OSPF via API
A topologia é construída com base em LSA1 e LSA2, que são específicos de cada área. Para redes com múltiplas áreas, é necessário salvar a saída da LSDB de vários dispositivos em arquivos separados no formato Nome do fabricante_nome do protocolo.txt
Por exemplo, dois LSDBs: Cisco_ospf.txt, Juniper_ospf.txt
Os LSDBs são salvos na pasta lsdb_samples e empacotados em um dicionário de atributos LSDB
{'lsdb_output': '...lsdb output...', 'vendor_device': 'Cisco, Juniper...', 'igp_protocol': 'ospf|isis'}
Exemplo completo:
import requests
TOPOLOGRAPH_HOST="127.0.0.1"
TOPOLOGRAPH_PORT=5000
TOPOLOGRAPH_WEB_API_USERNAME_EMAIL="your login"
TOPOLOGRAPH_WEB_API_PASSWORD="your password"
from pprint import pprint as pp
lsdbs_attr_ll = []
lsdb_dir = os.path.join(os.getcwd(), 'lsdb_samples')
for vendor_name, protocol_name in [('Cisco', 'ospf'), ('Juniper', 'ospf')]:
f_name = os.path.join(lsdb_dir, f"{vendor_name}_{protocol_name}.txt")
with open(f_name) as f:
lsdbs_attr_ll.append({'lsdb_output': f.read(), 'vendor_device': vendor_name, 'igp_protocol': protocol_name})
r_post = requests.post(f'http://{TOPOLOGRAPH_HOST}:{TOPOLOGRAPH_PORT}/api/graphs', auth=(TOPOLOGRAPH_WEB_API_USERNAME_EMAIL, TOPOLOGRAPH_WEB_API_PASSWORD), json=lsdbs_attr_ll, timeout=(5, 30))
pp(r_post.json())
A resposta contém:
Grupos & VRF
Múltiplas instâncias de roteamento OSPF podem existir em um único dispositivo em diferentes VRFs, causando duplicação de nós no grafo. A aba VRF permite apontar múltiplas instâncias OSPF para uma única e evitar a duplicação.
Há três VRFs e três instâncias OSPF em um roteador. Para evitar a duplicação, crie as VRFs (ou importe-as via CSV), associe o nó à VRF e aponte as instâncias duplicadas para o RID OSPF mestre.
