Fix wording in IP Fabric documentation
This commit is contained in:
@@ -40,7 +40,7 @@ C'est ce modèle de snapshots qui rend possibles plusieurs des cas d'usage ci-de
|
||||
|
||||
C'est le cas d'usage qui a tout déclenché pour moi, et celui référencé directement dans la série de blog. IP Fabric construit un diagramme de topologie et un ensemble de tables relationnelles (équipements, interfaces, voisins, VLANs, VRFs) à partir de la discovery en direct, pas depuis un tableur maintenu à la main ou un schéma Visio que personne n'a pensé à mettre à jour.
|
||||
|
||||
Sur mon lab EVPN/VXLAN, ça veut dire que j'ai une réponse toujours à jour à la question « qu'est-ce qui est connecté à quoi », sans avoir à me fier à ma mémoire ou à un schéma périmé. C'est la couche qu'un agent IA devrait interroger en premier, avant tout le reste, s'il doit raisonner correctement sur le réseau — c'est tout l'enjeu du problème de « l'agent aveugle » évoqué dans la série de blog : un agent qui travaille sur une topologie obsolète se trompe avec assurance, il n'est pas prudemment incertain.
|
||||
Sur mon lab EVPN/VXLAN, ça veut dire que j'ai une réponse toujours à jour à la question « qu'est-ce qui est connecté à quoi », sans avoir à me fier à ma mémoire ou à un schéma périmé. C'est la couche qu'un agent IA devrait interroger en premier, avant tout le reste, s'il doit raisonner correctement sur le réseau — c'est tout l'enjeu du problème de « l'agent aveugle » évoqué dans la série de blog : un agent qui travaille sur une topologie obsolète répond avec assurance, même quand il se trompe.
|
||||
|
||||

|
||||
|
||||
@@ -48,7 +48,7 @@ Sur mon lab EVPN/VXLAN, ça veut dire que j'ai une réponse toujours à jour à
|
||||
|
||||
Les intent checks sont des règles qu'on définit une seule fois, du genre « pas de VLAN inutilisé », « la racine STP doit être sur les switches core », « chaque port d'accès doit avoir BPDU guard activé » — et IP Fabric les évalue automatiquement sur chaque nouveau snapshot. Les échecs remontent sous forme de vérifications colorées, avec possibilité de descendre jusqu'à l'équipement et l'interface précise qui enfreint la règle.
|
||||
|
||||
C'est là qu'IP Fabric bascule du « descriptif » (ce qui existe) au « normatif » (ce qui existe est-il correct). Ça rejoint naturellement le principe de standardisation que je répète souvent dans la série de blog : les intent checks permettent d'imposer la cohérence de nommage et de configuration automatiquement, plutôt que de compter sur un humain pour repérer une dérive.
|
||||
Ici, IP Fabric bascule du « descriptif » (ce qui existe) au « normatif » (ce qui existe est-il correct). Ça rejoint naturellement le principe de standardisation que je répète souvent dans la série de blog : les intent checks permettent d'imposer la cohérence de nommage et de configuration automatiquement, plutôt que de compter sur un humain pour repérer une dérive.
|
||||
|
||||

|
||||
|
||||
@@ -64,7 +64,7 @@ Avec une source, une destination et, en option, un protocole/port, IP Fabric sim
|
||||
|
||||
Comme chaque exécution de discovery est conservée sous forme de snapshot, IP Fabric peut comparer directement deux d'entre eux (un avant une fenêtre de changement, un après, par exemple) et faire ressortir précisément ce qui diffère : équipements ajoutés ou retirés, changements de VLAN, écarts dans les tables de routage, changements d'état d'interface.
|
||||
|
||||
C'est la réponse concrète à « qu'est-ce qui a vraiment changé », d'ordinaire la question la plus difficile à répondre après un incident. Plutôt que de reconstituer une chronologie de mémoire ou à partir de tickets de changement épars, le diff est déjà là.
|
||||
Ça donne une réponse concrète à « qu'est-ce qui a vraiment changé », d'ordinaire la question la plus difficile à répondre après un incident. Plutôt que de reconstituer une chronologie de mémoire ou à partir de tickets de changement épars, le diff est déjà là.
|
||||
|
||||

|
||||
|
||||
|
||||
Reference in New Issue
Block a user