[Dr.WoW] [No.52] Explication des Techniques VGMP -Partie 1

73 0 0 0

La combination de VGMP et de VRRP s’applique uniquement aux réseaux utilisant des pare-feu connectés à des périphériques de couche 2. Par conséquent, si un pare-feu se connecte à un routeur ou si un pare-feu accède de manière transparente à un réseau (les interfaces de service fonctionnent dans la couche 2), quelle technique un groupe VGMP utilise-t-il en réponse? Dans cette section, je vais révéler les techniques de groupe VGMP restantes pour tout le monde.


1 - Technique VGMP pour les connexions pare-feu / routeur


Dans la figure 1-1, les interfaces de service en amont et en aval (upstream and downstream) de deux pare-feu fonctionnent dans la couche 3 et sont connectées à des routeurs. Les pare-feu et les routeurs exécutent OSPF entre eux. Comme les périphériques en amont et en aval ne sont pas des commutateurs de couche 2, le groupe VGMP ne peut pas utiliser de groupes VRRP. Par conséquent, la technique que les groupes VGMP utiliseront pour surveiller les défaillances est la surveillance directe de l'état de l'interface. Ceci est accompli en ajoutant directement des interfaces aux groupes VGMP. En cas de défaillance de l'une des interfaces d'un groupe VGMP, le groupe VGMP perçoit directement le changement d'état de l'interface et diminue donc sa propre priorité.


Figure 1-1 Mise en réseau des pare-feu connectés aux routeurs en amont et en aval (upstream and downstream)


569856516b029.png


Les étapes de configuration de la surveillance directe d'interface à l'aide de groupes VGMP sont décrites dans le tableau 1-1 (comme indiqué à l'aide de la méthode de basculement actif / en veille (active/Standby failover) de la mise en veille à chaud (hot standby).)


Tableau 1-1 Configuration de la surveillance directe d'interface à l'aide de groupes VGMP



Article

Configuration de FW1

Configuration de FW2

Configurez le groupe VGMP pour surveiller directement l'interface GE1/0/1.

interface GigabitEthernet 1/0/1

 ip address 10.1.1.2 255.255.255.0

 hrp track active

interface GigabitEthernet 1/0/1

 ip address 10.1.2.2 255.255.255.0

 hrp track standby

Configurez le groupe VGMP pour surveiller directement l'interface GE1/0/3.

interface GigabitEthernet 1/0/3

 ip address 10.2.1.2 255.255.255.0

 hrp track active

interface GigabitEthernet 1/0/3

 ip address 10.2.2.2 255.255.255.0

 hrp track standby

Configurez la fonction d'ajustement automatique des coûts.

hrp ospf-cost adjust-enable

hrp ospf-cost adjust-enable

Configurez l'interface de pulsation (heartbeat).

hrp interface GigabitEthernet 1/0/2 

hrp interface GigabitEthernet 1/0/2 

Activez la fonction hot standby .

hrp enable

hrp enable


Remarque:

Si la méthode de partage de charge hot standby est utilisée, il suffit d'exécuter les commandes hrp track active et hrp track standby sur chaque interface de service et d'ajouter les interfaces de service aux groupes VGMP actif et standby.


[Question de Dr. Wow] Ici, les lecteurs curieux peuvent se demander: est-ce que nous n’ajoutons pas d’interfaces aux groupes VGMP pour permettre à un groupe VGMP de contrôler les états des interfaces? Pourquoi la commande hrp track et non vgmp track? Ceci est dû à ce que nous avons discuté dans la section ci-dessus concernant les paquets VGMP et HRP étant tous deux encapsulés avec un en-tête VRRP et un en-tête VGMP (la seule différence étant que les paquets HRP doivent également être encapsulés avec un en-tête HRP). Par conséquent, lorsque les développeurs ont conçu cette commande, ils ont utilisé le paramètre hrp. Cette pratique a continué d'être utilisée jusqu'à aujourd'hui.


Une fois la configuration terminée, nous pouvons exécuter la commande display hrp state sur FW1, ce qui nous permet de voir que les interfaces GE1 / 0/1 et GE1 / 0/3 ont été ajoutées au groupe actif et sont surveillées par le groupe actif.


HRP_A<FW1> display hrp state

The firewall's config state is: ACTIVE

 

Current state of interfaces tracked by active:

             GigabitEthernet0/0/1 : up 

             GigabitEthernet0/0/3 : up 

L'exécution de l'affichage de la commande hrp sur FW2 montre que les interfaces GE1 / 0/1 et GE1 / 0/3 ont été ajoutées au groupe standby VGMP et qu'elles sont surveillées par le groupe.


HRP_S<FW2> display hrp state

The firewall's config state is: Standby

 

Current state of interfaces tracked by standby:

             GigabitEthernet0/0/1 : up 

             GigabitEthernet0/0/3 : up 

L'exécution de la commande display hrp group sur FW1 indique que l'état du groupe VGMP actif est actif, sa priorité est 65001 et que le groupe standby VGMP n'a pas été activé.


HRP_A<FW1> display hrp group

 

Active group status:

   Group enabled:         yes

   State:                 active

   Priority running:      65001

   Total VRRP members:    0

   Hello interval(ms):    1000

   Preempt enabled:       yes

   Preempt delay(s):      30

   Peer group available:  1

   Peer's member same:    yes

 Standby group status:

   Group enabled:         no

   State:                 initialize

   Priority running:      65000

   Total VRRP members:    0

   Hello interval(ms):    1000

   Preempt enabled:       yes

   Preempt delay(s):      0

   Peer group available:  0

   Peer's member same:    yes


L'exécution de la commande display hrp group sur FW2 indique que l'état du groupe standby VGMP est standby, que sa priorité est 65000 et que le groupe VGMP actif n'a pas été activé.


HRP_S<FW2> display hrp group

 

Active group status:

  Group enabled:         no

   State:                 initialize

   Priority running:      65001

   Total VRRP members:    0

   Hello interval(ms):    1000

   Preempt enabled:       yes

   Preempt delay(s):      30

   Peer group available:  1

   Peer's member same:    yes

 Standby group status:

   Group enabled:         yes

   State:                  standby

   Priority running:      65000

   Total VRRP members:    2

   Hello interval(ms):    1000

   Preempt enabled:       yes

   Preempt delay(s):      0

   Peer group available:  1


Nous pouvons donc en conclure qu'après l'achèvement de la configuration, le groupe VGMP de FW1 est à l'état actif et que FW1 est devenu le périphérique principal. L'état du groupe VGMP de FW2 est à l'état standby et FW2 est devenu le périphérique de sauvegarde.


Dans la vue d'ensemble de Hot Standby, j'ai indiqué que si nous souhaitons que le trafic de PC1 vers PC2 soit transmis par FW1, nous devons augmenter manuellement le coût OSPF de la liaison de FW2 (R1—> FW2—> R2). Cependant, que se passe-t-il s'il est inconvenient / impossible de configurer les routeurs R1 ou R2 en amont et en aval? Cette situation nécessite que nous utilisions la fonction de direction du trafic du groupe VGMP du pare-feu pour diriger automatiquement le trafic sur le périphérique principal. Cela peut être fait car le pare-feu ajustera automatiquement les coûts OSPF en fonction de l'état du groupe VGMP (la commande est hrp ospf-cost adjust-enable). Une fois cette fonction activée, si un groupe VGMP actif se trouve sur un pare-feu, celui-ci annoncera les itinéraires avec des coûts normaux. Si le groupe VGMP d'un pare-feu est à l'état standby, il augmentera les coûts de 65 500 (valeur par défaut pouvant être ajustée) lors de la publicité des routes.


Remarque

S'il s'agit d'un réseau de partage de charge (load sharing network), étant donné qu'il existe des groupes VGMP actifs sur les deux pare-feu, chaque pare-feu annoncera les routes avec des coûts normaux.


Sur la gauche de la figure 1-1, le pare-feu principal FW1 (l'état de son groupe VGMP est actif) annonce normalement les routes, et le périphérique de sauvegarde FW2 (son groupe VGMP est à l'état standby) augmentera donc les coûts de 65500 lorsque les routes publicitaires aux dispositifs amont et aval. Par conséquent, du point de vue de R1, le coût OSPF d'utilisation de FW1 pour accéder à PC2 est 1 + 1 + 1 = 3, tandis que le coût OSPF d'utilisation de FW2 pour accéder à PC2 est de 65501 + 1 + 1 = 65503. Comme le routeur choisit le chemin avec le coût le plus bas lors du transfert du trafic (R1—> FW1—> R2), le trafic provenant du PC1 de l'intranet vers le PC2 du réseau externe sera transféré via le périphérique principal FW1.


Nous pouvons voir dans la table de routage de R1 que le prochain saut (next hop) de paquets allant au réseau 1.1.1.0 est l'adresse 10.1.1.2 de GE1 / 0/1 de FW1.


[R1] display ip routing-table

Route Flags: R - relay, D - download to fib

------------------------------------------------------------------------------

Routing Tables: Public

         Destinations : 11       Routes : 11      

 

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

 

1.1.1.0/24     OSPF    10   3            D   10.1.1.2        GigabitEthernet0/0/1


En cas de défaillance de l'une des interfaces de service de FW1, les groupes VGMP des deux pare-feu sont soumis au état de commutation . Après l'état de commutation, le groupe VGW de FW2 passe en mode actif et FW2 devient le périphérique principal. L'état du groupe VGMP de FW1 passera en standby et FW1 deviendra le périphérique de sauvegarde. FW2 annonce normalement les routes (il n'augmente pas la valeur du coût), tandis que le coût de l'itinéraire annoncé par FW1 passe à 65500. Pour R1, le chemin d'accès à PC2 à l'aide de FW1 est bloqué (car l'interface amont de FW1 est défaillante) et l'itinéraire sur PC2 via FW2 est accessible et le coût est de 3, de sorte que le trafic provenant de l’intranet PC1 accédant à PC2 sur le réseau externe sera transféré via le nouveau périphérique principal FW2.


Dans la table de routage de R1, nous pouvons également constater que le prochain saut de paquets acheminant vers le segment de réseau de destination 1.1.1.0 a été remplacé par l'adresse 10.1.2.2 de GE1 / 0/1 de FW2.


[R1] display ip routing-table

Route Flags: R - relay, D - download to fib

------------------------------------------------------------------------------

Routing Tables: Public

         Destinations : 11       Routes : 11      

 

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

 

1.1.1.0/24     OSPF    10   3            D   10.1.2.2        GigabitEthernet0/0/2


2- La technique VGMP lorsque les pare-feu accèdent et se connectent de manière transparente à des commutateurs


Dans la figure 1-2, les interfaces de service en amont et en aval de deux pare-feu fonctionnent toutes les deux dans la couche 2 et sont connectées à des commutateurs. Comme les interfaces de service des pare-feu fonctionnent dans la couche 2, elles ne possèdent pas d'adresse IP. Les groupes VGMP n'ont donc aucun moyen d'utiliser des groupes VRRP ou de surveiller directement les états d'interface. Par conséquent, la technique de surveillance des pannes utilisée par les groupes VGMP consiste à surveiller les états d'interface à l'aide d'un VLAN. Ceci est accompli en ajoutant des interfaces de service de couche 2 à un VLAN, le groupe VGMP surveillant le VLAN. Lorsqu'une interface d'un groupe VGMP échoue, le groupe VGMP perçoit ce changement d'état de l'une de ses interfaces via le VLAN et diminue donc sa propre priorité.


Figure 1-2 Mise en réseau avec un pare-feu pour accéder et se connecter de manière transparente aux commutateurs


5698567261880.png

Le tableau 1-2 indique les étapes de configuration utilisées pour permettre à un groupe VGMP d'utiliser un VLAN pour surveiller les états d'interface (active/ standby failover).


Tableau 1-2 Configuration de l'utilisation d'un VLAN par les groupes VGMP pour surveiller les interfaces (active/ standby failover).


Item

Configuration FW1

Configuration FW2

Ajoutez des interfaces de service de couche 2 dans le même VLAN et configurez le groupe VGMP pour surveiller le VLAN..

vlan 2

 port GigabitEthernet 1/0/1

port GigabitEthernet 1/0/3 

hrp track active

vlan 2

 port GigabitEthernet 1/0/1

port GigabitEthernet 1/0/3

hrp track standby

Configurez l'interface de pulsation (heartbeat)

hrp interface GigabitEthernet 1/0/2

hrp interface GigabitEthernet 1/0/2

Activer la fonction hot standby 

hrp enable

hrp enable


REMARQUE  Lorsque les interfaces de service des pare-feu fonctionnent dans la couche 2 et sont connectées à des commutateurs, la méthode de partage de charge de hot standby n'est pas prise en charge. En effet, si vous utilisiez la méthode de partage de charge, les VLAN seraient activés sur les deux périphériques et chaque périphérique serait en mesure de transférer le trafic, de sorte que l'ensemble du réseau formerait une boucle.


Une fois la configuration terminée, l'état du groupe VGMP de FW1 est actif et FW1 devient le périphérique principal. L'état du groupe VGMP de FW2 est standby et FW2 devient le périphérique de sauvegarde. Comme les interfaces de service des pare-feu fonctionnent dans la couche 2, les pare-feu eux-mêmes ne peuvent pas exécuter OSPF. Par conséquent, les groupes VGMP ne peuvent pas diriger le trafic en amont et en aval en utilisant les coûts OSPF. Cependant, les VGMP peuvent contrôler si leur VLAN transfère le trafic pour s'assurer que le trafic est dirigé sur le périphérique principal. Lorsqu'un groupe VGMP est actif, le VLAN du groupe est en mesure de transférer le trafic. Lorsque l'état d'un groupe VGMP est standby, le VLAN du groupe est désactivé et il ne peut pas transférer le trafic. Un contrôle VGMP indiquant si son trafic VLAN transfère ne doit pas être configuré séparément; l'ajout d'un VLAN au groupe VGMP est tout ce qui est requis.


Comme le montre la figure 1-2, dans des circonstances normales, le VLAN du périphérique principal (FW1; son groupe VGMP est actif) est activé et il peut transférer le trafic. Le VLAN du périphérique de sauvegarde (FW2; son groupe VGMP est standby) est désactivé et il ne peut pas transférer le trafic. Par conséquent, le trafic entre PC1 et PC2 sera tous transmis par le périphérique principal FW1.


Après une défaillance de l'interface de service sur le FW1, les groupes VGMP des deux pare-feu vont subir une commutation d'état. Lorsque l'état du groupe VGMP du FW1 bascule de l'état actif à l'état standby, l'état des interfaces normales du réseau local virtuel (VLAN) du groupe devient down puis up. Cela force les commutateurs amont et aval à mettre à jour leurs propres tables d'adresses MAC pour mapper l'adresse MAC de destination sur le port Eth0 / 0/2, ce qui dirige le trafic sur FW2.


  • x
  • Standard:

Responder

envoyer
Connectez-vous pour répondre. Se connecter | Enregistrer

Remarque : Afin de protéger vos droits et intérêts légitimes, ceux de la communauté et des tiers, ne divulguez aucun contenu qui pourrait présenter des risques juridiques pour toutes les parties. Le contenu interdit comprend, sans toutefois s'y limiter, le contenu politiquement sensible, le contenu lié à la pornographie, aux jeux d'argent, à l'abus et au trafic de drogues, le contenu qui peut divulguer ou enfreindre la propriété intellectuelle d'autrui, y compris les secrets professionnels, les marques commerciales, les droits d'auteur et les brevets, ainsi que la vie privée personnelle. Ne partagez pas votre nom d'utilisateur ou votre mot de passe avec d'autres personnes. Toutes les opérations effectuées à partir de votre compte seront considérées comme vos propres actions, et toutes les conséquences en découlant vous seront imputées. Pour plus de détails, voir « Politique de confidentialité ».
Si le bouton de la pièce-jointe n'est pas disponible, mettez à jour Adobe Flash Player à la dernière version.

Connectez-vous pour participer à la communication et au partage

S'identifier
Réponse rapide Accéder au haut de page