About Bruce Large

Follow me on Twitter @belarge - http://twitter.com/belarge

The Winning that is Digital Optical Monitoring (DOM)

A number of Cisco Optical Interfaces implement Digital Optical Monitoring (DOM) which enables the monitoring of some interesting status values on the interface with the most useful values being the optical receive and transmit powers.

By being able to monitor transmit and receive power levels of optical interfaces you are able to characterise the fibre loss and isolate any unidirectional connectivity issues.

The following link is useful for identifying which optical interfaces support DOM – http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_8031.html

Continue reading

All of the Pings!

Ping is one of the most recognised network troubleshooting tools. It is used without thought and is considered so basic that to post about it seems pointless, however, pings aren’t pings!

Ping started as a small utility written by Mike Muuss who was working at the Ballistic Research Laboratory and needed a quick and easy way to troubleshoot the state of the network. Given the tools usefulness it has since been ported to many platforms.

Ping uses the Internet Control Message Protocol (ICMP) to send ICMP Echo Requests to the target host and listen for ICMP Echo Replies. If you want to learn more about ICMP, check out RFC 792

Ping is useful for the following reasons:

  • It can assist in detecting network reachability of a host (However it can be confusing if there are return path issues .. )
  • It is useful as a “yard stick” for network performance by looking at the Round Trip Time (RTT) (Latency), the degree that the RTT changes (i.e. Jitter) and the rate of packet drops (if any)
  • To discover devices on a network (nmap –sP –PN!)
  • To discover any MTU limitations and network performance issues that can result

Continue reading

Bruce’s thoughts on Fault Finding

Fault finding is an incredibly subjective topic, I can’t think of the perfect fault finding process but there are a number of hints and best practices that a network engineer will pick up over time. From my recent TSHOOT studies, Cisco defines the fault finding process as:

  • Define the Problem
  • Gather Information
  • Analyse Information
  • Eliminate Possible Problem Causes
  • Formulate a Hypothesis
  • Test Hypothesis
  • Solve the Problem

This is a good position to start discussing my thoughts about fault finding issues in a network.

Continue reading



Tom has kindly asked that I contribute to Etherhex, which of course, I immediately accepted.

Tom and I used to work with each other and even despite moving to different places we are still drawn to asking questions around networking.

To begin with I want to focus my input to Etherhex around the day to day of what a network engineer in our position comes up against. In the line of work that we do we often have to have an understanding of the end app to both design and operate the network. Often the network is blamed which means we need to gather the appropriate information to see if it is us or not. For this I can not stress the benefit of having a solid Network Management System (NMS).

So, watch this space in the New Year!