Re: [j-nsp] QFX3500 optics lock?
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 showing link state up despite nothing being plugged in. :) Juniper uses Methode Elec. OEM SFPs. Those work fine. Stay away from Finisar units, they have such phantom link problems. JNPR actually claimed that this problem was going to be fixed on 10.4R7 (PR665918, by you). I got such claim in ticket 2011-0725-0041. I've heard elsewhere that it has not been fixed. I don't care any more, sourced enough methode cuSFPs from flexoptix. MX80 experiences this same problem with with even JNPR optics for ISG and SRX at least. It boggles the mind vendor would internally want to use different optics for different vendors, seems losing bet. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 manufacturers a list of SN's and codes equal to the number of units they're purchasing, to prevent the classic counterfeiting problem of the factory in China running during the day for the customer and at night for themselves. That's something I've heard before, but to be frank it's always seemed a bit... highly organised, shall I say?... for the vendors to actually accomplish. Are you convinced that they're actually doing this? If so, I don't suppose you could share the evidence that convinced you? ;o) If nothing else, one wonders how things like the widely-available XYZ Compatible optics (or the flexBox) would work if this validation were taking place. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 EX and MX. There are still unsolved issues with ports showing link state up despite nothing being plugged in. :) Juniper uses Methode Elec. OEM SFPs. Those work fine. Stay away from Finisar units, they have such phantom link problems. JNPR actually claimed that this problem was going to be fixed on 10.4R7 (PR665918, by you). I got such claim in ticket 2011-0725-0041. I've heard elsewhere that it has not been fixed. I don't care any more, sourced enough methode cuSFPs from flexoptix. MX80 experiences this same problem with with even JNPR optics for ISG and SRX at least. It boggles the mind vendor would internally want to use different optics for different vendors, seems losing bet. Not to mention using the same model numbers for MX SFPs and EX SFPs (the order numbers are different) so once you have them installed (or even out of their original packaging), you can't tell which is which, and then having support issues when one works and the other doesn't because you used it in the wrong platform. Been there, done that. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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. 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. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 SFP+'s seem to not set off the NON-JNPR flag in EX without any additional hackery required, though I have no clue at all if they'd work properly in a QFX. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 every possible SFP+ vendor so we can't allow you to use any vendor crap. 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. :) Fine, if it breaks, I get to keep both pieces :-) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 careful what you ask for... We've seen many issues with the support for third party optics, for example we still have ongoing issues with Cisco copper SFPs which show link up despite nothing being plugged in when used in an MX80... It's not as bad as a blatant lock, but if they don't have to support it they don't need to fix it either. :) The better way to say it is, we aren't going to call you and make you fix it if it's just one broken optic doing something bad, but we still expect you to make every reasonable effort to make your product work correctly with other standards compliant components. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 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? Actually, this one I get... They're trying to detect and block a counterfeit product that says Cisco on it, and which as you said, was introduced into the supply chain without your knowledge that it was an inferior fake (and maybe even without your VARs knowledge too). This is COMPLETELY different from artificially disabling a third party's product. Of course, if they weren't so busy trying to do the later there wouldn't be nearly as much demand for people doing the former, but they're still probably justified in blocking the duplicate serial #'s of Cisco products. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 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? Actually, this one I get... They're trying to detect and block a counterfeit product that says Cisco on it, and which as you said, was introduced into the supply chain without your knowledge that it was an inferior fake (and maybe even without your VARs knowledge too). This is I wouldn't want to comment on the VAR. Suffice to say that too good to be true described the situation and pricing well... COMPLETELY different from artificially disabling a third party's product. 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 new optic is understandable. But shutting down an existing link is deeply unhelpful (as well as TOTALLY NON-OBVIOUS to the person inserting the optics). For starters - what if the existing link is a Genuine Cisco(tm) SFP? Then the forged SFP not only doesn't work (fine) but stops a valid SFP from working (not fine). Unlikely I will admit, but not impossible. I will also add that I have no evidence this duplicate checking is limited to transceivers matching CISCO* in the EEPROM; for all I know, it does it for any transceiver... Of course, if they weren't so busy trying to do the later there wouldn't be nearly as much demand for people doing the former, but they're still probably justified in blocking the duplicate serial #'s of Cisco products. If you mean denying the new SFP, then I could understand that. If you mean shutting down the existing SFP then I'm afraid we'll have to agree to disagree. Anyway, this is getting OT for a Juniper list. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 new optic is understandable. But shutting down an existing link is deeply unhelpful (as well as TOTALLY NON-OBVIOUS to the person inserting the optics). For starters - what if the existing link is a Genuine Cisco(tm) SFP? Then the forged SFP not only doesn't work (fine) but stops a valid SFP from working (not fine). Unlikely I will admit, but not impossible. I will also add that I have no evidence this duplicate checking is limited to transceivers matching CISCO* in the EEPROM; for all I know, it does it for any transceiver... 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 manufacturers a list of SN's and codes equal to the number of units they're purchasing, to prevent the classic counterfeiting problem of the factory in China running during the day for the customer and at night for themselves. But even without defeating the hash, they can always just clone the serial number from a known good one... Of course in theory there should never be two identical serial numbers, so when they do show up in the same chassis you should be guaranteed that they're both counterfeit. Of course, I'm sure mistakes do happen from time to time, and you could make the argument that it's bad to affect production customer traffic if the customer didn't know, but there is at least some logic behind it. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 vendors hardware on hand. Couple of points (but long email, sorry - this is a pet peeve issue of mine!). Firstly, I think the phrase certified optics is a misnomer, one that I'm sure Juniper would like to hide behind. It would be a completely different matter if Juniper said something like: We only support optics from the following 3rd party vendors/product lines. Instead, they're saying: We will only allow you to use our optics. ...and then fail to price them competitively. This is an abuse of market power, and like most such abuses, it's bad for everyone except the owners / shareholders of the company doing the abusing. I note that, at current pricing levels, 10G transceivers actually cost more than the per-port cost of the *packet forwarding hardware* for some high-density platforms (which is extraordinary). You could make a convincing argument that over-priced transceivers retard deployment of high-bandwidth networks, and that this adversely affects pricing all up the value chain. 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 / jitter until the customer tries a Juniper or Juniper-approved transceiver. (If the issue didn't go away when I purchased and installed such a transceiver, I would like Juniper to refund my money of course...;o) There are hundreds of things that can go wrong with a box, and the transceiver has relatively little to do with most of them. For them to claim that a major risk to a QFX box is dodgy optics, especially when the vast majority of optics are made in the same few places, and differ only in physical label and EEPROM contents, is either self-deluding or dishonest on Junipers part. If they want people to believe that, they'll need to be a lot more open about the testing they did to prove that uncertified optics cause problems, and that still doesn't get them off the hook. Certified != Juniper. That said, even cisco does this with the unsupported optics command. Indeed, and I don't have much problem with that model. Semi-interesting aside though; we once got stung with a batch of really crappy, forged cisco genuine transceivers. The reason I know they were forged is that we had a large number of duplicate serial numbers. The reason I knew that they were crappy? They were malformed - at least 5% of them wouldn't accept an LC connector due to mis-aligned barrels, and about half the rest had EXTRAORDINARILY low power output. We shouted at the reseller, and got our money back. 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. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 better myself. To lock third party optics out you had to *add* code to JunOS, remember that. Indeed. It's hardly likely to have been accidental oops my finger slipped and I added code to read the EEPROM and disable the port if non-Juniper ;o) Even ignoring common optic types (SR, LR, etc) there's still plenty of reasons to want third party optics, passive C/DWDM is just the start, RAD's [TE][13] SFP modules are another type that Juniper just don't offer. Tunables for DWDM sparing, optics that do G.709 inside the transceiver, 120km optics (if/when they appear in 10G format). The list goes on. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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). Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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
Re: [j-nsp] QFX3500 optics lock?
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 / jitter until the customer tries a Juniper or Juniper-approved transceiver. Juniper need to restrict the large consumer vendor that produces cool i-Devices antics to Junos Space. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 compatible with non-Juniper SFP+. Right now it looks like we will be sending them all back and going with another vendor. Glad I wasted my time doing QA with the sales engineer.. :/ 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? However, I personally would send them back, and disqualify Juniper from future procurements for a period, and ensure they understand why this happened. For what it's worth, our most recent procurements contain the following mandatory requirement text (amongst others): The device must support generic / unbranded transceivers. Any device which prevents use of, or restricts features based on transceiver vendor will be immediately disqualified. ...and: 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 urge you all to include similar text; unless they are made to, vendors will continue to abuse their market power to charge inflated prices for fungible items. I would be very happy to see the EU competition commission intervene here... Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 to see that a majority of the RFPs that I see, mostly BTOP ones, also include some sort of requirement for support of 3rd party optics. Preventing 3rd party optics from working in the QFX immediately disqualifies it from a majority of the new network builds I see and I would never recommend a product to my customers that won't work with 3rd party optics. -- Brandon Ross AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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+ cable, there isn't an excuse for this - It's all copper and it's a friggin network port. Eesh. That said, even cisco does this with the unsupported optics command. On Jan 7, 2012, at 2:58 PM, Brandon Ross wrote: 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 to see that a majority of the RFPs that I see, mostly BTOP ones, also include some sort of requirement for support of 3rd party optics. Preventing 3rd party optics from working in the QFX immediately disqualifies it from a majority of the new network builds I see and I would never recommend a product to my customers that won't work with 3rd party optics. -- Brandon Ross AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 this statement yesterday, so here's an attempt at a sane response. 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. If you're so worried about latency within a Qfabic making Juniper branded (because I'll bet they're not even a special run, let alone special model) optics required on the internal side of a fabric is annoying, but not all that objectionable. There's also nothing wrong with WONTFIXing latency tickets if the path is not 100% Juniper optics, much as other issues with third party optics are handled today. To lock third party optics out you had to *add* code to JunOS, remember that. Even ignoring common optic types (SR, LR, etc) there's still plenty of reasons to want third party optics, passive C/DWDM is just the start, RAD's [TE][13] SFP modules are another type that Juniper just don't offer. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
+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 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 this statement yesterday, so here's an attempt at a sane response. 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. If you're so worried about latency within a Qfabic making Juniper branded (because I'll bet they're not even a special run, let alone special model) optics required on the internal side of a fabric is annoying, but not all that objectionable. There's also nothing wrong with WONTFIXing latency tickets if the path is not 100% Juniper optics, much as other issues with third party optics are handled today. To lock third party optics out you had to *add* code to JunOS, remember that. Even ignoring common optic types (SR, LR, etc) there's still plenty of reasons to want third party optics, passive C/DWDM is just the start, RAD's [TE][13] SFP modules are another type that Juniper just don't offer. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 the obvious logistical issues with stocking vendor-coded optics. Juniper could give me optics for free and it still wouldn't be acceptable. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QFX3500 optics lock?
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 like we will be sending them all back and going with another vendor. Glad I wasted my time doing QA with the sales engineer.. :/ -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 compatible with non-Juniper SFP+. Right now it looks like we will be sending them all back and going with another vendor. Glad I wasted my time doing QA with the sales engineer.. :/ Our SE warned us : they guarantee a latency and jitter so they WON'T support (nor make work) any non Juniper transceiver... Good luck with that, -- Frederic Gabut-Deloraine Network Engineer NEO TELECOMS - AS8218 signature.asc Description: Message signed with OpenPGP using GPGMail ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 will never be compatible with non-Juniper SFP+. Right now it looks like we will be sending them all back and going with another vendor. Glad I wasted my time doing QA with the sales engineer.. :/ That's nuts. What if you have a different vendor at the other end of a Direct Attach Copper SFP+ cable assembly that does the same thing? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 QFX, but not sure about 10G SFP+ ports on SRX. Since DAC cables are technically NOT optics, the statements that you cannot use non-Juniper optics in QFX3500 but that you can use non-Juniper DAC SFP+ cables should both hold true. Curious. I wonder if it's possible for $sinister_vendor to have a means of detecting the make of the far-end device on a DAC cable connection and lock out the port if the local and distal ends are both $sinister_vendor but the DAC cable is from $other_vendor (and maybe already patented!). Paul Zugnoni On Jan 6, 2012, at 14:59 , Chuck Anderson wrote: 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 will never be compatible with non-Juniper SFP+. Right now it looks like we will be sending them all back and going with another vendor. Glad I wasted my time doing QA with the sales engineer.. :/ That's nuts. What if you have a different vendor at the other end of a Direct Attach Copper SFP+ cable assembly that does the same thing? ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 the QFX recognises that they are there and you can read the Digital information from them, however, the SFP will never be recognised and be available for use by the switch. Hope this helps, Jim Glen Chief Engineer CODONiS, Inc. 12201 Tukwila International Blvd. Seattle, WA 98168 On Jan 6, 201216, at 2:59 PM, Chuck Anderson wrote: 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 will never be compatible with non-Juniper SFP+. Right now it looks like we will be sending them all back and going with another vendor. Glad I wasted my time doing QA with the sales engineer.. :/ That's nuts. What if you have a different vendor at the other end of a Direct Attach Copper SFP+ cable assembly that does the same thing? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 that vendor says, You must use HP/Dell/EMC/Intel/whatever DAC cables. Non-HP/Dell/EMC/Intel/whatever DAC cables will not link up. Now you are stuck. Proprietary vendor A won't talk to proprietary vendor B. This defeats the purpose of having standards/MSAs (SFP, Ethernet, TCP/IP, etc.) in the first place. 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 and SFP+ DAC Vendor B on the other end of the same DAC cable assembly. On Fri, Jan 06, 2012 at 04:57:29PM -0800, Jim Glen wrote: 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 the QFX recognises that they are there and you can read the Digital information from them, however, the SFP will never be recognised and be available for use by the switch. Hope this helps, Jim Glen Chief Engineer CODONiS, Inc. 12201 Tukwila International Blvd. Seattle, WA 98168 On Jan 6, 201216, at 2:59 PM, Chuck Anderson wrote: 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 will never be compatible with non-Juniper SFP+. Right now it looks like we will be sending them all back and going with another vendor. Glad I wasted my time doing QA with the sales engineer.. :/ That's nuts. What if you have a different vendor at the other end of a Direct Attach Copper SFP+ cable assembly that does the same thing? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
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 and SFP+ DAC Vendor B on the other end of the same DAC cable assembly. At the very least NetApp used to require use of their DAC cables, with an exception for (IIRC) Brocade cables going to a Brocade switch, I doubt they actually locked it out though. In the early days of UCS Cisco were weird (even for them) about this as well. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QFX3500 optics lock?
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 . QFABRIC has supported 3rd party DACs since its first release 113R1 . Please refer to the following link http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/cable-qfx3500-sfp-plus-direct-attach.html 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 . Thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
