Différences de configuration entre les services adaptatifs et les services nouvelle génération
Vue d’ensemble
Les services nouvelle génération vous obligent à configurer les services différemment de ce à quoi vous êtes habitué avec les services adaptatifs, qui s’exécutent sur des cartes de type MS (MS-MPC, MS-MIC et MS-DPC). La configuration de la carte de services SPC3 s’aligne davantage sur la façon dont vous configurez la passerelle de services. Une fois que vous vous serez familiarisé avec cette approche plus unifiée, vous devriez être en mesure de configurer les services sur ces deux plateformes de manière plus transparente, ce qui réduira les coûts d’entraînement et le risque d’erreurs de configuration.
Outre les différences entre les CLI, vous devez connaître les différences matérielles de base entre les cartes multiservices (MS-DPC, MS-MPC et MS-MIC) et la carte de services SPC3. Les cartes de type MS contiennent quatre complexes de CPU alors que la carte SPC3, bien que plus puissante, contient deux complexes de CPU. Chaque complexe CPU dessert un seul PIC, ce qui signifie que les cartes de type MS prennent en charge quatre PIC alors que la SPC3 en prend en charge deux. Les cartes de type MS utilisent des PIC multiservices (MS) et de services adaptatifs (AS) spéciaux, tandis que les PIC de la carte SPC3 sont intégrés.
Étant donné que le nombre de PIC affecte directement le nombre d’interfaces (Tableau 1), vous devrez peut-être ajouter des unités logiques à chaque interface du SPC3 pour augmenter le nombre d’interfaces à quatre. Par exemple, si vous utilisez actuellement les quatre interfaces sur la carte de type MS et que vous disposez d’un ensemble de services par interface, vous pouvez créer deux unités logiques par interface sur le SPC3 pour porter le nombre total d’interfaces à quatre, puis réassocier les quatre ensembles de services à ces quatre interfaces logiques.
Cartes MS |
SPC3 |
|
|---|---|---|
Nombre de complexes de CPU |
4 |
2 |
Nombre de PIC par complexe CPU |
1 |
1 |
Nombre d’interfaces par PIC |
1 |
1 |
Nombre total d’interfaces sur la carte |
4 |
2 |
|
Remarque :
Pour plus d’informations sur le matériel SPC3, reportez-vous à la MX Series 5G référence des modules d’interface de la plate-forme de routage universelle . |
||
Les sections suivantes donnent un aperçu des différences de configuration de base entre les services sur les cartes de type MS et les services sur la carte SPC3. L’objectif de ces sections est de vous aider à démarrer en utilisant des exemples de base pour illustrer les changements majeurs. Ces exemples présentent un sous-ensemble des options de configuration CLI et ne remplacent pas le traitement plus formel du sujet que l’on trouve dans le Guide de l’utilisateur des interfaces de services de nouvelle génération pour les périphériques de routage et le Guide de référence Junos OS CLI.
Les exemples de configuration de ces sections sont présentés côte à côte afin que vous puissiez facilement voir les différences entre les deux. Les exemples sont destinés à vous montrer comment configurer les fonctionnalités de carte de type MS existantes sur le SPC3. Les exemples n’ont pas pour but de vous montrer comment configurer de nouvelles fonctionnalités uniquement disponibles sur le SPC3. Pour des raisons de lisibilité et de facilité de comparaison, l’ordre des déclarations présentées peut différer légèrement de l’ordre réel des déclarations affichées dans le CLI.
Si vous disposez déjà d’un grand nombre de services adaptés, nous savons que ces changements peuvent être un inconvénient pour vous. Pour vous aider à migrer des cartes de type MS vers le SPC3, nous vous suggérons de procéder comme suit :
Parcourez les exemples de ce guide pour avoir une vue d’ensemble des changements requis.
Parcourez l’ensemble des exemples de configuration de l’article KB35348 de la base de connaissances.
Parcourez ce guide et le guide de référence CLI Junos OS pour comprendre toutes les fonctionnalités, les options de configuration et la syntaxe.
Contactez le JTAC pour obtenir de l’aide dans votre migration.
Vous n’avez pas besoin d’apporter ces modifications de configuration si vous continuez à exécuter des services adaptatifs sur les cartes de type MS. Toutefois, une fois que vous avez déployé le SPC3 sur un routeur, vous devez remplacer toutes les cartes de type MS sur ce routeur et reconfigurer vos services pour les aligner sur le paradigme de configuration des services de nouvelle génération.
Interfaces
Les cartes de type MS utilisent la convention ms-1/0/0de dénomination des interfaces , tandis que vous spécifiez les interfaces SPC3 à l’aide des multiservices virtuels ou vms-1/0/0 de la convention de dénomination des interfaces. Les noms ams et mams les interfaces ne sont pas modifiés.
En outre, un certain nombre de paramètres configurés sous services-options sur une ms interface sont configurés sous service-set-options dans un ensemble de services.
Le tableau 2 présente des exemples de ces changements.
Cartes de type MS |
SPC3 |
|---|---|
[edit interfaces]
ms-5/1/0 {
<...>
}
|
[edit interfaces]
# Change interface name to vms.
vms-5/1/0 {
<...>
}
|
[edit interfaces]
ms-5/1/0 {
services-options {
open-timeout 40;
close-timeout 40;
inactivity-tcp-timeout 10;
inactivity-asymm-tcp-timeout 10;
tcp-tickles 8;
ignore-errors tcp;
}
}
|
[edit services]
service-set sset1 {
service-set-options {
# Set tcp parameters under tcp-session.
tcp-session {
open-timeout 40;
close-timeout 40;
inactivity-tcp-timeout 10;
inactivity-asymm-tcp-timeout 10;
tcp-tickles 8;
ignore-errors tcp;
}
}
}
|
[edit interfaces]
ms-5/1/0 {
services-options {
inactivity-non-tcp-timeout 40;
session-timeout 10;
}
}
|
[edit services]
service-set sset1 {
# Set non-tcp parameters directly under
# service-set-options.
service-set-options {
inactivity-non-tcp-timeout 40;
session-timeout 10;
}
}
|
[edit interfaces]
ms-5/1/0 {
services-options {
fragment-limit 10;
reassembly-timeout 5;
}
} |
[edit interfaces]
vms-5/1/0 {
services-options {
fragment-limit 10;
reassembly-timeout 5;
}
} |
[edit interfaces]
ms-5/1/0 {
services-options {
session-limit {
maximum 100;
cpu-load-threshold 12;
rate 10;
}
}
}
|
[edit services]
# Maximum number of sessions can be
# specified per service-set.
service-set sset1 {
service-set-options {
session-limit {
maximum 100;
}
}
}
[edit interfaces]
# All session-limit parameters continue to be
# configurable per interface. If the maximum
# number of sessions is different from the associated
# service-set, the smaller number takes effect.
vms-5/1/0 {
services-options {
session-limit {
maximum 100;
cpu-load-threshold 12;
rate 10;
}
}
}
|
[edit interfaces]
ms-5/1/0 {
services-options {
pba-interim-logging-interval 10;
}
}
|
[edit interfaces]
# Set interim-logging-interval under the nat branch.
nat {
source {
pool src-pool {
port {
block-allocation {
interim-logging-interval 10;
}
}
}
|
[edit interfaces]
ms-5/1/0 {
services-options {
syslog {
host {
<...>
}
}
}
}
|
Voir |
[edit interfaces]
ms-5/1/0 {
services-options {
syslog {
message-rate-limit 10;
}
}
}
|
[edit services]
service-set sset1 {
syslog {
event-rate 10;
}
}
|
[edit interfaces]
ms-5/1/0 {
services-options {
ignore-errors alg;
disable-global-timeout-override;
trio-flow-offload {
minimum-bytes 1000;
}
}
}
|
Non pris en charge |
Ensemble de services
Le Tableau 3 présente des changements mineurs dans la façon dont certains service-set paramètres sont configurés.
Cartes de type MS |
SPC3 |
|---|---|
[edit services]
service-set sset1 {
tcp-mss 1460;
service-set-options {
tcp-non-syn drop-flow-send-rst;
tcp-fast-open drop;
}
}
|
[edit services]
service-set sset1 {
service-set-options {
# Set tcp parameters under tcp-session.
tcp-session {
tcp-mss 1460;
tcp-non-syn drop-flow-send-rst;
tcp-fast-open drop;
}
}
}
|
[edit services]
service-set sset1 {
replicate-services {
replication-threshold 180;
}
}
|
[edit interfaces]
# Set replication-threshold on the interface.
vms-5/1/0 {
redundancy-options {
replication-threshold 180;
}
}
|
[edit services]
service-set sset1 {
syslog {
host 10.1.1.1 {
port 514;
}
}
}
|
[edit services]
service-set sset1 {
syslog
# Process security logs in the dataplane.
mode stream;
stream s1 {
# Specify host to send security logs to.
host {
10.1.1.1;
port 514;
}
}
}
}
|
[edit services]
service-set sset1 {
syslog {
host local;
}
}
|
[edit services]
service-set sset1 {
syslog
# Process security logs in the control plane,
# saving logs to local file specified by rtlog.
mode event;
}
}
rtlog {
traceoptions {
# Specify filename for logs.
file rtlog size 1g;
flag all;
}
}
|
[edit services]
service-set sset1 {
service-order <...>
}
|
L’ordre de service est fixe. |
[edit services]
service-set sset1 {
sampling-service <...>
}
|
La journalisation J-Flow est prise en charge en ligne. |
[edit services]
service-set sset1 {
tag-rule-sets <...>
tag-rules <...>
hcm-profile <...>
hcm-url-rule-sets <...>
hcm-url-rules <...>
service-set-options {
bypass-traffic-on-pic-failure;
}
}
|
Actuellement non pris en charge |
Pare-feu dynamique
Règles et politiques
Les règles de pare-feu dynamiques sur SPC3 sont structurées légèrement différemment des règles de pare-feu dynamiques pour les services sur les cartes de type MS. Sur le SPC3, vous placez les règles dans un policies wrapper et vous définissez les termes de correspondance et les actions pour la règle dans un contenu dans la policy règle.
Tout comme un service de pare-feu dynamique sur la carte de type MS, vous créez un ensemble de services pour associer une interface à un ensemble de règles. Un ensemble de règles contient des références à une ou plusieurs règles. Les règles sont appliquées séquentiellement dans l’ordre dans lequel vous les répertoriez jusqu’à ce qu’une correspondance se produise et qu’une action soit effectuée.
Chaque règle contient une ou plusieurs paires de termes et d’actions de correspondance. Sur le SPC3, chaque paire de termes et d’actions de correspondance est appelée stratégie. Les stratégies sont appliquées séquentiellement dans l’ordre dans lequel vous les spécifiez jusqu’à ce qu’une correspondance se produise et qu’une action soit effectuée.
Le Tableau 4 illustre les différences de configuration entre les règles de pare-feu dynamiques de la carte MS et du SP3. Notez en particulier les différentes définitions des permitactions /deny/reject .
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set s1 {
stateful-firewall-rule-sets rule-set-basic-sfw;
interface-service {
service-interface ms-1/1/0;
}
}
|
service-set s1 {
policies stateful-firewall-rule-sets rule-set-basic-sfw;
interface-service {
service-interface vms-1/1/0;
}
}
|
stateful-firewall {
|
# Enclose stateful firewall rules within the policies wrapper.
policies {
|
rule Rule1 {
match-direction input;
term ping-https-apps {
from {
source-address {
any
}
destination-address {
any
}
applications [junos-icmp-ping junos-https];
}
then {
accept/reject/discard
skip-ids;
syslog;
}
}
term accept {
then {
accept;
}
}
} # end Rule1
|
policies stateful-firewall-rule Rule1 {
match-direction input;
# Define match terms and actions in a policy.
policy ping-https-apps {
# Unlike the from statement, the match statement (and
# source-address, destination-address, and application)
# are mandatory.
match {
source-address any;
destination-address any;
application [ junos-icmp-ping junos-https ];
}
then {
# permit = allow
# deny = silently drop
# reject = drop and send ICMP unreachable or TCP RST
permit/deny/reject
# skip-ids is not supported. One possible way of
# achieving this same goal is to create two
# service-sets, one with IDS and one without IDS,
# and route your next-hop-service
# traffic to the desired service set via the associated
# inside or outside interface.
log;
}
}
policy accept {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
} # end Rule1
|
rule Rule2 {
match-direction output;
term local {
from {
source-address {
10.1.3.2/32;
}
application-sets APPL-SET1;
}
then {
accept;
}
}
} # end Rule2
|
policies stateful-firewall-rule Rule2 {
match-direction output;
policy local {
match {
source-address 10.1.3.2/32;
destination-address any;
# application can refer to an application set.
application APPL-SET1;
}
then {
permit;
}
}
} # end Rule2
|
rule-set rule-set-basic-sfw {
rule Rule1;
rule Rule2;
}
} # end stateful-firewall
|
# Use the stateful-firewall-rule-set element to list the
# firewall rules in the order that you want them applied.
stateful-firewall-rule-set rule-set-basic-sfw {
stateful-firewall-rule Rule1;
stateful-firewall-rule Rule2;
}
} # end policies
|
Listes et plages d’adresses
Les règles de pare-feu dynamiques peuvent contenir des termes de correspondance qui font référence à des plages et à des listes d’adresses.
Sur la carte MS, vous utilisez source-address-range les éléments et destination-address-range pour spécifier les plages d’adresses et prefix-list les éléments sous policy-options pour spécifier les listes d’adresses. L’élément prefix-list n’est pas destiné à être utilisé uniquement pour les règles de pare-feu dynamiques. Vous utilisez également l’élément pour spécifier des listes d’adresses prefix-list à utiliser dans les stratégies de routage.
Sur le SP3, l’élément n’est prefix-list pas utilisé pour les règles de pare-feu dynamiques. Utilisez un under services pour définir des address-book listes et des plages d’adresses à utiliser dans les règles de pare-feu dynamiques. L’élément prefix-list existe toujours, mais il est utilisé exclusivement pour les stratégies de routage. Vous devez donc configurer les deux address-book éléments et prefix-list si vous spécifiez des listes d’adresses pour les règles de pare-feu dynamiques et des listes d’adresses pour les stratégies de routage.
Le Tableau 5 indique les différences entre la façon dont vous spécifiez les adresses pour les règles de pare-feu dynamiques sur la carte MS et la SP3.
Carte MS |
SP3 |
|---|---|
[edit]
policy-options {
prefix-list p1 {
10.1.22.45/32;
192.168.0.11/32;
}
}
[edit services]
stateful-firewall {
rule sfw-rule {
match-direction input;
term banned-addresses {
from {
source-prefix-list {
p1;
}
source-address-range {
low 10.1.22.100 high 10.1.22.109;
}
}
then {
reject;
syslog;
}
}
<...>
|
[edit services]
# Define address lists and address ranges in an address book.
address-book {
global {
address-set p1 {
address p1-a;
address p1-b;
}
address p1-a 10.1.22.45/32;
address p1-b 192.168.0.11/32;
address p2 {
address-range 10.1.22.100/32 {
to {
10.1.22.109/32;
}
}
}
}
} # end address-book
policies {
stateful-firewall-rule sfw-rule {
match-direction input;
policy banned-addresses {
match {
# Refer to the addresses defined in the address book.
source-address [ p1 p2 ];
destination-address any;
application any;
}
then {
deny;
log;
}
<...>
|
Domaines d’application
Le SP3 prend en charge davantage d’applications Junos intégrées que la carte MS. Vous pouvez faire correspondre ces applications intégrées lorsque vous créez une règle de pare-feu dynamique.
Pour afficher la liste complète des applications intégrées, utilisez la show groups junos-defaults applications commande mode configuration. Par exemple :
[edit]
# show groups junos-defaults applications | match junos
application junos-ftp {
application junos-ftp-data {
application junos-tftp {
application junos-twamp {
application junos-rtsp {
application junos-netbios-session {
<...>
Traceoptions et compteurs
Les pare-feu dynamiques pour les services nouvelle génération sur le SP3 prennent en charge des capacités supplémentaires pour aider à déboguer et à compter le trafic :
traceoptions- Permet de tracer les événements liés aux politiques, tels que les recherches de politiques et les événements basés sur des règles. Les événements sont capturés dans le fichier spécifié pour être visualisés.count- Utilisé pour compter les événements liés au trafic tels que les octets et les paquets entrants/sortants. Affichez les compteurs à l’aide des commandes show :show services policies detail- La sortie inclut des compteurs liés au trafic lorsque vous spécifiez l’optioncountdans votre stratégieshow services policies hit-count- Le nombre de visites est toujours disponible, que vous utilisiez ou non l’optioncountdans votre police
Le Tableau 6 montre comment utiliser les traceoptions éléments et count :
Carte MS |
SP3 |
|---|---|
Non pris en charge |
[edit services]
policies {
# Enable traceoptions to trace policy-related events.
traceoptions {
file policylogs size 10m files 5;
flag all;
}
stateful-firewall-rule Rule1 {
match-direction input;
policy my-policy {
match {
source-address any;
destination-address any;
application [ junos-dns-udp junos-dns-tcp ];
}
then {
permit
# Enable counting of traffic events.
count;
}
} # end my-policy
...
|
CGNAT (Carrier Grade Network Address Translation)
La configuration de NAT pour les services de nouvelle génération sur le SP3 diffère de la configuration de NAT sur les services hérités sur la carte MS de plusieurs façons :
Sur le SP3, vous configurez la NAT source séparément de la NAT de destination. Vous configurez le NAT source dans la branche source de l’arborescence de configuration et vous configurez le NAT de destination dans la branche de destination de l’arbre de configuration. Le NAT source et le NAT de destination ont chacun leurs propres ensembles de pools d’adresses et de règles dans leur branche respective de l’arbre de configuration.
Sur le SP3, si vous configurez à la fois la NAT source et la NAT de destination, la NAT de destination s’applique en premier, puis la NAT source s’applique au résultat traduit de la NAT de destination. En d’autres termes, vous écrivez la règle NAT source non pas en fonction du paquet d’origine, mais en fonction du résultat traduit par le NAT de destination.
Sur le SP3, vous ne configurez pas explicitement un
translation-typefichier . Le type de traduction est déterminé implicitement par votre configuration.Sur le SP3, la traduction de ports est le comportement par défaut pour les mappages dynamiques (où différentes adresses pré-NAT peuvent correspondre à la même adresse post-NAT au fil du temps). Si vous n’incluez pas explicitement l’instruction
portdans une définition de pool, la conversion des ports a lieu avec une plage de ports [1024, 65535] et le port est sélectionné de manière circulaire. Si vous ne voulez pas que la traduction de ports ait lieu, vous devez ajouter uneportinstruction avec l’optionno-translation. Cette valeur par défaut ne s’applique pas aux mappages statiques où une adresse pré-NAT est toujours mappée à la même adresse post-NAT.
Les tableaux 7 à 19 montrent des exemples de configuration des différents types de conversion sur le SP3.
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-basic-nat44;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-basic-nat44;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 10.10.10.0/24;
}
|
pool src-pool {
address {
10.10.10.0/24;
}
# host-address-base indicates a type of static mapping
# where the base address 10.45.1.0/0 maps to the
# lowest address in the pool, namely 10.10.10.0/0,
# and the other addresses map sequentially from there
# e.g. 10.45.1.1 maps to 10.10.10.1, and so on.
# Since this is a static mapping, there is no port translation
# by default.
# Note that host-address-base does not have to be the
# lowest address allowed by the subsequent source rule.
# Any packet with a source address allowed by the source rule
# but is lower than the host-address-base is discarded.
host-address-base 10.45.1.0/0;
}
|
rule rule-basic-nat44 {
match-direction input;
term t1 {
from {
source-address {
10.45.1.0/24
}
}
then {
translated {
source-pool src-pool;
translation-type {
basic-nat44;
}
}
}
}
}
|
rule-set rule-basic-nat44 {
match-direction input;
rule r1 {
match {
source-address 10.45.1.0/24;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-basic-nat66;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-basic-nat66;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 2001:DB8:2222::0/96;
}
|
pool src-pool {
address {
2001:DB8:2222::0/96;
}
}
|
rule rule-basic-nat66 {
match-direction input;
term t1 {
from {
source-address {
2001:DB8:1111::0/96;
}
}
then {
translated {
source-pool src-pool;
translation-type {
basic-nat66;
}
}
}
}
}
|
rule-set rule-basic-nat66 {
match-direction input;
rule r1 {
match {
source-address 2001:DB8:1111:::0/96;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-dynamic-nat44;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-dynamic-nat44;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address-range low 10.10.10.2 high 10.10.10.10;
}
|
pool src-pool {
address {
10.10.10.2/32 to 10.10.10.10/32;
}
# Since this is implicitly a dynamic mapping,
# there is port translation by default , so we need to
# explictly specify that we don’t want port translation.
port {
no-translation;
}
}
|
rule rule-dynamic-nat44 {
match-direction input;
term t0 {
from {
applications junos-icmp-all;
}
then {
no-translation;
}
}
term t1 {
from {
destination-address {
10.99.0.2/32;
}
source-address-range {
low 10.45.0.2 high 10.45.0.10;
}
}
then {
translated {
source-pool src-pool;
translation-type {
dynamic-nat44;
}
}
}
}
}
|
rule-set rule-dynamic-nat44 {
match-direction input;
rule r0 {
match {
source-address 0.0.0.0/0;
application junos-icmp-all;
}
then {
source-nat {
off;
}
}
}
rule r1 {
match {
source-address-name addr1;
destination-address 10.99.0.2/32;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
} # end nat
|
address-book {
global {
address addr1 {
address-range 10.45.0.2/32 {
to {
10.45.0.10/32;
}
}
}
}
}
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-napt44;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-napt44;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 10.10.10.0/24;
port {
automatic;
}
}
|
pool src-pool {
address {
10.10.10.0/24;
}
# Since this is implicitly a dynamic mapping,
# and there is no explicit port statement
# to indicate otherwise, the default port
# mapping behavior takes effect.
}
|
rule rule-napt44 {
match-direction input;
term t1 {
from {
source-address {
10.45.1.0/24
}
application-sets accept-algs;
}
then {
translated {
source-pool src-pool;
translation-type {
napt44;
}
}
}
}
}
|
rule-set rule-napt44 {
match-direction input;
rule r1 {
match {
source-address 10.45.1.0/24;
application accept-algs;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-napt66;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-napt66;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 2001:DB8:2222::0/112;
port {
range low 20000 high 30000;
}
}
|
pool src-pool {
address {
2001:DB8:2222::0/112;
}
port {
range {
20000;
to {
30000;
}
}
}
}
|
rule rule-napt66 {
match-direction input;
term t1 {
from {
source-address {
2001:DB8:1111::0/96;
}
}
then {
translated {
source-pool src-pool;
translation-type {
napt66;
}
}
}
}
}
|
rule-set rule-napt66 {
match-direction input;
rule r1 {
match {
source-address 2001:DB8:1111::0/96;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-dnat-44;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-dnat-44;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
destination {
|
pool dest-pool {
address 10.10.10.2/32;
}
|
pool dest-pool {
address {
10.10.10.2/32;
}
}
|
rule rule-dnat-44 {
match-direction input;
term t1 {
from {
destination-address {
10.45.0.2/32
}
}
then {
translated {
destination-pool dest-pool;
translation-type {
dnat-44;
}
}
}
}
}
|
rule-set rule-dnat-44 {
match-direction input;
rule r1 {
match {
destination-address 10.45.0.2/32;
}
then {
destination-nat {
pool {
dest-pool;
}
}
}
}
}
|
} # end nat |
} # end destination
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-stateful-nat464;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-stateful-nat464-src;
nat-rule-sets rule-stateful-nat464-dest;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 10.10.10.0/24;
port {
automatic;
}
}
|
pool src-pool {
address {
10.10.10.0/24;
}
port {
automatic {
round-robin;
}
}
}
|
rule rule-stateful-nat464 {
match-direction input;
term t1 {
from {
source-address {
2001:DB8:1111::0/96;
}
destination-address {
2001:DB8:2222::0/96;
}
applications [junos-icmp-all junos-icmp-ping junos-traceroute junos-traceroute-ttl 1];
}
then {
translated {
source-pool src-pool;
clat-prefix 2001:DB8:1111::0/96;
destination-prefix 2001:DB8:2222::0/96;
translation-type {
stateful-nat464;
}
}
}
}
}
|
# This source rule applies after the destination rule.
rule-set rule-stateful-nat464-src {
match-direction input;
rule r1 {
match {
source-address 2001:DB8:1111::0/96;
# Since destination NAT happens first, the
# destination IPv6 prefix has been stripped off,
# resulting in an IPv4 destination address.
destination-address 0.0.0.0/0;
application [junos-icmp-all junos-icmp-ping junos-traceroute junos-traceroute-ttl 1];
}
then {
source-nat {
pool {
src-pool;
}
clat-prefix 2001:DB8:1111::0/96;
}
}
}
}
|
} # end nat |
} # end source
|
destination {
|
|
# This destination rule applies before the source rule.
rule-set rule-stateful-nat464-dest {
match-direction input;
rule r1 {
match {
destination-address 2001:DB8:2222::0/96;
}
then {
destination-nat {
destination-prefix 2001:DB8:2222::0/96;
}
}
}
}
|
|
} # end destination
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-stateful-nat64;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-stateful-nat64-src;
nat-rule-sets rule-stateful-nat64-dest;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 10.10.10.0/24;
port {
automatic;
random-allocation;
}
}
mapping-timeout 500;
}
|
pool src-pool {
address {
10.10.10.0/24;
}
port {
automatic {
random-allocation;
}
}
mapping-timeout 500;
}
|
rule rule-stateful-nat64 {
match-direction input;
term t1 {
from {
destination-address {
2001:DB8:2222::0/64;
}
}
then {
translated {
source-pool src-pool;
destination-prefix 2001:DB8:2222::0/64;
translation-type {
stateful-nat64;
}
}
}
}
term t2 {
from {
destination-address {
2001:DB8:3333::0/64;
}
}
then {
translated {
source-pool src-pool;
destination-prefix 2001:DB8:3333::0/64;
translation-type {
stateful-nat64;
}
}
}
}
}
|
# This source rule applies after the destination rule.
rule-set rule-stateful-nat64-src {
match-direction input;
rule r1 {
match {
source-address 0::/0;
# Since destination NAT applies first, the
# destination address is now IPv4.
destination-address 0.0.0.0/0;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
|
destination {
|
|
# This destination rule applies before the source rule.
rule-set rule-stateful-nat64-dest {
match-direction input;
rule r1 {
match {
destination-address 2001:DB8:2222::0/64;
}
then {
destination-nat {
destination-prefix 2001:DB8:2222::0/64;
}
}
}
rule r2 {
match {
destination-address 2001:DB8:3333::0/64;
}
then {
destination-nat {
destination-prefix 2001:DB8:3333::0/64;
}
}
}
}
|
|
} # end destination
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-twice-basic-nat-44;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-twice-basic-nat-44-src;
nat-rule-sets rule-twice-basic-nat-44-dest;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 10.98.10.0/24;
}
pool dest-pool {
address 10.99.10.0/24;
}
|
pool src-pool {
address {
10.98.10.0/24;
}
# host-address-base indicates a type of static mapping where
# the base address 10.10.10.0/0 maps to the lowest
# address in the pool, namely 10.98.10.0/0,
# and the other addresses map sequentially from there
# e.g. 10.10.10.1 maps to 10.98.10.1, and so on.
# Since this is a static mapping, there is no port translation
# by default.
# Note that host-address-base does not have to be the
# lowest address allowed by the subsequent source rule.
# Any packet with a source address allowed by the source rule
# but is lower than the host-address-base is discarded.
host-address-base 10.10.10.0/0;
}
|
rule rule-twice-basic-nat-44 {
match-direction input;
term t1 {
from {
source-address {
10.10.10.0/24;
}
destination-address {
10.20.10.0/24;
}
}
then {
translated {
source-pool src-pool;
destination-pool dest-pool;
translation-type {
twice-basic-nat-44;
}
}
}
}
}
|
# This source rule applies after the destination rule.
rule-set rule-twice-basic-nat-44-src {
match-direction input;
rule r1 {
match {
source-address 10.10.10.0/24;
# Since destination NAT happens first, the destination
# address refers to the NAT’d address.
destination-address 10.99.10.0/24;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
|
destination {
|
|
pool dest-pool {
address {
10.99.10.0/24;
}
}
|
|
# This destination rule applies before the source rule.
rule-set rule-twice-basic-nat-44-dest {
match-direction input;
rule r1 {
match {
destination-address 10.20.10.0/24;
}
then {
destination-nat {
pool {
dest-pool;
}
}
}
}
}
|
|
} # end destination
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-twice-dynamic-nat-44;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-twice-dynamic-nat-44-src;
nat-rule-sets rule-twice-dynamic-nat-44-dest;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 10.98.10.0/24;
}
pool dest-pool {
address 10.99.10.0/24;
}
|
pool src-pool {
address {
10.98.10.0/24;
}
port {
no-translation;
}
}
|
rule rule-twice-dynamic-nat-44 {
match-direction input;
term t1 {
from {
source-address {
10.10.10.0/24;
}
destination-address {
10.20.10.0/24;
}
}
then {
translated {
source-pool src-pool;
destination-pool dest-pool;
translation-type {
twice-dynamic-nat-44;
}
}
}
}
}
|
# This source rule applies after the destination rule.
rule-set rule-twice-dynamic-nat-44-src {
match-direction input;
rule r1 {
match {
source-address 10.10.10.0/24;
# Since destination NAT happens first, the destination
# address refers to the NAT’d address.
destination-address 10.99.10.0/24;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
|
destination {
|
|
pool dest-pool {
# By default, address mapping in destination pools is static.
address {
10.99.10.0/24;
}
}
|
|
# This destination rule applies before the source rule.
rule-set rule-twice-dynamic-nat-44-dest {
match-direction input;
rule r1 {
match {
destination-address 10.20.10.0/24;
}
then {
destination-nat {
pool {
dest-pool;
}
}
}
}
}
|
|
} # end destination
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-twice-napt-44;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-twice-napt-44-src;
nat-rule-sets rule-twice-napt-44-dest;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 10.98.10.0/24;
port {
automatic;
secured-port-block-allocation block-size 256 max-blocks-per-address 1 active-block-timeout 300;
}
}
pool dest-pool {
address 10.99.10.2/32;
}
|
pool src-pool {
address {
10.98.10.0/24;
}
port {
automatic {
round-robin;
}
block-allocation {
block-size 256;
maximum-blocks-per-host 1;
active-block-timeout 300;
}
}
}
|
rule rule-twice-napt-44 {
match-direction input;
term t1 {
from {
source-address {
10.10.10.0/24;
}
destination-address {
10.20.10.2/32;
}
}
then {
translated {
source-pool src-pool;
destination-pool dest-pool;
translation-type {
twice-napt-44;
}
}
}
}
}
|
# This source rule applies after the destination rule.
rule-set rule-twice-napt-44-src {
match-direction input;
rule r1 {
match {
source-address 10.10.10.0/24;
# Since destination NAT happens first, the
# destination address refers to the NAT’d address.
destination-address 10.99.10.2/32;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
|
destination {
|
|
pool dest-pool {
address {
10.99.10.2/32;
}
}
|
|
# This destination rule applies before the source rule.
rule-set rule-twice-napt-44-dest {
match-direction input;
rule r1 {
match {
source-address 10.10.10.0/24;
destination-address 10.20.10.2/32;
}
then {
destination-nat {
pool {
dest-pool;
}
}
}
}
}
|
|
} # end destination
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-deterministic-napt44;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-deterministic-napt44;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 10.10.10.0/24;
port {
range low 1024 high 19999;
deterministic-port-block-allocation block-size 256;
}
mapping-timeout 120;
}
|
pool src-pool {
address {
10.10.10.0/24;
}
port {
range {
1024;
to {
19999;
}
}
deterministic {
block-size 256;
# host address specifies the subnet that you
# want to apply to this pool.
host address 10.2.0.0/20;
}
}
mapping-timeout 120;
}
|
rule rule-deterministic-napt44 {
match-direction input;
term t1 {
from {
source-address {
10.2.0.0/18;
}
}
then {
translated {
source-pool src-pool;
translation-type {
deterministic-napt44;
}
mapping-type endpoint-independent;
}
}
}
}
|
rule-set rule-deterministic-napt44 {
match-direction input;
rule r1 {
match {
source-address 10.2.0.0/18;
}
then {
source-nat {
pool {
src-pool;
}
mapping-type endpoint-independent;
}
}
}
}
|
} # end nat |
} # end source
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-deterministic-napt64;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-deterministic-napt64-src;
nat-rule-sets rule-deterministic-napt64-dest;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 10.98.10.0/24;
port {
automatic;
random-allocation;
}
deterministic-port-block-allocation block-size 256;
}
}
|
pool src-pool {
address {
10.98.10.0/24;
}
port {
automatic {
random-allocation;
}
deterministic {
block-size 256;
host address 2001:DB8:1111::1/120;
}
}
}
|
rule rule-deterministic-napt64 {
match-direction input;
term t1 {
from {
source-address {
2001:DB8:1111::1/120;
}
}
then {
translated {
destination-prefix 2001:DB8:2222::/96;
source-pool src-pool;
translation-type {
deterministic-napt64;
}
}
}
}
}
|
# This source rule applies after the destination rule.
rule-set rule-deterministic-napt64-src {
match-direction input;
rule r1 {
match {
source-address 2001:DB8:1111::1/120;
# Since destination NAT happens first, the destination
# address refers to the NAT’d address.
destination-address 0.0.0.0/0;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
|
destination {
|
|
pool dest-pool {
address {
10.99.10.2/32;
}
}
|
|
# This destination rule applies before the source rule.
rule-set rule-destination-napt64-dest {
match-direction input;
rule r1 {
match {
destination-address 2001:DB8:2222::/96;
}
then {
destination-nat {
destination-prefix 2001:DB8:2222::/96;
}
}
}
}
|
|
} # end destination
} # end nat
|
Carte MS |
SP3 |
|---|---|
[edit services] |
[edit services] |
service-set sset1 {
nat-rules rule-napt-pt;
interface-service {
service-interface ms-1/2/0;
}
}
|
service-set sset1 {
nat-rule-sets rule-napt-pt-src;
nat-rule-sets rule-napt-pt-dest;
interface-service {
service-interface vms-2/0/0;
}
}
|
nat {
|
nat {
source {
|
pool src-pool {
address 10.10.10.2/32;
}
pool dest-pool {
address 10.99.10.2/32;
}
|
pool src-pool {
address {
10.10.10.2/32;
}
}
|
rule rule-napt-pt {
match-direction input;
term t1 {
from {
source-address {
2001:DB8:1111::2/128;
}
destination-address {
2001:DB8:2222::2/128;
}
}
then {
translated {
source-pool src-pool;
destination-pool dest-pool;
translation-type {
napt-pt;
}
}
}
}
}
|
rule-set rule-napt-pt-src {
match-direction input;
rule r1 {
match {
source-address 2001:DB8:1111::2/128;
destination-address 10.99.10.0/24;
}
then {
source-nat {
pool {
src-pool;
}
}
}
}
}
|
} # end nat |
} # end source
|
destination {
|
|
pool dest-pool {
address {
10.99.10.2/32;
}
}
|
|
rule-set rule-napt-pt-dest {
match-direction input;
rule r1 {
match {
destination-address 2001:DB8:2222::2/128;
}
then {
destination-nat {
pool {
dest-pool;
}
}
}
}
}
|
|
} # end destination
} # end nat
|
Système de détection des intrusions (IDS)
Les règles IDS pour les services nouvelle génération sur le SP3 sont définies sous la screen branche. Il existe des différences mineures dans la dénomination des différents éléments, mais le principal changement réside dans le comportement de détection des paquets avec des options IPv4 et des extensions IPv6 :
Pour le service IDS sur la carte MS, le comportement par défaut consiste à détecter et à supprimer les paquets avec des options IPv4 et des extensions IPv6. Si vous souhaitez autoriser ces paquets, vous devez les autoriser explicitement via la configuration.
Pour le service IDS Next Gen sur le SP3, le comportement par défaut est d’autoriser les paquets avec des options IPv4 et des extensions IPv6. Si vous souhaitez détecter et supprimer ces paquets, vous devez les interdire explicitement via la configuration.
Le Tableau 21 présente des exemples de différences de configuration.
Carte MS |
SP3 |
|---|---|
[edit services]
service-set sset1 {
ids-rules r1;
ids-rules r2;
}
|
[edit services]
service-set sset1 {
# Replace ids-rules with ids-option.
ids-option ids1;
ids-option ids2;
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
<...>
}
}
}
|
[edit services]
# Define ids rules under the screen branch.
screen {
# Replace rule with ids-option.
ids-option ids1 {
match-direction input;
# Flatten hierarchy by removing term and placing
# contents directly under ids-option.
<...>
}
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
then {
allow-ip-options [ loose-source-route route-record router-alert security stream-id strict-source-route timestamp ];
}
}
}
}
|
[edit services]
screen {
ids-option ids1 {
match-direction input;
# By default, all ip options are allowed.
}
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
then {
<no allow-ip-options configured>
}
}
}
}
|
[edit services]
screen {
ids-option ids1 {
match-direction input;
# Explicitly specify the disallowed options.
ip {
loose-source-route-option;
record-route-option;
security-option;
stream-option;
strict-source-route-option;
timestamp-option;
# router-alert option for IPv4 is not supported.
}
}
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
then {
allow-ipv6-extension-header [ ah dstopts esp fragment hop-by-hop mobility routing ];
}
}
}
}
|
[edit services]
screen {
ids-option ids1 {
match-direction input;
# By default, all ipv6 extensions are allowed.
}
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
then {
<no allow-ipv6-extension-header configured>
}
}
}
}
|
[edit services]
screen {
ids-option ids1 {
match-direction input;
ip {
# Explicitly specify the disallowed extensions.
ipv6-extension-header {
AH-header;
ESP-header;
fragment-header;
hop-by-hop-header;
mobility-header;
routing-header;
# dstoptions is not supported.
}
}
}
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
then {
aggregation {
source-prefix 24;
destination-prefix 24;
source-prefix-ipv6 64;
destination-prefix-ipv6 64;
}
}
}
}
}
|
[edit services]
screen {
ids-option ids1 {
match-direction input;
aggregation {
source-prefix-mask 24;
destination-prefix-mask 24;
source-prefix-v6-mask 64;
destination-prefix-v6-mask 64;
}
}
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
then {
icmp-fragment-check;
icmp-large-packet-check;
}
}
}
}
|
[edit services]
screen {
ids-option ids1 {
match-direction input;
# Group icmp checks under icmp.
icmp {
fragment;
large;
}
}
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
then {
land-attack-check;
tcp-winnuke-check;
tcp-syn-fragment-check;
tcp-syn-defense;
}
}
}
}
|
[edit services]
screen {
ids-option ids1 {
match-direction input;
# Group tcp checks under tcp.
tcp {
land;
winnuke;
syn-frag;
# tcp-syn-defense is not supported.
}
}
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
then {
session-limit {
by-source {
maximum 100;
rate 10;
packets 1k;
}
by-destination {
maximum 100;
rate 10;
packets 1k;
}
}
}
}
}
}
|
[edit services]
screen {
ids-option ids1 {
match-direction input;
limit-session {
by-source {
maximum-sessions 100;
session-rate 10;
packet-rate 1k;
}
by-destination {
maximum-sessions 100;
session-rate 10;
packet-rate 1k;
}
}
}
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
then {
session-limit {
by-source {
by-protocol {
tcp {
maximum 100;
rate 10;
packets 1k;
}
udp {
maximum 100;
rate 10;
packets 1k;
}
icmp {
maximum 100;
rate 10;
packets 1k;
}
}
}
}
}
}
}
|
[edit services]
screen {
ids-option ids1 {
match-direction input;
limit-session {
by-source {
by-protocol {
tcp {
maximum-sessions 100;
session-rate 10;
packet-rate 1k;
}
udp {
maximum-sessions 100;
session-rate 10;
packet-rate 1k;
}
icmp {
maximum-sessions 100;
session-rate 10;
packet-rate 1k;
}
}
}
}
}
}
|
[edit services]
ids {
rule r1 {
match-direction input;
term t1 {
then {
session-limit {
by-destination {
by-protocol {
tcp {
maximum 100;
rate 10;
packets 1k;
}
udp {
maximum 100;
rate 10;
packets 1k;
}
icmp {
maximum 100;
rate 10;
packets 1k;
}
}
}
}
}
}
}
|
[edit services]
screen {
ids-option ids1 {
match-direction input;
limit-session {
by-destination {
by-protocol {
tcp {
maximum-sessions 100;
session-rate 10;
packet-rate 1k;
}
udp {
maximum-sessions 100;
session-rate 10;
packet-rate 1k;
}
icmp {
maximum-sessions 100;
session-rate 10;
packet-rate 1k;
}
}
}
}
}
}
|
Migrer de la carte MS vers le SP3
Utilisez cette procédure pour configurer un routeur afin qu’il prenne en charge les services de nouvelle génération.
Vous utilisez généralement cette procédure pour migrer un routeur prenant en charge les services hérités sur la carte MS vers un routeur prenant en charge les services de nouvelle génération sur le SP3, mais cette procédure s’applique même si le routeur à partir duquel vous migrez ne contient pas de cartes MS.
Étant donné que la configuration des services nouvelle génération n’est pas compatible avec le provisionnement de services hérité, la migration d’un routeur pour prendre en charge les services nouvelle génération sur le SP3 nécessite que vous déprovisionniez et reprovisionnez complètement votre routeur. De plus :
Vous ne pouvez pas installer une carte SP3 dans un routeur qui a des cartes MS.
Vous ne pouvez pas configurer les services nouvelle génération sur un routeur équipé de cartes MS.
Vous ne pouvez pas configurer les services hérités sur un routeur équipé de cartes SP3.
En d’autres termes, un routeur peut fonctionner avec des cartes MS ou SP3, mais pas les deux en même temps.
Cette procédure affecte le service. Vous configurez le routeur sur la configuration d’usine par défaut.