This topic covers the following sections:
Availability of a service provider’s IP network can be thought of as the reachability between the regional points of presence (POP), as shown in Figure 5.
Figure 5: Regional Points of Presence
With the example above, when you use a full mesh of measurement points, where every POP measures the availability to every other POP, you can calculate the total availability of the service provider’s network. This KPI can also be used to help monitor the service level of the network, and can be used by the service provider and its customers to determine if they are operating within the terms of their service-level agreement (SLA).
Where a POP may consist of multiple routers, take measurements to each router as shown in Figure 6.
Figure 6: Measurements to Each Router
Measurements include:
To measure POP availability of POP A to POP B in Figure 6, you must measure the following four paths:
Measuring availability from POP B to POP A would require a further four measurements, and so on.
A full mesh of availability measurements can generate significant management traffic. From the sample diagram above:
This makes a total of 68 interfaces. A full mesh of paths between every interface is:
[n x (n–1)] / 2 gives [68 x (68–1)] / 2=2278 paths
To reduce management traffic on the service provider’s network, instead of generating a full mesh of interface availability tests (for example, from each interface to every other interface), you can measure from each router’s loopback address. This reduces the number of availability measurements required to a total of one for each router, or:
[n x (n–1)] / 2 gives [24 x (24–1)] / 2=276 measurements
This measures availability from each router to every other router.
A typical SLA between a service provider and a customer might state:
- A Point of Presence is the connection of two back-to-back
provider edge routers to separate core provider routers using different
links for resilience. The system is considered to be unavailable when
either an entire POP becomes unavailable or for the duration of a
Priority 1 fault.
An SLA availability figure of 99.999 percent for a provider’s network would relate to a down time of approximately 5 minutes per year. Therefore, to measure this proactively, you would have to take availability measurements at a granularity of less than one every five minutes. With a standard size of 64 bytes per ICMP ping request, one ping test per minute would generate 7680 bytes of traffic per hour per destination, including ping responses. A full mesh of ping tests to 276 destinations would generate 2,119,680 bytes per hour, which represents the following:
With a size of 1500 bytes per ICMP ping request, one ping test per minute would generate 180,000 bytes per hour per destination, including ping responses. A full mesh of ping tests to 276 destinations would generate 49,680,000 bytes per hour, which represents the following:
Each router can record the results for every destination tested. With one test per minute to each destination, a total of 1 x 60 x 24 x 276 = 397,440 tests per day would be performed and recorded by each router. All ping results are stored in the pingProbeHistoryTable (see RFC 2925) and can be retrieved by an SNMP performance reporting application (for example, service performance management software from InfoVista, Inc., or Concord Communications, Inc.) for post processing. This table has a maximum size of 4,294,967,295 rows, which is more than adequate.
There are two methods you can use to measure availability:
This section discusses real-time performance monitoring as a proactive monitoring solution.
Juniper Networks provides a real-time performance monitoring (RPM) service to monitor real-time network performance. Use the J-Web Quick Configuration feature to configure real-time performance monitoring parameters used in real-time performance monitoring tests. (J-Web Quick Configuration is a browser-based GUI that runs on Juniper Networks routers. For more information, see the J-Web Interface User Guide.)
Some of the most common options you can configure for real-time performance monitoring tests are shown in Table 25.
Table 25: Real-Time Performance Monitoring Configuration Options
For each real-time performance monitoring test configured on the router, monitoring information includes the round-trip time, jitter, and standard deviation. To view this information, select Monitor > RPM in the J-Web interface, or enter the show services rpm command-line interface (CLI) command.
To display the results of the most recent real-time performance monitoring probes, enter the show services rpm probe-results CLI command:
user@host> show services rpm probe-resultsOwner: p1, Test: t1
Target address: 10.8.4.1, Source address: 10.8.4.2, Probe type: icmp-ping
Destination interface name: lt-0/0/0.0
Test size: 10 probes
Probe results:
Response received, Sun Jul 10 19:07:34 2005
Rtt: 50302 usec
Results over current test:
Probes sent: 2, Probes received: 1, Loss percentage: 50
Measurement: Round trip time
Minimum: 50302 usec, Maximum: 50302 usec, Average: 50302 usec,
Jitter: 0 usec, Stddev: 0 usec
Results over all tests:
Probes sent: 2, Probes received: 1, Loss percentage: 50
Measurement: Round trip time
Minimum: 50302 usec, Maximum: 50302 usec, Average: 50302 usec,
Jitter: 0 usec, Stddev: 0 usec
 |
Copyright © 2009, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |