Baselining a Cisco 8832 Phone

Demonstrating the value of baselining, in this example, we capture the device bootup and investigate any anomalies of a Cisco 8832 phone.

Tony Fortunato

August 17, 2020

The problem with baselining is that very few people do it. In some cases, the analyst has “paralysis due to analysis.” In other words, they over think what is involved in producing a baseline and never do one.

I will give you the best tip I know regarding baselining: “just capture and start something.” Don’t worry about ‘getting everything’ or expecting to ‘understand every packet you see.’ Decide on a goal for your baseline and meet that goal. Heck, just capturing some packets, giving the trace file a meaningful name, and filing it away is incredibly helpful.

One of my favorite baselines is a ‘boot-up’ baseline since it contains so much valuable information. Examples of what I like to generally record is:

  • Client MAC/IP address

  • Network captured from (i.e VLAN, subnet, etc)

  • Boot time

  • Total Bytes or packets transferred

  • Protocol used and not used

  • List of servers client converses with

  • Dhcp options and any relay ip helper address information

  • Commands not responded to

With Wireshark, all this information can be entered into its File Comments (the little pencil on the bottom left corner of the application).

Of course, every device or application will have additional items to document but the goal here is to document how the data was captured, tool used, and the immediate goal you identified. The same trace file can be used for other future reviews or as a comparison if something goes awry.

In this example, we received our first Cisco 8832 and I thought this would be a great opportunity to capture the device bootup and investigate any anomalies. I need a way to capture the bootup traffic and using a span port was not an option in this specific environment. So, I needed a tap that passed POE (power over Ethernet) and, in this case, a regular tap where I used my Ethernet port would trip the switch port security settings. The other thing about using my Ethernet port to capture packets is that due to Microsoft filtering, possible firewall interference, and the inability to see errored packets made this option less desirable.  

The trace was pretty clean with the exception of the phone sending ntp commands to an old decommissioned ntp server. Everybody’s immediate reaction was that was due to a misconfigured DHCP option. When we checked that’s was not the case.

I showed them that the ntp ip address file was provided within one of the many files that the phone downloads from their Cisco Unified Communications Manager. I documented the file and the voice admin made the change. This is a great example of simply ‘tuning and cleaning up’ the many settings in the typical corporate environment.

It’s worth noting that I use Jaspers tracewrangler to clean up the trace file for my video.

About the Author(s)

Tony Fortunato

Sr Network Performance Specialist

Tony Fortunato is a network performance expert who has been designing, implementing and troubleshooting networks since 1989. His company, The Technology Firm, provides clients of all sizes with services ranging from project management, network design, consulting, troubleshooting, designing custom-designed training courses, and assisting with equipment installation. Tony's experience in networking started with financial trading floor networks and ISPs, where he learned to integrate and support equipment from various vendors. Tony has taught and presented at numerous colleges and universities, public forums and private classes. He blogs frequently at NetworkDataPediaand has a popular YouTube channel.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
More Insights