Fonction d’enregistrement et de reporting pour les abonnés

Contrôle des journaux et des rapports

Les sessions de données d’un abonné sont journalisées et envoyées aux collecteurs en fonction d’un profil LRF que vous configurez et associez à l’abonné.

Le profil LRF comprend :

• Modèles : spécifiez le type de données que vous souhaitez envoyer et le déclencheur qui provoque l’envoi des données. Vous pouvez configurer un maximum de 16 modèles dans un profil LRF.

• Collecteurs : identifient la destination vers laquelle envoyer les données. Vous pouvez configurer un maximum de huit collecteurs dans un profil LRF.

• Règles LRF : spécifiez le modèle et le collecteur à utiliser et, le cas échéant, une limite de volume de données qui déclenche l’envoi des données. Les actions d’une règle LRF sont exécutées lorsque les conditions de correspondance d’une règle PCC statique qui fait référence à la règle LRF sont remplies. Vous pouvez configurer un maximum de 32 règles LRF dans un profil LRF.

Pour associer le profil LRF à un abonné :

• Pour la prise en compte de l’abonné par Junos OS, attribuez le profil LRF à l’ensemble de services TDF conscient de l’abonné qui appartient à l’interface TDF (MIF) dans le domaine TDF de l’abonné.

• Pour la gestion des abonnés haut débit de Junos OS, attribuez le profil LRF à l’ensemble de services configuré pour le contrôle des stratégies en fonction des applications.

Modèles

Vous spécifiez les champs de données d’un modèle en configurant un ou plusieurs types pour le modèle ; HTTP et IPv4, par exemple. Chaque type représente un ensemble de champs, et le modèle que vous configurez inclut des champs de tous les types que vous configurez. Le modèle est envoyé au collecteur lorsque vous le configurez et est renvoyé à un intervalle configurable. Les types de modèles que vous pouvez sélectionner et les champs inclus par chaque type sont les suivants :

• Données de l’appareil : contient des champs de données spécifiques à l’appareil qui collecte le flux de journalisation :

  • Version du moteur DPI

  • Adresse IP de la passerelle TDF (au format IPv4)

• DNS : (non disponible si les services nouvelle génération sont activés avec la carte de services MX-SPC3) Contient le champ de données sur le temps de réponse DNS.

• ID de flux : contient le champ de données ID de flux.

  Lorsque la journalisation des transactions multiples HTTP est activée, FlowID est un type implicite qui est inclus dans le modèle HTTP. Lorsque le journal de session consolidé est généré au moment de la SESSION_CLOSE, LRF inclut le FlowID qui peut être utilisé pour établir une corrélation avec les enregistrements du journal de transactions HTTP.

• HTTP : contient les champs de données pour les métadonnées HTTP des champs d’en-tête :

  • Agent utilisateur

  • Longueur du contenu - Demande

  • Code de réponse HTTP

  • Langue

  • Hôte

  • Emplacement

  • Méthode HTTP

  • Référent (HTTP)

  • Type MIME

  • Temps jusqu’au premier octet

• IFL abonné : contient des champs de données spécifiques aux abonnés basés sur IFL :

  • Nom de l’abonné : ne s’applique pas aux abonnés BNG, cette valeur n’est donc pas honorée (est remplie par zéro).

  • IFL Name : renseigné avec le nom IFL par défaut (renseigné avec les valeurs IFL Next Gen Services)

• IPFlow : contient des champs de données pour les octets et les octets de liaison montante et descendante. Lorsqu’un enregistrement de données pour la limite de volume est exporté, ces statistiques IPFlow dans l’enregistrement sont les données réelles reçues après la dernière limite de volume signalée dans cette session de données et non les données cumulatives.

  • Octets de liaison montante

  • Octets de liaison descendante

  • Paquets de liaison montante

  • Paquets en liaison descendante

  • Protocole IP : ID de protocole de l’en-tête IP ; par exemple, 17 (UDP), 6 (TCP).

  • Raison de l’enregistrement : valeur de pour la fermeture de 1 la session et valeur de pour la limite de 2 volume.

• IPFlow Extended : contient des champs de données pour le nom de l’ensemble de services, l’instance de routage et les horodatages de la charge utile. L’initiateur du tout premier paquet d’une session est le client et le répondant est le serveur.

  • Service-Set-Name : rempli avec active service-set-name (la valeur de 16 octets est remplie active service-set-name. Par exemple, si service-set-name est : bng-service-set-1, la valeur du modèle est : bng-service-set-(16bytes)

  • Routing-Instance : ne s’applique pas aux abonnés BNG, donc cette valeur n’est pas honorée (est remplie par zéro).

• IPFlow TCP : contient des champs de données pour les horodatages liés au protocole TCP :

  • Paquets TCP retransmis en liaison montante

  • Paquets TCP retransmis en liaison descendante

  • Horodatage de création de flux TCP

• IPFlow TCP Timestamp : contient des champs de données spécifiques à IBM pour les horodatages liés au protocole TCP :

  • Liaison montante RTT fluide

  • Liaison descendante RTT fluide

  • Temps d’installation du client

  • Temps d’installation du serveur

  • Horodatage de la charge utile du premier client

  • Heure de téléchargement

  • Horodatage de la charge utile du premier serveur

  • Temps de téléchargement

  • Volumes acquittés en liaison montante

  • Volumes acquittés en liaison descendante

  Pour utiliser le modèle d’horodatage TCP IPFlow lors de la configuration d’un profil LRF, identifiez le modèle comme spécifique au fournisseur pour éviter un avertissement de validation. Voir Configuration d’un profil LRF pour les abonnés.

• IPFlow Timestamp : contient des champs de données pour les horodatages de début et de fin du flux :

  • Heure de début du flux : pour TCP, l’heure de début du flux est celle de la réception du paquet SYN. Pour UDP, c’est à ce moment-là que le premier paquet est envoyé.

  • Heure de fin du flux

• IPv4 : contient des champs de données pour les informations de base IPv4 source et de destination :

  • Adresse IPv4 source

  • Adresse IPv4 de destination

• IPv4 étendu : (non disponible si les services de nouvelle génération avec la carte de services MX-SPC3 sont activés) Contient des champs de données pour les éléments des champs étendus IPv4 :

  • Conditions d’utilisation IPv4 / Classe de service

  • Masque de source IPv4

  • Masque de destination IPv4

  • Saut suivant IPv4

• IPv6 : contient des champs de données pour les informations de base IPv6 source et de destination :

  • Adresse IPv6 source

  • Adresse IPv6 de destination

• IPv6 étendu : (non disponible si les services nouvelle génération sont activés avec la carte de services MX-SPC3) Contient des champs de données pour les éléments des champs étendus IPv6 :

  • Masque de source IPv6

  • Masque de destination IPv6

  • Saut suivant IPv6

  • Classe de trafic

• Application L7 : contient des champs de données pour l’application de couche 7 :

  • Protocole d’application : protocole de données d’application sous le nom de l’application classifiée ; par exemple, http ou ssl.

  • Nom de l’application : nom de l’application ; par exemple, junos:facebook ou junos:Netflix.

  • Host : hôte d’en-tête HTTP lorsque le protocole d’application est http, nom commun SSL lorsque le protocole d’application est ssl, nom DNS lorsque le protocole d’application est dns.

• Abonné mobile : (non disponible si les services de nouvelle génération avec la carte de services MX-SPC3 sont activés) Contient des champs de données spécifiques aux abonnés mobiles :

  • IMSI

  • Le MSISDN

  • IMEI

  • Type RAT

  • ULI

  • ID de station appelé RADIUS

• PCC : contient le champ de données du nom de la règle PCC. Non applicable si les services nouvelle génération sont activés.

• Distribution de codes d’état : contient des champs de données pour les codes d’état HTTP ou DNS :

  • Code d’état 1

  • Code d’état 2

  • Code d’état 3

  • Code d’état 4

  • Code d’état 5

  • Nombre d’instances 1

  • Nombre d’instances 2

  • Nombre d’instances 3

  • Nombre d’instances 4

  • Nombre d’instances 5

• Données sur l’abonné : contient des champs de données pour les informations génériques sur l’abonné qui peuvent être incluses avec les abonnés sans fil (mobiles) ou filaires :

  • NAS_IP_ADDR : ne s’applique pas aux abonnés BNG, cette valeur n’est donc pas honorée (est remplie par zéro).

  • Type d’abonné : 1 pour l’abonné IP, 2 pour l’abonné IFL.

  • Adresse IP de l’abonné

  • VRF d’abonné : ne s’applique pas aux abonnés BNG, donc cette valeur n’est pas honorée (est remplie par zéro).

  • ID de port NAS : ne s’applique pas aux abonnés BNG, donc cette valeur n’est pas honorée (est remplie par zéro).

  • Accounting-Session-Id : ne s’applique pas aux abonnés BNG, cette valeur n’est donc pas honorée (est remplie par zéro).

  • Classe : ne s’applique pas aux abonnés BNG, donc cette valeur n’est pas honorée (est remplie par zéro).

  • Type de port NAS : ne s’applique pas aux abonnés BNG, donc cette valeur n’est pas honorée (est remplie par zéro).

• Couche transport : contient des champs de données pour la couche transport :

  • Source Transport Port

  • Destination Transport Port

• Vidéo : (non disponible si les services nouvelle génération avec la carte de services MX-SPC3 sont activés) Contient des champs de données pour le trafic vidéo :

  • Débit binaire

  • Durée

• Abonné filaire : (non disponible si les services de nouvelle génération avec la carte de série MX-SPC3 sont activés) Contient le champ de données Nom d’utilisateur pour les abonnés filaires. C’est la même chose que l’ID de station appelée RADIUS.

Le modèle spécifié dans une règle LRF détermine l’ensemble des champs de données inclus lorsque les données sont envoyées à un collecteur. Le message de données inclut un pointeur vers l’ID du modèle afin que le collecteur puisse corréler le contenu des données avec les longueurs et les types de champs de données.

Dans un modèle, vous spécifiez également le type de déclencheur qui détermine quand envoyer des données au collecteur. Ce type de déclencheur peut être une limite de volume de données, une limite de temps ou la fermeture d’une session de données (les sessions UDP sont considérées comme fermées après 60 secondes d’inactivité ; Les sessions TCP sont considérées comme fermées lorsqu’un FIN, FIN-ACK ou RST est reçu).

Journalisation des transactions HTTP

Vous pouvez activer la journalisation des transactions HTTP dans un profil LRF. Chaque transaction HTTP d’une session TCP est alors enregistrée séparément et envoyée au collecteur, comme illustré à la figure 1. Cette option n’est pertinente que lorsque le modèle utilisé inclut HTTP dans le type de modèle.

Par défaut, la journalisation des transactions HTTP est désactivée et les enregistrements de transaction HTTP d’une session TCP sont envoyés ensemble en un seul groupe d’enregistrements.

Figure 1 : Journalisation des transactions HTTP