This week I was part of a panel at the Satellite 2010 conference in Washington, DC. Our panel was titled “Securing Your Network: Protecting your Operations, Content and Assets.” Your first thought upon seeing the session title was probably “encryption.” While encrypting the data being transmitted prevents eavesdropping, it doesn’t protect the satellite infrastructure. A lot of satellite data is now IP-based packet data. Routers and switches connect the endpoints to the satellite link. The satellite modems themselves are often connected into the routing and switching infrastructure. Everything is running IP. Protecting bandwidth for mission-critical applications is as important as protecting customer data from eavesdropping. That’s what my focus was: making sure that the infrastructure is handling data the way it should.
The first part of my presentation was about segregating user traffic – making sure that customer A’s data stream is not seen by customer B. Either 802.1q VLANs at Layer 2 or MPLS at Layer 3 is often used to segregate user traffic. This was about alternatives to encryption for protecting user data.
My other talking point was about network management, since you need to watch the network to make sure that it remains secure and that it is properly transporting customer data. One of the major factors is good QoS design and implementation. One customer’s data, say internet radio or large file downloads, could adversely affect another customer’s critical data (e.g., voice). Without an NMS providing visibility into the network’s operation, how would you know that the QoS implementation is working? You could use the CLI to check, but I doubt that you would do it very often.
In the first figure below, a congested link (aren’t all satellite links congested?) is properly prioritizing the data. The low priority packets are being dropped and fewer packets are being dropped in higher priority queues, with the high priority queue not dropping anything. The high priority queue is typically the Express Forwarding (EF) queue, handling real-time traffic like VoIP.
In the next figure, the real-time traffic class is dropping packets too. Perhaps the real-time queue was under-provisioned, or maybe the real-time traffic load increased beyond the original design parameters. For example, you could have configured the link to handle four concurrent G.711 calls with policing enforced to reserve bandwidth for the data applications. G.711 uses about 90K-100Kbps per call, or nearly 400Kbps of voice traffic for four concurrent calls. If the number of calls increases, possibly due to additional staff at the site, the link is now under-provisioned and will start dropping packets.
Only by monitoring the individual traffic classes will you know what is happening and whether important network traffic is being dropped. That would be important to you if the service level agreement contains penalties for poor performance of important applications.
Another thing to keep in mind is that you may need to periodically examine the high priority traffic to make sure that there isn’t any undesirable traffic running in the high priority queues. I was working on a case last year in which voice traffic over a satellite link was being prioritized. When we examined the traffic in detail, we found that a big chunk of it was voice that was running to/from a free IP voice site on the Internet. The business-critical voice traffic was being overwhelmed by people who were running non-business-critical voice applications. A simple ACL was all it took to classify the business-critical voice separately from the non-business-critical voice.
What are your high utilization links doing?
-Terry
_____________________________________________________________________________________________
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html
