Utiliser le guide de configuration pour l'intégration DRA multifournisseur

Introduction

Ce document décrit les étapes de configuration ainsi que les meilleures pratiques pour l'intégration DRA multifournisseur avec le cluster PCRF Cisco Policy Suite (CPS).

Conditions préalables

Exigences

Cisco recommande aux ingénieurs travaillant avec cette solution de se familiariser avec les sujets suivants :

• système d'exploitation Linux
• Plate-forme et architecture de cluster Cisco Policy Suite (CPS)
• Fonction PCRF (Policy and Charging Rules Function)
• Utilisation de l'éditeur Vi
• Outil d’analyse réseau Wireshark

Composants utilisés

Les informations contenues dans ce document sont basées sur la version CPS 25.1 et la version 8.10 d'AlmaLinux.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Étapes de configuration et meilleures pratiques

Étape 1: Déterminer le mode de connectivité DRA (homologues entrants et sortants)

• Homologues entrants : Le PCRF est configuré pour accepter les demandes de connexion des homologues Diameter désignés. Le noeud homologue initie la requête d'échange de capacités de diamètre (CER) au PCRF.
• Homologues sortants : Le PCRF est configuré pour initier le CER vers ses homologues.

Meilleure pratique :
Pour la plupart des intégrations DRA multifournisseurs, configurez le DRA en tant qu'homologue entrant, où le DRA initie le CER vers le PCRF.

Étape 2: Configurer l'homologue entrant dans Policy Builder

Dans l'interface utilisateur graphique du générateur de politiques, configurez le nom d'homologue entrant et le domaine homologue, en faisant référence aux tables Homologues entrants et Domaines.

Ces paramètres peuvent être configurés sous Homologues entrants :

Table des homologues

Paramètre	Description
Pairs	Définit les noms d'homologues autorisés à établir des connexions vers PCRF.
Nom d'hôte local	Identifie le nom d'hôte local du Policy Director (équilibreur de charge) qui identifie et autorise une connexion entrante de l'homologue.
Numéro d'instance	Indique le numéro attribué au processus Policy Server (QNS) qui établit une connexion avec l'homologue sortant. Remarque : Le nom d'hôte local et le numéro d'instance doivent être spécifiés si l'intention est qu'un seul processus Policy Server (QNS) sur Policy Builder (équilibreur de charge) autorise/lance une connexion avec ledit homologue. Sinon, le numéro d'instance peut être maintenu à 0. Dans ce cas, tous les processus Policy Server (QNS) sur Policy Director (équilibreur de charge) tentent/autorisent la connexion avec l'homologue. La valeur par défaut est 0.
Classement	Priorité attribuée à cet homologue pour la transmission d'une requête initiée par PCRF. Les plus la valeur d'évaluation est élevée, plus la priorité attribuée à l'homologue est élevée. La valeur par défaut est 1.
Plage de ports	Doit être spécifié uniquement lorsque la connexion de transport sous-jacente est SCTP et non obligatoire lorsque le même protocole est TCP .
Délai de réponse	Cisco recommande de ne pas utiliser ce paramètre.
Modèle de nom	La valeur VP d’origine-hôte A dans CER doit être validée par rapport à ce modèle dans ordre d'établissement de la connexion. Si ce n'est pas le cas, le CER est silencieusement ignorée et la connexion TCP est réinitialisée par PCRF. La vérification du modèle de nom n'a pas lieu si l'option Accepter un homologue non défini décrit dans Configuration de la pile de diamètres.  Le modèle de nom doit être l'expression régulière Java standard syntaxe décrite ici.

Tableau des domaines

Paramètre	Description
Domaines	Définit les domaines homologues autorisés à établir des connexions vers PCRF.
Type de pair	Non utilisé avec les domaines entrants.
Protocole de traitement	Mappage entre le nom du domaine et la logique PCRF spécifique qui peut être appliqué pour le message, pour plus d'informations sur le protocole de traitement. Lorsqu'une pile de diamètre avec un domaine de diamètre est importée sans protocole attribué, il prend la valeur par défaut GX_TGPP .
Classement	Priorité attribuée à ce domaine pour la transmission d'une requête initiée par PCRF. Ceci est uniquement utilisé avec le protocole de traitement SY_PRIME. La valeur par défaut est 0. Plus la valeur d'évaluation est faible, plus la priorité attribuée au domaine est élevée. Par exemple, un domaine ayant Rating=10 est utilisé après un domaine ayant Note = 1.
Alias de statistiques	Quelles que soient les statistiques qui sont générées pour le royaume respectif obtient le nom configuré dans l'alias de statistiques ajouté à ces statistiques. Ceci s'applique uniquement aux statistiques mbean com.broadhop.message.
Modèle de nom	Domaine d'origine Une valeur VP dans CER doit être validée par rapport à ce modèle dans ordre de traitement du message entrant. Si cela ne se produit pas, le message est ignoré en silence et la connexion TCP est réinitialisée par PCRF. Le modèle de nom doit être l'expression régulière Java standard syntaxe décrite ici.

Meilleure pratique : 

Pour un contrôle plus granulaire, configurez des entrées spécifiques d'homologue et de domaine de gestion des identités selon les besoins, et pour autoriser la création d'homologue uniquement à partir d'homologues spécifiques, décochez la case Accepter l'homologue non défini.

Exemple :

Figure 1 : Table des homologues entrants

Figure 1 : Table des homologues entrants

Étape 3: Configuration de l'adresse IP hôte AVP

Le protocole AVP Diameter Host-IP-Address communique l'adresse IP du noeud lors des échanges CER/CEA (RFC 3588) pour les connexions SCTP. Dans Cisco CPS PCRF, cette adresse est par défaut l'adresse IP de l'interface interne, qui est différente de l'adresse IP du service Diameter attendue pour certains fournisseurs DRA.

Dans Cisco CPS PCRF, vous pouvez utiliser l'adresse IP virtuelle de l'équilibreur de charge (LbVIP) ou l'adresse IP physique des machines virtuelles de l'équilibreur de charge comme adresse IP de point d'extrémité source-diamètre.

Par défaut, l'adresse IP de l'interface interne est communiquée en tant qu'adresse IP d'hôte dans les messages CER/CEA de diamètre, comme indiqué dans l'image, où l'on peut voir que l'adresse IP source dans la capture est différente de l'adresse IP vue dans l'adresse IP d'hôte AVP.

Figure 2 : Message CEA avec IP interne comme adresse IP d'hôte

Figure 2 : Message CEA avec IP interne comme adresse IP d'hôte

Bien que ce protocole AVP ne soit pas obligatoire lorsque le protocole TCP est utilisé comme protocole de transport (reportez-vous à la RFC 3588), certains fournisseurs de DRA se réfèrent à ce protocole AVP lors de l'établissement de la connexion Diameter et s'attendent à ce que le service Diameter IP de PCRF soit utilisé à la place du protocole IP interne. Si cette attente n'est pas satisfaite, les pairs ne parviendront pas à établir.

Meilleure pratique :

Pour annoncer l'adresse IP du service Diameter dans l'AVP d'adresse IP d'hôte à partir de PCRF, mettez à jour le fichier /etc/hosts avec une entrée mappant le nom de domaine complet (FQDN) source PCRF (tel que défini dans les points d'extrémité locaux de la pile Diameter) à l'adresse IP souhaitée.

Pour mettre à jour des entrées d'hôtes supplémentaires dans le PCRF CPS basé sur Openstack :

• Vérifiez que le cluster CPS est à l'état déployé.

   curl -X GET installer le système API.

• Récupérez et mettez à jour le fichier additional-hosts.yaml via l'API REST.

   curl -X GET http://<IP Cluster Manager>:8458/api/system/config/additional-hosts >> additional-hosts.yaml

• Appliquez les modifications à l'aide des commandes curl comme décrit dans la documentation du produit.

   curl -X PUT système API hôtes supplémentaires -H "Content-Type : application/yaml" —data-binary @additional-hosts.yaml

   

À la fin de cet appel d'API, Cluster Manager est configuré avec le nouveau fichier /etc/hostsfile et toutes les autres machines virtuelles déployées sont alors mises à jour de manière asynchrone.

Pour mettre à jour les entrées d'hôtes supplémentaires dans CPS PCRF basé sur Vmware :

• Ajoutez l'entrée dans le fichier AdditionalHosts.csv situé dans le chemin /var/qps/config/deploy/csv/
• Pour importer des modifications dans la machine virtuelle Cluster Manager :

    /var/qps/install/current/scripts/import/import_deploy.sh

• Appliquer les modifications à partir du Gestionnaire de cluster :

   /var/qps/install/current/scripts/build_all.sh

   /var/qps/install/current/scripts/upgrade/reinit.sh

Exemple :

Figure 3 : Diamètre de l'interface utilisateur graphique Points d'extrémité locaux

Figure 3 : Diamètre de l'interface utilisateur graphique Points d'extrémité locaux

Exemple d'entrée /etc/hosts :

10.x.x.130HOSTNAME.pcrf.mncXXX.mccYYY.3gppnetwork.orgHOSTNAME.pcrf.mncXXX.mccYYY.3gppnetwork.org
192.x.x.16 HOSTNAME-cluman installer
#END_QPS_OTHER_HOSTS
[root@Hostname-cluman ~]#

Étape 4: Valider l'échange de capacités homologues

L'autorité de régulation de domaine doit annoncer explicitement la prise en charge des applications Diameter telles que Gx (16777238) et Rx (16777236) dans les messages de demande d'échange de capacités (CER) et d'échange de capacités (CEA).

L'application Relay, avec l'identificateur d'application 0xffffffff, n'est pas prise en charge par Cisco PCRF. Si seule l'application Relay (4294967295) est échangée et non Gx/Rx, la connexion homologue est établie en mode relais uniquement et PCRF ne répond pas aux messages CCR-I.

Référez-vous à la section Routage de tronçon suivant dans le Guide de configuration mobile CPS pour plus de détails. 

Meilleure pratique :
Pendant la phase d'établissement de la connexion homologue, capturez toujours le pcap sur PCRF pour vous assurer que DRA envoie un message de demande d'échange de capacités (CER) de diamètre avec un jeu de valeurs d'ID d'application d'authentification AVP Diamètre des applications telles que Gx (16777238) ou Rx (16777236) ou les deux et PCRF répond avec des valeurs similaires dans le message de réponse d'échange de capacités (CEA).

Figure 4 : Message CER avec une valeur incorrecte dans Auth-Application-Id en tant que relais

Figure 4 : Message CER avec une valeur incorrecte dans Auth-Application-Id as Relay

Figure 5 : Message CER avec les valeurs correctes dans Auth-Application-Id : Gx et Rx

Figure 5 : Message CER avec les valeurs correctes dans Auth-Application-Id : Gx et Rx

Étape 5: Assurez-vous que le nom d'hôte source unique du diamètre est défini à chaque noeud homologue de diamètre 

Cisco CPS PCRF prend en charge un environnement dans lequel chaque noeud homologue connecté requiert un nom d'hôte source de diamètre unique.

Si la migration doit être effectuée pour des connexions homologues de diamètre à partir d'une connectivité Gx ou Rx directe existante vers des liaisons à médiation DRA, la liaison DRA pour chaque interface de diamètre (Gx ou Rx) entre PCEF ou P-CSCF et DRA doit idéalement utiliser un nom d'hôte source unique pour l'application de diamètre (la valeur de l'origine-hôte AVP) qui serait différente de celle utilisée pour la connectivité PCRF directe avec le même noeud homologue.

Cela garantit que les requêtes des noeuds homologues sont acheminées via la liaison homologue DRA correcte et ne sont pas abandonnées si d'anciennes entrées de liaison directe désactivée sont présentes dans la liste PCRF show_peers.py.

Meilleure pratique :

S'il n'est pas possible de modifier le nom d'hôte pour les liaisons DRA sur l'homologue, effectuez un redémarrage complet des quatre services QNS séquentiellement sur chaque machine virtuelle d'équilibrage de charge après avoir supprimé les liaisons homologues directes. 

Cela permettrait de s'assurer que les anciennes entrées obsolètes (hôte d'origine : ) des homologues utilisées précédemment pour l'interface de diamètre direct (Gx/Rx) entre PCEF/P-CSCF et PCRF ne sont plus présentes dans la liste de connexion d'homologue de diamètre PCRF, et que la sortie de show_peers.py aurait uniquement des connexions d'homologue DRA et donc un routage correct des messages d'application de diamètre (par exemple : Gx_CCA-I, Gx_CCA-T ) à partir des liaisons de diamètre nouvellement créées entre DRA et PCRF.

Étape 6 : configurez la table de routage de tronçon suivant pour les homologues DRA

Cette fonctionnalité permet l'interfonctionnement avec un DRA qui n'est pas en mode de masquage de topologie. Lorsqu'un DRA établit une connexion, il annonce ses propres valeurs Origin-Host et Realm. Cependant, les messages d'application Diameter utilisent l'hôte d'origine et le domaine (par exemple, PCEF, TDF, AF) de l'hôte d'application réel, de sorte que PCRF doit déterminer quelle connexion DRA utiliser pour remettre les messages à l'hôte correct.

Ces paramètres peuvent être configurés dans la table de routage de tronçon suivant :

Paramètre	Description
Domaine du saut suivant	Nom de domaine DRA tel que reçu dans Origin-Realm AVP dans CER ou CEA message. Remarque : Tous les domaines de saut suivant (domaine de saut suivant) doivent correspondre à la valeur VP du domaine origine A dans le message CER/CEA entrant.
Hôtes du saut suivant	Liste de noms d'hôtes DRA telle que reçue dans Origin-Host AVP dans CER ou CEA message. Remarque : Tous les noms d'hôtes de tronçon suivant (hôtes de tronçon suivant) doivent correspondre à la valeur VP d'origine-hôte A dans le message CER/CEA entrant.
ID d'application	ID d'application de diamètre annoncé comme étant pris en charge par le DRA. Il contient des informations qui identifient le service particulier que le service session appartient à.
Modèle des domaines de destination	Modèle de nom de domaine de destination réel reçu dans le protocole AVP du domaine d'origine dans le message AAR. Le modèle doit être le standard Java régulier syntaxe d'expression.
Modèle hôte de destination	Modèle de nom d'hôte de destination réel tel que reçu dans Origin-Host AVP dans message AAR. Le modèle doit être un modèle Java standard les conventions. Le modèle doit être le standard Java régulier syntaxe d'expression.

Meilleure pratique : 

Essayez toujours d'utiliser le modèle d'expression régulière correct (correspondance de caractères génériques) lors de l'écriture des entrées dans la colonne Modèle de domaines de destination et Modèle d'hôte de destination dans

Table de routage de tronçon suivant pour réduire les entrées de configuration pour les homologues Gx et Rx et plusieurs connexions et empêcher les erreurs de configuration.

Historique de révision

Révision	Date de publication	Commentaires
1.0	19-Aug-2026	Première publication