Descripción de RPF de unidifusión (enrutadores)
En el caso de las interfaces que transportan tráfico IPv4 o IPv6, puede reducir el impacto de los ataques de denegación de servicio (DoS) configurando el reenvío de ruta inversa (RPF) de unidifusión. RPF de unidifusión ayuda a determinar el origen de los ataques y rechaza paquetes de direcciones de origen inesperadas en interfaces donde RPF de unidifusión está habilitado.
-
Puede proteger una red aplicando la función de verificación RPF de unidifusión en el borde (en interfaces orientadas al cliente) de la red. En un entorno de ISP, esto puede afectar a la red, lo que puede imponer una configuración a escala. En caso de que ya haya protegido el borde de su red, un paquete con una dirección IP de origen falsificada ni siquiera aparecerá en una interfaz de núcleo frente a. En este caso, no es necesario comprobar RPF de unidifusión. Habilitar la función RPF de unidifusión puede afectar el rendimiento del plano de control, así que úselo donde sea necesario. Por lo tanto, se recomienda no habilitar esta función en las interfaces de núcleo (internas) de red.
Actualmente, en las plataformas PTX, la configuración de la especificación de flujo del BGP (flowspec) crea un filtro implícito para establecer la instancia de VRF. En las plataformas PTX, la búsqueda de filtro precede a la búsqueda de IP de origen/destino. Por lo tanto, la búsqueda de IP de origen y destino se realiza en el contexto de la instancia vrf.
RPF de unidifusión y ruta predeterminada
Cuando la ruta activa no se puede elegir entre las rutas de una tabla de enrutamiento, el enrutador elige una ruta predeterminada. Una ruta predeterminada es equivalente a una dirección IP de 0.0.0.0/0. Si configura una ruta predeterminada y configura RPF de unidifusión en una interfaz que usa la ruta predeterminada, el RPF de unidifusión se comporta de manera diferente a como lo hace de otro modo.
Para determinar si la ruta predeterminada usa una interfaz, escriba el show route comando:
user@host> show route address
address es la dirección del salto siguiente de la ruta predeterminada configurada. La ruta predeterminada usa las interfaces que se muestran en la salida del show route comando.
En las siguientes secciones se describe cómo se comporta la RPF de unidifusión cuando una ruta predeterminada usa una interfaz y cuando una ruta predeterminada no usa una interfaz:
- Comportamiento de RPF de unidifusión con una ruta predeterminada
- Comportamiento de RPF de unidifusión sin una ruta predeterminada
- RPF de unidifusión con asimetría de enrutamiento
Comportamiento de RPF de unidifusión con una ruta predeterminada
En todos los enrutadores, excepto los que tienen MPC y el enrutador MX80, el RPF de unidifusión se comporta de la siguiente manera si configura una ruta predeterminada que usa una interfaz configurada con RPF de unidifusión:
Modo flexible: todos los paquetes se aceptan automáticamente. Por esta razón, recomendamos que no configure el modo suelto de RPF de unidifusión en las interfaces que usa la ruta predeterminada.
Modo estricto: el paquete se acepta cuando la dirección de origen del paquete coincide con cualquiera de las rutas (predeterminadas o aprendidas) que se pueden acceder a través de la interfaz. Tenga en cuenta que las rutas pueden tener varios destinos asociados con ellas; por lo tanto, si uno de los destinos coincide con la interfaz de entrada del paquete, se acepta el paquete.
En todos los enrutadores con MPC y el enrutador MX80, la RPF de unidifusión se comporta de la siguiente manera si configura una ruta predeterminada que usa una interfaz configurada con RPF de unidifusión:
Modo flexible: se aceptan todos los paquetes, excepto los paquetes cuyo origen se aprende de la ruta predeterminada. Todos los paquetes cuyo origen se aprende de la ruta predeterminada se pierden en el motor de reenvío de paquetes. La ruta predeterminada se trata como si la ruta no existiera.
Modo estricto: el paquete se acepta cuando la dirección de origen del paquete coincide con cualquiera de las rutas (predeterminadas o aprendidas) que se pueden acceder a través de la interfaz. Tenga en cuenta que las rutas pueden tener varios destinos asociados con ellas; por lo tanto, si uno de los destinos coincide con la interfaz de entrada del paquete, se acepta el paquete.
En todos los enrutadores, el paquete no se acepta cuando se cumple cualquiera de los siguientes aspectos:
La dirección de origen del paquete no coincide con un prefijo de la tabla de enrutamiento.
La interfaz no espera recibir un paquete con este prefijo de dirección de origen.
Comportamiento de RPF de unidifusión sin una ruta predeterminada
Si no configura una ruta predeterminada o si la ruta predeterminada no usa una interfaz configurada con RPF de unidifusión, el RPF de unidifusión se comporta como se describe en Configuración del modo estricto de RPF de unidifusión y Configuración del modo suelto de RPF de unidifusión. En resumen, el RPF de unidifusión sin una ruta predeterminada se comporta de la siguiente manera:
Modo estricto: no se acepta el paquete cuando se cumple alguna de las siguientes condiciones:
El paquete tiene una dirección de origen que no coincide con un prefijo de la tabla de enrutamiento.
La interfaz no espera recibir un paquete con este prefijo de dirección de origen.
Modo suelto: no se acepta el paquete cuando el paquete tiene una dirección de origen que no coincide con un prefijo en la tabla de enrutamiento.
RPF de unidifusión con asimetría de enrutamiento
En general, recomendamos no habilitar RPF de unidifusión en interfaces internas de la red, ya que es probable que las interfaces internas tengan asimetría de enrutamiento. La asimetría de enrutamiento significa que las rutas de salida y devolución de un paquete son diferentes. Es más probable que los enrutadores en el núcleo de la red tengan rutas inversas asimétricas que los enrutadores en el borde del cliente o del proveedor. La Figura 1 muestra RPF de unidifusión en un entorno con asimetría de enrutamiento.
enrutamiento
En la figura 1, si habilita RPF de unidifusión en la interfaz so-0/0/0, el tráfico destinado al enrutador A no se rechaza. Si habilita RPF de unidifusión en la interfaz so-1/0/1, el tráfico del enrutador A se rechaza.
Si necesita habilitar RPF de unidifusión en un entorno de enrutamiento asimétrico, puede usar filtros de error para permitir que el enrutador acepte paquetes entrantes que se sabe que llegan por rutas específicas. Para obtener un ejemplo de un filtro de error que acepta paquetes con una dirección de origen y destino específica, consulte Configurar RPF de unidifusión.
Configuración del modo estricto de RPF de unidifusión
En modo estricto, RPF de unidifusión comprueba si el paquete entrante tiene una dirección de origen que coincide con un prefijo en la tabla de enrutamiento y si la interfaz espera recibir un paquete con este prefijo de dirección de origen.
Si el paquete entrante falla la comprobación de RPF de unidifusión, el paquete no se acepta en la interfaz. Cuando no se acepta un paquete en una interfaz, RPF de unidifusión cuenta el paquete y lo envía a un filtro de error opcional. Si el filtro de error no está configurado, la acción predeterminada es descartar el paquete de forma silenciosa.
El filtro de error opcional le permite aplicar un filtro a los paquetes que fallan la comprobación de RPF de unidifusión. Puede definir el filtro de error para realizar cualquier operación de filtro, incluyendo la aceptación, el rechazo, el registro, la toma de muestras o la vigilancia.
Cuando se habilita RPF de unidifusión en una interfaz, no se aceptan paquetes de protocolo de arranque (BOOTP) y protocolo de configuración dinámica de host (DHCP) en la interfaz. Para permitir que la interfaz acepte paquetes BOOTP y paquetes DHCP, debe aplicar un filtro de error que acepte todos los paquetes con una dirección de origen y una dirección de destino Para un ejemplo de 0.0.0.0 255.255.255.255. configuración, consulte Configurar RPF de unidifusión.
Para obtener más información acerca de cómo definir filtros de error, consulte la Guía del usuario de políticas de enrutamiento, filtros de firewall y policías de tráfico.
Para configurar RPF de unidifusión, incluya la rpf-check instrucción:
rpf-check <fail-filter filter-name>;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit interfaces interface-name unit logical-unit-number family (inet | inet6)][edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6)]
Cuando se implementa con filtros de tráfico, el uso de RPF de unidifusión puede tener varias consecuencias:
Los filtros de error de RPF se evalúan después de los filtros de entrada y antes de los filtros de salida.
Si configura un contador de filtros para los paquetes caídos por un filtro de entrada y desea saber el número total de paquetes caídos, también debe configurar un contador de filtro para los paquetes caídos por la comprobación RPF.
Para contar paquetes que fallan en la comprobación RPF y son aceptados por el filtro de error de RPF, debe configurar un contador de filtro.
Si un filtro de entrada reenvía paquetes en cualquier lugar que no sea las tablas de enrutamiento inet.0 o inet6.0, no se realiza la comprobación RPF de unidifusión.
Si un filtro de entrada reenvía paquetes en cualquier lugar que no sea la instancia de enrutamiento para la que está configurada la interfaz de entrada, no se realiza la comprobación RPF de unidifusión.
En enrutadores serie ACX y MX:
- El filtro de error de uRPF no puede coincidir con los paquetes fallidos en la comprobación del puerto de entrada (modo estricto).
- El filtro de error uRPF puede coincidir con paquetes que fallan en la búsqueda de IP de origen, pero no puede coincidir con paquetes que fallan en la comprobación de interfaz de entrada (modo estricto).
- El filtro de error uRPF solo se aplica a instancias específicas de interfaz del filtro de firewall.
- Los filtros de error de uRPF no admiten acciones de instancia de rechazo ni enrutamiento.
Configure el modo estricto de unidifusión RPF y aplique un filtro de error que permita a la interfaz aceptar paquetes BOOTP y DHCP. El filtro acepta todos los paquetes con una dirección de origen y una dirección de 0.0.0.0 destino de 255.255.255.255.
Para configurar RPF de unidifusión en modo estricto:
Configuración del modo flexible de RPF de unidifusión
De forma predeterminada, la RPF de unidifusión usa el modo estricto. El modo suelto de RPF de unidifusión es similar al modo estricto de RPF de unidifusión y tiene las mismas restricciones de configuración. El único modo de comprobación libre es si el paquete tiene una dirección de origen con un prefijo correspondiente en la tabla de enrutamiento; el modo libre no comprueba si la interfaz espera recibir un paquete con un prefijo de dirección de origen específico. Si no se encuentra el prefijo correspondiente, el modo suelto de RPF de unidifusión no acepta el paquete. Como en el modo estricto, el modo libre cuenta el paquete fallido y opcionalmente lo reenvía a un filtro de error, que acepta, rechaza, registra, muestras o lo ordena.
Para configurar el modo suelto de RPF de unidifusión, incluya:mode
Configuración del modo flexible RPF de unidifusión con capacidad de descartar paquetes
El modo suelto RPF de unidifusión tiene la capacidad de descartar paquetes con la dirección de origen apuntando a la interfaz de descarte. El uso del modo suelto RPF de unidifusión, junto con el filtrado de ruta nula activado remotamente, proporciona una forma eficiente de descartar paquetes procedentes de fuentes de ataque conocidas. Las políticas de BGP en los enrutadores de borde garantizan que los paquetes con direcciones de origen no confiables tengan su próximo salto establecido en una ruta de descarte. Cuando un paquete llega al enrutador con una dirección de origen que no es de confianza, RPF de unidifusión realiza una búsqueda de ruta de la dirección de origen. Dado que la ruta de dirección de origen apunta a un siguiente salto de descarte, el paquete se cae y se incrementa un contador. Esta característica se admite en familias de direcciones IPv4 (inet) e IPv6 (inet6).
Para configurar el modo suelto de RPF de unidifusión con la capacidad de descartar paquetes, incluya la rpf-loose-mode-discard family (inet | inet6) instrucción en el [edit forwarding-options] nivel de jerarquía:
rpf-loose-mode-discard {
family {
inet;
}
}
En este ejemplo, no se requiere ninguna configuración especial más allá de la inicialización del dispositivo.
Configure el modo suelto de RPF de unidifusión y aplique un filtro de error que permita que la interfaz acepte paquetes BOOTP y DHCP. El filtro acepta todos los paquetes con una dirección de origen y una dirección de 0.0.0.0 destino de 255.255.255.255.
Para configurar el modo suelto de RPF de unidifusión con la capacidad de descartar paquetes:
Configuración de RPF de unidifusión en una VPN
Puede configurar RPF de unidifusión en una interfaz VPN habilitando RPF de unidifusión en la interfaz e incluyendo la interface instrucción en el [edit routing-instances routing-instance-name] nivel de jerarquía.
Puede configurar RPF de unidifusión solo en las interfaces que especifique en la instancia de enrutamiento. Esto significa lo siguiente:
-
Para VPN de capa 3, RPF de unidifusión se admite en la interfaz del enrutador CE.
-
RPF de unidifusión no se admite en interfaces orientadas al núcleo.
-
Para las instancias de enrutamiento de enrutador virtual, RPF de unidifusión se admite en todas las interfaces especificadas en la instancia de enrutamiento.
-
Si un filtro de entrada reenvía paquetes en cualquier lugar que no sea la instancia de enrutamiento para la que está configurada la interfaz de entrada, no se realiza la comprobación RPF de unidifusión.
Configure RPF de unidifusión en una interfaz VPN de capa 3:
[edit interfaces]
so-0/0/0 {
unit 0 {
family inet {
rpf-check;
}
}
}
[edit routing-instance]
VPN-A {
interface so-0/0/0.0;
}
Configuración de RPF de unidifusión
Configure el modo estricto de unidifusión RPF y aplique un filtro de error que permita a la interfaz aceptar paquetes BOOTP y DHCP. El filtro acepta todos los paquetes con una dirección de origen y una dirección de 0.0.0.0 destino de 255.255.255.255.
[edit firewall]
filter rpf-special-case-dhcp-bootp {
term allow-dhcp-bootp {
from {
source-address {
0.0.0.0/32;
}
address {
255.255.255.255/32;
}
}
then {
count rpf-dhcp-bootp-traffic;
accept;
}
}
term default {
then {
log;
reject;
}
}
}
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp-bootp;
}
}
}
}