Configuration HSRP : Hot Standby Router Protocol

Sur un PC on configure généralement une seule passerelle par défaut… Mais que se passe-t-il si celle-ci est hors service ? … La réponse est simple … plus moyen de communiquer en dehors de son domaine de diffusion.

Pour remédier à cela, il existe plusieurs méthodes pour gérer la redondance de passerelle dont les protocoles HSRP, VRRP et GLBP.

Voici un exemple simple de mise en place de redondance de passerelle à l’aide de HSRP. Il est toutefois important de noter qu’il s’agit d’un protocole propriétaire Cisco.

La topologie

Afin d’aller directement à l’essentiel, la configuration de base de la topologie est considérée comme terminée. Pour ma part j’ai simplement activé EIGRP entre R1, R2 et R3.

R3 dispose d’une interface Loopback (1.1.1.1/32) que j’utiliserai pour tester la communication depuis le PC.

Le PC (C1) est configuré avec l’adresse 192.168.0.10/24 avec une passerelle par défaut 192.168.0.254. Notez qu’il ne s’agit pas de l’adresse configurée sur R1 ou R2 … Mais ce sera celle dont le rôle sera assumé soit par R1 soit par R2 en fonction de l’état du réseau.

Principe général

HSRP est un protocole qui fourni une solution de continuité de service principalement pour la redondance de passerelles par défaut.

Pour chaque réseau, on associe les interfaces des routeurs à un groupe HSRP (le même n° de groupe pour toutes les interfaces qui doivent assurer le même rôle). A ce groupe on associe une adresse IP virtuelle (dans le cas présent ce sera 192.168.0.254).

La redondance est mise en place par le biais du protocole ARP. Lorsque le PC doit envoyer une trame à sa passerelle, il émet une requête ARP et celle-ci répond en fournissant son adresse MAC.

Avec HSRP, les routeurs vont associer une adresse MAC particulière à l’adresse IP virtuelle sous la forme 00:00:0c:07:ac:XX (où XX est le n° du groupe HSRP).

Dés lors, pour le PC, quoi qu’il arrive, ce sera cette adresse MAC qui identifiera sa passerelle.   De leur côté les routeurs dialoguent par multicast afin de négocier et de savoir qui devra se charger de traiter la trame destinée à l’adresse MAC HSRP.

Configuration de R1

R1(config)# interface FastEthernet0/0
R1(config-if)# standby 1 ip 192.168.0.254
R1(config-if)# standby 1 priority 200
R1(config-if)# standby 1 preempt

On a donc configuré ici l’interface Fa0/0 de R1 pour fonctionner dans le groupe HSRP n°1 auquel on a associé l’adresse IP virtuelle 192.168.0.254. En plus on a défini une priorité de 200 (la plus grande priorité sera la passerelle effective) et on active le droit de préemption (si R1 tombe en panne, R2 prend le relai… mais is R1 revient, il reprendra sa place, sans préemption, R2 resterait la passerelle).

Configuration de R2

R2(config)# interface FastEthernet0/0
R2(config-if)# standby 1 ip 192.168.0.254
R2(config-if)# standby 1 priority 100

La configuration de R2 est similaire à celle de R1, étant donné que R2 est configuré avec une priorité plus faible, il n’est pas nécessaire d’activer la préemption.

Vérification

Sur le PC, un test de communication démontre le bon fonctionnement de la configuration…

La configuration de C1:

NAME  IP/MASK         GATEWAY       MAC
VPCS1 192.168.0.10/24 192.168.0.254 00:50:79:66:68:00

Test de communication vers 1.1.1.1

VPCS[1]> ping 1.1.1.1
1.1.1.1 icmp_seq=1 timeout
1.1.1.1 icmp_seq=2 ttl=254 time=50.000 ms
1.1.1.1 icmp_seq=3 ttl=254 time=50.000 ms
1.1.1.1 icmp_seq=4 ttl=254 time=39.000 ms
1.1.1.1 icmp_seq=5 ttl=254 time=48.000 ms

Il est intéressant d’analyser la table ARP de C1…

VPCS[1]> arp
00:00:0c:07:ac:01 192.168.0.254 expires in 114 seconds

On constate donc bien que 192.168.0.254 est la passerelle de C1 et que l’adresse MAC associée est bien celle d’un groupe HSRP (ici le groupe 1, indiqué par le dernier octet de l’adresse MAC … 01). Un traceroute prouvera que R1 est bien le routeur faisant office de passerelle…

VPCS[1]> trace 1.1.1.1
trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
 1 192.168.0.1  20.000 ms 10.000 ms 10.000 ms
 2 172.30.0.1   30.000 ms 10.000 ms 10.000 ms
 3 1.1.1.1      30.000 ms 10.000 ms 10.000 ms

Vérification de la configuration

Sur R1 et R2 il est possible de vérifier le fonctionnement de HSRP d’une simple commande:

R1#show standby
FastEthernet0/0 - Group 1
 State is Active
 2 state changes, last state change 00:14:40
 Virtual IP address is 192.168.0.254
 Active virtual MAC address is 0000.0c07.ac01
 Local virtual MAC address is 0000.0c07.ac01 (v1 default)
 Hello time 3 sec, hold time 10 sec
 Next hello sent in 1.064 secs
 Preemption enabled
 Active router is local
 Standby router is 192.168.0.2, priority 100 (expires in 8.320 sec)
 Priority 200 (configured 200)
 Group name is "hsrp-Fa0/0-1" (default)
R1#

On y voit que « State is Active » qui signifie que R1 est la passerelle active (et donc R2 est en standby). Le reste des informations sont explicites.

Que se passe-t-il si R1 tombe en panne …

Pour simuler une panne, je mets simplement l’interface Fa0/0 de R1 en shutdown…

R1(config-if)# shutdown
*Mar 1 00:44:02.331: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Init
*Mar 1 00:44:04.343: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 1 00:44:05.343: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0, changed state to down

Réaction immédiate de R2 …

R2#
*Mar 1 00:44:11.071: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active

R2 est bien devenu la passerelle active, vérifions sur C1…

VPCS[1]> ping 1.1.1.1
1.1.1.1 icmp_seq=1 ttl=254 time=32.000 ms
1.1.1.1 icmp_seq=2 ttl=254 time=41.000 ms
1.1.1.1 icmp_seq=3 ttl=254 time=31.000 ms
1.1.1.1 icmp_seq=4 ttl=254 time=31.000 ms
1.1.1.1 icmp_seq=5 ttl=254 time=40.000 ms

VPCS[1]> arp
00:00:0c:07:ac:01 192.168.0.254 expires in 15 seconds

Rien n’a changé de son côté, normal … puisque R1 et R2 utilisent la même adresse IP virtuelle associée à la même adresse MAC pour HSRP. Par contre le paquet ICMP passe bien par R2…

VPCS[1]> trace 1.1.1.1
trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
 1 192.168.0.2  21.000 ms 11.000 ms 11.000 ms
 2 172.30.0.5   31.000 ms 12.000 ms 12.000 ms
 3 1.1.1.1      32.000 ms 12.000 ms 12.000 ms

Voilà de quoi gérer très simplement la redondance de passerelle par défaut (à condition de disposer de matériel Cisco).

Read More

Configuration VRRP : Virtual Router Redundancy Protocol

Dans l’article précédent nous avons vu une mise en oeuvre simple de HSRP qui permet de gérer la redondance de passerelle (entre autre). Bien que simple à mettre en place, HSRP a comme principal defaut d’être propriétaire  Cisco. Voici donc une mise en place équivalente de VRRP, protocole standard défini dans la RFC 5798…

Afin de permettre une comparaison facile avec HSRP, j’ai gardé la même structure pour l’article.

La topologie

La topologie est similaire à celle utilisée dans l’article sur HSRP. R1 et R2 seront donc les deux passerelles par défaut à faire fonctionner en redondance.

R1 et R2 communiqueront à l’aide de VRRP par leurs interfaces FastEthernet afin de négocier leur rôle.

Principe général

VRRP est donc, à l’instar de HSRP, également un protocole qui fourni une solution de continuité de service principalement pour la redondance de passerelles par défaut.

Pour chaque réseau, on associe les interfaces des routeurs à un groupe VRRP (le même n° de groupe pour toutes les interfaces qui doivent assurer le même rôle). A ce groupe on associe une adresse IP virtuelle (dans le cas présent ce sera 192.168.0.254).

La redondance est mise en place par le biais du protocole ARP. Lorsque le PC doit envoyer une trame à sa passerelle, il émet une requête ARP et celle-ci répond en fournissant son adresse MAC.

Dans le cas de VRRP, les routeurs vont associer une adresse MAC particulière à l’adresse IP virtuelle sous la forme  00:00:5E:00:01:XX (où XX est le n° du groupe VRRP).

Dés lors, pour le PC, quoi qu’il arrive, ce sera cette adresse MAC qui identifiera sa passerelle.   De leur côté les routeurs dialoguent par multicast (224.0.0.18) afin de négocier et de savoir qui devra se charger de traiter la trame destinée à l’adresse MAC VRRP.

Configuration de R1

R1(config)# interface FastEthernet0/0
R1(config-if)# vrrp 1 ip 192.168.0.254
R1(config-if)# vrrp 1 priority 200
R1(config-if)# vrrp 1 preempt

L’interface Fa0/0 de R1 fonctionnera dans le groupe VRRP n°1 auquel on a associé l’adresse IP virtuelle 192.168.0.254. En plus on a défini une priorité de 200 (la plus grande priorité sera la passerelle effective) et on active le droit de préemption (si R1 tombe en panne, R2 prend le relai… mais is R1 revient, il reprendra sa place, sans préemption, R2 resterait la passerelle).

Configuration de R2

R2(config)# interface FastEthernet0/0
R2(config-if)# vrrp 1 ip 192.168.0.254
R2(config-if)# vrrp 1 priority 100

La configuration de R2 est similaire à celle de R1. Notez que les deux routeurs doivent être configurés dans le même groupe et gérer la même adresse virtuelle, sans quoi il n’y aura soit pas de dialogue VRRP soit un conflit d’adresse.

Vérification

Configuration de C1:

NAME  IP/MASK         GATEWAY       MAC
VPCS1 192.168.0.10/24 192.168.0.254 00:50:79:66:68:00

Test de communication vers 1.1.1.1

VPCS[1]> ping 1.1.1.1
1.1.1.1 icmp_seq=1 timeout
1.1.1.1 icmp_seq=2 ttl=254 time=25.000 ms
1.1.1.1 icmp_seq=3 ttl=254 time=25.000 ms
1.1.1.1 icmp_seq=4 ttl=254 time=32.000 ms
1.1.1.1 icmp_seq=5 ttl=254 time=31.000 ms

Il est intéressant d’analyser la table ARP de C1…

VPCS[1]> arp
00:00:5e:00:01:01 192.168.0.254 expires in 114 seconds

C1 a bien émi une requête ARP pour obtenir l’adresse MAC correspondant à 192.168.0.254, qui correspond bien à une adresse MAC VRRP où le dernier byte est défini par le n° de groupe VRRP.

VPCS[1]> trace 1.1.1.1
trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
 1 192.168.0.1  19.000 ms 10.000 ms 9.000 ms
 2 172.16.0.1   20.000 ms 10.000 ms 10.000 ms
 3 1.1.1.1      20.000 ms 10.000 ms 10.000 ms

On constate ici que R1 assure bien le role de 192.168.0.254

Vérification de la configuration

Vérification du fonctionnement de VRRP sur R1 :

R1#show vrrp
FastEthernet0/0 - Group 1
 State is Master
 Virtual IP address is 192.168.0.254
 Virtual MAC address is 0000.5e00.0101
 Advertisement interval is 1.000 sec
 Preemption enabled
 Priority is 200
 Master Router is 192.168.0.1 (local), priority is 200
 Master Advertisement interval is 1.000 sec
 Master Down interval is 3.218 sec
R1#

Le « State » indique soit Master (actif) soit Backup (en standby). Le reste des informations est explicite.

Que se passe-t-il si R1 tombe en panne …

Test de fonctionnement en mettant Fa0/0 de R1 en shutdown…

R1(config-if)#shutdown
*Mar 1 02:21:46.399: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Master -> Init
*Mar 1 02:21:48.403: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 1 02:21:49.403: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

Réaction immédiate de R2 …

R2#
*Mar 1 02:21:41.727: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Backup -> Master

R2 est bien devenu la passerelle active, vérifions sur C1…

VPCS[1]> ping 1.1.1.1
1.1.1.1 icmp_seq=1 ttl=254 time=26.000 ms
1.1.1.1 icmp_seq=2 ttl=254 time=19.000 ms
1.1.1.1 icmp_seq=3 ttl=254 time=19.000 ms
1.1.1.1 icmp_seq=4 ttl=254 time=19.000 ms
1.1.1.1 icmp_seq=5 ttl=254 time=19.000 ms

VPCS[1]> arp
00:00:5e:00:01:01  192.168.0.254 expires in 7 seconds

Comme pour HSRP, la table ARP de C1 reste idendique. La transition entre R1 et R2 est transparente pour C1.

VPCS[1]> trace 1.1.1.1
trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
 1 192.168.0.2  9.000 ms 9.000 ms 9.000 ms
 2 172.16.0.5   10.000 ms 10.000 ms 10.000 ms
 3 1.1.1.1      10.000 ms 11.000 ms 10.000 ms

Conclusion

Pour une configuration aussi simple, VRRP fonctionne quasiment comme HSRP, il n’y a donc pas grand chose d’autre à ajouter. Les différences majeures se situent dans les rouages du protocole (adresse multicast utilisée, adresse MAC etc.).

Read More

Configuration GLBP : Gateway Load-Balancing Protocol

Après HSRP et VRRP, il est temps de présenter la génération suivante de protocole prenant en charge la redondance de passerelles: GLBP…

Comme son nom l’indique, non seulement il permet de gérer la gestion de passerelles redondantes, mais qui plus est il permet d’équilibrer le trafic entre elles, là ou HSRP et VRRP se contentaient d’en utiliser une et de laisser les autres en standby!

Topologie similaire aux articles concernant HSRP et VRRP. La seule différence étant la présence de deux hôtes afin de tester l’équilibrage de charge.

Nous allons donc ici mettre en place, à nouveau, une redondance entre R1 et R2 et ensuite voir comment les deux hôtes se comportent.

Quelques explications concernant GLBP

Première chose à noter, GLBP est un protocole propriétaire Cisco (sans doute son seul vrai défaut).

Le concept général reste assez proche de ce que nous avons déjà vu. C’est toujours le protocole ARP qui est au coeur du tour de magie. Les passerelles sont configurées pour faire partie d’un groupe GLBP auquel est attribué une adresse IP virtuelle (10.0.0.254 dans le cas présent).

Lorsqu’un des hôtes doit utiliser la passerelle par défaut pour communiquer en dehors de son domaine de diffusion, il émet une requête ARP pour obtenir l’adresse MAC correspondant à 10.0.0.254 … C’est ici que les choses se compliquent … ou du moins s’enrichissent.

Dans le cas de GLBP, un des routeurs sera l’AVG (Active Virtual Gateway), celui qui aura la plus grande priorité (ou la plus grande adresse IP configurée à priorité égale). Les autres routeurs seront les AVF (Active Virtual Forwarders).

L’AVG a pour mission de distribuer la charge entre les différentes passerelles (lui-même et les différents AVF). Pour y arriver, il se chargera de répondre aux requêtes ARP en variant la réponse, indiquant la sienne, celle d’un AVF, celle de l’AVF suivant etc.

Ceci est possible par le fait que chaque routeur faisant partie d’un même groupe GLBP prendra en charge une adresse MAC GLBP différente mais faisant partie d’un même groupe. La structure de l’adresse MAC est la suivante: 0007.b40X.XXYY (où les X symbolisent le n° de groupe allant de 1 à 1023 et les Y l’incrémentation d’une passerelle à l’autre).

Les routeurs communiquent entre eux par multicast (224.0.0.102) en s’échangeant des messages HELLO. Si l’un d’eux manque à l’appel il disparaît de la rotation au niveau des réponses ARP et si c’est l’AVG qui disparaît, c’est le meilleur AVF qui prendra sa place.

Configuration de R1

R1(config)#interface FastEthernet 0/0
R1(config-if)#glbp 10 ip 10.0.0.254
R1(config-if)#glbp 10 preempt
R1(config-if)#glbp 10 priority 150
*Mar 1 00:27:32.447: %GLBP-6-STATECHANGE: FastEthernet0/0 Grp 10 state Standby -> Active
*Mar 1 00:27:42.451: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 10 Fwd 1 state Listen -> Active

L’interface Fa0/0 de R1 est donc configurée ici pour participer au groupe 10 de GLBP. On active le droit de préemption (afin d’autoriser R1 à reprendre sa place le cas échéant), on défini une priorité supérieure à la valeur par défaut (qui est de 100) afin de forcer R1 à devenir l’AVG.

Vérifications …

FastEthernet0/0 - Group 10
  State is Active
    2 state changes, last state change 00:04:25
  Virtual IP address is 10.0.0.254
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.052 secs
  Redirect time 600 sec, forwarder timeout 14400 sec
  Preemption enabled, min delay 0 sec
  Active is local
  Standby is unknown
  Priority 150 (configured)
  Weighting 100 (default 100), thresholds: lower 1, upper 100
  Load balancing: round-robin
  Group members:
    c000.116c.0000 (10.0.0.1) local  <== MAC réelle
  There is 1 forwarder (1 active)
  Forwarder 1
    State is Active
      1 state change, last state change 00:04:15
    MAC address is 0007.b400.0a01 (default) <== MAC Virtuelle
    Owner ID is c000.116c.0000
    Redirection enabled
    Preemption enabled, min delay 30 sec
    Active is local, weighting 100
R1#

Configuration de R2

R2(config)#int FastEthernet 0/0
R2(config-if)#glbp 10 ip 10.0.0.254

Rien de plus simple … ici on a juste assigné l’interface de R2 au même groupe GLBP et bien entendu avec la même adresse IP virtuelle.

Vérification

R2#show glbp
FastEthernet0/0 - Group 10
  State is Standby
    1 state change, last state change 00:01:55
  Virtual IP address is 10.0.0.254
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.120 secs
  Redirect time 600 sec, forwarder timeout 14400 sec
  Preemption disabled
  Active is 10.0.0.1, priority 150 (expires in 8.380 sec)
  Standby is local
  Priority 100 (default)
  Weighting 100 (default 100), thresholds: lower 1, upper 100
  Load balancing: round-robin
  Group members:
    c000.116c.0000 (10.0.0.1)
    c001.116c.0000 (10.0.0.2) local
  There are 2 forwarders (1 active)
  Forwarder 1
    State is Listen
    MAC address is 0007.b400.0a01 (learnt)
    Owner ID is c000.116c.0000
    Time to live: 14398.376 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 10.0.0.1 (primary), weighting 100 (expires in 9.192 sec)
  Forwarder 2
    State is Active
      1 state change, last state change 00:02:05
    MAC address is 0007.b400.0a02 (default)
    Owner ID is c001.116c.0000
    Preemption enabled, min delay 30 sec
    Active is local, weighting 100
R2#

Le Forwarder 1 n’est autre que R1, qui a le rôle d’AVG puisqu’il a une meilleure priorité. Le Forwarder 2 est donc R2. Pour chacun on retrouve son adresse MAC réelle et son adresse MAC virtuelle.

Notez également la méthode d’équilibrage: round-robin, ce qui signifie en gros à chacun son tour !. Il est possible de la modifier, par exemple en fonction de l’adresse MAC de l’hôte (1 hôte = toujours le même forwarder) ou alors en fonction d’une proportion (20% d’un côté et 80% de l’autre par exemple).

Test des hôtes …

Sur C1 …

C1#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/21/48 ms
C1#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.0.254              2   0007.b400.0a01  ARPA   FastEthernet0/0
C1#

Sur C2…

C2#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/25/40 ms
C2#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.0.0.254              1   0007.b400.0a02  ARPA   FastEthernet0/0
C2#

La nuance apportée par GLBP se situe au niveau du contenu des tables ARP de C1 et C2. Comme vous pouvez le constater, pour C1 10.0.0.254 est associé à 0007.b400.0a01 … tandis que sur C2 cette ip virtuelle est associée à 0007.b400.0a02.

L’AVG distribue donc bien le trafic entre les différents forwarders (AVG inclus).

Remarque: Dans cette topologie j’ai utilisé deux routeurs pour remplacer les hôtes virtuels de GNS3 afin de garantir un comportement naturel au niveau du protocole ARP. Pour qu’ils se comportent comme un PC, j’ai désactivé le routage (no ip routing), configuré leur interface Fa0/0 et configuré une passerelle par défaut (ip default-gateway 10.0.0.254) ce qui n’est possible qu’à condition d’avoir désactivé le routage au préalable.

Conclusion

GLBP apporte un élément décisif, permettant de ne pas laisser un équipement « dormir ». Non seulement la redondance est présente (si un forwarder disparaît, il est simplement supprimé de la rotation) mais en plus on profite des ressources de celle-ci!

Il est bien entendu possible d’obtenir une configuration plus poussée, en ajustant les timers par exemple afin d’améliorer la réactivité du protocole etc… Ce sera le sujet d’un prochain article!.

Read More

Configuration PPP Multilink : Agrégation de liaisons sérielles PPP

Qu’est-ce que le PPP Multilink ?

Il s’agit d’un protocole standard qui permet l’agrégation de liaisons PPP en un seul lien PPP. Les liaisons groupées peuvent être de tout type, ISDN, T1, ou tout autre type qui supporte le protocole PPP de base. La configuration multilink doit être effectuée des deux côtés de la liaison, ce qui implique que les différents liens doivent relier les deux mêmes équipements.

La topologie

Pour la démonstration, j’utilise ici deux routeurs interconnectés par deux liaisons sérielles. L’objectif sera donc de les combiner en une interface Multilink que l’on configurera ensuite comme n’importe quelle interface.

La configuration

Pour configurer ce multilink PPP, il faut passer par deux étapes majeures:

1. Créer l’interface virtuelle Multilink
2. Configurer les interfaces sérielles à intégrer dans le bundle.

Configuration sur R1

R1#configure terminal
!!!! Création de l'interface Multilink !!!!
R1(config)#interface multilink 1
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#ip address 192.168.0.1 255.255.255.252
R1(config-if)#exit
R1(config)#
!!!! Intégration de l'interface s0/0 dans le bundle
R1(config)#interface serial 0/0
R1(config-if)#encapsulation ppp
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#
!!!! Intégration de l'interface s0/1 dans le bundle
R1(config)#interface serial 0/1
R1(config-if)#encapsulation ppp
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#

Parmi les détails importants… Il faut bien entendu que le numéro de groupe multilink indiqué dans la configuration des interfaces corresponde. Comme le montre cette configuration, les interfaces S0/0 et s0/1 ne sont pas adressées. Elles ne servent plus que de liaison physique. L’adressage se fait sur l’interface multilink.

Notez également que si vous devez utiliser un protocole de routage, un processus de NAT ou tout autre élément qui interviendrait au niveau du routage de cette interface, c’est l’interface multilink qui devra être référencée.

Configuration sur R2

R2#configure terminal
!!!! Création de l'interface Multilink !!!!
R2(config)#interface multilink 1
R2(config-if)#ppp multilink
R2(config-if)#ppp multilink group 1
R2(config-if)#ip address 192.168.0.2 255.255.255.252
R2(config-if)#exit
R2(config)#
!!!! Intégration de l'interface s0/0 dans le bundle
R2(config)#interface serial 0/0
R2(config-if)#encapsulation ppp
R2(config-if)#ppp multilink
R2(config-if)#ppp multilink group 1
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config)#
!!!! Intégration de l'interface s0/1 dans le bundle
R2(config)#interface serial 0/1
R2(config-if)#encapsulation ppp
R2(config-if)#ppp multilink
R2(config-if)#ppp multilink group 1
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config)#

La configuration est quasiment identique, bien entendu. Notez que le numéro de l’interface multilink ne doit pas être forcément le même que sur l’autre routeur. Il en va de même pour le numéro de groupe multilink. Il n’y a pas non plus de relation entre le numéro de l’interface multilink et le numéro du groupe.

Test de communication

R1#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/12 ms
R1#

Pas de surprise… tout fonctionne!

Vérification de la configuration

R1#show interface serial 0/0
Serial0/0 is up, line protocol is up
 Hardware is GT96K Serial
 MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation PPP, LCP Open, multilink Open
 Link is a member of Multilink bundle Multilink1, loopback not set
 Keepalive set (10 sec)
 CRC checking enabled
 Last input 00:00:09, output 00:00:03, output hang never
 Last clearing of "show interface" counters 00:13:07
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: weighted fair [suspended, using FIFO]
 FIFO output queue 0/40, 0 drops
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 163 packets input, 5310 bytes, 0 no buffer
 Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
 183 packets output, 5770 bytes, 0 underruns
 0 output errors, 0 collisions, 6 interface resets
 0 unknown protocol drops
 0 output buffer failures, 0 output buffers swapped out
 0 carrier transitions
 DCD=up DSR=up DTR=up RTS=up CTS=up
R1#

L’interface fonctionne bien en PPP, et est membre du groupe multilink 1.

R1#show interface multilink 1
Multilink1 is up, line protocol is up
 Hardware is multilink group interface
 Internet address is 192.168.0.1/30
 MTU 1500 bytes, BW 3088 Kbit/sec, DLY 100000 usec,
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation PPP, LCP Open, multilink Open
 Open: IPCP, CDPCP, loopback not set
 Keepalive set (10 sec)
 DTR is pulsed for 2 seconds on reset
 Last input 00:00:31, output never, output hang never
 Last clearing of "show interface" counters 00:17:23
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue: 0/40 (size/max)
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 29 packets input, 5944 bytes, 0 no buffer
 Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
 29 packets output, 6266 bytes, 0 underruns
 0 output errors, 0 collisions, 1 interface resets
 0 unknown protocol drops
 0 output buffer failures, 0 output buffers swapped out
 0 carrier transitions
R1#

Remarquez ici la bande passante de l’interface qui reprend la valeur combinée des deux interfaces physiques (2x 1544kbits/s).

R1#show ppp multilink

Multilink1
 Bundle name: R2
 Remote Endpoint Discriminator: [1] R2
 Local Endpoint Discriminator: [1] R1
 Bundle up for 00:26:33, total bandwidth 3088, load 1/255
 Receive buffer limit 24000 bytes, frag timeout 1000 ms
 0/0 fragments/bytes in reassembly list
 0 lost fragments, 37 reordered
 0/0 discarded fragments/bytes, 0 lost received
 0x5C received sequence, 0x5C sent sequence
 Member links: 2 active, 0 inactive (max not set, min not set)
 Se0/0, since 00:26:34
 Se0/1, since 00:26:03
No inactive multilink interfaces
R1#

Ici vous retrouvez l’état du lien multilink. vous retrouvez les interfaces qui font partie du bundle, ainsi que les informations relatives au nom de l’équipement distant et des compteurs pour le nombre de paquets transmis, détruits, …

Conclusion

La configuration de base d’une liaison multilink PPP est assez simple et intuitive. Elle permet en outre d’augmenter la bande passante de la liaison sans rendre la topologie plus complexe. Notez toutefois qu’il s’agit ici d’une configuration tout ce qu’il y a de plus basique, il est bien entendu possible de configurer l’authentification, ou encore de paramétrer la répartitions des données sur les liens.

Read More