pointer

Tag Archives: network analysis

10G Upgrades: Fact or Fiction?

Posted on by .

    When it comes to network bandwidth and data speeds, for the most part we are still living in a 1G to 10G-transition world. That’s not to say that no one has invested in 10G or even 40G, but the pool of enterprises that are moving in this direction is still quite small.

    Why?

    It is not a technology issue – there are plenty of products that are out there and ready to handle 10G. The issue is cost. Businesses just don’t need 10x the bandwidth and are not willing to pay 3x the cost. Instead they are opting for multiple 1G channels. The Dell’Oro Group recently published a report on the underwhelming statistics for companies moving to 10G.

    There is, however, one common use case for enterprises moving to 10G. Below we illustrate this common use case, and some best practices that have stemmed to monitor and analyze data at 10G.

    Common Use Case for Moving to 10G
    One of our customers, a large manufacturing company, made the transition because of significant growth in their backup traffic. They were saturating 2x and 4x Gig channels when their backup would kick in at night so they started looking to virtualized architectures for help. After that transition, they needed 10G to support their virtualization server clusters, which had grown tremendously. Although this particular example is with a manufacturing company, this is one of the most common reasons we hear across many industries for initially making a switch to 10G – too much backup traffic, and not enough time.

    What to Think About Before You Switch to 10G
    Migration to 10G usually happens first at core switches and in the network backbone – and the same is also true if you’re already at 10G and planning a move to 40G. As we mentioned above, cost is a huge factor in folks holding back, and it is not only the equipment costs. Cabling, rewiring, and increased power consumption can all be issues, depending on the magnitude of the migration, so don’t forget to factor in ALL the costs.

    Network Monitoring and Analysis at 10G
    As part of your migration plan, remember to upgrade your network analysis and troubleshooting solution(s) as well. Network analysis at 10G is a completely different beast, and a beast it is! The days of point-and-shoot, real-time analysis go by the wayside at 10G. Network recorders are a must. Installed at strategic locations, like WAN links, data centers, etc., network recorders keep an ongoing record of all your network traffic. If you start getting alerts, or alarms go off, you simply need to rewind your network traffic to see exactly what the problem was. If a particular user is having problems or you need to retrieve packet-level data (network OR application) for a compliance investigation, again, the data is there and instantly searchable and retrievable.
    With 10G 24×7 recording and monitoring are requirements. Simply connecting an analyzer after a problem is reported is just not viable – there’s just too much data, and trying to reproduce problems is a nightmare. You need to capture the traffic – packet-by-packet – so you can immediately recreate the conditions to analyze and solve the problem.

    With 10G you also have to streamline and condense what you want to analyze. Attempting to monitor and analyze every type of data that streams through your network can be tedious and there is a key limiting factor – storage capacity for all that data. If you do not need to analyze VoIP data, for example, then take it out of the mix. It will reduce the overall storage required and typically increase overall speed of network traffic that can be processed and stored.

    2013 might not be the year for you to transition over to 10G, but it is the year to start planning and thinking about what that transition will look like, especially if you are looking to move to a more virtualized data center. If you are interested in learning more about best practices for moving to high-speed networks and the new role that overlay networks play in this transition, check out our webcast “Packet capture in high-speed and data center networks.”

      Best Practices for Network Monitoring on High-Speed Networks

      Posted on by .

        High-speed networking – networks operating at 10Gbps or greater – is growing across the globe, from San Francisco to Stuttgart. In fact, while at CeBIT last week our discussions with visitors to the booth often turned to corporate initiatives focused on 40G network upgrades, and of course, the ability to monitor, analyze, and troubleshoot at these blinding speeds. And as networks get faster the data they carry is becoming increasingly hidden inside overlay networks created by VM infrastructure, software-defined networks, and layer 2 multipathing.

        Given these increasing challenges, here are a few best practices for monitoring, analyzing, and troubleshooting your system when poor performance or errors occur.

        Monitoring on High-Speed Networks
        With today’s network speeds and complexities, network monitoring is no longer a “one size fits all” proposition. You first need to decide what it is you want to monitor. Your devices and assets? Your network performance? Your application performance? Although there may be other ways of dissecting the network monitoring market, this approach is very understandable, is consistent with current industry analyst market segmentation, and significantly simplifies your search for commercially available solutions. And it’s certainly not an either/or choice. Your company most probably needs to monitor all of these functions, although not all may be your individual responsibility. And some functions may be much more important to your business than others. What’s most important is to define your requirements based on this breakdown. Once your requirements are well defined, you can look for a solution, or multiple solutions, that meet your needs. Many solutions available on the market attempt to address several, if not all, of these areas of network monitoring, but each has its strengths and typically excels in only one area.

        Analysis on High Speed Networks
        When we talk about analysis on high speed networks the focus shifts a bit. Although it seems a bit geeky, the best way to better define your analysis needs on a network is to reference the OSI Model and its seven layers of networking. Just to review, these are the physical layer, the data link layer, the network layer, the transport layer, the session layer, presentation layer, and the application layer. Solutions typically marketed as “network monitoring and analysis” focus on the first four layers. These solutions are often based on flow-based technologies, for example NetFlow or sFlow, and have little to no visibility into the session, presentation, and application layer. Solutions marketed as “application monitoring and analysis” specifically focus on layers five through seven, leveraging application characteristics instead of network data as the basis of their reporting. Each solution type does have some overlap, but this is definitely an area where one class of solution excels over the other, depending on your needs.

        Solutions based on packet capture and analysis are designed to address all seven layers of the model, and do so quite well. A packet capture solution will passively analyze each and every packet on the network, compiling data corresponding to all network layers. But again, no one solution excels in all areas, and although a packet-based solution will certainly give you the most breadth, they still tend to excel at network layer analysis (layers one through four) versus application layer analysis.

        We are holding a webinar on March 20th at 8:30am PDT to discuss this topic further. If you have any specific questions that you would like us to address during the webinar, please post a comment. We’ll also have some time after the webinar to discuss any questions that you may have.

        Blind Spots on High Speed Networks
        Virtual servers are now commonplace. Virtual storage is taking the IT market by storm. And the virtual data center and virtual networks are visible on the horizon. Virtualization provides tremendous efficiencies, reducing the cost of equipment, management, and even utilities. But as with most technological shifts there are consequences, especially in network analysis, that must be addressed. Virtualization, regardless of the “flavor,” creates a blind spot – a loss of visibility into traffic between virtual applications or virtual systems – when using traditional network analysis products and techniques.

        Blind spots in virtual servers are the easiest to address. These exist when inter-application traffic all resides within the same virtual host. Since the traffic never hits a traditional hardware NIC, capturing the data through traditional means is ineffective, and the data is essentially hidden. A simple solution is to carve out a small segment of the virtual server to run packet-based network analysis software. Since the software is running on the VM, it has access to the virtual NICs that are part of the VM, giving the software access to traffic that is communicated between each of the virtualized applications on the server.

        Virtualized storage is less prone to this problem as the storage systems are physically separated from the virtual application servers (in most cases) so the traffic between the applications and the storage systems traverses a physical hardware NIC, providing a traditional capture point for network monitoring data.

        Virtual data centers and virtual networks are just beginning to be deployed, and mostly by cloud service providers and not in traditional enterprise networks, though the technology will certainly filter down to the enterprise at some point. Virtual data centers and virtual networks employ new standards, like VXLAN and NVGRE, which encapsulate traffic in distributed VMs, a core technology in virtual data centers. To monitor traffic in these environments, not only does the solution need to have access to virtual NICs, as it does when monitoring virtual servers, it also needs to strip the actual TCP/IP traffic out from these new encapsulation layers to be effective. Since this area of virtualization is very new, network monitoring products are just beginning to address these challenges.

        Networks are becoming faster, and much more complex. The days of a “one size fits all” network monitoring and analysis solution are gone. Network analysis requirements must be very carefully considered, and multiple solutions are typically needed to address these complex environments, particularly in large enterprises. But by breaking down your network analysis requirements as defined in this blog you’ll be able to quickly find the solutions you need to best address your specific needs.

          Next-Generation Firewalls and Classifying Network Applications

          Posted on by .

            Recently Joel Snyder of Network World wrote an article on next-generation firewalls. Within the article he describes that with next-generation firewalls visibility into the network is a requirement as opposed to a nice-to-have option with traditional firewalls:

            In a traditional firewall, visibility is a nice-to-have, because security policy dictates what ports are allowed inbound and outbound and other tools, such as Netflow analyzers, can be used to dig into traffic. In next-generation firewalls, where the emphasis is on controlling application usage, visibility is a requirement.

            The key differentiator of next-generation firewalls is the use of heuristics to decouple the protocol or application from its usual port. Proper policy enforcement therefore relies on correct protocol identification. Auditing firewalls using information from the firewall itself, such as logs, inherits the same benefits and the same weakness. If an application is misidentified for any reason, the wrong policy will be applied. Additionally, if firewall reporting is based purely on the output from the same firewall, the logs won’t indicate there was an error – meaning that the mistake won’t necessarily be apparent in the analytics, nor will it be easy to detect or understand. It’s critical to know what the firewall’s definitions are for applications so policies can be written correctly and the reporting output can be trusted.

            Or, as Snyder states:

            Applications may have many different names and categories, and compared to ports and IP addresses, we found tremendous variation and ambiguity. Without visibility and knowing how the firewall classifies each application it identifies, you can’t write the rules that make a next generation firewall “next-generation.”

            A useful tool for understanding these next-generation firewalls – how they classify traffic for both policy enforcement and reporting – is a separate external device which monitors the traffic. WildPackets makes a line of network traffic recorders which constantly monitor the network data flow and provide a traditional 5-tuple breakdown: IP addresses and TCP/UDP ports. Viewing the traffic using vocabulary familiar to network and security engineers provides the necessary translation to understand the abstracted application definitions in next-generation firewalls. In short, a network traffic recorder lets you “trust, but verify.”

            It is good practice to audit network traffic, much like businesses audit their accounting. Just as companies use an external auditor to track money, IT should use “external” auditing to track data. The good news is that, in networking, this external perspective is provided by the network recorder: it watches the inputs and outputs objectively without relying on the proprietary jargon of a new device. Additionally, if an anomaly is detected – like a suspected deviation from security policy – the network recorder will have a full record of the recent traffic, so a network forensic search will reveal the full details of exactly what happened.

            Synder concludes his article with this note:

            Overall, we think that the visibility tools we found offer a good start into what is needed for next generation firewalls. All of the products have slightly different approaches, but it was clear that an off-box reporting engine — even if you only have a single firewall — is a minimum requirement to effectively build next-generation firewall policies.

            We at WildPackets agree – in security, it’s imperative to know what the firewall is doing. The tools from the firewall vendor are indeed “a good start.” However, we at WildPackets have to disagree with Snyder’s suggestion that more tools from the same vendor are the next step. For full visibility into policy enforcement, take the same step that businesses take when they’re serious about accountability: use external verification. A network traffic recorder provides that assurance by looking at the packets, because, regardless of the variation of the network applications and the firewall classifications, a traffic recorder shows that the packets don’t lie.