IPFPM/3/hwIpfpmMultiTwoDelayExceed_active

Message

IPFPM/3/hwIpfpmMultiTwoDelayExceed_active: The two-way delay of one link in an IPFPM test instance exceeded the upper threshold over five consecutive statistical periods. (TestInstanceId=[InstanceId], AchId=[AchId], IpfpmMcpSeqNoHigh=[SeqNoHigh], IpfpmMcpSeqNoLow=[SeqNoLow], ForwardSourceDCP=[FwdSrcDcpId], ForwardSourceTLP=[FwdSrcTlpId], ForwardDestinationDCP =[FwdDstDcpId], ForwardDestinationTLP=[FwdDstTlpId], BackwardSourceDCP=[BwdSrcDcpId], BackwardSourceTLP=[BwdSrcTlpId], BackwardDestinationDCP=[BwdDstDcpId], BackwardDestinationTLP=[BwdDstTlpId], TwoDelay=[DelayValue])

Description

The two-way delay of one link in an IP FPM instance exceeded the upper threshold over five consecutive statistical periods.

Parameters

Parameter Name	Parameter Meaning
InstanceId	IP FPM instance ID
AchId	Atomic closed hop ID
SeqNoHigh	32 most significant bits of the statistical period ID
SeqNoLow	32 least significant bits of the statistical period ID
FwdSrcDcpId	Source DCP for the forward target flow
FwdSrcTlpId	Source TLP for the forward target flow
FwdDstDcpId	Destination DCP for the forward target flow
FwdDstTlpId	Destination TLP for the forward target flow
BwdSrcDcpId	Source DCP for the backward target flow
BwdSrcTlpId	Source TLP for the backward target flow
BwdDstDcpId	Destination DCP for the backward target flow
BwdDstTlpId	Destination TLP for the backward target flow
DelayValue	Two-way delay for the target flow

Possible Causes

Cause 1: The network bandwidth was insufficient because of abnormal traffic.

Cause 2: The physical link was unstable.

Procedure

1. Check whether abnormal traffic existed on the network when the trap was generated.

If abnormal traffic existed on the network, go to Step 2.
If no abnormal traffic existed on the network, go to Step 3.

2. Check whether the abnormal traffic was caused by misoperations.

If the abnormal traffic was caused by misoperations, go to Step 3.
If the abnormal traffic was not caused by misoperations, go to Step 6.

3. Delete the misoperation configurations and check whether the trap persists.

If the trap persists, go to Step 4.
If the trap is cleared, go to Step 7.

4. Check whether the link status was stable when the trap was generated.

If the link status was stable, go to Step 6.
If the link status was unstable, go to Step 5.

5. Check the problem that caused the unstable link status, resolve the problem, and check whether the trap persists.

If the trap persists, go to Step 6.
If the trap is cleared, go to Step 7.

6. Collect alarm information and configuration information, and then contact technical support personnel.

7. End.