Comprobación de reenvío de ruta inversa de unidifusión para VPN
Descripción de la RPF de unidifusión (conmutadores)
Para protegerse contra la suplantación de IP y algunos tipos de ataques de denegación de servicio (DoS) y de 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 que no es de confianza y la compara con la entrada de la tabla de reenvío de 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 de una ruta válida, el dispositivo descarta el paquete. A menos que esté protegido contra, la suplantación de IP puede ser una forma efectiva para que los intrusos pasen paquetes IP a un destino como tráfico genuino, cuando en realidad los paquetes no están destinados al destino.
RPF de unidifusión es compatible con las familias de protocolos IPv4 e IPv6, así como con la familia de direcciones de red privada virtual (VPN). RPF de unidifusión no se admite en interfaces configuradas como orígenes 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 suelto. El valor predeterminado es el modo estricto, lo que significa que el conmutador reenvía un paquete sólo si la interfaz receptora 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 (donde usuarios o procesos que no son de confianza pueden colocar paquetes en el segmento de red) y para interfaces enrutadas simétricamente (consulte Cuándo habilitar RPF de unidifusión). Para obtener más información acerca de la RPF de unidifusión estricta, consulte RFC 3704, Filtrado de entrada para redes de host múltiple en http://www.ietf.org/rfc/rfc3704.txt.
Para habilitar el RPF de unidifusión de modo estricto en una interfaz de borde del cliente seleccionada:
[editar interfaces]user@switch# set interface-name unit 0 family inet rpf-check
El otro modo es el modo flexible, 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 activar el modo flexible RPF de unidifusión, escriba:
[editar interfaces]user@switch# set interface-name unit 0 family inet rpf-check mode loose
- Descripción general del RPF de unidifusión para conmutadores
- Implementación del FPR de unidifusión
- Cuándo habilitar la RPF de unidifusión
- Cuándo no habilitar RPF de unidifusión
- Limitaciones de la implementación del FPR de unidifusión en conmutadores EX3200, EX4200 y EX4300
Descripción general del RPF de unidifusión para conmutadores
El 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, RPF de unidifusión está deshabilitado en las interfaces del conmutador. El conmutador solo admite el método de rutas activas para determinar la mejor ruta de retorno a una dirección de origen de unidifusión. El método de rutas activas busca la mejor entrada de ruta inversa de la tabla de reenvío. No tiene en cuenta las rutas alternativas especificadas mediante métodos específicos del protocolo de enrutamiento a la hora de determinar la mejor ruta de retorno.
Si en la tabla de reenvío se muestra la interfaz receptora como la interfaz que se utilizará para reenviar el paquete de vuelta a su origen de unidifusión, es la mejor interfaz de ruta de retorno.
Implementación del FPR de unidifusión
- Filtrado de paquetes RPF de unidifusión
- Protocolo de arranque (BOOTP) y solicitudes DHCP
- Manejo de rutas predeterminado
Filtrado de paquetes RPF de unidifusión
Cuando se habilita la RPF de unidifusión en el conmutador, este controla el tráfico de la siguiente manera:
Si el conmutador recibe un paquete en la interfaz que es 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 desde el 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.
Protocolo de arranque (BOOTP) y solicitudes DHCP
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 paquetes de solicitud DHCP sin realizar comprobaciones RPF de unidifusión.
Manejo de rutas predeterminado
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 del FPR de unidifusión normal en los paquetes.
En el EX4300, la ruta predeterminada no se utiliza cuando el conmutador está configurado en modo estricto RPF de unidifusión.
Cuándo habilitar la RPF de unidifusión
Active RPF de unidifusión cuando desee asegurarse de que el tráfico que llega a una interfaz de red proviene de un origen que reside en una red a la que la interfaz puede llegar. Puede habilitar RPF de unidifusión en interfaces que no sean 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 provenientes de Internet.
Habilitar 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 falsificado antes de que pueda propagarse o llegar a interfaces que no tienen habilitado el RPF de unidifusión. Dado que la RPF de unidifusión está habilitada globalmente en los conmutadores EX3200, EX4200 y EX4300, asegúrese de que todas las interfaces estén enrutadas 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 que se filtren paquetes de fuentes legítimas. Una interfaz enrutada simétricamente utiliza la misma ruta en ambas direcciones entre el origen y el destino.
El FPR de unidifusión se habilita globalmente en los conmutadores EX3200, EX4200 y EX4300, por lo que con estos dispositivos, asegúrese de que todas las interfaces estén enrutadas simétricamente antes de habilitar el RPF de unidifusión en estos conmutadores. La habilitación de RPF de unidifusión en interfaces enrutadas asimétricamente da como resultado que se filtren paquetes de fuentes legítimas.
enrutadas simétricamente
Es muy probable que las siguientes interfaces de conmutación se enruten simétricamente y, por lo tanto, son candidatas para habilitar RPF de unidifusión:
El borde del proveedor de servicios para un cliente
El borde del cliente a un proveedor de servicios
Un único punto de acceso fuera de la red (normalmente en el perímetro de la red)
Una red de terminales que tiene un solo vínculo
En los conmutadores EX3200, EX4200 y EX4300, se recomienda habilitar explícitamente el RPF de unidifusión en todas las interfaces o en una sola. Para evitar posibles confusiones, no lo habilite solo en algunas interfaces:
Habilitar el RPF de unidifusión explícitamente en una sola interfaz hace que sea más fácil si decide deshabilitarlo en el futuro, ya que debe deshabilitar explícitamente el RPF de unidifusión en cada interfaz en la que lo habilitó explícitamente. Si habilita explícitamente el FPR de unidifusión en dos interfaces y lo deshabilita en una sola interfaz, el FPR de unidifusión seguirá estando habilitado implícitamente globalmente en el conmutador. El inconveniente de este enfoque es que el conmutador muestra el indicador que indica que el FPR de unidifusión solo está habilitado en interfaces en las que el FPR de unidifusión está habilitado explícitamente, por lo que, aunque el FPR de unidifusión está habilitado en todas las interfaces, este estado no se muestra.
Habilitar RPF de unidifusión explícitamente en todas las interfaces hace que sea más fácil saber si el RPF de unidifusión está habilitado en el conmutador, ya que cada interfaz muestra el estado correcto. (Solo las interfaces en las que se habilita explícitamente el RPF de unidifusión muestran el indicador que indica que el RPF de unidifusión está habilitado). El inconveniente de este enfoque es que si desea deshabilitar RPF de unidifusión, debe deshabilitarlo explícitamente en cada interfaz. Si el FPR de unidifusión está habilitado en cualquier interfaz, se habilita implícitamente en todas las interfaces.
Cuándo no habilitar RPF de unidifusión
Normalmente, no habilitará el FPR de unidifusión si:
Las interfaces de conmutador son de multiconexión.
Las interfaces de conmutador son interfaces de confianza.
BGP lleva prefijos y algunos de esos prefijos no se anuncian o no son aceptados por el ISP bajo 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 conmutador están orientadas hacia el núcleo de la red. Las interfaces orientadas al núcleo suelen enrutarse asimétricamente.
Una interfaz enrutada asimétricamente usa 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 al origen. Si la interfaz receptora no es la mejor ruta de retorno al origen de un paquete, el RPF de unidifusión hace que el conmutador descarte el paquete aunque provenga de un origen válido.
enrutadas asimétricamente
No habilite el RPF de unidifusión en conmutadores EX3200, EX4200 y EX4300 si alguna interfaz de conmutador está enrutada asimétricamente, ya que el FPR de unidifusión está habilitado globalmente en todas las interfaces de estos conmutadores. Todas las interfaces de 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 del FPR 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 mundial. No se puede habilitar RPF de unidifusión por interfaz. La RPF de unidifusión está deshabilitada globalmente de forma predeterminada.
Cuando se habilita RPF de unidifusión en cualquier interfaz, se habilita automáticamente en todas las interfaces de conmutador, 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 se 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 el RPF de unidifusión en cada interfaz en la que se habilitó explícitamente, o el RPF de unidifusión permanece habilitado en todas las interfaces del conmutador.
Los conmutadores QFX, OCX y EX3200 y EX4200 no realizan el filtrado RPF de unidifusión en el tráfico de múltiples rutas (ECMP) de igual costo. La comprobación RPF de unidifusión examina sólo una de las mejores rutas 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 porque 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 ayudar a defender las interfaces de entrada contra ataques de denegación de servicio (DoS) y denegación de servicio distribuido (DDoS) configurando RPF de unidifusión en una interfaz perimetral 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 utiliza OSPF para anunciar un prefijo para el vínculo que se conecta al dispositivo D. El dispositivo B tiene configurado un RPF de unidifusión. 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 a través del 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 puedan llegar al agente de retransmisión en los enrutadores cuando corresponda.
En este ejemplo también se incluye un filtro de error. Cuando un paquete no supera la comprobación RPF de unidifusión, se evalúa el filtro de error 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.
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, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] 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
En el ejemplo siguiente es necesario navegar por varios niveles en la jerarquía de configuración. Para obtener 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 directiva 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
En el ejemplo siguiente es necesario navegar por varios niveles en la jerarquía de configuración. Para obtener 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 el 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 no supera la comprobación de 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 tengan en cuenta en la comprobación del 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 la configuración emitiendo los show firewallcomandos , show interfaces, show routing-optionsshow protocols, y .show policy-options Si el resultado no muestra la configuración deseada, repita las instrucciones de 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 la CLI.
Verificación
Confirme que la configuración funciona correctamente.
- Confirmar que el FPR de unidifusión esté habilitado
- Confirmar que las direcciones de origen están bloqueadas
- Confirme que las direcciones de origen estén desbloqueadas
Confirmar que el FPR de unidifusión esté habilitado
Propósito
Asegúrese de que las interfaces del dispositivo B tengan habilitado el 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 el FPR de unidifusión está habilitado en esta interfaz.
Confirmar que las direcciones de origen están bloqueadas
Propósito
Use el comando para asegurarse de que el dispositivo B bloquea el ping tráfico de direcciones de origen inesperadas.
Acción
Desde el dispositivo A, haga ping a las interfaces del dispositivo B, utilizando 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 era de esperar, se produce un error en la operación de ping.
Confirme que las direcciones de origen estén desbloqueadas
Propósito
Utilice el comando para asegurarse de que el dispositivo B no bloquea el ping 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 era de esperar, la operación de ping se realiza correctamente.