<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">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),
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Wilbur<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><a name="_MailEndCompose"><o:p> </o:p></a></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<p class="MsoNormal"><b>From:</b> foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net]
<b>On Behalf Of </b>Youssef Bengelloun-Zahr<br>
<b>Sent:</b> Monday, February 27, 2017 2:26 AM<br>
<b>To:</b> foundry-nsp@puck.nether.net<br>
<b>Subject:</b> [f-nsp] Basic SNMP MIBs missing<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Dear Community,<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Just wanted to share a basic / silly / simple experience I have gone through with our favorite $VENDOR.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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.<o:p></o:p></p>
</div>
<p class="MsoNormal">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 :<br>
<br>
PRODRFE104332: regarding VDX implementation<br>
PRODRFE104333: regarding FCX implementation<br>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">It has also made its' way on Observium's facebook page :
<a href="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=">
https://fr-fr.facebook.com/observium/</a><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I hope this feedback will inspire you.<o:p></o:p></p>
</div>
<p class="MsoNormal">Best regards.<o:p></o:p></p>
</div>
</div>
</body>
</html>