LoveMyTool - Open Community for Network Management and Monitoring

On-the-Fly Network Analysis at 10G - Are You Crazy? (By Jay Botelho)

With traditional network analysis on a 1 Gigabit (1G) network, you had a lot of flexibility. If a problem occurred on your network, you simply connected your network analyzer, started a trace, and determined the problem. If the problem occurred in the past, you would attempt to replicate the problem and solve the issue, or perhaps just wait for it to happen again. But with 10G there’s way too much data to operate in this “point and shoot” mode.

Instead of operating in the reactive way you did with 1G, you need a different approach when handling your 10G networks. With 10G, you need to identify key analysis points, put equipment in place that can monitor 24/7 while both reporting real-time key performance indicators and saving all network data for forensic analysis, and record network data at your peak data rate with zero data loss – always! When a problem is detected, you’ll already have the data stored and you can simply rewind data (rather than waste valuable time replicating the problem), analyze that data, and identify the root cause of the issue.

Identify Unauthorized Video Traffic (by Jay Botelho)

Your colleague sends you one of those hilarious viral cat videos; you watch and begin to laugh. You look to the side pane and see another hilarious cat video; you can’t help yourself and click on the next one in the queue. You have fallen under the spell of YouTube, and this is from someone who doesn't like cats. You are not alone.

Whether it’s watching a video for pleasure during your work day or using video for your job – check out “Seven Ways Enterprises are Using Video in Everyday Business” – video is beginning to compete with mission critical enterprise application data. As the volume of video explodes, as it’s predicted to do between now and 2015, this could become one of the most serious issues facing your network. Video demands high quality of service and is one of the most unpredictable data types on your network when it comes to packet sizes and packet bursts. But how do you know who the video bandwidth hog is and whether or not they are using video for business meetings or just watching a cat play a piano?

The three approaches below can help you determine who is inappropriately using video and bogging down your network, and whether the video sources are inside or outside the company.

Understanding Packet Path Critical to Analyzing Application Problems (by Chris Greer)

Close your eyes and imagine that you are a packet (I know it sounds nerdy, but stick with me here). You’re leaving the NIC at the client end, and you are on your merry way to the application server at the other end of the connection. What is the first switch and port number you enter into? Which port are you forwarded out of? Which switch is next? Which routers are involved? What if you hit a roadblock, where do you get re-routed to?

Now this is probably the most important question – Are you sure you know the path betwen client and server?

Most network people know their systems pretty well, and may be confident about the path of a packet between clients and servers. But with moves, adds, changes, upgrades, and servers being made every day, be careful about assuming that a path from A to B is well documented and understood. Be especially careful about this assumption when installing analysis gear to capture a trace file and analyze the traffic. After all, there is nothing worse than getting a great analyzer installed where we assume traffic to be, starting the capture, reproducing the issue, then digging through the traffic – all to find out that what we’re in the wrong place.

How to Find the Path

There are some great tools out there at display the path a packet takes from client to server at layer 3. But one of my favorites – the OptiView XG – also shows the layer 2 path through the switches as well. It does this by using a feature called Path Analysis.

Real World Testing through Emulation! Plus a very cool FREE tool to test you network, website, application servers and more…at the end! (by The Oldcommguy®)

I decided to study an instrument that helps Network Architects test and predict new applications deployments, installations, WAN predictability, Cell Backhaul services and much more!

I found some very interesting and important information and why you should use an Emulator and not a Simulator!

OK, Lets first define what a real Network Architect is, the kind of professional that would do Emulation –

The fourth and Highest level of Network Personnel is the Architect!

The fourth network level is where we meet the most senior and the most capable of the Network Engineers. This level is not only where the most difficult issues are solved but this is the home of the Network Architect. This level is where the future design of the network and its applications comes from and is the main focus. This is the level where the Business goals and growth meet the reality of network and application design implementation. The Architect can develop, define and present the value of the network in relationship to the business goals of the company. This level is where all future growth design, testing and purchase value come from. Some may call this the “What if Level” – What if we add 50 new employees to the main application with 50 new VoIP phones, What if we open a new remote facility ..Etc – What will we need to do to make sure that the network will be able to deliver these additions/changes. Timing is an essential element in deployment considerations!

At LoveMyTool we are fortunate to have two real world Analysts that share their knowledge monthly with you - Tony Fortunato and Chris Greer!

This is from my article Four Types of Network Personnel- http://www.lovemytool.com/blog/2009/10/four-types-of-network-personnel-by-tim-oneill.html

So now we know the correct level of Network personnel that would want to be this interactive and focused on the network growth and application success.

To be proactive and test one now has to understand the difference between a network Emulator and the Simulator.

The three most important differences are:

Application vs. Network – The Fight is On! (by Jay Botelho)

Users are experiencing slow Application Response Time (ART) and the blame goes first to the network, so the network engineer - you - must once again climb into the ring for the classic match between network and application performance. The best outcome is a knock out in the first round, allowing you to address the frustrated user as quickly as possible. So, what can you do to help guarantee that the fight will be quick?

The Weigh In: Create Your Baselines

In order to determine if users are experiencing unusual latencies, you of course have to know what is usual on your network. Part of your preparation for the fight is to be sure to baseline your network, with a focus on both network and application latencies, before entering the ring. Be sure to assess latencies across a wide range of users (especially those in different physical locations) and your full range of applications. When possible, collect network traffic at multiple locations, with one being as close to the users as possible and the other as close to the application and data servers as possible. The value of a baseline is in performing trend analysis, so run baselines at regular intervals to possibly even see issues before users report them. It’s impossible to predict the winner if you don’t know your network’s and applications’ normal behavior, as well as how new applications may affect your network.

Analyzing slow applications? Capture on both sides of the connection (by Chris Greer).

When firing up Wireshark (or any other packet analyzer for that matter) to capture traffic on a slow application, one of the first questions that usually comes up is –

Should I capture on the client side or server side?

For years now, this question has been debated among analysts and continues to be a matter of preference, experience, and all too often, timing. Sometimes we don’t have the time or gear to properly capture on the server side, so we are left to the client end.

So which one should we capture on? Well, as a packet geek who wants as much information as possible about a problem, I say BOTH! The best case scenario is to setup a capture on the client end, as well as the server end, simultaneously capturing traffic while the problem is occurring. At times, this may be the only way to pinpoint the real underlying problem.

How can we capture on both sides?

Free New IP Tool - The IP Inspector (by Dan Klimke)

All Network Geeks love new toys and tools and here is a very cool new tool FREE from Fluke (for some info) the IP Inspector!

The Free tool is a limited time offer so get you copy today and start reviewing your IP world simply and quickly!

 Press here -  

Fluke Networks is offering this handy new software utility, the IP Inspector™ to help all Network Managers.

This free tool allows you to discover active devices connected to your IP network and includes key information about each device.

Check out the main screen picture - chock full of important IP information. Supports IPv4 and IPv6!

Click on the picture to expand or better yet go and download to see this cool  free tool in action!

 

Click below to get the Main features of IP Inspector:

 

How to Troubleshoot Web-Based Application Performance Issues (by Josh Stephens)

Application Performance is always the issue!

Troubleshooting application performance is one of the most common tasks that network administrators and sys admins do on a daily basis. Many of today’s applications are web based which can complicate troubleshooting as the application itself may be on a network that you don’t control and that is distant to your users. Likewise, most web based applications can be accessed from anywhere. This means that users at remote sites and telecommuters may report performance issues that you’re responsible for solving. 
When troubleshooting this type of application performance problem there are three main things to understand before you start troubleshooting.

First, you need to understand which part of the application is running slowly. Even a simple web based application can have many parts. For this example, we’ll use a basic shopping cart based ecommerce site. Typically, an application like this would involve steps like these:

• Loading of the initial web page
• Searching or browsing to the desired item
• Selection of the desired item
• Adding it to the cart
• Reviewing the cart
• Submitting the order
• Processing payment
• Display of order confirmation

The Age of Spotify: How to Keep Your Network Running Smoothly with an Influx of Superfluous Data (by Jay Botelho)

With the debut of Spotify last month, Internet music access entered a whole new realm, offering access to 15 million songs with excellent sound quality (160-kbps Ogg Vorbis format). What does this have to do with network management? Well, since users can listen to any track on any album legally, can start playing music almost instantaneously without experiencing latency, and it’s free, you can bet you’ll be seeing Spotify on your list of most active applications on the enterprise network real soon.

So, the $64,000 question is, will you deny employees access to this Swedish treat (Spotify was started in Sweden in 2008) because it might bog down your network? Applications, both commercial and for the enterprise, are growing both in number and complexity, and are displaying a rich appetite for network services.

The most common enterprise response right now is to increase network capacity from 1G to 10G on key network segments, and with the commoditization of 10G equipment and the associated price competition this isn’t a bad option. But one hidden cost in this transition is the need for network performance and analysis solutions that are truly able to monitor and troubleshoot data at these much higher data rates. The bottom line is that 10G introduces unique network monitoring and troubleshooting concerns that should be addressed alongside the deployment of new equipment.

Slow Applications? Don’t Overlook Packet Loss (by Chris Greer)

Sometimes when we are tracking down the cause of performance problems, we can get lost in the nitty gritty details. Especially when dealing with a multi-tiered application, a complex array of load balancers, application accelerators, or the many virtualization technologies, troubleshooting a slow application can be a daunting prospect. 

But never fear. When we are looking for that golden nugget, the ultimate needle in the data center haystack which will resolve our priority-10 performance problem, we may overlook some of the heavy hitting speed-killers which are easy to spot with the right tool. So next time a problem strikes, resist the urge to pour through user privileges in the domain or dig through the back end SQL data for the bad call, and check out a few of the basics. One of which is packet loss.

Packet Loss – Really? In Today’s Networks?