<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://www.netcordia.com/community/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Infoblox NetMRI Community</title><link>http://www.netcordia.com/community/blogs/</link><description /><dc:language>en-US</dc:language><generator>CommunityServer 2007.1 SP2 (Build: 31113.47)</generator><item><title>Designing a Logging Solution</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/11/16/designing-a-logging-solution.aspx</link><pubDate>Wed, 16 Nov 2011 21:33:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3298</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>I just found out about a great tutorial on designing logging solutions by Marcus Ranum. Marcus has been doing network security work for a long time and is well known in the network security industry. I have previously referenced some of his work in my blog Handling Network Events (syslog and snmp traps) where Marcus defines the term Artifical Ignorance . The tutorial by Marcus is quite long - over 200 pages, but it contains a lot of really useful information about how to process log files (syslog...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/11/16/designing-a-logging-solution.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3298" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/syslog/default.aspx">syslog</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/syslog+summary+script/default.aspx">syslog summary script</category></item><item><title>Rethinking Interface Error Reports</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/11/02/rethinking-interface-error-reports.aspx</link><pubDate>Thu, 03 Nov 2011 01:58:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3279</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>&amp;#39;ve always looked at percentage of interface errors as an indicator of which interfaces I should examine. What did I know? Not enough, as it turns out. I&amp;#39;ve been working with customers on application performance, as you might have guessed from the series of recent blogs on the topic of application performance and the effect that packet loss has on TCP performance. ( Application Analysis Using TCP Retransmissions, Part 1 and Application Analysis Using TCP Retransmissions, Part2 ) Of course...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/11/02/rethinking-interface-error-reports.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3279" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/mathis+equation/default.aspx">mathis equation</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/TCP+throughput/default.aspx">TCP throughput</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/performance+data/default.aspx">performance data</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/errors/default.aspx">errors</category></item><item><title>Application Performance Troubleshooting</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/10/17/application-performance-troubleshooting.aspx</link><pubDate>Mon, 17 Oct 2011 18:36:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3258</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>In the last two blogs, I described how application performance is impacted by TCP Retransmissions. Of course, there are many other causes of poor application performance. My review of this topic came about because Pete Welcher and I have just finished investigating whether application slowness at a customer site was due to the network or due to the applications themselves. Packet Loss As I described in the blog posts about TCP retransmissions, even small amounts of packet loss can cause significant...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/10/17/application-performance-troubleshooting.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3258" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/troubleshooting/default.aspx">troubleshooting</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/discards/default.aspx">discards</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/overruns/default.aspx">overruns</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/application+performance/default.aspx">application performance</category></item><item><title>Application Analysis Using TCP Retransmissions, Part 2</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/10/12/application-analysis-using-tcp-retransmissions-part-2.aspx</link><pubDate>Wed, 12 Oct 2011 17:14:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3253</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>In my last post, I talked about TCP retransmissions that are caused by link errors. Another source of TCP retransmissions is too much buffering in network routers and L3 switches. Some buffering allows the network to handle traffic bursts without dropping many packets, which is good. However, too much buffering causes problems. How much buffering is too much? Looking at how TCP works can help us understand what the limits should be. TCP measures the Round Trip Time (RTT) of its connection (see Wikipedia...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/10/12/application-analysis-using-tcp-retransmissions-part-2.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3253" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/network+performance/default.aspx">network performance</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/bufferbloat/default.aspx">bufferbloat</category></item><item><title>Application Analysis Using TCP Retransmissions, Part 1</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/09/29/application-analysis-using-tcp-retransmissions-part-1.aspx</link><pubDate>Thu, 29 Sep 2011 12:52:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3241</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>I&amp;#39;ve been doing a number of network assessments recently and one of the factors that I use to determine network health is the number of TCP retransmissions that occur. I look at servers and user workstations as well as looking for retransmisisons using packet capture tools. There is a fair amount of information on the web about TCP retransmissions and how TCP works. But I haven&amp;#39;t seen anything much about the sources of TCP retransmissions. The few things I did find typically contained inaccuracies...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/09/29/application-analysis-using-tcp-retransmissions-part-1.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3241" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/network+analysis/default.aspx">network analysis</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/TCP+throughput/default.aspx">TCP throughput</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/errors/default.aspx">errors</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/network+performance/default.aspx">network performance</category></item><item><title>A Network Management Architecture, Part 4</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/08/31/a-network-management-architecture-part-4.aspx</link><pubDate>Wed, 31 Aug 2011 16:31:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3181</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>This is the fourth and final post of a series on the network management architecture used by NetCraftsmen . The architecture is shown below, consisting of seven elements. In this post, we&amp;#39;ll look at Topology Mapping and discuss integrating the elements together. Topology Mapping Until recently, we had not identified a good way to track the physical network topology. The basic Visio network discovery and topology creation mechanism has never worked well for us. However, we have found several tools...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/08/31/a-network-management-architecture-part-4.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3181" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/Network+Health+Metrics/default.aspx">Network Health Metrics</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/network+management+architecture/default.aspx">network management architecture</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/topology+mapping/default.aspx">topology mapping</category></item><item><title>A Network Management Architecture, Part 3</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/08/22/a-network-management-architecture-part-3.aspx</link><pubDate>Tue, 23 Aug 2011 02:29:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3173</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>This is the third of a series of posts on the network management architecture used by NetCraftsmen in our network assessments. The architecture consists of seven elements, shown below. The two prior posts covered Events, NCCM, Performance, and IP Address Management. In this post, we&amp;#39;ll look at Active Path Testing, and Application Performance. Active Path Testing Network management systems tell us how the network devices are operating. But they often don&amp;#39;t tell us what the applications experience...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/08/22/a-network-management-architecture-part-3.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3173" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/network+management+architecture/default.aspx">network management architecture</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/Path+Testing/default.aspx">Path Testing</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/Application+Performance+Management/default.aspx">Application Performance Management</category></item><item><title>A Network Management Architecture, Part 2</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/08/15/network-management-architecture-part-2.aspx</link><pubDate>Mon, 15 Aug 2011 15:06:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3128</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>In Part 1, I discussed a Network Management Architecture, composed of seven elements, shown in the figure below. I described the Event and NCCM elements in that post. Performance Performance monitoring is typically where most people focus their early network management efforts. I think that&amp;#39;s because it is easy for an organization&amp;#39;s management to understand and it is relatively easy to implement. A lot of tools provide performance monitoring, with the Top N displays of utilization and errors...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/08/15/network-management-architecture-part-2.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3128" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/event+analysis/default.aspx">event analysis</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/NCCM/default.aspx">NCCM</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/mathis+equation/default.aspx">mathis equation</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/IPAM/default.aspx">IPAM</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/IP+Address+Management/default.aspx">IP Address Management</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/IF-MAP/default.aspx">IF-MAP</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/network+management+architecture/default.aspx">network management architecture</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/architecture/default.aspx">architecture</category></item><item><title>A Network Management Architecture, Part 1</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/08/11/a-network-management-architecture-part-1.aspx</link><pubDate>Thu, 11 Aug 2011 17:36:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3123</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>At Netcraftsmen , we get to do a lot of network assessments where we examine and evaluate a customer&amp;#39;s network, including the network management implementation. As a result of this work, we&amp;#39;ve identified a set of network management architectural elements. There are currently seven elements in the architecture, shown in the figure below. Each element provides a key piece of functionality that provides visibility into the network&amp;#39;s operation. There are multiple products that provide functionality...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/08/11/a-network-management-architecture-part-1.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3123" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/event+analysis/default.aspx">event analysis</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/NCCM/default.aspx">NCCM</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/network+management+architecture/default.aspx">network management architecture</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/architecture/default.aspx">architecture</category></item><item><title>Debugging NetMRI Perl Scripts</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/08/03/debugging-netmri-perl-scripts.aspx</link><pubDate>Wed, 03 Aug 2011 19:21:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3109</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>One of the new features in the latest release of NetMRI is the ability to write scripts in Perl. This means that the Perl programmers in your organization can now help you write and debug your command scripts. But the environment in which you can develop scripts is a locked-down sandbox to prevent a Perl script from doing undesirable things to the system. So how do you go about debugging these scripts? Create a simple script that runs the commands that you expect to execute on the network devices...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/08/03/debugging-netmri-perl-scripts.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3109" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/scripting/default.aspx">scripting</category></item><item><title>Network Management Function Review at CiscoLive 2011</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/07/27/network-management-function-review-at-ciscolive-2011.aspx</link><pubDate>Wed, 27 Jul 2011 15:34:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3088</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>I just returned from a week at CiscoLive 2011. The show floor had a lot of network management products on display, making it an easy place to walk around and investigate various products. I did an informal product survey of functions that are important to a good NMS. Without going into the details of what I found for each vendor, I thought it would be worth describing the key factors that I investigated. Alerting Alerting is top on my list of key functions. A network with more than a few devices...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/07/27/network-management-function-review-at-ciscolive-2011.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3088" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/network+analysis/default.aspx">network analysis</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/NMS+performance/default.aspx">NMS performance</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/data+analysis/default.aspx">data analysis</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/NMS+alerting/default.aspx">NMS alerting</category></item><item><title>Diagnosing a QoS Deployment</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/07/22/diagnosing-a-qos-deployment.aspx</link><pubDate>Fri, 22 Jul 2011 22:30:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3077</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>Monitoring QoS traffic class drops. Reference prior post. Discuss what happened with drops in high piroiry queue. Several of us at Netcraftsmen were involved in an interesting network QoS configuration case a few weeks ago. The customer had requested assistance with the first phase of a QoS deployment in which we were going to add QoS to some overloaded WAN links. These links ran at low utilization at night, but at 8am the utilization started increasing and by 9am it was typically into link saturation...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/07/22/diagnosing-a-qos-deployment.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3077" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/qos/default.aspx">qos</category></item><item><title>Diagnosing the "ipOutNoRoute" Counter</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/07/08/diagnosing-the-quot-ipoutnoroute-quot-counter.aspx</link><pubDate>Fri, 08 Jul 2011 17:54:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3040</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>Any devices that implement the IP MIB have an interesting SNMP counter called ipOutNoRoutes that has the following definition: ipOutNoRoutes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION &amp;quot;The number of IP datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this `no-route&amp;#39; criterion. Note that this includes any datagrams which a host cannot route...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/07/08/diagnosing-the-quot-ipoutnoroute-quot-counter.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3040" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/routing+black+hole/default.aspx">routing black hole</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/ARP/default.aspx">ARP</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/subnet+mask/default.aspx">subnet mask</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/ipOutNoRoute/default.aspx">ipOutNoRoute</category></item><item><title>What Are Critical Network Problems?</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/07/06/what-are-critical-network-problems.aspx</link><pubDate>Wed, 06 Jul 2011 12:58:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3032</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>What are your critical network problems? Every network has them. They are the problems that cause network outages, or are the precursor to network outages. Most networks have similar designs and have similar critical network problems. I&amp;#39;ve heard network staff say &amp;quot;our network is unique&amp;quot; and I always think to myself &amp;quot;if that&amp;#39;s true, you have unique problems that you probably don&amp;#39;t understand&amp;quot;. Using well-known configurations allows network vendor technical staff to...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/07/06/what-are-critical-network-problems.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3032" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/redundancy/default.aspx">redundancy</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/config+archive/default.aspx">config archive</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/reliability/default.aspx">reliability</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/performance/default.aspx">performance</category></item><item><title>Device Real-Time Displays</title><link>http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/06/24/device-real-time-displays.aspx</link><pubDate>Fri, 24 Jun 2011 22:23:00 GMT</pubDate><guid isPermaLink="false">5d983763-db35-4d57-ab7d-8a0a48ffcea2:3024</guid><dc:creator>tslattery</dc:creator><slash:comments>0</slash:comments><description>I&amp;#39;ve been doing a number of device configuration changes as a result of the things that NetMRI and syslog are reporting in a customer network. Both NetMRI and syslog have rather long reporting cycles before I know that something was fixed, so I&amp;#39;ve been thinking about a device real-time display as a nice function to have. NetMRI is not unique in its data collection. Network management systems tend to using a polling mechanism to collect a lot of the data that is displayed. The collection tends...(&lt;a href="http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/06/24/device-real-time-displays.aspx"&gt;read more&lt;/a&gt;)&lt;img src="http://www.netcordia.com/community/aggbug.aspx?PostID=3024" width="1" height="1"&gt;</description><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/real-time/default.aspx">real-time</category><category domain="http://www.netcordia.com/community/blogs/terrys_blog/archive/tags/device+viewer/default.aspx">device viewer</category></item></channel></rss>
