Tag Archives: Huawei CLI

Very useful command, especially when you are preparing and executing upgrade of a software of Huawei carrier class devices, like NE40E and CX600. Let’s look what can be checked by this command:

<labnario>check ?
  hardware-compatibility  hardware compatibility
  startup                 Check the version of the resource file
  system-software         system-software
  version                 check version

I personally use “check hardware-compatibility” before all planned upgrades. During a preparation phase of an upgrade, you have to read software release notes, to be sure that all software and hardware components will be compatible with the new software. You can check hardware compatibility by the command, instead of searching software documents.

Imagine that you’ve just uploaded a new software to CFcard of a router. The new software is v600r006c00spc300.

<labnario>check hardware-compatibility v600r006c00spc300.cc
Slot#    BoardType        Result           Detail
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3        CR57LAXFB00      Compatible       NA
4        CR57LAXFB00      Compatible       NA
5        CR57EMGFB20      Compatible       NA
6        CR57EMGFB20      Compatible       NA
9        CR57SRU200A5     Compatible       NA
10       CR57SRU200A5     Compatible       NA
11       CR57SFU200C0     Compatible       NA
12       FRA200A          Compatible       NA
13       FRA200A          Compatible       NA

It’s very simple, isn’t it?

Let’s assume that you have U2000 NMS server to monitor Huawei devices. We can manage these devices in 2 ways: outband or inband management. Outband management means that you have a separate DCN network to manage devices. It is commonly used for critical nodes, for example for backbone routers. Unlike to backbone network, it is difficult to implement DCN for mobile backhaul networks, where the number of devices reaches hundreds or even thousands. In such situation inband management is implemented to reduce cost. Then the decision how to send SNMP packets to the NMS server is based on routing protocols. The packets travel through the monitored network and are susceptible to all turbulences, which can appear in the network. This may lead to the fact that some SNMP packets may be lost by the network.

Let’s imagine such case. A link between a router and NMS is “DOWN”. No redundant link is established. The router sends SNMP trap to the NMS server but the server is not available. The SNMP packet is lost. Then the link is going to “UP” state and the router send SNMP trap to U2000. This trap is then dropped by U2000 because there is not related “DOWN” trap, which was lost before.

And what’s next?

U2000 synchronizes alarms with devices every 30 minutes and NMS server receives “DOWN” trap from the router, which was lost earlier. As the clearing trap was dropped, this “DOWN” alarm will not be cleared anymore. Then we have “DOWN” hanging (not cleared) alarm in U2000.

I’ve had only one case when I used this command and … full success.

Sometimes it can happen that the file system doesn’t work properly. When you run dir command, you can find the space, which usage status is unknown. The system prompts you that the file system should be restored. Then you can run fixdisk command to release the unknown space.

Notice that:

• It is not recommended to use it when the file system works correctly.
• It doesn’t help when physical medium is damaged.
• Do not use it when CPU usage is high.

Lost chains in flash detected, please use fixdisk to recover them!
<labnario>fixdisk flash:
Fixdisk flash: will take long time if needed
%Fixdisk flash: completed.

I have never used it but it looks interesting. Arp-ping lets us to check whether a specified IP address or MAC address is being used in a LAN. Intrigued, I opened Huawei eNSP simulator to check this feature. Results are not fully satisfied. As arp-ping IP works correctly, I cannot say the same about arp-ping MAC. There are some problems with communication between router and hosts. It looks like router does not receive ICMP Echo Reply packets from hosts in the LAN. I checked the same between router and switch “labnario_SW2″. Results look promising. Let’s pass on to the lab.

Labnario_RT config:

#
vlan batch 100 200
#
interface Vlanif100
 ip address 10.0.0.100 255.255.255.0 
#
interface Ethernet0/0/0
 port link-type trunk
 port trunk allow-pass vlan 100
#
interface GigabitEthernet0/0/1
 ip address 172.16.0.100 255.255.255.0

I have come across link flapping protection feature recently. It is available on S5700 switches. It looks like it is a new feature on Huawei switches. I had not met it in older hardware versions. That’s why I decided to write a few words about it. Unfortunatelly, although this command is available in Huawei network simulator eNSP, it does not work properly. But maybe you will have possibility check it on your real devices.

Port flapping (port going UP and DOWN continually) can be caused by a faulty cable, link failure, active/standby switchover, port hardware failure, etc. Frequent status changes on an interface can lead to:

• STP topology recalculation and changes,
• ARP entries updates,
• dynamic routing instability and convergence problems.

All these issues can negatively affect switch performance and should be avoided.

Link Flapping Protection is a feature that can be implemented on an interface to solve problems caused by the flapping port or link. It checks the interface flapping frequency and link flapping detection interval. If the number of interface flapping times reaches the limit, in a specified period, the interface is shut down.