Scenario 1 - Firewall Problem
A user in San Diego is unable to participate in a NORTHCOM DCTS conference. The user MUST be in a 1500 conference and it is already 1400. The user contacts the NORTHCOM DCTS support personnel and advises them of the situation. NORTHCOM confirms that there are already numerous people connected to the conference and are unable to determine what the cause of the problem is. The firewall administrators at NORTHCOM and the users site explain that they are properly configured. NORTHCOM requests support through many channels and the problem begins to travel around the world seeking resolution. Three months after the user’s 1500 meeting, it is finally determined that there was in fact a closed port on their local firewall due to a recent security audit. The required port is opened and the user may now attend DCTS conferences at NORTHCOM.
The main problem here was that the firewall administrator was simply incorrect in saying the firewall was properly configured. Without evidence to the contrary, however, the DCTS administrator had to move on to other solutions. In this situation, CETA could have been run between the user’s computer and a computer near the NORTHCOM conference server as soon as they reported the problem. Within seconds, they would have a report in their hand, clearly indicating the offending port closure. Action could have been focused and the problem could have been resolved in time for the 1500 meeting, instead of three months later.
Before CETA, if a firewall was suspected to cause a problem, support personnel would usually locate the device and visually monitor it to see if port traffic was being attempted and denied. However, this time consuming process only tells part of the story. What matters, is that the information can get from the user’s computer to the conference server, traversing all network devices in between. With CETA, there is now a definitive way to determine if there is some device between the two networks causing the problem. In many cases, simply tracking down the appropriate personnel to gain access to the firewall can take weeks. CETA allows administrators to get the information that they need without spending time tracking down individuals.
Scenario 2 - Bandwidth Problem
DISA begins to field a new collaboration product. This new product is good and everyone is excited to use it. Key personnel at a remote location inquire about having the product installed at their site so that their users can communicate with their counter parts at CENTCOM. The remote site begins to gather information regarding their network architecture in an effort to determine if the new product will be well suited there. The network engineers at the remote site advise that they have 56k of bandwidth available to the link to CENTCOM, which is well within the usability range for the new product. Shortly there after, decisions are made to deploy a team of engineers to install the product at the remote site. The installation goes well and the team returns home. Users immediately begin to experience problems. They are supposed to be able to see and hear the personnel in CENTCOM while communicating with the new product, but the audio is shaky and the video doesn’t seem to work at all.
Support is requested, but nothing seems to help the problem. CENTCOM does not report any similar problems with other sites. Users at the remote site simply stop using the product and many months later it seems as though the money spent to equip the site has been wasted.
In this situation, the bandwidth available to the remote site was significantly less that the engineers initially reported. While the site maintained a 56k circuit to CENTCOM, what failed to be accounted for was that normal network operations at the remote site already consume nearly three quarters of their available bandwidth. The new product could never have succeeded in this environment. CETA could have been run during the site survey process and the actual bandwidth available to the site would have been realized. Armed with this information, efforts could have been made to find alternatives to the existing 56k link or even to schedule the collaborative meetings at non-peak hours.
Before CETA, site collaboration personnel have had very few ways of determining whether they had enough bandwidth to conduct needed operations. CETA gives the people that are responsible for their products the ability to see first hand if they have an appropriate network infrastructure.
Scenario 3 - Stability Problem
Every day at 1500, there is a desktop VTC session scheduled between SOUTHCOM and SOCOM key personnel. During every session, the users at one of the participating SOCOM sites experience problems. It seems as though they connect to the session but are randomly disconnected. The other session participants experience significant delays with the PowerPoint slides that are being shared through the desktop VTC. The slide presentation gets out of sync with the presenters voice pretty quickly and soon it becomes too confusing to continue. Support personnel advise them of different ways of sharing the data that may be more tolerant of the network but the problems persist.
In this situation, CETA could have been run between each participating site. CETA would have determined that every day during the scheduled session, there is a small series of outages on the remote SOCOM site’s network. When the users at this SOCOM site are disconnected, the disruption is felt by ALL session participants due to the specific technologies in use. The method with which they are sharing the presentation is very negatively affected by the frequent disconnects and becomes unsynchronized on each participant’s computer. By using CETA to determine that outages had in fact occurred, local administrators are able to pinpoint them to a specific local server’s backup routine. They could then adjust this server and the collaboration session would be successful.
Before CETA, site administrators have relied heavily upon communication with their network engineers to find out if and when network outages occur. The problem is that there is no uniform definition of an outage, a two second blip may go completely unnoticed by the network administrators, but it could devastate a collaboration session. CETA places the power to determine network stability in your hands. Without having to spend time tracking down network engineers and other personnel, the people using and responsible for collaboration can easily find the information for themselves using CETA.
|
