SUR CETTE PAGE
Configuration de l’agrégation de flux sur les routeurs MX, M, vMX et T Series et NFX250 pour utiliser des modèles de flux de version 9
L’utilisation du modèle de flux de la version 9 vous permet de définir un modèle d’enregistrement de flux adapté au trafic IPv4, au trafic IPv6, au trafic MPLS, à une combinaison de trafic IPv4 et MPLS ou au trafic de facturation PEER AS. Les modèles et les champs inclus dans le modèle sont transmis régulièrement au collecteur, et le collecteur n’affecte pas la configuration du routeur.
La version 9 nécessite que vous installiez une PIC de services, telle que Adaptive Services PIC ou MS-PIC dans le routeur. Sur les routeurs MX Series, le MS-DPC répond à cette exigence. Pour plus d’informations sur les pics de services adaptés à votre routeur, consultez l’activation des packages de services ou la documentation matérielle appropriée.
Si plusieurs familles de protocoles sont configurées pour un collecteur de flux particulier, les paquets d’exportation proviennent de plusieurs ID source, chaque ID source correspondant à un protocole particulier. Les ID source multiples n’indiquent pas que les paquets d’exportation proviennent de plusieurs PIC de service.
Configuration du trafic à échantillonner
Pour spécifier un échantillon de trafic de facturation IPv4, IPv6, MPLS ou peer AS, incluez la configuration appropriée de l’instruction family au niveau de la [edit forwarding-options sampling] hiérarchie :
[edit forwarding-options]
sampling {
family (inet | inet6 | mpls);
}
Vous pouvez inclure family inet ,family inet6ou family mpls.
Si vous spécifiez un échantillonnage pour le trafic de facturation PEER AS, l’état family prend uniquement en charge le trafic IPv4 et IPv6 (inet ou inet6). Le trafic de facturation peer AS n’est activé qu’au niveau de la hiérarchie d’instances globale et n’est pas disponible pour les instances du moteur de transfert de paquets.
Après avoir spécifié la famille de trafic à échantillonner, configurez les paramètres d’échantillonnage tels que :
Longueur maximale des paquets (au-delà de laquelle les paquets sont tronqués).
Nombre maximal de paquets à échantillonner par seconde (au-delà desquelles les paquets sont abandonnés).
Débit (par exemple, si vous spécifiez 10, chaque 10ème paquet est échantilloné).
Longueur d’exécution (qui spécifie le nombre de paquets à échantillonner après le déclenchement; c’est-à-dire que, si l’échantillon
rateest défini sur 10 etrun-length5, cinq paquets commençant par le 10e paquet sont échantillonnées).
[edit forwarding-options sampling]
input {
maximum-packet-length bytes
max-packets-per-second number;
rate number;
run-length number;
}
Configuration des propriétés du modèle version 9
Pour définir les modèles de la version 9, incluez les déclarations suivantes au niveau de la [edit services flow-monitoring version9] hiérarchie :
[edit services flow-monitoring version9] template template-name { options-template-id template-id source-id flow-active-timeout seconds; flow-inactive-timeout seconds; option-refresh-rate packets packets seconds seconds; template-refresh-rate packets packets seconds seconds; (ipv4-template | ipv6-template | mpls-ipv4-template | mpls-template | peer-as-billing-template) { label-position [ positions ]; } }
Les détails suivants s’appliquent aux déclarations de configuration :
Vous attribuez à chaque modèle un nom unique en incluant l’instruction
template template-name.Vous spécifiez ensuite chaque modèle pour le type de trafic approprié en incluant le
ipv4-template,ipv6-template,mpls-ipv4-templateoumpls-template.Si le modèle est utilisé pour le trafic MPLS, vous pouvez également spécifier jusqu’à trois positions de label pour les données de label d’en-tête MPLS en incluant l’instruction
label-position; les valeurs par défaut sont[1 2 3].Dans la définition du modèle, vous pouvez éventuellement inclure des valeurs pour les
flow-active-timeoutinstructions etflow-inactive-timeout. Ces instructions ont des valeurs par défaut et de plage spécifiques lorsqu’elles sont utilisées dans les définitions de modèles ; la valeur par défaut est de 60 secondes et la plage est de 10 à 600 secondes. Les valeurs que vous spécifiez dans les définitions de modèles remplacent les valeurs globales de délai d’expiration configurées au niveau de la[edit forwarding-options sampling family (inet | inet6 | mpls) output flow-server]hiérarchie.Vous pouvez également inclure des paramètres pour les déclarations et
template-refresh-ratedansoption-refresh-rateune définition de modèle. Pour ces deux propriétés, vous pouvez inclure une valeur de minuterie (en secondes) ou un nombre de paquets (en nombre de paquets). Pour l’optionseconds, la valeur par défaut est 60 et la plage est de 10 à 600. Pour l’optionpackets, la valeur par défaut est 4800 et la plage est de 1 à 480 000.Pour filtrer le trafic IPv6 sur une interface multimédia, la configuration suivante est prise en charge :
interfaces interface-name { unit 0 { family inet6 { sampling { input; output; } } } }
Personnalisation de l’ID de modèle, de l’ID du domaine d’observation et de l’ID source pour les modèles de flux version 9
À partir de la version 14.1 de Junos OS, vous pouvez définir un modèle d’enregistrement de flux version 9 adapté au trafic IPv4, IPv6, au trafic MPLS, à une combinaison de trafic IPv4 et MPLS, ou au trafic de facturation PEER AS. Les modèles et les champs inclus dans le modèle sont transmis régulièrement au collecteur, et le collecteur n’affecte pas la configuration du routeur. Vous pouvez spécifier l’identifiant unique des modèles IPFIX et version 9. L’identifiant d’un modèle est localement unique dans une combinaison d’une session de transport et d’un domaine d’observation. Les IDs de modèles 0 à 255 sont réservés aux ensembles de modèles, aux ensembles de modèles d’options et à d’autres ensembles pour une utilisation ultérieure. Les modèles d’IO des ensembles de données sont numérotés de 256 à 65535. En règle générale, cet élément ou ce champ d’information du modèle est utilisé pour définir les caractéristiques ou les propriétés d’autres éléments d’information dans un modèle. Une fois qu’un redémarrage du processus d’exportation des modèles est effectué, vous pouvez réattribuer des IDs de modèle.
Cette fonctionnalité permettant de configurer l’ID de modèle, l’ID de modèle d’options, l’ID de domaine d’observation et l’ID source est prise en charge sur tous les routeurs équipés de MPC.
Les ID de modèle comprenant MPLS et l’ID de modèle MPLS-IPv4 s’appliquent uniquement à IPFIX. Le format V9 comporte un ID de modèle différent.
Les ensembles de données et les ensembles d’options correspondants contiennent la valeur des ID de modèle et des ID d’options respectivement dans le champ ID défini. Cette méthode permet au collecteur de faire correspondre un enregistrement de données à un enregistrement de modèle.
Pour plus d’informations sur la spécification de l’ID source, de l’ID de domaine d’observation, de l’ID de modèle et de l’ID de modèle d’options pour les flux IPFIX et version 9, voir Configuration de l’ID de domaine d’observation et de l’ID source pour les flux IPFIX et la configuration de l’ID de modèle et du modèle d’options pour les flux de la version 9 et IPFIX.
Restrictions
Les restrictions suivantes s’appliquent aux modèles de la version 9 :
Vous ne pouvez pas appliquer simultanément les deux types différents de configuration d’agrégation de flux.
L’exportation de flux basée sur un
mpls-ipv4modèle suppose que l’en-tête IPv4 suit l’en-tête MPLS. Dans le cas des VPN de couche 2, le paquet sur le routeur du fournisseur (routeur P) ressemble à ceci :MPLS | Layer 2 Header | IPv4
Dans ce cas,
mpls-ipv4les flux ne sont pas créés sur le PIC, car l’en-tête IPv4 ne suit pas directement l’en-tête MPLS. Les paquets sont supprimés sur le PIC et sont comptabilisés comme des erreurs d’analyse.Le trafic du moteur de routage sortant n’est pas échantilloné. Un filtre de pare-feu est appliqué en tant que sortie sur l’interface de sortie, qui échantillonne les paquets et exporte les données. Pour le trafic de transit, l’échantillonnage sortant fonctionne correctement. Pour le trafic interne, le saut suivant est installé dans le moteur de transfert de paquets, mais les paquets échantillonés ne sont pas exportés.
Les flux sont créés sur le PIC de surveillance uniquement une fois l’opération de resynchronisation de l’enregistrement de route terminée, soit 60 secondes après l’affichage du PIC. Tous les paquets envoyés au PIC sont supprimés jusqu’à ce que le processus de synchronisation soit terminé.
Étant donné que le transfert d’un paquet qui arrive avec des étiquettes MPLS s’effectue sur le label MPLS et non sur l’adresse IP contenue dans le paquet, le paquet est échantillonné à l’interface de sortie, le label MPLS qui a été retiré n’étant pas disponible au moment de l’échantillonnage. Dans ce cas, en fonction de l’interface entrante (IIF), l’index VRF est identifié et la route du paquet échantillon est déterminée dans la table VRF. Étant donné qu’un routage spécifique n’est pas disponible dans le VRF qui est différent du VRF sur lequel le paquet est reçu, les champs Index de l’interface de sortie, Masque source et Masque de destination sont mal remplis. Ce comportement se produit lorsqu’un modèle IPv4 est appliqué en tant que filtre de pare-feu sur une interface de sortie avec l’exemple comme action.
Champs inclus dans chaque type de modèle
Les champs suivants sont communs à tous les types de modèles :
Interface d’entrée
Interface de sortie
Nombre d’octets
Nombre de paquets
Heure de début du flux
Temps de fin de flux
Le modèle IPv4 comprend les champs spécifiques suivants :
Adresse source IPv4
Adresse de destination IPv4
L4 Source Port
L4 Destination Port
IPv4 ToS
Protocole IPv4
Type et code ICMP
Indicateurs TCP
Adresse du saut suivant IPv4
Numéro du système autonome (AS) source
Numéro AS de destination
Le modèle IPv6 comprend les champs spécifiques suivants :
Masque et adresse source IPv6
Adresse et masque de destination IPv6
L4 Source Port
L4 Destination Port
IPv6 ToS
Protocole IPv6
Indicateurs TCP
Version du protocole IP
Adresse du saut suivant IPv6
Informations sur l’interface sortante
Numéro as (Source Autonomous System)
Numéro AS de destination
Le modèle MPLS comprend les champs spécifiques suivants :
Label MPLS #1
Label MPLS #2
Label MPLS #3
Informations exp MPLS
Adresse IP FEC
Le modèle MPLS-IPv4 comprend tous les champs trouvés dans les modèles IPv4 et MPLS.
Le modèle de facturation peer AS comprend les champs spécifiques suivants :
Classe de service (ToS) IPv4
Interface entrante
BGP IPv4 Adresse du saut suivant
Numéro AS de destination peer BGP
Comportement d’échantillonnage MPLS
Cette section décrit le comportement lorsque l’échantillonnage MPLS est utilisé sur les interfaces de sortie dans divers scénarios (pop d’étiquette ou permutation) sur les routeurs des fournisseurs (routeurs P). Pour plus d’informations sur la configuration et l’arrière-plan spécifiques aux applications MPLS, consultez le Guide de l’utilisateur des applications MPLS.
Vous configurez l’échantillonnage MPLS sur une interface sortante du routeur P et vous configurez un modèle d’agrégation de flux MPLS. L’action de route est label pop car l’avant-dernier saut popping (PHP) est activé.
Avec la capacité actuelle d’appliquer des modèles MPLS, des flux MPLS sont créés.
Comme dans le premier cas, vous configurez l’échantillonnage MPLS sur une interface sortante sur le routeur P et configurez un modèle d’agrégation de flux MPLS. L’action de route est l’échange d’étiquettes et le label permuté est 0 (null explicite).
Le comportement qui en résulte est que les paquets MPLS sont envoyés au PIC. Le flux échantilloné correspond au label avant l’échange.
Vous configurez un réseau VPN de couche 3, dans lequel un routeur de périphérie client (CE-1) envoie le trafic à un routeur de périphérie fournisseur (PE-A), via le routeur P, à un routeur de périphérie de fournisseur (PE-B) similaire et à un routeur de périphérie client (CE-2) similaires à l’extrémité distante.
Le comportement qui en résulte est que vous ne pouvez pas échantillonner des paquets MPLS sur la liaison de routeur PE-A vers P.
Vérification
Pour vérifier les propriétés de configuration, vous pouvez utiliser la commande du show services accounting aggregation template template-name name mode opérationnel.
Toutes les autres show services accounting commandes prennent également en charge les modèles de version 9, à l’exception de show services accounting flow-detail et show services accounting aggregation aggregation-type. Pour plus d’informations sur les commandes du mode opérationnel, consultez l’Explorateur CLI.
Exemples : configuration de modèles de flux version 9
L’exemple suivant illustre une configuration de modèle de version 9 :
services {
flow-monitoring {
version9 {
template ip-template {
flow-active-timeout 20;
flow-inactive-timeout 120;
ipv4-template;
}
template mpls-template-1 {
mpls-template {
label-position [1 3 4];
}
}
template mpls-ipv4-template-1 {
mpls-ipv4-template {
label-position [1 5 7];
}
}
template vpls-template-1 {
vpls-template;
}
}
}
}
}
L’exemple suivant illustre la configuration d’un filtre de pare-feu pour le trafic MPLS :
firewall {
family mpls {
filter mpls_sample {
term default {
then {
accept;
sample;
}
}
}
}
}
L’exemple suivant applique le filtre d’échantillonnage MPLS sur une interface réseau et configure l’AS PIC pour accepter à la fois le trafic IPv4 et MPLS :
interfaces {
at-0/1/1 {
unit 0 {
family mpls {
filter {
input mpls_sample;
}
}
}
}
sp-7/0/0 {
unit 0 {
family inet;
family mpls;
}
}
}
L’exemple suivant applique le modèle MPLS version 9 à la sortie d’échantillonnage et l’envoie au PIC AS :
forwarding-options {
sampling {
input {
family mpls {
rate 1;
}
}
family mpls {
output {
flow-active-timeout 60;
flow-inactive-timeout 30;
flow-server 192.0.2.4 {
port 2055;
version9 {
template mpls-ipv4-template-1;
}
}
interface sp-7/0/0 {
source-address 198.51.100.1;
}
}
}
}
}
L’exemple suivant illustre la configuration d’un filtre de pare-feu pour le trafic de facturation PEER AS :
firewall {
family inet {
filter peer-as-filter {
term 0 {
from {
destination-class dcu-1;
interface ge-2/1/0;
forwarding-class class-1;
}
then count count_team_0;
}
}
term 1 {
from {
destination-class dcu-2;
interface ge-2/1/0;
forwarding-class class-1;
}
then count count_team_1;
}
term 2 {
from {
destination-class dcu-3;
interface ge-2/1/0;
forwarding-class class-1;
}
then count count_team_2;
}
}
}
}
L’exemple suivant applique le filtre de pare-feu peer AS en tant qu’attribut de filtre dans la hiérarchie des options de transfert pour la collecte d’informations d’utilisation du trafic de données au niveau CoS :
forwarding-options {
family inet {
filter output peer-as-filter;
}
}
L’exemple suivant applique les options de stratégie DCU AS peer pour collecter des statistiques d’utilisation pour le flux de trafic pour l’entrée en tant que chemin sur une interface d’entrée spécifique, la hiérarchie de configuration du pare-feu étant appliquée en tant que filtres de table de transfert (FTF). La fonctionnalité de configuration avec la fonctionnalité CoS peut être obtenue par le biais de FF pour une utilisation en classe de destination avec classe de transfert pour des interfaces d’entrée spécifiques :
policy-options {
policy-statement P1 {
from {
protocol bgp;
neighbor 10.2.25.5; #BGP router configuration;
as-path AS-1; #AS path configuration;
}
then destination-class dcu-1; #Destination class configuration;
}
policy-statement P2 {
from {
neighbor 203.0.113.5;
as-path AS-2;
}
then destination-class dcu2;
}
policy-statement P3 {
from {
protocol bgp;
neighbor 192.0.2.129;
as-path AS-3;
}
then destination-class dcu3;
}
as-path AS-1 3131:1111:1123;
as-path AS-2 100000;
as-path AS-3 192:29283:2;
}
L’exemple suivant applique le modèle vpls version 9 pour permettre l’échantillonnage du trafic à des fins de facturation :
forwarding-options {
sampling {
}
input {
rate 1;
}
family inet {
output {
flow-server 10.209.15.58 {
port 300;
version9 {
template {
peer-as;
}
}
}
interface sp-5/2/0 {
source-address 203.0.113.133;
}
}
}
}
}
family inet {
filter {
output peer-as-filter;
}
}