-
Cisco Active Network Abstraction Managing MPLS User Guide, 3.6.6
-
Preface
-
Viewing MPLS VPNs
-
Managing MPLS VPN Maps
-
Managing VPN Business Configuration
-
Viewing MPLS VPN Properties
-
Viewing MPLS Logical Inventory
-
IPv6 VPN over MPLS
-
MPLS Network Faults
-
Impact Analysis in MPLS Networks
-
Using Cisco ANA PathTracer in MPLS Networks
-
Running a VPN Leak Report
-
MPLS User Guide Index
-
Table Of Contents
Pseudo Wire MPLS Tunnel Down Alarm
MPLS Network Faults
The following topics describe the alarms that Cisco ANA detects and reports for MPLS, LSP, LDP, BGP, TE tunnels, and Layer 2 VPNs. Topics include:
•
MPLS Network Alarms Overview—Provides a summary of the MPLS and VPN alarms supported in Cisco ANA.
•
•
•
•
•
•
•
Note
MPLS Network Alarms Overview
Table 7-1 lists the MPLS, BGP, LSP, LDP, TE tunnel, and Layer 2 VPN alarms supported by Cisco ANA. Alarms are displayed in the ticket pane of the Cisco ANA NetworkVision window.
BGP Neighbor Loss Alarm
If BGP connectivity is lost to a specific device in an MPLS VPN network, VPN sites lose connectivity. The VNE models the BGP connection between routers and actively monitors its state. A BGP Neighbor Loss alarm is generated from both sides of the connection when a connectivity loss occurs. Alarms and tickets are issued and impact analysis information displayed.
The correlation engine identifies various faults that affect the BGP connection and reports them as the root cause for the BGP neighbor loss alarm, for example, Link Down, CPU Overutilized, and Link Data Loss.
Note
The BGP Neighbor Loss alarm is detected actively by the system and service alarms are generated. The system also supports BGP neighbor down syslogs.
When the VNE BGP component polls the BGP neighbor status (expedite or normal polling) and finds an entry for a neighbor no longer exists or its state changed from Established to another state, the BGP component issues a BGP Neighbor Loss alarm. This alarm causes the BGP component to issue a Root Cause Analysis (RCA) correlation flow to find the root cause. If RCA does not find an alarm to correlate, the VNE sends the alarm to the gateway as a ticket.
If this alarm is configured in the registry to issue a Look For Affected flow. If a BGP neighbor loss occurs and the BGP component has no other BGP PE links, all VRFs with route entries to the PE as BGP next hops are true-affected. This information is sent as an update to the previous BGP Neighbor Loss alarm.
BGP Process Down Alarm
A Cisco ANA query checks the status of the BGP process when the VNE BGP component polls for the status and configuration of its BGP neighbors (expedite or normal polling). If the BGP process is not running, the VNE BGP component issues an BGP Process Down alarm. This alarm is always a ticket and does not try to correlate to other alarms. All the BGP Neighbors Down alarms issued in response to the BGP Process Down alarm and is correlated to the BGP Process Down ticket.
Broken LSP Discovered Alarm
The MPLS Black Hole Found alarm activates a backward flow on the specific untagged entry in order to traverse the full path of the LSPs passing through it. If Cisco ANA locates services (for example, VRFs, pseudowire tunnels) along this path that are using these LSPs, a Broken LSP Discovered alarm is issued. Such services can be found only on PE routers, and they can be found on more than one PE router. The source of the Broken LSP Discovered alarm is the PE router on which the service was discovered, and in many cases this router is different from the router that issued the MPLS Black Hole Found alarm.
Broken LSP Discovered alarms are correlated to the MPLS Black Hole Found alarm (except in the case of a black hole alarm due to a link down). The Broken LSP Discovered alarm is detected actively by the system, namely, service alarms are generated. An example of an MPLS black hole scenario follows.
In the network described in this example, the shortest path from PE2 to PE3 is PE2<->P2<->PE3. The link between P2 and PE3 is an MPLS link, meaning interfaces on both sides of the link are configured as MPLS interfaces. Also assume that for some reason, the MPLS configuration is incomplete or incorrect, namely:
•
•
In this case, the label switching table on P2 and PE3 will have untagged entries for the LSPs between PE2 and PE3. If PE2 and PE3 have VPN services (for example VRFs and pseudowires), the outcome will be that the data flow between PE2 and PE3 will be affected.
Figure 7-1 Example of an MPLS Black Hole Scenario
In this case, Cisco ANA does the following:
•
•
•
–
–
•
Note
After the MPLS Black Hole alarm clears, and the configured gateway correlation timeout period is reached, the gateway can close the ticket because all the alarms correlated to MPLS Black Hole and Broken LSP are auto-cleared.
Note
LDP Neighbor Down Alarm
LDP enables neighboring P or PE routers acting as LSRs to discover peers in an MPLS network to which they can establish LDP sessions. The sessions allow the routers to negotiate and exchange labels used for forwarding packets.
If a session to an LDP neighbor goes down, an LDP Neighbor Down alarm is issued. This can happen as the result of a failure in the TCP connection used by the LDP session, or if the interface is no longer running MPLS. The LDP neighbor down alarm is cleared by a corresponding LDP Neighbor Up alarm.
The alarm is issued when a peer is removed from the table in the LDP Neighbors tab. The alarm runs a correlation flow to detect the network core triggering event A root cause analysis is performed to find the root cause. The alarm initiates an IP-based flow toward the peer transport address destination. If an alarm is found during the flow, that alarm is correlate to to the LDP Neighbor Down alarm.
Note
MPLS Black Hole Found Alarm
an MPLS black hole is defined as an abnormal termination of an MPLS path (LSP) inside an MPLS network. An MPLS black hole exists when on a specific interface there are untagged entries destined for a known PE router. It is assumed that a router functions as a PE router if there are services using the MPLS network, such as L3 VPNs or pseudowire (L2 VPN) MPLS tunnels. Note that the untagged interfaces may exist in the network in normal situations. For example, where the boundary of the MPLS cloud has untagged interfaces this is still considered normal.
An MPLS black hole cause the loss of all the MPLS labels on a packet including the VPN information that lies in the inner MPLS label. If a packet goes through an untagged interface, the VPN information is lost. The VPN information loss causes VPN sites to lose connectivity.
MPLS Black Hole Found alarms are actively detected. Service alarms are generated whenever Cisco ANA discovers an MPLS interface with at least one untagged LSP leading to a known PE router.
Black hole alarms are detected either:
•
•
Note
MPLS TE Tunnel Alarms
MPLS TE tunnel alarms include:
•
•
•
If a TE tunnel operational status changes to down, an MPLS TE Tunnel Down alarm is generated. The Cisco ANA correlation engine identifies the faults that affect the TE tunnel status and identifies the root cause for the MPLS TE Tunnel Down alarm. For example, a Link Down will cause a TE tunnel to go down. Multiple up and down alarms that are generated during a short time interval are suppressed and displayed as an MPLS TE Tunnel Flapping alarm (according to the specific flapping configuration).
MPLS TE Tunnel Down and MPLS TE Tunnel Flapping alarms are actively detected and service alarms are generated. The system also supports MPLS TE Tunnel Down syslogs, which are correlated to the service alarm.
For Cisco CRS-1 routers running Cisco IOS XR 3.6 software and using PBTS in MPLS or MPLS VPN networks, Cisco ANA supports the following ubalarms for the MPLE TE Tunnel Down alarm:
•
•
•
The specific subalarm that is generated depends on the EXP bit specified for the traffic. Cisco ANA maps the specified EXP bit to tunnel priority and uses that mapping to generate the resultant subalarm. The alarm description includes information about the EXP bit.
Tunnel reoptimization occurs when a tunnel is up and its route changes but the tunnel continues to remain up. When a TE tunnel is reoptimized to take a different path, the system parses the tunnel reoptimized syslog, if such a syslog is available, and displays it as a ticket.
The Tunnel Reoptimized alarm is generated from a syslog message sent by the router.
Pseudo Wire MPLS Tunnel Down Alarm
A Pseudo Wire MPLS Tunnel Down alarm is issued when the pseudowire link goes down, namely, the pseudowire tunnel is reported as down from both the devices (based on the status of the tunnel), and the tunnel is not flapping.
The correlation engine identifies various faults that affect the pseudowire tunnel status and reports on them as the root cause for the Pseudo Wire MPLS Tunnel Down alarm, for example, Link Down. Cisco ANA traces the LSE path to the edge of the PWE3 tunnel and marks the edges of the tunnel as affected. The Pseudo Wire MPLS Tunnel Down alarm is detected actively by the system, namely, service alarms are generated.
