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

Vous pouvez configurer la redondance du service d’abonné M :N sur un serveur DHCP s’exécutant 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 obtenir une redondance BNG au niveau du châssis MX Series pour les abonnés haut débit, le périphérique MX Series de secours exécutant le serveur DHCP doit posséder toutes les informations faisant autorité sur l’abonné. Le serveur de sauvegarde garantit un service d’abonné ininterrompu lorsque vous redémarrez ou remplacez le serveur DHCP principal, ou lorsque le serveur principal présente des défaillances matérielles telles qu’une défaillance de la liaison d’accès, une défaillance de la carte de ligne d’accès ou une défaillance du châssis.

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

Dans la redondance de service abonné 1:1, un serveur DHCP (serveur DHCP principal) est sauvegardé sur un autre serveur DHCP (serveur DHCP de secours) pour les interfaces abonnés. Le serveur principal et le serveur de secours ont le même ensemble de configurations. À partir de la version 24.4R1 de Junos OS, la fonctionnalité de redondance DHCP sur châssis pour les modèles d’accès MX480 offre la fonctionnalité supplémentaire de redondance active de bail 1:1 basée sur le châssis, en dessous de la limite de quantification (ALQ/BLQ) pour les interfaces d’abonnés sous-jacentes non participantes, sans qu’il soit nécessaire de configurer la découverte de topologie. Cette fonctionnalité est prise en charge sur les piles et les configurations DHCP, BBE et DHCP non-BBE sans découverte de topologie, pour 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 Stack et Double Stack.
• Modèle d’accès pseudo-filaire 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.

  Pour plus d’informations sur la configuration, reportez-vous à Exemple de configuration : ALQ/BLQ pour la redondance DHCP 1:1.

Dans la redondance du service d’abonné M :N, plusieurs (M) serveurs DHCP (serveur DHCP principal) sont sauvegardés sur plusieurs (N) serveurs DHCP (serveur DHCP de secours). La redondance du service d’abonné M :N nécessite la découverte de topologie pour mapper les interfaces entre les serveurs homologues. Pour répliquer les abonnés sur l’interface, la requête de location active 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 appropriée met l’abonné sous tension sur le serveur de sauvegarde. Ensuite, l’adresse DHCP et les informations de bail sont synchronisées entre les serveurs. Si les informations relatives au bail ou à l’adresse changent, le BNG de sauvegarde passe par la machine d’état appropriée pour activer ou désactiver l’état de l’abonné.

Actuellement, la redondance des services d’abonnés sur DHCP prend en charge le protocole de redondance pseudowire et la découverte de topologie sur pseudowire entre les serveurs homologues. La redondance des services d’abonnés 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 IPoE DHCP, VLAN statique	M :N avec état avec VRRP et leasequery actif	Pour la prise en charge dynamique des VLAN, il faut utiliser PWHT
Relais IPoE DHCP sur PWHT	M :N avec requêtede bail active
Serveur IPoE DHCP sur PWHT	M :N dynamique	Inclut la prise en charge des 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 d’un circuit L2 PWHT IP/MPLS PWHT en mode client-relais serveur.

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

1. La liaison pseudowire active reçoit les paquets du client.
2. L’abonné se connecte au BNG principal.
3. Le BNG principal synchronise les détails de liaison de l’abonné avec le 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, la liaison pseudowire de secours devient active.
5. Le BNG de sauvegarde reçoit les paquets du client.
6. Comme le BNG de sauvegarde était déjà en mode veille, il peut renouveler ou lier à nouveau les paquets pour une requête de bail active et synchroniser les abonnés.

Pour la redondance du service d’abonnés M :N, vous devez sauvegarder l’interface d’abonnés sur le serveur DHCP de sauvegarde. L’interface peut avoir différents noms. Le serveur DHCP principal utilise la découverte de topologie pour mapper les interfaces entre les serveurs DHCP homologues.

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 principal doit répondre à la requête avec tous les abonnés ayant des adresses Gi ou des adresses 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, il répond à la requête de la nouvelle table comme suit :

• Lorsque le serveur envoie une requête, il vérifie la configuration de découverte de topologie et envoie une requête basée sur l’adresse GI ou l’adresse de lien avec l’adresse IP de l’interface.
• Lorsque le serveur reçoit une requête basée sur l’adresse GI ou l’adresse de lien, le serveur vérifie la configuration existante du serveur. Si une configuration de requête de location active est disponible, le serveur répond à la requête en fonction de la nouvelle base de données.

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