In recent years, companies have shown the benefits of “copying” and sending traffic from network backbones to purpose-built monitoring devices…no interference with the existing, “live” traffic and the traffic can be analyzed in real-time or stored for later playback. However, the best approaches to “copying” and sending the traffic to be monitored has been a source of contention. As 40/100G becomes more prevalent, how the traffic is accessed will become increasingly important.
Initially, the Switched Port Analyzer (SPAN) ports were used to deliver copies of traffic to analyzers, but this has posed several problems at the 1G and 10G data rates, which likely will increase exponentially with 40/100G:
- SPAN ports are part of the switch/router and operate in much the same way as typical ports, so the data is not always an exact copy
- Traffic congestion both on the router and on the SPAN port itself can result in increased latency or the traffic to be dropped completely
- Relying on a device that could be creating the problem to help identify it can be a self-defeating exercise
Figure 1: Network Monitoring with SPAN Ports
The practice most recently deployed, uses passive taps to send an exact copy of the traffic to the analyzer(s). While this accomplishes the task of not interfering with the “live” network, it presents issues in terms of cost and data accessibility. For example, if a network has 10x10Gbps backbones that require monitoring, the network must also have 10 analyzer ports available for the monitoring. That may not seem that daunting at first, but suppose you are a service provider or data center and you have 144/288 fibers that require monitoring. Now, you need that many analyzer ports as well, which are expensive even at 10Gbps, so what happens when the customer migrates to 40/100G?
Figure 2: Network Monitoring with Passive Taps
Of course, a practical approach to this issue would be to connect the “monitor” ports from the tap, storage device ports, and a few analyzer ports to a patch panel. If a 1x3 tap is used (creates two monitoring ports for each backbone), all of the traffic can be stored for replay using one of the monitoring ports, and the analyzer(s) can be patched into the other monitoring port as needed. This enables all traffic on the network backbones to be captured while simultaneously monitoring the most critical paths (the paths of most interest) in real-time.
Figure 3: Network Monitoring with Passive Taps and a Patch Panel
While the approach above does solve the problem of capturing everything and reducing the cost of the analyzing equipment, it does present one key problem: manually patching in the storage device or backbone that you want to monitor can be time consuming, error prone, and increase the risk of creating a network issue. Using a Layer 1 switch or an automated patch panel can eliminate or reduce these issues. For example, connecting the “monitor” ports from the tap to a Layer 1 switch or an automated patch panel reduces the time needed to make connections because now they can be made remotely and at the click of a mouse. Furthermore, using a switch or automated patch panel reduces errors as generally some intelligence keeps the user from making an inappropriate connection (software may be intelligent enough to prevent a 10G port connection to a 100G port). In addition, making the connections inside the switch or automated patch panel reduces exposure to the elements preventing network errors that can occur, such as dirt on the end of a fiber optic connector.
Figure 4: Network Monitoring using Passive Taps and Symmetrical Switch
Ideally, the Layer 1 switch or automated patch panel would be used to “patch” either a monitor port directly from the network or a storage device port to the analyzer as needed. As a result, one of the “monitor” ports can be statically connected through a patch panel to the storage device’s Rx port. In this case, all of the storage device’s Tx ports and the other “monitor” ports from the tap should be connected to the input ports on the Layer 1 switch or automated patch panel. With that in mind, the output ports of the Layer 1 switch or automated patch panel should be connected to the Rx port(s) on the analyzer. This approach further reduces the cost of capturing the traffic on the network because it requires a patch panel, a passive optical tap, a highly asymmetrical Layer 1 switch or automated patch panel, and only a handful of analyzer ports. The cost savings of this approach versus the previous one above is primarily due to the asymmetrical Layer 1 switch or automated patch panel cost versus a symmetrical switch.
Figure 5: Network Monitoring using Passive Taps and Asymmetrical Switch
In summary, as we move toward 40/100G networks, the same problems seen in monitoring networks at 10G still exist but are compounded with the additional cost and complexity associated with 40/100G. The best and most cost-effective approach to ensuring that all data is quickly, reliably, and easily captured is to deploy passive optical taps coupled with either optical switches or automated patch panels, which connect the network backbones to storage devices and network analyzers.
With most of the world now relying on fiber optic systems for communication, a key component to ensuring a high level of performance from operators is network monitoring. When we think of network monitoring, much of the focus is usually on the equipment itself, as well as the management of all the data flowing through the system. As a result, an area often overlooked when deploying and monitoring a network is the actual fiber optic cable, through which all the data is sent from one location to another.
While network operators aim to protect fiber optic cables as best they can, it is a relatively common occurrence to hear via the local news or industry reports that a fiber optic cable was accidentally cut and some type of outage immediately followed. A recent article on AllAfrica.com by Eric Bright serves as a great example in highlighting some recent events in Europe and Africa along these lines. This is especially true in the developing countries, where there may not yet be the same level of protection or advanced routing options readily available.
To deal with these types of issues in the past, most operators would need to physically check the line using an OTDR to determine the location and then travel to that specific point to service the issue. With every second of downtime counting negatively towards the operator in several ways, this process often took up valuable time before a resolution could be completed.
Fortunately, Remote Fiber Test Systems (RFTS) are available to assist operators in servicing these fiber-related issues in the most efficient manner. By installing a remote fiber test system, an operator is able to monitor fibers around-the-clock from anywhere and receive immediate alerts of breaks, degraded connections, and even malicious intrusion attempts. In addition to the quick notification, most fiber test systems will provide a near-exact location of the issue, so the service team will not have to waste as much time determining where to go. The positive end result is increased network availability via another layer of network monitoring.
When looking into deploying a remote fiber test system, there are several different alternatives available in the market that might be suitable for an operator’s requirements. While some have utilized solutions based on traditional OTDR technology, due to the extremely high price tag and ongoing budgetary pressure, many are finding new systems based on alternative technology to be sufficient for meeting their fiber monitoring goals. Since all networks are unique, it is important to obtain information on a number of different systems to find the solution that best fits all the objectives of the operator.