This article is about troubleshooting MPLS ldp.
Two devices establish direct-attached LDP neighbors:
R2 and R3.r2 's interface Giga 2/0 and R3 interface to establish the LDP's direct-link neighbors.
First, review the LDP's neighbor establishment process:
LDP utility is the UDP/TCP Port 646来 discovers the neighbor's. So in the future troubleshooting, if the two sides can ping, but can not build a neighbor to check whether the port has been sealed.
This shows all the procedures established by a LDP neighbor.
When the neighbors are established, they will send the hello message at intervals to detect whether the neighbor still exists.
As you can see, the relationship between the Hello message and the LDP neighbor is quite important.
So if two LDP objects are not built up neighbors, the first to be checked is the hello message, in the end, this break sent out hello? Also, does this end receive an end-to-end send to my hello
With commands: Show MPLS LDP discovery
Here we look at two scenarios, the first of which is the normal establishment of MPLS LDP neighbors at both ends.
This column more highlights: http://www.bianceng.cn/Network/basis/
Notice here that the g2/0 interface, the g2/0 of R2, is the LDP, and there are two extremely important parameters, XMit and recv.
XMit said that from g2/0 successfully sent the LDP hello out. Recv indicates that the port was successfully received by the interface g1/0 of the end R3 sent back to Hello.
So now I'm going to put the R3 g1/0 interface shutdown. The result should be that the g2/0 light of the R2 of this end will not receive hello. So if R3 's g1/0 interface is down, R2 above g2/0 only displays xmit and recv parameters should not.
Let's verify:
Go back to R2, and show mpls LDP discovery again with a command?
Here only the hair is not collected, and the principle is consistent.