<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">We monitor light levels and FEC values on all links and have thresholds for early-warning and PRe-failure analysis. <div><br></div><div>Short answer is yes we see links lose packets before completely failing and for dozens of reasons that’s still a good thing, but you need to monitor every part of a resilient network. <br><br><div dir="ltr"><div><span style="background-color: rgba(255, 255, 255, 0);">Ms. Lady Benjamin PD Cannon of Glencoe, ASCE<br class="">6x7 Networks & 6x7 Telecom, LLC <br class="">CEO </span></div><div><span style="background-color: rgba(255, 255, 255, 0);">lb@6by7.net<br class="">"The only fully end-to-end encrypted global telecommunications company in the world.”</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br class="">FCC License KJ6FJJ<br class=""></span></div><span style="background-color: rgba(255, 255, 255, 0);"><br></span><div><span style="background-color: rgba(255, 255, 255, 0);">Sent from my iPhone via RFC1149.</span></div></div><div dir="ltr"><br><blockquote type="cite">On Apr 29, 2021, at 2:32 PM, Eric Kuhnke <eric.kuhnke@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>The Junipers on both sides should have discrete SNMP OIDs that respond with a FEC stress value, or FEC error value. See blue highlighted part here about FEC. Depending on what version of JunOS you're running the MIB for it may or may not exist.</div><div><br></div><div><a href="https://kb.juniper.net/InfoCenter/index?page=content&id=KB36074&cat=MX2008&actp=LIST">https://kb.juniper.net/InfoCenter/index?page=content&id=KB36074&cat=MX2008&actp=LIST</a></div><br><div>In other equipment sometimes it's found in a sub-tree of SNMP adjacent to optical DOM values. Once you can acquire and poll that value, set it up as a custom thing to graph and alert upon certain threshold values in your choice of NMS. <br></div><div><br></div><div>Additionally signs of a failing optic may show up in some of the optical DOM MIB items you can poll: <a href="https://mibs.observium.org/mib/JUNIPER-DOM-MIB/">https://mibs.observium.org/mib/JUNIPER-DOM-MIB/</a></div><div><br></div><div>It helps if you have some non-misbehaving similar linecards and optics which can be polled during custom graph/OID configuration, to establish a baseline 'no problem' value, which if exceeded will trigger whatever threshold value you set in your monitoring system. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 29, 2021 at 1:40 PM Baldur Norddahl <<a href="mailto:baldur.norddahl@gmail.com">baldur.norddahl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello<div><br></div><div>We had a 100G link that started to misbehave and caused the customers to notice bad packet loss. The optical values are just fine but we had packet loss and latency. Interface shows FEC errors on one end and carrier transitions on the other end. But otherwise the link would stay up and our monitor system completely failed to warn about the failure. Had to find the bad link by traceroute (mtr) and observe where packet loss started.</div><div><br></div><div><div>The link was between a Juniper MX204 and Juniper ACX5448. Link length 2 meters using 2 km single mode SFP modules.</div><div></div></div><div><br></div><div>What is the best practice to monitor links to avoid this scenarium? What options do we have to do link monitoring? I am investigating BFD but I am unsure if that would have helped the situation.</div><div><br></div><div>Thanks,</div><div><br></div><div>Baldur</div><div><br></div><div><br></div></div>
</blockquote></div>
</div></blockquote></div></body></html>