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 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
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 vendors,
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 crap.
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 stock
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 with
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 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 not
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
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 the
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
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
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 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
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 / delay /
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
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
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
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
+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 jgood...@studio442.com.au wrote:
On 07/01/12 15:50, Salman Zahid wrote:
2. In terms of 3rd party optics
On Sat, Jan 7, 2012 at 8:48 PM, OBrien, Will obri...@missouri.edu 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
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 compatible with non-Juniper
SFP+. Right now it looks
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 be
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
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
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
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,
and
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 end
There are two points I would like to make .
1. 3rd party DACs / Twinax cables are supported on QFX3500 standalone
switch as well as QFX3000 QFabric system. The release that supports 3rd party
DACs in QFX3500 are 11.3R3 and 11.R4 and future releases will also support
3rd party DACs .
29 matches
Mail list logo
