On 01/08/2012 12:22 PM, sth...@nethelp.no wrote:
However - crappy though they were, imagine my irritation when, even with
"service unsupported-transceiver", a duplicate SFP serial number caused
err-disable on BOTH ports, and requires BOTH transceivers to be removed.
It's not obvious to me that this is a reasonable response; the 1st
transceiver was in, and forwarding packets. Why disable it? What
possible "value" does that add?
So even the Cisco model is a bit more restrictive than first
appearances. It's only "some" unsupported transceivers.
I believe I've also seen the problem that switches which *can* read
DOM values (e.g. 3560, ME3400) won't do this for non-cisco branded
SFPs (e.g. when you need to use "service unsupported-transceiver")
even when the SFPs themselves support this (and will happily supply
optical signal levels when inserted for instance into a Juniper MX
router).
Ugh, I'd forgotten about that. What was their crappy claim?
"We once saw an SFP give crazy DOM numbers, and the customer really
hassled TAC, so we decided to disable DOM on all non-Cisco SFPs just in
case, even though they all come from the same factory."
DOM in Cisco has always been a bit of a pain though (6748-SFP linecards,
GRR HULK SMASH).
That's why we took the time to specifically add the 2nd clause to our ITT:
"""
The device must support DOM/DDM, specifically including TX and RX light
levels. Any device which does not report DOM/DDM on generic transceivers
will be immediately disqualified.
"""
I am determined that the vendors are going to start getting the message
on this.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
