Redondance du service d’abonné M :N sur le serveur DHCP

Vous pouvez configurer la redondance du service d’abonné M :N sur un serveur DHCP exécuté sur la passerelle réseau haut débit (BNG) MX Series. Le serveur DHCP conserve une quantité considérable d’informations officielles concernant l’adresse qu’il a louée aux clients DHCP. Pour atteindre MX Series redondance BNG au niveau du châssis pour les abonnés haut débit, le périphérique de MX Series de secours exécutant le serveur DHCP doit posséder toutes les informations abonné faisant autorité. Le serveur de sauvegarde garantit un service d’abonné ininterrompu lorsque vous redémarrez ou remplacez le serveur DHCP principal, ou que le serveur principal présente des défaillances matérielles telles que des défaillances de liaison d’accès, de carte de ligne d’accès ou de châssis.

La redondance du service d’abonnés sur le serveur DHCP se concentre sur la synchronisation abonné entre les serveurs homologues à l’aide de LeaseQuery actif. La mise à jour en direct des informations de liaison entre les deux serveurs pairs permet de maintenir les serveurs en mode veille à chaud.

Dans la redondance 1:1 du service d’abonné, un serveur DHCP (serveur DHCP principal) est sauvegardé sur un autre serveur DHCP (serveur DHCP de secours) pour les interfaces d’abonné. Le serveur principal et le serveur de sauvegarde ont le même ensemble de configurations. À partir de la version 24.4R1 de Junos OS, la fonctionnalité de redondance DHCP basée sur châssis pour les modèles d’accès MX480 prend en charge la redondance ALQ/BLQ (Active Lease Query/Below Limit of Quantification) 1:1 basée sur châssis pour les interfaces d’abonnés sous-jacents non participantes. Cette fonctionnalité est prise en charge sur les piles et les configurations DHCP, y compris DHCP BBE et non-BBE, dans les scénarios suivants :

• Gestion des abonnés activée
• Gestion des abonnés désactivée
• IP Demux/IP Demux Lite
• Session unique double pile et double pile
• Modèle d’accès Pseudo Wire Interface PS (circuit L2 / EVPN VPWS / L2VPN)
• Modèle d’accès VRRP Interfaces GE, XE et AE
• Instance de routage autre que celle par défaut

• Relais DHCP et serveur DHCP.

  Voir Exemple de configuration : ALQ/BLQ pour la redondance DHCP 1:1 pour plus de détails sur la configuration.

Dans le service M :N abonné redondance plusieurs (M) serveurs DHCP (serveur DHCP primaire) sont sauvegardés sur plusieurs (N) serveurs DHCP (serveur DHCP de secours). Pour répliquer les abonnés sur l’interface, le leasequery actif utilise Gi-Address query pour IPv4 et link-address query pour IPv6.

Lorsque les abonnés reçoivent la réponse leasequery, la machine d’état concernée met l’abonné sous tension sur le serveur de sauvegarde. Ensuite, l’adresse DHCP et les informations de bail se synchronisent entre les serveurs. Si les informations de bail ou d’adresse changent, la BNG de secours passe par la machine d’état concernée pour allumer ou désactiver l’état de l’abonné.

Actuellement, la redondance des services d’abonné sur DHCP prend en charge le protocole de redondance pseudowire. La redondance des services d’abonné prend en charge les protocoles répertoriés dans le Tableau 1.

Tableau 1 : Redondance des services d’abonnés

Protocoles pris en charge	Services d’abonnés Mode de redondance	Détails supplémentaires
Relais DHCP IPoE, VLAN statique	Dynamique M :N avec VRRP et leasequery actif	Pour la prise en charge dynamique des VLAN, il faut utiliser PWHT
Relais DHCP IPoE sur PWHT	Dynamique M :N avec leasequery actif
Serveur DHCP IPoE sur PWHT	M :N avec état	Inclut la prise en charge de VLAN dynamiques ou statiques

La figure 1 montre la topologie du PWHT IP/MPLS basé sur un circuit L2 en mode client-serveur.

La figure 2 montre la topologie du PWHT IP/MPLS basé sur un circuit L2 en mode client-relais-serveur.

En mode client-serveur et en mode client-relais-serveur, les serveurs BNG utilisent la connexion TCP pour les requêtes de bail actives afin de synchroniser les détails de liaison. La redondance du service d’abonné sur le serveur DHCP se produit dans l’ordre suivant :

1. Le lien pseudowire actif reçoit des paquets du client.
2. L’abonné se connecte au BNG primaire.
3. La BNG principale synchronise les détails de la liaison de l’abonné avec la BNG de sauvegarde à l’aide d’une connexion TCP.
4. Lorsque vous redémarrez ou remplacez le BNG principal ou que le BNG principal présente une défaillance du châssis, le lien pseudowire de secours devient actif.
5. Le BNG de secours reçoit des paquets du client.
6. Comme le BNG de sauvegarde était déjà en mode de veille, il peut renouveler ou lier à nouveau des paquets pour une requête de bail active et synchroniser également les abonnés.

Pour la redondance du service d’abonné M :N, vous devez sauvegarder l’interface des abonnés sur le serveur DHCP de sauvegarde. L’interface peut avoir différents noms.

Le serveur DHCP utilise la requête d’adresse Gi ou d’adresse de lien pour répliquer les informations des abonnés sur le serveur DHCP de secours. Dans le serveur, les clients ayant une adresse Gi ou une adresse de lien différente apparaissent sur une seule interface, donc le BNG primaire doit répondre à la requête avec tous les abonnés ayant des adresses Gi ou une adresse de lien différentes sur l’interface. Pour prendre en charge cette fonctionnalité, le serveur crée une nouvelle table pour stocker les clients en fonction de l’interface entrante. Lorsque le serveur reçoit une requête d’adresse Gi ou d’adresse de lien, le serveur vérifie la configuration existante du serveur. Si une configuration leasequery active est disponible, le serveur répond à la requête en fonction de la nouvelle base de données.

La requête de bail active peut être effectuée entre le relais vers le relais ou le serveur vers le serveur à tout moment. Le serveur DHCP peut ne pas accepter simultanément la connexion du serveur ou du relais homologue, de sorte que la configuration du serveur DHCP peut être soit active-leasequery, soit allow-active-leasequery, allow-bulk-leasequery ou allow-leasequery.