My network is slow. Why? Do you have network monitoring in place?

October 24, 2009 by Leave a Comment

Network performance is always a hot topic to discuss.  When performance slows, it is easy to blame the carrier.  But often the problem is due to your own LAN or server applications.  How can you figure out what the problem is?

Unless you have centralized network monitoring installed on your network, you very likely will never resolve your performance issues.

Most people are familiar with SNMP (Simple Network Management Protocol) since nearly every network device supports it.  SNMP is fine to keep track of devices that devices are attached and operating, but beyond that, it places a great deal of overhead traffic on your network. It uses Polling, running information back and forth on the network.  But SNMP won’t provide much troubleshooting information.

Products such as NetFlow, Sflow, Jflow and IPFIX are common standards for Flow Records.  Flow Records follow the flow of packets source IP address, destination IP address, source port, destination port, layer 3 protocol type, type of service (TOS) byte, and input logical interface.  Flow analysis compiles and collects packet samples entering the switches and routers, providing good data for analysis.  Flow analysis uses statistical sampling, so not every packet is collected.  There are some freeware applications that run on Linux that are worth investigating.

Flow-based analysis relies heavily on the same hardware being used to control network traffic: the routers and switches themselves.  On busy networks,  conflicts for hardware resources like processing power and memory can result. It is the flow analysis that loses when conflicts occur. While it does allow for some troubleshooting, like identifying users who are hogging bandwidth, for example, it does not include any payload information, nor are the packets saved, limiting one’s ability to troubleshoot the network intelligently. (This explains one reason why routers have options for additional memory.)

Packet based monitoring is the most comprehensive tool.  The common term “packet sniffing” is done by capturing every packet traversing the network.  The packets are then decoded and analyzed, allowing analysis right down to the application level.  The server collecting your data can be accessed whenever a network problem arises, so you can see exactly what has happened.  You can go back in time which is especially helpful with intermittent problems that are difficult to reproduce.  Finally, you will also want to collect Payload information, which is the linkage between networking and application information.  Then all the data you need is available.  But this approach also is the most expensive approach.

Here are a few links worth visiting learn about monitoring applications:

MRTG – Multi Router Traffic Grapher:   http://oss.oetiker.ch/mrtg/

NTOP Netflow Probe: http://www.ntop.org/solutions.html

WinPcap: http://www.winpcap.org/

PRTG Network Monitor: http://www.paessler.com/prtg/

EtherApe: http://etherape.sourceforge.net/

Wild Packets: http://www.wildpackets.com/products/network_analysis

Solarwinds:  http://www.solarwinds.com/products/

MPLS-Experts has the technical resources to help you resolve your network performance challenges.  Contact us for more information.

Filed Under: Network FAQs, Routers, Troubleshooting MPLS Networks Tagged With: , , , ,

WAN Accelerators and MPLS – Important Facts

November 19, 2008 by Leave a Comment

WAN Accelerators are wonderful tools in improving your network performance, provided your traffic can benefit from this technology.

If you obtain an MPLS network, your network performance will be better than a VPN over the internet.  But you need to select your Classes of Service appropriately.  Different CoS levels have different packet loss SLAs.  On a simple level, the SLAs might be:

  • Basic CoS: 99.9% packet delivery
  • Middle CoS: 99.99% packet delivery
  • Best CoS: 99.999% packet delivery

If you decide to subscribe to all Basic CoS, the SLA is 99.9% packet delivery.  That is typically the same as an uncongested internet access circuit, so you might not see any performance improvement.  But if you use your WAN Accelerator with the Middle CoS with 99.99% packet delivery, you will experience a more noticeable improvement.  Obviously, the Basic CoS will work better than the internet when the internet is congested, since the MPLS network avoids those bottlenecks.

When using a WAN Accelerator, since you are using compression, if your compression ratio is 20:1, if you lose 1 packet, you are really losing 20 or more packets.  So you maximize performance with a network that has less packet loss/better packet delivery.

To reduce or eliminate the number of undelivered packets, select a higher CoS.

One thing you should be aware of, that is not widely publicized is that the lower level Class of Service levels will not provide the expected performance improvements when you use a WAN Accelerator.  But if you design your network accordingly, you will be very pleased with the performance boost.

Filed Under: New MPLS Implementations, Notes About Implementations, Quotation Thoughts Tagged With: , , , , , , ,

Network Backbones – A question of security

September 12, 2008 by Leave a Comment

When procuring an MPLS network for mission critical applications, many people tend to focus on Service Level Agreements.  SLA’s address compensation for performance shortcomings.  But take a serious look at the network provider’s backbone.

The network backbone is critical to performance.  The best performance will come from a dedicated MPLS backbone with a minimal number of AS numbers.

Some carriers will share a variety of network services on a single backbone to get a better return on their investment.  For instance, using VLANs, a carrier can run their internet network on the same backbone as their MPLS network.  Everything is segregated and the MPLS network is secure from any internet traffic.  Guess what happens if their router receives a Denial of Service Attack from the Internet?  You guessed it!  Your MPLS network performance can go to a crawl.  So while the MPLS network is secure, it’s performance might not be.

Ask the hard questions and understand what you are dealing with.  Or, just give us a call!

Filed Under: Carriers Offering MPLS, Industry Surveys, Notes About Implementations Tagged With: , , , ,

When you think you need MPLS but perhaps do not

August 15, 2008 by Leave a Comment

We had a conference call with a potential client today that is interested in an MPLS network for their twenty offices in the USA and Canada.  As usual, I asked them “why”? “Our network performance is poor and we understand MPLS is the best for WANs”.

After a series of questions, I learned that this company does a large amount of file transfers from their many offices to the central data center.  No interactive apps.  No video.  No voice. They use Cisco hardware VPNs over the internet. 

Average file size: 60Mbps

Typical bandwidth per office: T1

Home office bandwidth: 15Mbps

Can you see where this is going?  Never start the process of building a new network without understanding exactly what is happening on your network today.  Would MPLS with the same bandwidth help this company? Probably not.  What do they need?  They need to analyze their network traffic.  This involved packet sniffing and logging with software such as NTOP and MRTG.  If you don’t know how to do this, pay a consulting company such as MPLS-Experts to do it for you.

How can you cost justify paying a consultant?  Because you will end up with the network you really need and pay no more than you should.  Overprovisioning is easy, but expensive.  Underprovisioning will make you or your carrier look bad.  Get the help to do the job correctly.  We may be the MPLS-Experts, but we tell many of our clients to use internet VPN with the correct bandwidth if that is what their applicaton requirements suggest.

Filed Under: Get MPLS Price Quote, New MPLS Implementations, Notes About Implementations Tagged With: , , , , ,