Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Faults
Suppose LSP1 is happily forwarding IP traffic when suddenly the R2-R3 link goes down. This could be caused by R2 or R3 going down, or by one of the linked interfaces going into the down state. Regardless of the reason for the problem, in our sample MPLS network the explicitly routed LSP1 will go down because there's no protection such as fast reroute or a backup tunnel instance.
The end result will be a number of SNMP notifications being sent from the network to the NMS. Assuming that the appropriate tunnel traps have been enabled, one of the notifications will be mplsTunnelDown. This notification includes sufficient information to allow the NMS operator to quickly determine exactly which tunnel has gone down. Typically, the NMS will process the notification and reflect the new status of the tunnel (down, in this case) by a color change in a GUI representation of the network topology; the operator can drill down to the exact problem that caused the notification.
The other notification that may be sent during this process is a linkDown. Again, the NMS receives this notification and must inform the operator (again, by changing the color of some GUI element). The NMS can also send any of the following:
Email message
Pager alert
Mobile phone message
Once the operator becomes aware of the problem, he or she resolves the underlying issue—in this case, an interface that has gone into the down state.