National Research and Education Network
Education Cloud Data Center
Multi-Channel HD Telemedicine Solution
Over The Top/Multi-Tenant Data Center (OTT/MTDC)
Internet Exchange Point (IXP)
Internet Access Provider (IAP)
Design & Simulation
Planning & Analytics
Oil & Gas IoT
HPC & Operations Management
Digital Urban Rail
Retail Cloud Platform
Enterprise Data Center
Enterprise Cloud Communications
Network Management System
Buy from Huawei
If you want to get more information about your project, you can submit your information and we will contact you as soon as possible.
If your company has signed an eDeal contract with Huawei, please buy your required product/solution via the link below.
Buy from resellers
Search for a nearby reseller and get direct contact information.
Become a Partner
Resources and Support
Huawei Authorized Learning Partner
Huawei Authorized Information and Network Academy
We confirmed it from transmission expert that while loopback hard test in ODF of transmission side, transmission device will not send any rdi or ais SDH alarm, so the command “alarm lrdi sensitive; alarm prdi sensitive; alarm pais sensitive” will not work so the physical port will be up for router is receiving power from itself through loop. When default encapsulation protocol of POS link layer is HDLC, the line protocol can be up even looping with hardware device. So the both physical and line protocol status of the two POS ports were up.
Refer to RFC 3036, LDP Specification, LHR-NE80E-B1 is active; it attempts to establish the LDP TCP connection by connecting to the well-known LDP port at address LHR-NE40E-A1. LHR-NE40E-A1 is passive; it waits for LHR-NE80E-B1 to establish the LDP. (LSR1 determines whether it will play the active or passive role in session establishment by comparing addresses A1 and A2 unsigned integers. If A1 > A2, LSR1 plays the active role; otherwise it is passive, it waits for LSR2 to establish the LDP TCP connection to its well-known LDP port.) So we found many LDP establishing logs in LHR-NE80E-B1 but no such logs in LHR-NE40E-A1.
These LDP establishing tries continued until ip-trunk shutdown activity because the both physical and line protocol status of the two POS ports were up and LDP protocol packets were hashed to this link always. These LDP establishing tries failed because the communication between the two LDP peers was down actually due to loopback hard test.
A. PPP and HDLC are different and line protocol can not be up in the situation of last day so LDP would not try to establish peer in that pos interface otherwise shift to other good pos of ip-trunk.
PPP from Physical UP to Line Protocol UP need the below 3 steps：
3.Network layer negotiate(IPCP、IPXCP).
Any failure in any step will cause negotiate fail. While LCPU negotiate, including MRU, magic number, Authenticate mode and etc. If loopback detected, magic number checking mechanism will find loop then cause LCP negotiate fail and line protocol of PPP can not be up at last.
But maybe you can find line protocol of PPP is up for several seconds and down for ever if you lucky because it's during negotiate.
B. LDP module of NE80E/40E doesn't have the check list that if loopback detected, so physical up and line protocol up will let LDP trust the pos is fine.
C. The traffic hadn't been shifted in that pos during loopback test. There are two planes in NE40E/80E, one is control plane (such as ISIS) which control if give the command to reroute the traffic, another is forward plane (such as MPLS LDP) which is used to forward traffic (mpls label switch). So at that moment, control plane is ok but forward plane is down, control plane though ip-trunk 4 is ok but actually forward plane is down. So traffic was discarded and blocked.