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 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 AS. Les modèles et les champs qu’ils contiennent sont transmis périodiquement au collecteur, qui n’a aucune incidence sur la configuration du routeur.
La version 9 nécessite l’installation d’un pic de services, tel que le PIC des services adaptatifs ou le MS-PIC dans le routeur. Sur les routeurs MX Series, le MS-DPC répond à cette exigence. Pour plus d’informations sur la détermination du PIC de services adapté à votre routeur, reportez-vous à la section 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 de source multiples n’indiquent pas que les paquets d’exportation proviennent de plusieurs PIC de service.
Configuration du trafic à échantillonner
Pour spécifier l’échantillonnage du 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 inet6, ou family mpls.
Si vous spécifiez l’échantillonnage pour le trafic de facturation homologue AS, l’instruction prend uniquement en charge le family trafic IPv4 et IPv6 (inet ou inet6). Le trafic de facturation Peer AS est activé uniquement au niveau de la hiérarchie globale des instances et n’est pas disponible pour les instances par moteur de transfert de paquets.
Une fois que vous avez spécifié la famille de trafic à échantillonner, configurez les paramètres d’échantillonnage, par exemple :
Longueur maximale des paquets (au-delà de laquelle les paquets sont tronqués).
Nombre maximal de paquets à échantillonner par seconde (au-delà duquel les paquets sont abandonnés).
Rate (par exemple, si vous spécifiez 10, un paquet sur 10 est échantillonné).
Longueur d’exécution (qui spécifie le nombre de paquets à échantillonner après le déclencheur ; c’est-à-dire que si le
rateest défini sur 10 etrun-lengthsur 5, cinq paquets à partir du 10e paquet sont échantillonnés).
[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 Version 9, incluez les instructions 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 instructions 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 , ,
ipv4-templateipv6-templatempls-ipv4-templateou .mpls-templateSi le modèle est utilisé pour le trafic MPLS, vous pouvez également spécifier jusqu’à trois positions d’étiquette pour les données d’étiquette 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 andflow-inactive-timeout. Ces instructions ont des valeurs par défaut et de plage spécifiques lorsqu’elles sont utilisées dans des définitions de modèle ; La valeur par défaut est de 60 secondes et la plage est comprise entre 10 et 600 secondes. Les valeurs que vous spécifiez dans les définitions de modèle remplacent les valeurs de délai d’expiration globales 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
option-refresh-rateinstructions ettemplate-refresh-ratedans une 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 cettesecondsoption, la valeur par défaut est 60 et la plage est comprise entre 10 et 600. Pour cettepacketsoption, la valeur par défaut est 4800 et la plage est comprise entre 1 et 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 de domaine d’observation et de l’ID de source pour les modèles de flux de la version 9
À partir de Junos OS version 14.1, vous pouvez définir un modèle d’enregistrement de flux version 9 adapté au trafic IPv4, au trafic IPv6, au trafic MPLS, à une combinaison de trafic IPv4 et MPLS, ou au trafic de facturation homologue AS. Les modèles et les champs qu’ils contiennent sont transmis périodiquement au collecteur sans que celui-ci n’affecte la configuration du routeur. Vous pouvez spécifier l’identificateur unique pour les modèles version 9 et IPFIX. L’identificateur d’un modèle est localement unique au sein d’une combinaison d’une session de transport et d’un domaine d’observation. Les ID de modèle 0 à 255 sont réservés aux jeux de modèles, aux jeux de modèles d’options et à d’autres ensembles pour une utilisation ultérieure. Les ID de modèle des ensembles de données sont numérotés de 256 à 65535. En règle générale, cet élément ou champ d’information dans le 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. Après avoir redémarré le processus d’exportation des modèles, vous pouvez réaffecter les ID de modèles.
Cette fonctionnalité de configuration de l’ID de modèle, de l’ID de modèle d’options, de l’ID de domaine d’observation et de l’ID source est prise en charge sur tous les routeurs avec MPC.
Les ID de modèle qui incluent l’ID de modèle MPLS et MPLS-IPv4 ne s’appliquent qu’à IPFIX. Le format V9 comporte un ID de modèle différent.
Les jeux de données et les jeux de données d’options correspondants contiennent la valeur des ID de modèle et des ID de modèle d’options, respectivement, dans le champ ID de l’ensemble. Cette méthode permet au collecteur de faire correspondre un enregistrement de données avec 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 la version 9 et les flux IPFIX, consultez Configuration de l’ID de domaine d’observation et de l’ID de source pour les flux de la version 9 et IPFIX et Configuration de l’ID de modèle et des 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 les deux types différents de configuration d’agrégation de flux en même temps.
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 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 abandonnés sur le PIC et sont comptabilisés comme des erreurs d’analyseur.Le trafic sortant du moteur de routage n’est pas échantillonné. Un filtre de pare-feu est appliqué en sortie sur l’interface de sortie, qui échantillonne les paquets et exporte les données. Pour le trafic de transit, l’échantillonnage de sortie fonctionne correctement. Pour le trafic interne, le saut suivant est installé dans le moteur de transfert de paquets, mais les paquets échantillonné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 la sortie du PIC. Tous les paquets envoyés au PIC sont abandonnés jusqu’à ce que le processus de synchronisation soit terminé.
Étant donné que le transfert d’un paquet qui arrive avec des étiquettes MPLS est effectué sur la base de l’étiquette MPLS et non sur la base de l’adresse IP contenue dans le paquet, le paquet est échantillonné à l’interface de sortie, l’étiquette MPLS qui a été éclatée 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 le chemin du paquet échantillonné est déterminé dans la table VRF. Étant donné qu’aucune route spécifique n’est disponible dans le VRF qui est différente du VRF sur lequel le paquet est reçu, les champs Index de l’interface de sortie, Masque source et Masque de destination ne sont pas renseignés correctement. Ce comportement se produit lorsqu’un modèle IPv4 est appliqué comme filtre de pare-feu sur une interface de sortie avec 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
Heure de fin du 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 de 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 :
Adresse source et masque IPv6
Adresse et masque de destination IPv6
L4 Source Port
L4 Destination Port
IPv6 ToS
Protocole IPv6
Indicateurs TCP
Version du protocole IP
Adresse de saut suivant IPv6
Informations sur l’interface de sortie
Numéro du système autonome source (AS)
Numéro AS de destination
Le modèle MPLS comprend les champs spécifiques suivants :
Étiquette MPLS #1
Étiquette MPLS #2
Étiquette MPLS #3
Informations sur MPLS EXP
Adresse IP FEC
Le modèle MPLS-IPv4 inclut tous les champs présents dans les modèles IPv4 et MPLS.
Le modèle de facturation homologue AS comprend les champs spécifiques suivants :
Classe de service (ToS) IPv4
Interface d’entrée
Adresse de saut suivant BGP IPv4
Numéro AS de destination de l’homologue BGP
Comportement d’échantillonnage MPLS
Cette section décrit le comportement lors de l’utilisation de l’échantillonnage MPLS sur les interfaces de sortie dans divers scénarios (étiquette, pop ou swap) sur les routeurs du fournisseur (routeurs P). Pour plus d’informations sur la configuration et le contexte spécifiques aux applications MPLS, reportez-vous au Guide de l’utilisateur des applications MPLS.
Vous configurez l’échantillonnage MPLS sur une interface de sortie sur le routeur P et 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é.
Grâce à la possibilité 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 de sortie sur le routeur P et configurez un modèle d’agrégation de flux MPLS. L’action de routage est l’échange d’étiquettes et l’étiquette permutée est 0 (null explicite).
Le comportement résultant est que les paquets MPLS sont envoyés au PIC. Le flux échantillonné correspond à l’étiquette avant l’échange.
Vous configurez un réseau VPN de couche 3, dans lequel un routeur de périphérie client (CE-1) envoie du trafic à un routeur Provider Edge (PE-A), via le routeur P, à un routeur Provider Edge (PE-B) et à un routeur de périphérie client (CE-2) similaires à l’extrémité distante.
Il en résulte que vous ne pouvez pas échantillonner de paquets MPLS sur la liaison du routeur PE-A vers P.
Vérification
Pour vérifier les propriétés de configuration, vous pouvez utiliser la commande mode show services accounting aggregation template template-name name opérationnel.
Toutes les autres show services accounting commandes prennent également en charge les modèles de la version 9, à l’exception de show services accounting flow-detail et show services accounting aggregation aggregation-type. Pour plus d’informations sur les commandes en mode opérationnel, reportez-vous à l’Explorateur CLI.
Exemples : Configuration des modèles de flux de la version 9
L’exemple suivant montre une configuration de modèle 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 montre une configuration de 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 le PIC AS pour qu’il accepte à 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 à l’AS PIC :
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 montre une configuration de filtre de pare-feu pour le trafic de facturation homologue 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 homologue AS en tant qu’attribut de filtre sous la hiérarchie forwarding-options pour la collecte d’informations sur l’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 de DCU AS homologue afin de collecter des statistiques d’utilisation pour le flux de trafic entrant en tant que chemin à une interface d’entrée spécifique avec la hiérarchie de configuration du pare-feu appliquée sous forme de filtres de table de transfert (FTF). La fonctionnalité de configuration avec la capacité CoS peut être obtenue via des FTF pour une utilisation de classe de destination avec une 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 activer 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;
}
}
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.