How to Improve SNMP MIBs

Terry Slattery
Principal Architect

SNMP is a pretty reasonable system for retrieving device data, but its implementation has a few warts.  Well, it isn’t really an SNMP problem as much as it is a MIB deficiency.  There are a few variables in some MIBs that try to provide information about problems that are occuring but the lack of additional data makes them pretty useless.  Let’s take a look at a couple of examples and I’ll make suggestions for how future MIB designers can provide better data in the future.

The first variable is ipOutNoRoutes, which appears in the IP-MIB. Its description says:

“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’ criterion.  Note that this includes any datagrams which a host cannot route because all of its default routers are down.”

Knowing about destinations with no route could be useful in troubleshooting.  But there are a couple of problems with this variable.  In the Cisco code, it counts packets where there are ARP failures as well as routing failures.  This isn’t necessarily a fatal flaw as it could point to end stations that are attempting to access a device that has been moved.  The real problem is that to diagnose which systems are sending the packets, you have to do packet capture.  The designers should have included a 1-entry cache of the source and destination IP address of the packet that caused the counter to increment.  Even if you missed a large number of values, you’d capture valuable data that you could use to diagnose a variety of network problems without resorting to packet capture.

The ipFragOKs object could use similar instrumentation.  I’d like to know the source/destination where fragmentation is being required.  Something isn’t configured correctly to force fragmentation.  Maybe it is an old end node that needs to have its MTU adjusted, or perhaps it’s an app that used to work fine over T1 or Frame Relay and now requires fragmentation to run over a VPN.   The various ICMP message counters (icmpOutDestUnreachs, icmpOutTimeExcds) have similar problems.

The end result of each of the above items is that the network runs slower and is less efficient.  If performance impacting configuration problems can be addressed, the cost of IT can be reduced.  Note that what I’m describing may sound like pure performance problems, but the end result is that the configuration of some network device or end node is not correct, causing problems for other devices on the network.

The above is what I call “system level analysis,” which is determining from a collection of data that a configuration or implementation problem is occuring and its impact on the business.



Re-posted with Permission 

NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under


Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.