Add Support for Calix B6-316 and B6-318 blades

Device Requests
1

We use the Calix B6 platform in our shop. I have set up all of the devices on LibreNMS. While some of the metrics (processor etc) are showing up. I am having trouble especially with the ports not returning utilization on many of the port graphs.

I was wondering if someone could help us through the process of getting ports to map correctly. I am a newbie so I will probably require some hand holding, but I am willing!

I did the initial discoveries etc on a B6-316 blade.

I did a validate.php and everything seems in line.

./discovery.php -h HOSTNAME -d | ./pbin.sh = https://p.libren.ms/view/8d78d244
./poller.php -h HOSTNAME -r -f -d | ./pbin.sh = https://p.libren.ms/view/3a7db849
snmpbulkwalk -OUneb 172.17.1.0 -c public -v 2c . | ./pbin.sh = https://p.libren.ms/view/e9bb3635

Here is a link to the mibs: https://1drv.ms/u/s!Aq7M3pKXhPyGhpAstJDlOvgk54y4MA?e=R1wcZD

Also, the Calix logo is in stock because libreNMS supports a different platform of theirs.

Any and all help would be much appreciated, please let me know what else I can provide!

Thank you,

bwehrspann

2

Hi @bwehrspann
Seems that the snmpwalk is incomplete. Or the SNMP implementation is incomplete. But clearly, with current snmpdata, there is not much we can add.

I am wondering if the issue is not snmpbulkwalk. Also adding a longer timout. Can you try to run this command instead :
snmpwalk -t 10 -OUneb 172.17.1.0 -c public -v 2c . | ./pbin.sh

Bye

3

Good call on the snmpbulkwalk timeout.
Here’s 12000+ lines instead of 511.

snmpwalk -t 10 -OUneb 172.17.1.0 -c public -v 2c . | ./pbin.sh = https://p.libren.ms/view/7556bd12

Also, I should mention I found the definition / discovery yaml file under occamos.yaml.

Which makes sense as this is the original vendor of the product line.

Let me know what I need to do next.

Thanks

Ben Wehrspann

4

Hi @bwehrspann
It is indeed much better with the walk (instead of bulk) and the timeout.
To see which one for the 2 change is the fix, you can try :

snmpwalk -OUneb 172.17.1.0 -c public -v 2c .

and

snmpbulkwalk -OUneb 172.17.1.0 -c public -v 2c .

If you get a correct result only with the 1st one, you need to add this line into includes/definitions/occamos.yaml :

nobulk: true

(If this is the correct fix, please come back here so we can patch LibreNMS directly, and everybody will get the fix).

If the timeout is the solution, then you can adapt it for your install here :
http://librenmsServer/settings/poller/snmp

5

I tried both snmpwalk without the timeout and snmpbulkwalk with timeout = 10. Both work.
I’ve chosen to use the nobulk: true in the occamos.yaml definition file at this time since it is a bit more specific.
These devices poll slowly.

I have been looking at the port graphs and the labels I don’t think are right. Can we get these port labels to assign to the ports?

.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.6 = STRING: “Ethernet1/48”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.7 = STRING: “Ethernet1/47”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.8 = STRING: “Ethernet1/46”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.9 = STRING: “Ethernet1/45”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.10 = STRING: “Ethernet1/44”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.11 = STRING: “Ethernet1/43”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.12 = STRING: “Ethernet1/40”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.13 = STRING: “Ethernet1/39”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.14 = STRING: “Ethernet1/38”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.15 = STRING: “Ethernet1/37”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.16 = STRING: “Ethernet1/36”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.17 = STRING: “Ethernet1/35”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.18 = STRING: “Ethernet1/32”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.19 = STRING: “Ethernet1/31”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.20 = STRING: “Ethernet1/30”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.21 = STRING: “Ethernet1/29”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.22 = STRING: “Ethernet1/42”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.23 = STRING: “Ethernet1/41”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.24 = STRING: “Ethernet1/34”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.25 = STRING: “Ethernet1/33”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.26 = STRING: “Ethernet1/28”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.27 = STRING: “Ethernet1/27”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.28 = STRING: “Ethernet1/26”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.29 = STRING: “Ethernet1/25”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.30 = STRING: “Ethernet1/20”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.31 = STRING: “Ethernet1/4”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.32 = STRING: “XgEthernet1/1”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.33 = STRING: “XgEthernet1/2”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.34 = STRING: “XgEthernet1/4”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.35 = STRING: “XgEthernet1/3”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.36 = STRING: “Ethernet1/19”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.37 = STRING: “Ethernet1/18”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.38 = STRING: “Ethernet1/17”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.39 = STRING: “Ethernet1/8”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.40 = STRING: “Ethernet1/7”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.41 = STRING: “Ethernet1/24”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.42 = STRING: “Ethernet1/23”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.43 = STRING: “Ethernet1/22”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.44 = STRING: “Ethernet1/21”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.45 = STRING: “Ethernet1/16”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.46 = STRING: “Ethernet1/15”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.47 = STRING: “Ethernet1/3”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.48 = STRING: “Ethernet1/2”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.49 = STRING: “Ethernet1/1”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.50 = STRING: “Ethernet1/6”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.51 = STRING: “Ethernet1/5”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.52 = STRING: “Ethernet1/14”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.53 = STRING: “Ethernet1/13”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.54 = STRING: “Ethernet1/12”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.55 = STRING: “Ethernet1/11”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.56 = STRING: “Ethernet1/10”
.1.3.6.1.4.1.6066.2.1.3.1.1.11.1.4.769.1.57 = STRING: “Ethernet1/9”

6

OK, I’ll suggest you monitor this for a while and we’ll see the result.

Concerning the port names, unfortunalely, we don’t have any easy way to use anything else than IF-MIB (the standard IF MIB standard).
And I don’t seen a lot of difference between both in fact, GigabitEthernet1/48 becomes Ethernet1/48 in the proprietary mib (which looks less precise). And 10GigabitEthernet becomes XgEthernet (again, XgEthernet does not look very good either).
So if the vendor decided to provide more standard names in IF-MIB, we should definitely stick with that.

7

Is your device “far” from your LibreNMS device ? What is the latency between both ? If latency is high, increasing the timeout and keeping the bulk is better.
If latency is normal (below 10 ms) then the device is slow and we need to get around that by disabling bulk (using nobulk: true).

8

Latency is low:
[root@Jesup-LibreNMS definitions]# ping 172.17.1.0
PING 172.17.1.0 (172.17.1.0) 56(84) bytes of data.
64 bytes from 172.17.1.0: icmp_seq=1 ttl=62 time=0.698 ms
64 bytes from 172.17.1.0: icmp_seq=2 ttl=62 time=0.428 ms
64 bytes from 172.17.1.0: icmp_seq=3 ttl=62 time=0.443 ms
64 bytes from 172.17.1.0: icmp_seq=4 ttl=62 time=0.757 ms
64 bytes from 172.17.1.0: icmp_seq=5 ttl=62 time=0.552 ms
64 bytes from 172.17.1.0: icmp_seq=6 ttl=62 time=0.902 ms
64 bytes from 172.17.1.0: icmp_seq=7 ttl=62 time=0.808 ms

So increasing the timeout is probably better. Is there a way to adjust this in occamos.yaml or should I adjust it by device. I have 36 devices I’ll need to adjust if I do it through the gui. Or can I do it dynamically by device group?

Ben

9

I have the Vendor MIBS, but it appears that some of the standard ones in the Vendor MIBS might be overiding the standard ones that LibreNMS normally uses. Can you help me understand which ones to keep?

Here is a link to the mibs: https://1drv.ms/u/s!Aq7M3pKXhPyGhpAstJDlOvgk54y4MA?e=R1wcZD

Thanks

Ben

10

If latency is low, then you have to use the nobulk variant. Means that the device is not handling the bulk command as we hoped it will do.
Bulk is here to make snmpwalk faster … It behave the exact opposite with your device, so we turn to standard snmpwalk instead if it works.

So the fix will come with LibreNMS update (We’ll change the YAML file). Until then, you can manually change your YAML file (but then you’ll have to revert your fix to get LibreNMS accept the patched version during upgrade).

11

I realized I misunderstood what you wrote.

“If latency is normal (below 10 ms) then the device is slow and we need to get around that by disabling bulk (using nobulk: true ).”

I’ll keep the ‘nobulk: true’ in occamos.

Sorry for the confusion.

12

Good for the mibs. Got the necessary ones and I should be able to add a few sensors etc.
Will create a Pull Request in GitHub so you can test it when done.

13

Hi @bwehrspann
You can test sensor support here : https://github.com/librenms/librenms/pull/12744
Please let me know how it goes on your devices.
Bye

14

In vendor CLI interfaces are referred to as follows:

FR102.02-F01-01#show interfaces ?
bvi BVI interface
ethernet Ethernet interface
lag lag interface
mgmt Mgmt interface
summary Show interface summary
xg XG interface

So using:
‘ifDescr’ => ‘10GigabitEthernet 1/2’,
‘ifName’ => ‘XgEthernet1/2’,
‘ifAlias’ => ‘10GigabitEthernet 1/2’,
‘ifType’ => ‘ethernetCsmacd’,
‘ifOperStatus’ => ‘up’,
),

If we could map the GUI description to the ifName for these devices that would be good. Also is there a way to sort the ports differently?

Thanks

Ben

15

@bwehrspann
As I explained, there is no way to use anything else that IF-MIB currently. And IF-MIB implementation is provided by the vendor, not LibreNMS. They decided to provide different names. So if you prefer the proprietary names, you can:

  • Ask the vendor to change the IF-MIB replies
  • Rewrite code in LibreNMS to handle proprietary MIB (that’s a significant amount of code to re-write and (most importantly) test).

Still not clear why the vendor provides different names in IF-MIB and proprietary, but my guess is that the proprietary names are “unusual” names, so they decided to use more “usual” names in IF-MIB. And the matching between the proprietary and IF-MIB names is easy (Xg becomes 10Gigabit, etc etc).

16

I think I understand about the port names. Still learning about MIBS and what they do.

Still exploring the capabilities.

I appreciate all of your help today. I have loaded the patch 12744 and rediscovered my devices.
I definitely have more visiblility to the sensors.

Will continue to test patch and check back later with news and results of testing.

Thanks again,

Ben Wehrspann