RE: A case against vendor-locking optical modules
Let talk about the 800 pound gorilla in the room and the #1 reason to hate vendor locked optics. Some vendors (yes, Cisco I'm looking at you) want to charge ridiculously high prices for optic that are identical to generic optics other than the vendor lock. Maybe a better tactic would be to have the vendor explain to you why the vendor lock is necessary. You are after all the customer and don't owe them any explanations. Steven Naslund Chicago IL -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jérôme Nicolle Sent: Monday, November 17, 2014 12:12 PM To: nanog@nanog.org Subject: A case against vendor-locking optical modules Hello, I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. My points are : - I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line - I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed. - I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts. Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up. What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14
Re: A case against vendor-locking optical modules
Vendor Lock's... this is nothing new, it has been in practice since the beginning of the IT / Computer Industry... We have seen this with Cables (old old days, Vax/PDP 11/ IBM Mainframes, well into the PC cycle), Floppy Drives, Hard Drivers etc etc etc... To the best of my knowledge, none of this was ever won by argument with the vendor...This always changed with time... When more and more people started deploying generic / non oem items, the vendors were forced to either turn a blind eye or forced to reconsider... The big carrot or stick, the vendors always held with the Customers / Consumers, was the warranty and or support. If history has any advice to offer, it would be, if you are not dependent on warranty or support issues from the Vendor, then go forward, do what you please, .. :) Regards. Faisal Imtiaz - Original Message - From: Steve Naslund snasl...@medline.com To: nanog@nanog.org Sent: Monday, November 17, 2014 1:20:09 PM Subject: RE: A case against vendor-locking optical modules Let talk about the 800 pound gorilla in the room and the #1 reason to hate vendor locked optics. Some vendors (yes, Cisco I'm looking at you) want to charge ridiculously high prices for optic that are identical to generic optics other than the vendor lock. Maybe a better tactic would be to have the vendor explain to you why the vendor lock is necessary. You are after all the customer and don't owe them any explanations. Steven Naslund Chicago IL -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jérôme Nicolle Sent: Monday, November 17, 2014 12:12 PM To: nanog@nanog.org Subject: A case against vendor-locking optical modules Hello, I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. My points are : - I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line - I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed. - I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts. Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up. What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14
Re: A case against vendor-locking optical modules
On Mon, Nov 17, 2014 at 1:11 PM, Jérôme Nicolle jer...@ceriz.fr wrote: I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. Hi Jérôme, Change can't to won't, because you find it inconvenient and insulting to work around artificial and costly problems created by your vendor. If you can't use their equipment then they haven't lost any business but if you _won't_ then they have. Then schedule a call with the CEO, not your salesman. The CEO probably doesn't understand it, probably caused it, and probably won't understand it when you're done talking. He will understand customer ditching us over some subordinate's stupid behavior, and will assign someone more technical with instructions to redress the error. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: A case against vendor-locking optical modules
Le 17/11/2014 19:28, Faisal Imtiaz a écrit : If history has any advice to offer, it would be, if you are not dependent on warranty or support issues from the Vendor, then go forward, do what you please, .. Well, I could go on and re-code the optics, at least by simply cloning a few OEMs. But there is still the spare items issue. No datacenter remote-hands will accept any lyability in operating a recoder (wich, when not operated properly, can easily fry the module). So I have to keep multiple spares per module type, each beeing recoded and labelled for different vendors. Le 17/11/2014 19:54, William Herrin a écrit : Change can't to won't, because you find it inconvenient and insulting to work around artificial and costly problems created by your vendor. If you can't use their equipment then they haven't lost any business but if you _won't_ then they have. Let's talk about the £800 gorilla in the room then : it's not an issue for a $20 LX SFP, it may be doable for a $120 LR SFP+, it's certainly not an option for an ER-DWDM SFP+ 8-40 waves set ($800 each). You're right about how inconvinient and insulting such restrictions feel, but my main concern is about costs, efficiency and logistics. Having to stock more spare optics, one per vendor, has its cost. Having to cheat the restriction by recoding the optics, also has costs in terms of time, tools and complexity. At the end of the day, everyone loses. Because it's absurd and induce more costs and complexity, I _can't_ fall into such trap. Because it's insulting and bordeline moronic to begin with, I certainly _won't_. Now, about discussing with a CEO, I'm not really sure it could be reached. Salesmen on the other hand have their own interest in both selling OEM modules to the corporate market, and unlocked equipments to the SP/telco market, to whom they won't sell anything otherwise. Is it unrealistic to hope for enough salesmen pressure on the corporate ladder to make such moronic attitude be reversed in the short term ? Best regards, -- Jérôme Nicolle +33 6 19 31 27 14
RE: A case against vendor-locking optical modules
You say lock in, they say loyalty Tell them loyalty is two ways, and you need them to help you remain a loyal customer. To start with, a fantastic CLA. Make sure it includes 15 minute new optics delivery in case of failure (since you can't keep spares on-site as they are too expensive.) Technicians available without wait time to help you focus/finish/program them. Not instant response to take a ticket, followed by a call within 4 hours, but instant response by a knowledgeable tech who finishes the call by filling out a ticket. Etc. If they want vendor focused thinking on your part with concomitant committing of resources ($$), they need customer focused thinking on theirs. They want your loyalty, awesome... let them know what it will take. Remind them of how much money you will spend this year if they can get your lock in. I'm just singing here. --p -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jérôme Nicolle Sent: Monday, November 17, 2014 12:12 PM To: nanog@nanog.org Subject: [EXTERNAL]A case against vendor-locking optical modules Hello, I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. My points are : - I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line - I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed. - I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts. Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up. What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14
Re: A case against vendor-locking optical modules
On Mon, Nov 17, 2014 at 2:12 PM, Jérôme Nicolle jer...@ceriz.fr wrote: Le 17/11/2014 19:54, William Herrin a écrit : Change can't to won't, because you find it inconvenient and insulting to work around artificial and costly problems created by your vendor. If you can't use their equipment then they haven't lost any business but if you _won't_ then they have. Let's talk about the £800 gorilla in the room then : it's not an issue for a $20 LX SFP, it may be doable for a $120 LR SFP+, it's certainly not an option for an ER-DWDM SFP+ 8-40 waves set ($800 each). You're right about how inconvinient and insulting such restrictions feel, but my main concern is about costs, efficiency and logistics. Having to stock more spare optics, one per vendor, has its cost. Having to cheat the restriction by recoding the optics, also has costs in terms of time, tools and complexity. At the end of the day, everyone loses. Because it's absurd and induce more costs and complexity, I _can't_ fall into such trap. Because it's insulting and bordeline moronic to begin with, I certainly _won't_. Have they had a bad quarter because they carelessly induced indirect costs which priced them out of the market? This is something their CEO would like to know about. Now, about discussing with a CEO, I'm not really sure it could be reached. Salesmen on the other hand have their own interest in both selling OEM modules to the corporate market, and unlocked equipments to the SP/telco market, to whom they won't sell anything otherwise. You'd be surprised how reachable CEOs are, but if you have any trouble making an appointment, call the CFO instead. CFO's are lonely. Almost nobody ever calls them. The CFO will take the call from a customer/investor, and unlike your salesman the CFO has the CEO's ear. And if he's had a bad quarter, the CFO is even more in tune with the idea that an indirect cost (which makes them no direct money) caused you not to buy. Is it unrealistic to hope for enough salesmen pressure on the corporate ladder to make such moronic attitude be reversed in the short term ? Your salesman is not a corporate warrior. He spends his time working the lowest hanging fruit he can find. Unless you have a *lot* of money to spend, that isn't a customer who requires a change to corporate policy. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: A case against vendor-locking optical modules
I've asked the same question and got the answer that there is a REAL BIG chip manufacture that was having huge system issue and told the vendor that they were going to rip out all the manufactures routing / switching equipment if they didn't get it fixed. after the manufacture send engineering staff on site they found that the problem was not the routers or switches but the SFP's that the Chip manufacture had purchased. After replacing the SFP's they had no problems. So if you were the router manufacture you might also put in the locks... Just say'n I hate it also, but I also really like a stable network. I also know that there are some OEM's for even Cisco that I have used in the past. Just my two cents. Scott On Mon, Nov 17, 2014 at 10:11 AM, Jérôme Nicolle jer...@ceriz.fr wrote: Hello, I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. My points are : - I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line - I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed. - I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts. Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up. What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14
Re: A case against vendor-locking optical modules
At 02:49 PM 17/11/2014, Scott Voll wrote: I've asked the same question and got the answer that there is a REAL BIG chip manufacture that was having huge system issue and told the vendor that they were going to rip out all the manufactures routing / switching equipment if they didn't get it fixed. after the manufacture send engineering staff on site they found that the problem was not the routers or switches but the SFP's that the Chip manufacture had purchased. After replacing the SFP's they had no problems. I've heard that explanation a number of times in various forms. I suspect it was an explanation crafted to counter the argument. Regardless, it should have been simple enough to rule out the optics with proper diagnostics and swapping out of suspect units. The real reason of course is margin http://www.lightreading.com/optical/optical-components/ciscos-secret-franchise/d/d-id/631651 --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409
RE: A case against vendor-locking optical modules
That is their most popular argument. However this is no different from putting a NIC card. RAM, or hard drives in a server platform. For that matter, do you blame the network vendor if you have a faulty optical cable? In your example, can you be sure that the SFP was the issue? You can't be because someone obviously did not follow the standards for the SFP interface, was it the network gear or the SFP itself. Just because brand X does not work with switch Y does not make it brand Xs fault. Obviously if there is a flaw in the NIC, the server guys should not get blamed. Just as there are standards for USB, PCI, SATA, and other, there are standards for SFP and SFP+ interfaces. If the optic vendor is not compliant, that's their problem and if your network gear does not accept any optic that complies with the standard that is the network gear's fault. Consider how you would feel if HP servers only accepted HP hard drives or would not accept an Intel NIC, would you accept that? Steven Naslund Chicago IL I've asked the same question and got the answer that there is a REAL BIG chip manufacture that was having huge system issue and told the vendor that they were going to rip out all the manufactures routing / switching equipment if they didn't get it fixed. after the manufacture send engineering staff on site they found that the problem was not the routers or switches but the SFP's that the Chip manufacture had purchased. After replacing the SFP's they had no problems. So if you were the router manufacture you might also put in the locks... Just say'n I hate it also, but I also really like a stable network. I also know that there are some OEM's for even Cisco that I have used in the past. Just my two cents. Scott
Re: A case against vendor-locking optical modules
there's a reason why cisco introduced service unsupported-transceiver, which still remains an undocumented command. i have arista gear as well. kinda wish they had a similar undocumented command.
RE: Route Science
As someone that used the routescience/avaya product for 6-7 years and then also demoed the IRP I can tell you that the IRP has a lot of similar functionality that the routescience/avaya CNA product had. The nice thing about the Noction product (the demo at least?) is that you aren't locked into an ancient IBM xServer with a 32 bit kernel like you were with the Avaya product. You can install it on your own machines, so in theory it should be possible to scale it. Scaling was the only reason we decommissioned our CNA, otherwise we'd still be using it. -Drew -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Greg Grabowski Sent: Thursday, November 13, 2014 11:41 PM To: nanog@nanog.org Subject: Route Science Does anyone still have a Route Science box running out there? Our enterprise still has a box running and working. Just curious..;-)
Re: A case against vendor-locking optical modules
On Mon, 17 Nov 2014, Jérôme Nicolle wrote: What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? In the case of some vendors (yes, you again, Cisco), the shift has been in the wrong direction. Some vendors treat optics as just a tool to do a job, and price accordingly. Those vendors tend to have fairly relaxed policies re: working with non-$vendor optics, as well. Other vendors treat optics as a cash cow^H^H^H^H^H^H^H^Hprofit center, and also price accordingly. Those vendors tend to scream bloody murder if a non-$vendor optic is encountered. Beyond that, I'd say you've covered all of the logical reasons why vendor lock-in is a bad idea, but as others have mentioned in this thread, those attitudes tend to change at a ridiculously slow pace, and only when forced by market conditions. jms
Re: A case against vendor-locking optical modules
On Mon, 17 Nov 2014, Jérôme Nicolle wrote: Is it unrealistic to hope for enough salesmen pressure on the corporate ladder to make such moronic attitude be reversed in the short term ? No salesperson is likely to do that for you. They know only to well that eliminating vendor lock-in means they will lose sales on artificially costly optics from $vendor to a lower-cost rival. Less sales = less commission for the affected sales person. jms
Re: A case against vendor-locking optical modules
On Mon, 17 Nov 2014 15:34:50 -0500, Justin M. Streiner said: No salesperson is likely to do that for you. They know only to well that eliminating vendor lock-in means they will lose sales on artificially costly optics from $vendor to a lower-cost rival. Less sales = less commission for the affected sales person. I suspect that losing the commission on a few $6digit chassis sales is worse than losing the commission on a $3digit optic? pgpoJWSoRFCzW.pgp Description: PGP signature
Re: A case against vendor-locking optical modules
On Mon, 17 Nov 2014, valdis.kletni...@vt.edu wrote: On Mon, 17 Nov 2014 15:34:50 -0500, Justin M. Streiner said: No salesperson is likely to do that for you. They know only to well that eliminating vendor lock-in means they will lose sales on artificially costly optics from $vendor to a lower-cost rival. Less sales = less commission for the affected sales person. I suspect that losing the commission on a few $6digit chassis sales is worse than losing the commission on a $3digit optic? That turns into a forest trees problem. Many salescritters don't think about the larger picture, or the responsible business units don't care about what affects other business units. Also, in the 10G-and-up world, most of those optics are a lot more than $3digits. jms
DNS Lookup - Filter localhost
This past weekend we started receiving bursts of lookups on our DNS server for localhost. We blocked our subscriber abusing this lookup (most assuredly malware and not intentional) but curious what safeguards you put in place for DOS attacks on your DNS servers. 1. As an ISP do you see a problem with blocking localhost on your DNS servers? (we don't see any validity to these requests but checking with you to see if we've overlooked something). 2. Do you have an actual localhost zone that issues 127.0.0.1? 3. Do you block 512 Bytes DNS requests? 4. Do you block non-UDP DNS requests or rate-limit requests? 5. Anything else you block/filter on your DNS servers? -=JGR
Re: A case against vendor-locking optical modules
On 17/11/2014 18:11, Jérôme Nicolle wrote: What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? there have been documented cases in the past where transceivers have had serious problems working on kit, where those problems have ranged from the transceivers simply not working correctly to the network devices crashing and rebooting. The kit vendor gets the blame in all situations, even though it's not always their fault. Ultimately, transceivers are devices which need device drivers to work properly. I haven't seen any driver code for handling them, but if you take a look at any other device driver, you'll probably notice that a good chunk of the code is spend dealing with quirks and device-specific weirdness. From talking to vendors, I understand that the situation is much the same with optical transceivers. So there are some technical reasons for being cautious about this, particular at the early stage of transceiver development. Having said that, most vendors use transceiver lock-out for strictly commercial purposes and will refuse to enable full functionality on third party kit as a matter of policy. Bear it in mind that for every customer who doesn't accept this, the vendor will make 10x as much cash with this policy by applying it to enterprise and public sector. Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? No, but I've never had the opportunity to wave $100m at a vendor either. These days I buy blank transceivers from a reputable third party vendor, and recode them in-house as appropriate for whatever kit we need to use them in. This works well for me, but other people will have different policies which work well for them. Nick
RE: A case against vendor-locking optical modules
On Mon, 17 Nov 2014, Naslund, Steve wrote: Let talk about the 800 pound gorilla in the room and the #1 reason to hate vendor locked optics. Some vendors (yes, Cisco I'm looking at you) want to charge ridiculously high prices for optic that are identical to generic optics other than the vendor lock. Maybe a better tactic would be to have the vendor explain to you why the vendor lock is necessary. You are after all the customer and don't owe them any explanations. The Packetpushers recently discussed this issue: http://packetpushers.net/ps-show-35-oem-sfp-qsfp-modules-work/ Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263.
Re: DNS Lookup - Filter localhost
On 11/17/2014 01:11 PM, Radke, Justin wrote: This past weekend we started receiving bursts of lookups on our DNS server for localhost. We blocked our subscriber abusing this lookup (most assuredly malware and not intentional) but curious what safeguards you put in place for DOS attacks on your DNS servers. 1. As an ISP do you see a problem with blocking localhost on your DNS servers? (we don't see any validity to these requests but checking with you to see if we've overlooked something). Not really 2. Do you have an actual localhost zone that issues 127.0.0.1? Yes 3. Do you block 512 Bytes DNS requests? No. 4. Do you block non-UDP DNS requests or rate-limit requests? Yes 5. Anything else you block/filter on your DNS servers? block/limit any queries block/limit root NS queries block anycast/broadcast source address packets block fragmented packets
Re: A case against vendor-locking optical modules
On Mon, Nov 17, 2014 at 1:09 PM, ryanL ryan.lan...@gmail.com wrote: there's a reason why cisco introduced service unsupported-transceiver, which still remains an undocumented command. i have arista gear as well. kinda wish they had a similar undocumented command. Arista does have it (at least in older codes, no idea if it still works). http://serverfault.com/questions/281534/what-is-the-command-to-enable-3rd-party-sfp-transceivers-on-arista-switch One note: I did not have to reboot the switch for it to work. That took care of *most* 3rd-party optics, but I seem to recall it didn't cover 100%. Ken
Re: A case against vendor-locking optical modules
Le 17/11/2014 21:09, ryanL a écrit : kinda wish they had a similar undocumented command. Well, there is a command, and you can automate it's application. See https://gist.github.com/agh/932bbd1f74d312573925 . Can't tell if DOM is supported on 3rd party. -- Jérôme Nicolle +33 6 19 31 27 14
Re: A case against vendor-locking optical modules
This is an interesting thread, but the actual winning strategy was only tangentially mentioned. Q: How do you get a vendor to change? A: Everyone stop buying that vendor's gear. It's a simple business decision. If the profit dollars of the people who stick around with locked optics are greater than the profit dollars of everyone buying without, guess what a vendor will do? (I'm ignoring a ton of second-order effects, such as having enough kit in production to be considered ubiquitous, since most companies can't think that far ahead.) You like Arista for price, density, etc.? Then factor in the cost (OpEx CapEx) of vendor-specific optics and see if they still make sense. Don't just look at the per-port cost of the blade. See, it's a simple business decision for you too. Besides, what's wrong with using something (as Nick mentioned) like FlexOptics programmable optics? Haven't tried it in Arista, but other kit works fine. -- TTFN, patrick On Nov 17, 2014, at 16:19 , Nick Hilliard n...@foobar.org wrote: On 17/11/2014 18:11, Jérôme Nicolle wrote: What are other arguments against vendor lock-in ? Is there any argument FOR such locks (please spare me the support issues, if you can't read specs and SNMP, you shouldn't even try networking) ? there have been documented cases in the past where transceivers have had serious problems working on kit, where those problems have ranged from the transceivers simply not working correctly to the network devices crashing and rebooting. The kit vendor gets the blame in all situations, even though it's not always their fault. Ultimately, transceivers are devices which need device drivers to work properly. I haven't seen any driver code for handling them, but if you take a look at any other device driver, you'll probably notice that a good chunk of the code is spend dealing with quirks and device-specific weirdness. From talking to vendors, I understand that the situation is much the same with optical transceivers. So there are some technical reasons for being cautious about this, particular at the early stage of transceiver development. Having said that, most vendors use transceiver lock-out for strictly commercial purposes and will refuse to enable full functionality on third party kit as a matter of policy. Bear it in mind that for every customer who doesn't accept this, the vendor will make 10x as much cash with this policy by applying it to enterprise and public sector. Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? No, but I've never had the opportunity to wave $100m at a vendor either. These days I buy blank transceivers from a reputable third party vendor, and recode them in-house as appropriate for whatever kit we need to use them in. This works well for me, but other people will have different policies which work well for them. Nick
Re: DNS Lookup - Filter localhost
4. Do you block non-UDP DNS requests or rate-limit requests? Yes Why? RFC5966 DNS Transport over TCP - Implementation Requirements You make it very hard for DNSSEC 5. Anything else you block/filter on your DNS servers? block fragmented packets Why? You then block EDNS0, which DNSSEC uses. (UDP packets up to 4096 bytes, then TCP) /Anders
Re: A case against vendor-locking optical modules
Hello Patrick, Le 18/11/2014 00:17, Patrick W. Gilmore a écrit : You like Arista for price, density, etc.? Then factor in the cost (OpEx CapEx) of vendor-specific optics and see if they still make sense. Don't just look at the per-port cost of the blade. See, it's a simple business decision for you too. You got my point : I do care about per-port cost, but the actual cost is a composite of : - kit price - licences - optics - spare optics - power per port over expected run time - collocation space Besides, what's wrong with using something (as Nick mentioned) like FlexOptics programmable optics? Haven't tried it in Arista, but other kit works fine. Programmable optics are fine, but then you'd have to keep your programming gear available and train your techniciens on it, or keep pre-coded spares for every locked manufacturers. It's probably fine in a pure DC environment with few locations and only one SFP+ type, but it's rapidly a total mess when you have to manage 40 channels for 3 module types over dozens of locations AND the added manufacturer specific pain-in-the-ass. -- Jérôme Nicolle +33 6 19 31 27 14
Re: A case against vendor-locking optical modules
Our experience using that command has been mixed enough to be unreliable for production. Problems include error disabled interfaces refusing to come back online and the command not surviving a power cycle. Use with caution. Steven Naslund Chicago IL On Nov 17, 2014, at 2:11 PM, ryanL ryan.lan...@gmail.com wrote: there's a reason why cisco introduced service unsupported-transceiver, which still remains an undocumented command. i have arista gear as well. kinda wish they had a similar undocumented command.
Re: DNS Lookup - Filter localhost
3. Do you block 512 Bytes DNS requests? How many 512 byte DNS requests are people seeing? Perhaps the requester meant 512 byte DNS responses? Blocking 512 byte responses would be ... unfortunate. 4. Do you block non-UDP DNS requests or rate-limit requests? Yes I presume (hope) the yes applies rate limiting? Blocking non-UDP DNS is a bad idea. As RFC 5966 states: ... it should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) may result in resolution failure and/or application-level timeouts. block anycast/broadcast source address packets How do you know if a source address is an anycast address? block fragmented packets Why would you want to block fragmented packets? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail
