Mailing List Archive

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/

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.
Re: Basic SNMP MIBs missing [ In reply to ]
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@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
Sent: Monday, February 27, 2017 2:26 AM
To: foundry-nsp@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.
Re: Basic SNMP MIBs missing [ In reply to ]
Heh... this doesn't surprise me, since I was told by BTAC that they do
not "support" LLDP-MIB on fastiron/ICX devices. We did end up getting
product management involved to get our issue fixed (namely, SNMP is
missing LLDP info for ports after a windows 10 device), but only in
the 8.0.30 code train (which has a lot of major changes from 8.0.10).

Speaking of which, is anyone running 8.0.30 on ICX switches with
mac-based authentication enabled? They really want us to upgrade, but
it terrifies me since it sounds like the mac-auth/802.1x support was
re-written from the ground up (which could be good or bad).

--
Eldon

On Thu, Mar 9, 2017 at 12:36 PM, Wilbur Smith <wsmith@brocade.com> wrote:
> 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@puck.nether.net] On Behalf Of
> Youssef Bengelloun-Zahr
> Sent: Monday, February 27, 2017 2:26 AM
> To: foundry-nsp@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/
>
> 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.
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: Basic SNMP MIBs missing [ In reply to ]
Isn’t what’s being requested already available from the CLI?



Frank



From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Wilbur Smith
Sent: Thursday, March 9, 2017 1:37 PM
To: Youssef Bengelloun-Zahr <bengelly@gmail.com>; foundry-nsp@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@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
Sent: Monday, February 27, 2017 2:26 AM
To: foundry-nsp@puck.nether.net <mailto:foundry-nsp@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.
Re: Basic SNMP MIBs missing [ In reply to ]
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@iname.com> <frnkblk@iname.com> a écrit :
>
> Isn’t what’s being requested already available from the CLI?
>
> Frank
>
> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Wilbur Smith
> Sent: Thursday, March 9, 2017 1:37 PM
> To: Youssef Bengelloun-Zahr <bengelly@gmail.com>; foundry-nsp@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@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
> Sent: Monday, February 27, 2017 2:26 AM
> To: foundry-nsp@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/
>
> 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.
Re: Basic SNMP MIBs missing [ In reply to ]
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@gmail.com]
Sent: Monday, March 13, 2017 1:21 AM
To: frnkblk@iname.com
Cc: Wilbur Smith <wsmith@brocade.com>; foundry-nsp@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@iname.com <mailto:frnkblk@iname.com> > <frnkblk@iname.com <mailto:frnkblk@iname.com> > a écrit :

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



Frank



From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Wilbur Smith
Sent: Thursday, March 9, 2017 1:37 PM
To: Youssef Bengelloun-Zahr <bengelly@gmail.com <mailto:bengelly@gmail.com> >; foundry-nsp@puck.nether.net <mailto:foundry-nsp@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@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
Sent: Monday, February 27, 2017 2:26 AM
To: foundry-nsp@puck.nether.net <mailto:foundry-nsp@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.
Re: Basic SNMP MIBs missing [ In reply to ]
Frank,

I'm happy I'm not the only sharing this point of vue. I was beginning to
think I was some kind of intolerant extremist.

Well, hopefully Brocade will hear us and correct this. Maybe Wilbur can try
to relay this internally ?

I know I am pressing with my SE as much as I can.

Best regards.



2017-03-13 15:25 GMT+01:00 Frank Bulk <frnkblk@iname.com>:

> 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@gmail.com]
> *Sent:* Monday, March 13, 2017 1:21 AM
> *To:* frnkblk@iname.com
> *Cc:* Wilbur Smith <wsmith@brocade.com>; foundry-nsp@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@iname.com> <frnkblk@iname.com> a écrit :
>
> Isn’t what’s being requested already available from the CLI?
>
>
>
> Frank
>
>
>
> *From:* foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net
> <foundry-nsp-bounces@puck.nether.net>] *On Behalf Of *Wilbur Smith
> *Sent:* Thursday, March 9, 2017 1:37 PM
> *To:* Youssef Bengelloun-Zahr <bengelly@gmail.com>;
> foundry-nsp@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@puck.nether.net
> <foundry-nsp-bounces@puck.nether.net>] *On Behalf Of *Youssef
> Bengelloun-Zahr
> *Sent:* Monday, February 27, 2017 2:26 AM
> *To:* foundry-nsp@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.
>
>