To have a better experience, please upgrade your IE browser.upgrade
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?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
1. we analysis the service when the link between P1 and P2 down, the TE switch to FRR path ,like P1---P3---P4---P2, the PE node have no effected about the L3VPN service
2.we check the log,when the link down ,the ldp peer got down in P1 and P2 ,so this will caused the LDP LSP down E2E form PE1 to PE2 ,this should be the root cause about the L3VPN down
3.we still had a question, when the PE still had the VRF router, when the LSP down,normally if the LSP down ,the BGP router should be inactive.but in this case the VRF router is ok
4.so we test again ,and made a ping lsp test from PE1 to PE2, and we found the PING lsp is ok ,but the reply ip is the interface ip address in P1 interface which connect to PE1
5.the test show that the PE1 still had the lsp to PE2 ,but the LSP ended in P1, the LSP egress proxy can lead this phenomenon, so we checked the config in P1, lsp trigger-all had configed in the MPLS view
6.at the same time,we found another mistake in P1, the P1 and P2, don`t have remote ldp peer but just a local ldp peer, when the link between P1 and P2 is up,the local LDP peer can be used for ldp over te
but if this link down ,the TE switch to P1--P3---P4---P2, but the local ldp down, so the LDP over TE down
7.we fixed these two mistake, and test again, the service down again, and we confirm the config is ok after we checked the config again and again
8.we checked the log, then we got the root cause, at the beginning the customer shutdown the main port, but they shutdown the sub-interface this time,when they shutdown the sub-interface in P1, the P2 sub-interface
still got up, so the service down ,it must be recover when the RSVP down between P1 and P2, the TE can switch to FRR, but this need two mins
we suggest the customer config BFD for sub-interface and test again ,the service is ok