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
- Check whether the interfaces bound to the TNP can be pinged.
- If yes, go to Step 23.
- If not, go to step 2.
- Check whether the intermediate transmission network is faulty.
- The inspection method is the same as that in step 1 and step 2.
- Check whether the physical protocol status of the interface bound to the TNP is Up.
- Check whether the shutdown command is run on the interface.
- Check whether the IP address of the interface bound to the TNP is changed.
- Check whether the interfaces bound to the TNP can be pinged.
- If yes, go to Step 23.
- If not, go to step 8.
- Check whether ports 3478 and 4500 are restricted on the intermediate transport network.
- 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.
- Check whether the service route to the corresponding site changes.
- Run the display site-tnp site-id verbose command to check whether the TNP weight changes.
- Run the display site-tnp site-id verbose command to check whether the TNP bandwidth changes.
- Check whether the ESN blocklist and trustlist function is configured.
- Check whether BGP or connection reset is performed on the local device.
- Check whether the device has flapped.
- Check whether the service route to the corresponding site is deleted.
- Run the display tunnel all command to view information about all tunnels.
- 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.
- 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.
- Run the display ipsec p2mp-policy command to check key-exchange information on the peer device. Check whether the DH group is changed.
- The device detects that the connection is abnormal and recovers from self-healing.
- 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.
- 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.
- 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.
- 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.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot