Eric Stewart: Running Off At The Mouth

It is possible on the Nexus 7700 line, with certain optics, to break out 40Gb (and eventually 100Gb) to 4x10Gb interfaces (no one knows for sure what 100Gb will do – it will either be 8x10Gb or 10x10Gb). In this post I go over how $JOB is doing it (at least with the 40Gb) and what you need to be aware of. I do touch a little bit on the 100Gb breakout future and explain why we were looking to do it.

We racked our Nexus 7710 recently. Here’s some of the things you might need to know regarding getting this monster of a chassis into a rack.

I figured I should get this written while I can, and before it all fades away from my brain … here’s my thoughts on Cisco Live and some advice for future first-time attendees.

So we powered on our first to arrive Nexus 7706s (two of them). Here’s some notes so far.

As is not unusual, I run into an edge case that might be specific to us. While attempting to monitor IPv6 reachability of an NTP server I had just upgraded, I ran into an interesting case where NTP was responding via IPv4, but not IPv6, and they appeared to be identically configured.

It’s been a while since I’ve done more than just update the Unified Trees post for new versions, and I stumbled across an issue that Linux administrators that make use of iptables should be aware of. The case is actually true for any “client initiated connection” when it comes to iptables – not just MySQL slaves. That’s just where I stumbled across the issue.

Got multiple Cacti installs? Want the Tree view of your graphs to show all of your trees mashed together? Then this is the plugin for you.

I wrote a Cacti plugin I called DPDiscover – Discovery Protocol Discover, which uses LLDP, CDP, and FDP information pulled from SNMP to ‘spider’ a network and attempt to automatically add equipment to Cacti. It is heavily based off of the original “Auto Discovery” plugin that would sweep IP ranges.

An attempt to communicate an issue (and the solution) I ran into with Perl’s Net::SNMP function “get_table”, that would result in a “The message size exceeded the buffer maxMsgSize of 1452” error. It took a couple of packet captures and Googling to figure out why this problem was occurring and implement a fix.

A fellow engineer attempting to debug a jumbo frames issue was seeing what should have been a bunch of fragmented frames as a single 13,000 byte frame. Once he figured out why, I was told to fix it. Here’s my solution.