Apprendre les technologies WAN: PPP, PPPoE, Tunnels GRE et BGP

Apprendre les technologies WAN: PPP, PPPoE, Tunnels GRE et BGP

La mise en œuvre des technologies WAN (Wide Area Network) pour l’examen CCNA se concentre sur les protocoles PPP, PPPoE, GRE, et eBGP. Aujourd’hui, nous passons en revue les commandes permettant de configurer, vérifier et de dépanner ces technologies.

Concepts PPP

PPP fournit plusieurs fonctions de base mais importantes qui sont utiles sur une ligne louée (ligne spécialisée (LS)) qui relie deux appareils :

  • Définition d’un en-tête et d’une bande-annonce qui permettent la livraison d’une trame de données sur la liaison.
  • Prise en charge des liaisons synchrones et asynchrones
  • Un champ Type de protocole dans l’en-tête, permettant à plusieurs protocoles de couche 3 de passer sur la même liaison.
  • Outils d’authentification intégrés, tels que le protocole d’authentification par mot de passe (PAP) et le protocole CHAP (Challenge Handshake Authentication Protocol)
  • Protocoles de contrôle pour chaque protocole de couche supérieure qui passe sur PPP, ce qui facilite l’intégration et la prise en charge de ces protocoles.

Le format de trames PPP

L’une des caractéristiques les plus importantes de la norme PPP est le champ Protocole normalisé, qui identifie le type de paquet à l’intérieur de la trame. Notez dans la Figure A que PPP a été construit sur la trame HDLC.

La trame HDLC montrée est le format Cisco, qui est le type d’encapsulation par défaut des interfaces série sur les routeurs Cisco.

Figure A Comparaison des trames Cisco HDLC et PPP
Figure A Comparaison des trames Cisco HDLC et PPP

PPP définit un ensemble de messages de contrôle de couche 2 qui exécutent diverses fonctions de contrôle de liaison. Ces fonctions de contrôle se divisent en deux grandes catégories :

  • Fonctions nécessaires quel que soit le protocole de couche 3 envoyé sur la liaison
  • Fonctions spécifiques à chaque protocole de couche 3

Le protocole PPP Link Control Protocol (LCP) met en œuvre les fonctions de contrôle qui fonctionnent de la même manière, quel que soit le protocole de couche 3.

Pour les fonctions liées aux protocoles de couche supérieure (généralement les protocoles de couche 3), PPP utilise une série de protocoles de contrôle PPP (CP), tels que IP Control Protocol (IPCP).

PPP utilise une instance de LCP par liaison et un CP pour chaque protocole de couche 3 défini sur la liaison. Par exemple, sur une liaison PPP utilisant IPv4, IPv6 et Cisco Discovery Protocol (CDP), la liaison utilise une instance de LCP, plus IPCP (pour IPv4), IPv6CP (pour IPv6) et CDPCP (pour CDP).

On les appelle souvent les protocoles de contrôle de réseau (NCP).

Protocole de contrôle de liaison PPP (LCP)

LCP offre quatre fonctionnalités notables (voir le tableau A)

Tableau A – Fonctionnalités du LCP

FonctionFonctionnalité LCPDescription
Détection de liaison en boucleNombre magiqueDétecte si la liaison est bouclée et désactive l'interface, ce qui permet le réacheminement du trafic sur une route.
Détection d'erreursSurveillance de la qualité des liens (LQM)Désactive une interface qui dépasse un seuil de pourcentage d'erreur, ce qui permet le réacheminement sur de meilleurs routes.
Support MultilinkPPP à liaisons multiplesÉquilibre la charge du trafic sur plusieurs liaisons parallèles.
AuthentificationPAP et CHAPÉchange des noms et des mots de passe afin que chaque appareil puisse vérifier l'identité de l'appareil à l'autre extrémité du lien.

Détection de liens en boucle

LCP détecte rapidement les liens en boucle à l’aide d’une fonction appelée numéros magiques. Les messages PPP LCP comprennent un nombre magique qui diffère selon le routeur.

Si une ligne est bouclée (par exemple lors d’un test effectué par un technicien en télécommunications), le routeur reçoit un message LCP avec son propre numéro magique au lieu de recevoir un message avec celui de l’autre routeur.

PPP aide le routeur à reconnaître rapidement une liaison en boucle afin qu’il puisse réduire l’interface et éventuellement utiliser un route alternative.

Si le routeur peut immédiatement constater que la liaison est bouclée, il peut mettre l’interface dans un état down et down, et les protocoles de routage peuvent modifier leurs mises à jour en fonction du fait que la liaison est hors-service.

Détection d’erreur améliorée (Enhanced Error Detection)

Lorsqu’un réseau possède des liens redondants, vous pouvez utiliser PPP pour surveiller la fréquence avec laquelle les trames sont reçues par erreur.

Une fois le taux d’erreur configuré est dépassé, PPP peut démonter l’interface, ce qui permet aux protocoles de routage d’installer une meilleure route de sauvegarde.

PPP LCP analyse les taux d’erreur sur une liaison à l’aide d’une fonction PPP appelée Link Quality Monitoring (LQM).

PPP Multilink

Dans une configuration redondante entre deux routeurs, les routeurs utilisent l’équilibrage de charge de couche 3, alternant le trafic entre les deux liaisons, ce qui n’aboutit pas toujours à un partage vraiment équilibré du trafic.

Multilink PPP équilibre la charge du trafic de manière égale sur les liaisons PPP tout en permettant à la logique de couche 3 de chaque routeur de traiter les liaisons parallèles comme une seule liaison.

Lors de l’encapsulation d’un paquet, PPP fragmente le paquet en trames plus petites, envoyant un fragment sur chaque liaison. Multilink PPP permet aux tables de routage de couche 3 d’utiliser une route unique qui se réfère aux liens combinés, ce qui réduit la taille de la table de routage.

Authentification PPP

PAP et CHAP authentifient les points d’extrémité à chaque extrémité d’une liaison série point à point.

CHAP est aujourd’hui la méthode préférée parce que le processus d’identification utilise des valeurs cachées par un hachage unidirectionnel de l’algorithme MD5, qui est plus sûr que d’utiliser les mots de passe clairs envoyés par le protocole PAP.

La figure B montre les différents processus PAP et CHAP utilisés. Avec PAP, le nom d’utilisateur et le mot de passe sont envoyés dans le premier message.

Avec CHAP, le protocole commence par un message appelé challenge, qui demande à l’autre routeur d’envoyer son nom d’utilisateur et son mot de passe.

Figure B Protocoles d'authentification PPP
Figure B Protocoles d’authentification PPP

PAP est beaucoup moins sûr que CHAP car PAP envoie le nom d’hôte et le mot de passe en texte clair dans le message.

CHAP utilise plutôt un algorithme de hachage unidirectionnel, l’entrée dans l’algorithme étant un mot de passe qui ne traverse jamais le lien, plus un nombre aléatoire partagé. Le challenge CHAP indique le nombre aléatoire ; les deux routeurs sont pré-configurés avec le mot de passe.

Le routeur mis en cause exécute l’algorithme de hachage à l’aide du nombre aléatoire nouvellement appris et du mot de passe secret et renvoie les résultats au routeur qui a envoyé le challenge.

Le routeur qui a envoyé le challenge exécute le même algorithme en utilisant le nombre aléatoire (envoyé à travers le lien) et le mot de passe (pas envoyé à travers le lien).

Si les résultats correspondent, les mots de passe doivent correspondre. Avec le nombre aléatoire, la valeur de hachage est différente à chaque fois.

Configuration et vérification du protocole PPP

Cette section fait référence à la topologie de la figure C.

Figure C Topologie PPP
Figure C Topologie PPP

Protocole PPP de base

La configuration de PPP ne nécessite que la commande encapsulation ppp aux deux extrémités de la liaison. L’exemple A montre une configuration simple utilisant les deux routeurs de la Figure C.

Exemple A – Configuration et vérification du PPP

R1(config)# interface serial 0/0/1
R1(config-if)# ip address 192.168.2.1 255.255.255.0
R1(config-if)# encapsulation ppp
R1(config-if)# no shutdown
%LINK-5-CHANGED: Interface Serial0/0/1, changed state to down
R2(config)# interface serial 0/1/1
R2(config-if)# ip address 192.168.2.2 255.255.255.0
R2(config-if)# encapsulation ppp
R2(config-if)# no shutdown
%LINK-5-CHANGED: Interface Serial0/1/1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1/1, changed state to up
R2(config-if)# end

R2# show interfaces serial 0/1/1
Serial0/1/1 is up, line protocol is up (connected)
   Hardware is HD64570
   Internet address is 192.168.2.2/24
   MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
   Encapsulation PPP, loopback not set, keepalive set (10 sec)
   LCP Open
   Open: IPCP, CDPCP

<texte ignoré>

La commande show interfaces au bas de l’exemple montre la sortie normale lorsque le lien est établi et fonctionne.

Quelques lignes après la sortie, les phrases surlignées montrent que PPP est effectivement configuré et que LCP a terminé son travail avec succès, comme indiqué avec la phrase “LCP Open”.

En outre, le résultat indique que deux CPs, CDPCP et IPCP, ont été activés avec succès (toutes de bonnes indications que le PPP fonctionne correctement).

CHAP

Bien que CHAP soit optionnel, il doit être configuré pour fournir une liaison point à point sécurisée. La version la plus simple de la configuration CHAP ne nécessite que quelques commandes.

La configuration utilise un mot de passe configuré sur chaque routeur. Comme alternative, le mot de passe peut être configuré sur un serveur externe d’authentification, d’autorisation et de comptabilité (AAA) à l’extérieur du routeur.

Les étapes de configuration sont les suivantes :

Étape 1. Configurez les noms d’hôtes des routeurs à l’aide de la commande de configuration globale hostname name.

Étape 2. Configurez le nom de l’autre routeur et le mot de passe secret partagé à l’aide de la commande de configuration globale username name password password.

Étape 3. Activez CHAP sur l’interface de chaque routeur en utilisant la sous-commande d’authentification ppp chap.

L’exemple B montre un exemple de configuration à l’aide des routeurs de la Figure C. Comme les noms d’hôtes sont déjà configurés, cette étape n’est pas affichée.

Exemple B Configuration de l’authentification CHAP

R1(config)# username R2 password itsasecret
R1(config)# interface serial 0/0/1
R1(config-if)# ppp authentication chap
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down

R2(config)# username R1 password itsasecret
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1/1, changed state to up
R2(config)# interface serial 0/1/1
R2(config-if)# ppp authentication chap
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1/1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1/1, changed state to up

Notez que dès que CHAP est configuré sur R1, l’interface tombe en panne. Puis sur R2, une fois le mot de passe configuré correctement, l’interface est réactivée. Enfin, il tombe brièvement en panne avant de se réactiver lorsque CHAP est configuré sur R2.

Les commandes elles-mêmes ne sont pas compliquées, mais il est facile de mal configurer les noms d’hôtes et les mots de passe.

Notez que chaque routeur se réfère au nom d’hôte de l’autre routeur spécifié dans la commande username, mais que les deux routeurs doivent configurer la même valeur de mot de passe.

De plus, non seulement les mots de passe (itsasecret, dans ce cas) sont sensibles à la casse, mais les noms d’hôtes, tels que référencés dans la commande username, le sont aussi.

Comme CHAP est une fonction de LCP, si le processus d’authentification échoue, LCP n’est pas terminé et l’interface passe à un état d’interface up et down.

PAP

Comme pour CHAP, le PAP est facultatif. Vous ne l’utilisez que si l’un des appareils ne supporte pas CHAP.

PAP utilise les mêmes commandes de configuration que CHAP, sauf que la commande ppp authentification pap est utilisée à la place de ppp authentification chap.

Les autres commandes de vérification fonctionnent de la même manière, quel que soit le type d’authentification utilisé. Par exemple, si l’authentification PAP échoue, LCP échoue et le lien s’installe dans un état up et down.

Le logiciel Cisco IOS prend également en charge la possibilité de configurer le routeur pour essayer d’abord une méthode d’authentification, puis, si l’autre partie ne répond pas, essayer l’autre option. La syntaxe complète de la commande d’authentification ppp suit :

Router(config-if)# ppp authentication {pap | chap | pap chap | chap pap}

Par exemple, la sous-commande interface ppp authentication chap pap indique au routeur d’envoyer des messages CHAP et, si aucune réponse n’est reçue, d’essayer PAP.

Notez que la seconde option n’est pas essayée si les messages CHAP circulent entre les deux dispositifs ; par conséquent, l’authentification échoue. Le router utilise l’autre option uniquement si l’autre appareil ne renvoie aucun message.

Dépannage PPP

Utilisez la commande debug ppp pour résoudre les problèmes PPP.

Router# debug ppp {packet | negotiation | error | authentication | compression | cbcp}

Les problèmes PPP sont le plus souvent liés aux erreurs de configuration d’authentification. Dans l’exemple C, nous savons que le nom d’utilisateur ou le mot de passe est mal configuré sur un ou sur les deux côtés du lien.

Exemple C – Échec de l’authentification PPP CHAP dans la sortie du débogage de l’authentification ppp

R1# debug ppp authentication
PPP authentication debugging is on
Se0/0/0 PPP: Authorization required
Se0/0/0 CHAP: O CHALLENGE id 57 len 23 from "R1"
Se0/0/0 CHAP: I CHALLENGE id 66 len 23 from "R2"
Se0/0/0 CHAP: Using hostname from unknown source
Se0/0/0 CHAP: Using password from AAA
Se0/0/0 CHAP: O RESPONSE id 66 len 23 from "R1"
Se0/0/0 CHAP: I RESPONSE id 57 len 23 from "R2"
Se0/0/0 PPP: Sent CHAP LOGIN Request
Se0/0/0 PPP: Received LOGIN Response FAIL
Se0/0/0 CHAP: O FAILURE id 57 len 25 msg is "Authentication failed"

Concepts PPPoE

PPP peut être utilisé sur toutes les liaisons série, y compris les liaisons créées avec des modems analogiques dialup et RNIS.

Jusqu’à ce jour, la liaison d’un utilisateur d’accès commuté à un fournisseur de services Internet (FSI), à l’aide de modems analogiques, utilise probablement le PPP (voir Figure D).

Figure D Connexion typique PPP à un FSI
Figure D Connexion typique PPP à un FSI

En outre, les FSIs utilisent souvent le PPP comme protocole de liaison de données sur des connexions à large bande pour les raisons suivantes :

  • La possibilité d’attribuer des adresses IP aux extrémités distantes d’une liaison PPP
  • Prise en charge de CHAP pour authentifier les clients, permettant aux FSIs de vérifier également les écritures comptables avant d’autoriser l’accès.

Les technologies sont arrivées sur le marché dans l’ordre suivant, avec un soutien variable pour les PPP :

  1. Modems analogiques pour accès commuté pouvant utiliser PPP et CHAP
  2. RNIS pour les accès commutés qui pourraient utiliser PPP et CHAP
  3. DSL, qui n’a pas créé de liaison point à point et ne pouvait pas prendre en charge les PPP et CHAP

PPPoE a été développé parce que les liaisons Ethernet ne supportent pas nativement PPP. Comme le montre la Figure E, PPPoE permet l’envoi de trames PPP encapsulées dans des trames Ethernet.

Figure E Construction d'un tunnel PPP à l'intérieur d'Ethernet
Figure E Construction d’un tunnel PPP à l’intérieur d’Ethernet

Configuration PPPoE

Pour mettre en œuvre PPPoE, suivez les étapes suivantes :

Étape 1. Créez un tunnel PPP à l’aide d’une interface de numérotation (dialer interface), qui est un type d’interface virtuelle. Configurez PPP et l’adressage sur l’interface du numéroteur (dialer interface). En règle générale, le FSI attribue automatiquement l’adressage IP.

Étape 2. Configurez PPP CHAP pour effectuer l’authentification avec le FSI.

Étape 3. Activez PPPoE sur l’interface physique avec la commande pppoe enable. L’interface du numéroteur est reliée à l’interface Ethernet avec la commande pppoe-client, suivie du numéro utilisé pour créer le pool de numéroteurs à l’étape 2.

Le numéro d’interface du numéroteur ne doit pas nécessairement correspondre au numéro de pool du numéroteur .

Étape 4. L’unité de transmission maximale (MTU) doit être fixée à 1492, contre 1500 par défaut, pour tenir compte des en-têtes PPPoE. Ceci permet d’éviter la fragmentation des paquets, ce qui entraîne un retard dans la transmission.

Exemple de configuration PPPoE
L’exemple D montre comment configurer et vérifier PPPoE sur R1.

Exemple D – Configuration et vérification de PPPoE

R1(config)# interface dialer 5
R1(config-if)# encapsulation ppp
R1(config-if)# ip address negotiated
R1(config-if)# ip mtu 1492
R1(config-if)# dialer pool 5
R1(config-if)# ppp chap hostname customer2222
R1(config-if)# ppp chap password ConnectMe
R1(config-if)# no shutdown
R1(config-if)# interface GigabitEthernet 0/0
R1(config-if)# no ip address
R1(config-if)# pppoe enable
R1(config-if)# pppoe-client dial-pool-number 5
R1(config-if)# no shutdown
R1(config-if)# end
R1# show ip interface brief
Interface 		IP-Address 	OK? Method Status 	Protocol
GigabitEthernet0/0 	unassigned 	YES NVRAM  up 		up
GigabitEthernet0/1 	172.16.1.1 	YES manual up 		up
Dialer5 		64.100.10.1 	YES manual up 		up
Virtual-Access1 	unassigned 	YES unset  up 		up

Dépannage PPPoE

Après vous être assuré que le routeur client et le modem DSL sont connectés avec les câbles appropriés, un ou plusieurs des problèmes suivants sont généralement la cause d’une connexion PPPoE qui ne fonctionne pas correctement :

  • Échec dans le processus de négociation de PPP
  • Échec du processus d’authentification PPP
  • Non-réglage de la taille maximale des segment TCP

GRE Tunnelage

L’encapsulation de routage générique (GRE) est un exemple de protocole de tunnelage VPN de base, non sécurisé, site-à-site. Typiquement, le GRE est utilisé pour acheminer les paquets IP à travers l’Internet, comme dans la Figure F.

Nous passons brièvement en revue ici les caractéristiques et la configuration de la technologie GRE.

Figure F Encapsulation du routage générique
Figure F Encapsulation du routage générique

Caractéristiques de la technologie GRE

GRE possède ces caractéristiques :

  • GRE est défini comme une norme IETF (RFC 2784).
  • Dans l’en-tête IP externe, 47 est utilisé dans le champ Protocole pour indiquer qu’un en-tête GRE suivra.
  • L’encapsulation GRE utilise un champ Type de protocole dans l’en-tête GRE pour prendre en charge l’encapsulation de tout protocole OSI de couche 3. La RFC 1700 définit les types de protocole comme EtherTypes.
  • Le GRE lui-même est stateless; par défaut, il ne comporte aucun mécanisme de contrôle de flux.
  • Le GRE ne comprend pas de mécanismes de sécurité solides pour protéger son payload.
  • L’en-tête GRE, avec l’en-tête IP tunneling indiqué sur la figure, crée au moins 24 octets de surcharge supplémentaire pour les paquets tunnelés.

Configuration et vérification des tunnels GRE

Dans la figure G, R1 communique avec R2 par Internet via un tunnel GRE.

Figure G Topologie du tunnel GRE
Figure G Topologie du tunnel GRE

Notez que l’adressage des interfaces physiques n’appartient pas au même sous-réseau, mais que l’adressage de l’interface tunnel appartient au même sous-réseau.

Pour configurer un tunnel GRE, suivez les étapes suivantes :

Étape 1. Créez une interface tunnel à l’aide de la commande interface tunnel number.

Étape 2. Spécifiez l’adresse IP source du tunnel. La source peut également être le nom de l’interface locale et le numéro de série, tel que Serial 0/0/0.

Étape 3. Spécifiez l’adresse IP de destination du tunnel.

Étape 4. Configurez une adresse IP pour l’interface tunnel.

Étape 5. (Facultatif) Spécifiez le mode du tunnel GRE comme mode de l’interface tunnel avec la commande tunnel mode gre ip. Le mode GRE tunnel est le mode par défaut d’une interface tunnel du logiciel Cisco IOS.

L’exemple E illustre les étapes de configuration d’un tunnel GRE sur R1 et R2. Notez que la configuration OSPF inclut le sous-réseau du tunnel afin que les routeurs puissent établir une adjacence OSPF à travers la liaison tunnel.

Exemple E – Configuration du tunnel GRE

R1(config)# interface Tunnel0
R1(config-if)# tunnel mode gre ip
R1(config-if)# ip address 192.168.2.1 255.255.255.0
R1(config-if)# tunnel source s0/0/0
R1(config-if)# tunnel destination 198.133.219.87
R1(config-if)# router ospf 1
R1(config-router)# network 192.168.2.0 0.0.0.255 area 0

R2(config)# interface Tunnel0
R2(config-if)# tunnel mode gre ip
R2(config-if)# ip address 192.168.2.2 255.255.255.0
R2(config-if)# tunnel source s0/0/0
R2(config-if)# tunnel destination 209.165.201.1
R2(config-if)# router ospf 1
R2(config-router)# network 192.168.2.0 0.0.0.255 area 0

REMARQUE : L’implémentation d’IPsec est supposée dans cet exemple. Cependant, la configuration d’IPsec dépasse le portée de l’examen CCNA/ICND2.

Pour vérifier l’implémentation d’un tunnel GRE, vous devriez pouvoir pinguer R1 à partir de R2 et aussi pinguer R2 à partir de R1, et ils devraient avoir des tables de routage convergentes. En outre, vous pouvez utiliser les commandes show ip interface brief et show interface Tunnel, comme dans l’exemple F.

Exemple F – Vérifier que l’état de l’interface du tunnel est up

R1# show ip interface brief | include Tunnel

Tunnel0 	192.168.2.1 	YES manual up 	up

R1# show interface Tunnel 0
Tunnel0 is up, line protocol is up
   Hardware is Tunnel
   Internet address is 192.168.2.1/24
   MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
      reliability 255/255, txload 1/255, rxload 1/255
   Encapsulation TUNNEL, loopback not set
   Keepalive not set
   Tunnel source 209.165.201.1, destination 198.133.219.87
   Tunnel protocol/transport GRE/IP

<output ignoré>

Dépannage du GRE

Les problèmes avec les tunnels GRE résultent généralement d’une ou plusieurs des erreurs de configuration suivantes :

  • Les adresses IP de l’interface tunnel ne sont pas sur le même réseau ou les masques de sous-réseau ne correspondent pas.
  • Les interfaces pour la source et/ou la destination du tunnel ne sont pas configurées avec l’adresse IP correcte ou sont à l’état down.
  • Le routage statique ou dynamique n’est pas correctement configuré.

Concepts BGP

BGP échange des informations de routage avec un autre routeur, appelé voisin BGP ou pair BGP. Ces voisins BGP sont des routeurs d’autres entreprises, et non des routeurs de la même entreprise.

Ceci distingue le protocole BGP des protocoles de passerelle intérieure (IGP) tels que OSPF et EIGRP qui échangent des informations de routage avec des routeurs de la même entreprise.

Un routeur de périphérie d’entreprise est configuré pour annoncer un préfixe IPv4 public avec son FSI. Dans la Figure H, le routeur d’entreprise annonce le préfixe IPv4 192.0.2.0/24 au FSI1.

FSI1 annonce ensuite le préfixe au FSI2, et ainsi de suite. De cette façon, les routeurs Internet sont informés sur l’espace d’adressage public de l’entreprise.

Figure H Les routes BGP se propagent vers les FSI
Figure H Les routes BGP se propagent vers les FSI

BGP utilise TCP avec le port bien connu numéro 179 pour transporter ses messages entre deux pairs BGP. Lorsque vous configurez BGP, il ouvre le port 179, en attendant les demandes de connexion entrantes provenant d’autres routeurs. Lorsqu’un pair se connecte, la connexion TCP est établie.

Le numéro de système autonome (ASN dans la figure H) joue un rôle important dans BGP en identifiant les réseaux qui fonctionnent séparément des autres réseaux. Par exemple, le FSI1 de la Figure I a trois routeurs dans ASN1. Les routeurs du même AS (autonomous system) échangent des préfixes BGP intérieurs (iBGP) qui incluent très probablement des préfixes appris de voisins BGP extérieurs (eBGP).

Figure I iBGP et eBGP
Figure I iBGP et eBGP

Configuration et vérification du protocole eBGP

Pour l’examen CCNA, vous êtes responsable de savoir comment configurer et vérifier une connexion eBGP mono-domiciliée.

Il s’agit généralement d’un emplacement configuré pour annoncer ses préfixes IPv4 publics à un FSI local, comme illustré à la Figure J.

Figure J Topologie de la configuration eBGP
Figure J Topologie de la configuration eBGP

Pour implémenter eBGP pour une connexion mono-domiciliée, vous devez effectuer les tâches suivantes :

Étape 1. Activer le routage BGP.

Étape 2. Configurer le(s) voisin(s) BGP (peering).

Étape 3. Annoncer le(s) réseau(s) issu(s) du AS courant.

Le tableau B présente la syntaxe des commandes et décrit la configuration de base de l’eBGP.

Tableau B – Commandes de configuration du BGP

CommandeDescription
Router(config)# router
bgp as-number
Active un processus de routage BGP et place le routeur en mode de configuration routeur.
Router(config-router)#
neighbor ip-address
remote-as as-number
Spécifie un voisin BGP. Le numéro d'identification est l'AS du voisin.
numéro.
Router(config-router)#
network network-address
[mask network-mask]
Spécifie un réseau comme local pour cet AS, l'ajoute à la table de routage BGP et annonce le réseau aux pairs BGP. Le masque de réseau spécifie quelle partie de l'adresse réseau est annoncée. Si aucun masque n'est configuré, le masque par défaut de la classe est considéré comme un masque par défaut.

L’exemple G montre la configuration BGP pour l’entreprise A et le FSI1.

Exemple G – Exemple de configuration BGP

Company-A(config-if)# router bgp 65000
Company-A(config-router)# neighbor 209.165.201.1 remote-as 65001
Company-A(config-router)# network 198.133.219.0 mask 255.255.255.0

ISP-1(config-if)# router bgp 65001
ISP-1(config-router)# neighbor 209.165.201.2 remote-as 65000
%BGP-5-ADJCHANGE: neighbor 209.165.201.2 Up
ISP-1(config-router)# network 0.0.0.0

 

La commande neighbor définit le pair BGP et son numéro AS. Notez que le numéro AS du FSI est différent de celui de l’entreprise.

Ceci informe le processus BGP que le voisin se trouve dans un AS différent et est donc un voisin BGP externe. Observez le message d’adjacence sur FSI-1 après que la commande neighbor a été saisie.

La commande network insère l’adresse réseau dans la table BGP locale. La table BGP contient toutes les routes qui sont apprises via BGP ou annoncées via BGP. eBGP annonce ensuite l’adresse réseau à ses voisins eBGP.

Sur le FSI-1, la commande network 0.0.0.0 annonce un réseau par défaut à la Entreprise-A.

REMARQUE : Bien que la commande network 0.0.0.0 soit une option de configuration BGP valide, il existe de meilleures façons d’annoncer une route par défaut dans eBGP. Cependant, ces méthodes dépassent le cadre de l’examen CCNA.

Trois commandes peuvent être utilisées pour vérifier eBGP (voir Tableau C).

Tableau C – Commandes de vérification BGP

CommandeDescription
Router# show ip routeVérifie que les routes annoncées par le voisin BGP sont présentes dans la table de routage IPv4.
Router# show ip bgpVérifie que les réseaux IPv4 reçus et annoncés se trouvent dans la table BGP.
Router# show ip bgp
summary
Vérifie les voisins BGP IPv4 et autres informations BGP

L’exemple H affiche la sortie de ces trois commandes pour l’Enreprise-A.

Exemple H – Vérification du eBGP pour l’entreprise-A

Entreprise-A# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
<..............>

Gateway of last resort is 209.165.201.1 to network 0.0.0.0

B* 0.0.0.0/0 [20/0] via 209.165.201.1, 00:00:47
   198.133.219.0/24 is variably subnetted, 2 subnets, 2 masks
C       198.133.219.0/24 is directly connected, GigabitEthernet0/0
L      198.133.219.1/32 is directly connected, GigabitEthernet0/0
   209.165.201.0/24 is variably subnetted, 2 subnets, 2 masks
C       209.165.201.0/27 is directly connected, GigabitEthernet0/1
L       209.165.201.2/32 is directly connected, GigabitEthernet0/1

Entreprise-A# show ip bgp
BGP table version is 3, local router ID is 209.165.201.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
         r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
         x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
   Network    Next Hop    Metric    LocPrf    Weight    Path
*>    0.0.0.0    209.165.201.1    0          0 65001 i
*>    198.133.219.0    0.0.0.0    0          32768 i

Entreprise-A# show ip bgp summary
BGP router identifier 209.165.201.2, local AS number 65000
BGP table version is 3, main routing table version 3
2 network entries using 288 bytes of memory
2 path entries using 160 bytes of memory
2/2 BGP path/bestpath attribute entries using 320 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 792 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor    V    AS    MsgRcvd    MsgSent    TblVer    InQ OutQ    Up/Down    State/PfxRcd
209.165.201.1    4    65001    7       5       3     0    0    00:01:27 1
Entreprise-A#

 

Dans la sortie de la commande show ip route, noter le B, qui indique que la route a été apprise par BGP. La commande show ip bgp affiche la table BGP. Le saut suivant, 0.0.0.0 pour 198.133.219.0, indique que le réseau provient de ce routeur.

Dans la sortie de la commande show ip bgp summary, la première ligne affiche l’adresse IPv4 locale utilisée pour construire une connexion avec un autre voisin BGP et le numéro AS local de ce routeur. L’adresse et le numéro AS du voisin BGP distant apparaissent en bas de la sortie.

LAISSER UN COMMENTAIRE

Please enter your comment!
Please enter your name here


CAPTCHA Image
Reload Image