packetmischief.ca

It’s May and that means a new version of OpenBSD is out. My SNMP MIBs have been updated for 5.1 and are available for download on the OpenBSD SNMP MIBs page.

THIS WILL BE ONE OF THE LAST RELEASES OF THE MIBS FOR NET-SNMP

During the OpenBSD 5.1 development cycle, I committed the CARP MIB to the base OpenBSD snmpd. The kernel sensor MIB has been in the base snmpd for a few releases now. That leaves the pf MIB which was committed to 5.1-current some weeks ago and will be present in the 5.2 release.

So, you’ve got a few options.

1. Want to still run Net-SNMP with the extra MIBS? Go to the SNMP MIBs page and follow the directions. No change from previous versions. However, make plans to migrate away from Net-SNMP for OpenBSD 5.2.
2. Only use the CARP or kernel sensors MIB? Use the base snmpd(8). There’s no configuration necessary, just run the daemon. The MIB files are in /usr/share/snmp/mibs/ (The pf MIB file is present there, but the implementation is not part of snmpd(8) in 5.1). You should also read my guide on what’s changed between the Net-SNMP and snmpd(8) implementations of the MIBs.
3. Want to use the base snmpd(8) but still have a requirement for Net-SNMP? See my blog post on using both together.

Cisco’s Identity Services Engine (ISE) is a powerful rule-based engine for enabling policy-based network access to users and devices. ISE allows policy enforcement around the Who?, What?, and When? of network access.

• Who is this user? A guest? An internal user? A member of the Finance department?
• What device is the user bringing onto the network? A corporate PC? A Mac? A mobile device?
• When are they connecting? Are they connecting to the secure network during regular business hours or at 02:00 in the morning?

These questions can all be answered easily within ISE and are all standard policy conditions that are relatively easy to implement. In the post below I’m going to focus on the How? — How is the user or device connecting to the network? Asked another way, the question is Wired? or Wireless? Read More >>

FabricPath is Cisco’s proprietary, TRILL-based technology for encapsulating Ethernet frames across a routed network. Its goal is to combine the best aspects of a Layer 2 network with the best aspects of a Layer 3 network.

• Layer 2 plug and play characteristics
• Layer 2 adjacency between devices
• Layer 3 routing and path selection
• Layer 3 scalability
• Layer 3 fast convergence
• Layer 3 Time To Live field to drop looping packets
• Layer 3 failure domain isolation

An article on FabricPath could go into a lot of detail and be many pages long but I’m going to concentrate on five facts that I found particularly interesting as I’ve learned more about FabricPath.

Read More >>

I don’t really keep up to speed on consumer technology. For me, the enterprise IT space holds more challenge and interest. There is one piece of consumer tech though that has become fully ingrained in my life: the tablet. For that reason, I’m going to summarize my experience in using both Android and Apple based tablets. Read More >>

These are some articles/interviews that I came across this week that got me thinking about Apple’s Bonjour in enterprise environments. Read More >>

I’ve had two main areas of interest in my IT career. Professionally, I’ve been a network guy. Designing, building, and supporting IP networks is what pays my bills. On the other side, I’m a Unix geek. Building, tinkering, and hacking code on Unix systems and related open source software has always been fun and challenging for me. Recently I was reflecting on my career and realized that my Unix and open source experience has played a big role in my career as a network engineer. Here’s some of the ways I believe network engineers can benefit from Unix experience. Read More >>

I read an excellent blog post by Scott Lowe (@scott_lowe) this week on Single Root I/O Virtualization (SR-IOV) titled “What is SR-IOV?“. It’s an older post but it did a great job of solidifying my understanding and filling in the knowledge gaps. One thing that stuck out was this bit:

SR-IOV requires support in the BIOS as well as in the operating system instance or hypervisor that is running on the hardware. Until very recently, I had been under the impression that SR-IOV was handled solely in hardware and did not require any software support; unfortunately, I was mistaken. Software support in the operating system instance or hypervisor is definitely required.

Like Scott, I didn’t realize there was a software dependency. Here’s the kicker though:

I do not have a timeframe for SR-IOV support in VMware vSphere or Microsoft Hyper-V.

Ouch. I immediately wondered how the Virtual Interface Cards (VICs) in Cisco UCS were able to successfully present multiple vNICs and vHBAs to the hypervisor. Was Cisco pulling a fast one? Was this only possible if the UCS node was running an OS like Windows or Redhat on bare metal and not when running vSphere or Hyper-V?

To the Google! Actually, first to bradhedlund.com. Brad (@bradhedlund) is well known in the blogosphere and Twitterverse as a Cisco UCS authority. He plainly points out [Cisco UCS criticism and FUD: Answered, answer to question #6] that the UCS VIC does not employ SR-IOV but uses alternate, standards-based PCIe methods of presenting virtual hardware to the hypervisor.

To further drive the point home, the datasheet for the first generation “Palo” adapter [UCS M81KR Virtual Interface Card] and the gen 2 1240/1280 cards [UCS Virtual Interface Card 1240 Data Sheet] both state that IO virtualization is achieved without the use of SR-IOV.

So there we go. Question asked and answered. I don’t quite understand what the “alternate methods” are, but I know that the VIC adapters will work just fine with vSphere and Hyper-V.

On a side note, the thing that led me down this rabbit hole was Scott’s recent post on SR-IOV support coming in the next version of Hyper-V [SR-IOV Support in the Next Version of Hyper-V].

RANCID (Really Awesome New Cisco confIg Differ) is a tool for automating the collection of hardware and configuration data from network devices. I recently upgraded an installation from version 2.3.1 to 2.3.8. And naturally, because I didn’t have a ton of time to devote to this, stuff broke. It stopped pulling data from some switches. Not all switches, mind, that would be too easy to troubleshoot. Only some.

Read More >>

Although it would be awesome to ditch Net-SNMP altogether now that the base OpenBSD SNMP daemon has support for all of the OpenBSD-related MIBS (CARP, PF, kernel sensors), reality is that Net-SNMP still offers some features that are needed. OpenBSD doesn’t have any SNMP tools (snmpwalk, snmpset, etc) so these are still required from Net-SNMP. There’s also some unique features in the Net-SNMP daemon that are still useful if you want to do things like monitor BIND9 or Postfix statistics.

Here’s how to run both at the same time and leverage snmpd for the OpenBSD-related MIBs and the Net-SNMP daemon for its ability to retrieve data from scripts and extend itself using loadable modules and smux sub-agents. Read More >>

Update: For help running both snmpds at the same time, see Net-SNMP and snmpd Coexistence on OpenBSD.

Now that OPENBSD-CARP-MIB and OPENBSD-PF-MIB have been added to the base snmpd in OpenBSD (CARP-MIB will be in 5.1-release, PF-MIB in 5.2, and the SENSOR MIB has been there since 4.5), I wanted to document the differences between these MIBs and the corresponding implementation of the MIBs that I wrote for Net-SNMP.

Both implementations provide the same set of OIDs and allow the same data to be retrieved. Whatever you were querying via Net-SNMP is available via snmpd.

What has changed is the base OID where the CARP and PF MIBs are rooted at as well as the name of certain OIDs. Read More >>