Avoid Traffic Headaches on the Road and in your Network

Traffic congestion on the way to work is a sure way to get an immediate headache. That is why I’m a big fan of viewing live traffic patterns from my smart phone. I get a live view of traffic that shows which routes are congested and clear. With this information, I arrive at the office much faster and in a better state of mind (my co-workers agree).

Wouldn’t it be nice if finding congestion in network traffic was as simple as flipping on your smartphone and pressing a couple of buttons? Maybe someday. In the mean time, to make life as simple as possible, I use dopplerVUE which has Netflow built in, so I can look deep into routers and capture rich details about what types of traffic, which IPs are talking and how much bandwidth is being used. Take a look at dopplerVUE in action below. You can try it out free for 30 days.

If you don’t have access to tools like dopplerVUE, there are free tools that can help you as long as you’re willing to invest the time.


There are basically two types of techniques to monitor congestion - packet monitoring and packet capturing. I’ve listed some free tools for both methods below.

Packet Monitoring
Packet monitors watch the number of packets whizzing by and tell you a little bit of information about them, such as the number of packets and if there are any errors in the packet. But that is about it, you don’t get much more detail. So this method is good for watching long term trends.


1) For Windows users, look at the network interface properties. The display shows you packets sent and received. This is an easy way to see if your interface is working.

2) The Windows command line provides a number of useful tools to determine the performance of your TCP/IP connection. The Netstat command can give you details about each TCP connection including how many packets have been processed. Below is the result of a netstat –e command.

A list of the most common communications related commands available for the Windows command line are listed below:

Packet Capturing
Packet capture actually stores a copy of each packet that comes by which allows you to look at all characteristics of the packet. But all this detail comes with a down side - it will eat up storage space very quickly. So this method is best to capture a small sample of traffic for deep analysis.


1) For packet capture, the gold standard for open source tools is Wireshark. Here is a screenshot of a packet capture done with Wireshark on my laptop. As you can see, every packet is listed with full details about source and destination address, protocol type and data contents.

Wireshark is one of many open source tools that leverage the Winpcap tool for network monitoring. A list of tools that use Winpcap can be found here.


2) Windows server users have access to a similar tool called Network Monitor that helps monitor network traffic. Below is a screenshot of Network Monitor in action.

I hope these tools help you avoid congestion on your way to work and in your network.

Slow Bandwidth? Remove Unused Protocols to Improve Speed

Identifying protocols that contribute to slow bandwidth

I’m always looking for easy and effective ways to improve network performance. When I’m unhappy with network performance I try removing unused protocols to help lower traffic and increase network speed. Have you found any other effective methods that you want to share with us? 

To give this one a try, check the default network protocol settings used when installing operating systems and network drivers. They often include protocols such as IPv6, LLMNR and PGM, which are not commonly used in most networks. For example, if you have Microsoft Vista, you’re wasting traffic with the IPv6 protocol running, unless you’re actually using IPv6. If you remove it, you’ll open up your network and improve speed.

Common unnecessary protocols

IPv6

Microsoft ships IPv6 as one of the default protocols on Windows Vista and Windows 2008. While IPv6 may be a replacement for IPv4, it is not yet a standard protocol for most networks. Auto enabling all devices with IPv6 may be a bit ambitious, since most LANs and WANs simply are not yet supporting IPv6. Check out this Microsoft article on how to remove IPv6.

IPX Network client

If you’re not using Netware, don’t leave the IPX (Internetwork Packet Exchange) Network client installed. Sometimes it’s left over on older systems and can easily be removed. Uncheck the Client Service for Netware box and reboot the system (see Figure 1).

  

NetBIOS

Prior to Windows 2000 and DNS, NetBIOS was the method used by Windows for name resolution. Unless your network is running Windows NT systems, it is pretty safe to stop using the NetBIOS functionality. Check out this article for step by step instructions for removing NetBios from Windows 2000/XP/2003 systems.

LLMNR

Link-local Multicast Name Resolution (LLMNR) is used to connect devices when a well established network is not available. It’s used by both IPv4 and IPv6 networks when services such as DNS and DHCP are not available.  Ever notice your Windows system auto configures a169.254.0.XXX address when the network isn’t available? This allows devices connected via a hub, switch or cross cable to get some connectivity. If your users are always on a working LAN, this protocol may be unnecessary.

PGM

Pragmatic General Multicast (PGM) is a reliable and scalable multicast protocol. PGM is appropriate for applications that require duplicate-free multicast data delivery from multiple sources to multiple receivers. Not doing multicast? Then you do not need this protocol.

Find Unnecessary Protocols

To find out if your network is running any of the previously mentioned protocols (or any others you may not need), try using a packet sniffer. I’ve used WireShark (a commonly used packet sniffer), but have also heard that Microsoft Network monitor, which shows the process name of the application that is creating the traffic, is being commonly used. You can get both of these products for free:

Wireshark

Microsoft Network Monitor

Start your packet sniffer and collect a reasonable sample size, such as 20-30 minutes of data.  Then simply sort or filter by protocol, and see which ones are on your network and causing unwanted traffic. Then simply remove the unwanted protocols to improve network speed and performance. Try this approach and let us know how well it works for you.

What is Fueling Future Network Growth? Your Thoughts...

What do you think is driving future network growth?According to a new Cisco study, many residential, business, and mobile IP networking trends are being driven largely by a combination of video, social networking and advanced collaboration applications, termed “visual” networking traffic.

Service provider networks are carrying a significant amount of visual networking traffic, with more than one-third of the average global broadband connection supporting video, social networking and collaboration applications each month. Maybe social networking isn’t a fad.                                                                             

Cisco VNI (Visual Networking Index) Usage Highlights:

Aggregate Broadband Findings (Q3CY09):                               

- Globally, the average broadband connection (primarily residential subscribers and some business users) generates approximately 11.4 gigabytes of Internet traffic per month.

Per connection per day, this amount is roughly equivalent to downloading 3,000 text emails, 100 MP3 music files or 360 text-only e-books.)

- Globally, the average broadband connection consumes about 4.3 gigabytes of visual networking applications advanced services such as video, social networking and collaboration) traffic per month.

Per connection per day, this amount is roughly the equivalent of approximately 20.5 short-form Internet videos or approximately 1.1 hours of Internet video, whether streamed on its own, embedded in a Web page, or viewed as part of video communications.)

- Top 1 percent of global subscribers generated more than 20 percent of all traffic.

- Top 10 percent of global subscribers generated more than 60 percent of all traffic.

Peak Broadband Usage During Internet Prime Time:

- In an average day over the reported quarter, Internet "prime time" spans from approximately 9 p.m to 1 a.m. around the world. This contrasts with broadcast TV prime time, which is generally from 7 p.m. to 11 p.m. across most global markets.

- 25 percent (or 93.3 megabytes per day per connection) of global Internet traffic is generated during the Internet "prime time" period.

- A peak Internet hour has 20 percent more traffic than a nonpeak Internet hour. The peak Internet hour averages 18 megabytes of traffic per connection (per hour), while nonpeak Internet hours average 15 megabytes of traffic per connection (per hour).

The peak Internet visual networking hour has almost 25 percent more traffic than average hourly Internet traffic.

It’s one thing to imagine the amount of traffic passing through networks every day, but it’s another to actually see the numbers. My favorite statistic is the number of GBs used per connection per day compared to text messages, e-books and music. The numbers are huge! I can’t imagine sending 3,000 text messages per day, can you?

What do you think about these findings? What are the future implications? I’m interested in hearing your thoughts.

Before Adding More Bandwidth…

Does your network reach capacity at similar times every day? If so, before you decide to add more bandwidth at additional cost, think about adjusting traffic patterns at no cost.

As a first step, consider using a network monitoring tool to baseline the most common time periods when your network is at capacity. With this critical information, you can take some pro-active steps to optimize your network traffic.

Move maintenance tasks such as back-ups, updates, source control synchronization and large file transfers to off peak periods to decrease the load on the network.

If you can’t alter the timeline for maintenance tasks, encourage users to schedule bandwidth intensive tasks (video teleconferencing and webcasts) that are not time sensitive to business operations to off peak periods. Most users want the best possible viewing experience and will appreciate being able to schedule online events to take advantage of improved network availability.

Of course, if you don’t have flexibility to adjust traffic patterns to optimize the network, it may be time to add more bandwidth.

Looking to Reduce IT Costs…Optimize Network Traffic

In these days of pinching pennies and saving dimes, the best way to help your organization is to find ways to reduce costs. Do you know which network resources are costing you the most? Answering this question can lead to optimizing network traffic and cutting costs.

For instance, the cost of LAN traffic within your office is usually fairly affordable, however, once the packets hit the WAN, the price tag increases significantly.

You can use Netflow to identify which network resources are adding the most to your monthly bill. Start monitoring the circuits that make up the majority of your high cost list with Netflow and you might find some network efficiencies that lead to savings that have a big financial impact.

To find cost savings, I use a network management tool, dopplerVUE, that has a bandwidth locator that sorts and finds top bandwidth users in networks. dopplerVUE provides Netflow support to give you multiple ways to view traffic in your network.

If you want more details on where all your traffic is going and how to configure Netflow to give you the answers, check out this recent post.

Monitoring Bandwidth Part 2: Examining SNMP Traffic Data

Let’s start by discussing what we really want to know about bandwidth:

1. How much is moving across any given interface?
2. Is the interface maxed out?
3. Is the device or devices beyond this one slow (or down)?

SNMP MIB-II enabled devices provide the following key metrics that will be used to derive answers to 1 & 2.

ifSpeed - The interfaces current bandwidth in bits per second
ifInOctets - The total number of octets received on the interface
ifOutOctets - The total number of octets transmitted out on the interface
Source: RFC 1213

The octet metrics are simple counters that grow as traffic is passed on an interface. Using these metrics we can poll devices two times and use some “simple” math to determine the delta between the polling jobs. This will give us the amount of traffic that has passed in the interval. You can divide this by the amount of time to get an average bit per second rate. Or you could simply use a tool like dopplerVUE that does the math for you (screenshot below).

* Important Tip - The measurement for the size of a file and the speed that an interface passes traffic is not the same. Despite looking and sounding similar each measurement is calculated in a different way. This is a common error. For example, network speeds are notated in bits per second. Files are normally referred to in bytes. There are 8 bits in a byte, then you need to factor in that file notation grows by 1024 not simple 1000s.

Notation examples:
Network Speed
1 Kbps = 1,000 bits per second
1 Mbps = 1,000,000 bits per second
1 Gbps = 1,000,000,000 bits per second

Data file size
1 KB = 1,024 Bytes
1 MB = 1,024 KB
1 GB = 1,024 MB

Now that the amount of traffic is known you can compare this information to the ifSpeed metric to determine the percentage of the pipe that is full. You can figure out the math or let the tools do it for you (dopplerVUE screenshot below).

To answer the final question about if the traffic is causing a slowdown on the network, check the ping response time to the device and devices beyond (if router or switch).

There are many other items we can look at regarding traffic that indicate problems in the network. You can look for packet loss, discards and errors that are occurring (dopplerVUE screenshot below). We’ll explain why these issues occur and how to correct them in a different posting, but you should consider checking these metrics as well.

Implementing a Bandwidth Monitoring Program: Getting Started

Nearly every network engineer I work with is either looking for a way to monitor their bandwidth or ways to improve how they monitor their bandwidth usage. So, popularity wins out this week and the next couple of posts will be a series on implementing bandwidth monitoring.

Why monitor bandwidth usage?
We each have our reasons, here are some of mine:

1. When the network slows, lots of people call and complain, and I don’t like that

2. Need to have data supporting when an upgrade to the T1 line is necessary and validation that we are getting the service we have paid for

3. Helps to understand what servers are being used heavily and when the load should be split into multiple servers

4. Lets me identify high bandwidth consumers and adjust the network topology keeping the key users close to their end systems

5. Allows me to locate end users who are downloading high volumes of data and request they stop during sensitive times (executive webcasts etc…)

Getting started: SNMP enable your network
To effectively monitor bandwidth usage it requires that you have a method of accessing the bandwidth consumption statistics for each device. SNMP is the industry standard and works with all major brands of networking devices, server and workstation operating systems. It uses a software agent installed on each device and a collector type system to aggregate and report the data. With SNMP you will be able to collect bandwidth data such as utilization % for each interface, total packets, discards and more. Here is a screenshot of a typical interface display for an SNMP enabled device:



















To retrieve this information on a device, you will need to set a community string (aka password) that your monitoring system will use when retrieving the bandwidth statistics. At the bottom of this article are the steps to enable SNMP on Windows and Cisco devices.

For more overview information check out these website links:
http://www.dopplervue.com/bandwidth.php and the tutorial at http://www.dopplervue.com/tutorials_show.php?what=Managing_Bandwidth.

The next blog post will discuss monitoring systems that can gather this data, what to do with the information, alerts and rules that can be set and common reports that you will want to use for bandwidth monitoring.

Enabling SNMP on a Windows System

Windows 2003 and XP
1. In the Control Panel, click Add Remove Programs.
2. In the left pane, click Add/Remove Windows Components.
3. Select the Management and Monitoring Tools checkbox and click Details.
4. Select the Simple Network Management Protocol checkbox, click OK, and then click Next.
5. If prompted, insert the Windows 2003 or XP disc to finish the setup.

Windows Vista
1.In the Control Panel, click Programs and Features.
2. In the left pane, click Turn Windows features on or off.
3. Select the SNMP Feature checkbox and and click OK.

On a Windows system, you must configure security for the SNMP service by adding a community name(s) and permissions to a list of communities that can send it SNMP requests. This is known as a "community string":
1. In the Control Panel, click Administrative Tools, and then click Services.
2. Right-click the SNMP Service, click Properties, and then select the Security tab.
3. In the Accepted Community Names pane, click Add.
4. You may accept the default community rights, and then enter a community name (case sensitive). Click Add.
5. Select Accept SNMP packets from any host, and then click OK.
This ensures all SNMP packets from all SNMP hosts belonging to any community listed in Accepted community names are processed. No SNMP packets are rejected on the basis of the host name or IP address of the source host or the list of acceptable hosts.
6. Ensure the SNMP Service is selected and click Restart the Service to initiate the changes.

Enabling SNMP on Cisco Devices
Log in to the router and enter configuration mode: Router#configure terminal

1. Enable SNMP on the router (note that "public" and "private" are for example purposes):
Router(config)#snmp-server community public RO
Router(config)#snmp-server community private RW
Router(config)#exit

Interop Las Vegas in Review

I spent last week in Las Vegas at Interop and thought I’d share my experience with you. Attendance was definitely down this year, but exhibitor attendance was about the same and booth extravagance seemed to be at an all time high. The exhibitor floor was much smaller and orange seemed to be the color of choice. However, it was easier to spend quality time with attendees that stopped by the booth. I had many great conversations with folks about their network management challenges and the need for enhanced visualization, alarm and bandwidth management and the benefits of all-in-one tools. The conference sessions were worth attending and covered the hottest topics including cloud computing, virtualization, green IT, SOA and web 2.0. I was tweeting live from some of the conference sessions – take a look at the trail of tweets, if you’re interested in some details about each session. All-in-all it was a great trip – got some good leads from the show and came home without losing too much face at the blackjack table.