There are ways to make these network blind spots visible, but to get the right prescription you need to first determine the type of virtualization that needs to be addressed.

Standalone VM Systems
Standalone VM systems have multiple VM guests, but a single VM host. The host is the physical hardware, while the guests refer to the virtual machines running inside of the physical server that can be used to run various applications which share the overall hardware platform. Standalone VM systems are how virtualization got started, and this is probably still the most common type of virtualization in the market. In standalone VM systems you may have one or more virtual network interfaces (vNICs) per guest and one or more physical network interfaces (pNICs) per VM host, creating a complex flow of both virtualized traffic and physical traffic.

A blind spot will occur in standalone VM systems when processes are communicating between different guests inside the same overall physical system. To remedy this, you’ll want to run additional software, like OmniVirtual, as a part of the virtual system to gain access to the traffic crossing the virtual NICs. This will capture inter-VM traffic and provide you with the visibility necessary to properly analyze both your network and application performance.

Coordinated/Distributed Virtualization
In the case of coordinated or distributed virtualization, the system consists of multiple VM hosts connected via a virtual distribution layer, making both inter-VM guest and inter-VM host traffic invisible to traditional network analysis techniques.

To address this more complex situation, a virtual tap is necessary. This is software that acts like a traditional hardware network tap, running at the level of the hypervisor. It allows users to tap into the vNICs and virtual switches that are connecting the various hosts, and gain access to the packet streams of interest for detailed network analysis. Since the virtual tap runs in the VM layer itself, it is typically vendor-specific so keep that in mind when researching virtual taps. Once a virtual tap is in place, network recorders like WildPackets TimeLine or Omnipliance Core can be connected to the virtual tap and capture network and application traffic as if physically connected to the virtual layer.

Cloud
There are three different cloud scenarios, two of which have similar blind spot remedies to our previously mentioned ones in the sections above: in-house and third party. For an in-house cloud server, this is similar to distributed virtualization in that you’ll have physical access to your systems and can add technologies like virtual taps. For a third-party cloud solution, or Infrastructure as a Service (IaaS), you can install your own software – like OmniVirtual – to perform network analysis on remote VM hosts.

The only time when it is truly difficult to perform network analysis in the Cloud is in the case of Software-as-a-Service (SaaS), or hosted services. Here, you are essentially at the mercy of the service provider, as you will not have access to virtual servers to install software of your own.

Regardless of your network virtualization type, there is almost always a solution to gain full visibility into your network. Just follow the steps above or watch our ondemand webcast for further details.

Network growth results in more network analysis through increased analytical throughput, scope, data storage, and distributed analysis. As your network grows and you encounter these issues, there are ways to scale your visibility so that you’re not looking for a needle in a 10G haystack.

Architect for Visibility
As always, knowing your network is key. Know what traffic is important to your company. Is it mission critical business applications, like order entry, financials, and CRM? Or is it web-based traffic that’s driving your online retail business? Once you decide what, and how much, of this traffic requires ongoing monitoring and analysis, you’ll know where to look to specifically identify the traffic that you’ll want to capture. Building visibility into your network infrastructure can help both of these practices. Through strategic placement of analysis points, you’ll be able to get instant information to fix problems faster.

Visibility includes both summary level monitoring data and detailed network metrics, including visibility into network packet traffic and even specific packet decodes. Only a packet-based network analysis system, like the Omni Distributed Analysis Platform, provides the complete range of visibility required to monitor and troubleshoot today’s high-speed networks, keeping networks running smoothly and guaranteeing the very best end-user experience.

Backbone Visibility
Though often the fastest link in your infrastructure, the network backbone – the aggregation of all your distribution layer networks – can be an excellent point for monitoring network traffic and capturing network data for more detailed analysis. Depending on your overall network architecture, the network backbone may be a roll-up of just about all of your critical network traffic, especially if traffic is driven through a centralized network operations center (NOC), or if your company is a heavy user of cloud-based or other third party SaaS applications that drive network traffic through your WAN link. Using high speed network monitoring appliances on the network backbone can centralize your network monitoring and analysis, and save money by consolidating network analysis into a single appliance.
The aggregated traffic on the network backbone will typically be high speed, with more and more enterprises migrating to 10G backbones. Packet-based network analysis on the backbone means you’ll be interested in all of the packets, so you will likely need an appliance like WildPackets’ TimeLine network recorder, which captures at rates up to 12Gbps with zero packet loss. Timeline network recorder allows you to store all your data for forensic analysis while continuously capturing network traffic. And if you’re already migrating your backbone to 40G, you can simply add an aggregation tap and a few more TimeLine appliances for a complete 40G solution.

Adding Visibility to Virtual “Blind Spots”
Traditionally, north-south traffic was the most important in network monitoring. However, with the explosive growth virtualization, east-west traffic is becoming more and more important in enterprise networks, and poses a new challenge in network and application performance monitoring. East-west traffic is typically traffic moving within a virtual host or a distributed virtual system. Since much of this traffic resides solely within the virtual environment, and therefore never hits a physical network interface, traditional network monitoring and analysis that is done by tapping into the physical network does not capture this east-west traffic. For example, let’s say the order entry system and the inventory database reside on separate VMs within the same host or distributed system. Communications between the order entry application and the database are east-west traffic. Application performance issues between these systems are “hidden” within the VM. To add visibility, you can either install WildPackets OmniVirtual on one of the VMs to gain visibility into the entire host, or, in the case of larger, distributed virtual systems, the use of a virtual tap is recommended. Virtual taps are sold by many tap vendors, and they provide a physical link that traditional network monitoring appliances can access to expose east-west traffic within the virtual system.

For more information about how WildPackets can help scale your networks, check out our ondemand webcast.

Users are continually experiencing garbled and choppy VoIP calls, Internet connections are slow, and you are receiving complaints of poor video quality.

If you answered network bandwidth issues, you are correct. With video becoming the primary data type on networks of all types, it’s a lot easier for networks to become strained and overused, and often not by mission critical traffic.

If you are consistently experiencing these problems, here are some helpful steps to take to prevent bandwidth issues.

Step 1: Create a baseline
It’s always important to know what your bandwidth needs are based on the number of users and the types of applications that are running on your network. Know who is using what, when, where, and why in regards to network segments. This will help you understand the overall demand on your network and allocate bandwidth appropriately. It will also allow you to quickly determine when network usage is exceeding norms.

If new applications, new users, or new devices are introduced be sure to reevaluate your baseline usage.

Step 2: Prioritize critical business applications and tie baseline protocols and usage to those applications
Each network segment may have different protocol priorities because of the specific applications that traverse those segments. Top applications need to be handled based on business importance for the segment they are individually on.

That said, even if you prioritize your business applications, any protocol that is not performing well could affect overall application performance. In order to determine what application might be causing problems, it is essential to have a network analyzer that can break down and show individual flows and their performance. The network analyzer can provide visibility into the weakest link as well as options to sort application flows with various criteria choices.

Step 3: Use packet shaping technologies
Packet shaping allows you to prioritize certain network traffic, like key applications or real-time data (like VoIP) over other, less critical traffic on your network. For example, if you run an online store that is the backbone of your business, HTTP traffic to and from your web servers is critical. Packet shaping technology can give this traffic priority over everything else, ensuring the best possible user experience for your online customers.

Step 4: Prune your protocols/traffic
Most corporate networks have unnecessary traffic which can consume precious network bandwidth needlessly. Check for protocols that may no longer be necessary on your network, or that could be network hogs, like SNMP, to determine if they still have a purpose or if they are being misused. If they are no longer mission critical, make sure your packet shaping technology treats this traffic with the lowest possible priority.

Along with continuously pruning your network, be sure to constantly monitor your network. The best monitoring solutions will allow you to archive packet data to disk, providing a complete recording of network activity. When your monitoring solution indicates problems, simply “rewind” your network to determine exactly what the issue is. Whether it’s a surge in web-based sales due to your latest promotion, or employees streaming the Stanley Cup playoffs, it’s up to you to know what your network can handle, and up to your network monitoring and analysis solution to let you know when bandwidth issues are about to occur.

Protocol analysis is a subset of packet analysis. Protocol analyzers interrogate packet headers to determine if the protocol is being used for communication, and what type, like HTTP. This form of analysis is strictly for the communication layer and is best served if you are trying to solve basic connectivity or configuration issues or simple timing issues.

On the other hand, packet analysis dives deeper into the packet for analysis. Packet analyzers address both the packet header as well as the payload, which contains critical information about applications and their operation on your network. Packet analyzers can answer the deeper, and often-asked question, “is it the network or the application?” The evidence is clear when you dive into a network flow for a user with a problem and see in the decode “Process ID 169 was deadlocked with another process and has been chosen as the deadlock victim. Re-run your command.”

Need a deeper explanation of troubleshooting end user experience with packet payloads? Check out this post on LoveMyTool.

This week, you will not only find us at Interop Las Vegas, but also our full range of Omnipliance solutions will be a part of the InteropNet!

Preparing for Interop
Being a part of the Interop NOC is challenging in several ways. First, you are working in a research and development environment that has the most advanced wired and wireless technologies.

Second – and maybe the most challenging – is Interop vendors and attendees use as much bandwidth as possible to ensure that product demos go on without a hitch and to stay connected to the outside world via mobile devices. The number of devices deployed as well as the bandwidth needed to run the show makes operating a highly reliable, high performance network a challenge and the ability to troubleshoot and quickly resolve issues a high priority. This is where our real-time analysis and network forensics on both wired and wireless networks will play a crucial role both in finding and diagnosing any problem.

For the last two weeks, we’ve been working with our fellow NOC vendors and volunteers to create a working infrastructure and testing our Omnipliances interoperability with the other products in the NOC. Together, we helped enable a seamless, end-to-end network application monitoring, analysis and troubleshooting solution that is ready for the show, although our work has just begun.

During Interop
The WildPackets’ Professional Services team will be looking at the real-time health across all the network segments in a single view at Interop and ready to quickly troubleshoot any network issues. With leveraging our expert events and network forensic capabilities, we can easily detect any bandwidth hogs and maintain the high quality runtime of InteropNet.

For wireless, our Omnipliances will help validate the placement of access points and the signal strength. They will validate configuration and optimizations changes that network engineers may make during the show. For example, these changes may include increasing the signal strength of an Access Point (AP), changing a directional antenna, changing what types of clients can connect, or even changing how often an AP will beacon. Also, the Omnipliances can easily detect and investigate BYOD issues when wireless devices are in motion to maintain the high quality wireless experience at InteropNet.

If you want to hear more about our participation at Interop, leave us a comment or come say hello at booth 2059. You can also tour the NOC on Wednesday and Thursday, May 8 and 9.

Why?

802.11ac introduces data rates that exceed 6Gbps – faster than most wired speeds. Even the most sophisticated USB devices based on USB 3.0 (the latest standard) have a theoretical bus speed of 5Gbps, with an effective rate of about 3.2Gbps. So even USB 3.0 does not provide sufficient performance for capturing peak 802.11ac data rates, and every packet counts when it comes to wireless analysis.

In order to effectively and efficiently capture and analyze your WLAN traffic for analysis, you’ll need to look to another device to help you – access points (APs). Using APs as packet capture devices is hugely beneficial because the APs in your network are typically specified to handle the most capable clients that will connect to your WLAN – guaranteeing that you’ll have the capacity to capture whatever traffic is on your WLAN.

Wireless packet capture from APs can be accomplished using two different, but similar, approaches. The first is using remote PCAP (RPCAP) and the second is using custom remote adapters.

Capturing Packets with Remote PCAP (RPCAP)
PCAP is the de facto standard for capturing packet data on a network (wired or wireless) and allows interaction with remote devices to capture packets. In order to capture data for analysis on a remote device, it must be running the RPCAP daemon (rpcapd).

There are two modes that can be implemented when using RPCAP – a passive and an active mode. Active mode will try to establish a connection to the analyzer; the analyzer then sends the appropriate commands to the daemon and starts the capture. This method requires the WLAN itself to have knowledge of when it wants to start an analysis session, and this is beyond the capability of most WLANs today, leaving the active mode as an interesting but mostly untapped capability of RPCAP, especially for wireless analysis.

For this blog, we’ll focus on the passive mode, which is the most common and the simplest. In passive mode, the analyst directs the analyzer to the devices to be used for packet capture by providing the IP addresses of the device(s). The analyzer then connects to the remote daemon and is provided a list of available interfaces that can be used for packet capture. The analyst then selects the interfaces of interest and starts a capture just as if that adapter was connected locally. All channel and band choices are made directly on the AP, or through the AP controller software.

Now, if you are interested in this type of capture method, your next step is to find access points that support RPCAP. This feature is not easy to find, as it is not necessarily a “marketed feature” by manufacturers. That said, we have already tested RPCAP for wireless analysis using several devices, including:

• Aerohive: Model HiveAP 120
• Ruckus: ZoneFlex 7363 (requires ZoneDirector Controller)

Many other AP manufacturers have told us that they also support RPCAP across most if not all of their AP offerings. If you know of other specific products with this capability, we’d love to hear about them.

Capturing Packets using Custom Remote Adapters
With custom remote adapters, the APs directly deliver data to the WLAN analysis software. This feature has been a part of WildPackets technology for a while and we have custom adapters to collect from Cisco, Aruba, and Meru APs. The process for developing a custom remote adapter is very similar to that of RPCAP but it requires a little more interaction between network analysis software vendors and hardware equipment manufacturers since the tunnel used to send the packets between the AP and the analysis software is proprietary to each equipment vendor and therefore requires a “custom” adapter.

Now, in order to get this system set up, go into your controller software on your AP and pick either an AP or a radio and put these into promiscuous mode. If an access point has multiple radios, you can put some in promiscuous mode and leave some in network mode so user connectivity is not affected. Most enterprise installations have sufficient wireless coverage so even if you take a few APs and put them in promiscuous mode, network performance will not be degraded. Once this configuration is done, you provide the controller with the IP address where your WLAN analysis software is running, and the AP immediately begins streaming packets to the analyzer. Now simply start your capture on the specific custom remote adapter and begin analyzing.

Remote adapters in general provide another benefit besides being capable of performing packet capture for the most demanding networks. They also allow analysts to capture packets for analysis anywhere in the network – worldwide – without leaving their desks. WLAN analysis requires that packets be captured within a few hundred feet of the area where the problem is being reported. There’s no way around this. Now that 802.11 technology has become so popular, problems can be happening anywhere, and it is not feasible to have an analyst close enough to every installation to be able to just walk over with the network analyzer and collect data. Remote adapters provide the flexibility to capture WLAN data anytime and anywhere.

For the most part, 802.11ac is really a “lessons learned” from 802.11n. Below we break down the essential ways that 802.11ac has improved upon 802.11n and how it results in an amazing improvement in aggregate WLAN capacity.

More, and More Efficient, MIMO (Multiple Input Multiple Output)
802.11n has become the de facto wireless standard – and many people have moved to this new standard and are already seeing huge benefits. 802.11ac takes many of the new technologies introduced with 802.11n, including MIMO, and drives them even further.

In 802.11n, the maximum number of MIMO streams is four. Addition of MIMO streams creates a linear increase in overall throughput, and with 802.11ac the maximum number of MIMO streams is increased to eight. So with no other improvements (even though there ARE many more), 802.11ac would double the overall available throughput.

Along with an increase in the number of streams, 802.11ac also introduces higher encoding rates when converting digital traffic for RF modulation. This higher encoding rate results in an overall throughput improvement of over 40%, which is realized for each individual data stream.

As you can see, we’re already on our way to some significant improvements!

Smarter Channel Bonding
Channel bonding was also first introduced in 802.11n. In essence channel bonding creates new, data only channels that are wider than the existing 802.11 channel definitions. Specifically, a single 802.11 channel is approximately 20MHz wide. Channel bonding “steals” some space from adjacent channels and increases the overall channel width to, in the case of 802.11n, 40MHz. This effectively doubles the throughput for the data packets. All management packets are still sent using the standard 20MHz bandwidth and on standard channels to accommodate backward compatibility.

802.11ac increases the number of channels that can be bonded, creating even wider channels that can handle even greater throughput. Channel widths of 80MHz, and optionally 160MHz, have been added. Channel bonding is a bit of a double-edged sword, because although users benefit from the increased throughput, the number of channels available for use effectively decreases. This is often not an issue in consumer environments, where WLANs typically consist of a single AP and very little overlap with other adjacent WLANs (like your neighbor’s). In fact, this is an ideal case for greater channel bonding since only one channel is usually in use anyway, so why not maximize the bandwidth of that channel to take advantage of as much spectrum, and as much throughput, as you can? Channel bonding in enterprise environments can be a bit more tricky. 802.11ac tries to deal with this by limiting operation to only the 5GHz band, where the original channel allocation is wider, and more overall spectrum is available. But there can still be issues, and we’ll likely cover this in more detail in a future blog post.

So, if you’re keeping track, additional channel bonding in 802.11ac doubles or quadruples the maximum data throughput, offering yet another significant improvement!

Multi-User MIMO
Earlier we described how 802.11ac uses eight spatial streams, while 802.11n only uses four. But this is not the only MIMO improvement in 802.11ac.

Multi-User MIMO (or MU-MIMO) allows multiple stations to transmit or receive the exact same data simultaneously. For example, if you’re hosting a Super Bowl party and you want to have the game displayed on all your video screens (say two HDTV monitors and an iPad that can be moved around the house), 802.11ac can distribute this video stream simultaneously to all these devices. Without 802.11ac, even for an identical data stream, the wireless protocol required you to send the data stream to each device separately, and serially, thereby limiting the effective throughput for each individual device. In our Super Bowl example, and without 802.11ac, this means each device would actually see an effective throughput less than one third of the available throughput since the data would be sent three times, once for each individual device.

The tally of increased performance continues to grow by leaps and bounds, with MU-MIMO providing significant improvements in effective WLAN throughput.

Additional Updates
Additional improvements, including more efficient and effective use of beam forming (another optional feature) and other layer 1 and 2 changes, round out the list of substantial improvements. So, when the accounting is all done, the aggregate capacity of the WLAN grows from 600Mbps with an all-out implementation of 802.11n to 6.93Gbps with an all-out implementation of 802.11ac, better than a 10x improvement!

Stay tuned in the coming weeks as we translate these technical improvements into the real-world improvements we all hope to take advantage of as 802.11ac begins to roll out. First up will be improvements for mobile, battery-operated devices, including those we’ve become dependent on, like iPhones and Droids.

Luckily, if you are using OmniPeek, problems of any type, whether application or network, or common or rare, can be easily remedied. Let’s take a look at some common user experience issues and how OmniPeek can help to identify the root cause and guide you towards a permanent solution.

Network Downtime
Fortunately unplanned network downtime is a pretty rare occurrence nowadays, but if it does occur the response must be instantaneous. With OmniPeek you can immediately assess the scope of the outage, from a few specific users to an entire subnet. If distributed, 24×7 analysis is in place, you can rewind the network to see exactly what was going on when the outage occurred, providing the best clues possible for determining the root cause, which in this case is probably equipment failure somewhere in the network path of the effected users.

Not Enough Bandwidth? Find the Hog
Bandwidth issues typically arise not because of a lack of bandwidth, but because a user or users are consuming an abnormally high amount of bandwidth. This is becoming more common with the wide availability of video streaming sources, particularly those that are not work related. The Compass dashboard in OmniPeek is an easy way to isolate bandwidth hogs, allowing you to identify not only the user but the type of traffic, providing the ammunition you need to ensure that network traffic is strictly business related.

VoIP Quality Issues
VoIP is the most commonly used real-time protocol on corporate networks. Given its real-time nature, it is extremely sensitive to network problems like too much latency, dropped packets, and jitter, much more so than “regular” network traffic. For real-time data to be useful, it must arrive in order, and within a few hundred milliseconds of being sent, otherwise it is no longer “real-time” and doesn’t fit into the overall conversational flow. Problems with real-time data will continue to grow as more corporate video is transmitted over IP networks, and as more wireless networks are used for the last 100m of data delivery (voice over Wi-Fi, or VoFi).

From a network perspective, VoIP, VoFi, or video over IP are just data on the network. In order to identify problems with real-time traffic, you first need to isolate the traffic, while still seeing it in the context of the overall network. To do this, you can use the Voice and Video dashboard in OmniPeek to see how real-time traffic is coexisting with the rest of the network. Then, the Calls and Media views will allow you to see a more detailed analysis of the packet-by-packet performance of the real-time flow, including detailed analytical metrics and a bounce diagram so you can pinpoint exactly where the problem is, and compare it with network activity to correlate real-time transport problems with overall network usage.

If you are experiencing another kind of reoccurring issue on your network, please leave us a comment and we’ll address best practices for remedying this issue.

Below we go into where you should set up your capture points to get the most visibility on your high-speed network.

Capturing Data on the Network
Typically, if you are connecting directly on the network you are going to collect data through traditional SPAN ports, mirror ports, or taps. This is a well known method that is used frequently to obtain a passive feed from a network, so the process and any associated configuration should be familiar. One challenge does arise when virtualization is in use, as you will miss intra-host traffic when capturing only on the physical network. Don’t worry, below we will explain how you can capture this traffic as well.

In this video, you will see where to capture traffic if you are in the data center, a corporate campus, or remote office.

Capturing Data on vSwitch
Data on virtual servers pose a unique challenge, as oftentimes much of the data never leaves the virtual server – for example, communication between and application and a database running on the same virtual machine. In this case, capturing data off the span port of the virtual switch or hypervisor allows you to get visibility into intra-host traffic. To do so, you either need to have network analysis software running directly on the server, or you need a “virtual tap” (a piece of software) that can perform the function of a traditional hardware tap and copy network traffic off to a separate physical tap which can then be utilized in a traditional fashion. If you’re running the network analysis software directly on the local VM, remember to allocate enough memory, IO, and disk space to accommodate your network analysis needs.

Capturing Packets in the Cloud
Cloud computing comes in many shapes and forms. If you are trying to capture data in a private cloud, the practice and procedure will be similar to that of capturing on your vSwitch. If you control the infrastructure, you can sniff anywhere. If you are a service provider, you need to carefully consider data access, data separation, and customer privacy issues.

If you are using a third-party cloud service, the ability to capture and monitor traffic is going to depend on the implementation. If you are running software-as-a-service (SaaS) from a provider, it will be hard to have sniffing rights, so your last point of knowledge about your traffic will be at WAN link. This will still allow you to obtain valuable analytics, like round trip latency, which will provide a good indication of the overall user experience. However, if users are experiencing latency and you think that it might be an application performance problem and not an overall network problem, then it will be difficult to analyze the situation. For example, a database connection issue or database contention may be very difficult to troubleshoot. But then again, isn’t that why you’re paying your SaaS provider?

If you are employing infrastructure-as-a-service then you will have the ability to sniff your own traffic by installing a network analysis software probe on the hosted virtual server to see all the traffic on the virtual  server, thereby restoring your ability to analyze application issues that may otherwise be hidden.

If you are working within another environment and would like tips on capturing data, please leave us a comment.

Organizations both big and small have suffered from DDoS attacks in the last few months. Although DDoS are pretty “old school,” they remain highly effective in bringing down websites and web-based applications. The methods behind these attacks have become more sophisticated, with much greater horsepower behind the attacks, and much more obfuscation as to the sources. But network monitoring and analysis are also rapidly improving, offering new strategies to both protect your network and clean up your network if an incident occurs. Below we detail how you can be both proactive in protection and also reactive if you fall victim.

How to Protect Yourself
DDoS attacks are designed to block network access for legitimate users. These attacks create extremely large volumes of useless traffic, causing various network resources to become saturated thereby blocking access for users and customers. The attacks predecessor, Denial of Service (DoS) attacks, affected servers by using up resources signaling the start of a conversation with no intention to converse. To mitigate these attacks, you could use ACLs (access control lists) or firewall rules to keep the attack traffic from reaching the server. But with DDoS attacks, the first “D,” or the distributed nature of the attack, makes blocking offending traffic extremely difficult, and it broadens the scale of the attack from a few machines to a widespread attack from machines worldwide that have been infected by bots.

With today’s DDoS attacks it really comes down to network protection. It is therefore very important to:

• Use network analysis tools to capture all the data in one place, although attacks come from a large number of IP addresses, these attacks are fairly homogenous in the IP layer. If you can find a common behavior at the packet level then you can filter out this traffic.
• Set up alerts to isolate questionable behavior. If you are experiencing a request that requires more data than normal, or the number of users accessing your website suddenly spikes, it might be the beginning of a DDoS attack.

How to Clean-Up the Mess
Having a network recorder with network forensics in place is key to helping you clean up your system. Network forensics is the process of capturing and storing data packet-level network data 24X7 for analysis if a problem occurs. This process gives you a complete picture of the problem and allows you to gain crucial information, including exactly where, and how, the attack was orchestrated. Armed with this knowledge, you can build new rules for intrusion detection and prevention systems (IDS/IPS), or new alarms for the network monitoring and analysis solution, so you’ll be notified at the first sign of a renewed attack. If you are interested in learning more about network forensics, check out this Rich Report podcast featuring Jay Botelho, Director of Product Management at WildPackets, here.

DDoS attacks are on the rise and even large banks like Wells Fargo have trouble protecting themselves and reacting to these attacks. To help mitigate some of the headaches, have a game plan in place both for proactively stopping these attacks and cleaning up after these attacks if you are targeted.