Comprobación de reenvío de ruta inversa de unidifusión para VPN
Descripción de RPF (conmutadores) de unidifusión
Para protegerse de la suplantación de IP y de algunos tipos de ataques de denegación de servicio (DoS) y denegación de servicio distribuido (DDoS), el reenvío de ruta inversa (RPF) de unidifusión verifica que los paquetes lleguen de una ruta legítima. Para ello, comprueba la dirección de origen de cada paquete que llega a una interfaz de entrada no confiable y lo compara con la entrada de tabla de reenvío para su dirección de origen. Si el paquete proviene de una ruta válida, es decir, una que el remitente usaría para llegar al destino, el dispositivo reenvía el paquete a la dirección de destino. Si no es desde una ruta válida, el dispositivo descarta el paquete. A menos que esté protegida, la suplantación de IP puede ser una forma eficaz para que los intrusos pasen paquetes IP a un destino como tráfico genuino, cuando de hecho los paquetes no están realmente destinados al destino.
RPF de unidifusión es compatible con las familias de protocolos IPv4 e IPv6, así como para la familia de direcciones de red privada virtual (VPN). RPF de unidifusión no se admite en interfaces configuradas como fuentes de túnel. Esto solo afecta a los paquetes de tránsito que salen del túnel.
Hay dos modos de RPF de unidifusión, modo estricto y modo flexible. El valor predeterminado es el modo estricto, lo que significa que el conmutador reenvía un paquete solo si la interfaz de recepción es la mejor ruta de retorno a la dirección de origen de unidifusión del paquete. El modo estricto es especialmente útil en interfaces que no son de confianza (en las que usuarios o procesos no confiables pueden colocar paquetes en el segmento de red) y en interfaces simétricamente enrutadas (consulte Cuándo habilitar RPF de unidifusión). Para obtener más información acerca de RPF de unidifusión estricta, consulte RFC 3704, Filtrado de entrada para redes multihome en http://www.ietf.org/rfc/rfc3704.txt.
Para habilitar RPF de unidifusión en modo estricto en una interfaz seleccionada de cliente-borde:
[editar interfaces] user@switch # set interface-name unit 0 family inet rpf-check
El otro modo es el modo libre, lo que significa que el sistema comprueba si el paquete tiene una dirección de origen con el prefijo correspondiente en la tabla de enrutamiento, pero no comprueba si la interfaz receptora es la mejor ruta de retorno a la dirección de origen de unidifusión del paquete.
Para habilitar el modo suelto de RPF de unidifusión, ingrese:
[editar interfaces] user@switch # set interface-name unit 0 family inet rpf-check mode loose
- Descripción general de RPF de unidifusión para conmutadores
- Implementación de RPF de unidifusión
- Cuándo habilitar RPF de unidifusión
- Cuándo no habilitar RPF de unidifusión
- Limitaciones de la implementación de RPF de unidifusión en conmutadores EX3200, EX4200 y EX4300
Descripción general de RPF de unidifusión para conmutadores
RPF de unidifusión funciona como un filtro de entrada que reduce el reenvío de paquetes IP que podrían estar suplantando una dirección. De forma predeterminada, la RPF de unidifusión está deshabilitada en las interfaces del conmutador. El conmutador solo admite el método de rutas activas para determinar la mejor ruta de retorno de vuelta a una dirección de origen de unidifusión. El método de rutas activas busca la mejor entrada de ruta inversa en la tabla de reenvío. No considera las rutas alternativas especificadas mediante métodos específicos de protocolo de enrutamiento al determinar la mejor ruta de retorno.
Si la tabla de reenvío enumera la interfaz de recepción como la interfaz que se utilizará para reenviar el paquete a su origen de unidifusión, es la mejor interfaz de ruta de devolución.
Implementación de RPF de unidifusión
- Filtrado de paquetes RPF de unidifusión
- Solicitudes dhcp y protocolo de arranque (BOOTP)
- Gestión de rutas predeterminada
Filtrado de paquetes RPF de unidifusión
Cuando habilita RPF de unidifusión en el conmutador, el conmutador controla el tráfico de la siguiente manera:
Si el conmutador recibe un paquete en la interfaz que sea la mejor ruta de retorno a la dirección de origen de unidifusión de ese paquete, el conmutador reenvía el paquete.
Si la mejor ruta de retorno del conmutador a la dirección de origen de unidifusión del paquete no es la interfaz receptora, el conmutador descarta el paquete.
Si el conmutador recibe un paquete que tiene una dirección IP de origen que no tiene una entrada de enrutamiento en la tabla de reenvío, el conmutador descarta el paquete.
Solicitudes dhcp y protocolo de arranque (BOOTP)
El protocolo de arranque (BOOTP) y los paquetes de solicitud DHCP se envían con una dirección MAC de difusión y, por lo tanto, el conmutador no realiza comprobaciones de RPF de unidifusión en ellos. El conmutador reenvía todos los paquetes BOOTP y los paquetes de solicitud DHCP sin realizar comprobaciones de RPF de unidifusión.
Gestión de rutas predeterminada
Si la mejor ruta de retorno al origen es la ruta predeterminada (0.0.0.0) y la ruta predeterminada apunta a reject, el conmutador descarta los paquetes. Si la ruta predeterminada apunta a una interfaz de red válida, el conmutador realiza una comprobación de RPF de unidifusión normal en los paquetes.
En el EX4300, la ruta predeterminada no se usa cuando el conmutador está configurado en modo estricto RPF de unidifusión.
Cuándo habilitar RPF de unidifusión
Habilite la RPF de unidifusión cuando desee asegurarse de que el tráfico que llega a una interfaz de red proviene de una fuente que reside en una red a la que puede llegar la interfaz. Puede habilitar RPF de unidifusión en interfaces que no son de confianza para filtrar paquetes falsificados. Por ejemplo, una aplicación común para RPF de unidifusión es ayudar a defender una red empresarial de ataques DoS/DDoS procedentes de Internet.
Habilite la RPF de unidifusión solo en interfaces enrutadas simétricamente, y lo más cerca posible del origen de tráfico detiene el tráfico suplantado antes de que pueda proliferar o alcanzar interfaces que no tengan habilitado RPF de unidifusión. Dado que la RPF de unidifusión se habilita globalmente en conmutadores EX3200, EX4200 y EX4300, asegúrese de que todas las interfaces se enrutan simétricamente antes de habilitar la RPF de unidifusión en estos conmutadores, como se muestra en la figura 1. La habilitación de RPF de unidifusión en interfaces enrutadas asimétricamente da como resultado paquetes de fuentes legítimas que se filtran. Una interfaz enrutada simétricamente usa la misma ruta en ambas direcciones entre el origen y el destino.
RPF de unidifusión está habilitado globalmente en conmutadores EX3200, EX4200 y EX4300, para con estos dispositivos, asegúrese de que todas las interfaces se enrutan simétricamente antes de habilitar RPF de unidifusión en estos conmutadores. La habilitación de RPF de unidifusión en interfaces enrutadas asimétricamente da como resultado paquetes de fuentes legítimas que se filtran.
enrutadas simétricamente
Es muy probable que las siguientes interfaces de conmutación se enrutan simétricamente y, por lo tanto, sean candidatas para habilitar RPF de unidifusión:
El borde del operador de telecomunicaciones a un cliente
El borde del cliente a un proveedor de servicios
Un único punto de acceso fuera de la red (generalmente en el perímetro de la red)
Una red de terminales que tenga un solo vínculo
En los conmutadores EX3200, EX4200 y EX4300, se recomienda habilitar explícitamente RPF de unidifusión en todas las interfaces o solo en una. Para evitar posibles confusiones, no lo habilite solo en algunas interfaces:
Habilitar RPF de unidifusión explícitamente en una sola interfaz facilita si elige deshabilitarlo en el futuro, ya que debe deshabilitar explícitamente RPF de unidifusión en cada interfaz en la que lo habilitó explícitamente. Si habilita explícitamente RPF de unidifusión en dos interfaces y lo deshabilita en solo una interfaz, la RPF de unidifusión sigue estando implícitamente habilitada globalmente en el conmutador. El inconveniente de este enfoque es que el conmutador muestra la marca que indica que la RPF de unidifusión solo está habilitada en interfaces en las que RPF de unidifusión está explícitamente habilitado, por lo que aunque la RPF de unidifusión esté habilitada en todas las interfaces, este estado no se muestra.
Habilitar RPF de unidifusión explícitamente en todas las interfaces facilita saber si RPF de unidifusión está habilitado en el conmutador, ya que cada interfaz muestra el estado correcto. (Solo las interfaces en las que habilite explícitamente RPF de unidifusión muestran la marca que indica que RPF de unidifusión está habilitada.) El inconveniente de este enfoque es que si desea deshabilitar RPF de unidifusión, debe deshabilitarlo explícitamente en cada interfaz. Si la RPF de unidifusión está habilitada en cualquier interfaz, se habilita implícitamente en todas las interfaces.
Cuándo no habilitar RPF de unidifusión
Por lo general, no habilitará RPF de unidifusión si:
Las interfaces de conmutación son multiconexión.
Las interfaces de conmutación son interfaces de confianza.
El BGP lleva prefijos y algunos de esos prefijos no se anuncian o no son aceptados por el ISP según su política. (El efecto en este caso es el mismo que el filtrado de una interfaz mediante una lista de acceso incompleta.)
Las interfaces de conmutación se enfrentan al núcleo de la red. Las interfaces orientadas al núcleo suelen enrutar de forma asimétrica.
Una interfaz enrutada asimétricamente utiliza diferentes rutas para enviar y recibir paquetes entre el origen y el destino, como se muestra en la figura 2. Esto significa que si una interfaz recibe un paquete, esa interfaz no coincide con la entrada de la tabla de reenvío como la mejor ruta de retorno de vuelta al origen. Si la interfaz de recepción no es la mejor ruta de retorno al origen de un paquete, RPF de unidifusión hace que el conmutador descarte el paquete aunque provenga de un origen válido.
enrutadas asimétricamente
No habilite la RPF de unidifusión en conmutadores EX3200, EX4200 y EX4300 si se enrutan las interfaces de conmutador de forma asimétrica, ya que la RPF de unidifusión está habilitada globalmente en todas las interfaces de estos conmutadores. Todas las interfaces del conmutador deben enrutarse simétricamente para que pueda habilitar RPF de unidifusión sin el riesgo de que el conmutador descarte el tráfico que desea reenviar.
Limitaciones de la implementación de RPF de unidifusión en conmutadores EX3200, EX4200 y EX4300
En los conmutadores EX3200, EX4200 y EX4300, el conmutador implementa RPF de unidifusión a nivel global. No puede habilitar RPF de unidifusión por interfaz. El RPF de unidifusión está deshabilitado globalmente de forma predeterminada.
Cuando habilita RPF de unidifusión en cualquier interfaz, se habilita automáticamente en todas las interfaces de conmutación, incluidos los grupos de agregación de vínculos (LAG), las interfaces de enrutamiento y puente integrados (IRB) y las interfaces VLAN enrutadas (RVI).
Cuando deshabilita RPF de unidifusión en la interfaz (o interfaces) en la que habilitó RPF de unidifusión, se deshabilita automáticamente en todas las interfaces de conmutador.
Debe deshabilitar explícitamente la RPF de unidifusión en todas las interfaces en las que se habilitó explícitamente o la RPF de unidifusión permanece habilitada en todas las interfaces de conmutador.
Los conmutadores QFX, OCX y EX3200 y EX4200 no realizan filtrado RPF de unidifusión en tráfico de multiruta (ECMP) de igual costo. La comprobación de RPF de unidifusión examina solo una mejor ruta de retorno al origen del paquete, pero el tráfico ECMP emplea un bloque de direcciones que consta de varias rutas. El uso de RPF de unidifusión para filtrar el tráfico ECMP en estos conmutadores puede dar como resultado que el conmutador descarte los paquetes que desea reenviar, ya que el filtro RPF de unidifusión no examina todo el bloque de direcciones ECMP.
Ver también
Ejemplo: Configuración de RPF de unidifusión (en un enrutador)
En este ejemplo, se muestra cómo proteger las interfaces de entrada contra ataques de denegación de servicio (DoS) y denegación de servicio distribuido (DDoS) mediante la configuración de RPF de unidifusión en una interfaz de borde del cliente para filtrar el tráfico entrante.
Requisitos
No se requiere ninguna configuración especial más allá de la inicialización del dispositivo.
Visión general
En este ejemplo, el dispositivo A usa OSPF para anunciar un prefijo para el vínculo que se conecta al dispositivo D. El dispositivo B tiene RPF de unidifusión configurado. El OSPF está habilitado en los vínculos entre el dispositivo B y el dispositivo C y los vínculos entre el dispositivo A y el dispositivo C, pero no en los vínculos entre el dispositivo A y el dispositivo B. Por lo tanto, el dispositivo B aprende acerca de la ruta al dispositivo D al dispositivo C.
Si se utiliza el filtrado de entrada en un entorno en el que se utiliza DHCP o BOOTP, debe asegurarse de que los paquetes con una dirección de origen de 0.0.0.0 y una dirección de destino de 255.255.255.255 pueden llegar al agente de retransmisión en los enrutadores cuando sea necesario.
En este ejemplo también se incluye un filtro de error. Cuando un paquete falla en la comprobación de RPF de unidifusión, el filtro de error se evalúa para determinar si el paquete debe aceptarse de todos modos. El filtro de error de este ejemplo permite que las interfaces del dispositivo B acepten paquetes del Protocolo de configuración dinámica de host (DHCP). El filtro acepta todos los paquetes con una dirección de origen de 0.0.0.0 y una dirección de destino de 255.255.255.255.
Topología
La figura 3 muestra la red de ejemplo.
Configuración
- Configuración rápida de CLI
- Configuración del dispositivo A
- Configuración del dispositivo B
- Resultados
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.
Dispositivo A
set interfaces fe-1/2/0 unit 1 family inet address 10.0.0.1/30 set interfaces fe-0/0/2 unit 5 family inet address 10.0.0.5/30 set interfaces fe-0/0/1 unit 17 family inet address 10.0.0.17/30 set interfaces fe-0/1/1 unit 25 family inet address 10.0.0.25/30 set interfaces fe-1/1/1 unit 29 family inet address 10.0.0.29/30 set protocols ospf export send-direct set protocols ospf area 0.0.0.0 interface fe-0/1/1.25 set protocols ospf area 0.0.0.0 interface fe-1/1/1.29 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct from route-filter 10.0.0.16/30 exact set policy-options policy-statement send-direct then accept
Dispositivo B
set interfaces fe-1/2/0 unit 2 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-1/2/0 unit 2 family inet address 10.0.0.2/30 set interfaces fe-1/1/1 unit 6 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-1/1/1 unit 6 family inet address 10.0.0.6/30 set interfaces fe-0/1/1 unit 9 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-0/1/1 unit 9 family inet address 10.0.0.9/30 set interfaces fe-0/1/0 unit 13 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-0/1/0 unit 13 family inet address 10.0.0.13/30 set protocols ospf area 0.0.0.0 interface fe-0/1/1.9 set protocols ospf area 0.0.0.0 interface fe-0/1/0.13 set routing-options forwarding-table unicast-reverse-path active-paths set firewall filter rpf-special-case-dhcp term allow-dhcp from source-address 0.0.0.0/32 set firewall filter rpf-special-case-dhcp term allow-dhcp from destination-address 255.255.255.255/32 set firewall filter rpf-special-case-dhcp term allow-dhcp then count rpf-dhcp-traffic set firewall filter rpf-special-case-dhcp term allow-dhcp then accept set firewall filter rpf-special-case-dhcp term default then log set firewall filter rpf-special-case-dhcp term default then reject
Dispositivo C
set interfaces fe-1/2/0 unit 10 family inet address 10.0.0.10/30 set interfaces fe-0/0/2 unit 14 family inet address 10.0.0.14/30 set interfaces fe-1/0/2 unit 21 family inet address 10.0.0.21/30 set interfaces fe-1/2/2 unit 26 family inet address 10.0.0.26/30 set interfaces fe-1/2/1 unit 30 family inet address 10.0.0.30/30 set protocols ospf area 0.0.0.0 interface fe-1/2/0.10 set protocols ospf area 0.0.0.0 interface fe-0/0/2.14 set protocols ospf area 0.0.0.0 interface fe-1/2/2.26 set protocols ospf area 0.0.0.0 interface fe-1/2/1.30
Dispositivo D
set interfaces fe-1/2/0 unit 18 family inet address 10.0.0.18/30
Dispositivo E
set interfaces fe-1/2/0 unit 22 family inet address 10.0.0.22/30
Configuración del dispositivo A
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.
Para configurar el dispositivo A:
Configure las interfaces.
[edit interfaces] user@A# set fe-1/2/0 unit 1 family inet address 10.0.0.1/30 user@A# set fe-0/0/2 unit 5 family inet address 10.0.0.5/30 user@A# set fe-0/0/1 unit 17 family inet address 10.0.0.17/30 user@A# set fe-0/1/1 unit 25 family inet address 10.0.0.25/30 user@A# set fe-1/1/1 unit 29 family inet address 10.0.0.29/30
Configure OSPF.
[edit protocols ospf] user@A# set export send-direct user@A# set area 0.0.0.0 interface fe-0/1/1.25 user@A# set area 0.0.0.0 interface fe-1/1/1.29
Configure la política de enrutamiento.
[edit policy-options policy-statement send-direct] user@A# set from protocol direct user@A# set from route-filter 10.0.0.16/30 exact user@A# set then accept
Si ha terminado de configurar el dispositivo A, confirme la configuración.
[edit] user@A# commit
Configuración del dispositivo B
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.
Para configurar el dispositivo B:
Configure las interfaces.
[edit interfaces] user@B# set fe-1/2/0 unit 2 family inet address 10.0.0.2/30 user@B# set fe-1/1/1 unit 6 family inet address 10.0.0.6/30 user@B# set fe-0/1/1 unit 9 family inet address 10.0.0.9/30 user@B# set fe-0/1/0 unit 13 family inet address 10.0.0.13/30
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@B# set interface fe-0/1/1.9 user@B# set interface fe-0/1/0.13
Configure RPF de unidifusión y aplique el filtro de error opcional.
[edit interfaces] user@B# set fe-1/2/0 unit 2 family inet rpf-check fail-filter rpf-special-case-dhcp user@B# set fe-1/1/1 unit 6 family inet rpf-check fail-filter rpf-special-case-dhcp user@B# set fe-0/1/1 unit 9 family inet rpf-check fail-filter rpf-special-case-dhcp user@B# set fe-0/1/0 unit 13 family inet rpf-check fail-filter rpf-special-case-dhcp
(Opcional) Configure el filtro de error que se evalúa si un paquete falla en la comprobación RPF.
[edit firewall filter rpf-special-case-dhcp] user@B# set term allow-dhcp from source-address 0.0.0.0/32 user@B# set term allow-dhcp from destination-address 255.255.255.255/32 user@B# set term allow-dhcp then count rpf-dhcp-traffic user@B# set term allow-dhcp then accept user@B# set term default then log user@B# set term default then reject
(Opcional) Configure solo las rutas activas para que se consideren en la comprobación RPF.
Este es el comportamiento predeterminado.
[edit routing-options forwarding-table] user@B# set unicast-reverse-path active-paths
Si ha terminado de configurar el dispositivo B, confirme la configuración.
[edit] user@B# commit
Resultados
Confirme su configuración mediante la emisión de los show firewallcomandos , show interfacesshow protocols, show routing-options, yshow policy-options. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
Dispositivo A
user@A# show interfaces
fe-1/2/0 {
unit 1 {
family inet {
address 10.0.0.1/30;
}
}
}
fe-0/0/2 {
unit 5 {
family inet {
address 10.0.0.5/30;
}
}
}
fe-0/0/1 {
unit 17 {
family inet {
address 10.0.0.17/30;
}
}
}
fe-0/1/1 {
unit 25 {
family inet {
address 10.0.0.25/30;
}
}
}
fe-1/1/1 {
unit 29 {
family inet {
address 10.0.0.29/30;
}
}
}
user@A# show protocols
ospf {
export send-direct;
area 0.0.0.0 {
interface fe-0/1/1.25;
interface fe-1/1/1.29;
}
}
user@A# show policy-options
policy-statement send-direct {
from {
protocol direct;
route-filter 10.0.0.16/30 exact;
}
then accept;
}
Dispositivo B
user@B# show firewall
filter rpf-special-case-dhcp {
term allow-dhcp {
from {
source-address {
0.0.0.0/32;
}
destination-address {
255.255.255.255/32;
}
}
then {
count rpf-dhcp-traffic;
accept;
}
}
term default {
then {
log;
reject;
}
}
}
user@B# show interfaces
fe-1/2/0 {
unit 2 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.2/30;
}
}
}
fe-1/1/1 {
unit 6 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.6/30;
}
}
}
fe-0/1/1 {
unit 9 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.9/30;
}
}
}
fe-0/1/0 {
unit 13 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.13/30;
}
}
}
user@B# show protocols
ospf {
area 0.0.0.0 {
interface fe-0/1/1.9;
interface fe-0/1/0.13;
}
}
user@B# show routing-options
forwarding-table {
unicast-reverse-path active-paths;
}
Ingrese las configuraciones en los dispositivos C, D y E, como se muestra en configuración rápida de CLI.
Verificación
Confirme que la configuración funciona correctamente.
- Confirme que la RPF de unidifusión está habilitada
- Confirme que las direcciones de origen están bloqueadas
- Confirme que las direcciones de origen están desbloqueadas
Confirme que la RPF de unidifusión está habilitada
Propósito
Asegúrese de que las interfaces del dispositivo B tengan habilitado RPF de unidifusión.
Acción
user@B> show interfaces fe-0/1/0.13 extensive
Logical interface fe-0/1/0.13 (Index 73) (SNMP ifIndex 553) (Generation 208)
Flags: SNMP-Traps 0x4000 Encapsulation: ENET2
Traffic statistics:
Input bytes : 999390
Output bytes : 1230122
Input packets: 12563
Output packets: 12613
Local statistics:
Input bytes : 998994
Output bytes : 1230122
Input packets: 12563
Output packets: 12613
Transit statistics:
Input bytes : 396 0 bps
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Protocol inet, MTU: 1500, Generation: 289, Route table: 22
Flags: Sendbcast-pkt-to-re, uRPF
RPF Failures: Packets: 0, Bytes: 0
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.0.0.12/30, Local: 10.0.0.13, Broadcast: 10.0.0.15, Generation: 241
Significado
El indicador uRPF confirma que la RPF de unidifusión está habilitada en esta interfaz.
Confirme que las direcciones de origen están bloqueadas
Propósito
Utilice el comando para asegurarse de que el ping dispositivo B bloquea el tráfico de direcciones de origen inesperadas.
Acción
Desde el dispositivo A, ping las interfaces del dispositivo B, usando 10.0.0.17 como dirección de origen.
user@A> ping 10.0.0.6 source 10.0.0.17 PING 10.0.0.6 (10.0.0.6): 56 data bytes ^C --- 10.0.0.6 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss
Significado
Como se esperaba, la operación de ping falla.
Confirme que las direcciones de origen están desbloqueadas
Propósito
Utilice el ping comando para asegurarse de que el dispositivo B no bloquee el tráfico cuando la comprobación RPF está desactivada.
Acción
Desactive la comprobación RPF en una de las interfaces.
Vuelva a ejecutar la operación de ping.
user@B> deactivate interfaces fe-1/1/1.6 family inet rpf-check user@A> ping 10.0.0.6 source 10.0.0.17 PING 10.0.0.2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=63 time=1.316 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=1.263 ms ^C --- 10.0.0.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.263/1.289/1.316/0.027 ms
Significado
Como se esperaba, la operación de ping tiene éxito.