Wednesday, November 25, 2009

Are Businesses Prepared for Workforce Disruptions? New Cisco Study Says No…

I’ve recently discussed keys to avoiding network failures and tips to being prepared for network disasters. A recent study by Cisco highlights the need to continually keep network continuity at the forefront of our minds.

The survey finds that organizations are not ready to operate as usual during workforce disruptions because they haven’t set-up the proper networking infrastructures to support remote work by a high percentage of their employees.


Here are some of the highlights of the survey:


- 74 percent of the 502 IT decision-makers surveyed said that fewer than half of their employees were currently set up to work remotely.

- Asked why more employees did not have remote access, 38 percent said that business requirements did not necessitate it.


- Only 22 percent of those top decision makers felt that their current remote access solutions have contributed to their disaster preparedness.


- Just 15 percent of the respondents listed "pandemic or other disaster preparedness" as a top business driver for providing remote access to employees, and only 5 percent listed it as the primary business driver.


The study suggests that organizations are more focused on business needs under normal conditions than on remote access for business continuity purposes. In this economic environment that is not so surprising. Of course, it only takes a road closing, really bad weather or widespread illness that affects employee productivity and company revenue to change that focus.


Cisco also posted a YouTube video with a preview of the findings from the survey, if you’re interested in more details.

Monday, November 23, 2009

5 Key Common Culprits for Single Points of Network Failures

I recently wrote a post about network disaster preparedness and provided some tips on how to avoid network outages. I came across a great blog post that added more depth to the topic by discussing how to avoid the most common culprits for single points of failure on small to midsize networks. The post was written by Derek Schauland from TechReuplic and he highlights some network areas that I agree need particular attention.


1. Network Switches – Keeping spare switches online is ideal, but may be cost prohibitive. Consider having a couple of extra switches around in case of a failure.


2. Tape Drives – Ensure you have redundancy in terms of tape drives for back-up and recovery in case of a worst case scenario. You never know when a tape drive may stop working.


3. Network Interface Cards (NICs) – Use servers with multiple NICS for improved connectivity and for failover in case one of the cards in the server fails.


4. Internet Connections – Having redundant connections can be a critical part of avoiding a single point of failure, especially considering the importance of the Internet to business operations these days. Of course the cost of keeping a connection with two providers active needs to be justifiable for your business. At a base level, it never hurts to have a plan in place to immediately take action to move to a secondary provider if your primary fails.


5. Cabling – I’m adding to Derek’s list here, but cabling issues often cause LAN failures. It’s always worthwhile to have many spare cables of different lengths ready to go. I keep a few really long ones as spares in every telco/IT room. They are great for testing and at times when I need a temporary cable.


This will help you to solve, both the most basic and overlooked issues and the more dramatic ones. This list is not all inclusive, but these fives areas should be considered in planning for a worst case scenario. Do you have any additional areas that you pay particular attention to in your network?

Tuesday, November 17, 2009

HP Buys 3Com… What Does It Mean for the Networking Market?

The recent acquisition of 3Com by HP makes me wonder what they are going to do in the networking market. For some time, we have been using HP Procurve switches along side Cisco gear. They have proven reliable and very cost effective. I have been looking forward to HP enchancing its offerings. In light of Cisco expanding into the server market, there was an expectation that HP would more aggressively address the networking market and create better choices for lower cost networking devices. It just doesn’t seem like the 3Com product line is sufficient for HP to go head-to-head with Cisco. This makes me think that HP is not even close to being done from an acquisition standpoint. I wonder when we will see HP drop another huge chunk of change to buy another device vendor. And who will the vendor be?

Anybody want to comment on who they think HP will buy next or do you think 3Com products sufficiently supplement the HP Procurve line?

Friday, November 13, 2009

Want to Become a Service Provider CEO? Try Cisco’s New Simulation Game…

Looking to try your hand at being a CEO for a day without all the real life pressures? Here’s your chance. Cisco has a free Sim City type real time strategy simulation game called myPlanNet, you can download (only works on Windows though). If you want a preview before downloading (40mbs in size) the game, check out the YouTube video.



You have to register (if you don’t already have an account) to get the game, but it’s worth the hassle. The point of the game is to manage your service provider business as the CEO as it evolves from the dial-up, through to the broadband and mobile connected eras and into the future age of networking.

Cisco created the game as a marketing and educational tool and I’ll admit it is a lot more fun than reading a white paper. Check it out and let me know what you think.

Tuesday, November 10, 2009

5 Easy Steps to Enabling SNMP on Cisco’s Unified Communications Manager for VoIP Monitoring

One of our offices has the new Unified Communications Manager (UCM) 6.1, the software-based call-processing component of the Cisco VoIP solution. Did you know that UCM supports SNMP monitoring? Based on a few conversations I had with people there seemed to be some confusion about the topic.

There is a good reason for the confusion. I was doing some SNMP polling and could not get the metrics to appear. It turns out that all previous versions of UCM supported SNMP by default, however the current version requires you to enable the protocol. After a bit of research I found that you need to enable SNMP on both the host server and the Unified Communications Manager application.


With both sets of SNMP services enabled, I was able to monitor both the health and status of the core system and gather quite a few metrics regarding the service. I’ll share a few of my favorite monitoring metrics and some associated screenshots in a later post.


For those of you, who already monitor your Unified Communications Manager with SNMP, let me know what you find useful. For those of you who have not turned on SNMP, here are the steps:


1. Open the web console to CCM


2. In the Navigation dropdown in the upper right, select Cisco Unified Servicability


3. Go to Tools / Service Activation


4. Select Cisco CallManager SNMP Service


5. Click the Save button


Here is a link to where I found the Cisco UCM MIBS.

Friday, November 6, 2009

Random Netflow – A Tool to Keep in Your Kit

In my network management adventures throughout the years, I’ve found Netflow to be an invaluable tool to troubleshoot a range of network issues – from bandwidth to service and resource problems. It’s an amazing traffic mining tool – it analyzes traffic flows across a network and provides a huge amount of information. That is where the problem lies as well – sometimes Netflow delivers too much information when I just want a small amount data for planning and traffic engineering. I’m sure you’ve come across this issue – right?

I know I’m not the only one, since I came across a great article from Network World on how to solve this issue. The advice is very straight forward and concise on how to solve the information overload issue by using the random Netflow feature. Thought it was worth sharing.

A few of my favorite tips from the article:

- Know your flow. Netflow versions 5 or 9 work if you need to export the data to look at it off device. With other versions you can view the data on the device.

- You can not have Netflow enabled on an interface you want to run random Netflow on. A device always gives full Netflow precedence over random Netflow.

- If you run into any problems there is a debug command: debug flow-sampler.

What was your favorite tip? Or if you have one that isn’t mentioned, I’d love to hear it!

Wednesday, November 4, 2009

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:


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.