Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
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.