Skip navigation

When it comes to managing IP addresses, few of us would forget to track the IPs we assign manually to our WAN interfaces, servers, switches, and etc. However, once we decide to assign a DHCP scope to a subnet we tend to "set it and forget it". In many cases, this is a big mistake.

For those of us that have been around awhile, we can remember situations where DHCP wasn't available and we had to assign all of our users' IP addresses by hand. Wow did that suck. I remember having to have multiple IP address tracking spreadsheets in Excel because I had too many addresses to fit them all within the row limitations of the application. I think I must have memorized at least a few thousand of those address assignments and a few of them are still with me today.

Now that I have DHCP at my disposal I simply assign a scope for that subnet and I can pretty much forget about it. However, that would be missing an important step - the monitoring of that DHCP scope. DHCP scopes running out of addresses is a frustrating and time consuming ordeal. The users can't connect to the network so they call the helpdesk. Since they don't have an IP address the helpdesk person probably starts troubleshooting at layer 1 and works their way up the stack. Once they determine what the problem is, then the scope has to be widened which may result some devices needing to be readdressed. It's a headache and it's a waste of time.

The simple solution is to ensure that your IP Address Management solution includes the ability to monitor and alert on DHCP scope utilization. This way, you'll know before you have a problem and can proactively address the issue before the users or the helpdesk are impacted.

As of now, the new SolarWinds Orion IP Address Manager (IPAM) includes this functionality. These are key new features, monitoring and alerting on DHCP scope usage, and I'm extremely pleased to see them within the product so soon after the v1 release (the current release is 1.5). You can of course download a copy to try it out for yourself from SolarWinds.com, but regardless of which application you decide to deploy, remember to monitor those DHCP scopes...


Flame on...
Josh
Follow me on Twitter

A little while back I wrote a Understanding NetFlow and its role in traffic analysis and as a transport protocol on network traffic analysis using NetFlow and talked specifically about NetFlow support on the Csico ASAs. One of the primary uses for NetFlow on the Cisco ASAs is as a tranport protocol for security events. That said, recently we learned that you can use NetFlow for traffic analysis on the Cisco ASAs, which is different than I'd understood at the time I wrote that post.

Long story short, not only can you now analyze traffic using NetFlow on the Cisco ASAs but the Orion NetFlow Traffic Analyzer (Orion NTA) version 3.5 SP2 now supports this as well. This means that if you own Orion NTA and have active maintenance you can install the latest version and begin analyzing traffic on your Cisco ASAs now. This is really important as many companies don't have adjacent devices to the ASAs that they can use to analyze the traffic. I've seen many networks where remote sites are connected with a Cisco ASA with a 3750 behind it - which until now meant that they couldn't leverage NetFlow to analyze the traffic.

There is a caveat to the support of NetFlow on the ASA. The ASA doesn't report traffic statistics for flows until the flow terminates. On most routers and switches you will also get flow statistics periodically while the flow is in progress. Keep this in mind as you're investigating traffic traversing your Cisco ASAs.

We've also documented the required configuration parameters for the ASA to enable NetFlow export here in the SolarWinds Knowledge Base.

Good luck and let us know if you have any questions.


Flame on...
Josh

 

 

 

As I mentioned a few weeks ago in a previous SolarWinds Products Nominated for Community Choice Awards - show some love and cast your votes!!!, several of our products here at SolarWinds have been nominated for the 2009 Community Choice Awards. The voting window closes Wednesday - so be sure to cast your votes quickly.

Thanks to everyone that's voted so far and I'll see you in the winner's circle...


Flame on...
Josh
Follow me on Twitter

As a best practice, when I'm troubleshooting network issues, I typically start at layer 1 and work my way up the stack. If you've been managing networks for very long you've probably learned that the first three steps to troubleshooting a network issue are "check the cable, check the cable, check the cable..". Once you've checked the cable though, it's probably time to move up to layer 2.

Using layer 2 protocols and methods to troubleshoot layer 3 problems has long been a favorite of mine. Understanding where layer 2 is working but layer 3 isn't is a key aspect of solving many types of network issues. When troubleshooting LAN connectivity issues using the Switch Port Mapper within the Engineer's Toolset can tell you what sort of issue you're having - whether it be a duplex mismatch or an ACL issue, the Switch Port Mapper makes quick work of helping you find the issue.

When it comes to troubleshooting WAN issues, I've primarily relied on the CLI within my routers. The fact that you can see the adjacent device with CDP (Cisco Discovery Protocol) or LLDP (Link Layer Discovery Protocol) but can't get to them with ICMP is a clear indicator that you have a layer 3 issue. While the CLI is still a great tool for this sort of troubleshooting, greg@solarwinds.net and the rest of the guys that write new apps for the Engineer's Toolset have been hard at work again and have just released a new tool called the "CDP/LLDP Neighbor Map". It does exactly what you'd expect - it does a layer 2 discovery and automatically creates a map displaying the CDP/LLDP connectivity of devices on the network. It's a great new tool and has already helped me solve several connectivity issues both here in the lab and for some customers.

You can of course download the latest SolarWinds Engineer's Toolset from the SolarWinds.com website. Give it a try and let us know what you think or if you have any suggestions for new tools/improving the existing ones.


Flame on...
Josh
Follow me on Twitter

 

 

With the recent ratification of 802.11n a lot of people are writing/talking about it. This has a lot more people wondering if they should be thinking about it and confused about what it means to them. So, since some of those people have turned to me for advice on the subject I thought I'd take a few minutes to shed some light on "n".

First off, 802.11n has been around for quite a while now. I've been using it at home for well over a year and I see it quite commonly in business environments. Most of the wireless infrastructure gear that you buy nowadays supports 802.11n. This means that the questions you need to ask yourself aren't around whether or not to buy 802.11n gear - they're about whether or not you should be deploying and supporting 802.11n.

To answer that question, let's first look at why 802.11n was developed - speed. It's all about throughput, baby. Wireless networks have always been noticeably slower than wired networks and "n" was designed to help solve that problem. So, if your wireless networks need more throughput then you should start thinking about deploying 802.11n.

Another common question is since the standard has now been ratified, will we all have to go out and replace the gear that we bought that was based on the draft? The answer to that is no. I haven't seen a case yet where this is the case and I don't expect to. The ratified standards hasn't changed much from the draft versions and so far every vendor I've talked to is planning to resolve any inconsistencies within software.

When deploying any new technology one of the main concerns should be manageability. Beginning with version 9.5, wireless infrastructure management is now included within every copy Orion NPM. As you're testing new wireless technologies and prototyping deployments on your networks be sure to remember to also add those devices to Orion and test for support there.

I could go on for a long time on this subject as there are several best practices around the deployment of 802.11n and there are also some really interesting lessons learned from organizations that have tried early deployments, but it's the Friday before Labor Day and I would imagine that a lot of you are already thinking about that long weekend. Be safe out there.


Flame on...
Josh
Follow me on Twitter

Filter Blog

By date: By tag: