Problem solve Get help with specific problems with your technologies, process and projects.

NetFlow and PBR

Most network administrators like to keep their networks as simple as possible but some features overwhelmingly justify the load and complexity they add.

Most network administrators like to keep their networks as simple as possible. Routing and switching are complicated enough without the additional complexity of all the thousands of bells and whistles that are actually supported in your hardware. Equally important, each of the additional features you configure burden the CPU and memory. For this reason, you'll find seasoned administrators refraining from turning on the mini-RMON agent on all 240 Fast Ethernet ports in a switch, for example, despite the wealth of interesting data that could theoretically be gathered. Similarly, when Policy Based Routing and Netflow, were introduced years ago, they went straight to the top of the list of really cool features you don't dare enable.

It's worth noting, however, that features are almost always implemented first in software, and later in hardware. This is exactly what happened with PBR. Originally, enabling PBR would stop your traffic from being Fast Switched, and cause it to be Process Switched, which is Cisco-speak for "bog down the CPU." But it wasn't too long before Netflow and PBR could take advantage of CEF. And as this report https://www.cisco.com/warp/public/cc/pd/iosw/prodlit/ntfo_wp.htm shows, it still affects your CPU, but not nearly as much as most people think.

The point is that there are some features that overwhelmingly justify the load and complexity they add, but they're rarely if ever used because of reputations of performance issues that haven't been relevant in years. Policy Based Routing, for example, can be used very effectively to solve a number of common IP telephony challenges, far beyond the source-based routing most people think of. And Netflow, for example, can be part of a lot of very impressive solutions.

So keep your network as clean as possible, but don't dismiss features before you've tested them, and never dismiss them permanently. If they have any redeeming value, it won't be long before the technology will be where you need it, or the hardware will grow to compensate.


About the author:
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex.

Dig Deeper on Network Infrastructure

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close