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
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 hav
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 th
On Mon, Nov 17, 2014 at 1:11 PM, Jérôme Nicolle 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 aro
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.
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.)
On Mon, Nov 17, 2014 at 2:12 PM, Jérôme Nicolle 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 t
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 sta
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.
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
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.
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
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 re
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 th
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
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 low
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
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 tra
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
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
On Mon, Nov 17, 2014 at 1:09 PM, ryanL 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 code
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
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 opt
>> 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 D
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 decis
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" w
>> 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) t
27 matches
Mail list logo
