Tabla de contenido
La cabida útil de los paquetes transmitidos durante el funcionamiento de la herramienta Ping
NO DEBERÍA ser ni todos ceros ni todos unos.
Cuando se arranca la herramienta Ping (es decir, cuando el valor de cabhCtpPingControl se fija a
start(1))
el
CTP
cabhCtpPingAvgRTT, cabhCtpPingMaxRTT, cabhCtpPingMinRTT, cabhCtpPingNumIcmpError y
cabhCtpPingIcmpError cada uno al valor 0.
El RTT de la herramienta Ping se mide en el PS como el tiempo transcurrido desde el último bit de
cada paquete transmitido por la herramienta Ping de CTP, al instante en que se recibe el último bit
de ese paquete.
El CTP DEBE permitir que la dirección IP de destino de la herramienta Ping (cabhCtpPingDestIp)
pueda fijarse a cualquier dirección IPv4 válida de cualquier dispositivo IP de LAN al que se pueda
acceder a través de cualquier interfaz LAN del PS que hace funcionar la herramienta Ping CTP.
La herramienta Ping NO DEBE generar paquetes por ninguna interfaz WAN.
El CTP NO DEBE utilizar ninguna dirección IP para la dirección IP de origen de la herramienta
Ping (cabhCtpPingSrcIp) excepto una dirección IP válida actual WAN-Data del PS (es decir, un
valor de objeto cabhCdpWanDataAddrIp activo) O una dirección IP válida actual de interfaz
LAN del PS. Si se configura un valor no válido para cabhCtpPingSrcIp, el CTP DEBE tratar la
ejecución de la prueba como un caso abortado y fijar el objeto cabhCtpPingStatus de estado de la
herramienta Ping a "abortado" y notificar el evento apropiado (véase el cuadro B.1).
6.5
Comunicación de eventos
El mecanismo de comunicación y control de eventos utilizado es RFC 2669, que define un formato
normalizado para la comunicación de la información de eventos, independientemente del tipo de
mensaje, e incluye un cuadro local de registro histórico de eventos, de cuyos elementos se
conservarán tras el rearranque del PS. Obsérvese que los eventos puede generarlos cualquier parte
del PS, pero el CMP efectúa las anotaciones históricas y/o comunica el evento o bien localmente o a
un servidor de registro histórico del sistema (Syslog) o de trampas (Trap).
6.5.1
Notificación de eventos
El PS DEBE generar eventos asíncronos correspondientes a los eventos y situaciones de
importancia especificados (véase el anexo B). Los eventos pueden almacenarse en un registro
histórico de eventos interno (LOG), en memoria no volátil, comunicarse a otras entidades SNMP
(en forma de mensajes TRAP o INFORMES SNMP), o enviarse como mensaje de evento SYSLOG
a un servidor SYSLOG cuya dirección IP se transfiera en la opción 7 de DHCP OFFER que se
recibe del servidor DHCP de cabecera a través de la interfaz WAN-Man del PS.
El PS DEBE soportar los siguientes mecanismos de notificación de eventos:
•
Registro histórico local de eventos del que ciertas anotaciones pueden conservarse tras un
rearranque del PS.
•
SNMP TRAP y SNMP INFORM.
•
SYSLOG.
La notificación de eventos por parte del PS es totalmente configurable. El PS DEBE implementar
docsDevEvControlTable de RFC 2669 a fin de controlar la comunicación de eventos. El PS DEBE
soportar los siguientes valores BIT para el objeto RFC 2669 docsDevEvReporting:
•
1: local-no volátil(0)
•
2: trampas(1)
•
3: syslog(2)
•
4: local-volátil(3)
DEBE
reactivar
cabhCtpPingNumSent,
Rec. UIT-T J.191 (03/2004)
cabhCtpPingNumRecv,
53
Tabla de contenido
