[c-nsp] Possible causes for fiber link flap?

[Tom Storey]

Even if you have no free ports, are you able to perhaps swap configuration
on two ports that you do have and see if the problem follows the port swap,
or remains on the same physical port?

Would require a little downtime for two ports/services, but should go a
long way to helping you narrow it down.


On 10 October 2013 19:49, Peter Rathlev <peter at rathlev.dk> wrote:

> "Good news everybody!" as professor Farnsworth would put it. :-)
>
> On Thu, 2013-10-10 at 18:28 +0200, Peter Rathlev wrote:
> > We have now introduced a switch between RTR-A and ODF 1 to rule out
> > the physical interface on RTR-A. This was necessary since we had no
> > free interfaces in RTR-A at the moment. It looks very much like the
> > problems are on the 3 Km run and we have asked the splice people to
> > invesitigate.
>
> It turned out the problem is located on RTR-A; after introducing the
> switch we only see the problem between the and RTR-A. The "switch" was
> configured with basic ISIS so we could see the adjacency flaps.
>
> So it turns out it's probably a defect port. We tried swapping the SFP+
> (and everything else) several times. Diagnostics show no problems,
> though we can only run the module based non-disruptive and the
> port-based disruptive at this time.
>
> Would anyone know of a way to actually be certain it's the port? I'm
> guessing RMA would only be allowed if we can somehow give our partner
> soemthing to work with.
>
> If we can't find the actual cause and can't RMA it's no big problem.
> We're currently migrating services away from this box to a Sup2T/6904
> next to it instead and will have the faulty device fully "decommisioned"
> in a months time.
>
> --
> Peter
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>