Re: EdgeMax (Zebra) MIB

I discovered GNOME-PRODUCT-ZEBRA-MIB in the /usr/share/snmp/mibs directory on the EdgeRouter itself. However, it references (is dependent on) GNOME-SMI which is not included in that directory. Also, the specific trap I'm getting ...3317.1.2.5.0.16 (...gnome.gnome-products.zebra.ospfd.0.16) is not listed in the ZEBRA mib. it stops at the ospfd = zebra.5 level.

So, what's needed is:

1) Include GNOME-SMI in the /usr/share/snmp/mibs directory in order to be able to use the existing GNOME-PRODUCT-ZEBRA-MIB.

2) Extend the GNOME-PRODUCT-ZEBRA-MIB (or perhaps add a separate file) to identify the OIDs used in Zebra traps. Otherwise, the EdgeRouter is sending traps that management stations can't recognize other than "ospfd.0.16" (and probably others).

Re: EdgeMax (Zebra) MIB

Thanks. Yeah, I found that, too. And that's where it gets interesting.

The older versions of GNOME-SMI used enterprise number 3317. The version you referenced is newer (produced in 2007) and shows enterprise number 3319. It seems to be the most recent version I've found.

But the traps sent from the EdgeRouter show enterprise 3317. Doing more hunting around, enterprise 3317 seems to be for FreeRADIUS. But RADIUS is not configured in the EdgeRouter (and I'm not aware that it's even a feature). So maybe the code that produces the traps is wrong (using the old enterprise number)?

Bottom line, UBNT should supply whatever MIBs are necessary to manage their products (wherever they ultimately come from). Without this information, the EdgeRouter is producing traps which are undecipherable. We shouldn't have to hunt around like this.

Re: EdgeMax (Zebra) MIB

mhmm, looking at the revision description in the mib it looks like the 3317 is indeed the wrong OID.

I know there is some work being done (especially airMAX side which has up until recently had abysmall SNMP support, and even then it's only fixed in the latest betas not release versions) to make SNMP better at ubnt. Most of the MIBs actually come from upstream products that EdgeOS uses (in this case quagga/zebra) and are not ubnt-authored - but it would be good for a central repository of all the MIBs to be assembled somewhere (perhaps in the form of a KB article?). Might be worth ubnt seeing if they can update to use the newer MIBs for ease of use?

Note the link I provided is actually a svn repo, you might find the older MIB as a revision there if you're lucky. Sadly the Quagga website doesn't seem to be very useful in this regard either (and they're the ones implementing it!).

... the correct enterprise number for gnome is 3319. So the later version of the GNOME-SMI MIB is correct.

But the traps from the EdgeRouter have enterprise number 3317.

We now know that the old GNOME-SMI MIB incorrectly specified the enterprise number as 3317. And we now know that that's the version that shows up in Quagga's GIT repository. So it's probably safe to assume that the traps coming from the EdgeRouter with enterprise 3317 are not really from enterprise 3317 but are actually from Quagga (routing).

So, the problem remains:

The Ubiquity EdgeRouter is sending traps that are not decipherable

Based on the detective work above, there appear to be three components to the solution:

1) Someone needs to fix the Quagga code and MIB to use the correct enterprise number (3319).

2) UBNT needs to include the GNOME-SMI MIB in /usr/share/snmp/mibs (whatever version actually matches the code).

3) Someone needs to extend the GNOME-PRODUCT-ZEBRA-MIB to include the the rest of the OID tree that is actually being used in the code to send traps.

Until all three are done, some of the EdgeRouter traps will not be decipherable.

I don't know the protocol here. Will someone from UBNT take this info and log it as a bug(s)?

Re: EdgeMax (Zebra) MIB

I'd probably raise the issue with the quagga guys directly first, then when it is decided on how it's going to be fixed upstream get the patches ported to EdgeOS afterwards.

The ubnt guys are fairly resource constrained so I doubt they have the spare resources to fix this themselves (or at least not in any reasonable amount of time), but would most likely be able to incorperate patches from upstream realtively easily.

Re: EdgeMax (Zebra) MIB

Good catch on the missing GNOME-SMI, that was missing in "upstream" as well. I've just fixed our quagga packaging to include the GNOME-SMI file as well (the file is actually there, just not included), so that will be in the next release.

For the numbering issue, as NVX said it might be better to get it fixed through Quagga upstream. Also, I checked the code and for example, it seems to be using OSPF-TRAP-MIB.txt for the traps, and those files should be on the router (in the same directory). Could you try those files and see if they provide enough information?

Re: EdgeMax (Zebra) MIB

I do have OSPF-TRAP-MIB.txt loaded. But as mentioned above, I'm getting a trap with OID = ...enterprises.3317.1.2.5.0.16 which is ...ospfd.0.16 which is not part of the quagga MIB. More recently, I've seen ...ospfd.0.2. I presume there will be others.

BTW, these traps occur when an OSPF interface is unplugged. In the case of ...ospfd.0.16, the interface has no neighbors. In the case of ...ospfd.0.2, there is a neighbor.

So the two things still missing are:

1) Correct the enterprise number in the OID to from 3317 to 3319.

2) Fill in the missing parts of the MIB to cover all enterprise-specific traps.

I will visit the quagga project website and attempt to report these there. But I strongly suspect you or Stig have direct ties with those guys and could get their attention better than some random person they've never heard from.

Re: EdgeMax (Zebra) MIB

BTW, based on just these two examples, it may be that the quagga code is paralleling the ospf trap mib, but using it's own enterprise-specific OID. If that is indeed what's happening, then that's pretty dumb. The world doesn't need yet another ospf mib. So, better than extending the quagga MIB to cover the OIDs that they're sending in traps would be to send the standard ospf-trap-mib OIDs instead.

Re: EdgeMax (Zebra) MIB

mefox: Yes I compared the OSPF SNMP code in ours with the upstream stable 0.99.20 (our base) and it's identical. And actually the exact same OSPF-TRAP-MIB.txt file is present in the same quagga source directory, so I think they did intend to use it but probably it's not doing it correctly. I do see a few trap-related changes in the quagga "master" branch that are not back-ported to the stable releases, so we could see if we can cherry-pick those changes.

Re: EdgeMax (Zebra) MIB

I haven't looked at the code, but one likely scenario I thought of last night:

They may be setting a variable to hold the OID "prefix" (i.e. 1.3.6.... every up to but excluding the ending number). And then, when issuing the trap, they use <prefix>.<value>, where value is 16 or 2 as we've seen. And perhaps they simply forgot to reset the prefix to the ospftrap prefix instead of their quagga ospfd prefix. That would explain why the ending value tracks exactly with the ospf-trap-mib but uses their enterprise-specific "prefix".