Sur cette page
Exemple : Configuration des routes BGP IPv6 sur le transport IPv4
Présentation des routes IPv4 publicitaires sur les sessions IPv6 BGP
Exemple : Routes IPv4 publicitaires sur les sessions BGP IPv6
Comprendre la redistribution des routes IPv4 avec le saut suivant IPv6 dans BGP
Configuration de BGP pour redistribuer des routes IPv4 avec des adresses de saut suivant IPv6
Comprendre les routes de flux BGP pour le filtrage du trafic
Exemple : Permettre à BGP de transporter des routes de spécification de flux
Exemple : Configuration de BGP pour transporter des routes de spécification de flux IPv6
Configuration des actions de spécification de flux BGP rediriger vers IP pour filtrer le trafic DDoS
Transfert du trafic à l’aide de la spécification de flux BGP action DSCP
BGP multi-protocole
Comprendre le BGP multiprotocole
Le BGP multiprotocole (MP-BGP) est une extension de BGP qui permet à BGP de transporter des informations de routage pour plusieurs couches réseau et familles d’adresses. MP-BGP peut transporter les routes unicast utilisées pour le routage multicast séparément des routes utilisées pour le transfert IP unicast.
Pour activer MP-BGP, vous configurez BGP pour qu’il transporte les informations d’accessibilité de la couche réseau (NLRI) pour les familles d’adresses autres que IPv4 unicast en incluant l’énoncé family inet :
family inet { (any | flow | labeled-unicast | multicast | unicast) { accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } <loops number>; prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } rib-group group-name; topology name { community { target identifier; } } } }
Pour permettre à MP-BGP de transporter NLRI pour la famille d’adresses IPv6, incluez la family inet6 déclaration :
family inet6 { (any | labeled-unicast | multicast | unicast) { accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } <loops number>; prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } rib-group group-name; } }
Sur les routeurs uniquement, pour permettre à MP-BGP de transporter le NLRI du réseau privé virtuel (VPN) de couche 3 pour la famille d’adresses IPv4, incluez la family inet-vpn déclaration :
family inet-vpn { (any | flow | multicast | unicast) { accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } <loops number>; prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } rib-group group-name; } }
Sur les routeurs uniquement, pour permettre à MP-BGP de transporter des NLRI VPN de couche 3 pour la famille d’adresses IPv6, incluez la family inet6-vpn déclaration :
family inet6-vpn { (any | multicast | unicast) { accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;} } <loops number>; prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;}} rib-group group-name; } }
Sur les routeurs uniquement, pour permettre à MP-BGP de transporter des NLRI VPN multicast pour la famille d’adresses IPv4 et d’activer la signalisation VPN, incluez la family inet-mvpn déclaration :
family inet-mvpn {
signaling {
accepted-prefix-limit {
maximum number;
teardown <percentage> <idle-timeout (forever | minutes)>;
drop-excess <percentage>;
hide-excess <percentage>;}}
<loops number>;
prefix-limit {
maximum number;
teardown <percentage> <idle-timeout (forever | minutes)>;
drop-excess <percentage>;
hide-excess <percentage>;}}
}
}
Pour permettre à MP-BGP de transporter des NLRI VPN multicast pour la famille d’adresses IPv6 et d’activer la signalisation VPN, incluez la family inet6-mvpn déclaration :
family inet6-mvpn {
signaling {
accepted-prefix-limit {
maximum number;
teardown <percentage> <idle-timeout (forever | minutes)>;
drop-excess <percentage>;
hide-excess <percentage>;}}
<loops number>;
prefix-limit {
maximum number;
teardown <percentage> <idle-timeout <forever | minutes>;
drop-excess <percentage>;
hide-excess <percentage>;}}
}
}
Pour plus d’informations sur les VPN multicast basés sur BGP multiprotocoles, consultez le Guide de l’utilisateur des protocoles multicast Junos OS.
Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure ces déclarations, consultez les sections de synthèse de ces déclarations.
Si vous modifiez la famille d’adresses spécifiée au niveau de la [edit protocols bgp family] hiérarchie, toutes les sessions BGP actuelles sur l’équipement de routage sont abandonnées, puis rétablies.
Dans junos OS version 9.6 et versions ultérieures, vous pouvez spécifier une valeur de boucle pour une famille d’adresses BGP spécifique.
Par défaut, les pairs BGP n’ont que des routes unicast utilisées à des fins de transfert unicast. Pour configurer des pairs BGP de manière à ne transporter que des routes multicast, spécifiez l’option multicast . Pour configurer les pairs BGP pour qu’ils transportent à la fois des routes unicast et multicast, spécifiez l’option any .
Lorsque MP-BGP est configuré, BGP installe les routes MP-BGP dans différentes tables de routage. Chaque table de routage est identifiée par la famille de protocoles ou l’indicateur de famille d’adresses (AFI) et un identifiant de famille d’adresses (SAFI) ultérieur.
La liste suivante présente toutes les combinaisons AFI et SAFI possibles :
AFI=1, SAFI=1, unicast IPv4
AFI=1, SAFI=2, multicast IPv4
AFI=1, SAFI=128, unicast IPv4 L3VPN
AFI=1, SAFI=129, multicast IPv4 L3VPN
AFI=2, SAFI=1, unicast IPv6
AFI=2, SAFI=2, multicast IPv6
AFI=25, SAFI=65, BGP-VPLS/BGP-L2VPN
AFI=2, SAFI=128, unicast IPv6 L3VPN
AFI=2, SAFI=129, multicast IPv6 L3VPN
AFI=1, SAFI=132, RT-Contrainte
AFI=1, SAFI=133, spécifications de flux
AFI=1, SAFI=134, spécifications de flux
AFI=3, SAFI=128, CLNS VPN
AFI=1, SAFI=5, NG-MVPN IPv4
AFI=2, SAFI=5, NG-MVPN IPv6
AFI=1, SAFI=66, MDT-SAFI
AFI=1, SAFI=4, étiqueté IPv4
AFI=2, SAFI=4, étiqueté IPv6 (6PE)
Les routes installées dans la table de routage inet.2 ne peuvent être exportées vers des pairs MP-BGP que parce qu’elles utilisent le SAFI et les identifient comme des routes vers des sources multicast. Les routes installées dans la table de routage inet.0 ne peuvent être exportées que vers des pairs BGP standard.
La table de routage inet.2 doit être un sous-ensemble des routes que vous avez dans inet.0, car il est peu probable que vous disposiez d’un routage vers une source multicast vers laquelle vous ne pourriez pas envoyer de trafic unicast. La table de routage inet.2 stocke les routes unicast utilisées pour les vérifications de transfert inverse de chemin multicast, ainsi que les informations d’accessibilité supplémentaires apprises par MP-BGP à partir des mises à jour multicast NLRI. Une table de routage inet.2 est automatiquement créée lorsque vous configurez MP-BGP (en définissant NLRI sur any).
Lorsque vous activez MP-BGP, vous pouvez effectuer les opérations suivantes :
- Limitation du nombre de préfixes reçus sur une session peer BGP
- Limitation du nombre de préfixes acceptés sur une session peer BGP
- Configuration des groupes de tables de routage BGP
- Résolution de routes vers des équipements de routage PE situés dans d’autres ass
- Autoriser les routes étiquetées et non étiquetées
Limitation du nombre de préfixes reçus sur une session peer BGP
Vous pouvez limiter le nombre de préfixes reçus sur une session peer BGP et consigner les messages à débit limité lorsque le nombre de préfixes injectés dépasse une limite définie. Vous pouvez également démolir l’appairage lorsque le nombre de préfixes dépasse la limite.
Pour configurer une limite au nombre de préfixes pouvant être reçus sur une session BGP, incluez l’instruction prefix-limit :
prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>; }
Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.
Pour maximum number, spécifiez une valeur dans la plage de 1 à 4 294 967 295. Lorsque le nombre maximal de préfixes spécifié est dépassé, un message de journal système est envoyé.
Si vous incluez l’instruction teardown , la session est détruite lorsque le nombre maximal de préfixes est dépassé. Si vous spécifiez un pourcentage, les messages sont enregistrés lorsque le nombre de préfixes dépasse ce pourcentage de la limite maximale spécifiée. Une fois la session détruite, elle est rétablie dans un court laps de temps (à moins que vous n’incluiez la idle-timeout déclaration). Si vous incluez l’instruction idle-timeout , la session peut être maintenue hors service pendant un certain temps, ou pour toujours. Si vous spécifiez forever, la session n’est rétablie qu’après l’émission d’une clear bgp neighbor commande. Si vous incluez l’instruction drop-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont supprimées lorsque le nombre de préfixes dépasse le pourcentage. Si vous incluez l’instruction hide-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont masquées lorsque le nombre de préfixes dépasse le pourcentage. Si le pourcentage est modifié, les routes sont automatiquement réévaluées.
Dans Junos OS version 9.2 et versions ultérieures, vous pouvez également configurer une limite au nombre de préfixes acceptés sur une session pair BGP. Pour plus d’informations, reportez-vous à la section Limitation du nombre de préfixes acceptés sur une session peer BGP.
Limitation du nombre de préfixes acceptés sur une session peer BGP
Dans junos OS version 9.2 et versions ultérieures, vous pouvez limiter le nombre de préfixes pouvant être acceptés sur une session pair BGP. Lorsque la limite spécifiée est dépassée, un message de journal système est envoyé. Vous pouvez également spécifier de réinitialiser la session BGP si la limite du nombre de préfixes spécifiés est dépassée.
Pour configurer une limite au nombre de préfixes pouvant être acceptés sur une session pair BGP, incluez l’instruction accepted-prefix-limit :
accepted-prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop <percentage>; hide <percentage>; }
Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.
Pour maximum number, spécifiez une valeur dans la plage de 1 à 4 294 967 295.
Incluez l’instruction teardown permettant de réinitialiser la session peer BGP lorsque le nombre de préfixes acceptés dépasse la limite configurée. Vous pouvez également inclure une valeur en pourcentage de 1 à 100 pour envoyer un message de journal système lorsque le nombre de préfixes acceptés dépasse ce pourcentage de la limite maximale. Par défaut, une session BGP réinitialisée est rétablie dans un court laps de temps. Incluez l’instruction idle-timeout pour empêcher la session BGP d’être rétablie pour une période de temps spécifiée. Vous pouvez configurer une valeur de délai d’expiration de 1 à 2 400 minutes. Incluez l’option forever permettant d’empêcher le rétablissement de la session BGP tant que vous n’avez pas passé la clear bgp neighbor commande. Si vous incluez l’instruction drop-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont supprimées lorsque le nombre de préfixes dépasse le pourcentage. Si vous incluez l’instruction hide-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont masquées lorsque le nombre de préfixes dépasse le pourcentage. Si le pourcentage est modifié, les routes sont automatiquement réévaluées.
Lorsque le routage actif sans interruption (NSR) est activé et qu’un basculement vers un moteur de routage de secours se produit, les pairs BGP qui sont en panne sont automatiquement redémarrés. Les pairs sont redémarrés même si l’instruction idle-timeout forever est configurée.
Vous pouvez également configurer une limite au nombre de préfixes pouvant être reçus (par opposition à acceptés) sur une session pair BGP. Pour plus d’informations, reportez-vous à la section Limitation du nombre de préfixes reçus sur une session peer BGP.
Configuration des groupes de tables de routage BGP
Lorsqu’une session BGP reçoit un NLRI unicast ou multicast, elle installe le routage dans la table appropriée (inet.0ou inet6.0 pour l’unicast, ou inet6.2inet.2 pour le multicast). Pour ajouter des préfixes unicast aux tables unicast et multicast, vous pouvez configurer des groupes de tables de routage BGP. Ceci est utile si vous ne pouvez pas effectuer de négociation NLRI multicast.
Pour configurer des groupes de tables de routage BGP, incluez l’énoncé rib-group :
rib-group group-name;
Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.
Résolution de routes vers des équipements de routage PE situés dans d’autres ass
Vous pouvez autoriser les routes étiquetées à être placées dans la table de routage pour la résolution des inet.3 routes. Ces routes sont ensuite résolues pour les connexions d’équipements de routage de périphérie de fournisseur (PE) où le PE distant est situé sur un autre système autonome (AS). Pour qu’un équipement de routage PE installe un routage dans l’instance de routage et de transfert VPN (VRF), le saut suivant doit être résolu vers un routage stocké dans la inet.3 table.
Pour résoudre les routes dans la inet.3 table de routage, incluez l’instruction resolve-vpn :
resolve-vpn group-name;
Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.
Autoriser les routes étiquetées et non étiquetées
Vous pouvez autoriser l’échange de routes étiquetées et non étiquetées en une seule session. Les routes étiquetées sont placées dans la table de routage inet.3 ou inet6.3, et les routes unicast étiquetées et non étiquetées peuvent être envoyées ou reçues par l’équipement de routage.
Pour permettre l’échange de routes étiquetées et non étiquetées, incluez l’énoncé rib :
rib (inet.3 | inet6.3);
Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.
Exemple : Configuration des routes BGP IPv6 sur le transport IPv4
Cet exemple montre comment exporter les préfixes IPv6 et IPv4 sur une connexion IPv4 où les deux côtés sont configurés avec une interface IPv4.
Conditions préalables
Aucune configuration spéciale au-delà de l’initialisation de l’équipement n’est requise avant de configurer cet exemple.
Présentation
Gardez à l’esprit les éléments suivants lors de l’exportation des préfixes BGP IPv6 :
BGP tire des préfixes de saut suivant à l’aide du préfixe IPv4 mappé IPv6. Par exemple, le préfixe IPv4 se traduit par le préfixe
10.19.1.1de saut suivant IPv6 ::ffff:10.19.1.1.REMARQUE :Il doit y avoir une route active vers le saut suivant IPv6 mappé IPv4 pour exporter les préfixes BGP IPv6.
Une connexion IPv6 doit être configurée sur la liaison. La connexion doit être soit un tunnel IPv6, soit une configuration double pile. Le double empilage est utilisé dans cet exemple.
Lors de la configuration des préfixes IPv6 mappés IPv4, utilisez un masque de plus de 96 bits.
Configurez un routage statique si vous souhaitez utiliser des préfixes IPv6 normaux. Cet exemple utilise des routes statiques.
Figure 1 affiche la topologie de l’exemple.
Configuration
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.
Équipement R1
set interfaces fe-1/2/0 unit 1 family inet address 192.168.10.1/24 set interfaces fe-1/2/0 unit 1 family inet6 address ::ffff:192.168.10.1/120 set interfaces lo0 unit 1 family inet address 10.10.10.1/32 set protocols bgp group ext type external set protocols bgp group ext family inet unicast set protocols bgp group ext family inet6 unicast set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 192.168.10.10 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options rib inet6.0 static route ::ffff:192.168.20.0/120 next-hop ::ffff:192.168.10.10 set routing-options static route 192.168.20.0/24 next-hop 192.168.10.10 set routing-options autonomous-system 100
Équipement R2
set interfaces fe-1/2/0 unit 2 family inet address 192.168.10.10/24 set interfaces fe-1/2/0 unit 2 family inet6 address ::ffff:192.168.10.10/120 set interfaces fe-1/2/1 unit 3 family inet address 192.168.20.21/24 set interfaces fe-1/2/1 unit 3 family inet6 address ::ffff:192.168.20.21/120 set interfaces lo0 unit 2 family inet address 10.10.0.1/32 set protocols bgp group ext type external set protocols bgp group ext family inet unicast set protocols bgp group ext family inet6 unicast set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext neighbor 192.168.10.1 peer-as 100 set protocols bgp group ext neighbor 192.168.20.1 peer-as 300 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options autonomous-system 200
Équipement R3
set interfaces fe-1/2/0 unit 4 family inet address 192.168.20.1/24 set interfaces fe-1/2/0 unit 4 family inet6 address ::ffff:192.168.20.1/120 set interfaces lo0 unit 3 family inet address 10.10.20.1/32 set protocols bgp group ext type external set protocols bgp group ext family inet unicast set protocols bgp group ext family inet6 unicast set protocols bgp group ext export send-direct set protocols bgp group ext export send-static set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 192.168.20.21 set policy-options policy-statement send-direct term 1 from protocol direct set policy-options policy-statement send-direct term 1 then accept set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options rib inet6.0 static route ::ffff:192.168.10.0/120 next-hop ::ffff:192.168.20.21 set routing-options static route 192.168.10.0/24 next-hop 192.168.20.21 set routing-options autonomous-system 300
Configuration de l’équipement R1
Procédure étape par étape
Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
Pour configurer l’équipement R1 :
Configurez les interfaces, y compris une adresse IPv4 et une adresse IPv6.
[edit interfaces] user@R1# set fe-1/2/0 unit 1 family inet address 192.168.10.1/24 user@R1# set fe-1/2/0 unit 1 family inet6 address ::ffff:192.168.10.1/120 user@R1# set lo0 unit 1 family inet address 10.10.10.1/32
Configurez EBGP.
[edit protocols bgp group ext] user@R1# set type external user@R1# set export send-direct user@R1# set export send-static user@R1# set peer-as 200 user@R1# set neighbor 192.168.10.10
-
Activez BGP pour transporter des routes unicast IPv4 et IPv6.
[edit protocols bgp group ext] user@R1# set family inet unicast user@R1# set family inet6 unicast
Les routes unicast IPv4 sont activées par défaut. Toutefois, lorsque vous configurez d’autres familles d’adresses NLRI, l’unicast IPv4 doit être explicitement configuré.
-
Configurez la stratégie de routage.
[edit policy-options] user@R1# set policy-statement send-direct term 1 from protocol direct user@R1# set policy-statement send-direct term 1 then accept user@R1# set policy-statement send-static term 1 from protocol static user@R1# set policy-statement send-static term 1 then accept
Configurez des routes statiques.
[edit routing-options] user@R1# set rib inet6.0 static route ::ffff:192.168.20.0/120 next-hop ::ffff:192.168.10.10 user@R1# set static route 192.168.20.0/24 next-hop 192.168.10.10
Configurez le numéro du système autonome (AS).
[edit routing-options] user@R1# set autonomous-system 100
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant le show interfaces, show policy-options, show protocolset les show routing-options commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@R1# show interfaces
fe-1/2/0 {
unit 1 {
family inet {
address 192.168.10.1/24;
}
family inet6 {
address ::ffff:192.168.10.1/120;
}
}
}
lo0 {
unit 1 {
family inet {
address 10.10.10.1/32;
}
}
}
user@R1# show policy-options
policy-statement send-direct {
term 1 {
from protocol direct;
then accept;
}
}
policy-statement send-static {
term 1 {
from protocol static;
then accept;
}
}
user@R1# show protocols
bgp {
group ext {
type external;
family inet {
unicast;
}
family inet6 {
unicast;
}
export [ send-direct send-static ];
peer-as 200;
neighbor 192.168.10.10;
}
}
user@R1# show routing-options
rib inet6.0 {
static {
route ::ffff:192.168.20.0/120 next-hop ::ffff:192.168.10.10;
}
}
static {
route 192.168.20.0/24 next-hop 192.168.10.10;
}
autonomous-system 100;
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration. Répétez la configuration sur les équipements R2 et R3, en modifiant les noms d’interface et les adresses IP, selon les besoins.
Vérification
Vérifiez que la configuration fonctionne correctement.
Vérification de l’état du voisin
But
Assurez-vous que BGP est activé pour transporter des routes unicast IPv6.
Action
Depuis le mode opérationnel, saisissez la show bgp neighbor commande.
user@R2> show bgp neighbor
Peer: 192.168.10.1+179 AS 100 Local: 192.168.10.10+54226 AS 200
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-direct send-static ]
Options: <Preference AddressFamily PeerAS Refresh>
Address families configured: inet-unicast inet6-unicast
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.10.10.1 Local ID: 10.10.0.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
Local Interface: fe-1/2/0.2
NLRI for restart configured on peer: inet-unicast inet6-unicast
NLRI advertised by peer: inet-unicast inet6-unicast
NLRI for this session: inet-unicast inet6-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast inet6-unicast
NLRI of received end-of-rib markers: inet-unicast inet6-unicast
NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast
Peer supports 4 byte AS extension (peer-as 100)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 3
Accepted prefixes: 2
Suppressed due to damping: 0
Advertised prefixes: 4
Table inet6.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 2
Last traffic (seconds): Received 24 Sent 12 Checked 60
Input messages: Total 132 Updates 6 Refreshes 0 Octets 2700
Output messages: Total 133 Updates 3 Refreshes 0 Octets 2772
Output Queue[0]: 0
Output Queue[1]: 0
Peer: 192.168.20.1+179 AS 300 Local: 192.168.20.21+54706 AS 200
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ send-direct send-static ]
Options: <Preference AddressFamily PeerAS Refresh>
Address families configured: inet-unicast inet6-unicast
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.10.20.1 Local ID: 10.10.0.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 1
BFD: disabled, down
Local Interface: fe-1/2/1.3
NLRI for restart configured on peer: inet-unicast inet6-unicast
NLRI advertised by peer: inet-unicast inet6-unicast
NLRI for this session: inet-unicast inet6-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast inet6-unicast
NLRI of received end-of-rib markers: inet-unicast inet6-unicast
NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast
Peer supports 4 byte AS extension (peer-as 300)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 3
Accepted prefixes: 2
Suppressed due to damping: 0
Advertised prefixes: 4
Table inet6.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 2
Last traffic (seconds): Received 1 Sent 15 Checked 75
Input messages: Total 133 Updates 6 Refreshes 0 Octets 2719
Output messages: Total 131 Updates 3 Refreshes 0 Octets 2734
Output Queue[0]: 0
Output Queue[1]: 0Sens
Les différentes occurrences de inet6-unicast la sortie montrent que BGP est activé pour transporter des routes unicast IPv6.
Vérification de la table de routage
But
Assurez-vous que l’équipement R2 dispose de routes BGP dans sa table de routage inet6.0.
Action
Depuis le mode opérationnel, saisissez la show route protocol bgp inet6.0 commande.
user@R2> show route protocol bgp table inet6.0
inet6.0: 7 destinations, 10 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
::ffff:192.168.10.0/120 [BGP/170] 01:03:49, localpref 100, from 192.168.20.1
AS path: 300 I
> to ::ffff:192.168.20.21 via fe-1/2/1.3
::ffff:192.168.20.0/120 [BGP/170] 01:03:53, localpref 100, from 192.168.10.1
AS path: 100 I
> to ::ffff:192.168.10.10 via fe-1/2/0.2Présentation des routes IPv4 publicitaires sur les sessions IPv6 BGP
Dans un réseau IPv6, BGP annonce généralement les informations d’accessibilité de la couche réseau IPv6 sur une session IPv6 entre pairs BGP. Dans les versions précédentes, Junos OS ne supportait que l’échange de familles d’adresses unicast inet6, multicast inet6 ou inet6 labeled-unicast uniquement. Cette fonctionnalité permet d’échanger toutes les familles d’adresses BGP. Dans un environnement double pile avec IPv6 en son cœur. cette fonctionnalité permet à BGP de promouvoir l’accessibilité unicast IPv4 avec le saut suivant IPv4 sur une session BGP IPv6.
Cette fonctionnalité est uniquement pour les sessions IPv6 BGP, où IPv4 est configuré sur les deux points de terminaison. Il local-ipv4-address peut s’agir d’une adresse de bouclage ou d’une adresse ipv4 pour une session IBGP ou EBGP à sauts multiples. Pour les haut-parleurs BGP externes à saut unique qui ne font pas partie des confédérations BGP, si l’adresse IPv4 locale configurée n’est pas directement connectée, la session BGP est fermée et reste inactive et une erreur est générée, qui s’affiche dans la sortie de la show bgp neighbor commande.
Pour activer la publicité de routage IPv4 sur une session IPv6, configurez local-ipv4-address comme suit :
[edit protocols bgp family inet unicast] local-ipv4-address local ipv4 address;
Vous ne pouvez pas configurer cette fonctionnalité pour les familles d’adresses unicast inet6, multicast inet6 ou inet6 labeled-unicast, car BGP est déjà en mesure d’annoncer ces familles d’adresses sur une session BGP IPv6.
La configuration local-ipv4-address est utilisée uniquement lorsque BGP annonce des routes avec un saut automatique. Lorsque IBGP annonce des routes apprises auprès de pairs EBGP ou que le réflecteur de route annonce des routes BGP à ses clients, BGP ne modifie pas le saut suivant de route, ignore la configuration local-ipv4-addresset utilise le saut suivant IPv4 d’origine.
Voir également
Exemple : Routes IPv4 publicitaires sur les sessions BGP IPv6
Cet exemple montre comment annoncer des routes IPv4 sur une session BGP IPv6. Dans un environnement double pile avec IPv6 en son cœur, il est nécessaire d’atteindre les hôtes IPv4 distants. Par conséquent, BGP annonce les routes IPv4 avec les sauts suivants IPv4 aux pairs BGP sur les sessions BGP à l’aide d’adresses source et de destination IPv6. Cette fonctionnalité permet à BGP de promouvoir l’accessibilité unicast IPv4 avec le saut suivant IPv4 sur les sessions BGP IPv6.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
Trois routeurs avec double capacité d’empilage
Junos OS Version 16.1 ou ultérieure s’exécutant sur tous les équipements
Avant d’activer les publicités IPv4 sur les sessions BGP IPv6, assurez-vous de :
Configurez les interfaces de l’équipement.
Configurez l’empilement double sur tous les équipements.
Présentation
À partir de la version 16.1, Junos OS permet à BGP de promouvoir l’accessibilité unicast IPv4 avec le saut suivant IPv4 sur une session BGP IPv6. Dans les versions précédentes de Junos OS, BGP ne pouvait faire la publicité que des familles d’adresses unicast inet6, inet6 multicast et inet6 étiquetées unicast sur des sessions BGP IPv6. Cette fonctionnalité permet à BGP d’échanger toutes les familles d’adresses BGP sur une session IPv6. Vous pouvez activer BGP pour annoncer les routes IPv4 avec les sauts suivants IPv4 auprès de pairs BGP sur une session IPv6. La configuration local-ipv4-address est utilisée uniquement lorsque BGP annonce des routes avec un saut automatique.
Vous ne pouvez pas configurer cette fonctionnalité pour les familles d’adresses unicast inet6, multicast inet6 ou inet6 labeled-unicast, car BGP est déjà en mesure d’annoncer ces familles d’adresses sur une session BGP IPv6.
topologie
Dans Figure 2, une session BGP externe IPv6 s’exécute entre les routeurs R1 et R2. Une session IBGP IPv6 est établie entre le routeur R2 et le routeur R3. Les routes statiques IPv4 sont redistribuées au BGP sur R1. Pour redistribuer les routes IPv4 sur la session BGP IPv6, la nouvelle fonctionnalité doit être activée sur tous les routeurs au niveau de la [edit protocols bgp address family] hiérarchie.
Configuration
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit à partir du mode de configuration.
Routeur R1
set interfaces ge-0/0/0 unit 0 description R1->R2 set interfaces ge-0/0/0 unit 0 family inet address 140.1.1.1/24 set interfaces ge-0/0/0 unit 0 family inet6 address ::140.1.1.1/126 set interfaces lo0 unit 0 family inet6 address 1::1/128 set routing-options static route 11.1.1.1/32 discard set routing-options static route 11.1.1.2/32 discard set routing-options autonomous-system 64497 set protocols bgp group ebgp-v6 type external set protocols bgp group ebgp-v6 export p1 set protocols bgp group ebgp-v6 peer-as 64496 set protocols bgp group ebgp-v6 neighbor ::140.1.1.2 description R2 set protocols bgp group ebgp-v6 neighbor ::140.1.1.2 family inet unicast local-ipv4-address 140.1.1.1 set policy-options policy-statement p1 from protocol static set policy-options policy-statement p1 then accept
Routeur R2
set interfaces ge-0/0/0 unit 0 description R2->R1 set interfaces ge-0/0/0 unit 0 family inet address 140.1.1.2/24 set interfaces ge-0/0/0 unit 0 family inet6 address ::140.1.1.2/126 set interfaces ge-0/0/1 unit 0 description R2->R3 set interfaces ge-0/0/1 unit 0 family inet address 150.1.1.1/24 set interfaces ge-0/0/1 unit 0 family inet6 address ::150.1.1.1/126 set interfaces lo0 unit 0 family inet6 address 1::2/128 set routing-options autonomous-system 64496 set protocols bgp group ibgp-v6 type internal set protocols bgp group ibgp-v6 export change-nh set protocols bgp group ibgp-v6 neighbor ::150.1.1.2 description R3 set protocols bgp group ibgp-v6 neighbor ::150.1.1.2 family inet unicast local-ipv4-address 150.1.1.1 set protocols bgp group ebgp-v6 type external set protocols bgp group ebgp-v6 peer-as 64497 set protocols bgp group ebgp-v6 neighbor ::140.1.1.1 description R1 set protocols bgp group ebgp-v6 neighbor ::140.1.1.1 family inet unicast local-ipv4-address 140.1.1.2 set policy-options policy-statement change-nh from protocol bgp set policy-options policy-statement change-nh then next-hop self set policy-options policy-statement change-nh then accept
Routeur R3
set interfaces ge-0/0/0 unit 0 description R3->R2 set interfaces ge-0/0/0 unit 0 family inet address 150.1.1.2/24 set interfaces ge-0/0/0 unit 0 family inet6 address ::150.1.1.2/126 set interfaces lo0 unit 0 family inet6 address 1::3/128 set routing-options autonomous-system 64496 set protocols bgp group ibgp-v6 type internal set protocols bgp group ibgp-v6 neighbor ::150.1.1.1 description R2 set protocols bgp group ibgp-v6 neighbor ::150.1.1.1 family inet unicast local-ipv4-address 150.1.1.2
Configuration du routeur R1
Procédure étape par étape
L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation sur l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le guide de l’utilisateur CLI.
Pour configurer le routeur R1 :
Répétez cette procédure pour les autres routeurs après avoir modifié les noms d’interface, adresses et autres paramètres appropriés.
Configurez les interfaces avec des adresses IPv4 et IPv6.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 description R1->R2 user@R1# set ge-0/0/0 unit 0 family inet address 140.1.1.1/24 user@R1# set ge-0/0/0 unit 0 family inet6 address ::140.1.1.1/126
Configurez l’adresse de bouclage.
[edit interfaces] user@R1# set lo0 unit 0 family inet6 address 1::1/128
Configurez un routage statique IPv4 qui doit être annoncé.
[edit routing-options] user@R1# set static route 11.1.1.1/32 discard user@R1# set static route 11.1.1.2/32 discard
Configurez le système autonome pour les hôtes BGP.
[edit routing-options] user@R1# set autonomous-system 64497
Configurez EBGP sur les routeurs de périphérie externes.
[edit protocols] user@R1# set bgp group ebgp-v6 type external user@R1# set bgp group ebgp-v6 peer-as 64496 user@R1# set bgp group ebgp-v6 neighbor ::140.1.1.2 description R2
Activez la fonctionnalité pour faire la publicité de l’adddress IPv4 140.1.1.1 sur les sessions IPv6 BGP.
[edit protocols] user@R1# set bgp group ebgp-v6 neighbor ::140.1.1.2 family inet unicast local-ipv4-address 140.1.1.1
Définissez une stratégie p1 pour accepter toutes les routes statiques.
[edit policy-options] user@R1# set policy-statement p1 from protocol static user@R1# set policy-statement p1 then accept
Appliquez la stratégie p1 sur le groupe EBGP ebgp-v6.
[edit protocols] user@R1# set bgp group ebgp-v6 export p1
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant le show interfaces, show protocols, show routing-optionset les show policy-options commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
description R1->R2;
family inet {
address 140.1.1.1/24;
}
family inet6 {
address ::140.1.1.1/126;
}
}
lo0 {
unit 0 {
family inet {
address 1::1/128;
}
}
}
}
[edit]
user@R1# show protocols
bgp {
group ebgp-v6 {
type external;
export p1;
peer-as 64496;
neighbor ::140.1.1.2 {
description R2;
family inet {
unicast {
local-ipv4-address 140.1.1.1;
}
}
}
}
}
[edit]
user@R1# show routing-options
static {
route 11.1.1.1/32 discard;
route 11.1.1.2/32 discard;
}
autonomous-system 64497;
[edit]
user@R1# show policy-options
policy-statement p1 {
from {
protocol static;
}
then accept;
}
Si vous avez fini de configurer l’équipement, validez la configuration.
user@R1# commit
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérifier que la session BGP est en cours
- Vérifier que l’adresse IPv4 est annoncée
- Vérifier que le routeur voisin BGP R2 reçoit l’adresse IPv4 annoncée
Vérifier que la session BGP est en cours
But
Vérifiez que BGP s’exécute sur les interfaces configurées et que la session BGP est active pour chaque adresse voisine.
Action
À partir du mode opérationnel, exécutez la commande sur le show bgp summary routeur R1.
user@R1> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
::140.1.1.2 64496 4140 4158 0 0 1d 7:10:36 0/0/0/0 0/0/0/0
Sens
La session BGP est opérationnelle et l’appairage BGP est établi.
Vérifier que l’adresse IPv4 est annoncée
But
Vérifiez que l’adresse IPv4 configurée est annoncée par le routeur R1 aux voisins BGP configurés.
Action
À partir du mode opérationnel, exécutez la commande sur le show route advertising-protocol bgp ::150.1.1.2 routeur R1.
user@R1> show route advertising-protocol bgp ::150.1.1.2 inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 11.1.1.1/32 Self 64497 64497 I * 11.1.1.2/32 Self 64497 64497 I
Sens
Le routage statique IPv4 est annoncé au routeur voisin BGP R2.
Vérifier que le routeur voisin BGP R2 reçoit l’adresse IPv4 annoncée
But
Vérifiez que le routeur R2 reçoit l’adresse IPv4 que le routeur R1 annonce au voisin BGP sur IPv6.
Action
user@R2> show route receive-protocol bgp ::140.1.1.1 inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 11.1.1.1/32 140.1.1.1 64497 I * 11.1.1.2/32 140.1.1.1 64497 I iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) inet6.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
Sens
La présence du routage IPv4 statique dans la table de routage du routeur R2 indique qu’il reçoit les routes IPv4 annoncées du routeur R1.
Comprendre la redistribution des routes IPv4 avec le saut suivant IPv6 dans BGP
Dans un réseau qui transporte principalement le trafic IPv6, il est nécessaire de router des routes IPv4 si nécessaire. Par exemple, un fournisseur d’accès Internet qui dispose d’un réseau IPv6 uniquement, mais dont les clients continuent de router le trafic IPv4. Dans ce cas, il est nécessaire de répondre aux besoins de ces clients et de transférer le trafic IPv4 sur un réseau IPv6. Comme décrit dans la RFC 5549, les informations publicitaires sur l’accessibilité de la couche réseau IPv4 avec un trafic IPv6 de saut IPv4 sont tunnelisées depuis les équipements des locaux clients (CPE) vers les passerelles IPv4-over-IPv6. Ces passerelles sont annoncées aux équipements CPE via des adresses anycast. Les équipements de passerelle créent ensuite des tunnels IPv4 sur IPv6 dynamiques vers les équipements CPE distants et annoncent des routes agrégées IPv4 pour orienter le trafic.
La fonctionnalité de tunnel IPv4 sur IPv6 dynamique ne prend pas en charge la norme ISSU unifiée dans la version 17.3R1 de Junos OS.
Les réflecteurs de route (RR) dotés d’une interface programmable sont connectés via IBGP aux routeurs de passerelle et aux routes hôtes avec l’adresse IPv6 comme saut suivant. Ces RR annoncent les adresses IPv4/32 pour injecter des informations sur le tunnel dans le réseau. Les routeurs de passerelle créent des tunnels IPv4 sur IPv6 dynamiques vers la périphérie du fournisseur distant. Le routeur de passerelle annonce également les routes agrégées IPv4 pour orienter le trafic. Le RR annonce ensuite les routes source des tunnels au FAI. Lorsque le RR retire la route du tunnel, BGP retire également la route, ce qui entraîne le démontage du tunnel et le CPE inaccessible. Le routeur de passerelle retire également les routes d’agrégation IPv4 et les routes source de tunnel IPv6 lorsque toutes les routes agrégées sont supprimées. Le routeur de passerelle envoie un retrait de route lorsque la carte d’interface du moteur de transfert de paquets d’ancrage tombe en panne, de sorte qu’il redirige le trafic vers d’autres routeurs de passerelle.
Les extensions suivantes sont introduites pour prendre en charge les routes IPv4 avec un saut suivant IPv6 :
- Codage du saut suivant BGP
- Localisation de tunnel
- Gestion des tunnels
- Gestion des défaillances du moteur d’équilibrage de charge des tunnels et de transfert de paquets d’ancrage
- Statistiques de flux de bouclage de tunnel
Codage du saut suivant BGP
BGP est étendu avec la fonctionnalité d’encodage du saut suivant qui est utilisée pour envoyer des routes IPv4 avec les sauts suivants IPv6. Si cette fonctionnalité n’est pas disponible sur l’homologue distant, BGP les regroupe en fonction de cette capacité d’encodage et supprime la famille BGP sans capacité d’encodage de la liste d’informations d’accessibilité de la couche réseau (NLRI) négociée. Junos OS n’autorise qu’une seule table de résolution telle que inet.0. Pour autoriser les routes BGP IPv4 avec les sauts suivants IPv6, BGP crée un nouvel arbre de résolution. Cette fonctionnalité permet à une table de routage Junos OS d’avoir plusieurs arbres de résolution.
Outre la RFC 5549, des informations d’accessibilité de la couche réseau IPv4 publicitaires avec un saut suivant IPv6 , une nouvelle communauté d’encapsulation spécifiée dans la RFC 5512, l’identifiant saFI (Next Address Family Identifier) BGP et l’attribut d’encapsulation du tunnel BGP est introduite pour déterminer la famille d’adresses de l’adresse du saut suivant. La communauté d’encapsulation indique le type de tunnels que le nœud d’entrée doit créer. Lorsque BGP reçoit des routes IPv4 avec l’adresse de saut suivant IPv6 et la communauté d’encapsulation V4oV6, alors BGP crée des tunnels dynamiques IPv4-over-IPv6. Lorsque BGP reçoit des routes sans la communauté d’encapsulation, les routes BGP sont résolues sans créer le tunnel V4oV6.
Une nouvelle action dynamic-tunnel-attributes dyan-attribute de stratégie est disponible au niveau de la [edit policy-statement policy name term then] hiérarchie pour prendre en charge la nouvelle encapsulation étendue.
Localisation de tunnel
L’infrastructure de tunnel dynamique est améliorée grâce à la localisation des tunnels pour prendre en charge un plus grand nombre de tunnels. La localisation des tunnels est nécessaire pour assurer la résilience nécessaire pour gérer le trafic en cas de défaillance de l’ancre. Un ou plusieurs châssis se sauvegardent les uns les autres et permettent au processus de protocole de routage (rpd) d’éloigner le trafic du point de défaillance vers le châssis de secours. Le châssis annonce uniquement ces préfixes agrégés au lieu des adresses de bouclage individuelles dans le réseau.
Gestion des tunnels
Les tunnels IPv4 sur IPv6 utilisent l’infrastructure de tunnel dynamique et l’ancrage de tunnel pour prendre en charge le châssis requis à grande échelle. L’état du tunnel est localisé dans un moteur de transfert de paquets et les autres moteurs de transfert de paquets orientent le trafic vers l’ancre du tunnel.
Entrée de tunnel
Encapsule le trafic IPv4 dans l’en-tête IPv6.
L’application maximale des unités de transmission (MTU) est effectuée avant l’encapsulation. Si la taille du paquet encapsulé dépasse le MTU du tunnel et que le paquet IPv4 n’est
DF-bitpas défini, alors le paquet est fragmenté et ces fragments sont encapsulés.Utilise l’équilibrage de charge du trafic basé sur le hachage sur les en-têtes de paquets internes.
Transfère le trafic à l’adresse IPv6 de destination. L’adresse IPv6 est tirée de l’en-tête IPv6.
Sortie de tunnel
Décapite le paquet IPv4 présent à l’intérieur du paquet IPv6.
Effectue une vérification anti-usurpage pour s’assurer que la paire IPv6 et IPv4 correspond aux informations utilisées pour configurer le tunnel.
Recherche l’adresse de destination IPv4 à partir de l’en-tête IPv4 du paquet décapité et transfère le paquet à l’adresse IPv4 spécifiée.
Gestion des défaillances du moteur d’équilibrage de charge des tunnels et de transfert de paquets d’ancrage
La défaillance du moteur de transfert de paquets doit être traitée rapidement pour éviter le filtrage de route null du trafic de tunnel ancré sur le moteur de transfert de paquets. La localisation de tunnel implique l’utilisation de publicités BGP pour réparer la défaillance dans le monde entier. Le trafic du tunnel est détourné du point de défaillance vers un autre châssis de secours contenant l’état du tunnel identique. Pour l’équilibrage de charge du trafic, le châssis est configuré pour annoncer différentes valeurs med (multiple exit discriminator) pour chacun des ensembles de préfixes, de sorte que seul le trafic d’un quart des tunnels passe par chaque châssis. Le trafic CPE est également géré de la même manière en configurant le même ensemble d’adresses anycast sur chaque châssis et en orientant seulement un quart du trafic vers chaque châssis.
Le moteur de transfert de paquets d’ancre est l’entité unique qui traite tous les tunnels. La sélection du moteur de transfert de paquets d’ancrage passe par un provisionnement statique et lié aux interfaces physiques du moteur de transfert de paquets. Lorsque l’un des moteurs de transfert de paquets tombe en panne, le démon marque tous les moteurs de transfert de paquets vers le bas sur la carte de ligne et communique ces informations au processus de protocole de routage du protocole de routage et à d’autres processus. Le processus de protocole de routage envoie des retraits BGP pour les préfixes qui sont ancrés sur le moteur de transfert de paquets défaillant et les adresses IPv6 attribuées au moteur de transfert de paquets en panne. Ces publicités redirigent le trafic vers d’autres châssis de secours. Lorsque le moteur de transfert de paquets défaillant est à nouveau opérationnel, le châssis marque le moteur de transfert de paquets comme up et met à jour le processus de protocole de routage. Le processus de protocole de routage déclenche des mises à jour BGP pour ses pairs que les tunnels ancrés au moteur de transfert de paquets spécifiques sont désormais disponibles pour le routage du trafic. La configuration d’un tunnel à grande échelle peut prendre quelques minutes. Par conséquent, le Ack mécanisme est intégré au système pour garantir une perte de trafic minimale tout en ramenant le trafic au châssis d’origine.
Statistiques de flux de bouclage de tunnel
L’infrastructure de tunnel dynamique utilise des flux de bouclage dans le moteur de transfert de paquets pour boucler le paquet après l’encapsulation. Étant donné que la bande passante de ce flux de bouclage est limitée, il est nécessaire de surveiller les performances des flux de bouclage de tunnel.
Pour surveiller les statistiques du flux de bouclage, utilisez la commande show pfe statistics traffic detail opérationnelle qui affiche les statistiques agrégées du flux de bouclage, y compris le taux de transfert, le taux de perte de paquets et le taux d’octets.
Voir également
Configuration de BGP pour redistribuer des routes IPv4 avec des adresses de saut suivant IPv6
À partir de la version 17.3R1, les équipements Junos OS peuvent transférer le trafic IPv4 sur un réseau IPv6 uniquement, qui ne peut généralement pas transférer le trafic IPv4. Comme décrit dans la RFC 5549, le trafic IPv4 est tunnelisé des équipements CPE aux passerelles IPv4-over-IPv6. Ces passerelles sont annoncées aux équipements CPE via des adresses anycast. Les équipements de passerelle créent ensuite des tunnels IPv4 sur IPv6 dynamiques vers les équipements des clients distants et annoncent des routes agrégées IPv4 pour orienter le trafic. Les réflecteurs de route avec interfaces programmables injectent des informations sur le tunnel dans le réseau. Les réflecteurs de route sont connectés via IBGP aux routeurs de passerelle, qui annoncent les adresses IPv4 des routes hôtes avec des adresses IPv6 comme saut suivant.
La fonctionnalité de tunnel IPv4 sur IPv6 dynamique ne prend pas en charge la norme ISSU unifiée dans la version 17.3R1 de Junos OS.
Avant de commencer à configurer BGP pour distribuer des routes IPv4 avec des adresses de saut suivant IPv6, effectuez les opérations suivantes :
Configurez les interfaces de l’équipement.
Configurez OSPF ou tout autre protocole IGP.
Configurez MPLS et LDP.
Configurez BGP.
Pour configurer BGP pour distribuer des routes IPv4 avec des adresses de saut suivant IPv6 :
Voir également
Activation de la signalisation VPN de couche 2 et VPLS
Vous pouvez activer BGP pour transporter des messages VPN de couche 2 et VPLS NLRI.
Pour activer la signalisation VPN et VPLS, incluez la family déclaration :
family { l2vpn { signaling { prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>; } } } }
Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.
Pour configurer un nombre maximal de préfixes, incluez l’instruction prefix-limit :
prefix-limit { maximum number; teardown <percentage> <idle-timeout (forever | minutes)>; drop-excess <percentage>; hide-excess <percentage>;}
Pour obtenir une liste des niveaux hiérarchiques auxquels vous pouvez inclure cette déclaration, consultez la section récapitulatif de l’instruction pour cette déclaration.
Lorsque vous définissez le nombre maximal de préfixes, un message est journalisé lorsque ce nombre est atteint. Si vous incluez l’instruction teardown , la session est détruite lorsque le nombre maximal de préfixes est atteint. Si vous spécifiez un pourcentage, les messages sont enregistrés lorsque le nombre de préfixes atteint ce pourcentage. Une fois la session détruite, elle est rétablie dans un court laps de temps. Incluez l’instruction idle-timeout permettant de maintenir la session en panne pendant un certain temps, ou pour toujours. Si vous spécifiez forever, la session n’est rétablie qu’après avoir utilisé la clear bgp neighbor commande. Si vous incluez l’instruction drop-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont supprimées lorsque le nombre de préfixes dépasse le pourcentage. Si vous incluez l’instruction hide-excess <percentage> et spécifiez un pourcentage, les routes excédentaires sont masquées lorsque le nombre de préfixes dépasse le pourcentage. Si le pourcentage est modifié, les routes sont automatiquement réévaluées.
Voir également
Comprendre les routes de flux BGP pour le filtrage du trafic
Un routage de flux est une agrégation des conditions de correspondance pour les paquets IP. Les routes de flux sont installées en tant que filtres de table de transfert d’entrée (implicitement) et sont propagées à travers le réseau à l’aide de messages NLRI (Network-specification-layer reachability information) et installées dans la table instance-name.inetflow.0de routage de flux . Les paquets peuvent traverser des routes de flux uniquement si des conditions de correspondance spécifiques sont remplies.
Les routes de flux et les filtres de pare-feu sont similaires en ce qu’ils filtrent les paquets en fonction de leurs composants et effectuent une action sur les paquets correspondant. Les routes de flux fournissent des fonctionnalités de filtrage du trafic et de limitation de débit, comme les filtres de pare-feu. En outre, vous pouvez propager des routes de flux sur différents systèmes autonomes.
Les routes de flux sont propagées par BGP via des messages NLRI de spécification de flux. Vous devez activer BGP pour propager ces NLRIs.
À partir de la version 15.1 de Junos OS, les modifications sont mises en œuvre pour étendre la prise en charge du routage actif sans interruption (NSR) aux familles inet-flow et inetvpn-flow existantes, et étendre la validation du routage pour les flux BGP par draft-ietf-idr-bgp-flowspec-oid-01. Deux nouvelles déclarations sont introduites dans le cadre de cette amélioration. Découvrez l’application avant tout et la non-installation.
À partir de la version 16.1 de Junos OS, la prise en charge d’IPv6 est étendue à la spécification de flux BGP qui permet de propager les règles de spécification des flux de trafic pour les paquets IPv6 et VPN-IPv6. Les spécifications de flux BGP automatisent la coordination des règles de filtrage du trafic afin d’atténuer les attaques par déni de service distribué pendant le routage actif sans interruption (NSR).
À partir de la version 16.1R1 de Junos OS, la spécification de flux BGP prend en charge l’action de filtrage du trafic extended-community . Pour le trafic IPv4, Junos OS modifie les bits de point de code DiffServ (DSCP) d’un paquet IPv4 en transit à la valeur correspondante de la communauté étendue. Pour les paquets IPv6, Junos OS modifie les six premiers bits du traffic class champ du paquet IPv6 de transmission à la valeur correspondante de la communauté étendue.
À partir de la version 17.1R1 de Junos OS, BGP peut transporter des messages NLRI (Network Layer Reachability Information) sur les routeurs PTX Series équipés de SPC de troisième génération (FPC3-PTX-U2 et FPC3-PTX-U3 sur PTX5000 et FPC3-SFF-PTX-U0 et FPC3-SFF-PTX-U1 sur PTX3000). La propagation des informations des filtres de pare-feu dans le cadre de BGP vous permet de propager dynamiquement les filtres de pare-feu contre les attaques par déni de service (DOS) sur les systèmes autonomes.
À partir de la version 17.2R1 de Junos OS, BGP peut transporter des messages NLRI (Network Layer Reachability Information) de spécifications de flux sur les routeurs PTX1000 équipés de PFC de troisième génération. La propagation des informations des filtres de pare-feu dans le cadre de BGP vous permet de propager dynamiquement les filtres de pare-feu contre les attaques par déni de service (DOS) sur les systèmes autonomes.
À partir de la version 20.3R1 de cRPD, les routes de flux et les règles de contrôle propagées via la spécification de flux BGP NLRI sont téléchargées sur le noyau Linux via l’infrastructure Linux Netfilter sur les environnements cRPD.
- Conditions de correspondance pour les routes de flux
- Actions pour les routes de flux
- Validation des routes de flux
- Prise en charge de l’algorithme de spécification de flux BGP version 7 et versions ultérieures
Conditions de correspondance pour les routes de flux
Vous spécifiez les conditions auxquelles le paquet doit correspondre avant que l’action de l’instruction then ne soit prise pour un routage de flux. Toutes les conditions de l’instruction from doivent correspondre pour que l’action soit prise. L’ordre dans lequel vous spécifiez des conditions de correspondance n’est pas important, car un paquet doit correspondre à toutes les conditions d’un terme pour qu’une correspondance se produise.
Pour configurer une condition de correspondance, incluez l’instruction match au niveau de la [edit routing-options flow] hiérarchie.
Tableau 1 décrit les conditions de correspondance du routage de flux.
|
Condition de correspondance |
Description |
|---|---|
|
|
Champ adresse de destination IP. Vous pouvez utiliser le |
|
|
Champ de port de destination TCP ou UDP (User Datagram Protocol). Vous ne pouvez pas spécifier les conditions et Au lieu de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte suivants (les numéros de port sont également répertoriés) : |
|
|
Point de code de services différenciés (DSCP). Le protocole DiffServ utilise l’octet de type de service (ToS) dans l’en-tête IP. Les six bits les plus importants de cet octet forment le DSCP. Vous pouvez spécifier le DSCP sous forme hexadécimale ou décimale. |
|
|
Correspondez à la valeur de l’étiquette de flux. La valeur de ce champ varie de 0 à 1048575. Cette condition de correspondance n’est prise en charge que sur les équipements Junos avec des MPC améliorés configurés pour |
|
|
Champ de type de fragment. Les mots clés sont regroupés par type de fragment auquel ils sont associés :
Cette condition de correspondance n’est prise en charge que sur les équipements Junos OS avec des MPC améliorés configurés pour |
|
|
Champ de code ICMP. Cette valeur ou mot-clé fournit des informations plus spécifiques que Au lieu de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte suivants (les valeurs de champ sont également répertoriées). Les mots clés sont regroupés par type ICMP auquel ils sont associés :
|
|
|
Champ de type de paquet ICMP. Normalement, vous spécifiez cette correspondance conjointement avec l’instruction Au lieu de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte suivants (les valeurs de champ sont également répertoriées) : |
|
|
Longueur totale du paquet IP. |
|
|
Champ source ou port de destination TCP ou UDP. Vous ne pouvez pas spécifier à la fois la Au lieu de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte répertoriés sous |
|
|
Champ protocole IP. Au lieu de la valeur numérique, vous pouvez spécifier l’un des synonymes de texte suivants (les valeurs de champ sont également répertoriées) : Cette condition de correspondance est prise en charge pour IPv6 uniquement sur les équipements Junos avec des MPC améliorés configurés pour |
|
|
Champ adresse source IP. Vous pouvez utiliser le |
|
|
Champ de port source TCP ou UDP. Vous ne pouvez pas spécifier les Au lieu du champ numérique, vous pouvez spécifier l’un des synonymes de texte répertoriés sous |
|
|
Format d’en-tête TCP. |
Actions pour les routes de flux
Vous pouvez spécifier l’action à entreprendre si le paquet correspond aux conditions que vous avez configurées dans le routage de flux. Pour configurer une action, incluez l’instruction then au niveau de la [edit routing-options flow] hiérarchie.
Tableau 2 décrit les actions de routage de flux.
|
Action ou modificateur d’action |
Description |
|---|---|
| Actions | |
|
|
Accepter un paquet. C’est la valeur par défaut. |
|
|
Jeter un paquet en silence, sans envoyer de message ICMP (Internet Control Message Protocol). |
|
|
Remplacez les communautés de la route par les communautés spécifiées. |
|
Marque value |
Définissez une valeur DSCP pour le trafic qui correspond à ce flux. Spécifiez une valeur de 0 à 63. Cette action est prise en charge uniquement sur les équipements Junos avec des MPC améliorés configurés pour |
|
|
Passez à la condition de correspondance suivante pour l’évaluation. |
|
|
Spécifiez une instance de routage vers laquelle les paquets sont transférés. |
|
|
Limitez la bande passante sur le routage de flux. Exprimez la limite en bits par seconde (bps). À partir de la version 16.1R4 de Junos OS, la plage de débit-limite est de [0 à 1000000000000000]. |
|
|
Échantillonner le trafic sur le routage de flux. |
Validation des routes de flux
Junos OS installe des routes de flux dans la table de routage de flux uniquement si elles ont été validées à l’aide de la procédure de validation. Le moteur de routage effectue la validation avant d’installer des routes dans la table de routage de flux.
Les routes de flux reçues à l’aide des messages NLRI (Network Layer Reachability Information) BGP sont validées avant leur installation dans la table instance.inetflow.0de routage des instances primaires de flux . La procédure de validation est décrite dans le draft-ietf-idr-flow-spec-09.txt, Diffusion des règles de spécification de flux. Vous pouvez contourner le processus de validation des routes de flux à l’aide de messages BGP NLRI et utiliser votre propre stratégie d’importation spécifique.
Pour suivre les opérations de validation, incluez l’instruction validation au niveau de la [edit routing-options flow] hiérarchie.
Prise en charge de l’algorithme de spécification de flux BGP version 7 et versions ultérieures
Par défaut, Junos OS utilise l’algorithme de classement défini dans la version 6 du projet de spécification de flux BGP. Dans junos OS version 10.0 et versions ultérieures, vous pouvez configurer le routeur pour qu’il se conforme à l’algorithme de commande de termes défini pour la première fois dans la version 7 de la spécification de flux BGP et pris en charge par le biais de la RFC 5575, Dissemination of Flow Specification Routes.
Nous vous recommandons de configurer Junos OS pour qu’il utilise l’algorithme de classement des termes défini pour la première fois dans la version 7 du projet de spécification de flux BGP. Nous vous recommandons également de configurer Junos OS pour qu’il utilise le même algorithme de commande de termes sur toutes les instances de routage configurées sur un routeur.
Pour configurer BGP de manière à utiliser l’algorithme de spécification de flux défini pour la première fois dans la version 7 du projet Internet, incluez l’instruction standard au niveau de la [edit routing-options flow term-order] hiérarchie.
Pour revenir à l’algorithme de classement des termes défini dans la version 6, incluez l’instruction legacy au niveau de la [edit routing-options flow term-order] hiérarchie.
L’ordre des termes configuré n’a qu’une signification locale. Autrement dit, l’ordre des termes ne se propage pas avec les routes de flux envoyées aux pairs BGP distants, dont l’ordre de termes est entièrement déterminé par leur propre configuration d’ordre de termes. Par conséquent, vous devez être prudent lors de la configuration de l’action next term dépendante de l’ordre lorsque vous n’avez pas connaissance du terme configuration d’ordre des pairs distants. Le local next term peut être différent de celui next term configuré sur l’homologue distant.
Sur Junos OS Evolved, next term ne peut pas apparaître comme le dernier terme de l’action. Un terme de filtre où next term est spécifié en tant qu’action mais sans aucune condition de correspondance configurée n’est pas pris en charge.
À partir de la version 16.1 de Junos OS, vous pouvez ne pas appliquer le flowspec filtre au trafic reçu sur des interfaces spécifiques. Un nouveau terme est ajouté au début du flowspec filtre qui accepte tout paquet reçu sur ces interfaces spécifiques. Le nouveau terme est une variable qui crée une liste d’exclusion des termes joints au filtre de table de transfert dans le cadre du filtre de spécification de flux.
Pour exclure l’application du flowspec filtre au trafic reçu sur des interfaces spécifiques, vous devez d’abord configurer a group-id sur ces interfaces en incluant l’instruction de groupe group-id de filtres de la famille inet au niveau de la [edit interfaces] hiérarchie, puis joindre le flowspec filtre au groupe d’interfaces en incluant l’instruction flow interface-group group-id exclude au niveau de la [edit routing-options] hiérarchie. Vous ne pouvez configurer qu’une group-id seule instance de routage avec l’instruction set routing-options flow interface-group group-id .
Voir également
Exemple : Permettre à BGP de transporter des routes de spécification de flux
Cet exemple montre comment permettre à BGP de porter des messages nlRI (Network Reachability Information) de spécifications de flux.
Conditions préalables
Avant de commencer :
Configurez les interfaces de l’équipement.
Configurez un protocole IGP (Interior Gateway Protocol).
Configurez BGP.
Configurez une stratégie de routage qui exporte des routes (telles que des routes directes ou des routes IGP) de la table de routage vers BGP.
Présentation
La propagation des informations des filtres de pare-feu dans le cadre de BGP vous permet de propager dynamiquement les filtres de pare-feu contre les attaques par déni de service (DOS) sur les systèmes autonomes. Les routes de flux sont encapsulées dans la spécification de flux NLRI et propagées via un réseau ou des réseaux privés virtuels (VPN), partageant des informations de type filtre. Les routes de flux sont une agrégation des conditions de correspondance et des actions qui en résultent pour les paquets. Ils vous fournissent un filtrage du trafic et des capacités de limitation de débit, comme les filtres de pare-feu. Les routes de flux unicast sont prises en charge pour l’instance par défaut, les instances de routage et de transfert VPN (VRF) et les instances de routeur virtuel.
Les stratégies d’importation et d’exportation peuvent être appliquées à la famille inet flow ou à la famille inet-vpn flow NLRI, affectant les routes de flux acceptées ou annoncées, de la même manière que les stratégies d’importation et d’exportation sont appliquées à d’autres familles BGP. La seule différence est que la configuration de la stratégie de flux doit inclure l’instruction from rib inetflow.0 . Cette déclaration entraîne l’application de la stratégie aux routes de flux. Une exception à cette règle se produit si la stratégie n’a que l’instruction then reject ou then accept et aucune from instruction. Ensuite, la stratégie affecte tous les routes, y compris l’unicast IP et le flux IP.
Les filtres de routage de flux sont d’abord configurés statiquement sur un routeur, avec un ensemble de critères de correspondance suivis des actions à effectuer. Ensuite, en plus de family inet unicast, family inet flow (ou family inet-vpn flow) est configuré entre cet équipement compatible BGP et ses pairs.
Par défaut, les routes de flux à configuration statique (filtres de pare-feu) sont annoncées aux autres équipements compatibles BGP qui prennent en charge le nlRI ou family inet-vpn flow le ou le family inet flow nlri.
L’équipement récepteur compatible BGP effectue un processus de validation avant d’installer le filtre de pare-feu dans la table instance-name.inetflow.0de routage de flux . La procédure de validation est décrite dans la RFC 5575, Diffusion des règles de spécification de flux.
L’équipement récepteur compatible BGP accepte un routage de flux s’il passe les critères suivants :
L’auteur d’une route de flux correspond à l’auteur de la meilleure correspondance unicast route pour l’adresse de destination intégrée à la route.
Il n’existe plus de routes unicast spécifiques par rapport à l’adresse de destination de la route de flux, pour laquelle la route active a été reçue d’un autre système autonome de sauts suivants.
Le premier critère garantit que le filtre est annoncé par le saut suivant utilisé par le transfert unicast pour l’adresse de destination intégrée à la route de flux. Par exemple, si un routage de flux est donné en tant que 10.1.1.1, proto=6, port=80, l’équipement récepteur compatible BGP sélectionne le routage unicast plus spécifique dans la table de routage unicast qui correspond au préfixe de destination 10.1.1.1/32. Sur une table de routage unicast contenant 10.1/16 et 10.1.1/24, cette dernière est choisie comme route unicast pour la comparaison. Seule l’entrée de route unicast active est prise en compte. Cela suit le concept qu’une route de flux est valable si elle est annoncée par l’auteur de la meilleure route unicast.
Le deuxième critère répond aux situations dans lesquelles un bloc d’adresses donné est alloué à différentes entités. Les flux qui se résolvent à un routage unicast qui correspond le mieux à un routage agrégé ne sont acceptés que s’ils ne couvrent pas des routes plus spécifiques qui sont acheminées vers différents systèmes autonomes de saut suivant.
Vous pouvez contourner le processus de validation des routes de flux à l’aide de messages BGP NLRI et utiliser votre propre stratégie d’importation spécifique. Lorsque BGP transporte des messages NLRI de spécification de flux, l’instruction no-validate au niveau de la [edit protocols bgp group group-name family inet flow] hiérarchie omet la procédure de validation du routage de flux une fois que les paquets sont acceptés par une stratégie. Vous pouvez configurer la stratégie d’importation pour qu’elle corresponde à l’adresse de destination et aux attributs de chemin, tels que la communauté, le saut suivant et le chemin AS. Vous pouvez spécifier l’action à entreprendre si le paquet correspond aux conditions que vous avez configurées dans le routage de flux. Pour configurer une action, incluez l’instruction au niveau de la [edit routing-options flow] hiérarchie. Le type NLRI de spécification de flux comprend des composants tels que le préfixe de destination, le préfixe source, le protocole et les ports définis dans la RFC 5575. La stratégie d’importation peut filtrer une route entrante à l’aide des attributs de chemin et de l’adresse de destination dans la spécification de flux NLRI. La stratégie d’importation ne peut pas filtrer les autres composants de la RFC 5575.
La spécification de flux définit les extensions de protocole requises pour répondre aux applications les plus courantes de l’unicast IPv4 et du filtrage unicast VPN. Le même mécanisme peut être réutilisé et de nouveaux critères de correspondance peuvent être ajoutés pour traiter un filtrage similaire pour d’autres familles d’adresses BGP (par exemple, unicast IPv6).
Une fois qu’un routage de flux est installé dans la inetflow.0 table, il est également ajouté à la liste des filtres de pare-feu du noyau.
Sur les routeurs uniquement, les messages NLRI de spécification de flux sont pris en charge dans les VPN. Le VPN compare la communauté étendue cible de routage dans le NLRI à la politique d’importation. S’il y a une correspondance, le VPN peut commencer à utiliser les routes de flux pour filtrer et limiter le trafic de paquets. Les routes de flux reçues sont installées dans la table instance-name.inetflow.0de routage de flux . Les routes de flux peuvent également être propagées sur un réseau VPN et partagées entre VPN. Pour permettre à BGP multiprotocole (MP-BGP) de porter la spécification de flux NLRI pour la inet-vpn famille d’adresses, incluez l’instruction flow au niveau de la [edit protocols bgp group group-name family inet-vpn] hiérarchie. Les routes de flux VPN sont uniquement prises en charge pour l’instance par défaut. Les routes de flux configurées pour les VPN avec famille inet-vpn ne sont pas automatiquement validées, de sorte que l’instruction no-validate n’est pas prise en charge au niveau hiérarchique [edit protocols bgp group group-name family inet-vpn] . Aucune validation n’est nécessaire si les routes de flux sont configurées localement entre les équipements dans un seul AS.
Les stratégies d’importation et d’exportation peuvent être appliquées au family inet flow NLRI, family inet-vpn flow ce qui affecte les routes de flux acceptées ou annoncées, de la même manière que les stratégies d’importation et d’exportation sont appliquées à d’autres familles BGP. La seule différence est que la configuration de la stratégie de flux doit inclure l’instruction from rib inetflow.0 . Cette déclaration entraîne l’application de la stratégie aux routes de flux. Une exception à cette règle se produit si la stratégie n’a que l’instruction then reject ou then accept et aucune from instruction. Ensuite, la stratégie affecte tous les routes, y compris l’unicast IP et le flux IP.
Cet exemple montre comment configurer les stratégies d’exportation suivantes :
Stratégie qui autorise la publicité des routes de flux spécifiées par un filtre de routage. Seules les routes de flux couvertes par le bloc 10.13/16 sont annoncées. Cette stratégie n’affecte pas les routes unicast.
Une stratégie qui permet d’annoncer tous les routes unicast et de flux au voisin.
Une politique qui ne permet pas à tous les itinéraires (unicast ou flux) d’être annoncés au voisin.
topologie
Configuration
- Configuration d’un routage de flux statique
- Routes de flux publicitaires spécifiées par un filtre de routage
- Publicité de toutes les routes unicast et de flux
- Pas de routes unicast ou de flux publicitaires
- Limitation du nombre de routes de flux installées dans une table de routage
- Limitation du nombre de préfixes reçus sur une session d’appairage BGP
Configuration d’un routage de flux statique
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.
set routing-options flow route block-10.131.1.1 match destination 10.131.1.1/32 set routing-options flow route block-10.131.1.1 match protocol icmp set routing-options flow route block-10.131.1.1 match icmp-type echo-request set routing-options flow route block-10.131.1.1 then discard set routing-options flow term-order standard
Procédure étape par étape
L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
Pour configurer les sessions peer BGP :
Configurez les conditions de correspondance.
[edit routing-options flow route block-10.131.1.1] user@host# set match destination 10.131.1.1/32 user@host# set match protocol icmp user@host# set match icmp-type echo-request
Configurez l’action.
[edit routing-options flow route block-10.131.1.1] user@host# set then discard
(Recommandé) Pour l’algorithme de spécification de flux, configurez l’ordre de termes basé sur la norme.
[edit routing-options flow] user@host# set term-order standard
Dans l’algorithme de commande des termes par défaut, comme spécifié dans le projet de RFC flowspec version 6, un terme avec des conditions de correspondance moins spécifiques est toujours évalué avant un terme avec des conditions de correspondance plus spécifiques. Cela fait que le terme avec des conditions de correspondance plus spécifiques ne peut jamais être évalué. La version 7 de la RFC 5575 a fait une révision de l’algorithme afin que les conditions de correspondance les plus spécifiques soient évaluées avant les conditions de correspondance moins spécifiques. En matière de rétrocompatibilité, le comportement par défaut n’est pas modifié dans Junos OS, même si le nouvel algorithme est plus logique. Pour utiliser le nouvel algorithme, incluez l’instruction
term-order standarddans la configuration. Cette déclaration est prise en charge dans Junos OS version 10.0 et versions ultérieures.
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show routing-options commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@host# show routing-options
flow {
term-order standard;
route block-10.131.1.1 {
match {
destination 10.131.1.1/32;
protocol icmp;
icmp-type echo-request;
}
then discard;
}
}
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Routes de flux publicitaires spécifiées par un filtre de routage
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.
set protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a from rib inetflow.0 set policy-options policy-statement p1 term a from route-filter 10.13.0.0/16 orlonger set policy-options policy-statement p1 term a then accept set policy-options policy-statement p1 term b then reject set routing-options autonomous-system 65001
Procédure étape par étape
L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
Pour configurer les sessions peer BGP :
Configurez le groupe BGP.
[edit protocols bgp group core] user@host# set family inet unicast user@host# set family inet flow user@host# set export p1 user@host# set peer-as 65000 user@host# set neighbor 10.12.99.5
Configurez la stratégie de flux.
[edit policy-options policy-statement p1] user@host# set term a from rib inetflow.0 user@host# set term a from route-filter 10.13.0.0/16 orlonger user@host# set term a then accept user@host# set term b then reject
Configurez le numéro du système autonome local (AS).
[edit routing-options] user@host# set autonomous-system 65001
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant le show protocols, show policy-optionset show routing-options les commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@host# show protocols
bgp {
group core {
family inet {
unicast;
flow;
}
export p1;
peer-as 65000;
neighbor 10.12.99.5;
}
}
[edit]
user@host# show policy-options
policy-statement p1 {
term a {
from {
rib inetflow.0;
route-filter 10.13.0.0/16 orlonger;
}
then accept;
}
term b {
then reject;
}
}
[edit] user@host# show routing-options autonomous-system 65001;
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Publicité de toutes les routes unicast et de flux
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.
set protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a then accept set routing-options autonomous-system 65001
Procédure étape par étape
L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
Pour configurer les sessions peer BGP :
Configurez le groupe BGP.
[edit protocols bgp group core] user@host# set family inet unicast user@host# set family inet flow user@host# set export p1 user@host# set peer-as 65000 user@host# set neighbor 10.12.99.5
Configurez la stratégie de flux.
[edit policy-options policy-statement p1] user@host# set term a then accept
Configurez le numéro du système autonome local (AS).
[edit routing-options] user@host# set autonomous-system 65001
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant le show protocols, show policy-optionset show routing-options les commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@host# show protocols
bgp {
group core {
family inet {
unicast;
flow;
}
export p1;
peer-as 65000;
neighbor 10.12.99.5;
}
}
[edit]
user@host# show policy-options
policy-statement p1 {
term a {
prefix-list inetflow;
}
then accept;
}
}
[edit] user@host# show routing-options autonomous-system 65001;
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Pas de routes unicast ou de flux publicitaires
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.
set protocols bgp group core family inet unicast set protocols bgp group core family inet flow set protocols bgp group core export p1 set protocols bgp group core peer-as 65000 set protocols bgp group core neighbor 10.12.99.5 set policy-options policy-statement p1 term a then reject set routing-options autonomous-system 65001
Procédure étape par étape
L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
Pour configurer les sessions peer BGP :
Configurez le groupe BGP.
[edit protocols bgp group core] user@host# set family inet unicast user@host# set family inet flow user@host# set export p1 user@host# set peer-as 65000 user@host# set neighbor 10.12.99.5
Configurez la stratégie de flux.
[edit policy-options policy-statement p1] user@host# set term a then reject
Configurez le numéro du système autonome local (AS).
[edit routing-options] user@host# set autonomous-system 65001
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant le show protocols, show policy-optionset show routing-options les commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@host# show protocols
bgp {
group core {
family inet {
unicast;
flow;
}
export p1;
peer-as 65000;
neighbor 10.12.99.5;
}
}
[edit]
user@host# show policy-options
policy-statement p1 {
term a {
then reject;
}
}
[edit] user@host# show routing-options autonomous-system 65001;
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Limitation du nombre de routes de flux installées dans une table de routage
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.
set routing-options rib inetflow.0 maximum-prefixes 1000 set routing-options rib inetflow.0 maximum-prefixes threshold 50
Procédure étape par étape
L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
L’application d’une limite de route peut entraîner un comportement imprévisible du protocole de routage dynamique. Par exemple, une fois que la limite est atteinte et que les routes sont rejetées, BGP ne tente pas nécessairement de réinstaller les routes rejetées après que le nombre de routes soit inférieur à la limite. Les sessions BGP devront peut-être être être bloquées pour résoudre ce problème.
Pour limiter les routes de flux :
Définissez une limite supérieure pour le nombre de préfixes installés dans
inetflow.0la table.[edit routing-options rib inetflow.0] user@host# set maximum-prefixes 1000
Définissez une valeur seuil de 50 % : lorsque 500 routes sont installées, un avertissement est enregistré dans le journal système.
[edit routing-options rib inetflow.0] user@host# set maximum-prefixes threshold 50
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show routing-options commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@host# show routing-options
rib inetflow.0 {
maximum-prefixes 1000 threshold 50;
}
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Limitation du nombre de préfixes reçus sur une session d’appairage BGP
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie.
set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit maximum 1000 set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit teardown 50 set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit drop-excess 50 set protocols bgp group x1 neighbor 10.12.99.2 family inet flow prefix-limit hide-excess 50
Vous pouvez inclure l’option teardown <percentage>, drop-excess <percentage>ou hide-excess<percentage> d’instruction une à la fois.
Procédure étape par étape
L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le Guide de l’utilisateur de l’interface cli Junos OS.
La configuration d’une limite de préfixe pour un voisin spécifique offre un contrôle plus prévisible sur l’homologue qui peut annoncer le nombre de routes de flux.
Pour limiter le nombre de préfixes :
Définissez une limite de 1 000 routes BGP à partir du voisin 10.12.99.2.
[edit protocols bgp group x1] user@host# set neighbor 10.12.99.2 family inet flow prefix-limit maximum 1000
-
Configurez la ou les préfixes voisins pour qu’ils
teardown <percentage>exécutent soit ,drop-excess <percentage>ouhide-excess<percentage>l’option d’instruction lorsque la ou les sessions atteignent leurs limites.[edit routing-options rib inetflow.0] user@host# set neighbor 10.12.99.2 family inet flow prefix-limit teardown 50 set neighbor 10.12.99.2 family inet flow prefix-limit drop-excess 50 set neighbor 10.12.99.2 family inet flow prefix-limit hide-excess 50
Si vous spécifiez l’instruction
teardown <percentage>et spécifiez un pourcentage, les messages sont consignés lorsque le nombre de préfixes atteint ce pourcentage. Une fois la session terminée, la session est rétablie dans un court laps de temps, à moins que vous n’incluiez laidle-timeoutdéclaration.Si vous spécifiez l’instruction
drop-excess <percentage>et spécifiez un pourcentage, les routes excédentaires sont supprimées lorsque le nombre de préfixes dépasse ce pourcentageSi vous spécifiez l’instruction
hide-excess <percentage>et spécifiez un pourcentage, les routes excédentaires sont masquées lorsque le nombre de préfixes dépasse ce pourcentage.
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show protocols commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@host# show protocols
bgp {
group x1 {
neighbor 10.12.99.2 {
flow {
prefix-limit {
maximum 1000;
teardown 50;
drop-excess <percentage>;
hide-excess <percentage>;
}
}
}
}
}
}
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification du NLRI
- Vérification des routes
- Vérification de la validation des flux
- Vérification des filtres de pare-feu
- Vérification de la journalisation du système en cas de dépassement du nombre de routes de flux autorisées
- Vérification de la journalisation du système en cas de dépassement du nombre de préfixes reçus sur une session d’appairage BGP
Vérification du NLRI
But
Regardez le NLRI activé pour le voisin.
Action
À partir du mode opérationnel, exécutez la show bgp neighbor 10.12.99.5 commande. inet-flow Recherchez dans la sortie.
user@host> show bgp neighbor 10.12.99.5 Peer: 10.12.99.5+3792 AS 65000 Local: 10.12.99.6+179 AS 65002 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ direct ] Options: <Preference HoldTime AddressFamily PeerAS Refresh> Address families configured: inet-unicast inet-multicast inet-flow Holdtime: 90 Preference: 170 Number of flaps: 1 Error: 'Cease' Sent: 0 Recv: 1 Peer ID: 10.255.71.161 Local ID: 10.255.124.107 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 Local Interface: e1-3/0/0.0 NLRI advertised by peer: inet-unicast inet-multicast inet-flow NLRI for this session: inet-unicast inet-multicast inet-flow Peer supports Refresh capability (2) Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 2 Received prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 3 Table inet.2 Bit: 20000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Table inetflow.0 Bit: 30000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 29 Sent 15 Checked 15 Input messages: Total 5549 Updates 2618 Refreshes 0 Octets 416486 Output messages: Total 2943 Updates 1 Refreshes 0 Octets 55995 Output Queue[0]: 0 Output Queue[1]: 0 Output Queue[2]: 0
Vérification des routes
But
Regardez les routes de flux. L’exemple de sortie montre un routage de flux appris par BGP et un routage de flux configuré statiquement.
Pour les routes de flux configurées localement (configurées au niveau de [edit routing-options flow] la hiérarchie), les routes sont installées par le protocole de flux. Par conséquent, vous pouvez afficher les routes de flux en spécifiant la table, comme dans show route table inetflow.0 ou show route table instance-name.inetflow.0, où instance-name est le nom de l’instance de routage. Vous pouvez également afficher toutes les routes de flux configurées localement sur plusieurs instances de routage en exécutant la show route protocol flow commande.
Si un routage de flux n’est pas configuré localement, mais qu’il est reçu de l’homologue BGP du routeur, ce routage de flux est installé dans la table de routage par BGP. Vous pouvez afficher les routes de flux en spécifiant la table ou en exécutant show route protocol bgp, qui affiche toutes les routes BGP (flux et non-flux).
Action
À partir du mode opérationnel, exécutez la show route table inetflow.0 commande.
user@host> show route table inetflow.0
inetflow.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.100.100.100,*,proto=1,icmp-type=8/term:1
*[BGP/170] 00:00:18, localpref 100, from 100.0.12.2
AS path: 2000 I, validation-state: unverified
Fictitious
200.200.200.200,*,proto=6,port=80/term:2
*[BGP/170] 00:00:18, localpref 100, from 100.0.12.2
AS path: 2000 I, validation-state: unverified
Fictitious
user@host> show route table inetflow.0 extensive
inetflow.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
7.7.7.7,8.8.8.8/term:1 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): accept,count
*Flow Preference: 5
Next hop type: Fictitious
Address: 0x8d383a4
Next-hop reference count: 3
State: <Active>
Local AS: 65000
Age: 9:50
Task: RT Flow
Announcement bits (1): 0-Flow
AS path: I
user@host> show route hidden
inetflow.0: 2 destinations, 2 routes (0 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
100.100.100.100,*,proto=1,icmp-type=8/term:N/A
[BGP ] 00:00:17, localpref 100, from 100.0.12.2
AS path: 2000 I, validation-state: unverified
Fictitious
200.200.200.200,*,proto=6,port=80/term:N/A
[BGP ] 00:00:17, localpref 100, from 100.0.12.2
AS path: 2000 I, validation-state: unverified
Fictitious
Sens
Un routage de flux représente un terme de filtre de pare-feu. Lorsque vous configurez un routage de flux, vous spécifiez les conditions de correspondance et les actions. Dans les attributs de correspondance, vous pouvez faire correspondre une adresse source, une adresse de destination et d’autres qualificatifs tels que le port et le protocole. Pour un routage de flux unique qui contient plusieurs conditions de correspondance, toutes les conditions de correspondance sont encapsulées dans le champ de préfixe de la route. Lorsque vous émettez la show route commande sur un routage de flux, le champ préfixe de la route s’affiche avec toutes les conditions de correspondance, 10.12.44.1,* ce qui signifie que la condition correspondante est match destination 10.12.44.1/32. Si le préfixe de la sortie était *,10.12.44.1, cela signifierait que la condition de correspondance était match source 10.12.44.1/32. Si les conditions correspondantes contiennent à la fois une source et une destination, l’astérisque est remplacé par l’adresse.
Les nombres d’ordre des termes indiquent la séquence des termes (routes de flux) évaluées dans le filtre de pare-feu. La show route extensive commande affiche les actions de chaque terme (route).
Vérification de la validation des flux
But
Affichez les informations sur le routage du flux.
Action
À partir du mode opérationnel, exécutez la show route flow validation detail commande.
user@host> show route flow validation detail
inet.0:
0.0.0.0/0
Internal node: best match, inconsistent
10.0.0.0/8
Internal node: no match, inconsistent
10.12.42.0/24
Internal node: no match, consistent, next-as: 65003
Active unicast route
Dependent flow destinations: 1
Origin: 10.255.124.106, Neighbor AS: 65003
10.12.42.1/32
Flow destination (1 entries, 1 match origin)
Unicast best match: 10.12.42.0/24
Flags: Consistent
10.131.0.0/16
Internal node: no match, consistent, next-as: 65001
Active unicast route
Dependent flow destinations: 5000
Origin: 10.12.99.2, Neighbor AS: 65001
10.131.0.0/19
Internal node: best match
10.131.0.0/20
Internal node: best match
10.131.0.0/21
Vérification des filtres de pare-feu
But
Affichez les filtres de pare-feu installés dans le noyau.
Action
À partir du mode opérationnel, exécutez la show firewall commande.
user@host> show firewall Filter: __default_bpdu_filter__ Filter: __flowspec_default_inet__ Counters: Name Bytes Packets 10.12.42.1,* 0 0 196.1.28/23,* 0 0 196.1.30/24,* 0 0 196.1.31/24,* 0 0 196.1.32/24,* 0 0 196.1.56/21,* 0 0 196.1.68/24,* 0 0 196.1.69/24,* 0 0 196.1.70/24,* 0 0 196.1.75/24,* 0 0 196.1.76/24,* 0 0
Vérification de la journalisation du système en cas de dépassement du nombre de routes de flux autorisées
But
Si vous configurez une limite du nombre de routes de flux installées, comme décrit dans Limitation du nombre de routes de flux installées dans une table de routage, consultez le message du journal système lorsque le seuil est atteint.
Action
À partir du mode opérationnel, exécutez la show log <message> commande.
user@host> show log message Jul 12 08:19:01 host rpd[2748]: RPD_RT_MAXROUTES_WARN: Number of routes (1000) in table inetflow.0 exceeded warning threshold (50 percent of configured maximum 1000)
Vérification de la journalisation du système en cas de dépassement du nombre de préfixes reçus sur une session d’appairage BGP
But
Si vous configurez une limite du nombre de routes de flux installées, comme décrit dans Limitation du nombre de préfixes reçus sur une session d’appairage BGP, consultez le message du journal système lorsque le seuil est atteint.
Action
À partir du mode opérationnel, exécutez la show log message commande.
Si vous spécifiez l’option d’instruction teradown <percentage> :
user@host> show log message Jul 12 08:44:47 host rpd[2748]: 10.12.99.2 (External AS 65001): Shutting down peer due to exceeding configured maximum prefix-limit(1000) for inet-flow nlri: 1001
Si vous spécifiez l’option d’instruction drop-excess <percentage> :
user@host> show log message Jul 27 15:26:57 R1_re rpd[32443]: BGP_DROP_PREFIX_LIMIT_EXCEEDED: 1.1.1.2 (Internal AS 1): Exceeded drop-excess maximum prefix-limit(4) for inet-unicast nlri: 5 (instance master)
Si vous spécifiez l’option d’instruction hide-excess <percentage> :
user@host> show log message Jul 27 15:26:57 R1_re rpd[32443]: BGP_HIDE_PREFIX_LIMIT_EXCEEDED: 1.1.1.2 (Internal AS 1): Exceeded hide-excess maximum prefix-limit(4) for inet-unicast nlri: 5 (instance master)
Exemple : Configuration de BGP pour transporter des routes de spécification de flux IPv6
Cet exemple montre comment configurer la spécification de flux IPv6 pour le filtrage du trafic. Les spécifications de flux BGP peuvent être utilisées pour automatiser la coordination inter-domaine et intra-domaine des règles de filtrage du trafic afin d’atténuer les attaques par déni de service.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
Deux routeurs MX Series
Junos OS Version 16.1 ou ultérieure
Avant d’activer BGP pour transporter des routes de spécification de flux IPv6 :
Configurez les adresses IP sur les interfaces de l’équipement.
Configurez BGP.
Configurez une stratégie de routage qui exporte des routes (telles que des routes statiques, des routes directes ou des routes IGP) à partir de la table de routage vers BGP.
Présentation
Les spécifications de flux offrent une protection contre les attaques par déni de service et limitent le trafic défectueux qui consomme la bande passante et l’arrête près de la source. Dans les versions précédentes de Junos OS, les règles de spécification des flux ont été propagées pour IPv4 sur BGP en tant qu’informations d’accessibilité de la couche réseau. À partir de la version 16.1 de Junos OS, la fonctionnalité de spécification de flux est prise en charge sur la famille IPv6 et permet de propager les règles de spécification des flux de trafic pour IPv6 et VPN IPv6.
topologie
Figure 7 affiche la topologie de l’exemple. Les routeurs R1 et R2 appartiennent à différents systèmes autonomes. La spécification de flux IPv6 est configurée sur le routeur R2. Tout le trafic entrant est filtré en fonction des conditions de spécification du flux, et le trafic est traité différemment en fonction de l’action spécifiée. Dans cet exemple, tout le trafic vers abcd:11:11:11:10/128 qui correspond aux conditions de spécification du flux est rejeté ; que le trafic destiné à abcd::11:11:11:30/128 et correspondant aux conditions de spécification du flux est accepté.
Configuration
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit à partir du mode de configuration.
Routeur R1
set interfaces ge-1/1/4 unit 0 family inet6 address abcd::13:14:2:1/120 set interfaces lo0 unit 0 family inet6 address abcd::128:220:21:197/128 set routing-options router-id 128.220.21.197 set routing-options autonomous-system 64496 set protocols bgp group ebgp type external set protocols bgp group ebgp family inet6 unicast set protocols bgp group ebgp family inet6 flow set protocols bgp group ebgp peer-as 64497 set protocols bgp group ebgp neighbor abcd::13:14:2:2
Routeur R2
set interfaces ge-1/0/0 unit 0 family inet6 address abcd::192:2:1:1/120 set interfaces ge-1/1/5 unit 0 family inet6 address abcd::13:14:2:2/120 set interfaces lo0 unit 0 family inet6 address abcd::128:220:41:229/128 set routing-options rib inet6.0 static route abcd::11:11:11:0/120 next-hop abcd::192:2:1:2 set routing-options rib inet6.0 flow route route-1 match destination abcd::11:11:11:10/128 set routing-options rib inet6.0 flow route route-1 match protocol tcp set routing-options rib inet6.0 flow route route-1 match destination-port http set routing-options rib inet6.0 flow route route-1 match source-port 65535 set routing-options rib inet6.0 flow route route-1 then discard set routing-options rib inet6.0 flow route route-2 match destination abcd::11:11:11:30/128 set routing-options rib inet6.0 flow route route-2 match icmp6-type echo-request set routing-options rib inet6.0 flow route route-2 match packet-length 100 set routing-options rib inet6.0 flow route route-2 match dscp 10 set routing-options rib inet6.0 flow route route-2 then accept set routing-options router-id 128.220.41.229 set routing-options autonomous-system 64497 set protocols bgp group ebgp type external set protocols bgp group ebgp family inet6 unicast set protocols bgp group ebgp family inet6 flow set protocols bgp group ebgp export redis set protocols bgp group ebgp peer-as 64496 set protocols bgp group ebgp neighbor abcd::13:14:2:1 set policy-options policy-statement redis from protocol static set policy-options policy-statement redis then accept
Configuration du routeur R2
Procédure étape par étape
L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation sur l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le guide de l’utilisateur CLI.
Pour configurer le routeur R2 :
Répétez cette procédure pour le routeur R1 après avoir modifié les noms d’interface, adresses et autres paramètres appropriés.
Configurez les interfaces avec des adresses IPv6.
[edit interfaces] user@R2# set ge-1/0/0 unit 0 family inet6 address abcd::192:2:1:1/120 user@R2# set ge-1/1/5 unit 0 family inet6 address abcd::13:14:2:2/120
Configurez l’adresse de bouclage IPv6.
[edit interfaces] user@R2# set lo0 unit 0 family inet6 address abcd::128:220:41:229/128
Configurez l’ID du routeur et le numéro du système autonome (AS).
[edit routing-options] user@R2# set router-id 128.220.41.229 user@R2# set autonomous-system 64497
Configurez une session d’appairage EBGP entre le routeur R1 et le routeur R2.
[edit protocols] user@R2# set bgp group ebgp type external user@R2# set bgp group ebgp family inet6 unicast user@R2# set bgp group ebgp family inet6 flow user@R2# set bgp group ebgp export redis user@R2# set bgp group ebgp peer-as 64496 user@R2# set bgp group ebgp neighbor abcd::13:14:2:1
Configurez un routage statique et un saut suivant. Ainsi, un routage est ajouté à la table de routage pour vérifier la fonctionnalité de cet exemple.
[edit routing-options] user@R2# set rib inet6.0 static route abcd::11:11:11:0/120 next-hop abcd::192:2:1:2
Spécifiez les conditions de spécification de flux.
[edit routing-options] user@R2# set rib inet6.0 flow route route-1 match destination abcd::11:11:11:10/128 user@R2# set rib inet6.0 flow route route-1 match protocol tcp user@R2# set rib inet6.0 flow route route-1 match destination-port http user@R2# set rib inet6.0 flow route route-1 match source-port 65535
Configurez une discard action pour éliminer les paquets qui correspondent aux conditions de correspondance spécifiées.
[edit routing-options] user@R2# set rib inet6.0 flow route route-1 then discard
Spécifiez les conditions de spécification de flux.
[edit routing-options] user@R2# set rib inet6.0 flow route route-2 match destination abcd::11:11:11:30/128 user@R2# set rib inet6.0 flow route route-2 match icmp6-type echo-request user@R2# set rib inet6.0 flow route route-2 match packet-length 100 user@R2# set rib inet6.0 flow route route-2 match dscp 10
Configurer une accept action pour accepter les paquets qui correspondent aux conditions de correspondance spécifiées
[edit routing-options] user@R2# set rib inet6.0 flow route route-2 then accept
Définissez une stratégie qui permet à BGP d’accepter des routes statiques.
[edit policy-options] user@R2# set policy-statement redis from protocol static user@R2# set policy-statement redis then accept
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant le show interfaces, show protocols, show routing-optionset les show policy-options commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]
user@R2# show interfaces
ge-1/0/0 {
unit 0 {
family inet6 {
address abcd::192:2:1:1/120;
}
}
}
ge-1/1/5 {
unit 0 {
family inet6 {
address abcd::13:14:2:2/120;
}
}
}
lo0 {
unit 0 {
family inet6 {
address abcd::128:220:41:229/128;
}
}
}
[edit]
user@R2# show protocols
bgp {
group ebgp {
type external;
family inet6 {
unicast;
flow;
}
export redis;
peer-as 64496;
neighbor abcd::13:14:2:1;
}
}
[edit]
user@R2# show routing-options
rib inet6.0 {
static {
route abcd::11:11:11:0/120 next-hop abcd::192:2:1:2;
}
flow {
route route-1 {
match {
destination abcd::11:11:11:10/128;
protocol tcp;
destination-port http;
source-port 65535;
}
then discard;
}
route route-2 {
match {
destination abcd::11:11:11:30/128;
icmp6-type echo-request;
packet-length 100;
dscp 10;
}
then accept;
}
}
}
router-id 128.220.41.229;
autonomous-system 64497;
[edit]
user@R2# show policy-options
policy-statement redis {
from protocol static;
then accept;
}
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérifier la présence de routes de spécification de flux IPv6 dans la table inet6flow
- Vérification des informations de synthèse BGP
- Vérification de la validation des flux
- Vérification des spécifications de flux des routes IPv6
Vérifier la présence de routes de spécification de flux IPv6 dans la table inet6flow
But
Affichez les routes dans le inet6flow tableau des routeurs R1 et R2, et vérifiez que BGP a appris les routes de flux.
Action
À partir du mode opérationnel, exécutez la commande sur le show route table inet6flow.0 extensive routeur R1.
user@R1> show route table inet6flow.0 extensive
inet6flow.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535/term:1 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): discard,count
*BGP Preference: 170/-101
Next hop type: Fictitious, Next hop index: 0
Address: 0x9b24064
Next-hop reference count: 2
State:<Active Ext>
Local AS: 64496 Peer AS: 64497
Age: 20:55
Validation State: unverified
Task: BGP_64497.abcd::13:14:2:2
Announcement bits (1): 0-Flow
AS path: 64497 I
Communities: traffic-rate:64497:0
Accepted
Validation state: Accept, Originator: abcd::13:14:2:2, Nbr AS: 64497
Via: abcd::11:11:11:0/120, Active
Localpref: 100
Router ID: 128.220.41.229
abcd::11:11:11:30/128,*,icmp6-type=128,len=100,dscp=10/term:2 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): accept,count
*BGP Preference: 170/-101
Next hop type: Fictitious, Next hop index: 0
Address: 0x9b24064
Next-hop reference count: 2
State: <Active Ext>
Local AS: 64496 Peer AS: 64497
Age: 12:51
Validation State: unverified
Task: BGP_64497.abcd::13:14:2:2
Announcement bits (1): 0-Flow
AS path: 64497 I
Accepted
Validation state: Accept, Originator: abcd::13:14:2:2, Nbr AS: 64497
Via: abcd::11:11:11:0/120, Active
Localpref: 100
Router ID: 128.220.41.229À partir du mode opérationnel, exécutez la show route table inet6flow.0 extensive commande sur le routeur R2.
user@R2> show route table inet6flow.0 extensive
inet6flow.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535/term:1 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): discard,count
Page 0 idx 0, (group pe-v6 type External) Type 1 val 0xaec8850 (adv_entry)
Advertised metrics:
Nexthop: Self
AS path: [64497]
Communities: traffic-rate:64497:0
Path abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535 Vector len 4. Val: 0
*Flow Preference: 5
Next hop type: Fictitious, Next hop index: 0
Address: 0x9b24064
Next-hop reference count: 3
State: <Active>
Local AS: 64497
Age: 14:21
Validation State: unverified
Task: RT Flow
Announcement bits (2): 0-Flow 1-BGP_RT_Background
AS path: I
Communities: traffic-rate:64497:0
abcd::11:11:11:30/128,*,proto=17,port=65535/term:2 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): accept,count
Page 0 idx 0, (group pe-v6 type External) Type 1 val 0xaec8930 (adv_entry)
Advertised metrics:
Nexthop: Self
AS path: [64497]
Communities:
Path abcd::11:11:11:30/128,*,proto=17,port=65535 Vector len 4. Val: 0
*Flow Preference: 5
Next hop type: Fictitious, Next hop index: 0
Address: 0x9b24064
Next-hop reference count: 3
State: <Active>
Local AS: 64497
Age: 14:21
Validation State: unverified
Task: RT Flow
Announcement bits (2): 0-Flow 1-BGP_RT_Background
AS path: I Sens
La présence des routes abcd::11:11:11:10/128 et abcd::11:11:11:30/128 dans le inet6flow tableau confirme que BGP a appris les routes de flux.
Vérification des informations de synthèse BGP
But
Vérifiez que la configuration BGP est correcte.
Action
À partir du mode opérationnel, exécutez la commande sur les show bgp summary routeurs R1 et R2.
user@R1> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet6.0
1 1 0 0 0 0
inet6flow.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
abcd::13:14:2:2 2000 58 58 0 2 19:48 Establ
inet6.0: 1/1/1/0
inet6flow.0: 2/2/2/0
user@R2> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet6.0
0 0 0 0 0 0
inet6flow.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
abcd::13:14:2:1 64496 51 52 0 0 23:03 Establ
inet6.0: 0/0/0/0
inet6flow.0: 0/0/0/0Sens
Vérifiez que la inet6.0 table contient l’adresse du voisin BGP et qu’une session d’appairage a été établie avec son voisin BGP.
Vérification de la validation des flux
But
Affichez les informations sur le routage du flux.
Action
À partir du mode opérationnel, exécutez la commande sur le show route flow validation routeur R1.
user@R1> show route flow validation
inet6.0:
abcd::11:11:11:0/120
Active unicast route
Dependent flow destinations: 2
Origin: abcd::13:14:2:2, Neighbor AS: 64497
abcd::11:11:11:10/128
Flow destination (1 entries, 1 match origin, next-as)
Unicast best match: abcd::11:11:11:0/120
Flags: Consistent
abcd::11:11:11:30/128
Flow destination (1 entries, 1 match origin, next-as)
Unicast best match: abcd::11:11:11:0/120
Flags: ConsistentSens
La sortie affiche les routes de flux dans la inet6.0 table.
Vérification des spécifications de flux des routes IPv6
But
Affichez le nombre de paquets qui sont rejetés et acceptés en fonction des routes de spécification de flux spécifiées.
Action
À partir du mode opérationnel, exécutez la show firewall filter_flowspec_default_inet6_ commande sur le routeur R2.
user@R2> show firewall filter __flowspec_default_inet6__ Filter: __flowspec_default_inet6__ Counters: Name Bytes Packets abcd::11:11:11:10/128,*,proto=6,dstport=80,srcport=65535 0 0 abcd::11:11:11:30/128,*,proto=17,port=65535 6395472 88826
Sens
La sortie indique que les paquets destinés à abcd::11:11:10/128 sont éliminés et que les paquets 88826 ont été acceptés pour la route abcd::11:11:11:11:11:30/128.
Configuration des actions de spécification de flux BGP rediriger vers IP pour filtrer le trafic DDoS
À partir de la version 18.4R1 de Junos OS, la spécification de flux BGP telle que décrite dans BGP Flow-Spec Internet draft-ietf-idr-flowspec-redirect-ip-02.txt, la redirection vers l’action IP est prise en charge. Rediriger vers l’action IP utilise la communauté BGP étendue pour fournir des options de filtrage du trafic pour atténuer les DDoS dans les réseaux des fournisseurs de services. Rediriger les spécifications de flux héritées vers IP utilise l’attribut BGP nexthop. Junos OS affiche une redirection vers une action de spécification de flux IP à l’aide de la communauté étendue par défaut. Cette fonctionnalité est nécessaire pour prendre en charge le chaînage de services dans la passerelle de contrôle des services virtuels (vSCG). Rediriger vers l’action IP permet de détourner le trafic correspondant aux spécifications de flux vers une adresse globalement accessible qui pourrait être connectée à un équipement de filtrage capable de filtrer le trafic DDoS et d’envoyer le trafic propre à l’équipement sortant.
Avant de commencer à rediriger le trafic vers ip pour les routes de spécification de flux BGP, effectuez les opérations suivantes :
Configurez les interfaces de l’équipement.
Configurez OSPF ou tout autre protocole IGP.
Configurez MPLS et LDP.
Configurez BGP.
Configurez la redirection vers la fonctionnalité IP à l’aide de la communauté étendue BGP.
Configurez la redirection des spécifications de flux héritées vers la fonctionnalité IP à l’aide de l’attribut nexthop.
Vous ne pouvez pas configurer des stratégies pour rediriger le trafic vers une adresse IP à l’aide de la communauté étendue BGP et de la redirection héritée vers l’adresse IP du saut suivant.
Configurez la redirection des spécifications de flux héritées vers l’ADRESSE IP spécifiée dans le projet Internet draft-ietf-idr-flowspec-redirect-ip-00.txt , BGP Flow-Spec Extended Community pour la redirection du trafic vers IP Next Hop inclure au niveau de la hiérarchie.
[edit group bgp-group neighbor bgp neighbor family inet flow] user@host# set legacy-redirect-ip-action
Définissez une stratégie correspondant à l’attribut de saut suivant.
[edit policy options] user@host#policy statement policy_name user@host#from community community-name user@host#from next-hop ip-address
Par exemple, définissez une stratégie p1 pour rediriger le trafic vers l’adresse IP 10.1.1.1.1.
[edit policy options] user@host#policy statement p1 user@host#from community redirnh user@host#from next-hop 10.1.1.1
Définissez une stratégie pour définir, ajouter ou supprimer la communauté BGP à l’aide de la spécification de flux héritée rediriger l’attribut de saut suivant vers l’action IP.
[edit policy-options] user@host# policy-statement policy_name user@host# then community set community-name user@host# then community add community-name user@host# then community delete community-name user@host# then next-hop next-hop-address
Par exemple, définissez une stratégie p1 et définissez, ajoutez ou supprimez une communauté BGP redirnh pour rediriger le trafic DDoS vers le saut suivant adresse IP 10.1.1.1.
[edit policy-options policy-statement p1] user@host# then community set redirnh user@host# then community add redirnh user@host# then community delete redirnh user@host# then next-hop 10.1.1.1
Voir également
Transfert du trafic à l’aide de la spécification de flux BGP action DSCP
Configurez l’action DSCP De flux BGP (FlowSpec) pour transférer efficacement les paquets à l’aide de la classe de transfert et des informations de priorité de perte sur le réseau.
Avantages de l’action BGP FlowSpec DSCP pour transférer des paquets
-
Transfère le trafic vers les files d’attente COS prévues, où les stratégies COS sont appliquées correctement au trafic.
-
Influence le comportement de transfert local (par exemple, la sélection du tunnel) en fonction de la valeur DSCP provisionné.
-
Aide à gérer efficacement le trafic sur votre réseau.
Lorsqu’un paquet pénètre dans un routeur, le paquet passe par les fonctionnalités (pare-feu, COS, etc.) appliquées à l’interface entrante. Lorsque vous configurez le filtre BGP FlowSpec sur l’interface entrante, le filtre est appliqué aux paquets par instance de routage en fonction de l’action DSCP. L’action DSCP classe et réécrit les paquets, ainsi que la modification du code DSCP via le filtre BGP FlowSpec. En fonction de la classe de transfert et des informations de priorité de perte, les paquets sont placés dans la file d’attente de transfert correcte. Les paquets passent par des routes de flux uniquement si des conditions de correspondance spécifiques sont remplies. Les conditions de correspondance peuvent être l’adresse IP source et de destination, le port source et de destination, DSCP, le numéro de protocole, etc. La classe de transfert et les informations de priorité des pertes sont mises à jour via la table de mappage inverse.
Voici la topologie d’une session BGP établie entre les réseaux du fournisseur de services et du client d’entreprise.
Dans cette topologie, une session BGP est configurée entre le fournisseur de services et le réseau client d’entreprise pour BGP FlowSpec. Le filtre BGP FlowSpec est appliqué aux routeurs PE1 et PE2. Les paquets entrant dans ces routeurs sont réécrits en fonction du filtre BGP FlowSpec et de l’action DSCP.
Pour activer le filtre BGP FlowSpec sur un équipement, vous devez ajouter l’énoncé de dscp-mapping-classifier configuration au niveau de la hiérarchie [edit forwarding-options family (inet | inet6)] :
forwarding-options {
family inet {
dscp-mapping-classifier ipv4-classifer;
}
family inet6 {
dscp-mapping-classifier ipv6-classifer;
}
}
L’exemple de configuration de service suivant mappe les points de code DSCP à la classe de transfert et à la priorité de perte :
class-of-service {
classifiers {
dscp dscp1 {
forwarding-class best-effort {
loss-priority low code-points 000000;
}
}
}
}
extended-community .