Note de révision EIGRP

Hello la compagnie,

J’ai décidé depuis peu, de partager mes notes, mes labs, tips et autres trucs que j’utilise pour préparer l’examen CCNP ROUTE. Dans cet article (qui est le premier du site), je ne savais pas trop par ou commencer. J’ai tout simplement choisi d’écrire sur ce que je fais actuellement.

Dans l’organisation de mes révisions, j’ai séparé les “gros sujets” des “petits sujets“. J’ai déjà révisé la partie EIGRP il y a quelques mois déjà, mais on a tendance à oublier ce qu’on ne pratique pas, donc j’ai eu envie de refaire un lab pour me rafraichir la mémoire sur les topics requis pour l’examen.

Avant chaque lab sur un sujet précis (OSPF, EIGRP, BGP, etc…), je prépare une note avec une liste de choses à tester que je rempli au fur et à mesure. Voici celle que j’ai préparé correspondant à l’EIGRP :

Analyse des paquets EIGRP

  • Observer les trames EIGRP. Le protocole, type de trames (unicast/multicast)
    • Protocol 88 (RTP)
    • Hello : multicast
      • Contient le hold time. C’est le temps qu’il attends avant de considérer son voisin down.
      • Contient les différentes valeurs des K
    • Ack : unicast, envoyé sous forme de paquet hello
    • Update : unicast / multicast
    • Query : multicast
    • Reply : unicast
  • => Autre observation :

Hello & Timers

  • Observer l’échange de paquets hello
    • via debug
    • via wireshark
  • Observer le hold time dans les paquets (hello ?)
    • via debug
    • via wireshark
  • Observer les valeurs de hello & hold time par défaut sur le routeur
    • Pour une interface Ethernet
    • Pour une interface Série
      • 60/180 sur une interface series avec encapsulation frame relay et BW 1544. Passe en 5/15 quand on augmente le BW
  • Modifier les timers et voir comment le routeur se comporte
    • Hello
    • Hold time
  • Faire des tests pour voir quand il dépasse le hold time
  • => Autre observation :

Router ID

  • Observer le router ID
    • Dans la table topologique
    • Via un sh ip protocols
    • Via wireshark
  • Vérifier qu’avec le même router-id, les cpe peuvent quand même devenir neighbor
  • Vérifier que les routes (internes & externes) annoncées depuis un neighbor ayant le même router-id ne sont pas acceptées
    • Ils s’échangent les routes ?
  • Vérifier que la relation de voisinage saute(quand on change le router-id
  • Observer dans la table topologique, le router-id pour les routes interne & externes (originating router)
  • => Autre observation :

Update

  • Observer les triggered updates via wireshark
    • Quand le routeur annonce un nouveau réseau
    • Quand une métrique change
  • Vérifier que la relation de voisinage tombe si le routeur ne reçoit pas d’ack après la 16ème retransmission (bloquer les ack) :
    • (mais le routeur continue à essayer de retransmettre au delà de 16 retransmission et le neighbor ne tombe pas)
    • => Autre observation :

Feasible distance / Reported distance

  • Observer les routes dans la table topologique
    • Observer les Feasible Distance & Reported Distances
    • Vérifier les Successor / Feasible Successor
    • Voir celles qui valident la “feasibility condition”
      • sh ip eigrp topo
    • Voir celles qui ne valident pas la “feasibility condition”
    • sh ip eigrp topo all-links
  • Modifier les métriques pour les faire passer ou non en feasible successor : OK
  • After forming an EIGRP neighbor relationship, neighbors exchange topology tables. Only the best routes (successor routes) are advertised to the neighbors. : à vérifier
  • faire du partage de charge
    • A coût égal
    • A coût non égal (variance)
  • => Autre observation :

Metric manipulation

  • Faire des calcules de métrique de route reçues
  • Modifier les valeurs de BW & DLY pour influencer la métrique de routes reçus/envoyés et observer la nouvelle métrique
  • Modifier la valeur de métrique envoyée/reçue via une offset-list avec une ACL standard
  • Modifier la valeur de métrique envoyée/reçue via une offset-list avec une ACL étendue : KO (ne fonctionne qu’avec les ACLs standard (nommées)
  • Observer (via wireshark) les valeurs des K reçues/envoyées après la mise en place d’offset list
  • Vérifier que c’est le delay qui est modifié quand on joue sur une offset-list
  • Regarder la valeur des FD/RD avec les offset list in/out
    • OK (Le FD du successor conserve l’ancienne valeur sur la première ligne tant que le voisinage n’est pas tombé mais il se sert de la nouvelle valeur pour le calcul de la métrique, elle est précisée la ligne en dessous)
    • Offset in : This doesn’t affect the value of the RD of what neighbors sends. But it modify the FD of the routes received. In the topology table, the previous FD value remains (value before offset was added). = a tester
  • => Autre observation :

Filtering

  • Faire du filtrage de routes reçues/envoyées :
    • Via Distribute-list, sans préciser d’interface
      • Avec ACLs
      • Avec Prefix-List
      • Avec Route-Map
    • Via Distribute-list, en précisant une interface

Queries

  • Quand le routeur envoie des queries exactement ?
  • Est ce qu’un routeur envoie un query si il a quand même un FS ? (non)
  • Observer l’envoie des queries quand le Feasible Successor tombe
  • Voir les ACK et reply quand il existe une route
  • Voir les ACK et reply quand il n’en existe pas
  • => Autre observation :

Stub

  • Configurer un routeur en stub
  • Vérifier les routes apprises côté stub
  • Vérifier les routes envoyées par le stub
  • Modifier les routes annoncées par le stub (connected & summary)
  • EIGRP router configured as stubs do not forward EIGRP learned routes to other neighbors. Configuring a router as a stub does not change or limit the information that it receives from its neighbors, but rather limits what information it shares with its neighbors. = a tester
  • Non stub routers will not send query message to stub routers : Vérifier que les queries ne sont pas envoyées au stub = a tester
  • => Autre observation :

Summarization

  • Envoyer des summary de route
  • Vérifier la présence dans la table de routage de la route pointant vers Null0 pour le summary configuré
  • Vérifier que le routeur envoyant un summary ne reçoive pas de queries mais que les queries sont bien envoyés aux autres neighbors
    • Quand on supprime un subnet qui est inclus dans le summary
    • Autre réseaux ne provenant pas du CPE
  • => Autre observation :

EIGRP Default route

  • Annoncer une route par défaut
    • Via redistribution d’une route statique : OK (vue comme route externe, exterior flag is set)
    • Via la commande ip default network command : OK (vue comme route interne, exterior flag is set. Par contre, il faut que le réseau soit un classful)
    • Via un summary avec la commande ip eigrp summary address : OK (vue comme route interne,)
      • -When a summary with default route is configured, it only sends a default route (if there is no other summary configured) : OK
    • Via une redistribution d’un IGP ?
  • => Autre observation :

EIGRP for IPv6

  • Configurer EIGRP pour IPv6
  • Configurer le router ID et voir qu’on ne peut pas démarrer le process si le routeur n’en a pas
  • Observer les addresses link local utilisés pour les neighbors/next-hop
  • Valider qu’on peut monter une relation de voisinage eigrp en ipv6 en étant dans 2 sous réseaux distants : EIGRP for ipv6 does not require neighbors to be in the same ipv6 subnet to become neighbors  : OK (car ils utilisent les addresses link local)
  • EIGRP for IPv6 does not need to be enabled on the interface. All IPv6-enabled interfaces are automatically included in the EIGRP for IPv6 process. = a tester
  • => Autre observation :

EIGRP named configuration

  • Faire des conf EIGRP en utilisant le named mode
  • Comprendre ce qui se configure dans les différents menus
    • address family :
    • address family int :
    • address family topo :
  • => Autre observation :

Authentication

  • Configurer une key chain
  • Vérifier les lifetimes des keys si elles sont spécifiées ou non
  • Mettre en place de l’authentification MD5 entre 2 neighbors ipv4
    • Checker le hash en clair dans la capture wireshark
    • Vérifier si les key ID et key string doivent matcher (debug eigrp packet, wireshark)
    • Configurer des clés avec différents périodes d’activations (qui se chevauchent) et voir que le changement de clé se fait sans problème
  • Mettre en place de l’authentification MD5 entre 2 neighbors ipv6
  • Mettre en place de l’authentification SHA1 entre 2 neighbors (named mode)
  • => Autre observation :
 

Frame Relay => Ne sera pas testé en LAB, hors programme CCNP R&S.

J’espère que çà pourra vous être utile 🙂

One Reply to “Note de révision EIGRP”

Leave a Reply

Your email address will not be published. Required fields are marked *