Help Center/ Huawei Qiankun CloudService/ More Documents/ Device Alarm Handling/ V300 AR Alarms/ ALM-4289404934 All connections between sites have entered down state
Updated on 2024-01-25 GMT+08:00

ALM-4289404934 All connections between sites have entered down state

Description

CONN/4/CONN_SITE_DISCONNECT:OID [oid] All connections between sites have entered down state. (SrcSite=[integer1], DestSite=[integer2])

SD-WAN EVPN sites are disconnected.

Attribute

Alarm ID

OID

Alarm Severity

Alarm Type

4289404934

1.3.6.1.4.1.2011.5.25.241.6.3.8

Major

Communication alarm

Parameters

Name

Meaning

oid

Indicates the MIB object ID of the alarm.

SrcSite

Name of the source site.

DestSite

Name of the destination site.

Impact on the System

All EVPN links between sites are in the Down state.

For each EVPN link in the Down state, the possible causes are as follows:

  • No keepalive packet is received from the peer device within the configured detection period.
  • A change in the protocol status of a physical interface may cause a change in the link status.
  • The BGP protocol established with the remote site is interrupted.

Possible Causes

  • Cause 1: KA detection fails.
  • Cause 2: The KA status is abnormal.
  • Cause 3: The interface went Down.
  • Cause 4: The interface address was changed.
  • Cause 5: NAT probe failed.
  • Cause 6: BGP instructs the TNP to be deleted.
  • Cause 7: BGP instructs the TNP to be updated.
  • Cause 8: The TNP weight changes.
  • Cause 9: The TNP configuration is changed.
  • Cause 10: DTLS notification.
  • Cause 11: The user is reset.
  • Cause 12: The diagnosis is complete.
  • Cause 13: The service route of the site was deleted.
  • Cause 14: The DH group does not match.
  • Cause 15: The DH group changes.
  • Cause 16: Self-healing was recovered.
  • Cause 17: The dynamic tunnel was aged.
  • Cause 18: The dynamic tunnel was blocked.
  • Cause 19: The dynamic tunnel was cleared.
  • Cause 20: Other causes.

Procedure

  1. Check whether the interfaces bound to the TNP can be pinged.
    • If yes, go to Step 23.
    • If not, go to step 2.
  2. Check whether the intermediate transmission network is faulty.
  3. The inspection method is the same as that in step 1 and step 2.
  4. Check whether the physical protocol status of the interface bound to the TNP is Up.
  5. Check whether the shutdown command is run on the interface.
  6. Check whether the IP address of the interface bound to the TNP is changed.
  7. Check whether the interfaces bound to the TNP can be pinged.
    • If yes, go to Step 23.
    • If not, go to step 8.
  8. Check whether ports 3478 and 4500 are restricted on the intermediate transport network.
  9. Run the display site-tnp site-id command to check whether the TNP of the peer device is deleted.
    • If yes, configure the TNP information.
    • If no, collect alarm and configuration information and contact technical support.
  10. Check whether the service route to the corresponding site changes.
  11. Run the display site-tnp site-id verbose command to check whether the TNP weight changes.
  12. Run the display site-tnp site-id verbose command to check whether the TNP bandwidth changes.
  13. Check whether the ESN blocklist and trustlist function is configured.
  14. Check whether BGP or connection reset is performed on the local device.
  15. Check whether the device has flapped.
  16. Check whether the service route to the corresponding site is deleted.
    1. Run the display tunnel all command to view information about all tunnels.
    2. Run the display tunnel tunnel-id command to check information about SD-WAN tunnels one by one and check whether service routes exist.
      • If it does not exist, configure the corresponding site route.
      • If yes, collect alarm and configuration information and contact technical support.
  17. Check whether the DH group of the local device matches that of the peer device.

    Run the display ipsec p2mp-policy command to check information about IPSec Key Exchange on both ends. If the DH groups of the two communication parties are different and one party uses the strict mode, the DH groups cannot be matched. Configure the same DH group or disable the strict mode.

  18. Run the display ipsec p2mp-policy command to check key-exchange information on the peer device. Check whether the DH group is changed.
  19. The device detects that the connection is abnormal and recovers from self-healing.
  20. Run the display smart-policy-route command to check whether dynamic tunnels are enabled. If dynamic tunnels are enabled, check whether traffic does not exist.
    • If the traffic persists, go to Step 23.
    • If the traffic is not present, it is normal.
  21. Run the display smart-policy-route command to check whether dynamic tunnels are enabled. If dynamic tunnels are enabled, check whether the number of links exceeds the upper limit.
    • If the number exceeds the specifications, the RR/HUB site resources are insufficient.
    • If the number does not exceed the specifications, collect alarm and configuration information and contact technical support.
  22. Run the display smart-policy-route command to check whether dynamic tunnels are enabled.
    • If dynamic tunnels are enabled, unnecessary links are cleared.
    • If not, collect alarm and configuration information and contact technical support.
  23. Collect alarm and configuration information and contact technical support.

Clearing

After the fault is rectified, the system clears this alarm, removing the need to manually clear it. This alarm will not be displayed on the Current Alarms page.