No relevant resource is found in the selected language.
Enterprise
Worldwide
Huawei Global - English
Support Documentation
Troubleshooting Internet Access Failures Through AR Routers
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Troubleshooting Internet Access Failures Through AR Routers

Troubleshooting Internet Access Failures Through AR Routers

Internet Access Failure Scenarios

AR routers function as enterprise gateways to provide Internet access services for internal users. Therefore, AR routers play an important role on enterprise networks. This document describes how to troubleshoot Internet access failures on AR routers. WAN-side network faults and terminal-side faults are not covered in this document. This document analyzes multiple real cases on the live network. Based on the fault occurrence phase, users cannot access the Internet in two scenarios, which are described in Table 1-1.

Table 1-1 Internet access failure scenarios

Scenario

Scenario Description

Possible Causes

Troubleshooting Method

Failure to access the Internet after deployment

Internet access failures occur in the deployment phase when an AR is connected to the Internet for the first time. After deployment personnel configure the Internet access function on the AR for the first time, users cannot access the Internet.

This is mostly because Internet access configurations are incorrect. For example, NAT is not enabled, the default route is not configured, or the DHCP configuration is incorrect.

Check whether the corresponding configurations are correct by referring to Troubleshooting Internet Access Failures Occurred After Deployment.

Failure to access the Internet during AR running

Internet access failures occur when the AR has been successfully deployed and running properly for a period of time. At a certain time point or during a certain period of time, users cannot access the Internet.

This is mostly because unexpected events occur, such as hardware faults, public DNS exceptions, ARP attacks, IP address conflicts, and route unreachability.

Check whether the corresponding configurations are correct by referring to Troubleshooting Internet Access Failures Occurred During AR Running.

Possible Causes of Internet Access Failures

Figure 1-1 shows possible causes of Internet access failures.

Figure 1-1 Possible causes of Internet access failures

Troubleshooting Internet Access Failures Occurred After Deployment

Internet Access Failure After Web-based Deployment

Context

If users fail to access the Internet through an AR after web-based deployment, check whether NAT is enabled and whether the default route and DHCP configurations are correct on the AR's web platform.

Troubleshooting Procedure

  1. Check whether NAT is enabled on the AR. Log in to the AR's web platform and choose Advanced > IP > NAT. The NAT page is displayed. Click next to External Network Access. The External Network Access page is displayed.

    As shown in Figure 1-2, if no record is displayed in the Configured External Network Access List area, NAT is not enabled on the device. In this case, set Internet access parameters and enable NAT by referring to Configuring Internet Access on an AR Router Through a Web System. If a record is displayed in the Configured External Network Access List area, check whether the NAT configuration is correct.

    Figure 1-2 External Network Access page

  2. Check whether a default route is configured on the AR. Log in to the AR's web platform and choose Advanced > IP > Route > Static Route Configuration. Click next to IPv4 Static Route. The IPv4 Static Route page is displayed.

    As shown in Figure 1-3, if no record or no route with the destination IP address 0.0.0.0 is displayed in the Configured Static Route List area, no default route is configured on the AR. In this case, configure a default route in the Static Route Settings area by referring to Static Routes Configuration. If a record is displayed in the Configured Static Route List area, check whether the default route configuration is correct.

    Figure 1-3 IPv4 Static Route page

  3. As shown in Figure 1-4, if no record is displayed in the Configured IPv4 Address Pool List area, the DHCP function is not configured on the AR. In this case, configure a DHCP address pool in the IPv4 Address Pool Settings area by referring to DHCP Address Pool. If a record is displayed in the Configured IPv4 Address Pool List area, check whether the DHCP address pool configuration is correct.

    Figure 1-4 DHCP Address Pool page

  4. If the fault persists after the preceding steps, restart the AR and then reconfigure Internet access by referring to Internet Access Wizard. However, restarting the AR may interrupt services. Evaluate the impact on services before restarting the AR. To restart an AR and restore the factory settings, power it off or press and hold down the RESET button for five seconds or longer.

Internet Access Failure After CLI-based Deployment

Context

If users fail to access the Internet through an AR after CLI-based deployment, perform operations in this section to check whether the NAT, default route, and DHCP configurations are correct. Before the check, ping an IP address on the Internet. If the ping operation succeeds, the network connectivity is normal and the routing and DHCP configurations are correct. You only need to check whether the NAT configuration is correct. If the ping operation fails, the network connectivity is abnormal. You need to check whether the NAT, default route, and DHCP configurations are correct.

Specifically, if users fail to access the Internet in 3G, 4G, or 5G mode, there is a high probability that this is caused by a dial-up failure. For details about possible causes of dial-up failures, see Why Does Dialup Often Fail on a 3G Cellular Interface? and Why Does Dialup Often Fail on a 4G Cellular Interface?. If users fail to access the Internet in PPPoE dialup mode, check whether the authentication mode, user name, and password are correct.

Troubleshooting Procedure

  1. Check whether the NAT function is configured on the AR. To allow private network users to access the Internet, the AR functioning as the gateway must be configured with the outbound NAT function to translate private IP addresses into public IP addresses. ARs support two outbound NAT modes: Easy IP and address pool.

    • Assume that the AR's outbound interface connected to the Internet is GE0/0/1. Run the display this command on GE0/0/1 to check whether outbound NAT in Easy IP mode is configured.
      <Huawei> system-view
[Huawei] interface gigabitEthernet0/0/1
[Huawei-GigabitEthernet0/0/1] display this
# 
 ip address 1.1.1.1 255.255.255.0                                              
 nat outbound 2000
#
    • Assume that the AR's outbound interface connected to the Internet is GE0/0/1. Run the display this command on GE0/0/1 to check whether outbound NAT in address pool mode is configured.
      <Huawei> system-view 
[Huawei] interface gigabitEthernet0/0/1  
[Huawei-GigabitEthernet0/0/1] display this 
# 
 ip address 1.1.1.1 255.255.255.0                                              
 nat outbound 2000 address-group 1 
#
    • If outbound NAT is not configured on the AR's interface connected to the Internet, configure NAT by referring to Example for Connecting Intranet Users to the Internet in Easy IP Mode or Example for Connecting Intranet Users to the Internet in NAT Address Pool Mode.

  2. Check whether a default route is configured on the device. To allow private network users to access the Internet, ensure that there is a reachable route between the AR and Internet. The simplest method is to configure a default route on the AR.

    • Run the display current-configuration command on the AR to check whether a default route is configured.
      <Huawei> display current-configuration | include route-static
ip route-static 0.0.0.0 0.0.0.0 1.1.1.255
    • If no default route is configured, run the ip route-static command to configure a default route.
      <Huawei> system-view 
[Huawei] ip route-static 0.0.0.0 0.0.0.0 1.1.1.255

  3. Check whether the DHCP function is configured on the AR. To allow private network users to access the Internet, the AR must be configured with the DHCP server function so that it can automatically assign IP addresses to connected private network users. The AR supports two types of DHCP address pools: global address pool and interface address pool.

    • Assume that the AR's interface connected to the private network belongs to VLAN 10. Run the display this command to check whether a global address pool is configured on VLANIF 10.
      <Huawei> system-view 
[Huawei] interface vlanif 10  
[Huawei-Vlanif10] display this 
# 
 ip address 192.168.1.1 255.255.255.0                                              
 dhcp select global 
#
    • Assume that the AR's interface connected to the private network belongs to VLAN 10. Run the display this command to check whether an interface address pool is configured on VLANIF 10.
      <Huawei> system-view 
[Huawei] interface vlanif 10  
[Huawei-Vlanif10] display this 
# 
 ip address 192.168.1.1 255.255.255.0                                              
 dhcp select interface 
#
    • If the DHCP server function is not configured on VLANIF 10, configure this function by referring to Example for Configuring the Device as the DHCP Server to Dynamically Assign IP Addresses to Users or Example for Configuring the Device as a DHCP Server (Based on the Interface Address Pool).

Troubleshooting Internet Access Failures Occurred During AR Running

ARP Attacks Occur on the Private Network

Context

If users can access the Internet after deployment but some users fail to access the Internet after a period of time, ARP attacks may occur on the private network. In this case, check whether ARP attacks occur on the device.

Troubleshooting Procedure

  1. Run the display logbuffer command to check for logs indicating ARP packets are discarded due to the CPU usage exceeding the threshold.

    <Huawei> display logbuffer 
Sep  9 2014 16:01:55+00:00 Huawei %%01SECE/4/PORT_ATTACK(l)[0]:Port attack occurred.(Slot=MPU, SourceAttackInterface=GigabitEthernet0/0/0, OuterVlan/InnerVlan=0/0, AttackPackets=64 packets per second) 
Sep  9 2014 16:01:54+00:00 Huawei %%01DEFD/4/CPCAR_DROP_MPU(l)[1]:Some packets are dropped by cpcar on the MPU. (Packet-type=arp-miss, Drop-Count=770) 
Sep  9 2014 16:01:54+00:00 Huawei %%01DEFD/4/CPCAR_DROP_MPU(l)[2]:Some packets are dropped by cpcar on the MPU. (Packet-type=arp-request, Drop-Count=3458)

  2. If such logs are displayed, ARP attacks may occur on the private network connected to the device. In this case, you can configure attack source tracing on the device to further locate the fault.

    <Huawei> system-view 
[Huawei] cpu-defend policy 1 
[Huawei-cpu-defend-policy-1] auto-defend enable 
[Huawei-cpu-defend-policy-1] auto-defend threshold 40  // Set a proper threshold. 
[Huawei-cpu-defend-policy-1] auto-defend attack-packet sample 5 
[Huawei-cpu-defend-policy-1] auto-defend protocol all 
[Huawei-cpu-defend-policy-1] auto-defend trace-type source-ip source-mac source-portvlan 
[Huawei-cpu-defend-policy-1] auto-defend alarm enable 
[Huawei-cpu-defend-policy-1] quit 
[Huawei] cpu-defend-policy 1   
[Huawei] cpu-defend-policy 1 global

  3. If the network encounters exceptions after attack source tracing is configured, run the display auto-defend attack-source command on the device to check whether ARP attacks occur.

    [Huawei] display auto-defend attack-source 
  Attack Source User Table: 
  ------------------------------------------------------------------------- 
      MacAddress       InterfaceName      Vlan:Outer/Inner      TOTAL  
  ------------------------------------------------------------------------- 
  xxxx-xxxx-xxxx   GigabitEthernet0/0/1         0               368     
  yyyy-yyyy-yyyy   GigabitEthernet0/0/0         0               7152    
  ------------------------------------------------------------------------- 
  Total: 2 
 
  Attack Source Port Table: 
  ----------------------------------------------------- 
    InterfaceName        Vlan:Outer/Inner       TOTAL   
  ----------------------------------------------------- 
  GigabitEthernet0/0/1     0                    368    
  GigabitEthernet0/0/0     0                    23472  
  ----------------------------------------------------- 
  Total: 2 
 
  Attack Source IP Table: 
  ------------------------------------- 
   IPAddress        TOTAL Packets  
  ------------------------------------- 
  x.x.x.x      368     
  y.y.y.y      7152    
  -------------------------------------   
  Total: 2
    • The preceding command output shows that the terminal with the source IP address y.y.y.y and source MAC address yyyy-yyyy-yyyy sends a large number of attack packets. (In this example, the AR is connected to the Internet through GE0/0/1 and the number of attack packets does not increase greatly, which can be ignored.) Based on the attacked interface GE0/0/0, locate the attack source user, and use antivirus software to rectify the fault.
    • If the attack source user cannot be located, configure an ACL rule to filter out Layer 2 ARP traffic on GE0/0/0 to deny the packets with the source MAC address yyyy-yyyy-yyyy.
      [Huawei] acl number 4444 
[Huawei-acl-L2-4444] rule 5 deny l2-protocol arp source-mac yyyy-yyyy-yyyy  
[Huawei] interface gigabitethernet 0/0/0 
[Huawei-GigabitEthernet0/0/0] traffic-filter inbound acl 4444 
[Huawei-GigabitEthernet0/0/0] quit 
[Huawei] quit
    • Alternatively, configure static ARP on the AR to bind the IP address y.y.y.y to a nonexistent MAC address to prevent ARP attacks. For details, see Can Static ARP Implement Binding of IP Addresses and MAC Addresses.
      <Huawei> system-view 
[Huawei] arp static y.y.y.y zzzz-zzzz-zzzz

Session Resources Are Insufficient

Context

When attacks occur on the network, the AR receives a large amount of abnormal traffic, which will quickly exhaust its session and block memory resources. As a result, other users may fail to access the Internet because they are not allocated with session and block memory resources. In this case, check whether the AR's session and block memory resources are sufficient.

Troubleshooting Procedure

  1. Run the display logbuffer command to check the log buffer for logs indicating that the session and block memory resources are overloaded.

    <Huawei> display logbuffer 
Logging buffer configuration and contents: enabled                               
Allowed max buffer size: 1024                                                    
Actual buffer size: 512                                                          
Channel number: 4, Channel name: logbuffer                                       
Dropped messages: 0                                                              
Overwritten messages: 167                                                        
Current messages: 512  
Mar  5 2021 15:47:25+08:00 Huawei %%01FORWARD/4/SESSION-RES-LACK(l)[135]:The device session resources were overloaded.(Usage = 94%) 
Mar  5 2021 16:29:25+08:00 Huawei %%01FORWARD/4/CAP-BLOCK-RES-LACK(l)[259]:The block memory resources were overloaded.(Usage = 97%) 
Mar  5 2021 16:34:25+08:00 Huawei %%01FORWARD/4/SESSION-RES-LACK(l)[261]:The device session resources were overloaded.(Usage = 92%) 
Mar  5 2021 16:43:25+08:00 Huawei %%01FORWARD/4/CAP-BLOCK-RES-LACK(l)[273]:The block memory resources were overloaded.(Usage = 96%)

  2. Enter the diagnostic view and run the display session statistics top 10 order-by source-ip command to collect session statistics about top 10 users based on their source IP addresses. If a large number of sessions are established by the private network interface (the source IP address is the IP address of the private network interface), you are advised to modify the ACL rule bound to the outbound NAT policy configured on the private network interface to permit only packets from private network segments and then delete these sessions.

    <Huawei> system-view 
[Huawei] diagnose 
[Huawei-diagnose] display session statistics top 10 order-by source-ip 
Session statistic top 10 (Condition: Source IP, Service: SESSION, Items: 10, Total Sessions: 17810) 
------------------------------------------------------------------------------------------------- 
TOP-N     IP/Port                       Counts              Percentage(%)        
------------------------------------------------------------------------------------------------- 
1         x.x.x.x                       16096               90.376193            
2         192.168.1.2                   1279                7.181359             
3         192.168.1.144                 106                 0.595171  
[Huawei-diagnose] quit   
[Huawei] interface GigabitEthernet 0/0/1 
[Huawei-GigabitEthernet0/0/1] display this 
# 
tcp adjust-mss 1200 
ip address x.x.x.x 255.255.255.252 
nat outbound 2999 
# 
[Huawei-GigabitEthernet0/0/1] quit

    Delete the original ACL rule and reconfigure a rule to allow only users in the private network segment 192.168.1.0/24 to access the Internet. Then, delete sessions.

    [Huawei] acl name GigabitEthernet0/0/1 2999   
[Huawei-acl-basic-2999] display this 
# 
rule 5 permit 
# 
[Huawei-acl-basic-2999] undo rule 5 
[Huawei-acl-basic-2999] rule permit source 192.168.1.0 0.0.0.255  
[Huawei-acl-basic-2999] quit  
[Huawei] reset nat session all  
Warning:The current all NAT sessions will be deleted.  
Are you sure to continue?[Y/N] y

  3. If a large number of sessions are established by private network users (source IP addresses of the sessions are the IP addresses of private network users), run the display session statistics top 10 order-by destination-port command to check port numbers of these sessions. In this example, private network users establish a large number of sessions with destination port numbers 445 and 1433. In this case, you are advised to configure an ACL rule on the private network interface to deny the traffic with destination port numbers 445 and 1433.

    <Huawei> system-view 
[Huawei] diagnose 
[Huawei-diagnose] display session statistics top 10 order-by source-ip 
Session statistic top 10 (Condition: Source IP, Service: SESSION, Items: 10, Total Sessions: 25768) 
------------------------------------------------------------------------------------------------- 
TOP-N     IP/Port                       Counts              Percentage(%)        
------------------------------------------------------------------------------------------------- 
1         192.168.1.99                  19714               76.505744            
2         192.168.1.88                  5988                23.238125            
3         192.168.1.165                 9                   0.034927    
[Huawei-diagnose] display session statistics top 10 order-by destination-port 
Session statistic top 10 (Condition: Destination Port, Service: SESSION, Items: 10, Total Sessions: 25768) 
------------------------------------------------------------------------------------------------- 
TOP-N     IP/Port                       Counts              Percentage(%)        
------------------------------------------------------------------------------------------------- 
1         445                           15486               60.097796            
2         1433                          9565                37.119683            
3         3389                          648                 2.514747 
[Huawei-diagnose] quit   
[Huawei] interface GigabitEthernet 0/0/0 
[Huawei-GigabitEthernet0/0/0] display this 
# 
ip address 192.168.1.255 255.255.255.0 
# 
[Huawei-GigabitEthernet0/0/0] quit

    Bind the ACL rule to a traffic policy and apply the traffic policy to the private network interface, so that the interface denies the traffic with destination port numbers 445 and 1433.

    [Huawei] acl 3000  
[Huawei-acl-adv-3000] rule 20 permit tcp  destination-port eq 445 
[Huawei-acl-adv-3000] rule 25 permit tcp  destination-port eq 1433 
[Huawei-acl-adv-3000] quit 
[Huawei] traffic classifier virus operator or 
[Huawei-classifier-virus] if-match acl 3000 
[Huawei-classifier-virus] quit 
[Huawei] traffic behavior virus 
[Huawei-behavior-virus] deny 
[Huawei-behavior-virus] quit 
[Huawei] traffic policy virus  
[Huawei-trafficpolicy-virus] classifier virus behavior virus  
[Huawei-trafficpolicy-virus] quit 
[Huawei] interface GigabitEthernet 0/0/0 
[Huawei-GigabitEthernet0/0/0] traffic-policy virus outbound 
[Huawei-GigabitEthernet0/0/0] traffic-policy virus inbound 
[Huawei-GigabitEthernet0/0/0] quit

DNS Servers on the Internet Cannot Be Accessed

Context

If DNS servers on the Internet cannot be accessed, users cannot access the Internet. If an AR connects to the Internet through a single link, it is recommended that the DNS server provided by a carrier be used to provide Internet access, thereby improving network stability. In an AR connects to the Internet through multiple carrier links, users may fail to access the Internet due to poor connectivity with the DNS servers provided by carriers. If users cannot access the Internet, check whether DNS servers on the Internet can be properly accessed.

Troubleshooting Procedure

  1. Assume that the AR's outbound interface connected to the private network is GE0/0/0. If AR connects to the Internet through a single link, run the display this command on GE0/0/0 to check whether the DNS server configured on the AR is provided by a carrier.

    <Huawei> system-view 
[Huawei] interface GigabitEthernet 0/0/0 
[Huawei-GigabitEthernet0/0/0] display this 
#  
interface GigabitEthernet0/0/0 
description connect to inside network 
ip address x.x.x.x 255.255.255.248 
dhcp select interface 
dhcp server dns-list y.y.y.y  // The IP address of the DNS server is y.y.y.y. 
#

    If the DNS server is not provided by a carrier, run the dhcp server dns-list ip-address command in the interface view to change the IP address of the DNS server in the interface address pool to the IP address of the DNS server provided by a carrier.

    [Huawei-GigabitEthernet0/0/0] undo dhcp server dns-list all 
[Huawei-GigabitEthernet0/0/0] dhcp server dns-list z.z.z.z  // The IP address of the DNS server provided by a carrier is z.z.z.z. 
[Huawei-GigabitEthernet0/0/0] quit 
[Huawei] quit

  2. If the AR connects to the Internet through multiple carrier links, check whether the Internet access failure is caused by poor connectivity with the DNS servers provided by carriers. Assume that a user uses a PC to access the Internet through links of carriers A and B.

    • Configure the IP address of the DNS server provided by carrier A on the PC, and use the PC to access the Internet through the link of carrier A. Then check whether the Internet access succeeds.
    • Configure the IP address of the DNS server provided by carrier B on the PC, and use the PC to access the Internet through the link of carrier B. Then check whether the Internet access succeeds.

    If the PC cannot access the Internet through one carrier link, change the IP address of the DNS server to 114.114.114.114 on the PC. If the fault persists, contact the carrier.

    If the PC cannot access the Internet through both carrier links, connect the PC directly to a carrier network for Internet access. If the fault persists, contact the carrier.

IP Address Conflicts Occur on the Private Network

Context

If users fail to access the Internet unexpectedly during AR running, check whether an IP address conflict occurs on the network.

Troubleshooting Procedure

  1. Assume that the AR automatically assigns IP addresses to private network users from the address pool on VLANIF 10. Run the display ip pool interface interface-pool-name conflict command to check information about conflicting IP addresses in the interface address pool.

    <Huawei> display ip pool interface Vlanif10 conflict 
  Pool-name        : Vlanif10 
  Pool-No          : 1 
  Lease            : 1 Days 0 Hours 0 Minutes 
 …… 
Client-ID format as follows: 
   DHCP  : mac-address                 PPPoE   : mac-address 
   IPSec : user-id/portnumber/vrf      PPP     : interface index 
   L2TP  : cpu-slot/session-id         SSL-VPN : user-id/session-id 
  ---------------------------------------------------------------- 
  Index              IP             Client-ID    Type       Left   Status 
  ---------------------------------------------------------------- 
   109      192.168.10.20           -        -         -    Conflict      
----------------------------------------------------------------

  2. After finding a conflicting IP address, locate the MAC address mapping this IP address so as to locate the terminal and change its IP address. The following methods are available for you to locate the MAC address of the terminal with a conflicting IP address.

    • The AR records IP-MAC mappings for terminals it has learned as its ARP entries, including the terminals with conflicting IP addresses. Run the display arp command on the AR to check ARP entries to find the MAC address mapping the conflicting IP address.
      <Huawei> display arp                                                            
IP ADDRESS      MAC ADDRESS     EXPIRE(M) TYPE        INTERFACE   VPN-INSTANCE  
                                    VLAN/CEVLAN(SIP/DIP)      PVC               
------------------------------------------------------------------------------  
10.10.10.1      xxxx-xxxx-xxxx            I -         GE0/0/5                   
10.10.10.214    yyyy-yyyy-yyyy  4         D-0         GE0/0/5                    
……                   
192.168.10.20   zzzz-zzzz-zzzz            I -         GE0/0/3
    • If the corresponding ARP entry is aged and no related information is found, check logs about IP address conflicts. Run the display logbuffer command to view log information recorded in the log buffer. Search for AM/4/IPCONFLICTDTC in the log buffer to find the MAC address mapping the conflicting IP address.
      <Huawei> display logbuffer                                                       
Logging buffer configuration and contents: enabled                              
Allowed max buffer size: 1024                                                   
Actual buffer size: 512                                                         
Channel number: 4, Channel name: logbuffer                                      
Dropped messages: 0                                                             
Overwritten messages: 3315                                                      
Current messages: 512                                                           

Apr  3 2020 13:46:15+00:00 Huawei %%01DEFD/4/CPCAR_DROP_MPU(l)[0]:Some packets a
re dropped by cpcar on the MPU. (Packet-type=arp-request, Drop-Count=14428)     
Apr  3 2020 13:36:15+00:00 Huawei %%01DEFD/4/CPCAR_DROP_MPU(l)[1]:Some packets a
re dropped by cpcar on the MPU. (Packet-type=arp-request, Drop-Count=16593)     
Apr  3 2020 13:26:15+00:00 Huawei %%01DEFD/4/CPCAR_DROP_MPU(l)[2]:Some packets a
re dropped by cpcar on the MPU. (Packet-type=arp-request, Drop-Count=922)
……

Some Web Pages Fail to Load Due to Packet Fragmentation

Context

If some web pages are slow or fail to load, Internet access failures may be caused by web page issues or improper packet fragmentation. If no user can access the web pages, the fault is caused by web page issues. If some users can access the web pages but others cannot, there is a high probability that the fault is caused by improper packet fragmentation. In this case, modify the packet fragmentation configuration.

Troubleshooting Procedure

  1. Run the display ip interface brief command to check whether the public network interface is a physical interface or a dialer interface.

    <Huawei> display ip interface brief 
*down: administratively down                                                     
^down: standby                                                                   
(l): loopback                                                                    
(s): spoofing                                                                    
(E): E-Trunk down     
The number of interface that is UP in Physical is 2                              
The number of interface that is DOWN in Physical is 3                            
The number of interface that is UP in Protocol is 2                              
The number of interface that is DOWN in Protocol is 3                            
 
Interface                         IP Address/Mask      Physical   Protocol       
Atm0/0/0                          unassigned           down       down           
Bridge-if10                       unassigned           down       down           
MFR0/0/1                          unassigned           down       down           
NULL0                             unassigned           up         up(s)          
GE0/0/1                           x.x.x.x/24           up         up

  2. If the public network interface is a physical interface, run the tcp adjust-mss command in the physical interface view to set the maximum segment size (MSS) of TCP packets on the interface. The recommended value is 1200 bytes.

    <Huawei> system-view 
[Huawei] interface GigabitEthernet 0/0/1 
[Huawei-GigabitEthernet0/0/1] tcp adjust-mss 1200  
[Huawei-GigabitEthernet0/0/1] quit

  3. If the public network interface is a dialer interface, run the tcp adjust-mss command in the dialer interface view to set the MSS of TCP packets on the interface. The recommended value is 1200 bytes. Then, run the mtu command to set the maximum transmission unit (MTU) of the interface to 1492 bytes. For a dialer interface, the adjust-mss and mtu values cannot be the same.

    [Huawei] interface Dialer 0 
[Huawei-Dialer0] tcp adjust-mss 1200 
[Huawei-Dialer0] mtu 1492 
[Huawei-Dialer0] restart 
[Huawei-Dialer0] quit 
[Huawei] quit

The ACL Rule Configuration Is Incorrect

Context

Whether a user can access the Internet depends on whether the ACL rule bound to the NAT policy configured on the public network interface of the AR permits Internet access traffic originated from the user's IP address. If not, the user cannot access the Internet. In normal cases, the permit action is defined in ACL rules. ACL rules with the deny action defined need to be configured only when Internet access of a specified user needs to be restricted. If a user cannot access the Internet, check whether the user's IP address is added to an ACL rule with the deny action defined.

Before checking ACL rules, run the display nat session command to check whether the NAT mapping table contains NAT session entries with the user's IP address. If not, no NAT entry has been created and the ACL rule is incorrectly configured. In this case, perform operations in this section. If such session entries are found, NAT entries have been successfully created and the ACL rule is correctly configured. In this case, skip this section.

Troubleshooting Procedure

  1. Run the display this command in the public network interface view to check the ACL bound to the NAT policy configured on the public network interface.

    <Huawei> system-view 
[Huawei] interface GigabitEthernet 0/0/1 
[Huawei-GigabitEthernet0/0/1] display this 
# 
tcp adjust-mss 1200 
ip address x.x.x.x 255.255.255.252 
nat outbound 2999 
# 
[Huawei-GigabitEthernet0/0/1] quit

  2. Enter the ACL view and run the undo rule command to delete the ACL rule with the deny action defined.

    [Huawei] acl name GigabitEthernet0/0/1 2999   
[Huawei-acl-basic-2999] display this 
# 
rule 5 deny source 192.168.1.0 0.0.0.255     
rule 6 permit source 192.168.2.0 0.0.0.255   
# 
[Huawei-acl-basic-2999] undo rule 5 
[Huawei-acl-basic-2999] quit 
[Huawei] quit

The Public Network Interface Is in Abnormal State

Context

If the public network interface works abnormally, users cannot access the Internet. When the Ethernet cable is installed improperly, the interface status indicator is off or blinks abnormally, check whether the interface on the AR connecting to the Internet works normally.

Troubleshooting Procedure

  1. Assume that the AR is connected to the Internet through GE0/0/1. Run the display interface command to check whether GE0/0/1 is Up, whether the duplex mode of GE0/0/1 is full-duplex in auto-negotiation mode, and whether the IP address of GE0/0/1 is correct.

    <Huawei> display interface GigabitEthernet 0/0/1 
GigabitEthernet0/0/1 current state : UP  
Line protocol current state : UP  
Last line protocol up time : 2016-08-17 16:53:19  
Description:HUAWEI, AR Series, GigabitEthernet0/0/1 Interface  
Route Port,The Maximum Transmit Unit is 1500  
Internet Address is x.x.x.x/24  
P Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 7054-f594-1ae6  
Last physical up time: 2016-08-17 16:53:19  
Last physical down time : 2016-08-17 15:46:29  
Current system time: 2016-08-18 15:36:56  
Port Mode: COMMON COPPER  
Speed : 1000,Loopback: NONE  
Duplex: FULL,Negotiation: ENABLE  
Mdi: AUTO,Clock: -

  2. Perform the following operations based on the interface check result:

    • If the interface does not go Up, check whether the Ethernet cable is properly connected and check the link connectivity.
    • Replace the Ethernet cable with a functioning one and reconnect it.
    • If the interface IP address is incorrect, configure the correct IP address for the interface.
    • If the duplex mode of the interface in auto-negotiation mode is half-duplex, run the auto duplex full command to change the duplex mode to full-duplex.
      <Huawei> system-view                                                       
[Huawei] interface GigabitEthernet 0/0/1
[Huawei-GigabitEthernet0/0/1] auto duplex full
[Huawei-GigabitEthernet0/0/1] quit
[Huawei] quit

  3. If the fault persists after the preceding operations, a hardware default may occur. Replace the AR with a new one.

There Are No Reachable Routes Between the AR and Internet

Context

If the AR cannot communicate with the Internet, users cannot access the Internet. In this case, check whether there are reachable routes between the AR and Internet.

Troubleshooting Procedure

  1. Run the display ip routing-table command to check whether the AR has the default route with the destination IP address 0.0.0.0 and pointing to the ISP gateway or a dialer interface (in the PPPoE scenario).

    <Huawei> display ip routing-table 0.0.0.0 
Route Flags: R - relay, D - download to fib   
--------------------------------------------------------------------- 
Routing Table : Public   
Summary Count : 1   
Destination/Mask Proto  Pre  Cost Flags NextHop  Interface   
       0.0.0.0/0 Static 60   0    RD    y.y.y.y  GigabitEthernet0/0/0

  2. If the routing table does not contain the default route, run the display current-configuration | include ip route command to check whether the default route is configured.

    <Huawei> display current-configuration | include route-static
    • If the default route is not found, it may be incorrectly deleted. In this case, run the ip route-static command to configure the default route.
      <Huawei> system-view
[Huawei] ip route-static 0.0.0.0 0.0.0.0 y.y.y.y
    • If the default route is configured but the corresponding routing entry is not generated, check whether the physical status of the outbound interface is Up. If not, locate and troubleshoot the fault. If the outbound interface of the route is a dialer interface, ensure that the dialer interface is Up.
    • If the default route is configured but the next hop is a private IP address instead of a public IP address, the default route is incorrectly configured. Run the undo ip route-static command to delete the default route.

  3. If equal-cost routes exist, run the ip load-balance hash src-ip command to configure load balancing based on source IP addresses and ensure that the bandwidth difference between the two links is not too large. If the bandwidth difference is too large, the link with higher bandwidth is recommended as the default route.

    [Huawei] ip load-balance hash src-ip 
[Huawei] quit

The Dialer Interface Status Is Abnormal After a Dial-up Failure

Context

In a multi-link PPPoE dial-up scenario, if dial-up on one PPPoE link fails, Internet access traffic of users is switched to another normal link for forwarding. However, if the dialer interface corresponding to the faulty link does not go Down, the default route of the dialer interface continues to take effect and Internet access traffic of users will not be switched to a normal link for forwarding. As a result, users fail to access the Internet. In this case, check the status of the dialer interface corresponding to the link where the dial-up failure occurs.

Troubleshooting Procedure

  1. Run the display ip interface brief command to check brief information about dialer interfaces, including their IP addresses, subnet masks, as well as the physical link status and protocol status (Up or Down).

    <Huawei> display ip interface brief 
*down: administratively down                                                     
^down: standby                                                                   
(l): loopback                                                                    
(s): spoofing                                                                    
(E): E-Trunk down     
The number of interface that is UP in Physical is 2                              
The number of interface that is DOWN in Physical is 3                            
The number of interface that is UP in Protocol is 2                              
The number of interface that is DOWN in Protocol is 3                            
 
Interface                         IP Address/Mask      Physical   Protocol   
Dialer1                           unassigned           up         up(s)      
Dialer2                           100.64.40.165/32     up         up(s)

  2. Run the display ip routing-table command to check IPv4 routing entries.

    <Huawei> display ip routing-table 
Route Flags: R - relay, D - download to fib, T - to vpn-instance 
------------------------------------------------------------------------------ 
Routing Tables: Public 
         Destinations : 31       Routes : 32        
 
Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface 
 
        0.0.0.0/0   Static  60   0           D   0.0.0.0         Dialer1 
                    Static  60   0           D   100.64.40.165   Dialer2

  3. According to the information obtained in step 1 and step 2, although Dialer1 fails to dial up and is not assigned an IP address, its physical link status and protocol status are both Up. As a result, the route of Dialer1 is still valid. In this case, you are advised to run the dialer number 1 autodial command on each dialer interface to enable the dialer interfaces to automatically go Down upon dial-up failures.

    <Huawei> system-view 
[Huawei] interface dialer 1 
[Huawei-Dialer1] dialer number 1 autodial 
[Huawei-Dialer1] quit 
[Huawei] quit

Typical Troubleshooting Cases

An AR Is Disconnected from the Wired Network Every Several Minutes

Fault Symptom

An AR is deployed as the egress gateway. When users access the Internet through a wired network, they are disconnected from the Internet every several minutes. More than 20 users are connected to the Internet through the AR, which is far less than the maximum supported by the AR.

Cause Analysis

  • Abnormal traffic exists on the private network. As a result, the session and block memory resource usage of the AR reaches the thresholds, and no session and block memory resources can be allocated for users to access the Internet. Although the AR periodically reclaims session and block memory resources, the resources are exhausted quickly again due to heavy abnormal traffic. As a result, users are frequently disconnected from the Internet.
  • If the device temperature or CPU usage is too high, wired Internet access may be interrupted frequently. In this case, take measures to reduce the device temperature or CPU usage.
  • If the device's system software version is too early, Internet access may be intermittently interrupted. In this case, upgrade the system software version.

Troubleshooting Procedure

  1. Run the display logbuffer command to check the log buffer for logs indicating that the session and block memory resources are overloaded.

    <Huawei> display logbuffer 
Logging buffer configuration and contents: enabled                               
Allowed max buffer size: 1024                                                    
Actual buffer size: 512                                                          
Channel number: 4, Channel name: logbuffer                                       
Dropped messages: 0                                                              
Overwritten messages: 167                                                        
Current messages: 512  
Mar  5 2021 15:47:25+08:00 Huawei %%01FORWARD/4/SESSION-RES-LACK(l)[135]:The device session resources were overloaded.(Usage = 94%) 
Mar  5 2021 16:29:25+08:00 Huawei %%01FORWARD/4/CAP-BLOCK-RES-LACK(l)[259]:The block memory resources were overloaded.(Usage = 97%) 
Mar  5 2021 16:34:25+08:00 Huawei %%01FORWARD/4/SESSION-RES-LACK(l)[261]:The device session resources were overloaded.(Usage = 92%) 
Mar  5 2021 16:43:25+08:00 Huawei %%01FORWARD/4/CAP-BLOCK-RES-LACK(l)[273]:The block memory resources were overloaded.(Usage = 96%)

  2. Enter the diagnostic view and run the display session statistics top 10 order-by source-ip command to collect session statistics about top 10 users based on their source IP addresses. If a large number of sessions are established by private network users (source IP addresses of the sessions are the IP addresses of private network users), run the display session statistics top 10 order-by destination-port command to check port numbers of these sessions. In this example, private network users establish a large number of sessions with destination port numbers 445 and 1433. In this case, you are advised to configure an ACL rule on the private network interface to deny the traffic with destination port numbers 445 and 1433.

    <Huawei> system-view 
[Huawei] diagnose 
[Huawei-diagnose] display session statistics top 10 order-by source-ip 
Session statistic top 10 (Condition: Source IP, Service: SESSION, Items: 10, Total Sessions: 25768) 
------------------------------------------------------------------------------------------------- 
TOP-N     IP/Port                       Counts              Percentage(%)        
------------------------------------------------------------------------------------------------- 
1         192.168.1.99                  19714               76.505744            
2         192.168.1.88                  5988                23.238125            
3         192.168.1.165                 9                   0.034927    
[Huawei-diagnose] display session statistics top 10 order-by destination-port 
Session statistic top 10 (Condition: Destination Port, Service: SESSION, Items: 10, Total Sessions: 25768) 
------------------------------------------------------------------------------------------------- 
TOP-N     IP/Port                       Counts              Percentage(%)        
------------------------------------------------------------------------------------------------- 
1         445                           15486               60.097796            
2         1433                          9565                37.119683            
3         3389                          648                 2.514747 
[Huawei-diagnose] quit   
[Huawei] interface GigabitEthernet 0/0/0 
[Huawei-GigabitEthernet0/0/0] display this 
# 
ip address 192.168.1.255 255.255.255.0 
# 
[Huawei-GigabitEthernet0/0/0] quit

    Bind the ACL rule to a traffic policy and apply the traffic policy to the private network interface, so that the interface denies the traffic with destination port numbers 445 and 1433.

    [Huawei] acl 3000  
[Huawei-acl-adv-3000] rule 20 permit tcp  destination-port eq 445 
[Huawei-acl-adv-3000] rule 25 permit tcp  destination-port eq 1433 
[Huawei-acl-adv-3000] quit 
[Huawei] traffic classifier virus operator or 
[Huawei-classifier-virus] if-match acl 3000 
[Huawei-classifier-virus] quit 
[Huawei] traffic behavior virus 
[Huawei-behavior-virus] deny 
[Huawei-behavior-virus] quit 
[Huawei] traffic policy virus  
[Huawei-trafficpolicy-virus] classifier virus behavior virus  
[Huawei-trafficpolicy-virus] quit 
[Huawei] interface GigabitEthernet 0/0/0 
[Huawei-GigabitEthernet0/0/0] traffic-policy virus outbound 
[Huawei-GigabitEthernet0/0/0] traffic-policy virus inbound 
[Huawei-GigabitEthernet0/0/0] quit

  3. Run the display temperature all command to check the temperature of each card on the device. If the Status field is displayed ABNORMAL, the temperature is too high and the corresponding card may be faulty. In this case, rectify the fault by referring to Why Is a High Temperature Alarm (ENTITYBRDTEMPALARM) Generated and How Can This Alarm Be Cleared?

    <Huawei> display temperature all                                                                                                    
---------------------------------------------------------------------------     
 Slot  Card  Sensor No.  SensorName          Status    Upper  Lower  Temp(C)    
---------------------------------------------------------------------------     
 1     -     1           2FE TEMP            NORMAL    75     0      40         
 2     -     1           1SA TEMP            NORMAL    74     0      53         
 3     -     1           1CPOS-155M TEMP     ABNORMAL  90     0      -         
 4     -     1           1ADSL-A/M TEMP      NORMAL    70     0      49         
 5     -     1           8FE1GE TEMP         NORMAL    85     0      57         
 8     -     1           1STM4 TEMP          NORMAL    74     0      39

  4. Run the display cpu-usage command to check CPU usage statistics. Generally, the system CPU usage is within the normal range when the following conditions are met:

    • The CPU usage does not exceed 80% when the system runs for a long period.
    • The CPU usage does not exceed 95% for a short period and does not increase continuously.
    • No high CPU usage alarm is generated.

    If the CPU usage exceeds 80% and a high CPU usage alarm is generated, rectify the fault by referring to What Can I Do If the CPU Usage Is High?

    <Huawei> display cpu-usage
CPU   Usage Stat. Cycle: 10 (Second)                                            
CPU   Usage Stat. Time : 2013-09-24  10:11:55                                   
Control Plane              
    CPU Usage: 23.3%   Max: 100%                                                
    User: 10.7%   System:  6.9%   SoftIrq:  0.0%   HardIrq:  5.5%   Idle: 76.7% 

    CPU utilization for ten seconds: 23.3%  one minute:  22.0%  five minutes:  2
3.0% .                     
Data    Plane              
    CPU Usage:  1.7%   Max: 100%                                                
    CPU utilization for ten seconds:  1.7%  one minute:   1.6%  five minutes:   
1.6% .                     

PID   ProcessName         CPU%     CoreIndex      Runtime     State             
194   cap32               1.7%      CPU1           26132042    R                
193   vrp                20.0%      CPU0           11216335    S 
......

  5. Run the display version command to check the device's system software version. If the version is too early, log in to Huawei technical support website to download the system software of the latest version and upgrade the device. Take the AR6120 as an example. Choose Routers > Access Routers > AR6000 Series > AR6120 > Software Download, and download the system software of the recommended version.

    <Huawei> display version
Huawei Versatile Routing Platform Software
VRP (R) software, Version 5.120 (AR6300 V300R021C00)
Copyright (C) 2011-2012 HUAWEI TECH CO., LTD
Huawei AR6300 Router uptime is 0 week, 1 day, 5 hours, 10 minutes
BKP 0 version information:
1. PCB      Version  : AR01BAK2B VER.A
2. If Supporting PoE : No
3. Board    Type     : AR6300
4. MPU Slot Quantity : 1
5. LPU Slot Quantity : 8

MPU 11(Master) : uptime is 0 week, 1 day, 5 hours, 10 minutes
SDRAM Memory Size    : 2048    M bytes
Flash Memory Size    : 16      M bytes
NVRAM Memory Size    : 512     K bytes
SD Card1 Memory Size : 1882    M bytes
MPU version information :
1. PCB      Version  : AR01SRU3A VER.B
2. MAB      Version  : 0
3. Board    Type     : SRU-400H
4. CPLD0    Version  : 104
......

Users Fail to Access Some Web Pages

Fault Symptom

When users access the Internet, some web pages are slow or fail to load.

Cause Analysis

There is a high probability that this fault is caused by improper packet fragmentation.

Troubleshooting Procedure

  1. Run the display ip interface brief command to check whether the public network interface is a physical interface or a dialer interface.

    <Huawei> display ip interface brief 
*down: administratively down                                                     
^down: standby                                                                   
(l): loopback                                                                    
(s): spoofing                                                                    
(E): E-Trunk down     
The number of interface that is UP in Physical is 2                              
The number of interface that is DOWN in Physical is 3                            
The number of interface that is UP in Protocol is 2                              
The number of interface that is DOWN in Protocol is 3                            
 
Interface                         IP Address/Mask      Physical   Protocol       
Atm0/0/0                          unassigned           down       down           
Bridge-if10                       unassigned           down       down           
MFR0/0/1                          unassigned           down       down           
NULL0                             unassigned           up         up(s)          
GE0/0/1                           x.x.x.x/24           up         up

  2. If the public network interface is a physical interface, run the tcp adjust-mss command in the physical interface view to set the MSS of TCP packets on the interface. The recommended value is 1200 bytes.

    <Huawei> system-view 
[Huawei] interface GigabitEthernet 0/0/1 
[Huawei-GigabitEthernet0/0/1] tcp adjust-mss 1200  
[Huawei-GigabitEthernet0/0/1] quit

  3. If the public network interface is a dialer interface, run the tcp adjust-mss command in the dialer interface view to set the MSS of TCP packets on the interface. The recommended value is 1200 bytes. Then, run the mtu command to set the MTU of the interface to 1492 bytes.

    [Huawei] interface Dialer 0 
[Huawei-Dialer0] tcp adjust-mss 1200 
[Huawei-Dialer0] mtu 1492 
[Huawei-Dialer0] restart 
[Huawei-Dialer0] quit 
[Huawei] quit

Wireless Users Can Access the Internet but Wired Users Cannot After PPPoE Dial-up Is Used for Internet Access

Fault Symptom

An AR is deployed as the egress gateway, and the Internet access service is normal. Due to service requirements, PPPoE dial-up is used for Internet access. After that, wireless users can access the Internet but wired users cannot.

Cause Analysis

The mtu and tcp adjust-mss parameters are set to the same value on the dialer interface. As a result, PPPoE dial-up fails and users cannot access the Internet.

Troubleshooting Procedure

  1. Run the display this command in the dialer interface view and check the values of the mtu and tcp adjust-mss parameters.

    <Huawei> system-view 
[Huawei] interface dialer 1 
[Huawei-Dialer1] display this 
# 
link-protocol ppp 
ppp chap user aaaaaaaaaa 
ppp chap password cipher %@%@B`)sN)(^6*fNn=T,"9uK,eE%%@%@ 
ppp pap local-user aaaaaaaaaa password cipher %@%@B`)sN)(^6*fNn=T,"9uK,eE%%@%@ 
ppp ipcp dns admit-any 
ppp ipcp dns request 
mtu 1200 
tcp adjust-mss 1200 
ip address ppp-negotiate 
dialer user arweb 
dialer bundle 1 
dialer-group 1 
nat outbound 2998 
#

  2. Run the undo mtu command to restore the default MTU of the dialer interface. Then restart the dialer interface.

    [Huawei-Dialer1] undo mtu 
[Huawei-Dialer1] restart 
[Huawei-Dialer1] quit 
[Huawei] quit

Users in a Network Segment Cannot Access the Internet

Fault Symptom

An enterprise deploys an AR as the egress gateway. The network administrator finds that users in a continuous network segment cannot access the Internet, but users in other network segments can access the Internet normally.

Cause Analysis

Internet access requests originated from IP addresses in the network segment 192.168.1.0/24 are denied by the ACL rule bound to the NAT policy configured on the public network interface of the AR. As a result, all users in this network segment cannot access the Internet.

Troubleshooting Procedure

  1. Run the display this command in the public network interface view to check the ACL bound to the NAT policy configured on the public network interface.

    <Huawei> system-view 
[Huawei] interface GigabitEthernet 0/0/1 
[Huawei-GigabitEthernet0/0/1] display this 
# 
tcp adjust-mss 1200 
ip address x.x.x.x 255.255.255.252 
nat outbound 2999 
# 
[Huawei-GigabitEthernet0/0/1] quit

  2. Enter the ACL view and run the undo rule command to delete the ACL rule with the deny action defined.

    [Huawei] acl name GigabitEthernet0/0/1 2999   
[Huawei-acl-basic-2999] display this 
# 
rule 5 deny source 192.168.1.0 0.0.0.255     
rule 6 permit source 192.168.2.0 0.0.0.255   
# 
[Huawei-acl-basic-2999] undo rule 5 
[Huawei-acl-basic-2999] quit 
[Huawei] quit

In a Multi-link PPPoE Dial-up Scenario, Users Cannot Access the Internet After Dial-up Fails on One Link

Fault Symptom

An AR is deployed as the egress gateway. To improve stability, users dial up to the Internet through multiple PPPoE links. When dial-up fails on one link, users cannot access the Internet through other links.

Cause Analysis

After dial-up fails on a PPPoE link, the dialer interface corresponding to the link does not go Down and the default route of the dialer interface is still valid. Users' Internet access traffic is still transmitted through the faulty link. As a result, the users fail to access the Internet.

Troubleshooting Procedure

  1. Run the display ip interface brief command to check brief information about dialer interfaces, including their IP addresses, subnet masks, as well as the physical link status and protocol status (Up or Down).

    <Huawei> display ip interface brief 
*down: administratively down                                                     
^down: standby                                                                   
(l): loopback                                                                    
(s): spoofing                                                                    
(E): E-Trunk down     
The number of interface that is UP in Physical is 2                              
The number of interface that is DOWN in Physical is 3                            
The number of interface that is UP in Protocol is 2                              
The number of interface that is DOWN in Protocol is 3                            
 
Interface                         IP Address/Mask      Physical   Protocol   
Dialer1                           unassigned           up         up(s)      
Dialer2                           100.64.40.165/32     up         up(s)

  2. Run the display ip routing-table command to check IPv4 routing entries.

    <Huawei> display ip routing-table 
Route Flags: R - relay, D - download to fib, T - to vpn-instance 
------------------------------------------------------------------------------ 
Routing Tables: Public 
         Destinations : 31       Routes : 32        
 
Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface 
 
        0.0.0.0/0   Static  60   0           D   0.0.0.0         Dialer1 
                    Static  60   0           D   100.64.40.165   Dialer2

  3. According to the information obtained in step 1 and step 2, although Dialer1 fails to dial up and is not assigned an IP address, its physical link status and protocol status are both Up. As a result, the route of Dialer1 is still valid. In this case, you are advised to run the dialer number 1 autodial command on each dialer interface to enable the dialer interfaces to automatically go Down upon dial-up failures.

    <Huawei> system-view 
[Huawei] interface dialer 1 
[Huawei-Dialer1] dialer number 1 autodial 
[Huawei-Dialer1] quit 
[Huawei] quit

Collecting Fault Information

If the issue persists after the preceding steps, collect relevant information and contact technical support personnel.
  1. Collect fault information.
    • Collect all diagnostic information and export the information to a file.

      1. Run the display diagnostic-information file-name command in the user view to collect diagnostic information and save the information to a file.

        <Huawei> display diagnostic-information dia-info.txt
  This operation will take several minutes, please wait.........................
..................................................................              
Info: The diagnostic information was saved to the device successfully..
      2. When the diagnostic file is generated, you can export the file from the device using TFTP, FTP, or SFTP. For details, see Local File Management.

        • You can run the dir command in the user view to check whether the file is generated.

        • You can also run the display diagnostic-information command and save STA logs in a diagnostic file on a disk. For details, see Diagnostic File Obtaining Guide.

        • If this command displays a long output, press Ctrl+C to abort this command.

        • The display diagnostic-information command displays diagnostic information, which helps locate faults but may affect system performance. For example, the CPU usage may become high. Therefore, do not use this command when the system is running properly.

        • Do not run the display diagnostic-information command simultaneously on multiple terminals connected to the device. This is because doing so may significantly increase the CPU usage of the device and deteriorate the device performance.

    • Collect the log and trap information on the device and export the information to files.

      1. Run the save logfile command in the user view to save the log and trap information in the buffer to files.

        <Huawei> save logfile
Info: It may take several seconds,please wait...  
Save log file successfully.
      2. When the diagnostic file is generated, you can export the file from the device using TFTP, FTP, or SFTP. For details, see Local File Management.

        You can also run the display logbuffer and display trapbuffer commands to view the log and trap information on the device, and save STA logs in a diagnostic file on a disk. For details, see Diagnostic File Obtaining Guide.

  2. Seek technical support.

    Click http://e.huawei.com/en/how-to-buy/contact-us to seek technical support.

    Technical support personnel will provide instructions for you to submit all the collected information and files, so that they can locate faults.

Translation
简体中文
Download
Updated: 2022-01-10

Document ID: EDOC1100202979

Views: 4797

Downloads: 36

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Digital Signature File

Digital Signature Authentication Mode
Share
Previous Next
Huawei e+ App Huawei e+

Copyright © 2022 Huawei Technologies Co., Ltd. All rights reserved.

You are going to visit :