Familia de protocolo y propiedades de dirección de interfaz
En esta sección se explica cómo configurar la familia de protocolos y las propiedades de dirección de interfaz.
Configurar la familia de protocolos
Una familia de protocolos es un grupo de propiedades lógicas dentro de una configuración de interfaz. Las familias de protocolos incluyen todos los protocolos que componen un conjunto de protocolos. Para utilizar un protocolo dentro de un conjunto determinado, debe configurar toda la familia de protocolos como una propiedad lógica para una interfaz.
Las familias de protocolos incluyen los siguientes conjuntos de protocolos comunes:
-
Inet: admite tráfico de protocolo IP, incluidos OSPF, BGP y el Protocolo de mensajes de control de Internet (ICMP).
-
Inet6: admite tráfico de protocolo IPv6, incluyendo RIP para IPv6 (RIPng), IS-IS y BGP.
-
ISO: admite tráfico IS-IS.
-
MPLS: admite MPLS.
Para configurar la familia de protocolos para la interfaz lógica, incluya la family instrucción y especifique la familia seleccionada.
Al configurar la familia de protocolos, realice las siguientes tareas en la [edit interfaces interface-name unit logical-unit-number family family] jerarquía.
-
Configure MTU.
-
Configure la unidad y la familia para que la interfaz pueda transmitir y recibir tráfico de multidifusión solamente.
-
Desactive el envío de mensajes de redireccionamiento por parte del router.
-
Asigne una dirección a una interfaz.
Asignar la dirección de interfaz
Para asignar una dirección a una interfaz, especifique la dirección al configurar la familia de protocolos. Para la inet familia oinet6, configure la dirección IP de la interfaz. Para la iso familia, configure una o más direcciones para la interfaz de circuito cerrado. Para las cccfamilias, ethernet-switching, mplstcctnp, , , y vpls nunca se configura una dirección.
Para asignar una dirección a una interfaz, realice los pasos siguientes:
Configurar direcciones e interfaces predeterminadas, principales y preferidas
En las secciones siguientes se describe cómo configurar direcciones e interfaces predeterminadas, principales y preferidas.
- Direcciones e interfaces predeterminadas, principales y preferidas
- Configurar la interfaz principal para el enrutador
- Configurar la dirección principal de una interfaz
- Configurar la dirección preferida para una interfaz
Direcciones e interfaces predeterminadas, principales y preferidas
El enrutador tiene una dirección predeterminada y una interfaz principal; y las interfaces tienen direcciones principales y preferidas.
La dirección predeterminada del enrutador se utiliza como dirección de origen en interfaces no numeradas. El proceso del protocolo de enrutamiento intenta seleccionar la dirección predeterminada como ID de enrutador, que utilizan los protocolos, incluidos OSPF y BGP interno (IBGP).
La interfaz principal para el enrutador es la interfaz que salen los paquetes cuando no se especifica ningún nombre de interfaz y cuando la dirección de destino no implica una interfaz de salida en particular.
La dirección principal de una interfaz se utiliza de forma predeterminada como dirección local para los paquetes de difusión y multidifusión que se originan localmente y se envían a la interfaz. La dirección preferida de una interfaz es la dirección local predeterminada que se usa para los paquetes que el enrutador local envía a destinos en la subred.
Puede marcar explícitamente la IP de una interfaz como principal y preferida mediante una instrucción de configuración. Si a una interfaz solo se le asigna una única IP, esa dirección se considera la dirección principal y preferida de forma predeterminada. Cuando se asignan varias direcciones IP, ninguna de las cuales se configura explícitamente como principal, se utiliza la dirección IP numéricamente más baja como dirección principal en esa interfaz.
La dirección predeterminada del enrutador se elige mediante la siguiente secuencia:
-
Se utiliza la dirección principal de la interfaz
lo0de circuito cerrado que no127.0.0.1se utiliza. -
Se utiliza la dirección principal de la interfaz principal.
-
Cuando hay varias interfaces con direcciones "principal" y "preferida", se selecciona la interfaz con el índice de interfaz más bajo y se utiliza la dirección principal. En el caso de que ninguna de las direcciones IP de la interfaz esté marcada explícitamente con la
primaryinstrucción, se utiliza la dirección numéricamente más baja de esa interfaz como dirección predeterminada del sistema. -
Se puede seleccionar cualquier interfaz restante con una dirección IP. Esto incluye la administración del enrutador o las interfaces internas. Por este motivo, se recomienda asignar una dirección de circuito cerrado, o configurar explícitamente una interfaz principal, para controlar la selección de direcciones predeterminadas.
Configurar la interfaz principal para el enrutador
La interfaz principal para el enrutador tiene las siguientes características:
-
Es la interfaz que salen los paquetes cuando se escribe un comando como ping 255.255.255.255, es decir, un comando que no incluye un nombre de interfaz (no hay ningún calificador de interfaz
type-0/0/0.0) y donde la dirección de destino no implica ninguna interfaz saliente en particular. -
Es la interfaz en la que las aplicaciones de multidifusión que se ejecutan localmente en el enrutador, como el Protocolo de anuncio de sesión (SAP), se unen a grupos de forma predeterminada.
-
Es la interfaz de la que se deriva la dirección local predeterminada para los paquetes que salen de una interfaz no numerada si no hay direcciones que no sean 127 configuradas en la interfaz de circuito cerrado, lo0.
De forma predeterminada, la interfaz con capacidad de multidifusión con la dirección de índice más bajo se elige como interfaz principal.
Para configurar una interfaz diferente para que sea la interfaz principal, incluya la primary instrucción:
primary
Puede incluir esta instrucción en el siguiente nivel jerárquico:
[edit interfaces interface-name unit logical-unit-number family family]
Configurar la dirección principal de una interfaz
La dirección principal de una interfaz es la dirección que se utiliza de forma predeterminada como dirección local para los paquetes de difusión y multidifusión de origen local y enviados a la interfaz. Por ejemplo, la dirección local en los paquetes enviados por un ping interface et-0/0/0.0 255.255.255.255 comando es la dirección principal en la interfaz et-0/0/0.0. El indicador de dirección principal también puede ser útil para seleccionar la dirección local utilizada para paquetes enviados a interfaces no numeradas cuando se configuran varias direcciones que no son 127 en la interfaz de circuito cerrado, lo0. De forma predeterminada, la dirección principal de una interfaz se selecciona como la dirección local numéricamente más baja configurada en la interfaz.
Para establecer una dirección principal diferente, incluya la primary instrucción:
primary
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit interfaces interface-name unit logical-unit-number family family address address]
Configurar la dirección preferida para una interfaz
La dirección preferida en una interfaz es la dirección local predeterminada que se usa para los paquetes que el enrutador local envía a destinos en la subred. De forma predeterminada, se elige la dirección local numéricamente más baja. Por ejemplo, si las direcciones 172.16.1.1/12, 172.16.1.2/12y 172.16.1.3/12 están configuradas en la misma interfaz, la dirección preferida de la subred (de forma predeterminada, 172.16.1.1) se utiliza como dirección local al emitir un ping 172.16.1.5 comando.
Para establecer una dirección preferida diferente para la subred, incluya la preferred instrucción:
preferred
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit interfaces interface-name unit logical-unit-number family family address address]
Comportamiento operativo de interfaces con la misma dirección IPv4
Puede configurar la misma dirección IP versión 4 (IPv4) en varias interfaces físicas. Cuando se asigna la misma dirección IPv4 a varias interfaces físicas, el comportamiento operativo de esas interfaces difiere dependiendo de si son (implícitamente) punto a punto o no.
Si configura la misma dirección IP en varias interfaces en la misma instancia de enrutamiento, el sistema operativo aplica la configuración aleatoriamente en una de las interfaces. Las otras interfaces permanecerán sin una dirección IP.
Los siguientes ejemplos muestran la configuración de ejemplo para asignar la misma dirección IPv4 a interfaces que son implícita y explícitamente interfaces punto a punto. Los ejemplos también muestran los show interfaces terse resultados de comando que corresponden a las interfaces punto a punto implícitas y explícitas para mostrar su estado operativo.
-
Configuración de la misma dirección IPv4 en dos interfaces que no son P2P:
[edit interfaces] user@host# show et-0/1/0 { unit 0 { family inet { address 203.0.113.1/24; } } }et-3/0/1 { unit 0 { family inet { address 203.0.113.1/24; } } }La siguiente salida de ejemplo (para la configuración anterior) revela que sólo
et-0/1/0.0se le asignó la misma dirección203.0.113.1/24IPv4 y sulinkestado eraup, mientraset-3/0/1.0que no se le asignó la dirección IPv4, aunque sulinkestado estaba activo, lo que significa que solo estará operativo cuando obtenga una dirección IPv4 única distinta de203.0.113.1/24.mostrar interfaces concisas
user@host> show interfaces terse et* Interface Admin Link Proto Local Remote et-0/1/0 up up et-0/1/0.0 up up inet 203.0.113.1/24 multiservice et-0/1/1 up down et-3/0/0 up down et-3/0/1 up up et-3/0/1.0 up up inet multiservice -
Configuración de la misma dirección IPv4 en interfaces P2P (implícitas):
[edit] user@host# show et-0/0/0 { unit 0 { family inet { address 203.0.113.1/24; } } } et-0/0/3 { unit 0 { family inet { address 203.0.113.1/24; } } }La siguiente salida de ejemplo (para la configuración anterior) revela que a ambos
et-0/0/0.0yet-0/0/3.0se les asignó la misma dirección203.0.113.1/24IPv4 y que suslinkestados estaban inactivos. Las interfaces están inactivas debido a un problema con el vínculo y no porque se asigne la misma dirección IPv4 a ambas interfaces. Se espera que no haya más de una interfaz activa en un momento dado (siguiendo un esquema de redundancia fuera del ámbito de los dispositivos Junos OS Evolved), ya que estar ambas activas pueden causar efectos adversos.mostrar interfaces concisas
user@host> show interfaces terse et* Interface Admin Link Proto Local Remote et-0/0/0 up up et-0/0/0.0 up down inet 203.0.113.1/24 et-0/0/1 up up et-0/0/2 up down et-0/0/3 up up et-0/0/3.0 up down inet 203.0.113.1/24 et-1/1/0 up down et-1/1/1 up down et-1/1/2 up up et-1/1/3 up up et-2/0/0 up up et-2/0/1 up up et-2/0/2 up up et-2/0/3 up down
-
Configuración de la misma dirección IPv4 en varias instancias de una interfaz que no sea P2P:
[edit interfaces] user@host# show et-0/0/1 { vlan-tagging; unit 0 { vlan-id 1; family inet { address 10.1.1.1/24; } } unit 1{ vlan-id 2; family inet { address 10.1.1.1/24; } } }En una interfaz que no sea P2P, no se puede configurar la misma dirección local en diferentes unidades de interfaces diferentes. Si lo hace, se producirá un error de confirmación y se producirá un error en la configuración.
-
Configuración de la misma dirección IPv4 en varias instancias de la misma interfaz P2P:
[edit interfaces] user@host# show et-0/0/10 { unit 0 { tunnel { source 10.1.1.1; destination 10.1.1.2; } family inet { mtu 1500; address 10.2.2.2/24; } } unit 1{ family inet { address 10.2.2.2/24; } } }El siguiente resultado de ejemplo (para la configuración anterior) revela que solo una interfaz se configura correctamente en interfaces P2P cuando intenta configurar la misma dirección IPv4 para varias instancias de interfaces diferentes.
mostrar interfaces concisas
user@host> show interfaces terse | match 10.2.2.2 Interface Admin Link Proto Local Remote et-0/0/10.0 up up inet 10.2.2.2/24
Configurar interfaces no numeradas: información general
Descripción general de interfaces no numeradas
Cuando necesite conservar direcciones IP, puede configurar interfaces no numeradas. La configuración de una interfaz no numerada permite el procesamiento de IP en la interfaz sin asignar una dirección IP explícita a la interfaz. Para IP versión 6 (IPv6), en la que conservar las direcciones no es una preocupación importante, puede configurar interfaces no numeradas para compartir la misma subred en varias interfaces.
Las interfaces IPv6 no numeradas solo se admiten en interfaces Ethernet. Las instrucciones que utilice para configurar una interfaz no numerada dependen del tipo de interfaz que esté configurando: una interfaz punto a punto o una interfaz Ethernet:
- Configurar una interfaz punto a punto no numerada
- Configurar una interfaz Ethernet o Demux no numerada
- Configurar una dirección secundaria como dirección de origen preferida para interfaces Ethernet o Demux no numeradas
- Restricciones para configuraciones de interfaz Ethernet no numeradas
- Ejemplo: Mostrar la configuración de interfaz Ethernet no numerada
- Ejemplo: muestra la dirección de origen preferida configurada para una interfaz Ethernet no numerada
- Ejemplo: muestra la configuración de la interfaz Ethernet no numerada como el siguiente salto para una ruta estática
Configurar una interfaz punto a punto no numerada
Para configurar una interfaz punto a punto no numerada:
-
Al configurar interfaces no numeradas, debe asegurarse de que haya una dirección de origen configurada en una interfaz del enrutador. Esta dirección es la dirección predeterminada. Se recomienda hacerlo asignando una dirección a la interfaz de circuito cerrado (
lo0), tal y como se describe en Configuración de la interfaz de circuito cerrado.Cuando se configura una dirección enrutable en la
lo0interfaz, esa dirección es siempre la dirección predeterminada. Esto es ideal porque la interfaz de circuito cerrado es independiente de cualquier interfaz física y, por lo tanto, siempre es accesible.
Configurar una interfaz Ethernet o Demux no numerada
Para configurar una interfaz Ethernet no numerada o de demultiplexación (demux):
-
Actualmente, la
unnumbered-addressinstrucción admite la configuración de interfaces demux no numeradas sólo para la familia de direcciones IP versión 4 (IPv4). Puede configurar interfaces Ethernet no numeradas para las familias de direcciones IPv4 e IPv6. -
La interfaz que configure para que no numere borrows como una dirección IP asignada desde otra interfaz y, por lo tanto, se denomina borrower interface. La interfaz de la que se toma prestada la dirección IP se denomina donor interface. En la
unnumbered-addressinstrucción,interface-nameespecifica la interfaz del donante. Para una interfaz Ethernet no numerada, la interfaz donante puede ser una interfaz Ethernet o de circuito cerrado que tenga un número de unidad lógica y una dirección IP configurada y no sea en sí misma una interfaz no numerada. Para una interfaz demux IP no numerada, la interfaz donante puede ser una interfaz Ethernet o de circuito cerrado que tenga un número de unidad lógica y una dirección IP configurada y no sea en sí misma una interfaz no numerada. Además, para Ethernet o demux, la interfaz donante y la interfaz del prestatario deben ser miembros de la misma instancia de enrutamiento y del mismo sistema lógico. -
Cuando se configura una interfaz Ethernet o demux no numerada, la dirección IP de la interfaz donante se convierte en la dirección de origen en los paquetes generados por la interfaz no numerada.
-
Puede configurar una ruta de host que apunte a una interfaz Ethernet o demux no numerada.
Configurar una dirección secundaria como dirección de origen preferida para interfaces Ethernet o Demux no numeradas
Cuando se configura una interfaz de circuito cerrado con varias direcciones IP secundarias como interfaz donante para una interfaz Ethernet no numerada o de demultiplexación (demux), opcionalmente puede especificar cualquiera de las direcciones secundarias de la interfaz de circuito cerrado como la dirección de origen preferida para la interfaz Ethernet o demux no numerada. Esta función le permite utilizar una dirección IP distinta de la dirección IP principal en algunas de las interfaces Ethernet o demux no numeradas de su red.
Para configurar una dirección secundaria en una interfaz donante de circuito cerrado como dirección de origen preferida para interfaces Ethernet o demux no numeradas:
Las siguientes consideraciones se aplican cuando se configura una dirección de origen preferida en una interfaz Ethernet o demux no numerada:
Actualmente
unnumbered-address, la instrucción admite la configuración de una dirección de origen preferida solo para la familia de direcciones IP versión 4 (IPv4) para interfaces demux y para las familias de direcciones IPv4 e IP versión 6 (IPv6) para interfaces Ethernet.Si no especifica la dirección de origen preferida, el enrutador utiliza la dirección IP principal predeterminada de la interfaz del donante.
No puede eliminar una dirección en una interfaz de circuito cerrado de donante mientras se utiliza como dirección de origen preferida para una interfaz Ethernet o demux no numerada.
Restricciones para configuraciones de interfaz Ethernet no numeradas
Se aplican los siguientes requisitos y restricciones al configurar interfaces Ethernet no numeradas:
Actualmente
unnumbered-address, la instrucción admite la configuración de interfaces Ethernet no numeradas para las familias de direcciones IP versión 4 (IPv4) e IP versión 6 (IPv6).Puede asignar una dirección IP sólo a una interfaz Ethernet que no esté ya configurada como interfaz no numerada.
Debe configurar una o más direcciones IP en la interfaz donante para una interfaz Ethernet no numerada.
No puede configurar la interfaz donante para una interfaz Ethernet no numerada como no numerada.
-
Una interfaz Ethernet no numerada no admite la configuración de las siguientes
addressopciones de instrucción:arp,broadcast,primary,preferred, ovrrp-group. Puede ejecutar el Protocolo de administración de grupos de Internet (IGMP) y el Módulo de interfaz física (PIM) solo en interfaces Ethernet no numeradas que estén directamente orientadas hacia el host y no tengan vecinos PIM descendentes. No puede ejecutar IGMP ni PIM en interfaces Ethernet no numeradas que actúen como interfaces ascendentes en una topología PIM.
Puede ejecutar OSPF sobre interfaces Ethernet no numeradas configuradas como una conexión punto a punto (P2P). Sin embargo, no puede ejecutar OSPF o IS-IS en interfaces Ethernet no numeradas que no están configuradas como P2P.
Para la distribución del estado del vínculo mediante un protocolo de puerta de enlace interior (IGP), asegúrese de que OSPF esté habilitado en la interfaz del donante para una configuración de interfaz no numerada, de modo que la dirección IP del donante sea accesible para establecer sesiones OSPF.
Si configura la misma dirección en varias interfaces en la misma instancia de enrutamiento, el sistema operativo solo utilizará la primera configuración. En este escenario, las configuraciones de direcciones restantes se omiten y pueden dejar interfaces sin dirección. Una interfaz que no tiene una dirección asignada no se puede utilizar como interfaz donante para una interfaz Ethernet no numerada.
Por ejemplo, en la siguiente configuración se ignora la configuración de direcciones de la interfaz et-0/0/1.0:
interfaces {
et-0/0/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
et-0/0/1 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
Ejemplo: Mostrar la configuración de interfaz Ethernet no numerada
Propósito
Para mostrar la interfaz no numerada configurada en el nivel jerárquico [edit interfaces interface-name unit logical-unit-number] :
-
Interfaz no numerada —et-1/0/0
-
Interfaz del donante —et-0/0/0
-
Dirección de interfaz del donante —4.4.4.1/24
La interfaz no numerada "toma prestada" una dirección IP de la interfaz del donante.
Acción
-
Ejecute el
showcomando en el nivel jerárquico[edit].interfaces { et-0/0/0 { unit 0 { family inet { address 4.4.4.1/24; } } } et-1/0/0 { unit 0 { family inet { unnumbered-address et-0/0/0.0; } } } }
Ejemplo: muestra la dirección de origen preferida configurada para una interfaz Ethernet no numerada
Propósito
Para mostrar la configuración de la dirección de origen preferida para una interfaz no numerada en el [edit interfaces interface-name unit logical-unit-number family inet] nivel jerárquico:
-
Interfaz no numerada —et-4/0/0
Interfaz del donante —lo0
Dirección principal de la interfaz del donante: 2.2.2.1/32
Dirección secundaria de la interfaz del donante: 3.3.3.1/32
Acción
-
Ejecute el
showcomando en el nivel jerárquico[edit].interfaces { lo0 { unit 0 { family inet { address 2.2.2.1/32; address 3.3.3.1/32; } } } } interfaces { et-4/0/0 { unit 0 { family inet { unnumbered-address lo0.0 preferred-source-address 3.3.3.1; } } } }
Significado
La interfaz lo0 de circuito cerrado es la interfaz donante de la que una interfaz et-4/0/0 Ethernet no numerada "toma prestada" una dirección IP.
En el ejemplo se muestra una de las direcciones secundarias de la interfaz de circuito cerrado, 3.3.3.1, como la dirección de origen preferida para la interfaz Ethernet no numerada.
Ejemplo: muestra la configuración de la interfaz Ethernet no numerada como el siguiente salto para una ruta estática
Propósito
Para mostrar la interfaz no numerada configurada como el siguiente salto para la ruta estática en el nivel de [edit interfaces interface-name unit logical-unit-number family inet] jerarquía:
-
Interfaz no numerada —et-0/0/0
Interfaz del donante —lo0
Dirección principal de la interfaz del donante: 5.5.5.1/32
Dirección secundaria de la interfaz del donante: 6.6.6.1/32
Ruta estática: 7.7.7.1/32
Acción
-
Ejecute el
showcomando en el nivel jerárquico[edit].interfaces { et-0/0/0 { unit 0 { family inet { unnumbered-address lo0.0; } } } } lo0 { unit 0 { family inet { address 5.5.5.1/32; address 6.6.6.1/32; } } }
-
La siguiente configuración permite al kernel instalar una ruta estática para direccionar 7.7.7.1/32 con un siguiente salto a través de la interfaz no numerada et-0/0/0.0.
static { route 7.7.7.1/32 { qualified-next-hop et-0/0/0.0; } }
Significado
En este ejemplo, et-0/0/0 es la interfaz no numerada. Una interfaz de circuito cerrado, lo0, es la interfaz del donante de la que et-0/0/0 "toma prestada" una dirección IP. En el ejemplo también se configura una ruta estática a 7.7.7.1/32 con un salto siguiente a través de una interfaz et-0/0/0.0no numerada.
Protocolo MTU
Visión general
La MTU de protocolo predeterminada depende del dispositivo y del tipo de interfaz. Cuando se configura inicialmente una interfaz, la MTU de protocolo se calcula automáticamente. Si posteriormente cambia la MTU de medios, la MTU de protocolo en las familias de direcciones existentes cambia automáticamente.
Si reduce el tamaño de MTU de medios pero una o más familias de direcciones ya están configuradas y activas en la interfaz, también debe reducir el tamaño de MTU de protocolo. Si aumenta el tamaño de la MTU de protocolo, debe asegurarse de que el tamaño de la MTU de medios sea igual o mayor que la suma de la MTU de protocolo y la sobrecarga de encapsulación.
Puede configurar el protocolo MTU en todas las interfaces de túnel.
Protocolo MTU para MPLS
Si no configura una MTU MPLS, Junos OS Evolved deriva la MTU MPLS de la MTU de interfaz física. A partir de este valor, el software resta la sobrecarga específica de la encapsulación y el espacio para el número máximo de etiquetas que se pueden insertar en el motor de reenvío de paquetes. El software proporciona tres etiquetas de cuatro bytes cada una, para un total de 12 bytes.
En otras palabras, la fórmula utilizada para determinar la MTU MPLS es la siguiente:
MPLS MTU = physical interface MTU – encapsulation overhead – 12
Deshabilitar la eliminación de bytes de dirección y control
Para algunas interfaces, la dirección y los bytes de control se quitan de forma predeterminada antes de encapsular el paquete en un túnel.
Sin embargo, puede deshabilitar la eliminación de bytes de dirección y control.
Para deshabilitar la eliminación de bytes de dirección y control, incluya la keep-address-and-control instrucción:
keep-address-and-control;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit interfaces interface-name unit logical-unit-number family ccc]
Ver también
Deshabilitar la transmisión de mensajes de redireccionamiento en una interfaz
De forma predeterminada, la interfaz envía mensajes de redireccionamiento de protocolo. Para deshabilitar el envío de estos mensajes en una interfaz, incluya la no-redirects instrucción:
no-redirects
Puede incluir esta instrucción en el siguiente nivel jerárquico:
[edit interfaces interface-name unit logical-unit-number family family]
Para deshabilitar el envío de mensajes de redireccionamiento de protocolo para todo el enrutador o conmutador, incluya la no-redirects instrucción en el [edit system] nivel de jerarquía.
Aplicar un filtro a una interfaz
Definir grupos de interfaces en filtros de firewall
Al aplicar un filtro de firewall, puede definir una interfaz para que forme parte de un grupo de interfaces. Los paquetes recibidos en esa interfaz se etiquetan como parte del grupo. A continuación, puede hacer coincidir estos paquetes mediante la instrucción match interface-group , tal y como se describe en la Guía del usuario de directivas de enrutamiento, filtros de firewall y políticas de tráfico.
Para definir la interfaz que formará parte de un grupo de interfaces, incluya la group instrucción:
group filter-group-number;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit interfaces interface-name unit logical-unit-number family family filter]
El número 0 no es un número de grupo de interfaz válido.
Reenvío basado en filtros en la interfaz de salida
Si los paquetes reflejados por puerto se van a distribuir a varias interfaces de supervisión o recopilación, según los patrones de los encabezados de paquete, resulta útil configurar un filtro de reenvío basado en filtros (FBF) en la interfaz de salida de duplicación de puertos.
Cuando se instala un filtro FBF como filtro de salida, un paquete que se reenvía al filtro ya ha sufrido al menos una búsqueda de ruta. Después de que el filtro FBF clasifica el paquete en la interfaz de salida, se redirige a otra tabla de enrutamiento para realizar búsquedas de ruta adicionales. Para evitar bucles de paquetes dentro del motor de reenvío de paquetes, la búsqueda de ruta en la última tabla de enrutamiento (designada por una instancia de enrutamiento FBF) debe dar como resultado un próximo salto diferente de cualquier salto siguiente especificado en una tabla que ya se haya aplicado al paquete.
Si una interfaz de entrada está configurada para FBF, la búsqueda de origen se deshabilita para aquellos paquetes que se dirigen a una instancia de enrutamiento diferente, ya que la tabla de enrutamiento no está configurada para controlar la búsqueda de origen.
Aplicar un filtro a una interfaz
Para aplicar filtros de firewall a una interfaz, incluya la filter instrucción:
filter {
group filter-group-number;
input filter-name;
input-list [ filter-names ];
output filter-name;
output-list [ filter-names ];
}
Para aplicar un solo filtro, incluya la input instrucción:
filter {
input filter-name;
}
Para aplicar una lista de filtros para evaluar los paquetes recibidos en una interfaz, incluya la input-list instrucción.
filter {
input-list [ filter-names ];
}
Puede incluir hasta 16 nombres de filtro en una lista de entrada.
Para aplicar una lista de filtros para evaluar paquetes transmitidos en una interfaz, incluya la output-list instrucción.
filter {
output-list [ filter-names ];
}
Cuando se aplican filtros mediante la input-list instrucción o la output-list instrucción, se crea un nuevo filtro con el nombre <interface-name>.<unit-direction>. Este filtro es exclusivamente específico de la interfaz.
Puede incluir estas instrucciones en los siguientes niveles jerárquicos:
[edit interfaces interface-name unit logical-unit-number family family]
En la family instrucción, la familia de protocolos puede ser ccc, inet, inet6, mpls, o vpls.
En la group instrucción, especifique el número de grupo de interfaces que desea asociar al filtro.
En la input instrucción, enumere el nombre de un filtro de firewall que se evaluará cuando se reciban paquetes en la interfaz.
En la input-list instrucción, enumere los nombres de los filtros para evaluar cuándo se reciben paquetes en la interfaz. Puede incluir hasta 16 nombres de filtro.
En la output instrucción, enumere el nombre de un filtro de firewall que se evaluará cuando se transmitan paquetes en la interfaz.
Los filtros de firewall de la familia MPLS aplicados en la interfaz de salida no son compatibles con el enrutador PTX10003 debido a limitaciones del producto.
En la output-list instrucción, enumere los nombres de los filtros para evaluar cuándo se transmiten paquetes en la interfaz. Puede incluir hasta 16 nombres de filtro.
Si aplica el filtro a la interfaz lo0, se aplica a los paquetes recibidos o transmitidos por el motor de enrutamiento.
Para obtener más información acerca de los filtros de firewall, consulte la Guía del usuario de directivas de enrutamiento, filtros de firewall y políticas de tráfico. Para obtener más información acerca de los filtros MPLS, consulte la Guía del usuario de aplicaciones MPLS.
Ejemplo: filtro de entrada para tráfico VPLS
[edit interfaces]
et-2/2/3 {
vlan-tagging;
encapsulation vlan-vpls;
unit 601 {
encapsulation vlan-vpls;
vlan-id 601;
family vpls {
filter {
input filter1; # Works for multicast destination MAC address
output filter1; # Does not work for multicast destination MAC address
}
}
}
}
[edit firewall]
family vpls {
filter filter1 {
term 1 {
from {
destination-mac-address {
01:00:0c:cc:cc:cd/48;
}
}
then {
discard;
}
}
term 2 {
then {
accept;
}
}
}
}
Ejemplo: reenvío basado en filtros en la interfaz de salida
En el ejemplo siguiente se muestra la configuración del reenvío basado en filtros en la interfaz de salida. En este ejemplo, el flujo de paquetes sigue esta ruta:
-
Un paquete llega a la interfaz
et-1/2/0.0con las direcciones10.50.200.1de origen y destino y10.50.100.1, respectivamente. -
La búsqueda de ruta en la tabla
inet.0de enrutamiento apunta a la interfazet-0/0/3.0de salida. -
El filtro de salida instalado en
et-0/0/3.0redirige el paquete a la tablafbf.inet.0de enrutamiento. -
El paquete coincide con la entrada
10.50.100.0/25de lafbf.inet.0tabla y el paquete finalmente sale del enrutador desde la interfazet-2/0/0.0.[edit interfaces] et-0/0/3 { unit 0 { family inet { filter { output fbf; } address 10.50.10.2/25; } } } et-1/2/0 { unit 0 { family inet { address 10.50.50.2/25; } } } et-2/0/0 { unit 0 { family inet { address 10.50.20.2/25; } } } [edit firewall] filter fbf { term 0 { from { source-address { 10.50.200.0/25; } } then routing-instance fbf; } term d { then count d; } } [edit routing-instances] fbf { instance-type forwarding; routing-options { static { route 10.50.100.0/25 next-hop et-2/0/0.0; } } } [edit routing-options] interface-routes { rib-group inet fbf-group; } static { route 10.50.100.0/25 next-hop 10.50.10.1; } rib-groups { fbf-group { import-rib [inet.0 fbf.inet.0]; } }
Habilitar el uso de clases de origen y de destino
- Descripción general del uso de clases de origen y clases de destino
- Habilitar el uso de clases de origen y de destino
Descripción general del uso de clases de origen y clases de destino
Para las interfaces que llevan IP versión 4 (IPv4), IP versión 6 (IPv6), MPLS o tráfico de facturación de AS par, puede mantener recuentos de paquetes basados en los puntos de entrada y salida del tráfico que pasa por la red. Los puntos de entrada y salida se identifican mediante prefijos de origen y destino agrupados en conjuntos separados, definidos como clases de origen y clases de destino. Puede definir clases basadas en una variedad de parámetros, como vecinos de enrutamiento, sistemas autónomos y filtros de ruta.
La contabilidad de uso de clase de origen (SCU) cuenta los paquetes enviados a los clientes mediante la realización de búsquedas en la dirección IP de origen. SCU permite rastrear el tráfico que se origina en prefijos específicos en el núcleo del proveedor y se destina a prefijos específicos en el borde del cliente. Debe habilitar la contabilidad de SCU en las interfaces físicas de entrada y salida, y la ruta del origen del paquete debe ubicarse en la tabla de reenvío.
Ni la SCU ni la contabilidad de uso de clase de destino (DCU) funcionan con rutas de interfaz conectadas directamente. El uso de clases de origen no cuenta los paquetes procedentes de orígenes con rutas directas en la tabla de reenvío, debido a limitaciones de la arquitectura de software.
El uso de clase de destino (DCU) cuenta los paquetes de los clientes realizando la búsqueda de la dirección IP de destino. DCU permite rastrear el tráfico que se origina en el borde del cliente y se destina a prefijos específicos en el enrutador central del proveedor.
Se recomienda detener el tráfico de red en una interfaz antes de modificar la configuración de DCU o SCU para esa interfaz. Modificar la configuración de DCU o SCU sin detener el tráfico podría dañar las estadísticas de DCU o SCU. Antes de reiniciar el tráfico después de modificar la configuración, escriba el clear interfaces statistics comando.
La figura 1 ilustra una red de ISP. En esta topología, puede usar DCU para contar los paquetes que los clientes envían a prefijos específicos. Por ejemplo, puede tener tres contadores, uno por cliente, que cuenten los paquetes destinados al prefijo 210.210/16 y 220.220/16.
Puede usar SCU para contar paquetes que el proveedor envía desde prefijos específicos. Por ejemplo, puede contar los paquetes que se envían desde el prefijo 210.210/16 y 215.215/16 que se transmiten en una interfaz de salida específica.
de origen y destino
Puede configurar hasta 126 clases de origen y 126 clases de destino. Para cada interfaz en la que habilite el uso de clases de destino y de clase de origen, el sistema operativo mantiene un contador específico de interfaz para cada clase correspondiente hasta el límite de 126 clases.
Para los paquetes de tránsito que salen del enrutador a través del túnel, las funciones de ruta de reenvío como RPF, filtrado de tabla de reenvío, uso de clases de origen y uso de clases de destino no se admiten en las interfaces que configure como interfaz de salida para el tráfico de túnel. Para el filtrado de firewall, debe permitir que los paquetes de túnel de salida pasen por el filtro de firewall aplicado al tráfico de entrada en la interfaz que es la interfaz del próximo salto hacia el destino del túnel.
La realización de la contabilidad de DCU cuando se habilita un servicio de salida produce un comportamiento incoherente en la siguiente configuración:
-
Tanto la entrada SCU como la DCU se configuran en la interfaz de entrada de paquetes.
-
La salida de SCU se configura en la interfaz de salida de paquetes.
-
Los servicios de interfaz están habilitados en la interfaz de salida.
Para un paquete entrante con prefijos de origen y destino que coincidan con las clases SCU y DCU configuradas en el enrutador, los contadores SCU y DCU se incrementarán. Este comportamiento no es dañino ni negativo. Sin embargo, es incoherente con los paquetes sin servicio, ya que solo se incrementará el recuento de SCU (porque el ID de clase de SCU anulará el ID de clase de DCU en este caso).
Para habilitar el conteo de paquetes en una interfaz, incluya la accounting instrucción:
accounting {
destination-class-usage;
source-class-usage {
direction;
}
}
direction puede ser uno de los siguientes:
-
input: configure al menos un punto de entrada esperado. -
output: configure al menos un punto de salida esperado. -
input output: en una sola interfaz, configure al menos un punto de entrada esperado y un punto de salida esperado.
Puede incluir estas instrucciones en los siguientes niveles jerárquicos:
[edit interfaces interface-name unit logical-unit-number family (inet | inet6 | mpls)]
Para que SCU funcione, debe configurar al menos una interfaz de entrada y al menos una interfaz de salida.
Después de habilitar la contabilidad en una interfaz, el sistema operativo mantiene contadores de paquetes para esa interfaz, con contadores independientes para inetlas familias de protocolos, inet6, mpls A continuación, debe configurar los atributos de clase de origen y clase de destino en las instrucciones de acción de directiva, que deben incluirse en las directivas de exportación de tabla de reenvío.
Al configurar instrucciones de acción de directiva, sólo puede configurar una clase de origen para cada ruta coincidente. En otras palabras, no se puede aplicar más de una clase de origen a la misma ruta.
Puede configurar la contabilidad de SCU para VPN de capa 3 configuradas con la vrf-table-label instrucción. Incluya la source-class-usage instrucción en el [edit routing-instances routing-instance-name vrf-table-label] nivel jerárquico. La source-class-usage instrucción en este nivel de jerarquía solo se admite para el tipo de instancia de enrutamiento y reenvío virtual (VRF).
No puede habilitar contadores DCU en la interfaz de conmutación de etiquetas (LSI) que se crea dinámicamente cuando la vrf-table-label instrucción se configura en un VRF.
Habilitar el uso de clases de origen y de destino
de origen y destino
Antes de poder habilitar el uso de clase de origen (SCU) y el uso de clase de destino (DCU), debe configurar la salida de DCU y SCU en una interfaz:
[edit]
interfaces {
et-6/1/0 {
unit 0 {
family inet {
accounting {
destination-class-usage;
source-class-usage {
output;
}
}
}
}
}
}
Para habilitar el uso de clases de origen y de destino:
Visión general
La difusión dirigida es un proceso de inundación de una subred de destino con paquetes IP de difusión L3 que se originan en una subred diferente. La intención de la difusión dirigida es inundar la subred de destino con los paquetes de difusión en una interfaz LAN sin difundir a toda la red.
La difusión dirigida por IP es una técnica en la que se envía un paquete de difusión a una subred remota específica y, a continuación, se difunde dentro de esa subred. Puede utilizar la difusión dirigida por IP para facilitar la administración remota de la red mediante el envío de paquetes de difusión a hosts de una subred especificada sin difusión a toda la red. Los paquetes de difusión dirigida por IP se difunden únicamente en la subred de destino. El resto de la red trata los paquetes de difusión dirigidos por IP como paquetes de unidifusión y los reenvía en consecuencia.
La difusión dirigida se configura con varias opciones en la interfaz de salida del enrutador o conmutador, y los paquetes IP se difunden únicamente en la interfaz LAN (salida). La difusión dirigida le ayuda a implementar tareas de administración remota, como copias de seguridad y LAN de reactivación (WOL) en una interfaz LAN, y admite instancias de VRF.
Los paquetes IP de difusión L3 normales que se originan en una subred se difunden dentro de la misma subred. Cuando estos paquetes IP llegan a una subred diferente, los paquetes se reenvían al motor de enrutamiento (para reenviarlos a otras aplicaciones). Por lo tanto, las tareas de administración remota, como las copias de seguridad, no se pueden realizar en una subred determinada a través de otra subred. Como solución alternativa, puede habilitar la difusión dirigida para reenviar paquetes de difusión que se originan en una subred diferente.
Los paquetes IP de difusión L3 tienen una dirección IP de destino que es una dirección de difusión válida para la subred de destino. Estos paquetes IP atraviesan la red de la misma manera que los paquetes IP de unidifusión hasta que los paquetes llegan a la subred de destino, como se indica a continuación:
- En la subred de destino, si el enrutador receptor tiene habilitada la difusión de destino en la interfaz de salida, los paquetes IP se reenvían a una interfaz de salida y al motor de enrutamiento, o solo a una interfaz de salida.
- A continuación, los paquetes IP se traducen en paquetes IP de difusión, que inundan la subred de destino sólo a través de la interfaz LAN, y todos los hosts de la subred de destino reciben los paquetes IP. Los paquetes se descartan si no existe ninguna interfaz LAN.
- El paso final de la secuencia depende de la difusión dirigida:
- Si la difusión dirigida no está habilitada en el enrutador receptor, los paquetes IP se tratan como paquetes IP de difusión normales de capa 3 y se reenvían al motor de enrutamiento.
- Si la difusión dirigida está habilitada sin ninguna opción, los paquetes IP se reenvían al motor de enrutamiento.
Puede configurar la difusión dirigida para reenviar los paquetes IP sólo a una interfaz de salida. El reenvío es útil cuando el enrutador está inundado de paquetes para procesar, o tanto a una interfaz de salida como al motor de enrutamiento.
Cualquier filtro de firewall configurado en el motor de enrutamiento lo0 no se puede aplicar a los paquetes IP que se reenvían al motor de enrutamiento como resultado de una difusión de destino. La razón es que los paquetes de difusión se reenvían como tráfico de inundación del próximo salto y no como tráfico local del próximo salto. Puede aplicar un filtro de firewall solo a las rutas locales del próximo salto para el tráfico dirigido hacia el motor de enrutamiento.
- Descripción general de la difusión dirigida
- Implementación de radiodifusión dirigida
- Cuándo habilitar la difusión dirigida
- Cuándo no habilitar la difusión dirigida
Descripción general de la difusión dirigida
Los paquetes de difusión de destino tienen una dirección IP de destino que es una dirección de difusión válida para la subred de destino de la difusión dirigida (la subred de destino). La intención de una difusión dirigida es inundar la subred de destino con los paquetes de difusión sin difundir a toda la red. Los paquetes de difusión de destino no pueden originarse en la subred de destino.
Cuando se envía un paquete de difusión de destino, a medida que viaja a la subred de destino, la red lo reenvía de la misma manera que reenvía un paquete de unidifusión. Cuando el paquete llega a un conmutador que está conectado directamente a la subred de destino, el conmutador comprueba si la difusión dirigida está habilitada en la interfaz que está conectada directamente a la subred de destino:
-
Si la difusión dirigida está habilitada en esa interfaz, el conmutador difunde el paquete en esa subred reescribiendo la dirección IP de destino como la dirección IP de difusión configurada para la subred. El conmutador convierte el paquete en un paquete de difusión de capa de vínculo que procesa cada host de la red.
-
Si la difusión dirigida está deshabilitada en la interfaz que está conectada directamente a la subred de destino, el conmutador descarta el paquete.
Implementación de radiodifusión dirigida
La difusión dirigida se configura por subred habilitando la difusión dirigida en la interfaz L3 de la VLAN de la subred. Cuando el conmutador que está conectado a esa subred recibe un paquete que tiene la dirección IP de difusión de la subred como dirección de destino, el conmutador difunde el paquete a todos los hosts de la subred.
De forma predeterminada, la difusión dirigida está deshabilitada.
Cuándo habilitar la difusión dirigida
La difusión dirigida está deshabilitada de forma predeterminada. Habilite la difusión dirigida cuando desee realizar servicios de administración o administración remotos, como copias de seguridad o tareas WOL en hosts de una subred que no tenga conexión directa a Internet.
La habilitación de la difusión dirigida en una subred solo afecta a los hosts dentro de esa subred. Solo los paquetes recibidos en la interfaz L3 de la subred que tengan la dirección IP de difusión de la subred, ya que la dirección de destino se inunda en la subred.
Cuándo no habilitar la difusión dirigida
Normalmente, no se habilita la difusión dirigida en subredes que tienen conexiones directas a Internet. La desactivación de la difusión dirigida en la interfaz L3 de una subred solo afecta a esa subred. Si deshabilita la difusión dirigida en una subred y un paquete que tiene la dirección IP de difusión de esa subred llega al conmutador, el conmutador descarta el paquete de difusión.
Si una subred tiene una conexión directa a Internet, habilitar la difusión dirigida en ella aumenta la susceptibilidad de la red a los ataques DoS.
Un atacante malintencionado puede suplantar una dirección IP de origen para engañar a una red para que identifique al atacante como legítimo. El atacante puede enviar difusiones dirigidas con paquetes de eco (ping) ICMP. Cuando los hosts de la red con difusión dirigida habilitada reciben los paquetes de eco ICMP, los hosts envían respuestas a la víctima que tiene la dirección IP de origen falsificada. Las respuestas crean una avalancha de respuestas de ping en un ataque DoS que puede abrumar la dirección de origen falsificada conocida como ataque pitufo . Otro ataque DoS común en redes expuestas con difusión dirigida habilitada es un ataque fraggle . El ataque es similar a un ataque pitufo, excepto que el paquete malicioso es un paquete de eco UDP en lugar de un paquete de eco ICMP.
Configurar difusión dirigida
Configurar difusión dirigida
Puede configurar la difusión dirigida en una interfaz de salida con diferentes opciones.
Cualquiera de estas configuraciones es aceptable:
-
Puede permitir que los paquetes de difusión IP destinados a una dirección de capa 3 se reenvíen a través de la interfaz de salida y enviar una copia de los paquetes de difusión IP al motor de enrutamiento.
-
Puede permitir que los paquetes de difusión IP se reenvíen únicamente a través de la interfaz de salida.
Tenga en cuenta que los paquetes se difunden sólo si la interfaz de salida es una interfaz LAN.
Para configurar la difusión dirigida y sus opciones:
Opciones de configuración de difusión dirigida a mostrar
Los siguientes temas de ejemplo muestran las opciones de configuración de difusión dirigida:
- Reenviar paquetes de difusión IP en la interfaz de salida y al motor de enrutamiento
- Reenviar paquetes de difusión IP solo en la interfaz de salida
Reenviar paquetes de difusión IP en la interfaz de salida y al motor de enrutamiento
Propósito
Mostrar la configuración cuando se configura la difusión de destino en la interfaz de salida para reenviar los paquetes de difusión IP en la interfaz de salida y para enviar una copia de los mismos paquetes al motor de enrutamiento.
Acción
[edit interfaces interface-name unit interface-unit-number family inet]
user@host#show
targeted-broadcast {
forward-and-send-to-re;
}
Para mostrar la configuración de irb, ejecute el comando en el show [edit interfaces irb unit interface-unit-number family inet].
[edit interfaces irb unit interface-unit-number family inet]
user@host#show
targeted-broadcast {
forward-and-send-to-re;
}
Reenviar paquetes de difusión IP solo en la interfaz de salida
Propósito
Muestre la configuración cuando se configura la difusión de destino en la interfaz de salida para reenviar los paquetes de difusión IP solo en la interfaz de salida.
Acción
[edit interfaces interface-name unit interface-unit-number family inet]
user@host#show
targeted-broadcast {
forward-only;
}
Para mostrar la configuración, ejecute el comando en el show [edit interfaces irb unit interface-unit-number family inet].
[edit interfaces irb unit interface-unit-number family inet]
user@host#show
targeted-broadcast {
forward-only;
}