Earlier in the week, I posted three tips for managing wireless networks. Thought I would also share a tip for managing wired networks to round things out for the week. Here is a response to a question I often get from customers.
How can I tell when a Cisco device configuration has been altered or accessed?
You can be notified of any configuration changes or attempts by enabling the CiscoConfigManEvent trap. This feature sends you a trap whenever a user exits the configuration session. Simply point the trap to your network management system to see when somebody accesses a Cisco configuration session.
For dopplerVUE Users
You can forward traps as an email for 24x7 instant access to changes on network devices. To read more about this trap and how to configure it, please reference the following Cisco article.
Showing posts with label dopplerVUE. Show all posts
Showing posts with label dopplerVUE. Show all posts
Thursday, September 3, 2009
Friday, August 7, 2009
Maintaining Network Awareness with Twitter…
Wanted to try a fun experiment and feed my network management alerts to Twitter instead of my email. Now let me explain, I’m using this for the alerts that are between super critical that need my instant attention (and are emailed to me) and those that can simply sit and wait all weekend or more for my attention (i.e. when I feel like looking at the NMS screen). By sending some events to Twitter (its on my phone and TweetDeck is on my pc) I can maintain “network awareness” while tweeting J or on the go.
Using the dopplerVUE network management tool, all alerts can be sent to a .Net assembly. Since Twitter has an API this part was simple – email me and I’ll send you the necessary files so you can create updates with your own Twitter account information.
Here are the steps to implement a twitter feed (takes about 5 minutes).
Using the dopplerVUE network management tool, all alerts can be sent to a .Net assembly. Since Twitter has an API this part was simple – email me and I’ll send you the necessary files so you can create updates with your own Twitter account information.
Here are the steps to implement a twitter feed (takes about 5 minutes).
The ABCs of adding a twitter feed to dopplerVUE
A. Update your system with the new twitter.dll and EventService.exe.config files
B. Create a Twitter action that can be re-used.
C. Define a rule that will use the Twitter action
A – Updating the dopplerVUE system
1. Add the twitter.dll to the //systechnologies/dopplerVUE/Server folder
2. Back up your existing //systechnologies/dopplerVUE/EventService.exe.config file and replace with the new one provided.
3. Edit the EventService.exe.config file user and password lines with your actual Twitter account username and password.
4. Preference>dopplerVUE System>dopplerVUE Services Then restart the dvEventService and dvDataService
A. Update your system with the new twitter.dll and EventService.exe.config files
B. Create a Twitter action that can be re-used.
C. Define a rule that will use the Twitter action
A – Updating the dopplerVUE system
1. Add the twitter.dll to the //systechnologies/dopplerVUE/Server folder
2. Back up your existing //systechnologies/dopplerVUE/EventService.exe.config file and replace with the new one provided.
3. Edit the EventService.exe.config file user and password lines with your actual Twitter account username and password.
4. Preference>dopplerVUE System>dopplerVUE Services Then restart the dvEventService and dvDataService
Now the Twitter action is ready to use.
B - Create a reusable Twitter action
1. Expand the NetOps> Action tree
2. Right Click on Actions and select Create Action
3. Enter an Action Name
4. Select Action Type: Custom DLL
5. Enter the assembly value of: Twitter.dll
6. Select Create.
B - Create a reusable Twitter action
1. Expand the NetOps> Action tree
2. Right Click on Actions and select Create Action
3. Enter an Action Name
4. Select Action Type: Custom DLL
5. Enter the assembly value of: Twitter.dll
6. Select Create.
C- Define a rule that will use the Twitter action
1. Expand the NetOps>Metric>Rules tree
2. Right click on an existing rule and select edit
3. At step 5, expand the Custom DLL folder and select the Tweet This! Action
4. Select Finish.
1. Expand the NetOps>Metric>Rules tree
2. Right click on an existing rule and select edit
3. At step 5, expand the Custom DLL folder and select the Tweet This! Action
4. Select Finish.
Friday, July 24, 2009
Taking Advantage of Network Virtualization
I’ve been hearing a lot about the benefits of virtualization for network management. From improved productivity to increased efficiency, network virtualization holds much promise. However, for all the benefits that virtualization brings to the field of network management, it also brings a few challenges.
How do you keep track of your virtual assets and real ones? Do you need a special team, tools or hardware to get the job done? It turns out that the most popular virtualization system (VMware), makes this an easy job for most network management systems when configured correctly.
VMware’s workstation product gives you three choices for network virtualization: Bridged, NAT and Host Only.
Bridged: This mode creates a virtual switch that sits between the host NIC and the VM instance. The VM instance looks like another PC on the network, it shares the host NIC resources and has an IP Address assigned via DHCP or static entry. A bridged VM instance looks and feels very much like a separate server on the network. It provides full monitoring capabilities similar to that of the host.
NAT: NAT mode uses the host machine's IP address to communicate with the network. As a result, no external IP address is assigned and the VM instance is not visible to the external network. This method provides a high level of security, but does not allow you to poll the VM instance directly. This method requires additional specialized software and agents.
Host Only: This method sets up a network that is completely contained within the host. It has no ability to communicate with the outside world. You will not be able to see the VM instance at all.
As you can see, the methods used for setting up networking on a virtual instance will determine what an IT management application will “see” and monitor. While this example is specific to VMware, most products offer similar options.
If you’re a dopplerVUE user you can create a group and associate the virtual devices to a physical device. dopplerVUE groups provide a view of all alarms and performance overlays in a single view, and allows drill down access into the performance of each virtual server.
How do you keep track of your virtual assets and real ones? Do you need a special team, tools or hardware to get the job done? It turns out that the most popular virtualization system (VMware), makes this an easy job for most network management systems when configured correctly.
VMware’s workstation product gives you three choices for network virtualization: Bridged, NAT and Host Only.
Bridged: This mode creates a virtual switch that sits between the host NIC and the VM instance. The VM instance looks like another PC on the network, it shares the host NIC resources and has an IP Address assigned via DHCP or static entry. A bridged VM instance looks and feels very much like a separate server on the network. It provides full monitoring capabilities similar to that of the host.
NAT: NAT mode uses the host machine's IP address to communicate with the network. As a result, no external IP address is assigned and the VM instance is not visible to the external network. This method provides a high level of security, but does not allow you to poll the VM instance directly. This method requires additional specialized software and agents.
Host Only: This method sets up a network that is completely contained within the host. It has no ability to communicate with the outside world. You will not be able to see the VM instance at all.
As you can see, the methods used for setting up networking on a virtual instance will determine what an IT management application will “see” and monitor. While this example is specific to VMware, most products offer similar options.
If you’re a dopplerVUE user you can create a group and associate the virtual devices to a physical device. dopplerVUE groups provide a view of all alarms and performance overlays in a single view, and allows drill down access into the performance of each virtual server.
Tuesday, July 14, 2009
Network Troubleshooting: IP SLA+ WMI = Better Web Services
Why is the network so slow? I’m sure you’ve never heard this complaint before :) Diagnosing the problem isn’t always easy with so many possible culprits. You can start by running down the network troubleshooting checklist:
The DNS service?
The web server?
The WAN link?
IP SLA and WMI information is critical to diagnosing potential network problems. For most Cisco devices, IP SLA can give you performance information for the connectivity layers of a net-centric service like a web application or VoIP. In Microsoft environments, WMI can do the same for the application/server/desktop layer. Combining WMI with IP SLA provides performance information about both layers and gives an end-to-end view of your web application or other net-centered service to most efficiently troubleshoot any issues.
Using IP SLA to Access the User Experience
IP SLA (Internet Protocol Service Level Agreements) is embedded in the Cisco IOS (Internet Operating System) for most Cisco routers and switches. IP SLA operations can measure delay (round trip time), jitter, packet loss, connectivity, voice quality scores, and many other key metrics for monitoring and troubleshooting network elements.
Additionally, threshold levels can be set for most metrics. When a metric crosses a threshold level, IP SLA sends an SNMP trap to the specified IP addresses.
You can configure an IP SLA HTTP operation to monitor the overall user experience for the “connectivity layer” of a web application (or any other net-centered application such as email, VoIP or videoconferencing). This operation uses a synthetic web transaction to measure the total round trip time (RTT) to perform a DNS query, establish a TCP connection to the HTTP service, and retrieve the web site’s home page. By configuring the HTTP operation on the LAN switch closest to users, the total RTT (or latency) is an accurate measure of the users’ experience (as opposed to measuring RTT from a central network management server).
Next, configure an IP SLA ICMP Echo operation to monitor RTT between the switch on the user LAN and the switch to which the web server is connected. This way, if the HTTP operation indicates the web transaction is slow or unresponsive, you can check the WAN RTT between the switches to see whether the problem is related to the WAN link or something on the web server.
Watching the Applications and Servers: Adding WMI
WMI (Windows Management Instrumentation) is an instrumentation tool similar to IP SLA that Microsoft has created for its products. WMI provides thousands of performance metrics for applications such as MS Exchange and MS SQL Server, as well as for server hardware and operating system components.
Microsoft has a built-in performance administration tool for monitoring WMI data for applications and servers. Using the tool you can view each server’s CPU utilization, physical memory and free disk space. Each of these sub systems is critical to the server’s performance regardless of the application running. Lack of memory, CPU cycles and low disk space are common causes of slowdowns on a server. You’ll have to go into each server to view the individual performance counters or you can use network management software to simplify the process by collecting any of the thousands of available WMI counters from across multiple servers.
Getting the End-To-End View
An end-to-end view of the network will really help you troubleshoot network problems much faster and avoid the common complaints you often hear. To get an end-to-end view consider network management software such as dopplerVUE that integrates fault and performance data from a variety of sources, including SNMP, syslog, WMI and IP SLA, you can integrate metrics from both layers of a web service into a single end-to-end dashboard view. Using dopplerVUE’s drag-and-drop interface, you can quickly create an integrated view of both layers of the service without having to shift between tools or viewers (screenshot below).
The DNS service?
The web server?
The WAN link?
IP SLA and WMI information is critical to diagnosing potential network problems. For most Cisco devices, IP SLA can give you performance information for the connectivity layers of a net-centric service like a web application or VoIP. In Microsoft environments, WMI can do the same for the application/server/desktop layer. Combining WMI with IP SLA provides performance information about both layers and gives an end-to-end view of your web application or other net-centered service to most efficiently troubleshoot any issues.
Using IP SLA to Access the User Experience
IP SLA (Internet Protocol Service Level Agreements) is embedded in the Cisco IOS (Internet Operating System) for most Cisco routers and switches. IP SLA operations can measure delay (round trip time), jitter, packet loss, connectivity, voice quality scores, and many other key metrics for monitoring and troubleshooting network elements.
Additionally, threshold levels can be set for most metrics. When a metric crosses a threshold level, IP SLA sends an SNMP trap to the specified IP addresses.
You can configure an IP SLA HTTP operation to monitor the overall user experience for the “connectivity layer” of a web application (or any other net-centered application such as email, VoIP or videoconferencing). This operation uses a synthetic web transaction to measure the total round trip time (RTT) to perform a DNS query, establish a TCP connection to the HTTP service, and retrieve the web site’s home page. By configuring the HTTP operation on the LAN switch closest to users, the total RTT (or latency) is an accurate measure of the users’ experience (as opposed to measuring RTT from a central network management server).
Next, configure an IP SLA ICMP Echo operation to monitor RTT between the switch on the user LAN and the switch to which the web server is connected. This way, if the HTTP operation indicates the web transaction is slow or unresponsive, you can check the WAN RTT between the switches to see whether the problem is related to the WAN link or something on the web server.
Watching the Applications and Servers: Adding WMI
WMI (Windows Management Instrumentation) is an instrumentation tool similar to IP SLA that Microsoft has created for its products. WMI provides thousands of performance metrics for applications such as MS Exchange and MS SQL Server, as well as for server hardware and operating system components.
Microsoft has a built-in performance administration tool for monitoring WMI data for applications and servers. Using the tool you can view each server’s CPU utilization, physical memory and free disk space. Each of these sub systems is critical to the server’s performance regardless of the application running. Lack of memory, CPU cycles and low disk space are common causes of slowdowns on a server. You’ll have to go into each server to view the individual performance counters or you can use network management software to simplify the process by collecting any of the thousands of available WMI counters from across multiple servers.
Getting the End-To-End View
An end-to-end view of the network will really help you troubleshoot network problems much faster and avoid the common complaints you often hear. To get an end-to-end view consider network management software such as dopplerVUE that integrates fault and performance data from a variety of sources, including SNMP, syslog, WMI and IP SLA, you can integrate metrics from both layers of a web service into a single end-to-end dashboard view. Using dopplerVUE’s drag-and-drop interface, you can quickly create an integrated view of both layers of the service without having to shift between tools or viewers (screenshot below).
Friday, June 26, 2009
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
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
Wednesday, May 27, 2009
Minimizing the impact of Alarm Storms...
I was working with a client today that just converted to dopplerVUE from a “traditional" log system that uses an event viewer to display each individual event. This was a big problem because he could not see how many different types of problems were occurring. The screen refreshed so fast leaving him with a new batch of alerts that he was unable to read or interpret since the last batch of alerts displayed. Let me show you an example of the screen and the problem:
In the below screenshot, identical copies of alarms are displayed in a new row.
Alarm grid from dopplerVUE (http://www.dopplerVUE.com)
In this picture, you can clearly see what the different types of alarms are, how many of them have occurred and when they started occurring. Now, real time monitoring of alarm conditions has value and is actionable. In this display, you even have syslog, snmp performance, snmp traps aggregated side by side for a complete picture.
In the below screenshot, identical copies of alarms are displayed in a new row.
Example 1: syslog event viewer
This type of event viewer becomes nearly useless when you are getting a large volume of alarms. Often times, the most valuable alarms are hidden in the clutter and are off the screen before you can react. You can only see the last few alarms and they may not be the critical ones.
These systems provide filtering to help you go back and search the log history. This is good if you want to get more detail about an old alert and you were able to write down or memorize the syntax. But, an even better way exists…
The dopplerVUE and NeuralStar displays are designed to consolidate identical alarms into a single row and display the total count and the first and last time when these alarms began occurring.
This type of event viewer becomes nearly useless when you are getting a large volume of alarms. Often times, the most valuable alarms are hidden in the clutter and are off the screen before you can react. You can only see the last few alarms and they may not be the critical ones.
These systems provide filtering to help you go back and search the log history. This is good if you want to get more detail about an old alert and you were able to write down or memorize the syntax. But, an even better way exists…
The dopplerVUE and NeuralStar displays are designed to consolidate identical alarms into a single row and display the total count and the first and last time when these alarms began occurring.
Alarm grid from dopplerVUE (http://www.dopplerVUE.com)
In this picture, you can clearly see what the different types of alarms are, how many of them have occurred and when they started occurring. Now, real time monitoring of alarm conditions has value and is actionable. In this display, you even have syslog, snmp performance, snmp traps aggregated side by side for a complete picture.
Friday, May 15, 2009
Welcome to the Network Zone…Let’s Talk About Network Management Needs
Thanks for coming by to read this blog. I look forward to hearing your views and comments on this post and future ones. I’ll keep the posts fun and helpful.
I read a great article on SearchNetworking by Shamus McGillicuddy. It discussed the state of the market for network management products and more importantly, some of the top issues network management staff are facing. Here are some of my take aways from reading it...
There is a clear need for network management that lets engineers move away from spreadsheets, manual processes and tools that simply require too much overhead to use. The proof is in the IDC research that shows the market is growing in these tough times, and it looks like more specialty vendors are becoming both competitors and complementary players in the space.
The article references the network management space as still being part of the Wild West. The growth in new products and modules is staggering. One vendor actually boasts their core product has over 45 utilities (I can only handle about 5-6 tools then its overload).
Often so many tools are being used that it creates a new problem...
"Too many tools can lead to a lack of integration," said Steven Guthrie, director of product marketing at CA. "The success of low-end niche tools in the enterprise tells us that these point products come in for good reasons. But then they outlive their usefulness, and they end up stalling mean-time-to-repair. That data source [in the niche tool] may not sync up with other data sources you may have."
As network engineers, we’re bombarded with new information all the time and simply don't want or have the time to keep learning and finding the right application when a crisis occurs. A central point of management is necessary. Shamus was right on when he wrote...
"But, clearly, IT pros would love to consolidate the number of management tools they use on a daily basis, if for no other reason than to save money and make their operations more efficient."
Tools that have a single database, can consolidate multiple sources of information and have a low maintenance overhead will ultimately win out. In the long run they make your life simpler.
To read the full article on SearchNetworking.com http://searchnetworking.techtarget.com/news/article/0,289142,sid7_gci1355151,00.html
I read a great article on SearchNetworking by Shamus McGillicuddy. It discussed the state of the market for network management products and more importantly, some of the top issues network management staff are facing. Here are some of my take aways from reading it...
There is a clear need for network management that lets engineers move away from spreadsheets, manual processes and tools that simply require too much overhead to use. The proof is in the IDC research that shows the market is growing in these tough times, and it looks like more specialty vendors are becoming both competitors and complementary players in the space.
The article references the network management space as still being part of the Wild West. The growth in new products and modules is staggering. One vendor actually boasts their core product has over 45 utilities (I can only handle about 5-6 tools then its overload).
Often so many tools are being used that it creates a new problem...
"Too many tools can lead to a lack of integration," said Steven Guthrie, director of product marketing at CA. "The success of low-end niche tools in the enterprise tells us that these point products come in for good reasons. But then they outlive their usefulness, and they end up stalling mean-time-to-repair. That data source [in the niche tool] may not sync up with other data sources you may have."
As network engineers, we’re bombarded with new information all the time and simply don't want or have the time to keep learning and finding the right application when a crisis occurs. A central point of management is necessary. Shamus was right on when he wrote...
"But, clearly, IT pros would love to consolidate the number of management tools they use on a daily basis, if for no other reason than to save money and make their operations more efficient."
Tools that have a single database, can consolidate multiple sources of information and have a low maintenance overhead will ultimately win out. In the long run they make your life simpler.
To read the full article on SearchNetworking.com http://searchnetworking.techtarget.com/news/article/0,289142,sid7_gci1355151,00.html
Subscribe to:
Posts (Atom)