| Fournisseur | 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 | — |
| Obligatoire | YES | YES | NO | Optionnel (TE) |
Visualisation de la topologie LSDB OSPFv3 (RFC 5340). Enregistrez la sortie de la commande dans un fichier avec l'extension .txt ou .log et chargez-le dans Topolograph.
| Fournisseur | Commande | Support API |
|---|---|---|
| Arista | show ipv6 ospf database detail | YES |
Enregistrez la sortie d'au moins deux commandes OSPF (pour obtenir LSA1 et LSA2) ou d'une seule commande IS-IS et chargez-la dans Topolograph avec l'extension .txt ou .log.
| Fournisseur | Commande | Support 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 |
*FRR mélange les LSPID et les noms d'hôtes dynamiques dans le LSDB IS-IS, c'est pourquoi la construction de la topologie IS-IS sans noms d'hôtes est uniquement prise en charge. "no hostname dynamic" désactive les noms d'hôtes dynamiques dans le LSDB IS-IS local.
| Nom TLV | Numéro 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 |
Le réseau de démonstration est déjà chargé pour tout le monde. Appuyez sur `Charger le graphe dynamique` pour le charger. Une fois fait, vous pouvez voir la topologie ; les lignes en gras indiquent les liens ECMP.
Appuyez sur une ligne en gras pour développer l'ECMP et voir tous les liens imbriqués.
Il est possible de construire le chemin le plus court depuis un nœud. Cliquez simplement avec le bouton droit sur un nœud. La description avec tous les nœuds et le coût du chemin est disponible au-dessus de la topologie.
Une fois la source et la destination définies, vous obtenez le chemin le plus court coloré.
Nouvelle fonctionnalité de la version 2.11. Le MST permet de voir tous les chemins les plus courts Vers ou Depuis un nœud. Activez-le simplement via cette case à cocher radio.
Nouvelle fonctionnalité de la version 2.11. Tous les entrants les chemins les plus courts sont construits vers le nœud.
Nouvelle fonctionnalité de la version 2.11. Tous les sortants les chemins les plus courts sont construits depuis le nœud.
Nouvelle fonctionnalité de la version 2.13. Différence entre entrants et sortants les chemins les plus courts du nœud sélectionné.
Comment savoir quels réseaux sont terminés sur un nœud particulier. Il y a deux façons de le savoir. La première : commencez à saisir l'ID du nœud dans le champ "Trouver un nœud par RID/IP. Trouver un réseau" et vous verrez tous les réseaux terminés sur le nœud.
La deuxième méthode consiste simplement à cliquer sur un nœud. Un nouveau formulaire apparaît avec la liste de tous les réseaux avec et sans secours. Un réseau est considéré comme sécurisé s'il est terminé sur au moins deux nœuds.
Pour trouver le chemin de secours, cliquez simplement sur un lien coloré. Vous simulerez une panne de lien et le chemin le plus court sera reconstruit en contournant le lien défaillant.
Il est possible de modifier le coût OSPF de n'importe quel lien. Cliquez avec le bouton droit sur le lien, un nouveau formulaire apparaît. Saisissez le nouveau coût OSPF dans le champ de saisie. Imaginez que nous devons rediriger un flux de trafic du lien 123.10.10.10 - 123.30.30.30 vers un autre lien.
Cliquez avec le bouton droit sur le lien coloré et définissez 12. Nous obtenons un nouveau flux de trafic avec le nouveau coût OSPF.
Lorsque vous effectuez des changements de configuration (ajout d'un nouveau réseau, redistribution d'un autre protocole vers OSPF ou modification des filtres dans les route-maps existants), il est fortement recommandé de vérifier que les résultats de votre action vous donnent les changements attendus dans le réseau OSPF. Pour ce faire, chargez votre réseau avant vos modifications puis juste après, et comparez-les. Ce qui sera affiché :
Dans ce mode, il est possible de simuler l'arrêt d'un lien ou d'un routeur. La topologie sera repeinte avec le flux de trafic modifié attendu, en évitant le lien ou le routeur défaillant.
Chargez un graphe si ce n'est pas encore fait et appuyez sur NetworkReactionOnFailure.
Comme vous pouvez le constater, le taux de diminution du trafic du nœud 123.30.30.30 vers 123.123.30.30 et 123.123.31.31 diffère de la direction opposée [de 123.123.30.30 à 123.30.30.30] d'environ 2 fois. Cela se produit en raison du chemin de trafic asymétrique.
Nous pouvons également voir le taux d'augmentation attendu du lien coloré en bleu.
Topolograph construit une topologie basée sur l'adjacence OSPF et la connectivité physique est masquée. Mais dans certains cas, on peut supposer que les voisins partagent le même média, et dans d'autres cas non. Par exemple, si des voisins ont un DR commun, on suppose qu'ils sont connectés via un média physique partagé, et lors de l'émulation d'une défaillance de lien entre de tels voisins, tous les liens sont émulés comme tombés.
Marquer tous les liens médias partagés (qui ont un DR commun) comme activés
Si les voisins n'ont pas de DR ou en ont un, mais ne sont que deux voisins sur le lien, lors de l'émulation d'une défaillance de lien, seul le lien unique entre ces deux voisins particuliers est supprimé.
Marquer tous les liens médias partagés (qui ont un DR commun) comme désactivés
Cliquez avec le bouton droit sur un nœud et choisissez `arrêter ce nœud`. L'algorithme exclut ce nœud.
La réaction du réseau à la panne du nœud 123.123.101.101.
Sous l'onglet NetworkReactionOnFailure il est possible de voir la réaction du réseau à une modification du coût OSPF à la volée. Définissez le nouveau coût OSPF dans le menu du lien cliqué avec le bouton droit.
LSDB OSPF/IS-IS <-> YAML est désormais interchangeable dans les deux sens, ce qui permet de concevoir un domaine IGP de zéro ou à partir d'un LSDB chargé, d'ajouter de nouveaux liens entre les nœuds ou de modifier le coût IGP, puis de vérifier la réaction du réseau basée sur nos modifications.
Construire un graphe avec des nœuds et des liens définis.
le nom du nœud est obligatoire. Doit être au format d'adresse IP. Pour le changer en une autre valeur, utilisez label
Les tags de nœud sont optionnels. Toute paire clé (type chaîne) : valeur (chaîne, entier, flottant, dictionnaire, liste).
Il y a un graphe avec 6 nœuds. Sélectionnez tous les nœuds primaires (ha_role: primary) dans le premier DC (dc1)
src, dst est obligatoire.
cost est optionnel. La valeur par défaut est 1. Équivalent au coût OSPF/IS-IS.
directed est optionnel. La valeur par défaut est false.
Les tags de lien sont optionnels. Toute paire clé (type chaîne) : valeur (chaîne, entier, flottant, dictionnaire, liste).
Sélectionner tous les liens via verizon ISP entre 10.10.10.2 et 10.10.10.4
Ajoutons un nouveau lien avec cost 1 entre R3 (10.10.10.3) et R4 (10.10.10.4) et voyons comment le réseau réagit.
Évidemment, nous observons une augmentation du trafic sur le lien direct R3<->R4 et une diminution du trafic vers R2 (10.10.10.2) et R5 (10.10.10.5).
Dans ce mode, il est possible d'exécuter des algorithmes pour vérifier votre réseau OSPF.
Afficher tous les liens unidirectionnels (le nombre de liens IN et OUT entre deux voisins n'est pas égal)
Le lien est marqué en rouge en raison des métriques OSPF de coût 1 et coût 10
Afficher tous les chemins asymétriques depuis différents points de vue.
Nous obtenons une liste de nœuds ayant des chemins asymétriques. En les vérifiant, nous pouvons voir la différence entre les chemins entrants et sortants.
Nous supposons que si nous avons plusieurs liens liés à l'ECMP et que le lien principal de l'ECMP tombe, le chemin de secours devrait passer par le deuxième lien de l'ECMP.
Rapport réussi
Si le chemin de secours ne passe pas par l'ECMP et choisit un chemin complètement différent, le rapport sera traité comme échoué.
Rapport échoué
Ce rapport vérifie que si deux sites sont directement connectés, les chemins de secours ne doivent passer que entre ces deux sites et non via un site tiers en transit. Avant d'exécuter ce rapport, il est nécessaire de créer des groupes (noms de sites/emplacements) et d'assigner les équipements aux groupes. Par exemple, il y a deux sites en France : le site principal (EU_FRA) et le site distant (EU_FRA1). Le même schéma s'applique aux bureaux en Italie. Les bureaux principaux en France et en Italie sont connectés entre eux et disposent d'un lien principal (coût OSPF 10) et d'un lien de secours (coût OSPF 20).
Les bureaux distants ont un lien principal (coût OSPF 1) vers leurs bureaux principaux et un lien de secours (coût OSPF 10) vers le bureau étranger.

Rapport échoué
Sous l'onglet Analytics il est possible de voir combien de sous-réseaux terminés sont sécurisés en terminant le même sous-réseau sur différents équipements.
Cliquez sur un nœud pour savoir quels réseaux sont sécurisés et lesquels ne le sont pas.
Comme nous pouvons le constater, seul le loopback de l'équipement lui-même n'est pas sécurisé - c'est normal.
"Analytics/Réseaux terminés dupliqués. Le problème avec MPLS étant affecté par les duplications IP dans le réseau provient du fait que les étiquettes sont générées sur la base des blocs IP, qui peuvent être dupliqués. En conséquence, le même bloc IP peut être associé à différentes étiquettes. Cela conduit à une situation où le même bloc, avec différentes étiquettes, est propagé à d'autres routeurs, y compris celui avec l'IP dupliquée. Cela devient problématique lors de la mise en œuvre du MPLS Traffic Engineering (MPLS-TE) ou du Resource Reservation Protocol Traffic Engineering (RSVP-TE), car cela peut dégrader les performances et entraîner des bogues de routage liés au MPLS-TE, entre autres problèmes. Par conséquent, le problème de duplication de blocs sur les liens est critique dans les environnements MPLS, principalement en raison de la génération d'étiquettes dupliquées pour le même bloc. Dans les routeurs, cela entraîne de la confusion lors du recalcul du chemin pour TE ou RSVP-TE."
| Réseau | Nombre de nœuds terminaux | Noms de nœuds |
|---|---|---|
| 10.0.0.0/24 | 4 | [172.16.1.2, 172.26.1.2], [172.30.2.1, 178.20.3.1] |
Le réseau 10.0.0.0/24 est terminé sur quatre nœuds : 172.16.1.2, 172.26.1.2 et 172.30.2.1, 178.20.3.1 sont directement connectés, mais pas entre eux.
Vous êtes libre de choisir votre outil NetDevOps préféré comme Ansible, netmiko, Nornir, SDK Topolograph, etc., et de charger votre graphe réseau OSPF dans Topolograph via une requête POST. Une fois le graphe chargé, vous obtenez la différence avec les graphes précédemment chargés, spécifiquement :
Il est nécessaire de créer un compte avec email/mot de passe sur la page de connexion/inscription ainsi que d'ajouter votre IP/réseau source à la liste des réseaux sources autorisés sous l'onglet API.
Enregistrez la sortie des commandes décrivant les LSA1, LSA2, LSA5 OSPF et sauvegardez-la dans le fichier unique - 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())
En utilisant Python, nous lisons le contenu du fichier et l'envoyons (ou plutôt le POSTons) à Topolograph.
La sortie renvoie :
>>> 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'}
Différence visuelle entre les états 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'}
La topologie est construite sur la base des LSA1, LSA2, qui sont uniquement basées sur les zones. Si un réseau a plusieurs zones, il est nécessaire d'enregistrer la sortie LSDB de plusieurs équipements et de les sauvegarder dans des fichiers séparés en utilisant le format suivant Nom du fournisseur_nom du protocole.txt
Par exemple : il y a deux LSDB Cisco_ospf.txt, Juniper_ospf.txt
Les LSDB sont enregistrés dans le dossier lsdb_samples , puis encapsulés dans le dictionnaire d'attributs LSDB
{'lsdb_output': '...lsdb output...', 'vendor_device': 'Cisco, Juniper...', 'igp_protocol': 'ospf|isis'}
L'exemple complet :
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())
La sortie renvoie :
Plusieurs instances de routage OSPF peuvent exister sur un seul équipement dans plusieurs VRF. Cela entraîne la duplication des nœuds sur le graphe de visualisation. L'onglet VRF permet de pointer plusieurs instances OSPF vers une seule et d'éviter la duplication des nœuds sur un graphe.
Il y a trois VRF et trois instances OSPF sur un routeur. Pour éviter la duplication des nœuds, créez des VRF (ou importez-les via CSV), associez le nœud au VRF et pointez les instances dupliquées vers le RID OSPF maître.