Can Your Arista Switch Capture User Traffic

This article was originally posted in October of 2012 at 10GbE.net

This falls into the category of “just because you can do something it doesn’t mean you should.” First I welcome comments from the folks at Arista Networks and will update this entry accordingly as I learn anything new.

Next, I’d like to set the stage a bit. Myricom makes a lossless packet capture driver, Sniffer10G, designed to run on our 10GbE network adapters. Recently several people have said that Arista switches have a similar function, and why shouldn’t they just capture and analyze all the user traffic right on the switch. On the surface, this appears a very reasonable question.
Switches have two basic types of data that flow into and through them: user packets & management packets.  User packets are what make up emails and the stuff we see in our browsers, like this blog entry, these are also called data plane traffic.  Management packets, know as control plane traffic, are used to configure networks and tell switches how to route packets, rules to follow, etc…
 
A switch administrator can easily install the program TCPDump on EOS, the operating system that runs on an Arista switch, and quickly capture and analyze these management packets.   This will NOT by default allow them to capture and analyze user traffic.  This can be done though.  Since EOS is Linux based, and Arista permits external programs to be installed on the switch Arista has created a recipe for accessing and capturing user traffic as well. For the adventurous, I’ll attach that link below.
 
It should be noted though that they strongly warn against doing this on a production switch as it can quickly consume the CPU of the switch, which is not a good thing.  In Arista’s example, they are only sampling 1 out of every 16,383 packets (that’s 0.006% of the traffic) and they mention that the impact on the host CPU is significant and warn against doing it on a switch with more than 50Mbps of total traffic.
 
So yes you can do this, but again it is not recommended for a production switch, and frankly, if you’re only looking at 6/1000ths of 1% of the traffic what’s the point? Configure your Arista switch with a spanning port and connect a Myricom or Emulex 10GbE adapter with FastStack Sniffer10G. Then you can look at ALL THE TRAFFIC at 200X the Arista recommended maximum data rate suggested above.
 
One final note, the newest line of Arista Networks switches includes FPGA technology. If the FPGA is properly programmed, a non-trivial effort, then their capture and analysis performance could be substantially improved.
 
Here is the Arista link covering Collection and Analysis:
 

Extreme Ethernet: Where Science Clashes with Artistry and Magic

This article was originally published in September of 2012 on 10GbE.net.

There are three very different technologies which can be employed to pull the bits off 10 or 40Gigabit Extreme Ethernet and deliver them to your application. The difference between them though is the difference between science, art, and magic. Science is when something is completely understood, it can be reduced to a formula and replicated indefinitely. While art is science applied with creativity to produce a wider variety of solutions, but where the replication process is still chaotic. Magic, on the other hand, is a secretive craft approach to science taken to the extreme for the purpose of producing apparently unbelievable results. In Ethernet, these approaches map very nicely to ASICs, processors & FPGAs.

The Application Specific Integrated Circuit (ASIC) is just what its name implies. An enormous collection of circuits etched onto a single chip to do a very specific well-defined task. This is the scientific approach to Extreme Ethernet. Everything known by the design team is reduced to a fixed circuit architecture to produce a black box where one can easily map all the known inputs to very well defined outputs. Now to be fair there are often some additional registers, memory buffers, and circuits included in the design to make final adjust and tweak things after the chip is in production. Once in production, this approach is the least expensive and is in use by Chelsio, SolarFlare, Mellanox, QLogic, Intel & Broadcom.
 
When you look at Extreme Ethernet as a form of artistry we’re talking processor instead of an ASIC. The difference between an ASIC and a processor is the difference between a cook and a chef. Both have access to ovens, appliances and ingredients, but a cook requires a recipe, while a chef can use any collection of fresh ingredients and produce a delightful dish. The difference is that the chef possesses knowledge, confidence and creativity. A chef knows what ingredients compliment each other, and can combine any number of ingredients together on the fly to create a never before seen meal without a recipe. At the core of the processor approach to Extreme Ethernet is the decision making engine which is in effect the chef. Often these processors have many of the same circuits found in the ASIC approach, your ovens, appliances & ingredients, but it is this decision making engine along with vast on chip memory buffers that separate it from ASICs. With a processor approach new recipes can be downloaded into these memory buffers to produce new solutions for ever evolving markets. Although this approach requires a substantially greater design effort, and is more expensive to produce it yields a far more flexible solution. Today only Myricom, and Emulex utilize this approach.
 
Finally, we have magic in the form of Field Programmable Gate Arrays (FPGAs). They combine the performance of a short order cook with the flexibility of a chef. FPGAs offer the speed of an ASIC while enabling the ability to reflow the logical design on the fly to support new solutions or markets. Crafting new designs is non-trivial, some say magical, and requires real skills that are typically in short supply, and are very costly. Furthermore, this flexibility often comes at a steep price. The hardware alone is often ten times that of a processor or ASIC based solution. Today Endace and Napatech are the lead vendors in this approach to the market.
 
So in the extreme ethernet market when you’re selecting a solution you can go ASIC, processor or FPGA. Which is like eating out at the Cheesecake Factory, McCormick & Schmidt’s or the Magic Castle.

GPS Jamming and Spoofing

This article was originally published in August of 2012 on 10GbE.net.atomicclock

Can someone use GPS Jamming or Spoofing to game the markets of the world in such a way that their HFT shop would have a competitive advantage? We weren’t sure so we asked an expert, John Fischer the CTO of Spectracom, and leader in the field of time distribution. John said “Jamming is easy. Spoofing is hard. It can be done, but you have to be smarter than the average bear. It’s like walking on a tightrope across Niagara Falls. It can be done, but not by just anyone. And we protect against jamming with our holdover oscillator.” What brought jamming into the news recently was testimony by Dr. Todd Humphreys on July 18, 2012, before the House Subcommittee on Homeland Security on how insecure the civilian GPS system is, and that it shouldn’t be blindly trusted. Last week we were asked by a reporter about this topic. In preparing an answer we learned a number of things we think should be shared. First, let’s clarify what we mean by GPS jamming and spoofing.

There are two satellite GPS signals that are commonly available: the insecure consumer signal and the highly encrypted military signal. This whole entry will ONLY cover the consumer signal. Jamming actually isn’t that difficult, you just need to know the frequency range of the GPS signal and reproduce one that is substantially stronger than that received from these satellites. Since the rings of GPS satellites circling the earth are in orbits 12,600 miles overhead, a local jammer hidden in someone’s pocket could easily overpower something so distant. A Google search today revealed that for as little as $32 US you can buy a GPS jammer, and the more you spend the better the jammer.

The second concept is Spoofing. Here one transmits a counterfeit signal where the time contained within the data has been artificially altered. Dr. Humphrey’s team at UT Austin with a budget of under $1,000 successfully spoofed a GPS signal sufficiently enough to PWN (take control) a UAV helicopter drone. Dr. Humphreys used this demo to point out that the civilian band of the GPS signal is transmitted in the clear and should not be blindly trusted, and in fact, if you’re intelligent enough you could replace the signal with your own. His team altered the signal sufficiently enough to drive the drone into the dirt. Now note this was a drone using the consumer GPS signal (not the military one).

In HFT most shops use a GPS signal provided by the exchange. They then bring this in and connect it to their own clock. The signal from this clock is then distributed to all their trading systems. The clock here is the key. What Dr. Humphrey’s didn’t address in his testimony (section 4.3 Banking and Finance) is that these clocks add a layer of hardware which has built in checks and balances. In the presence of a lost or jammed GPS signal, these clocks by design go into a free-run mode where their own internally oscillator (often Rubidium based) takes over to provide accurate time. These internal oscillators typically drift less than one microsecond a week.

By design, these clocks have two defenses against spoofing. Both defenses are built on the clock’s own internally reference oscillator. Dr. Humphrey’s implied that these clocks typically drift 1/10 of a microsecond per second, which I’m told is true for a software only based clocking system, this means potentially 60,000 microseconds a week. Contrast this to the internal hardware oscillator in these clocks which drift only 1 microsecond a week, and the problem Dr. Humphrey’s outlines disappear. First, if the GPS signals don’t align, within predefined tolerances, to the internal reference oscillator they are ignored and the clock goes into a free-run mode. This would be a defense against an attempt to dramatically shift time forwards or backward. Second, if the GPS signals were altered very subtly over time I’m told that it is possible that this change might not be detected. The change would have to be made extremely slowly over a long period of time, but it is possible although unlikely. Suppose someone was slowing down GPS time, as these changes are compounded they could eventually exceed a threshold when a periodic check is made that compares them to the internal oscillator and once again the clock would go into a free-run mode. Although if the change were small enough it could continue to slip through.

So the presence of an accurate oscillator in one’s clock, combined with a rigorous internal process for comparing that oscillator to both the inbound GPS signals and periodically double checking over time removes the issue of blindly trusting the insecure consumer GPS system from our market trading systems.

Black Hat USA 2012 – Emulex FastStack Sniffer10G Product Demo Shows 2x Suricata Performance Gain

This article was originally published in July of 2012 at 10GbE.net

At Black Hat USA this week at Caesars Palace in Las Vegas, Emulex & Myricom will be demonstrating Sniffer10G as it greatly improves Suricata performance by a factor of two. Suricata is a high-performance open source application for creating an intrusion prevention (IPS) or intrusion detection system (IDS). Snort is the leader in this space, but Suricata is the popular new application looking to capture early and mass adoption. While Snort was designed as a single threaded application, Suricata was built from the ground up to support multi-core servers. Sniffer10G takes this one step further, leveraging the processor found on Myricom and Emulex NX adapters to provide multiple capture buffers that can then be pinned to specific CPU cores.

This blog entry specifically outlines how to accomplish a 2X performance improvement for Suricata by using to Sniffer10G. First, you will need to purchase a high-performance dual port 10GbE adapter with Sniffer10G: Myricom dual port 10GbE (P/N 10G-PCIE2-8C2-2S+SNF2) or an Emulex NX adapter (P/N OCe12102-DX-SNF2). One of these cards is required to run Sniffer10G which is also required for performance gain. Both adapters can be purchased for $1,000.00.  This price includes Sniffer10G software. 
For the sake of this posting, we will assume you know how to install the server, the network adapter, and the OS. Prior to deployment, and for testing purposes only we will use a single DA cable to connect together both 10GbE ports. Also, make sure a gigabit ethernet port is connected to the independent server so we can download the software and a test suite. 
 
If you’ve not already downloaded Sniffer10G, then contact help@myricom.com and request a userid and password to access this product. Once downloaded issue the following command to install the product:
# rpm -i myri_snf-2.0.6.50271-2831.x86_64.rpm
 
This should put all the interesting stuff in /opt/snf. At this point, you should validate that you have purchased a card with the Sniffer10G license and that it’s ready to go. To do this issue:
 
# /opt/snf/sbin/myri_license
 
and it should return something similar to this: 
 
2 boards found
NIC 0 serial = 423691
License keys:
395e-e403-6a05-1a8f:2:423691:SNF:V2: # SNF, V2
NIC 1 serial = 423691
License keys:
395e-e403-6a05-1a8f:2:423691:SNF:V2: # SNF, V2
 
The reason it says two boards found is that each port is treated as a separate adapter. Next, you should confirm that the Sniffer10G code is running. The command to do this is myri_start_stop, you can use start, stop or restart. 
 
# myri_start_stop restart
Restarting Sniffer10G
Removing myri_snf
Loading myri_snf
 
Next, confirm that the system thinks things are ok by checking dmesg:
 
# dmesg | grep myri_snf
myri_snf INFO: 2 boards found and initialized
myri_snf INFO: eth4: Link0 is UP
myri_snf INFO: eth5: Link0 is UP
 
Now let’s confirm that traffic can pass easily between the ports. Here you’ll need two console windows open to your server, let’s call them Window-A and Window-B. On Window-A run the following command, it will setup your first port to receive traffic forever from the second port:
 
# /opt/snf/bin/tests/snf_simple_recv -p0 -t 1
snf_recv ready to receive
 
On Window-B run this command to generate one billion 60 byte packets on port 1:
 
# /opt/snf/bin/tests/snf_pktgen -p1 -s 60 -n 1000000000
 
Now in Window-A, you should see traffic along the following lines:
 
8650979 pkts (519058740B) in 1.001 secs (8641948 pps), Avg Pkt: 60, BW (Gbps): 4.148
14892539 pkts (893552340B) in 1.001 secs (14876784 pps), Avg Pkt: 60, BW (Gbps): 7.141
14894309 pkts (893658540B) in 1.001 secs (14878894 pps), Avg Pkt: 60, BW (Gbps): 7.142
 
Use Ctrl-C in both windows to stop things and in Window-B you should see:
 
Size Mbps Mpps Efficiency
60 7141.26 14.878 99.98%
 
This confirms that Sniffer10G is setup and working perfectly. Now on to Suricata.
 
Here are the steps to install Suricata, and build in the Sniffer10G libraries, note I’m not showing the output of the commands because it can be extensive:
 
 
# yum install file-devel
 
# tar -xvzf suricata-1.3.tar.gz
 
# mv suricata-1.3 suricata
 
# cd suricata
 
#./configure –with-libpcap-includes=/opt/snf/include/ –with-libpcap-libraries=/opt/snf/lib/ –prefix=/usr –sysconfdir=/etc –localstatedir=/var
 
# make
 
# make install-full
 
# cp classification.config /etc/suricata
 
# cp reference.config /etc/suricata
 
# cp suricata.yaml /etc/suricata
 
At this point we should confirm where Suricata is and if it was in-fact built with Sniffer10G. To do that use the following commands:
 
# which suricata
/usr/local/bin/suricata
# ldd /usr/local/bin/suricata | grep snf
libpcap.so.1 => /opt/snf/lib/libpcap.so.1 (0x00007f4359199000)
libsnf.so.0 => /opt/snf/lib/libsnf.so.0 (0x00007f4358b53000)
 
Now you need to edit your “suricata.yaml” file to make use of Sniffer10G. Suppose you have a dual socket system with eight cores per socket, you can then change your “suricata.yaml” file’s pcap section to look like this:
 
pcap:
– interface: eth4
threads: 16
buffer-size: 512kb
checksum-checks: no
 
We are assuming here that eth4 is your snf0 interface, you’ll need to confirm the actual interface names using “ifconfig”. Now to start Suricata and leverage all 16 cores, each with their own 512KB buffer use this command:
 
# SNF_NUM_RINGS=16 SNF_FLAGS=0x1suricata -c /etc/suricata/suricata.yaml -i eth4 –runmode=workers
 
For now, since the same system is both generating traffic and consuming it you should consider cutting this number back to 8 or 12 cores instead of all 16. During our testing, we typically use two systems connected back to back so we’ve not had to balance generation and consumption on the same system. 
 
This above command will start Suricata up, but the problem is where do you get traffic from. If you use Window-A for starting Suricata and Window-B for generating traffic then in Window-B we should first download some reasonable traffic. To do this use the following command from your home directory:
 
 
# mv 54 example.com-3.pcap
 
Then once suricata is running to generate test traffic you can use:
 
# /opt/snf/bin/tests/snf_replay -v -p0 -R 0.18 -i 2500 example.com-3.pcap
Thread 0> Packets: 5122500
Thread 0> Bytes: 1660497500
Thread 0> Rate: 0.27 Mpps
Thread 0> Throughput: 0.695 Gbps in 19.122 secs
 
Attached are three command output files:
 
 
and the two Suricata configuration files that were used for our testing:
 
 
These prove out the 2X performance improvement mentioned in the opening paragraph. It is possible to see gains well in excess of 2X, but those require additional tuning and tweaking of the suricata.yaml file beyond what was discussed above.

Low Latency is Just the Ante

This article was originally published in May 2012 at 10GbE.net

For the past few years, all you needed was a low latency network adapter to win business in High-Frequency Trading (HFT).  Now that’s just the Ante. Today most shops have a much greater appreciation for the role that NIC latency plays in their HFT infrastructure. They are also now aware of the other key requirements driving network adapter selection. One of the most obvious today is out of the box integration. How quickly & easily can the low latency drivers be installed and engaged with your existing production code? Does their low latency driver also provide a Java interface? Do they have low latency drivers for Windows? There are a number of far more technical requirements involving multicast groups, polling models, etc…, but this is not the place to be giving away any secrets. 

Today only three low latency NICs have anted up to deliver sub four-microsecond performance for the HFT market: Myricom, Solarflare & Mellanox. Solarflare and Myricom dominate the market because both were early to market with a transparent acceleration mode which enabled customers to quickly install the low latency driver and engage existing production code with little or no modification. Furthermore, both support Java. In January Mellanox introduced VMA 6, which requires their latest ConnectX-3 adapters, that now supports a transparent acceleration mode. This one feature has kept Mellanox at the table.
 
So what’s next? Solarflare’s CTO implies in his May blog post that the “world just got smaller” and says “one more down” then refers people to a link about the Emulex/Myricom partnership. Here he’s intimating that the partnership will remove Myricom from relevance in the HFT market. Nothing could be further from the truth, this partnership validates Myricom’s model and provides them with a substantial channel & manufacturing partner that is enabling them to compete even more efficiently, and aggressively moving forward. What Solarflare fails to understand is that Myricom has developed market specific software like DBL for HFTs for several other markets: Sniffer10G for network analytics, VideoPump for video content providers, and MX for high performance clusters. Furthermore Myricom has tuned their generic 10GbE driver to offer 50% better throughput than Solflare’s and double Chelsio’s. In the HFT space Myricom is the only vendor to offer a transparent mode low latency option for Windows. In addition Myricom has a roadmap of HFT features, built on customer requirements, that will dramatically improve DBL performance and functionality over the next 12 months. So is your NIC vendor focused on making the low latency driver you run your business on today even better, or have they gone down the FPGA rabbit hole?

CNA – Converged Network Agora

This article was originally posted in May of 2012 at 10GbE.net

With every generation of Ethernet, there is always a new crop of agile startups who race to silicon and deliver a variety of new ASICs for network adapters and switches.  As the market matures competition thins the herd and after several years only the best products remain.  This Darwinian process is what the market does best, and the process was in full swing in January of 2009 when I authored a post “Thinning the 10GbE Herd.”  In this article, I mentioned NetXen, Neterion, Tehuti, ServerEngines, NetEffect, & Teak Technologies all of which are gone three years later. 

Today three startups who have remained focused on high-performance 10GbE network interface card (NIC) silicon & software for the past six years still remain.  These companies are Chelsio, Myricom & Solarflare.  Don’t get me wrong, large public companies like Intel, Broadcom, Emulex & Qlogic ship far more 10GbE ports, but these are all well established public companies focused on the larger 10GbE market, and with significant silicon production capabilities.  To be complete there is also a cache of very niche players like Napatech, Endace, and HotLava but these firms leverage FPGAs or in HotLava’s case Intel silicon.
 
As someone who’s been selling 10GbE for the past seven years full time, it finally appears that 2012 will be the year of convergence.  Chelsio & Solarflare are both venture capital backed and by most estimates are reaching the end of their funding.  Myricom is privately held, and has been running on revenue for 18 years, also last week they announced a partnership with Emulex.
 
In the recent past, Intel gobbled up NetEffect & Folcrum so their appetite for 10GbE appears pretty well satiated.  Early on Broadcom acquired Siliquent, and they appear content.  So the game of musical chairs has started.  Emulex & Qlogic have made various plays, but they both still appear hungry, which leaves only two seats.  We have three remaining players (Chelsio, Myricom & Solarflare).  Later this year the music will stop, none may remain, and the convergence will be complete.  Two may win, and likely one will lose, the question is which?
 
Then in 2013, we get to start it all over again with 40GbE!

Optical Lock Down

This article was originally published in May of 2011 at 10GbE.net.

Today for the umpteenth time I had to explain to someone that if you go optical to connect your server to your switch with 10GbE it could easily cost you twice as much.  There is a secret at the end of this entry that MIGHT allow you to save some big time cash if you have enough muscle, but you have to read to the end of this entry.

For cable runs of seven meters or less you should always use Direct Attach (DA  otherwise known as Twinax) cable if possible as it could easily save enough to basically connect the second server for free! Here are some actual numbers from earlier today.
 
First, some basic end user costs assuming a five-meter run, note these are rounded a little bit to keep the math simple:
 
10GbE Network adapters, roughly $400/port
10GbE Switches, roughly $500/port
10GbE SR SFP+ Optics from switch vendor $800/port
10GbE SR SFP+ Optics from NIC vendor $200/port
10GbE SR Optical 5M cable $80/ea
10GbE Direct Attach 5M cable roughly $140/ea
 
Now let’s build a solution between the server and the switch using optics:
 
10GbE Network adapter $400
10GbE SR Optic from NIC vendor $200
10GbE SR Optical 5M cable $80
10GbE SR Optic from  Switch vendor $800
10GbE Switch port $500
Total $1,980 to connect a single server
 
Direct Attach (Twinax) Option:
 
10GbE Network adapter $400
10GbE Direct Attach 5M cable roughly $140/ea
10GbE Switch port $500
Total $1,040 to connect a single server
 
Let’s look more closely at the market dynamics going on here.  First, only a handful of companies make 80% of the 10GbE Short Range (SR) optics that everyone uses today.  These companies are typical: JDSU, Finisar, Agilent, etc…  None of the switch companies or NIC companies make their own optics, we all source them from several of the above companies, and a few others, all of whom rebrand them for us and burn our company name and part number into what is essentially flash memory within the optic.
 
Here’s where it gets interesting.  Myricom, the company I work for, sells it’s SR SFP+ optics online via CDW’s website for $185.  Here are some of the more expensive SR SFP+ optics listed on CDW’s site:
 
HP Procurve: $1,498
Avaya: $1,350
Enterasys: $1,210
Cisco: $1,100
Juniper: $1,082
Brocade: $1,022
QLogic: $930
IBM: $920
 
Now remember under the covers we’re all sourcing these optics from the same competitive pool, so why the price spread?
 
First, remember that we each buy our optics with our manufacturer name and part numbers already burned into them by the optics makers mentioned above.  Now here’s where it gets interesting the switch makers during switch initialization query the optic and if it does not return a valid company name and part number then it locks the optic out and reports the port as offline.  
 
A Cisco switch requires a Cisco optic.  If you were to use a Myricom optic it would see that the optic was made by “Myricom” with a part number “10G-SFP-SR” and it would lock that port out because it has an incompatible optic.  Never mind that a valid Cisco optic and the “failed” Myricom optics may very well have been made by JDSU on the same assembly line, perhaps even on the same day. 
 
Network adapter vendors, like Myricom, are optic agnostic. You can shove in an Arista, Cisco, HP, or Gnodal, we won’t care.  We provide optics to offer a complete solution for our customers.  Finally, we are not “in the optic business” so we pick them up, mark them up fairly, then offer them for sale.  I can assure you we’re not buying them at the same discount that a Cisco or Juniper might be getting, yet our price is clearly so much more reasonable.  
 
Now here’s the secret I promised.  Most switch vendors have a patch for the switch operating system so that it will ignore the optic check and allow you to use anybody’s optics.  If you have the buying power and the cojones, then insist that they provide the patch as a condition of buying their switch.  It will save you big time.  You can then take those savings, and buy a few more Myricom 10GbE adapters.

Dualies Aren’t Just for Trucks

This article was originally published in April of 2009 at 10GbE.net

One would think that after 30 years our industry would have developed a NIC naming convention for “dual-port.” Does a dual-port NIC mean your OS sees one or two interfaces? Do dual-port NICs mean that one port is active and the other is for fail-over? Can a dual-port run traffic through both port simultaneously? It all depends on who you talk to, and the product they’re selling.

With 10GbE we’ve seen three main approaches for building dual-port NICs:
 
Active/Active: this is what most people expect, a single OS interface with a driver that sprays traffic fairly evenly across both network ports and if one port fails the other picks up the slack until it can handle no more:
  • Chelsio’s N320E for $790 is an example of this type of card.
  • Intel’s AF DA card for $799 appears to be another example of this class of card.
Dual-NIC: two OS interfaces are presented to the OS and both interfaces run independently. This typically affords the best performance and the most flexibility:
  • Myricom’s 10G-PCIE2-8B2-2S+E for $995 appears to be the only example of this approach. Myricom utilizes two unique 10GbE controllers on the same PCI Express Gen2 NIC and a PCI Express bridge chip to break the slot into two unique NIC devices.
Active/Passive or Active/Fail-over: a single OS interface with a driver that monitors connectivity on the active port and if the connection fails the driver migrates traffic rapidly over to the second port:
  • Myricom’s 10G-PCIE-8B-2S+E for $795 is an example of this type of card. The fail over time is under 10 microseconds.
  • Chelsio’s B320E Bypass adapter for $3,483 is similar but it can detect an OS/BIOS/System failure and make a hard switch over to the second port.
Do the above categories cover it, or do we need more lingo? When looking for a dual-port NIC, what features do you require, and what do you expect? Please let us know.
 
P.S. As I brought this page back online I left off the links as most no longer apply, but from a historical perspective it is interesting to see how things have progressed.

Thinning the 10GbE Herd

This article was originally published in January of 2009 at 10GbE.net.

Thinning the herd.

In 2007 over one million 10GbE network ports were purchased. Many of those were for a switch to switch interconnects but some were to connect servers to networks via 10GbE. Natural selection is now taking effect in the 10GbE NIC market as the big dogs, Intel & Broadcom, start thrashing around in an effort to secure market share as 10GbE matures. Both want to dominate the 10GbE LAN on Motherboard (LoM) market. In the NIC market, four companies likely supply over 80% of the 10GbE NICs purchased and they are Chelsio, Intel, Myricom, and Neterion. The remaining 20% of NIC sales fall to companies like Broadcom, SMC, NetXen, ServerEngines, Tehuti, AdvancedIO, Endace, Napatech, etc… One should be wondering why Broadcom is in the second group, it’s because Broadcom’s focus is on selling 10GbE silicon to OEMs like IBM and HP for LoM projects positioning their silicon on high-end server mother boards and not retailing NIC cards. 

Officially the first documented victim is NetEffect, the leader in iWarp (Infiniband for 10GbE) NICs. NetEffect rose from the ashes of a failed Infiniband company, Banderacom, earlier this decade to apply their silicon development skills and Infiniband algorithms to the more stable Ethernet market as a new feature called iWarp. NetEffect in-fact led the iWarp charge, it was the self-proclaimed leader in low-latency iWarp 10GbE NICs. In August NetEffect filed for reorganization in US Bankruptcy Court. With the failure of NetEffect the market has cast its vote and drove a stake through the heart of iWarp, hopefully terminating this feature.
Rumors have been swirling around Teak Technologies, a maker of 10GbE NICs and a switch, for some time. It appears that Teak has not weathered the storm and has since faded away, their domain name is no longer resolving to an IP address. The domain was never transferred from the founder, and the founder announced this spring on Linkedin that he had moved on some time ago. Is it conclusive evidence, no, but would you buy technology from a tech company whose URL won’t resolve to a server?
It is a tough economic climate for start-up NIC companies, particularly those in the bottom 20% as they have likely never had a quarter in the black. Now is a challenging time to be out there seeking another round of capital from ones VCs. Several have been without an injection of new funding for over two years and lack the sales volume required to sustain their own existence much beyond year end. As such we’ve directly questioned one firm to see if they are alive, and another that is widely rumored in the industry to be in trouble, but their marketing departments are still bailing.