Rudimentary support of the ifTable MIB for intel10g

[alexandergall]

To be useful in the Real World, I need some way of monitoring the status of an interface. This PR uses the shared memory IPC construct to populate a row in the regular interface MIB for each instance of the intel10g driver. The status is checked every 5 seconds.

To make use of it, one needs an SNMP (sub-)agent that supports the semantics of the shmem module. I have such a beast (coming soon to a Git repository near you) and this is how a table walk looks like on my test system with two active interfaces:

IF-MIB::ifDescr.1 = STRING: 0000:04:00.0
IF-MIB::ifDescr.2 = STRING: 0000:04:00.1
IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifSpeed.1 = Gauge32: 10000000
IF-MIB::ifSpeed.2 = Gauge32: 10000000
IF-MIB::ifAdminStatus.1 = INTEGER: up(1)
IF-MIB::ifAdminStatus.2 = INTEGER: up(1)
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.2 = INTEGER: up(1)
IF-MIB::ifLastChange.1 = Timeticks: (1200) 0:00:12.00
IF-MIB::ifLastChange.2 = Timeticks: (1200) 0:00:12.00

The ifOperStatus changes when I shut down the interface on the attached host (or unplug the cable) and even the timers work correctly :)

IF-MIB::ifDescr.1 = STRING: 0000:04:00.0
IF-MIB::ifDescr.2 = STRING: 0000:04:00.1
IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifSpeed.1 = Gauge32: 10000000
IF-MIB::ifSpeed.2 = Gauge32: 10000000
IF-MIB::ifAdminStatus.1 = INTEGER: up(1)
IF-MIB::ifAdminStatus.2 = INTEGER: up(1)
IF-MIB::ifOperStatus.1 = INTEGER: down(2)
IF-MIB::ifOperStatus.2 = INTEGER: up(1)
IF-MIB::ifLastChange.1 = Timeticks: (300) 0:00:03.00
IF-MIB::ifLastChange.2 = Timeticks: (4300) 0:00:43.00

It would be fairly easy to include traffic counters directly through this MIB but I'm not sure if this is the way to go.

I use our current convention to identify an interface by its PCI address.

[alexandergall]

I guess I need to recover more gracefully if the directory for the shmem files doesn't exist (this is what breaks some of the test cases).

[lukego]

This is awesome work! Let me kick the straightline branch a bit before digging into this :)

[lukego]

Newbie question: In the brave new world of YANG are the IF-MIB objects still used? I mean: should we expect to support SNMP and YANG with the same backend or will they be separate? cc @plajjan

[plajjan]

Nope, IF-MIBs are replaced by the operational parts of a YANG model. Naturally, there is often a form of one-to-one mappings between them, mostly because we usually want to get the same type of data, like ifInOctets, regardless if it's SNMP or YANG.

Here's a YANG model that does roughly what IF-MIB does and it includes a mapping table between how we used to do it in SNMP and what it is called with YANG.
https://datatracker.ietf.org/doc/rfc7223/?include_text=1

[lukego]

Looks like the YANG models are taking pains to be compatible with the SNMP models, and so we can reasonably expect our SNMP support to gracefully extend to YANG in the future?

For example, the instrumentation that this pull requests adds to the driver would supply the statistics information to make both models happy? (I ask for the sake of my own education. I am perfectly happy to merge SNMP and YANG support separately.)

I have more questions for you guys :-). My experience with SNMP etc has mostly been implementing MIBs and I have always suspected that most objects that I lovingly populate will never be used by anybody. Please enlighten me to what is actually interesting and important as a network operator from:

1. Physical network interface statistics.
2. Sub-network interface statistics (SR-IOV, VMDq, VRF, VLAN, etc).
3. Virtual network interface statistics (Virtio-net interfaces to virtual machines).
4. Relationships/heirarchy between network interfaces (ifStackTable)
5. Snabb Switch app network internal interface statistics (links)
6. Other common MIB-II objects
7. Other objects entirely?

[alexandergall]

Well, this PR is just a pragmatic hack to get the most basic monitoring working. Trying to come up with a scheme that will also work for NETCONF/YANG is futile at this point, because we haven't even started to tackle the whole configuration/monitoring issue. It would certainly make sense to collect the data in a manner that makes it easy to implement various front-ends for accessing it, but we (well, at least I :) don't know yet what that should look like.

Of course, support for SNMP is a must if any of this stuff should work in a real-world network. I don't know if we need a list of MIBs that we need to support up front (but the IF-MIB is an obvious must-have). The designer of a Snabb module should decide which MIBs are relevant. In my case, for example, I need the MIBs from the "PWE3" (pseudowire edge-to-edge emulation) framework to make the whole thing fit in our own monitoring system. One of the strenghts of our project will be that we will be able to implement quickly whatever the operators need, in contrast to the fossilizied systems of (some) vendors.

[plajjan]

I suppose that there isn't really that much support or awareness in Snabb except for the naming of the values that follows the IF-MIB in your example, right!?

Values are named differently in SNMP and YANG so supporting both means that at least one will need a translation table. My (completely unbiased :P) opinion is that we should try to be closer to YANG and do translation for SNMP.

With that said, I do understand your perspective. If you want to do monitoring today it is a lot easier using SNMP. While it certainly is possible with YANG (we do it!), there's a lot fewer tools (especially FOSS) available out there.

I think of this similar to IPv4 and IPv6. If you want something today to communicate on the Internet you'd like IPv4 (that would be the equivalent of SNMP) while you know that IPv6 is the long term protocol (YANG). I'd rather design something for the long term and have mapping for the short term, than the other way around, again native YANG naming and translation for SNMP. On the other hand, I'm not religious about this, as long as there is a possibility to support both I'm happy :)

Oh, and great work @alexandergall :>

[plajjan]

@lukego 1 through 5 are all rather interesting. For my use case I think I'm less interested in hierarchy between things as I will likely already know that (since I pushed the configuration from my provisioning system I know how it looks). It could be useful nonetheless.

If I were to give a priority order, I think it would follow the order you have written them in, perhaps with 4 and 5 swapped.

[lukego]

Thanks for the great input!

[lukego]

Alex, what do you think about moving this SNMP instrumentation from the intel10g object into the link object?

The link object would need to track more state (admin/operational status) and the apps/drivers would have to supply this. The benefit would be that we could monitor any link with SNMP.

(I'd like to add this SNMP monitoring support to the Virtio-net interfaces for NFV too.)

[lukego]

Relevant news: Cisco have released Tail-f ConfD for free-as-in-beer now. (Looks like the free version excludes SNMP.)

I have used ConfD in the past. You can write a YANG model and ConfD will handle all CLI/SNMP/NETCONF/etc for you. There are multiple ways to integrate the management plane with the traffic plane, including a really simple batch import/export one that I like.

Something for the future?

[alexandergall]

On Thu, Feb 19, 2015 at 10:28 AM, Luke Gorrie notifications@github.com wrote:

Alex, what do you think about moving this SNMP instrumentation from the
intel10g object into the link object?

The link object would need to track more state (admin/operational status)
and the apps/drivers would have to supply this. The benefit would be that we
could monitor any link with SNMP.

I'm not sure how exactly a generic link should be modeled as an
interface, but, yes, I guess that could make sense. It doesn't seem
like a straight-forward hack to tie it into the app system, though. In
fact, the object that this code is monitoring is precisely not the
link that connects the intel driver with another app but the
"external" interface through which the driver pulls in packets from
the outside. I'll have to ponder this a little :)

(I'd like to add this SNMP monitoring support to the Virtio-net interfaces
for NFV too.)

—
Reply to this email directly or view it on GitHub.

[lukego]

I will ponder too. Can be that it is the wrong solution and that it is better to explicitly register interfaces. I'll look at the most straightforward way to tie in Virtio interfaces.