Diferencias de configuración entre los servicios adaptativos y los servicios de última generación
Descripción general
Los servicios de próxima generación requieren que configure los servicios de manera diferente a lo que está acostumbrado con los servicios adaptativos, que se ejecutan en tarjetas de tipo MS (MS-MPC, MS-MIC y MS-CPC). La configuración de la tarjeta de servicios SPC3 se alinea más estrechamente con la forma en que configura la puerta de enlace de servicios. Una vez que se familiarice 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 resultará en una menor sobrecarga de capacitación y un menor riesgo de error de configuración.
Aparte de las diferencias de la CLI, debe tener en cuenta las diferencias básicas de hardware entre las tarjetas de tipo multiservicios (MS-CPC, MS-MPC y MS-MIC) y la tarjeta de servicios SPC3. Las tarjetas de tipo MS contienen cuatro complejos de CPU, mientras que la tarjeta SPC3, aunque es más potente, contiene dos complejos de CPU. Cada complejo de CPU da servicio a una única PIC, lo que significa que las tarjetas de tipo MS admiten cuatro PIC, mientras que la SPC3 admite dos PIC. Las tarjetas tipo MS utilizan PIC especiales de multiservicios (MS) y servicios adaptativos (AS), mientras que las PIC de la tarjeta SPC3 están integradas.
Dado que el número de PIC afecta directamente al número de interfaces (tabla 1), es posible que tenga que agregar unidades lógicas a cada interfaz de la SPC3 para aumentar el número de interfaces a cuatro. Por ejemplo, si actualmente usa las cuatro interfaces de la tarjeta tipo MS y tiene un conjunto de servicios por interfaz, puede crear dos unidades lógicas por interfaz en la SPC3 para elevar el número total de interfaces a cuatro y, luego, volver a asociar los cuatro conjuntos de servicios a estas cuatro interfaces lógicas.
Tarjetas MS |
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 la plataforma de enrutamiento universal 5G de la serie MX para obtener más información sobre el hardware 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 SPC3. La intención de estas secciones es ayudarlo a comenzar mediante el uso de ejemplos básicos para ilustrar los cambios principales. Estos ejemplos muestran un subconjunto de las opciones de configuración de la 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 la CLI de Junos OS.
Los ejemplos de configuración en estas secciones se presentan uno al lado del otro para que pueda ver fácilmente las diferencias entre los dos. El objetivo de los ejemplos es mostrarle cómo configurar las funciones de tarjeta tipo MS existentes en la SPC3. Los ejemplos no pretenden mostrarle cómo configurar nuevas características que solo se encuentran en SPC3. Para mayor legibilidad y facilidad de 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 conjunto grande de servicios adaptables existentes, reconocemos que estos cambios pueden ser un inconveniente para usted. Para ayudarle a migrar de tarjetas de tipo MS a 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 en el artículo KB35348 de la base de conocimientos.
Consulte esta guía y la Guía de referencia de la CLI de Junos OS para comprender todas las características, las opciones de configuración y la sintaxis.
Comuníquese con el JTAC para obtener ayuda con su 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 la SPC3 en un enrutador, debe reemplazar todas las tarjetas tipo MS en ese enrutador y reconfigurar sus 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 SPC3 se especifican mediante la convención de nomenclatura de interfaz o vms-1/0/0 multiservicios virtuales. No hay cambios en los nombres de ams las interfaces ni mams en los nombres.
Además, una serie de parámetros que se configuran en services-options una ms interfaz se configuran en service-set-options un conjunto de servicios.
En la Tabla 2 se muestran ejemplos de estos cambios.
Tarjetas tipo 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 {
<...>
}
}
}
}
|
Véase |
[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
En la Tabla 3 se muestran cambios menores en la forma en que se configuran algunos service-set parámetros.
Tarjetas tipo 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 <...>
}
|
El orden de servicio es fijo. |
[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 compatible |
firewall de inspección de estado
Reglas y políticas
Las reglas de firewall con estado en la SPC3 están estructuradas de forma ligeramente diferente a las reglas de firewall con estado para servicios en las tarjetas de tipo MS. En la 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 varias reglas. Las reglas se aplican secuencialmente en el orden en que las enumera hasta que se produce una coincidencia y se lleva a cabo una acción.
Cada regla contiene uno o más pares de términos y acciones de coincidencia. En la SPC3, cada par de términos y acciones de coincidencia se denomina política. Las políticas se aplican secuencialmente en el orden en que se especifican hasta que se produce una coincidencia y se lleva a cabo una acción.
En la tabla 4 se muestran las diferencias de configuración entre las reglas de firewall con estado de la tarjeta MS y el SP3. En particular, tenga en cuenta las diferentes definiciones de las permitacciones /deny/reject .
Tarjeta 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
|
Listas de direcciones y rangos
Las reglas de firewall con estado pueden contener términos de coincidencia que hacen referencia a rangos de direcciones y listas.
En la tarjeta MS, utilice source-address-range 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 debe usarse únicamente para reglas de firewall con estado. También utilice el prefix-list elemento para especificar listas de direcciones para su uso en las políticas de enrutamiento.
En el SP3, el prefix-list elemento no se usa para reglas de firewall con estado. Utilice un address-book bajo services para definir listas de direcciones y rangos para su uso dentro de reglas de firewall con estado. El prefix-list elemento todavía existe, pero se usa exclusivamente para políticas 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 políticas de enrutamiento.
En la tabla 5 se muestran las diferencias entre la forma en que se especifican las direcciones para las reglas de firewall con estado en la tarjeta MS y en la SP3.
Tarjeta 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;
}
<...>
|
Aplicaciones
El SP3 admite más aplicaciones integradas de Junos que la tarjeta MS. Puede hacer coincidir en estas aplicaciones integradas al crear una regla de firewall con estado.
Para ver la lista completa de aplicaciones integradas, use el comando del modo de show groups junos-defaults applications 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 {
<...>
Opciones de seguimiento y contadores
Los firewalls de estado para servicios de próxima generación en el SP3 admiten capacidades adicionales para ayudar a depurar y contar el tráfico:
traceoptions- Úselo 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 entrantes y salientes y paquetes. Vea los contadores usando los comandos show:show services policies detail- El resultado incluye contadores relacionados con el tráfico cuando se especifica la opción en lacountpolíticashow services policies hit-count- El recuento de visitas siempre está disponible, independientemente de si usa lacountopción en su póliza o no.
En la Tabla 6 se muestra cómo utilizar los traceoptions elementos y count :
Tarjeta MS |
SP3 |
|---|---|
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 TDR para servicios de próxima generación en el SP3 difiere de la configuración de TDR en servicios heredados en la tarjeta MS de varias maneras:
En el SP3, el TDR de origen se configura por separado del TDR de destino. Configure el TDR de origen en la rama de origen del árbol de configuración y configure el TDR de destino en la rama de destino del árbol de configuración. El TDR de origen y el TDR de destino tienen cada uno sus propios conjuntos de conjuntos de direcciones y reglas en su rama respectiva del árbol de configuración.
En el SP3, si configura tanto la TDR de origen como la TDR de destino, se aplica primero la TDR de destino y, a continuación, la TDR de origen se aplica al resultado traducido de la TDR de destino. En otras palabras, escribe la regla TDR de origen no en función del paquete original, sino en función del resultado TDR de destino traducido.
En el SP3, no se configura explícitamente un
translation-typearchivo . El tipo de traducción viene determinado implícitamente por la configuración.En el SP3, la traducción de puertos es el comportamiento predeterminado para las asignaciones dinámicas (donde diferentes direcciones pre-TDR pueden asignarse a la misma dirección post-TDR a lo largo del tiempo). Si no incluye explícitamente la instrucción en una definición de agrupación, la
porttraducción de puertos se realiza con un rango de puertos [1024, 65535] y el puerto se selecciona en forma de operación 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-TDR siempre se asigna a la misma dirección post-TDR.
De la tabla 7 a la tabla 19 se muestran ejemplos de cómo se configuran los distintos tipos de traducción en el SP3.
Tarjeta 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
|
Tarjeta 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
|
Tarjeta 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;
}
}
}
}
}
|
Tarjeta 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
|
Tarjeta 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
|
Tarjeta 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
|
Tarjeta 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
|
Tarjeta 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
|
Tarjeta 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
|
Tarjeta 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
|
Tarjeta 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
|
Tarjeta 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
|
Tarjeta 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
|
Tarjeta 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
|
Sistema de detección de intrusiones (IDS)
Las reglas de IDS para los servicios de próxima generación en el SP3 se definen en la screen rama. Existen pequeñas diferencias en la nomenclatura 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 de próxima generación de IDS en el SP3, 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.
En el Cuadro 21 se muestran ejemplos de las diferencias de configuración.
Tarjeta 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;
}
}
}
}
}
}
|
Migrar de la tarjeta MS a la SP3
Utilice este procedimiento para configurar un enrutador para que admita servicios de próxima generación.
Normalmente, este procedimiento se utiliza para migrar un enrutador que admite servicios heredados en la tarjeta MS a un enrutador que admite servicios de próxima generación en el SP3, 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 servicios de próxima generación no es compatible con el aprovisionamiento de servicios heredados, la migración de un enrutador para admitir servicios de próxima generación en el SP3 requiere que desaprovisione y vuelva a aprovisionar completamente el enrutador. Además:
No puede instalar una tarjeta SP3 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 SP3.
En otras palabras, un enrutador puede ejecutarse con tarjetas MS o tarjetas SP3, pero no ambas al mismo tiempo.
Este procedimiento afecta al servicio. Está estableciendo el enrutador a la configuración predeterminada de fábrica.