|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org From: Jared Mauch <jared@puck.nether.net> In-Reply-To: <CAE_ug16i-K4fa3_oFgTSA3JuqkD5-RCk4-UCKPBkMWCRcLJgdA@mail.gmail.com> Date: Tue, 22 Nov 2016 10:35:47 -0500 To: Tim Durack <tdurack@gmail.com> Cc: "nanog@nanog.org" <nanog@nanog.org>, "cisco-nsp@puck.nether.net" <cisco-nsp@puck.nether.net> Errors-To: nanog-bounces@nanog.org > On Nov 22, 2016, at 9:32 AM, Tim Durack <tdurack@gmail.com> wrote: >=20 > 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. >=20 > We SNMP poll SFP DOM from Cisco equipment without issue. >=20 > Not heard this one before. Trying to see if there is some validity to = the > statement. Thoughts? It=E2=80=99s entirely possible some people implement it poorly and the = read cycles count. With 100k cycles somewhat typical for those bytes, = it=E2=80=99s certainly something that could be seen if polling every 5 = minutes in 347 days, but I think that=E2=80=99s 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=
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |