Chapitre 1
Introduction au protocole RIP
Chapitre 2
Principe de fonctionnement
RIPv1 vs RIPv2 vs RIPng
RIPv1 vs RIPv2 en pratique
Architecture de base
Mise à jour
Chapitre 3
Réaction du protocole RIP en cas de panne
Exemple de panne RIP
Réaction du protocole RIP en cas de panne
Chapitre 4
Le split-horizon
Dans un monde sans Split Horizon
Dans un monde avec Split Horizon
Configuration du split-horizon
CHAPITRE 5
Le route poisoning
Présentation
Mise en situation
Configuration
Conclusion
Chapitre 6
Configuration du protocole RIP
Configuration du RIPv2
Configuration du RIPng (IPv6)
Troubleshooting
Merci de votre attention
Sur le même thème
Merci de votre soutien et de votre fidélité ! Ce site existe grâce à vous et je ne vous remercierais jamais assez !
Comments (3)
Bonjour j’aime beaucoup la présentation de ton travail.félicitations.
Juste une petite question, pourquoi dans l’exemple 2 du protocole RIP, les adresses ne sont pas avec un “/8” car elles font partie de la classe A?.
Cordialement
Bonjour Marzaro.
Merci beaucoup pour ton commentaire.
Effectivement, je n’avais pas assez développé l’exemple 2 alors que c’est cet exemple qui marque bien la différence entre le RIPv1 et le RIPv2.
J’ai mis à jours l’exemple 2.
A toi de me dire si cet exemple est plus clair et si j’ai répondu à ta question.
Hésite pas à me faire part de tes commentaires sur d’autres Articles.
Ca m’aide énormément !!!
Bonne journée à toi !!
Félicitations pour les gros efforts ! C’est une belle présentation.
Pour avoir essayé à plusieurs reprises de percer certains mystères de RIP, je suggérerai d’améliorer certains points.
1 – Pour expliquer les avantages de RIPv2 par rapport à RIPv1, Il serait très pertinent de détailler un peu plus les aspects suivants :
– auto-summarization / manual summarization
– Mise à jour automatique en cas de modification de topologie (v2)
2 – Pour bien expliquer les Timers RIP, ça serait cool de faire un exemple. Merci, si possible, de préciser si ces timers ont la même signification selon qu’on est dans v1 ou v2.
3 – Dans la section “En cas de Panne”, je ne suis pas sûr que la dernière étape est valide. D’après la règle de SPLIT HORIZON, R3 ne peut pas informer 192.168.3.0 par la même interface par laquelle il l’a reçu. Pour montrer la problématique que tu as voulu expliquer, c’est généralement une architecture sous forme de “triangle” qu’il faut faire.