Configuración de la supervisión de IP con conmutación por error de ruta
Mediante la supervisión de IP con conmutación por error de ruta, puede realizar un seguimiento de una dirección IP o un conjunto de direcciones IP mediante una sonda de supervisión del rendimiento en tiempo real (RPM). Si se produce un error en la sonda RPM, puede insertar una ruta en la tabla de enrutamiento. Una vez que la sonda RPM alcanza correctamente su objetivo, la ruta se retira de las tablas de enrutamiento y reenvío.
La figura 1 muestra la topología utilizada en el ejemplo de configuración y cómo funciona la supervisión de IP.
de supervisión del rendimiento en tiempo real
En el estado normal de operación, el enrutador del siguiente salto para alcanzar la dirección IP 5.1.1.1 en la puerta de enlace de la serie SRX es 1.1.1.2. Sin embargo, cuando la sonda RPM a la dirección IP 5.1.1.2 falla, debe utilizar la dirección IP 2.1.1.2 como el siguiente salto.
Para lograr este resultado, defina una sonda RPM para monitorear la dirección IP 5.1.1.2. Introduzca la siguiente configuración:
set services rpm probe Probe-Payment-Server test paysvr target address 5.1.1.2 set services rpm probe Probe-Payment-Server test paysvr probe-count 5 set services rpm probe Probe-Payment-Server test paysvr probe-interval 5 set services rpm probe Probe-Payment-Server test paysvr test-interval 3 set services rpm probe Probe-Payment-Server test paysvr thresholds successive-loss 5 set services rpm probe Probe-Payment-Server test paysvr destination-interface fe-0/0/1.0 set services rpm probe Probe-Payment-Server test paysvr hardware-timestamp set services rpm probe Probe-Payment-Server test paysvr next-hop 1.1.1.2
Configure también la directiva de supervisión de IP para agregar una ruta preferida cuando falle el sondeo RPM. Introduzca la siguiente configuración:
set services ip-monitoring policy payment match rpm-probe Probe-Payment-Server set services ip-monitoring policy payment then preferred-route route 5.1.1.0/24 next-hop 2.1.1.2
En el estado estable, puede llegar a la dirección IP 5.1.1.1 a través del dispositivo con la dirección IP 1.1.1.2, y los sondeos RPM se realizan correctamente. Para comprobar el funcionamiento del estado estable, utilice los siguientes comandos:
root# run traceroute 5.1.1.1 source 10.1.1.1 traceroute to 5.1.1.1 (5.1.1.1) from 10.1.1.1, 30 hops max, 40 byte packets 1 1.1.1.2 (1.1.1.2) 14.697 ms 2.953 ms 9.043 ms 2 5.1.1.1 (5.1.1.1) 9.916 ms 3.612 ms 4.085 ms
En la siguiente show salida de comando, los PASS resultados en el Status campo indican que la sonda se ha realizado correctamente:
root# run show services ip-monitoring status Policy - payment RPM Probes: Probe name Address Status ---------------------- ---------------- --------- Probe-Payment-Server 5.1.1.2 PASS Route-Action: route-instance route next-hop State ----------------- ----------------- ---------------- ------------- inet.0 5.1.1.0 2.1.1.2 NOT-APPLIED
En la siguiente show salida de comando, el recuento y el recuento son iguales y Probes received el Probes sent Loss percentage es 0. Esto indica que la sonda se ha realizado correctamente.
root# run show services rpm probe-results
Owner: Probe-Payment-Server, Test: paysvr
Target address: 5.1.1.2, Probe type: icmp-ping
Destination interface name: fe-0/0/1.0
Test size: 5 probes
Probe results:
Response received, Tue Sep 20 06:18:00 2011, No hardware timestamps
Rtt: 1776 usec
Results over current test:
Probes sent: 5, Probes received: 5, Loss percentage: 0
Measurement: Round trip time
Samples: 5, Minimum: 1490 usec, Maximum: 7399 usec, Average: 2952 usec,
Peak to peak: 5909 usec, Stddev: 2235 usec, Sum: 14758 usec
Results over last test:
Probes sent: 5, Probes received: 5, Loss percentage: 0
Test completed on Tue Sep 20 06:18:00 2011
Measurement: Round trip time
Samples: 5, Minimum: 1490 usec, Maximum: 7399 usec, Average: 2952 usec,
Peak to peak: 5909 usec, Stddev: 2235 usec, Sum: 14758 usec
Results over all tests:
Probes sent: 45, Probes received: 45, Loss percentage: 0
Measurement: Round trip time
Samples: 45, Minimum: 1490 usec, Maximum: 93350 usec,
Average: 4766 usec, Peak to peak: 91860 usec, Stddev: 13517 usec,
Sum: 214456 usec
Cuando no se puede acceder a la dirección IP 5.1.1.2, los sondeos RPM fallan y la ruta especificada en la configuración de supervisión IP se inserta en la tabla de enrutamiento. La ruta insertada tiene una preferencia de uno (1), que tiene una preferencia más alta que cualquier ruta estática o ruta aprendida a través de un protocolo de enrutamiento. Ahora se puede acceder al servidor con la dirección IP 5.1.1.1 a través del dispositivo con la dirección IP de 2.1.1.2. Para comprobar el funcionamiento del estado de error, utilice los siguientes comandos:
root# run show services ip-monitoring status
Policy - test-remote-server
RPM Probes:
Probe name Address Status
---------------------- ---------------- ---------
Probe-Payment-Server 5.1.1.2 FAIL
Route-Action:
route-instance route next-hop State
----------------- ----------------- ---------------- -------------
inet.0 5.1.1.0 2.1.1.2 APPLIED
En el siguiente show resultado de comando, to 2.1.1.2 via fe-0/0/2.0 indica que la ruta ha cambiado:
root# run show route 5.1.1.1
inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
5.1.1.0/24 *[Static/1] 00:00:18, metric2 0
> to 2.1.1.2 via fe-0/0/2.0
[Static/5] 00:01:38
> to 1.1.1.2 via fe-0/0/1.0
En el siguiente show resultado de comando, (2.1.1.2) indica que la ruta ha cambiado desde (1.1.1.2) la mostrada en el traceroute de estado estable:
root# run traceroute 5.1.1.1 source 10.1.1.1 traceroute to 5.1.1.1 (5.1.1.1) from 10.1.1.1, 30 hops max, 40 byte packets 1 2.1.1.2 (2.1.1.2) 9.436 ms 9.457 ms 9.011 ms 2 5.1.1.1 (5.1.1.1) 3.671 ms 3.553 ms 4.036 ms
Cuando se vuelve a contactar con la dirección IP 5.1.1.2, el sondeo RPM alcanza correctamente su objetivo y se retira la ruta que se agregó en la tabla de enrutamiento.
Para comprobar el funcionamiento del estado estable restaurado, utilice los siguientes comandos y compruebe que los resultados son similares a los resultados de estado estable descritos anteriormente:
root# run show services rpm probe-results
Owner: Probe-Payment-Server, Test: paysvr
Target address: 5.1.1.2, Probe type: icmp-ping
Destination interface name: fe-0/0/1.0
Test size: 5 probes
Probe results:
Response received, Tue Sep 20 08:00:02 2011, No hardware timestamps
Rtt: 1410 usec
Results over current test:
Probes sent: 3, Probes received: 3, Loss percentage: 0
Measurement: Round trip time
Samples: 3, Minimum: 1410 usec, Maximum: 1769 usec, Average: 1596 usec,
Peak to peak: 359 usec, Stddev: 147 usec, Sum: 4788 usec
Results over last test:
Probes sent: 5, Probes received: 5, Loss percentage: 0
Test completed on Tue Sep 20 07:59:49 2011
Measurement: Round trip time
Samples: 5, Minimum: 1509 usec, Maximum: 3057 usec, Average: 1922 usec,
Peak to peak: 1548 usec, Stddev: 579 usec, Sum: 9612 usec
Results over all tests:
Probes sent: 143, Probes received: 25, Loss percentage: 82
Measurement: Round trip time
Samples: 25, Minimum: 1410 usec, Maximum: 8086 usec, Average: 2973 usec,
Peak to peak: 6676 usec, Stddev: 2337 usec, Sum: 74333 usec
root# run show route 5.1.1.1
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
5.1.1.0/24 *[Static/5] 00:13:18
> to 1.1.1.2 via fe-0/0/1.0
root# run show services ip-monitoring status
Policy - test-remote-server
RPM Probes:
Probe name Address Status
---------------------- ---------------- ---------
Probe-Payment-Server 5.1.1.2 PASS
Route-Action:
route-instance route next-hop State
----------------- ----------------- ---------------- -------------
inet.0 5.1.1.0 2.1.1.2 NOT-APPLIED
root# run traceroute 5.1.1.1 source 10.1.1.1 traceroute to 5.1.1.1 (5.1.1.1) from 10.1.1.1, 30 hops max, 40 byte packets 1 1.1.1.2 (1.1.1.2) 9.590 ms 9.968 ms 15.589 ms 2 5.1.1.1 (5.1.1.1) 9.175 ms 3.914 ms 3.750 ms
Es importante tener en cuenta que en la configuración de RPM, se especifica el valor del salto siguiente. Esto garantiza que todos los sondeos (incluso después de la conmutación por error) tomen la misma ruta para llegar a la dirección IP rastreada.
Sin el valor del salto siguiente, es posible que después de inyectar la nueva ruta (cuando falla la sonda RPM), haya una nueva ruta para llegar a la dirección IP rastreada. También es posible que si el sistema elige esta nueva ruta, es posible que un enrutador ascendente no tenga una ruta a la dirección IP rastreada, que los sondeos siempre fallen y que el sistema nunca vuelva a conmutar por error. Por lo tanto, siempre se recomienda incluir la instrucción en la next-hop configuración.