Differences

This shows you the differences between two versions of the page.

--- informatique:cisco:ospf [2009/10/29 09:05] – Liens pteu
+++ informatique:cisco:ospf [2011/08/11 13:57] – Liens : OSPF Neighbor Problems Explained pteu
@@ Line 32: / Line 32: @@
   * **PDU** Protocol Data Units ; les LSAs sont des PDUs
   * **LSA** Link-State Advertisement qui sont envoyer à tous les routeurs de l'aire
-  * **LSU** Link-State Update
+  * **LSR** Link-State Request : si les LSA sont plus récents que la base de topologie, le routeur demande les informations manquantes
+  * **LSU** Link-State Update : envoyé sur demande (LSR) par le DR aux autre routeurs du segment
   * **LSDB** Link-State DataBase qui sont identiques sur tous les routeurs de l'aire
   * **DR** Designated Router
@@ Line 67: / Line 68: @@
   * LSU
   * LSR
-  * DBD
+  * DBD : DataBase Descriptor
   * LSAck
-  * hello (**Hello interval** sur NBMA = 30s, sur interface rapides comme l'Ethernet c'est 10s ; le **dead time** est égal à <del>3</del> 4 fois le **Hello interval**)
+  * hello (**Hello interval** sur NBMA = 30s, sur interface rapides comme l'Ethernet c'est 10s ; le **dead time** est égal à <del>3</del> 4 fois le **Hello interval** donc = 40s sur Ethernet par ex.)
 ====Les différents types de LSAs====
@@ Line 85: / Line 86: @@
   * LSA type 7 (NSSA) : générés par les ASBR d'une aire NSSA, ils sont convertis par l'ABR de l'aire en LSA de type 5.
   * LSA type 9 à 11 (opaque)
+=====Les états OSPF=====
+^DOWN     | premier état OSPF ; le routeur émet des hello mais n'en reçoit pas |
+^ATTEMPT  | uniquement sur NBMA ; envoi de hello unicast a son voisin dont le dead time a expiré |
+^INIT     | le routeur reçoit un hello d'un voisin, mais il ne contient pas (encore) son router-id |
+^2WAY     | communication bidirectionnelle établie = les hellos reçus contiennent son router-id ; état normal d'un DROTHER avec un autre DROTHER puisqu'un routeur ne peut être FULL qu'avec le DR et le BDR) |
+^EXSTART  | état d'échange de //link state information// avec le DR/BDR |
+^EXCHANGE | état d'échange de DBD/LSA avec le DR/BDR |
+^LOADING  | suite à l'état EXCHANGE, état de demande au voisin une information pour mise à jour (link-stat request) |
+^FULL     | état normal symbolisant une adjacence complète = la base de données des voisins sont synchronisés |
+En résumé : seul l'état FULL dénote bon fonctionnement __sauf__ sur un réseau de type broadcast (comme l'Ethernet) dans le cas de l'adjacence de 2 routeurs DROTHER qui restent à l'état 2WAY.
+Voici l'algorithme d'état OSPF :
+{{:informatique:cisco:ospf_states.gif|}}
@@ Line 90: / Line 109: @@
 **Non-Broadcast Multi-Access** est un type de réseau qui n'accepte pas le broadcast (multicast) et qui est en mode multi-access (!= point à point). C'est le cas par défaut de Frame Relay.
-  * broadcast (ex : Ethernet) : permet la découverte automatique des voisins (par paquets hello) et nécessite l'élection d'un BR/BDR
+  * **broadcast** (ex : Ethernet) : permet la découverte automatique des voisins (par paquets hello) et nécessite l'élection d'un BR/BDR
-  * non-boadcast (ex : FR, ATM, X.25) : mode par défaut pour le FR ; ne permet pas la découverte automatique des voisins ; nécessite l'élection d'un BR/BDR
+  * **non-broadcast** (ex : FR, ATM, X.25) : mode par défaut pour le FR ; ne permet pas la découverte automatique des voisins ; nécessite l'élection d'un BR/BDR
-  * point-to-multipoint : peu conseillé, plusieurs voisins par réseaux, détection automatique des voisins, ne nécessite pas de DR/BDR
+  * **point-to-multipoint** : peu conseillé, plusieurs voisins par réseaux, détection automatique des voisins, ne nécessite pas de DR/BDR
-  * point-to-point (ex : interfaces série) : un voisin par interface, ne nécessite pas de DR/BDR
+  * **point-to-point** (ex : interfaces série) : un voisin par interface, ne nécessite pas de DR/BDR
+=====Timers par défaut=====
+brouillon / à valider
+Tableau récapitulatifs des timers par défaut :
+|                          ^ Protocole ^ Hello timer (s) ^ Dead timer (s) ^
+^ NBMA                     | FR        | 30              | 120            |
+^ Multipoint Broadcast     |           | 30              | 120            |
+^ Multipoint Non-Broadcast |           | 30              | 120            |
+^ Broadcast                | Ethernet  | 10              | 40             |
+^ Point-to-point           | Série     | 10              | 40             |
 =====Mise en place basique=====
@@ Line 236: / Line 268: @@
 Vérifs avec ''sh ip ospf virtual-links''.
+====Sub-second hello packet====
+Sur les liens de bonne qualité (donc souvent du LAN Ethernet) il peut être intéressant d'augmenter la réactivité de l'OSPF pour baisser les temps de convergence du réseau en cas de perte d'un routeur. On peut le faire en diminuant les timers d'envoi des paquets hello ainsi que le dead-time interval. Quand on descend en-dessous de la seconde, on appelle cela **Fast Hello Packets** ou **subsecond hello packets**. Cela doit être manipuler avec précaution sous peine d'avoir les adjacences OSPF de ses routeurs qui bagottent sans cesse.
+Cela se configure facilement, en spécifiant sur l'interface de routage la commande :
+<code bash>
+interface Gi0/0
+ ip ospf dead-interval minimal hello-multiplier 5
+</code>
+Ici on configure le //dead-interval// au minimum possible (càd 1 seconde) et on indique qu'on envoie 5 hellos dans cet intervalle de temps, ce qui fait un toutes les 200 ms. Comme un voisin est déclaré dead après la perte de 4 hellos packet, on descend bien en dessous de la seconde pour converger.
+Lien cisco : [[http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fasthelo.html|OSPF Support for Fast Hellos]]
@@ Line 273: / Line 318: @@
 =====Liens=====
- * [[http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml#t32|OSPF Design Guide]] sur cisco.com
+  * [[http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml#t32|OSPF Design Guide]] sur cisco.com
+  * [[http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cospf.html|Configuring OSPF]] sur cisco.com
+  * [[http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0e.shtml|OSPF neighbor states]]
+  * [[http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801ec9f0.shtml|How OSPF Injects a Default Route into a Normal Area]]
+  * [[http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094050.shtml|OSPF Neighbor Problems Explained]]