Diferencias de configuración entre los servicios adaptables y los servicios de próxima generación en el MX-SPC3
Visión general
Los servicios de próxima generación en el MX-SPC3 requieren que configure los servicios de manera diferente a lo que está acostumbrado con Adaptive Services, que se ejecutan en tarjetas de tipo MS (MS-MPC, MS-MIC y MS-DPC). La configuración de la tarjeta de servicios MX-SPC3 se ajusta más a la forma de configurar la puerta de enlace de servicios de la serie SRX. Una vez que esté familiarizado con este enfoque más unificado, debería poder configurar los servicios en estas dos plataformas de una manera más fluida, lo que en última instancia redundará en una menor sobrecarga de capacitación y un menor riesgo de errores de configuración.
Aparte de las diferencias de CLI, debe tener en cuenta las diferencias básicas de hardware entre las tarjetas de tipo multiservicio (MS-DPC, MS-MPC y MS-MIC) y la tarjeta de servicios MX-SPC3. Las tarjetas de tipo MS contienen cuatro complejos de CPU, mientras que la tarjeta MX-SPC3, aunque más potente, contiene dos complejos de CPU. Cada complejo de CPU da servicio a una sola PIC, lo que significa que las tarjetas de tipo MS admiten cuatro PIC, mientras que el MX-SPC3 admite dos PIC. Las tarjetas tipo MS utilizan PIC de multiservicios especiales (MS) y servicios adaptativos (AS), mientras que las PIC de la tarjeta MX-SPC3 están integradas.
Dado que el número de PIC afecta directamente al número de interfaces (tabla 1), es posible que deba agregar unidades lógicas a cada interfaz en la MX-SPC3 para aumentar el número de interfaces a cuatro. Por ejemplo, si actualmente utiliza las cuatro interfaces de la tarjeta de tipo MS y tiene un conjunto de servicios por interfaz, puede crear dos unidades lógicas por interfaz en MX-SPC3 para elevar el número total de interfaces a cuatro y, a continuación, volver a asociar los cuatro conjuntos de servicios a estas cuatro interfaces lógicas.
Tarjetas MS |
MX-SPC3 |
|
|---|---|---|
Número de complejos de CPU |
4 |
2 |
Número de PIC por complejo de CPU |
1 |
1 |
Número de interfaces por PIC |
1 |
1 |
Número total de interfaces en la tarjeta |
4 |
2 |
|
Nota:
Consulte la Referencia del módulo de interfaz de plataforma de enrutamiento universal 5G de la serie MX para obtener más información sobre el hardware MX-SPC3. |
||
En las secciones siguientes se proporciona una descripción general de las diferencias de configuración básicas entre los servicios de las tarjetas de tipo MS y los servicios de la tarjeta MX-SPC3. La intención de estas secciones es ayudarle a empezar mediante el uso de ejemplos básicos para ilustrar los principales cambios. Estos ejemplos muestran un subconjunto de las opciones de configuración de CLI y no reemplazan el tratamiento más formal del tema que se encuentra en la Guía del usuario de interfaces de servicios de próxima generación para dispositivos de enrutamiento y la Guía de referencia de CLI de Junos OS.
Los ejemplos de configuración de estas secciones se presentan uno al lado del otro para que pueda ver fácilmente las diferencias entre ambos. El objetivo de los ejemplos es mostrarle cómo configurar las funciones existentes de la tarjeta de tipo MS en el MX-SPC3. Los ejemplos no pretenden mostrarle cómo configurar nuevas funciones que solo se encuentran en el MX-SPC3. Para facilitar la legibilidad y la comparación, el orden de las instrucciones presentadas puede diferir ligeramente del orden real de las instrucciones que se muestran en la CLI.
Si tiene un gran conjunto de servicios adaptables existentes, reconocemos que estos cambios pueden ser un inconveniente para usted. Para ayudarle a migrar de tarjetas tipo MS a MX-SPC3, le sugerimos que proceda de la siguiente manera:
Consulte los ejemplos de esta guía para obtener una visión general de los cambios necesarios.
Consulte el conjunto de ejemplos de configuración del artículo KB35348 de Knowledge Base.
Consulte esta guía y la Guía de referencia de la CLI de Junos OS para comprender todas las características, opciones de configuración y sintaxis.
Comuníquese con el JTAC para obtener ayuda con la migración.
No es necesario realizar estos cambios de configuración si continúa ejecutando servicios adaptables en las tarjetas de tipo MS. Sin embargo, una vez que implemente MX-SPC3 en un enrutador, debe reemplazar todas las tarjetas de tipo MS en ese enrutador y volver a configurar los servicios para alinearlos con el paradigma de configuración de servicios de próxima generación.
Interfaces
Las tarjetas de tipo MS utilizan la convención ms-1/0/0de nomenclatura de interfaz , mientras que las interfaces MX-SPC3 se especifican mediante multiservicios virtuales o vms-1/0/0 convención de nomenclatura de interfaz. No hay cambios en los nombres ni ams mams en las interfaces.
Además, varios parámetros que se configuran en services-options en una ms interfaz se configuran en service-set-options en un conjunto de servicios.
La Tabla 2 muestra ejemplos de estos cambios.
Tarjetas tipo MS |
MX-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 {
<...>
}
}
}
}
|
Consulte |
[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;
}
}
}
|
No compatible |
Conjunto de servicios
La Tabla 3 muestra cambios menores en la forma en que se configuran algunos service-set parámetros.
Tarjetas tipo MS |
MX-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 <...>
}
|
La orden de servicio es fija. |
[edit services]
service-set sset1 {
sampling-service <...>
}
|
El registro de J-Flow se admite en línea. |
[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;
}
}
|
Actualmente no se admite |
Firewall de estado
Reglas y políticas
Las reglas de firewall con estado del MX-SPC3 están estructuradas de forma ligeramente diferente a las reglas de firewall con estado para los servicios de las tarjetas de tipo MS. En el MX-SPC3, se encierran las reglas dentro de un policies contenedor y se definen los términos y acciones de coincidencia para la regla en un policy contenido dentro de la regla.
Al igual que un servicio de firewall con estado en la tarjeta de tipo MS, se crea un conjunto de servicios para asociar una interfaz con un conjunto de reglas. Un conjunto de reglas contiene referencias a una o más reglas. Las reglas se aplican secuencialmente en el orden en que se enumeran hasta que se produce una coincidencia y se realiza una acción.
Cada regla contiene uno o más pares de términos y acciones de coincidencia. En el MX-SPC3, cada par de términos y acciones de coincidencia se denomina política. Las directivas se aplican secuencialmente en el orden en que se especifican hasta que se produce una coincidencia y se realiza una acción.
La Tabla 4 muestra las diferencias de configuración entre las reglas de firewall con estado en la tarjeta MS y la MX-SPC3. En particular, tenga en cuenta las diferentes definiciones de las permitacciones /deny/.reject
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Listas de direcciones y rangos
Las reglas de firewall con estado pueden contener términos coincidentes que hacen referencia a rangos de direcciones y listas.
En la tarjeta MS, utilice source-address-range elementos y destination-address-range para especificar rangos de direcciones y prefix-list elementos en policy-options para especificar listas de direcciones. El prefix-list elemento no se utiliza únicamente para reglas de firewall con estado. También puede utilizar el elemento para especificar listas de direcciones para utilizarlas prefix-list en las directivas de enrutamiento.
En el MX-SPC3, el prefix-list elemento no se utiliza para reglas de firewall con estado. Utilice un address-book bajo services para definir listas de direcciones y rangos para su uso dentro de las reglas de firewall de estado. El prefix-list elemento sigue existiendo, pero se utiliza exclusivamente para las directivas de enrutamiento. Por lo tanto, debe configurar ambos address-book elementos y prefix-list si especifica listas de direcciones para reglas de firewall con estado y listas de direcciones para directivas de enrutamiento.
En la tabla 5 se muestran las diferencias entre la forma de especificar direcciones para las reglas de firewall con estado en la tarjeta MS y la MX-SPC3.
Tarjeta MS |
MX-SPC3 |
|---|---|
[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;
}
<...>
|
Aplicaciones
El MX-SPC3 admite más aplicaciones integradas de Junos que la tarjeta MS. Puede hacer coincidir estas aplicaciones integradas al crear una regla de firewall con estado.
Para ver la lista completa de aplicaciones integradas, utilice el comando de show groups junos-defaults applications modo de configuración. Por ejemplo:
[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 y contadores
Los firewalls con estado para los servicios de próxima generación en el MX-SPC3 admiten capacidades adicionales para ayudar a depurar y contar el tráfico:
traceoptions- Se utiliza para rastrear eventos relacionados con políticas, como búsquedas de políticas y eventos basados en reglas. Los eventos se capturan en el archivo especificado para su visualización.count- Se utiliza para contar eventos relacionados con el tráfico, como bytes y paquetes entrantes / salientes. Vea los contadores mediante los comandos show:show services policies detail- El resultado incluye contadores relacionados con el tráfico cuando especifica la opción en sucountpolíticashow services policies hit-count- El recuento de visitas siempre está disponible, independientemente de si utiliza lacountopción en su póliza o no
En la Tabla 6 se muestra cómo utilizar los traceoptions elementos y count :
Tarjeta MS |
MX-SPC3 |
|---|---|
No compatible |
[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
...
|
Traducción de direcciones de red de grado de operador (CGNAT)
La configuración de NAT para servicios de próxima generación en MX-SPC3 difiere de la configuración de NAT en servicios heredados en la tarjeta MS en varios aspectos:
En el MX-SPC3, la NAT de origen se configura por separado de la NAT de destino. La NAT de origen se configura en la rama de origen del árbol de configuración y la NAT de destino en la rama de destino del árbol de configuración. La TDR de origen y la NAT de destino tienen sus propios conjuntos de reglas y grupos de direcciones en su rama respectiva del árbol de configuración.
En el MX-SPC3, si configura tanto la TDR de origen como la TDR de destino, la TDR de destino se aplica primero y, a continuación, la TDR de origen se aplica al resultado traducido de la NAT de destino. En otras palabras, la regla NAT de origen no se escribe en función del paquete original, sino en función del resultado traducido de NAT de destino.
En el MX-SPC3, no se configura explícitamente un archivo .
translation-typeEl tipo de traducción viene determinado implícitamente por la configuración.En el MX-SPC3, la traducción de puertos es el comportamiento predeterminado para las asignaciones dinámicas (donde diferentes direcciones pre-NAT pueden asignarse a la misma dirección post-NAT con el tiempo). Si no incluye explícitamente la instrucción en una definición de
portgrupo, la traducción de puertos se realiza con un intervalo de puertos [1024, 65535] y el puerto se selecciona de forma rotativa. Si no desea que se realice la traducción de puertos, debe agregar unaportinstrucción con lano-translationopción. Este valor predeterminado no se aplica a las asignaciones estáticas en las que una dirección pre-NAT siempre se asigna a la misma dirección post-NAT.
Las Tablas 7 a 19 muestran ejemplos de cómo se configuran los diferentes tipos de traducción en el MX-SPC3.
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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;
}
}
}
}
}
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Tarjeta MS |
MX-SPC3 |
|---|---|
[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
|
Sistema de detección de intrusos (IDS)
Las reglas de IDS para los servicios de próxima generación en el MX-SPC3 se definen en la screen rama. Existen pequeñas diferencias en la denominación de los distintos elementos, pero el cambio principal está en el comportamiento para detectar paquetes con opciones IPv4 y extensiones IPv6:
Para el servicio IDS en la tarjeta MS, el comportamiento predeterminado es detectar y descartar paquetes con opciones IPv4 y extensiones IPv6. Si desea permitir estos paquetes, debe permitirlos explícitamente a través de la configuración.
Para el servicio IDS Next Gen en el MX-SPC3, el comportamiento predeterminado es permitir paquetes con opciones IPv4 y extensiones IPv6. Si desea detectar y descartar estos paquetes, debe rechazarlos explícitamente a través de la configuración.
La Tabla 21 muestra ejemplos de las diferencias de configuración.
Tarjeta MS |
MX-SPC3 |
|---|---|
[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;
}
}
}
}
}
}
|
Migrar de la tarjeta MS a la MX-SPC3
Use este procedimiento para configurar un enrutador para que admita los servicios de próxima generación.
Normalmente, este procedimiento se utiliza para migrar un enrutador compatible con servicios heredados en la tarjeta MS a un enrutador compatible con servicios de próxima generación en MX-SPC3, pero este procedimiento se aplica incluso si el enrutador desde el que está migrando no contiene tarjetas de tarjeta MS.
Dado que la configuración de los servicios de próxima generación no es compatible con el aprovisionamiento de servicios heredados, para migrar un enrutador para que admita los servicios de próxima generación en el MX-SPC3 es necesario desaprovisionar y reaprovisionar completamente el enrutador. Además:
No puede instalar una tarjeta MX-SPC3 en un enrutador que tenga tarjetas MS.
No puede configurar los servicios de próxima generación en un enrutador equipado con tarjetas MS.
No puede configurar servicios heredados en un enrutador equipado con tarjetas MX-SPC3.
En otras palabras, un enrutador puede ejecutarse con tarjetas MS o tarjetas MX-SPC3, pero no con ambas al mismo tiempo.
Este procedimiento afecta al servicio. Está estableciendo el enrutador en la configuración predeterminada de fábrica.