Blog de Florent Appointaire

Blog sur les technologies Microsoft (Windows Server, System Center, Azure, Windows Azure Pack/Azure Stack, etc;)
    • 29/3/2012

    [CCNP] Premier pas avec eBGP

    Dans ce tutoriel, nous allons voir comment configurer BGP, lui ajouter une authentification et ainsi pouvoir échanger les tables de routages. Nous utiliserons cette topologie :

    eBGP_start

    Cette topologie (disponible en version initiale ici) est composée de quatre routeurs, deux réseaux d'entreprise et deux réseaux d'ISPs avec un lien redondant entre le routeur de l'entreprise 1 et l'ISP 1.
    Dans notre cas, on souhaiterai que l'entreprise 1 puisse accéder à l'entreprise 2 et inversement.
    On va donc commencer par effectuer un ping entre les deux entreprises :

    R4#ping 192.168.10.2
    Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
    .....
    Success rate is 0 percent (0/5)

    Le ping no fonctionne pas, ce qui est normal car R4 ne connait pas la route pour aller vers le réseau de l'entreprise 1.

    Dans un premier temps, nous allons activer BGP sur chaque routeur avec l'AS correspondant :

    R1>en
    R1#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    R1(config)#router bgp 60001
    R1(config-router)#
    R2>en
    R2#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    R2(config)#router bgp 3
    R2(config-router)#
    R3>en
    R3#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    R3(config)#router bgp 10
    R3(config-router)#
    R4>en
    R4#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    R4(config)#router bgp 60002
    R4(config-router)#

    BGP est maintenant activé sur chaque routeur.
    Sur R1 et R2, nous allons activer et paramétrer une interface loopback. Nous allons faire ceci pour les liens redondant entre R1 et R2. En effet, on indiquera dans notre configuration que pour envoyer les paquets, l'adresse source sera l'adresse de loopback. Nous allons aussi créer les routes pour ces paquets.

    R1(config)#ip route 2.2.2.2 255.255.255.255 s0/0
    R1(config)#ip route 2.2.2.2 255.255.255.255 s0/2
    R1(config)#interface loopback 1
    R1(config-if)#ip address 1.1.1.1 255.255.255.255
    R1(config-if)#exit
    R1(config)#router bgp 60001
    R1(config-router)#neighbor 2.2.2.2 remote-as 3
    R1(config-router)#neighbor 2.2.2.2 update-source loopback 1
    R2(config)#ip route 1.1.1.1 255.255.255.255 s0/0
    R2(config)#ip route 1.1.1.1 255.255.255.255 s0/2
    R2(config)#interface loopback 2
    R2(config-if)#ip address 2.2.2.2 255.255.255.255
    R2(config-if)#exit
    R2(config)#router bgp 3
    R2(config-router)#neighbor 1.1.1.1 remote-as 60001
    R2(config-router)#neighbor 1.1.1.1 update-source loopback 2

    Ici, on dit à R1 que son voisin à l'adresse ip 2.2.2.2 et qu'il se trouve dans l'AS 3 et que tous les messages BGP envoyés auront comme adresse ip source l'adresse ip de l'interface loopback 1.
    Si l'on regarde notre table BGP, on peut remarquer qu'il n'y a rien, chose normal, nous n'avons pas configurer le multihop. Le multihop va correspondre à votre TTL. Elle est à 1 par défaut. Quand le routeur va recevoir le paquet sur son interface S0/0, il va soustraire 1 à la TTL. Donc la nouvelle TTL sera à 0. Pour résoudre ce problème, il suffit d'utiliser la commande ebgp-multihop 2 comme ça, le routeur va recevoir le paquet, soustraire 1, il nous restera donc TTL = 1. Le paquet ne sera donc pas supprimé et il sera transféré à l'interface loopback 1. On va également ajouter une authentification MD5 entre les deux routeurs :

    R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
    R1(config-router)#neighbor 2.2.2.2 password florent-appointaire.fr
    R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2
    R2(config-router)#neighbor 1.1.1.1 password florent-appointaire.fr

    On peut maintenant vérifier que la connexion est bien établie entre les deux routeurs :

    R1#show ip bgp
    BGP table version is 15, local router ID is 1.1.1.1
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale
    Origin codes: i - IGP, e - EGP, ? - incomplete
    
       Network          Next Hop            Metric LocPrf Weight Path
    *> 1.1.1.1/32       0.0.0.0                  0         32768 i
    r> 2.2.2.2/32       2.2.2.2                  0             0 3 i
    R1#show ip bgp summary
    BGP router identifier 1.1.1.1, local AS number 60001
    BGP table version is 15, main routing table version 15
    2 network entries using 202 bytes of memory
    2 path entries using 96 bytes of memory
    2 BGP path attribute entries using 112 bytes of memory
    1 BGP AS-PATH entries using 24 bytes of memory
    0 BGP route-map cache entries using 0 bytes of memory
    0 BGP filter-list cache entries using 0 bytes of memory
    BGP using 434 total bytes of memory
    BGP activity 7/5 prefixes, 7/5 paths, scan interval 60 secs
    
    Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
    2.2.2.2         4     3      11      12       15    0    0 00:06:42        1
    R1#show ip bgp neighbors
    BGP neighbor is 2.2.2.2,  remote AS 3, external link
      BGP version 4, remote router ID 2.2.2.2
      BGP state = Established, up for 00:00:13
      Last read 00:00:13, hold time is 180, keepalive interval is 60 seconds
      Neighbor capabilities:
        Route refresh: advertised and received(old & new)
        Address family IPv4 Unicast: advertised and received
      Message statistics:
        InQ depth is 0
        OutQ depth is 0
                             Sent       Rcvd
        Opens:                  2          2
        Notifications:          1          0
        Updates:                0          3
        Keepalives:            14         11
        Route Refresh:          0          0
        Total:                 21         16
      Default minimum time between advertisement runs is 30 seconds
    
     For address family: IPv4 Unicast
      BGP table version 18, neighbor version 18
      Index 1, Offset 0, Mask 0x2
      1 update-group member
                                     Sent       Rcvd
      Prefix activity:               ----       ----
        Prefixes Current:               1          1 (Consumes 48 bytes)
        Prefixes Total:                 2          1
        Implicit Withdraw:              1          0
        Explicit Withdraw:              0          0
        Used as bestpath:             n/a          1
        Used as multipath:            n/a          0
    
                                       Outbound    Inbound
      Local Policy Denied Prefixes:    --------    -------
        AS_PATH loop:                       n/a          1
        Total:                                0          1
      Number of NLRIs in the update sent: max 0, min 0
    
      Connections established 2; dropped 1
      Last reset 00:02:14, due to BGP Notification sent, hold time expired
      External BGP neighbor may be up to 2 hops away.
    
    Connection state is ESTAB, I/O status: 1, unread input bytes: 0
    Local host: 1.1.1.1, Local port: 179
    Foreign host: 2.2.2.2, Foreign port: 11009
    R1#show tcp brief
    TCB       Local Address           Foreign Address        (state)
    6501FDA4  1.1.1.1.179             2.2.2.2.11009          FINWAIT2

    On peut voir que les deux routeurs sont bien connectés entre eux pour échanger leurs table de routage et qu'une connexion TCP est existante entre les deux. Ils ne nous reste plus qu'à leur ajouter les routes et configurer les deux autres routeurs.

    R1(config)#router bgp 60001
    R1(config-router)#neighbor 98.120.1.2 remote-as 10
    R1(config-router)#network 98.120.1.0 mask 255.255.255.252
    R1(config-router)#network 192.168.10.0 mask 255.255.255.0
    R1(config-router)#network 92.190.39.4 mask 255.255.255.252
    R1(config-router)#network 92.190.39.8 mask 255.255.255.252
    R1(config-router)#network 1.1.1.1 mask 255.255.255.255
    R2(config)#router bgp 3
    R2(config-router)#neighbor 130.245.3.22 remote-as 10
    R2(config-router)#neighbor 92.190.39.18 remote-as 60002
    R2(config-router)#network 92.190.39.4 mask 255.255.255.252
    R2(config-router)#network 92.190.39.8 mask 255.255.255.252
    R2(config-router)#network 130.245.3.20 mask 255.255.255.252
    R2(config-router)#network 92.190.39.16 mask 255.255.255.252
    R2(config-router)#network 2.2.2.2 mask 255.255.255.255
    R3(config)#router bgp 10
    R3(config-router)#neighbor 98.120.1.1 remote-as 60001
    R3(config-router)#neighbor 130.245.3.21 remote-as 3
    R3(config-router)#network 98.120.1.0 mask 255.255.255.252
    R3(config-router)#network 130.245.3.20 mask 255.255.255.252
    R4(config)#router bgp 60002
    R4(config-router)#neighbor 92.190.39.17 remote-as 3
    R4(config-router)#network 192.168.20.0 mask 255.255.255.0
    R4(config-router)#network 92.190.39.16 mask 255.255.255.252
    R4#ping 192.168.10.1
    
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 16/46/84 ms

    Le ping est maintenant fonctionnel. Vous pouvez télécharger la version complète du projet ici.

    • 23/3/2012

    [CCNP] Découverte de BGP

    Aujourd'hui, j'ai découvert BGP (Border Gateway Protocol). Depuis le temps que l'on m'en parlait, j'ai enfin pu voir les bases de fonctionnement de ce protocole. BGP est un protocole de routage utilisé le plus souvent sur internet, entre les ISPs, les entreprises, etc... Il est actuellement à la version 4 (BGPv4). Il utilise comme OSPF, un AS (Autonomous System) pour échanger ses tables de routages avec ses voisins. C'est un path vector protocol, c'est à dire un protocole à vecteur de chemin, dont les valeurs seront fixées par un administrateur d'une AS.

    BGP n'est pas obligé d'être dans le même sous réseau qu'un autre routeur pour être voisin avec lui. Il doit cependant être dans le même AS. La connexion entre deux voisins s'effectuera via une session TCP sur le port 179.
    Il y a deux types de BGP :

    • eBGP qui signifie external BGP, va etre utiliser dans le cas d'un échange de routes entre 2 AS différents.
    • iBGP quant à lui signifie internal BGP et va être utiliser dans le cas d'un échange de route dans un même AS.

    Pour mieux comprendre le principe, nous allons utiliser le schéma suivant :

    Screen-Shot-2012-03-23-at-19.02.11

    Ici, nous avons 3 AS différents (1, 2, 3). Les routes seront échangées à travers les AS une fois les routeurs bien configurés. Par exemple, le routeur R4 va envoyer les informations BGP qu'il connait aux routeurs R1, R2, R5 et R6. Et c'est ici qu'interviennent les routes eBGP et iBGP.

    Screen-Shot-2012-03-23-at-19.04.05

    Voici le même schéma que tout à l'heure mais avec cette fois-ci les routes eBGP et iBGP.

    AS_Path PA (Paths Attributes) va prendre en compte le fait de ne pas avoir de boucle sur le réseau. En effet, si vous recevez un paquet avec le meme AS que vous, BGP va directement refuser le paquet. Prenons ici l'exemple précédent. Admettons que le routeur R4 envoie ses routes BGP au routeur R5 qui lui envoie ses routes BGP au routeur R2. R2 va envoyer ses routes BGP à R4, ce qui formerait une boucle. Avec le AS_Path, étant donné que R4 connait déjà l'AS 1 (normal, il en fait parti), il va refuser le paquet et R2 va transférer ses routes BGP à R1 comme si de rien n'était.

    En ce qui concerne les AS externes (que l'on retrouve sur l'internet), ils sont distribués par IANA (Internet Assigned Numbers Authority) pour ne pas avoir de boucle.

       Valeur de l'AS     Utilisation de l'AS
    0 Réservé
    1 à 64495 Utilisation public, assigné par l'IANA
    64496 à 65511 Réservé pour l'utilisation dans des documentations
    65512 à 65534 Utilisation privée
    65535 Réservé

    J'espère que ces explications vous aurons été utiles, si vous avez des questions, posez les en commentaires ou par email :)

    • 14/3/2012

    [CCNA] Sauvegarder les configurations de vos Switchs/Routeurs

    cisco1

    Durant un de mes stages, j'ai eu à implémenter une solution de sauvegarde des Switchs et Routeurs Cisco automatiquement.
    Pour mettre en place cette solution, vous aurez besoin :

    • d'un serveur tftp (Cisco Tftp serveur, tftp32...)
    • du logiciel WrNet 1.2 disponible ici : http://www.cnetfrance.fr/telecharger/wrnet-20042154s.htm
    • d'un poste depuis lequel nous exécuterons notre script automatiquement
    • d'une configuration spécifique sur chaque Switchs et Routeurs
    Nous allons maintenant pouvoir commencer. Dans un premier temps, nous allons commencer par créer un fichier texte dans le dossier WrNet que nous renommerons avec l'extension .bat. Ensuite, nous allons remplir ce fichier avec cette commande (vous aurez donc une ligne pour chaque switch ou routeur) :

     

    WRNET 192.168.1.1 public 192.168.1.2 SW1.txt

     

    Ici, nous aurons pour correspondance :

    • 192.168.1.1 est l’IP du Switch
    • public est le nom de la communauté SNMP
    • 192.168.1.2 est l’IP du serveur TFTP
    • SW1.txt  est le nom que prendra le fichier texte contenant la configuration
    Il nous faut maintenant configurer la communauté SNMP sur le switch SW1 :

     

    SW1(config)#snmp-server community public RW

     

    Votre script est maintenant prêt à être lancé. Lancez votre fichier .bat et la configuration va être téléchargée dans le dossier TFTP.
    Ici, nous utilisons SNMP v2 et non la version 3 car WrNet ne supporte pas la version 3. La grosse difference est que SNMP v2 ne chiffre pas vos paquets. Donc dans notre cas, nous allons créer une ACL permettant juste a notre serveur TFTP d'utiliser cette communauté SNMP.

     

    access-list 10 permit 192.168.1.2 0.0.0.255
    access-list 10 deny any

    Il faut donc modifier notre communauté SNMP pour qu'elle utilise l'ACL 1o :

    SW1(config)#snmp-server community public RW 10

    Voilà, après si vous souhaitez sauvegarder vos configurations tous les jours/semaines/mois, il vous suffit de créer une tâche plannifiée :)

    En espérant que ce petit tutoriel vous sera utile.

    • 13/3/2012

    [CCNP] Les différents types de LSA

    ospf-standardarea

    Toujours dans la continuité de ma préparation vers la CCNP Route, je vais vous faire une présentation de LSA.

    LSA, qu'est-ce que c'est?

    LSA signifie link-state advertisement. Il servira aux routeurs de l'envoie des différents packets OSPF (1.Hello, 2.Database Description, 3.Link State Request, 4.Link State Update, 5.Link State Acknowledgement). Par exemple, vous allez envoyer votre packet Hello pour établir une relation de voisinage avec les autres routeurs OSPF ou pour maintenir la connexion avec vos voisins. Les autres types de packets vont être utile pour mettre à jour et maintenir votre LSDB (Link-State Database).
    Il existe 11 types différents de LSAs. Ici je vous parlerai des 7 premiers types de LSA :

    LSA Type NumberLSA Type Name
    1 Router
    2 Network
    3 Network Summary
    4 ASBR Summary
    5 AS External
    6 Group Membership
    7 NSSA External

    LSA Type 1 (Router) :

    Le LSA type 1 est généré par tous les routeurs d'une area pour informer les autres routeurs de cette même area des liens qui sont directement connectés à lui. Ce sont les routes intra-area. Dans votre table de routage, la route sera précédée de la lettre O. Autorise sur toutes les aires OSPF.

    LSA Type 2 (Network) :

    Le LSA type 2 est généré par le DR (Designated Router) pour lister tous les routeurs adjacents dans une area. Il renseigne le champ LSID (link state identifier ) qui correspond à l'adresse IP RID dans un premier temps, si celle-ci est absente, il se basera sur l'interface loopback de votre routeur et si celle-ci est elle aussi absente, ce sera l'adresse IP la plus grande de l'interface de votre routeur. Autorisé sur toutes les aires OSPF.

    LSA Type 3 (Network Summary) :

    Le LSA type 3 est généré par un routeur ABR (Area Border Router, routeur qui fait la correspondance entre votre area 0 (backbone) et les autres areas) pour délivrer ses routes resumés par lui même. Le type 3 fonctionne sur toutes les aires OSPF sauf pour les aires totally stub et totally NSSA stub. Lorsqu'une route traverse un routeur ABR, la route est connue comme une route intra-area. Dans votre table de routage, la route sera précédée par O IA pour OSPF Inter-Area.

    LSA Type 4 (ASBR Summary) :

    Le LSA type 4 est généré par un routeur ASBR (Autonomous System Boundary Router, routeur connecté directement à votre ISP) et est injecté dans la backbone area par les routeurs ABR pour avertir de la présence de routeur ASBR dans cette area. Autorisé dans toutes les aires OSPF sauf pour les aires totally stub et totally NSSA stub, il décrit les routes aux ASBRs (résumé interarea des routes).

    LSA Type 5 (AS External) :

    Le LSA type 5 est généré par un routeur ABR qui va flooder toutes les aires pour indiquer qu'il connait une route externe (redistribuée d'un autre protocole par exemple). Il fonctionne pour tout le domaine OSPF sauf pour les aires stub, totally stub, NSSA, totally NSSA.

    LSA Type 6 (Group Membership) :

    Le LSA type 6 n'est pas supporté par les routeurs Cisco. Il est défini pour MOSPF.

    LSA Type 7 (NSSA External) :

    Le LSA type 7 est généré par un routeur ASBR pour remplacer le LSA de type 5 dans le cas où vous disposez d'une aire NSSA ou totally NSSA. Les routes seront donc connues comme NSSA externe de type 1 ou 2. Dans votre table de routage, vos routes seront précédées de O N1 et O N2.

    Merci à Julien pour la correction ;)

    • 12/3/2012

    [CCNP] Redistribution entre EIGRP et OSPF

    Aujourd'hui, nous allons voir comment redistribuer les routes entre EIGRP et OSPF.

    C'est plutôt facile et rapide. La redistribution vous servira dans le cas où 2 entreprises mergent leurs réseaux ou encore quand vous avez plusieurs protocoles de routages dans votre entreprise. Nous allons prendre cette topologie, disponible en version GNS ici. J'ai installé 7 routeurs 3745, les nuages sont des sous-réseaux (ils ne sont pas connectés, pour ça, j'ai configuré une interface loopback 0 sur chaque routeur).

    Screen-Shot-2012-03-12-at-22.22.21

    Une fois notre configuration de base terminée, il faut maintenant configurer la redistribution sur notre routeur R1.

    Pourquoi R1?

    R1 parce que c'est le seul routeur ici qui a au moins une interface physique connectée sur chaque protocole de routage.

    Sur R1, si je fais un show ip route, j'obtiens ceci :

    R1#show ip route
    
    Gateway of last resort is not set
    
         10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
    D       10.0.2.0/24 [90/2297856] via 10.0.0.6, 00:29:44, Serial0/1
    C       10.0.0.0/30 is directly connected, Serial0/0
    D       10.0.1.0/24 [90/2297856] via 10.0.0.2, 00:29:46, Serial0/0
    C       10.0.0.4/30 is directly connected, Serial0/1
    D       10.0.0.24/30 [90/2681856] via 10.0.0.6, 00:29:47, Serial0/1
                         [90/2681856] via 10.0.0.2, 00:29:47, Serial0/0
    C       10.0.0.16/30 is directly connected, Serial0/4
    C       10.0.0.20/30 is directly connected, Serial0/5
    O       10.0.0.32/30 [110/1626] via 10.0.0.22, 00:08:02, Serial0/5
                         [110/1626] via 10.0.0.18, 00:08:02, Serial0/4
    O       10.0.5.254/32 [110/1563] via 10.0.0.18, 00:08:02, Serial0/4
    O       10.0.6.254/32 [110/1563] via 10.0.0.22, 00:08:02, Serial0/5

    Notre table de routage est complète. Maintenant, si depuis R2, je veux atteindre le réseau 10.0.5.0/24 par exemple, je ne peux pas. Pourquoi? C'est simple, dans la table de routage de R2, nous n'avons aucune route connectée pour aller vers le sous réseau 10.0.5.0/24. Nous allons donc configurer R1 pour distribuer les routes de OSPF dans EIGRP. Pour ceci, il nous faut relever quelques valeurs comme la bandwidth (Kbps), le delay (micro secondes), la reliability (une valeur entre 1 et 255), la load (une valeur entre 1 et 255) et la MTU. Toutes ces informations peuvent être trouvée en faisant un show interfaces serial 0/5 :

    R1#show interfaces serial 0/5
    Serial0/5 is up, line protocol is up
      Hardware is GT96K Serial
      Internet address is 10.0.0.21/30
      MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
         reliability 255/255, txload 1/255, rxload 1/255
      Encapsulation HDLC, loopback not set
      Keepalive set (10 sec)
      Last input 00:00:03, output 00:00:02, output hang never
      Last clearing of "show interface" counters never
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
      Queueing strategy: weighted fair
      Output queue: 0/1000/64/0 (size/max total/threshold/drops)
         Conversations  0/1/256 (active/max active/max total)
         Reserved Conversations 0/0 (allocated/max allocated)
         Available Bandwidth 1158 kilobits/sec
      5 minute input rate 0 bits/sec, 0 packets/sec
      5 minute output rate 0 bits/sec, 0 packets/sec
         80 packets input, 6208 bytes, 0 no buffer
         Received 39 broadcasts, 0 runts, 0 giants, 0 throttles
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
         94 packets output, 8524 bytes, 0 underruns
         0 output errors, 0 collisions, 9 interface resets
         0 output buffer failures, 0 output buffers swapped out
         0 carrier transitions
         DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

    Maintenant, pour redistribuer les routes OSPF vers EIGRP avec ces valeurs, nous avons 2 solutions. Soit avec la commande default-metric bandwith delay reliability load MTU avec les valeurs à la suite, soit avec la commande redistribute ospf process-id metric bandwith delay reliability load MTU. Avec la première solution, la commande sera appliquée sur toute l'AS eigrp 100, et donc vous aurez juste à écrire redistribute ospf process-id sans les valeurs. Avec la deuxième solution, il vous faudra écrire les valeurs pour chaque process-id. Nous allons utiliser la deuxième solution étant donné que nous avons ici qu'un seul process-id qui est 1 :

    R1(config)#router eigrp 100
    R1(config-router)#redistribute ospf 1 metric 1544 2000 255 1 1500

    On vérifie que R2 a bien appris les routes de OSPF via EIGRP :

    R2#show ip route
    
    Gateway of last resort is not set
    
         10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
    D       10.0.2.0/24 [90/2297856] via 10.0.0.26, 00:18:18, Serial0/1
    C       10.0.0.0/30 is directly connected, Serial0/0
    C       10.0.1.0/24 is directly connected, Loopback0
    D       10.0.0.4/30 [90/2681856] via 10.0.0.26, 00:18:18, Serial0/1
                        [90/2681856] via 10.0.0.1, 00:18:18, Serial0/0
    C       10.0.0.24/30 is directly connected, Serial0/1
    D EX    10.0.0.16/30 [170/2681856] via 10.0.0.1, 00:00:35, Serial0/0
    D EX    10.0.0.20/30 [170/2681856] via 10.0.0.1, 00:00:37, Serial0/0
    D EX    10.0.0.32/30 [170/2681856] via 10.0.0.1, 00:00:37, Serial0/0
    D EX    10.0.5.254/32 [170/2681856] via 10.0.0.1, 00:00:37, Serial0/0
    D EX    10.0.6.254/32 [170/2681856] via 10.0.0.1, 00:00:37, Serial0/0
    R2#ping 10.0.5.254
    
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.0.5.254, timeout is 2 seconds:
    .....
    Success rate is 0 percent (0/5)

    R2 a bien appris, via EIGRP les nouvelles routes. Nous pouvons remarquer que la distance administrative est de 170, ce qui est normal, c'est l'AD de EIGRP pour les routes externes, symbolisées par EX juste après D. Nous pouvons aussi voir que le ping ne fonctionne pas, c'est normal, 10.0.5.254 ne sait pas où renvoyer le paquet provenant de R2. Nous allons donc faire la redistribution de EIGRP pour OSPF :

    R1(config)#router ospf 1
    R1(config-router)#redistribute eigrp 100 subnets

    Ici on précise subnets car sinon, OSPF recevra de EIGRP que les sous-réseaux classful.

    Un ping depuis R2 vers 10.0.5.254 fonctionne maintenant :

    R2#ping 10.0.5.254
    
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.0.5.254, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 8/43/104 ms

    En espérant que ces explications vous seront utiles :) Le projet complet est disponible ici.

    • 4/3/2012

    [CCNP] Authentification OSPF

    Après avoir vu comment implémenter l'authentification sur EIGRP, nous allons voir la même chose via ce tutoriel pour OSPF.

    Cette fois, pour ce tutoriel, j'ai choisi 4 routeurs 2691, connectés entre eux via des liaisons séries dans une area 0.

    Screen-Shot-2012-03-02-at-18.40.00

    Vous pouvez retrouver la configuration de base en téléchargement ici.

    Avant de commencer la configuration, il y a quelques petits points à savoir.

    • Comme pour EIGRP, cette authentification via une clé partagée permettra aux routeurs de s'identifier entre eux avant de pouvoir envoyer leur packets OSPF contenant leur table de routage.
    • Il existe 3 types d'authentifications :
      - Pas d'authentification
      - Authentification avec texte en claire
      - Authentification chiffrée en MD5
    • Par défaut, il n'y a pas d'authentification
    • La longueur maximale de la clé utilisée pour l'authentification est de 16 caractères

    Il y a 2 façons d'activer l'authentification pour OSPF. Soit sur chaque interface du routeur, soit directement dans votre processus OSPF.

    1ère façon :

    Pour commencer, vérifions que nous avons bien 2 voisins depuis R1 :

    R1#show ip ospf neighbor
    Neighbor ID     Pri   State           Dead Time   Address         Interface
    4.4.4.4           0   FULL/  -        00:00:37    10.0.0.13       Serial0/1
    2.2.2.2           0   FULL/  -        00:00:36    10.0.0.2        Serial0/0

    Nous avons bien nos 2 routeurs R2 et R4. Pour activer l'authentification OSPF avec un mot de passe (maximum 8 caractères), nous allons écrire ces 2 commandes :

    R1(config-if)#ip ospf authentication
    R1(config-if)#ip ospf authentication-key florent

    Après avoir écrit la 1ère commande, vous devriez avoir un message de ce style :

    *Mar  1 00:04:49.655: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

    C'est normal, nous n'avons pas configuré l'interface série de R2.

    Pour vérifier la clé qu'il y a sur une interface précise :

    Serial0/0 is up, line protocol is up
    ...
      Simple password authentication enabled

    On a bien l'authentification activée sur l'interface série 0/0 et nous n'avons plus de voisins.

    R1#show ip ospf neighbor
    R1#

    Nous faisons maintenant de même sur les autres interfaces séries des routeurs R1, R2 et R4.
    Sur R4, en faisant un debug ip ospf packet, nous pouvons voir qu'il y a bien une authentification avec R1 (1.1.1.1) :

    *Mar  1 00:14:38.807: OSPF: rcv. v:2 t:1 l:48 rid:3.3.3.3
          aid:0.0.0.0 chk:DD90 aut:0 auk: from Serial0/0pa
    *Mar  1 00:14:41.047: OSPF: rcv. v:2 t:1 l:48 rid:1.1.1.1
          aid:0.0.0.0 chk:0 aut:2 keyid:0 seq:0x3C7EC7DC from Serial0/1cket

    2ème facon :

    Durant cette methode, nous allons activer l'authentification MD5 directement sur l'area 0 de OSPF. Vérifions déjà si R3 a bien 2 voisins et configurons l'authentification :

    R3#show ip ospf neighbor 
    
    Neighbor ID     Pri   State           Dead Time   Address         Interface
    4.4.4.4           0   FULL/  -        00:00:38    10.0.0.10       Serial0/1
    2.2.2.2           0   FULL/  -        00:00:38    10.0.0.5        Serial0/0
    R3#configure terminal
    R3(config)#router ospf 3
    R3(config-router)#area 0 authentication message-digest
    R3(config-router)#*Mar  1 00:30:18.895: %OSPF-5-ADJCHG: Process 3, Nbr 2.2.2.2 on Serial0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
    R3(config-router)#*Mar  1 00:30:19.475: %OSPF-5-ADJCHG: Process 3, Nbr 4.4.4.4 on Serial0/1 from FULL to DOWN, Neighbor Down: Dead timer expired

    Notre routeur vient de perdre ses 2 voisins car ils ne sont pas configuré avec l'authentification, jusqu'ici tout est normal. Maintenant on active cette authentification sur les interfaces séries et nous vérifions sur l'interface sériale 0/0 que l'authentification est bien activée :

    R3(config)#int s0/0
    R3(config-if)#ip ospf message-digest-key 1 md5 florent-appointa
    R3(config-if)#int s0/1
    R3(config-if)#ip ospf message-digest-key 1 md5 florent-appointa
    R3#show ip ospf interface s0/0
    ...
    Message digest authentication enabled
    Youngest key id is 1

    Pour information, la clé peut ici faire jusqu'a 16 caractères et vous pouvez avoir jusqu'à 255 clé différentes.

    Lançons le debug avant de configurer les interfaces de R2 et R4 :

    R3#debug ip ospf packet
    OSPF packet debugging is on

    Après avoir configuré R4 avec la même configuration que R3, le debug nous sort ceci :

    R3#
    *Mar  1 00:38:19.451: OSPF: rcv. v:2 t:1 l:48 rid:4.4.4.4
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECD47 from Serial0/1
    *Mar  1 00:38:19.467: OSPF: rcv. v:2 t:2 l:32 rid:4.4.4.4
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECD47 from Serial0/1
    *Mar  1 00:38:19.471: OSPF: rcv. v:2 t:2 l:112 rid:4.4.4.4
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECD47 from Serial0/1
    *Mar  1 00:38:19.471: OSPF: rcv. v:2 t:3 l:36 rid:4.4.4.4
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECD47 from Serial0/1
    *Mar  1 00:38:19.479: OSPF: rcv. v:2 t:2 l:32 rid:4.4.4.4
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECD47 from Serial0/1
    *Mar  1 00:38:19.479: OSPF: rcv. v:2 t:4 l:148 rid:4.4.4.4
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECD47 from Serial0/1
    *Mar  1 00:38:19.479: %OSPF-5-ADJCHG: Process 3, Nbr 4.4.4.4 on Serial0/1 from LOADING to FULL, Loading Done
    *Mar  1 00:38:19.987: OSPF: rcv. v:2 t:4 l:100 rid:4.4.4.4
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECD48 from Serial0/1
    *Mar  1 00:38:21.971: OSPF: rcv. v:2 t:5 l:44 rid:4.4.4.4
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECD4A from Serial0/1

    On voit ici que R3 vient d'apprendre qu'il avait un nouveau voisin avec le RID 4.4.4.4 sur l'interface série 0/1 et une authentification avec la clé 1.
    Faisons pareil sur R2 mais en faisant une faute de frappe dans la clé :

    R2(config)#router ospf 2
    R2(config-router)#area 0 authentication message-digest
    R2(config-router)#int s0/1
    R2(config-if)#ip ospf message-digest-key 1 md5 florent-appoimr

    R3 ne réagit pas, normal, il ne peut pas s'authentifier avec R2. Après avoir corrigé la clé, R3 remplit sa table car il s'est bien authentifier avec R2 :

    R3#
    *Mar  1 00:43:58.895: OSPF: rcv. v:2 t:1 l:48 rid:2.2.2.2
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECE92 from Serial0/0
    *Mar  1 00:43:58.895: OSPF: rcv. v:2 t:2 l:32 rid:2.2.2.2
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECE92 from Serial0/0
    *Mar  1 00:43:58.903: OSPF: rcv. v:2 t:2 l:112 rid:2.2.2.2
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECE92 from Serial0/0
    *Mar  1 00:43:58.907: OSPF: rcv. v:2 t:2 l:32 rid:2.2.2.2
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECE92 from Serial0/0
    *Mar  1 00:43:58.911: OSPF: rcv. v:2 t:2 l:32 rid:2.2.2.2
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECE92 from Serial0/0
    *Mar  1 00:43:58.911: %OSPF-5-ADJCHG: Process 3, Nbr 2.2.2.2 on Serial0/0 from LOADING to FULL, Loading Done
    *Mar  1 00:43:59.427: OSPF: rcv. v:2 t:4 l:100 rid:2.2.2.2
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECE92 from Serial0/0
    *Mar  1 00:44:01.887: OSPF: rcv. v:2 t:5 l:44 rid:2.2.2.2
          aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7ECE94 from Serial0/0

    Du côté de R2, nous obtenons ceci :

    R2(config-if)#
    *Mar  1 00:43:59.407: %OSPF-5-ADJCHG: Process 2, Nbr 3.3.3.3 on Serial0/1 from LOADING to FULL, Loading Done

    Voilà pour la fin de ce tuto, si vous avez des questions, n'hésitez pas. Le fichier GNS3 avec les configurations complètes est disponible ici.