Re: [c-nsp] SFP DOM SNMP Polling?
A typical SFP spec sheet leads me to conclude that reading optic values repeatedly is expected. For example: https://www.finisar.com/sites/default/files/resources/AN_2030_DDMI_for_SFP_Rev_E2.pdf (I selected Finisar as they have complete spec sheets publicly available.) I question the vendor statement... Tim:>
Re: [c-nsp] SFP DOM SNMP Polling?
I'm no expert in EEPROMs but recall awhile back we had an optical vendor (transport-side, not router-side) that did do frequent writes (maybe it was for performance info) to EEPROM and burned them out that way after a couple of years. Maybe your vendor is saying they don't support reporting this way because they would do it via writing to the EEPROM which is bad for it. Not saying whether they could do it some different way that would make it supportable, but who knows. May be some fundamental shortcoming/limitation of their design (or their OEM's design). $0.02 Tony On Tue, Nov 22, 2016 at 12:11 PM, Michael Loftis <mlof...@wgops.com> wrote: > On Tue, Nov 22, 2016 at 6:32 AM, Tim Durack <tdur...@gmail.com> wrote: > > I have a vendor that does not support SFP DOM SNMP polling. They state > this > > is due to EEPROM read life cycle. Constant reads will damage the SFP. > > Complete and total garbage. Reading from EEPROM and Flash both DO NOT > WEAR. It is the erase+write cycle that wears them. Further typical > EEPROM life cycle is ~1M erase/write cycles. If you wrote it every > minute you could conceivably wear it out in a couple years...but thats > flat out not how it works. The EEPROM, if any, is not going to be > used for statistics datamaybe fail counts of some kind, lifetime > (hours) maybe...that sort of thing. > > > > > > We SNMP poll SFP DOM from Cisco equipment without issue. > > > > Not heard this one before. Trying to see if there is some validity to the > > statement. Thoughts? > > > > Tim:> > > ___ > > cisco-nsp mailing list cisco-...@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler >
Re: [c-nsp] SFP DOM SNMP Polling?
Michael, I totally missed the fact that reads don’t stress EEPROMs! Excellent point, and makes the vendor’s claim totally bogus. Probably just one employees claim, but the vendor should step up and fix the real problem. -mel > On Nov 22, 2016, at 9:11 AM, Michael Loftis <mlof...@wgops.com> wrote: > > On Tue, Nov 22, 2016 at 6:32 AM, Tim Durack <tdur...@gmail.com> wrote: >> I have a vendor that does not support SFP DOM SNMP polling. They state this >> is due to EEPROM read life cycle. Constant reads will damage the SFP. > > Complete and total garbage. Reading from EEPROM and Flash both DO NOT > WEAR. It is the erase+write cycle that wears them. Further typical > EEPROM life cycle is ~1M erase/write cycles. If you wrote it every > minute you could conceivably wear it out in a couple years...but thats > flat out not how it works. The EEPROM, if any, is not going to be > used for statistics datamaybe fail counts of some kind, lifetime > (hours) maybe...that sort of thing. > > >> >> We SNMP poll SFP DOM from Cisco equipment without issue. >> >> Not heard this one before. Trying to see if there is some validity to the >> statement. Thoughts? >> >> Tim:> >> ___ >> cisco-nsp mailing list cisco-...@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler
Re: [c-nsp] SFP DOM SNMP Polling?
On Tue, Nov 22, 2016 at 6:32 AM, Tim Durack <tdur...@gmail.com> wrote: > I have a vendor that does not support SFP DOM SNMP polling. They state this > is due to EEPROM read life cycle. Constant reads will damage the SFP. Complete and total garbage. Reading from EEPROM and Flash both DO NOT WEAR. It is the erase+write cycle that wears them. Further typical EEPROM life cycle is ~1M erase/write cycles. If you wrote it every minute you could conceivably wear it out in a couple years...but thats flat out not how it works. The EEPROM, if any, is not going to be used for statistics datamaybe fail counts of some kind, lifetime (hours) maybe...that sort of thing. > > We SNMP poll SFP DOM from Cisco equipment without issue. > > Not heard this one before. Trying to see if there is some validity to the > statement. Thoughts? > > Tim:> > ___ > cisco-nsp mailing list cisco-...@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler
Re: [c-nsp] SFP DOM SNMP Polling?
> On Nov 22, 2016, at 9:32 AM, Tim Durack <tdur...@gmail.com> wrote: > > I have a vendor that does not support SFP DOM SNMP polling. They state this > is due to EEPROM read life cycle. Constant reads will damage the SFP. > > We SNMP poll SFP DOM from Cisco equipment without issue. > > Not heard this one before. Trying to see if there is some validity to the > statement. Thoughts? It’s entirely possible some people implement it poorly and the read cycles count. With 100k cycles somewhat typical for those bytes, it’s certainly something that could be seen if polling every 5 minutes in 347 days, but I think that’s a datapoint that most SFPs are warranted for much longer than 347 days. As the DDM data is stored not at 0x50 but at 0x51/0x52 in optics this is more likely done with a micro controller presenting the ram backed data via reads to/from those specific bytes. - Jared
Re: SFP DOM SNMP Polling?
cisco-...@puck.nether.net on the CC is a cross-post to another list, resulting in bounces if you're not subscribed to both lists. So I am removing cisco-...@puck.nether.net as NANOG does not permit cross-site posting. -mel beckman > On Nov 22, 2016, at 6:57 AM, Mel Beckman <m...@beckman.org> wrote: > > Seems bogus to me. I can't imagine why realtime stats would be in flash > rather than RAM. In fact, that can't be the case: they have to update the > stats many more times per second than SNMP would poll them. > > -mel beckman > >> On Nov 22, 2016, at 6:33 AM, Tim Durack <tdur...@gmail.com> wrote: >> >> I have a vendor that does not support SFP DOM SNMP polling. They state this >> is due to EEPROM read life cycle. Constant reads will damage the SFP. >> >> We SNMP poll SFP DOM from Cisco equipment without issue. >> >> Not heard this one before. Trying to see if there is some validity to the >> statement. Thoughts? >> >> Tim:>
Re: SFP DOM SNMP Polling?
Seems bogus to me. I can't imagine why realtime stats would be in flash rather than RAM. In fact, that can't be the case: they have to update the stats many more times per second than SNMP would poll them. -mel beckman > On Nov 22, 2016, at 6:33 AM, Tim Durack <tdur...@gmail.com> wrote: > > I have a vendor that does not support SFP DOM SNMP polling. They state this > is due to EEPROM read life cycle. Constant reads will damage the SFP. > > We SNMP poll SFP DOM from Cisco equipment without issue. > > Not heard this one before. Trying to see if there is some validity to the > statement. Thoughts? > > Tim:>
SFP DOM SNMP Polling?
I have a vendor that does not support SFP DOM SNMP polling. They state this is due to EEPROM read life cycle. Constant reads will damage the SFP. We SNMP poll SFP DOM from Cisco equipment without issue. Not heard this one before. Trying to see if there is some validity to the statement. Thoughts? Tim:>
