Tag Archives: Huawei CLI

display this

Very useful and very often used command on Huawei’s devices. You can use it in any view. Any time you configure something, you can use it to check what you have configured. If you set parameters, that are the same with the default ones, these parameters will not be displayed. Anyway “display current-configuration” does not also show the default parameters.

Example 1 (interface view):

[NE-GigabitEthernet1/0/1]display this
#
interface GigabitEthernet1/0/1
 description test
 undo shutdown
 ip address 10.1.1.1 255.255.255.252
 isis enable 1
 isis circuit-type p2p
 isis circuit-level level-2
 isis cost 100
 isis bfd enable
 mpls
 mpls te
 mpls rsvp-te
 mpls rsvp-te hello
#
return

reset saved-configuration

If you need to reconfigure a Huawei device and do not want to delete its configuration line by line, it is the fastest way to restore the device to the default configuration. Reset saved-configuration command does not delete the existing configuration file in storage device. It is required to restart the device to activate changes. Before reboot, the device compares the configuration file to be loaded at the next startup and existing file to be deleted. Finally the device:

• loads the default configuration if both files are the same
• deletes the configuration file in use if they are different
• displays a message indicating that the configuration file does not exist if the configuration file to be deleted does not exist

<labnario> reset saved-configuration
The action will delete the saved configuration in the device.
The configuration will be erased to reconfigure. Continue? [Y/N]: y

Which configuration file is set as the “next startup saved-configuration file” you can check by the following command:

BFD process-interface-status and process-pst are applicable only for single-hop BFD. Let’s assume that we have two routers directly connected through interface GE1/0/0.

process-interface-status

By associating BFD session status with interface status we can trigger fast route convergence. We can use this function only for BFD session that uses a default multicast IP address to detect the single-hop link. We can use association between BFD session status and interface status in the case, when transport devices exist on the link between the routers. As the actual physical path is segmented by transport devices, the routers on both ends need a long time to detect a fault that occurred on the link. The change of BFD status affects the protocol status of the interface and thus fast convergence is triggered. When the BFD session becomes DOWN, the correspondence interface status also goes to BFD_DOWN state, causing that this direct route is deleted from the routing table but the router can still forward BFD packets.

[Labnario] bfd
[Labnario-bfd] quit
[Labnario] bfd test bind peer-ip default-ip interface gigabitethernet 1/0/0
[Labnario-bfd-session-test] discriminator local 1
[Labnario-bfd-session-test] discriminator remote 2
[Labnario-bfd-session-test] process-interface-status
[Labnario-bfd-session-test] commit

I have been describing Huawei datacom devices on my blog since July 2011. I started with some basic information about Huawei CLI, access methods and upgrade procedures. Then I showed you more advanced topics like PBR, DHCP etc. I am pleasantly surprised that this blog is visited by people from all continents, even from countries I have never heard about. As this blog is getting more and more popular I will do my best to publish more interesting posts.

As we went through a some stage, I have decided to prepare a cheat sheet describing Huawei CLI. You can download it as PDF, print and keep it :). I hope it will be useful for you.

BFD (Bidirectional Forwarding Detection)

What to do to quickly establish an alternative path in case of communication failure between adjacent systems?

There are two detection mechanisms:

• Hardware detection, for example alarms in SDH used to detect link faults
• Hello mechanism used by routing protocols.

The main disadvantage of hardware detection is that not all media support it. For example Ethernet does not provide this kind of signalling.

When there is no hardware signalling we can use Hello in routing protocols but this mechanism is relatively slow. Sensitive services, for example voice, cannot work with more than one second delay.

The best solution is to use BFD (Bidirectional Forwarding Detection). This is simple mechanism that works independently of media, data and routing protocols. The main goal of BFD is to detect failures in the path between adjacent devices in a short time (minimum detection time for NE40E is 30ms). It does not matter if it is physical link, virtual circuit, tunnel, MPLS LSP, multi-hop path or unidirectional link. We can treat BFD as a simple Hello protocol where a pair of devices periodically sends BFD packets between them. If one device does not receive BFD packets within specified period, the system assumes that the bidirectional path to the neighboring system has failed.