On Tue, Jan 10, 2012 at 10:11:43AM +0200, Saku Ytti wrote:
> On (2012-01-10 07:26 +0100), Daniel Roesen wrote:
>
> > On Mon, Jan 09, 2012 at 04:02:14PM -0600, Richard A Steenbergen wrote:
> > > FWIW they've actually had serious problems interoperating correctly with
> > > copper SFPs from other v
I've always thought vendors that care about this would let you validate the
serial online as genuine(and not stolen etc). This is a minimal effort IMHO.
Jared Mauch
On Jan 10, 2012, at 5:07 AM, Phil Mayers wrote:
> On 01/10/2012 12:35 AM, Richard A Steenbergen wrote:
>
>> In theory the way i
On 01/10/2012 12:35 AM, Richard A Steenbergen wrote:
In theory the way it's supposed to work is that a cryptographically
verifiable code based on the serial number (probably some sort of hash,
but no clue what they actually use) is written to the EEPROM. That way,
Cisco can give the actual manuf
On (2012-01-10 07:26 +0100), Daniel Roesen wrote:
> On Mon, Jan 09, 2012 at 04:02:14PM -0600, Richard A Steenbergen wrote:
> > FWIW they've actually had serious problems interoperating correctly with
> > copper SFPs from other vendors, on EX and MX. There are still unsolved
> > issues with ports
On Mon, Jan 09, 2012 at 04:02:14PM -0600, Richard A Steenbergen wrote:
> FWIW they've actually had serious problems interoperating correctly with
> copper SFPs from other vendors, on EX and MX. There are still unsolved
> issues with ports showing link state up despite nothing being plugged
> in.
On Mon, Jan 09, 2012 at 11:37:03PM +, Phil Mayers wrote:
>
> I am not trying to compare this to vendor locking. They are indeed
> completely different, and I merely cite it as illustration of one other
> position on the spectrum of transceiver permissiveness.
>
> I will grant that denying t
On 01/09/2012 11:05 PM, Richard A Steenbergen wrote:
On Sun, Jan 08, 2012 at 12:11:19PM +, Phil Mayers 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 requir
On Sun, Jan 08, 2012 at 12:11:19PM +, Phil Mayers 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
On Sun, Jan 08, 2012 at 02:27:44PM +1100, Julien Goodwin wrote:
>
> Nobody is asking Juniper to *support* third party optics, they never
> have before. All we want is, that like all other Juniper products to
> date (that I'm aware of) that third party optics work, and have
> feature parity.
Be
On Mon, Jan 09, 2012 at 04:02:14PM -0600, Richard A Steenbergen wrote:
> On Fri, Jan 06, 2012 at 09:34:35PM -0500, Chuck Anderson wrote:
> > Like I said, that is nuts. I will NEVER buy the QFX then as long as
> > this "vendor arrogance" exists. And don't give me this "but we
> > haven't tested it
On Sat, Jan 07, 2012 at 11:45:40AM +, Phil Mayers wrote:
> Oh for the love of...
>
> In terms of practical "what now" ideas, have you tried to source a
> "Juniper compatible" SFP+ i.e. someone has blown the string into the
> EEPROM? Or maybe investigate FlexOptix' flexBox?
FWIW eoptolink's
On Fri, Jan 06, 2012 at 09:34:35PM -0500, Chuck Anderson wrote:
> Like I said, that is nuts. I will NEVER buy the QFX then as long as
> this "vendor arrogance" exists. And don't give me this "but we
> haven't tested it with every possible SFP+ vendor so we can't allow
> you to use any vendor" cra
On Sunday, January 08, 2012 08:11:19 PM Phil Mayers wrote:
> Secondly, I don't see why Juniper need to *force*
> whatever restriction (either the current Juniper-only,
> or some more gentle "certified only") in software. They
> could trivially deny JTAC support for any issue
> involving loss / del
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 t
> 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
On 01/08/2012 03:27 AM, Julien Goodwin wrote:
Nobody is asking Juniper to *support* third party optics, they never
have before. All we want is, that like all other Juniper products to
date (that I'm aware of) that third party optics work, and have feature
parity.
Spot on, couldn't have put it
On 01/08/2012 01:48 AM, OBrien, Will wrote:
I'd make darn sure that Juniper knows that this is an issue for you.
I'm half torn on the optics issue - I can half understand the
argument for certified optics, but I've also been in the position of
being short on 'blessed' optics while having other ve
On Sat, Jan 7, 2012 at 8:48 PM, OBrien, Will wrote:
> I'd make darn sure that Juniper knows that this is an issue for you.
In fact, we've let them know that the competing vendor is getting 60%
more money for a comparable product; but that large price premium is
worth it given the obvious logistic
+1
Nobody wants "support" just don't cripple the platform. "Reasons to use
Juniper over Cisco" - 1 if this stays this way, or becomes the norm.
On Jan 7, 2012 9:28 PM, "Julien Goodwin" wrote:
> On 07/01/12 15:50, Salman Zahid wrote:
> > 2. In terms of 3rd party optics support , we are evalu
On 07/01/12 15:50, Salman Zahid wrote:
> 2. In terms of 3rd party optics support , we are evaluating the support
> for 3rd party optics . Please continue to check the Juniper documentation and
> talk to your account team for roadmap information .
My ire has cooled considerably since reading
I'd make darn sure that Juniper knows that this is an issue for you.
I'm half torn on the optics issue - I can half understand the argument for
certified optics, but I've also been in the position of being short on
'blessed' optics while having other vendors hardware on hand.
With a sfp+ to sfp+
On Sat, 7 Jan 2012, Phil Mayers wrote:
The device must support generic / unbranded transceivers. Any device which
prevents use of, or restricts features based on transceiver vendor will be
immediately disqualified.
I'm very glad to see people doing this in their procurement. I'm also
happy
On 01/06/2012 06:26 PM, Jeff Wheeler wrote:
We just received our first QFX3500s, and contrary to what the Juniper
SE told us, they will not work with non-Juniper optics. Is there some
clever, undocumented means of using third-party optics in these
switches? JTAC says it will "never" be compatib
On 07/01/12 13:34, Chuck Anderson wrote:
> To clarify my original question, does anyone know of any such
> server/storage/NIC/HBA vendors out there that insist you use their DAC
> cables? I want to be sure not to buy those either, because last I
> checked, you can't put SFP+ DAC Vendor A on one en
Like I said, that is nuts. I will NEVER buy the QFX then as long as
this "vendor arrogance" exists. And don't give me this "but we
haven't tested it with every possible SFP+ vendor so we can't allow
you to use any vendor" crap.
What if you have an HP or Dell server, or EMC storage, or whatever,
Hi Chuck,
I have both QFX-3500's as well as a complete Q0Fabric system, I can absolutely
confirm that at this time everything that connects to a QFX node has to be
Juniper, this is true from 1gb (copper and fiber), as well as 10gb, Active and
Passive DAC cables.
If you plug in non-Juniper SFP's
I've found that Juniper EX SFP+ ports work fine with $other_vendor's DAC cables
connected to $other_vendor's equipment (and vice-versa with Juniper DAC cables)
at the same time those SFP+ ports won't work with anyone else's optics (and
likewise for many other vendors). I believe the same occurs
On Fri, Jan 06, 2012 at 01:26:19PM -0500, Jeff Wheeler wrote:
> We just received our first QFX3500s, and contrary to what the Juniper
> SE told us, they will not work with non-Juniper optics. Is there some
> clever, undocumented means of using third-party optics in these
> switches? JTAC says it
Le 6 janv. 2012 à 19:26, Jeff Wheeler a écrit :
> We just received our first QFX3500s, and contrary to what the Juniper
> SE told us, they will not work with non-Juniper optics. Is there some
> clever, undocumented means of using third-party optics in these
> switches? JTAC says it will "never"
29 matches
Mail list logo