Impact Analysis in MPLS Networks

Transcription

1 CHAPTER 7 The following topics provide an overview of the Cisco MPLS Assurance Manager 1.0 (Cisco MPLS-AM) service impact analysis (IA) solution and supported scenarios, which are used in VPN networks based on MPLS, including Layer 3 and Layer 2 VPNs. The following sections provide an impact analysis overview, then describe impact analysis for MPLS VPNs, TE tunnels and pseudowires: Impact Analysis Overview, page 7-1 MPLS VPN Impact Analysis, page 7-2 BGP Route Reflection, page 7-4 TE Tunnel and Pseudowire Impact Analysis, page 7-6 Impact Analysis Overview Cisco MPLS-AM analyzes network faults to determine which network elements involved in the VPN services (such as interfaces on the PE) are affected or potentially affected by the fault. After a fault occurs, Cisco MPLS-AM automatically generates the list of potential and actual service resources that were affected and adds this information in the ticket along with all the correlated faults. Automatic IA is not performed for every service alarm. It is performed for the following alarms: Link Down BGP Neighbor Loss TE Tunnel Down Broken LSP Discovered Card Out Automatic IA marks the affected parties with one of the following severities: Potentially Affected The service might be affected but it s real state is unknown. Real Affected The service is affected. Recovered The service is recovered. This state only relates to entries that were previously marked as potentially affected. It only indicates that there is an alternate route to the service, regardless of the service quality (level). 7-1

2 MPLS VPN Impact Analysis The initial impact report might mark the services as either Potentially Affected or Real Affected. As time progresses and more information is accumulated from the network, the system might issue an additional report to indicate which of the potentially affected parties are Real Affected or Recovered. The indications for these states are available both through the API and in the Cisco MPLS-AM GUI. Note The reported impact severities vary between fault scenarios. For more information about specific support for each fault scenario, see Supported MPLS VPN Fault Scenarios, page 7-3. Note When the alarm is cleared and no Clear state exists for the affected services, you can check the Alarm Clear State column in the Affected Parties tab of the Active Ticket tab to indicate that the alarm was cleared. For more information about the Affected Parties tab of the Active Ticket tab, see the Cisco Active Network Abstraction 4.0 User and Administration Guide. MPLS VPN Impact Analysis MPLS VPN IA analyzes the network faults that affect the network elements involved in the MPLS VPN services and determines which VPNs, customers, sites, PEs, CEs, and related attachment circuits (ACs) are affected by each fault. You can then drill down to view impact information in detail. Cisco MPLS-AM MPLS VPN IA solutions is initiated by faults in the network. When a fault occurs, an alarm is sent to the Cisco MPLS-AM IA system. Cisco MPLS-AM automatically calculates the affected service entities and updates the alarm. Events that trigger reactive IA include changes in the network operation state such as link down, interface down, LSP lost, MPLS black-hole, and other changes. Removing of service impacting router commands from devices also causes reactive IA. IA is viewed through the Monitoring perspective topology view, and through the Active Tickets tab in either the Inventory or Monitoring perspectives. The topology view allows you to see the MPLS VPN impact. The Active Tickets tab allows you to see impact information pertaining to MPLS VPN service. IA adds impact analysis information into the following MPLS VPN topology views. Site-to-Site View shows routing details including the connectivity between the PEs and CEs. Logical View Shows VRF connectivity and site connectivity including connectivity between the VRFs established using RTs with options for displaying site, CE, AC, site connectivity only, and other options. Note The description provided in this chapter refers only to faults in the MPLS core and not to faults in access networks. MPLS VPN Layer 3 Edge View Impact Analysis Cisco MPLS-AM analyzes the service-affecting faults that affect the network elements in the VPN service and determines VPNs and sites that might be affected. Simulation mode can be used to show the potential impact on specific links in the following scenarios: Link Down within MPLS core When a link goes down within the MPLS core, IA calculates the LSPs to discover the affected VRFs. From this analysis, the impacted sites are determined. 7-2

3 MPLS VPN Impact Analysis Link Down between CE and PE When a link is disconnected between a CE and PE, the IP interfaces on both ends are affected. Link Down inside a pseudowire When a link goes down inside a pseudowire, Cisco MPLS-AM traces the LSE path to the edge of the tunnel and marks both tunnel edges and CE devices that are affected. After the problem is identified, Cisco MPLS-AM creates an event that includes the impact and fault ticket information. You can view the inter site connections and the sites that have lost connectivity. Supported MPLS VPN Fault Scenarios The following fault scenarios trigger automatic IA calculation: Link Down BGP Neighbor Loss Broken LSP Discovered Table 7-1 shows the supported MPLS VPN faults. The table describes how the affected parties are calculated and the kind of severity that is generated. Table 7-1 MPLS VPN Fault Impact Analysis Fault Impact Calculation Reported Affected Severity Link Down Initiates an affected flow to determine the affected parties using the LSPs traversing the link. The Link Down alarm creates a series of affected severity updates. These updates are added to the previous updates and kept in the Cisco MPLS-AM database. The following reports are generated: The first Link Down report shows X<->Y as Potentially Affected. After the VNE identifies the service as Real affected or Recovered, an updated report is generated (this only applies to cross-mpls networks). The Affected Parties tab of the Active Tickets tab displays the latest severity, namely, Real affected. The Affected Parties Destination Properties dialog box displays both reported severities. 7-3

4 BGP Route Reflection Table 7-1 MPLS VPN Fault Impact Analysis (continued) Fault Impact Calculation Reported Affected Severity BGP Neighbor Loss Broken LSP Discovered 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. During the search, affected parties are located on all BGP neighbors learned through the route reflector. Initiates an affected flow to determine all the affected parties using the LSP. Only reports on real affected on the IBGP domain. (The BGP Neighbor Loss alarm represents a scenario where there is a BGP neighbor down.) Only reports on real affected. When the link down is cleared, all the correlated broken LSP alarms are autocleared. BGP Route Reflection BGP protocol requires all routers within an autonomous system (AS) to be fully meshed. For large networks, this can present a scaling problem. To solve it, route reflectors are used. Route reflectors enable a BGP entity to establish a single BGP connection with a peer through which routing information is learned from other peers. As a result the number of BGP sessions and connections is greatly reduced. Route reflectors separate the data path from the control path. 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 identified by a unique router ID. A route reflector is not a configuration of a specific router. A router might act as a route reflector if it has a BGP neighbor configured as a BGP client. A router might act as both a route reflector to some of its BGP neighbors (those that are configured as BGP clients) as well as a non-client BGP neighbor to those BGP neighbors that are configured as non-client BGP neighbors. A route reflector performs the following actions when it distributes routes to its BGP neighbors: Advertises to its client peers all routes learned from both other client and non-client peers. Advertises to its non-client peers only routes received from client peers. Router ID distribution follows the same logic described above. Cisco MPLS-AM IA provides a list of one or more router IDs to each router interface. This reflects the network behavior of receiving BGP updates from a BGP router (possessing that ID) through that interface. The Cisco MPLS-AM VNE also maintains the nature of the relationship (client and non-client) between the various VNEs representing the BGP routers. An example is shown in Figure

5 BGP Route Reflection Figure 7-1 Route Reflector Example Router A (RR) IF 2 IF 3 IF 2 Router D IF 2 Router B Router C In the example, the following configuration is applied: Router A (Router ID A) has clients configured on Routers 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 example, the Cisco MPLS-AM VNE maintains the following information: Router B learns Router D from Interface 1. Router B learns Routers A, C, and D from Interface 2. Router C learns Routers A, B, and D from Interface 1. Router D learns Router B from Interface 2. Router D learns Routers A, B, and C from Interface 1. Router A learns Router D from Interface 1. Router A learns Router C from Interface 2. Router A learns Router B from Interface 3. Table 7-2 shows two examples of the Cisco MPLS-AM IA that occurs when BGP connectivity is lost in the example shown in Figure

6 TE Tunnel and Pseudowire Impact Analysis Table 7-2 BGP Route Reflector Impact Analysis Examples Connection Loss From Router A to Router B From Router B to Router D Actions Router A notifies Routers C and D of the Router B loss. Router C removes the Router B ID from its tables and completely loses connectivity to it, resulting in a real affected IA. Router D loses the Router B ID learned from Interface 1 but it still has the Router B ID that was learned through Interface 2 therefore no IA is performed. Router B does not notify Router A of its Router ID loss because Router A is configured in the Router B tables as a non-client peer. Router D does not notify Router A of its router ID loss because Router A is configured in the Router D tables as a non-client peer. Router B notes that the Router D ID is no longer learned through Interface 1. Router D notes that the Router B ID is no longer learned through Interface 2. No IA is performed. TE Tunnel and Pseudowire Impact Analysis When faults occur to TE tunnels, Cisco MPLS-AM adds TE related business IA to the alarms received from the VNE. Events captured from the network and generation of alarms and tickets are performed at the VNE and gateway layers. 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, and the impacted pairs are displayed in the Active Tickets tab in the Inventory and Monitoring perspectives. Table 7-3 shows the supported TE tunnel and pseudowire faults. The table describes how the affected parties are calculated and the kind of severity that is generated. Table 7-3 TE Tunnel and Pseudowire Impact Analysis Fault Impact Calculation Reported Affected Severity MPLS TE Tunnel Down Layer 2 Tunnel Down Initiates a flow to look for affected parties. Initiates a flow to look for the affected parties. Only reports on Real affected. Note: The MPLS TE Tunnel Flapping fault is transitory. Only reports on Real affected on the MPLS domain. 7-6