Tag Archives: NE40E

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?

Some time ago I described how to display electronic labels. As you probably could see, the displayed information looked illegibly, especially for budding engineers.

Starting from V6R6 software of carrier class devices (like Huawei NE40E, CX600), it looks much better. You have all the information at a glance:

<labnario>display elabel brief
Slot     BoardType    BarCode                 Description
================================================================================
LPU 1    CR52LPUF40A  030KWD10AB000351        LPUF-40-A
  PIC 0  CR52L2XXN0   03675210A9000134        P40-2x10GBase LAN/WAN-XFP
  PIC 1  CR52L2XXN0   03675210A9000115        P40-2x10GBase LAN/WAN-XFP
LPU 2    CR52LPUF40A  030KWD10B7000867        LPUF-40-A
  PIC 0  CR52L2XXN0   03675210B7001018        P40-2x10GBase LAN/WAN-XFP
  PIC 1  CR52L2XXN0   03675210B7001188        P40-2x10GBase LAN/WAN-XFP
LPU 3    CR52LPUKD0   030KJY10A8000126        LPUF-21-A
  PIC 0  CR52L1XX0    030GSK10A9002012
  PIC 1  CR52L1XX0    030GSK10B7001228
LPU 7    CR52LPUKD0   030KJY10B1000383        LPUF-21-A
  PIC 0  CR52L1XX0    030GSK10A2001595
  PIC 1  CR52EBGF0    030GSH10B1000971
LPU 8    CR52LPUKD0   030KJY10CC001471        LPUF-21-A
  PIC 0  CR52L1XX0    030GSK10A2001005
  PIC 1  CR52EBGF0    030GSH10B1000795
MPU 9    CR57SRU40A4  030KSR10AA000258        SRUA4-40
MPU 10   CR57SRU40A4  030KSR10AA000175        SRUA4-40
SFU 11   CR57SFU40C0  030KSY10A9000472        SFUI-40-C
SFU 12
SFU 13

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

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.