[f-nsp] Basic SNMP MIBs missing

[Frank Bulk]

Youssef,

 

Thanks, that’s exactly my point – the hard work of extracting the data from the optic has already been done, it’s just a matter of exposing it in right MIB of the SNMP engine.

 

Frank

 

From: Youssef Bengelloun-Zahr [mailto:bengelly at gmail.com] 
Sent: Monday, March 13, 2017 1:21 AM
To: frnkblk at iname.com
Cc: Wilbur Smith <wsmith at brocade.com>; foundry-nsp at puck.nether.net
Subject: Re: [f-nsp] Basic SNMP MIBs missing

 

Dear Frank,

 

Yes, it is. That's is why it's so frustrating !

 

Seems like someone decided it was a good idea to develop the capability code half way through !?!

 

Best regards.

 


Le 13 mars 2017 à 05:21, <frnkblk at iname.com <mailto:frnkblk at iname.com> > <frnkblk at iname.com <mailto:frnkblk at iname.com> > a écrit :

Isn’t what’s being requested already available from the CLI?

 

Frank

 

From: foundry-nsp [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Wilbur Smith
Sent: Thursday, March 9, 2017 1:37 PM
To: Youssef Bengelloun-Zahr <bengelly at gmail.com <mailto:bengelly at gmail.com> >; foundry-nsp at puck.nether.net <mailto:foundry-nsp at puck.nether.net> 
Subject: Re: [f-nsp] Basic SNMP MIBs missing

 

Sorry you’re having issues with our MIB support. We try to support as many MIB OIDs as possible on as many platforms, but the reality is additional code needs to be written for every new OID. Optics can be specifically challenging because there’s no standard RFC based MIB to pull some types of data from the optic. I checked and this isn’t included in RFC-1213 (MIB-II), RFC-1775 (RMON),  RFC-4133 (Entity), 

 

Different optics manufacturers will also use different standards for passing this information; this standard also needs to also be compatible with the SERDES & chipset vendor’s own implementation. Sometimes supporting this isn’t as clear cut as we would like it to be and can take time & resources to build. We’re pretty good about supporting customer RFC’s though and we’ve added a lot of OID values to Fastiron & VDX based on customer requests, so we may add support for your request in a future release. Disclaimer: I’m not a Program Manager and can’t give you any insight into if/when. 

 

For VDX it does look like we support OID strings for portFault, noLight, etc on Fiber Channel ports (see string 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.3). Because of the way VDX thinks of Ethernet & FC ports this OID may return data for an Ethernet optic…worth a try. 

 

Wilbur

 

 

 

From: foundry-nsp [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
Sent: Monday, February 27, 2017 2:26 AM
To: foundry-nsp at puck.nether.net <mailto:foundry-nsp at puck.nether.net> 
Subject: [f-nsp] Basic SNMP MIBs missing

 

Dear Community,

Just wanted to share a basic / silly / simple experience I have gone through with our favorite $VENDOR.

We use observium as an NMS for our backbone (MLXe / CERT, FCX,VDX) and I recently noticed lack of support for basic SNMP MIBs, in particular ones responsible for gathering transceivers' sensors values for FCX and VDX switchs.

After opening cases with BTAC, I was told that it was perfectly normal (in 2017 !?!) because those specific MIBs were not implemented by design and that if I needed them, I should open up RFE requests... which I did with the help of my local SE :

PRODRFE104332: regarding VDX implementation
PRODRFE104333: regarding FCX implementation
 

It has also made its' way on Observium's facebook page : https://fr-fr.facebook.com/observium/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__fr-2Dfr.facebook.com_observium_&d=DwMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=l86Fj-WC0GHHSCjQjuUvTzxOj0iW25AHL3VIC5Dog8o&m=NmkDsINSY69cmh7Wmt7rWUQIuizZDEShiAN3aMagP-w&s=F8o92HgaKWqbiq1otVLKuwG1cuP8DppUlUJ_giSHcvM&e=> 

So, if you do love your favorite $VENDOR as much as we do and consider that your big bucks are worth having basic SNMP support in 2017, please start harrassing your SEs in order for SNMP MIBs to be implemented.

I hope this feedback will inspire you.

Best regards.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20170313/80f381fc/attachment-0001.html>