Table Of Contents

Impact Analysis in MPLS Networks

Service Impact Analysis Overview

Service Impact Analysis For MPLS-Based VPN Services

L3 VPN Report

Pseudowire (L2 VPN) Report

Supported Fault Scenarios

Link Down Scenario

Link Overutilized/Data Loss Scenario

BGP Neighbor Loss Scenario

Broken LSP Discovered Scenario

MPLS TE Tunnel Down Scenario

Pseudowire MPLS Tunnel Down Scenario

Impact Analysis in MPLS Networks

---

The following topics provide an overview of the service impact analysis solution and supported scenarios, which are used in VPN networks that are based on MPLS, including Layer 3 and Layer 2 VPNs. In addition, theybriefly describes proactive and automatic impact analysis.

•Service Impact Analysis Overview—Describes the service impact analysis solution.

•Service Impact Analysis For MPLS-Based VPN Services—Describes the impact analysis process for Layer 3 VPN and pseudowire (Layer 2 VPN) scenarios.

•Supported Fault Scenarios—Describes the scenarios supported by the service impact analysis solution.

Service Impact Analysis Overview

Cisco ANA analyzes network faults to identify the NEs involved in the VPN services (such as interfaces on the PE) that are affected, or potentially affected, by the fault. After a fault occurs, Cisco ANA automatically generates the list of potential and actual service resources affected by a fault and embeds this information in the ticket along with all the correlated faults. (You can configure this behavior.)

---

Note Automatic impact analysis is not performed for every service alarm. It is performed for a small group of selected alarms, for example, BGP Neighbor Loss, Broken LSP, Link Down, Layer 2 Tunnel Down, and so on.

---

During Cisco ANA impact analysis, affected parties can be marked with one of the following severities:

•Potentially Affected—The service might be affected but its real state is unknown.

•Real Affected—The service is affected.

•Recovered—The service has recovered. This state applies only to entries that were previously marked as potentially affected. It indicates only that there is an alternate route to the service, regardless of the service quality level)

The initial impact report may mark the services as either Potentially Affected or Real Affected. As time progresses and more network information is accumulated, the system might issue an additional report to indicate which of the potentially affected parties are Real Affected or Recovered. These indications are available through the API and the Cisco ANA GUI.

---

Note The reported impact severities vary between fault scenarios. For more information about specific support for each fault scenario, see Supported Fault Scenarios.

---

---

Note After the alarm clears, no Clear state for the affected services is generated. However, you can verify that the alarm cleared by checking the Alarm Clear State column in the Affected Parties tab of the Ticket Properties window. For more information about the Affected Parties tab of the Ticket Properties window, see the Cisco Active Network Abstraction 3.6.6 User Guide.

---

Cisco ANA provides "what-if" scenarios for determining the possible effect of network failures. This enables on-demand calculation of affected VPN sites for physical links in the network, thus enabling an immediate service availability check and analysis for potential impact and identification of critical network links. After executing a what-if scenario, Cisco ANA initiates an end-to-end flow to identify all the potentially affected edges in the affected VPNs. Proactive impact analysis is available from the following:

•Link Properties dialog box when selecting a physical link.

•Topological Link Properties window when selecting a physical link in the links view.

For more information about proactive impact analysis, see the Cisco Active Network Abstraction 3.6.6 User Guide.

Service Impact Analysis For MPLS-Based VPN Services

An MPLS network with PE routers is supported, where the PE routers implement either of the following:

•Layer 3 VPN (VRFs are affected)

•Pseudowire (L2 VPN tunnels are affected)

These scenarios are described in the following topics:

•L3 VPN Report

•Pseudowire (L2 VPN) Report

---

Note Descriptions provided in these scenarios refer only to faults in the MPLS core and not to faults in access networks.

---

L3 VPN Report

When the Cisco ANA impact analysis identifies the affected parties, the VRFs are displayed as the affected parties on the PE routers that lost connectivity between them in the Ticket Properties window. The number of affected parties that are reported is calculated from the pairs of VRFs and are reported in the Ticket Properties window. The structure of the edge point ID is Device ID \VRF ID\Subinterface (or interface) ID. (The subinterface or interface ID is optional.)

---

Note VRF sites are not reported as affected pairs.

---

Figure 8-1 shows an example with two PEs, A and B, and a VRF in the same VPN. The Layer 3 VPN faults that are reported are AX - BX.

Figure 8-1 Layer 3 VPN Example

Pseudowire (L2 VPN) Report

When a pseudowire tunnel goes down and an alarm occurs, the affected service resources are calculated by tracing the LSP to the edge of the pseudowire tunnel and collecting the affected pairs from both sides of the pseudowire tunnel. The edges of the tunnel are marked as affected.

The affected pairs are displayed in the Ticket Properties window. For more information about the Ticket Properties window, see the Cisco Active Network Abstraction 3.6.6 User Guide.

Supported Fault Scenarios

The following fault scenarios trigger automatic impact analysis calculation:

•Link Down Scenario

•Link Overutilized/Data Loss Scenario

•BGP Neighbor Loss Scenario

•Broken LSP Discovered Scenario

•MPLS TE Tunnel Down Scenario

•Pseudowire MPLS Tunnel Down Scenario

The following criteria are used in the tables that are described in the sections that follow:

•Impact Calculation—Describes the way in which the affected parties are calculated by system flows.

•Reported Affected Severity—Describes the kind of severity generated by the alarm.

---

Note Proactive impact analysis is performed only for links.

---

Link Down Scenario

Table 8-1 shows the impact calculations and reported affected severities for a link down fault scenario.

Table 8-1 Link Down Scenario

Impact and Affected Severity	Description
Impact calculation	Initiates an affected flow to determine the affected parties using the LSPs traversing the link.
Reported affected severity	•The Link Down alarm creates a series of affected severity updates over time. These updates are added to the previous updates in the system database. In this case, the system provides the following reports: –The first link down report shows "X<->Y" as Potentially Affected. –Over time, the VNE identifies that this service is Real Affected or Recovered and generates an updated report (this applies only to cross-MPLS networks). –The Affected Parties tab of the Ticket Properties dialog box displays the latest severity, for example, Real Affected. –The Affected Parties Destination Properties dialog box displays both reported severities. This functionality is currently supported for Link Down only.

Link Overutilized/Data Loss Scenario

Table 8-2 shows the impacted calculations and reported affected severities for a link overutilized/data loss fault scenario.

Table 8-2 Link Overutilized/Data Loss Scenario

Impact and Affected Severity	Description
Impact calculation	Initiates an affected flow to determine the affected parties using the LSPs traversing the link.
Reported affected severity	Only reports on potentially affected.

BGP Neighbor Loss Scenario

Table 8-3 shows the impacted calculations and reported affected severities for a BGP neighbor loss fault scenario.

Table 8-3 BGP Neighbor Loss Scenario

Impact and Affected Severity	Description
Impact calculation	•Initiates a local affected flow to all VRFs that are present on the issuing device. Each local VRF that has route entries with a next hop IP that was learned from the BGP neighbor that was lost collects VRFs from both sides and pairs them together as affected. •Supports a route reflector configuration, whereby during the affected search, affected parties are located on all BGP neighbors learned via the route reflector.
Reported affected severity	Only reports on Real Affected on the IBGP domain.

---

Note The BGP Neighbor Loss alarm represents a scenario where there is a BGP neighbor down.

---

---

Note The affected only relate to L3 VPN services.

---

BGP rules require all routers within an autonomous system be fully meshed. For large networks, this requirement represents a severe scaling problem. Route reflectors enable a BGP entity to establish a single BGP connection with a peer, where through that single peer, routing information is learned from other peers. As a result, the number of BGP sessions and connections is greatly reduced.

Decreasing the number of BGP connections and the presence of route reflectors further separates the data and control paths. For example, data packets going from A to B do not go through the route reflector while the routing updates between A and B do.

Every BGP router is uniquely identified by a router ID. A route reflector is not a configuration of a specific router. A router may act as a route reflector if it has a BGP neighbor configured as a BGP client. A router may act as both a route reflector to some of its BGP neighbors (those that are configured as BGP clients) and a non-client BGP neighbor to those BGP neighbors that are configured as non-client BGP neighbors.

A route reflector follows the following logic when distributing routes to its BGP neighbors:

•A router advertises to its client peers all routes learned from both other client and non-client peers.

•A router advertises to its non-client peers only routes received from client peers.

Router ID distribution follows the same logic described previously here.

Cisco ANA modeling provides a list of one or more router IDs for each interface. This reflects the network behavior of receiving BGP updates from a BGP router (possessing that ID) through that interface. The VNE also maintains the nature of the relationships (client and non-client) among the various VNEs representing the BGP routers. Figure 8-2 shows an example.

Figure 8-2 Route Reflector Example

In the example, the following configuration is applied:

•Router A (router ID A) has clients configured B, C, and D. Therefore it serves as the route reflector for these BGP routers.

•Routers B, C, and D all have Router A as a BGP non-client neighbor.

•Router D and Router B also have each other configured as BGP non-client neighbors.

In this case, in Cisco ANA, the following information is maintained by a VNE:

•Router B learns router ID D from interface 1.

•Router B learns router IDs A, C, and D from interface 2.

•Router C learns router IDs A, B, and D from interface 1.

•Router D learns router ID B from interface 2.

•Router D learns router IDs A, B, and C) from interface 1.

•Router A learns router ID D from interface 1.

•Router A learns router ID C from interface 2.

•Router A learns router ID B from interface 3.

In the Figure 8-2 example, if a BGP connection is lost from Router A to Router B, the following occurs:

•Router A notifies both Routers C and D of the loss of router ID B.

•Router C removes the ID of Router B from its tables and completely loses connectivity to it, resulting in a Real Affected impact analysis.

•Router D loses the ID of Router B learned from interface 1, but it still has Router B's ID that was learned through interface 2. Therefore, no impact analysis is performed.

If a BGP connection is lost from Router B to Router D, the following occurs:

•Router B does not notify Router A of its router ID loss, because Router A is configured in Router B's tables as a non-client peer.

•Router D does not notify Router A of its router ID loss, because Router A is configured in Router D's tables as a non-client peer.

•Router B notes that the ID of Router D is no longer learned through interface 1.

•Router D notes that the ID of Router B is no longer learned through interface 2.

•No impact analysis is performed.

Broken LSP Discovered Scenario

Table 8-4 shows the impacted calculations and reported affected severities for a broken LSP discovered fault scenario.

Table 8-4 Broken LSP Discovered Scenario

Impact and Affected Severity	Description
Impact calculation	Initiates an affected flow to determine all the affected parties using the LSP.
Reported affected severity	Only reports on Real Affected. When the Link Down is cleared, all the correlated broken LSP alarms are auto-cleared.

MPLS TE Tunnel Down Scenario

Table 8-5 shows the impacted calculations and reported affected severities for an MPLS TE tunnel down fault scenario.

Table 8-5 MPLS TE Tunnel Down Scenario

Impact and Affected Severity	Description
Impact calculation	Initiates a flow to look for affected parties.
Reported affected severity	Only reports on real affected.

Pseudowire MPLS Tunnel Down Scenario

Table 8-6 shows the impacted calculations and reported affected severities for a pseudowire MPLS tunnel down fault scenario.

Table 8-6 Pseudowire MPLS Tunnel Down

Impact and Affected Severity	Description
Impact calculation	Initiates a flow to look for the affected parties.
Reported affected severity	Only reports on real affected on the MPLS domain.