Wired Ethernet

SDN Use Case: Network Service Deployment

webadmin@intel.com — Mon, 03 Jun 2013 16:44:37 GMT

It can be argued that there’s never been a time when innovation was needed more in data center networks.

The increased reliance on information served up from cloud or enterprise data centers has made it vital to bring new security, performance management, privacy, traffic segregation, service-level agreement and revenue generation applications to the network.

Software-defined networking (SDN) and the Intel® Open Network Platform (ONP) help to open the network to this innovation, which brings us to the last in a series of blog posts about SDN use cases. This one focuses on the way this new network paradigm helps to simplify network application / service deployment.

SDN’s primary innovation is that it separates a network’s control plane from its data plane in order to centralize packet processing in a software controller. That makes it easier to deploy network-wide policies or services because the controller has a comprehensive perspective on data flows, including congestion information, QoS, security etcetera.

Logically, the SDN controller sits above the infrastructure layer, but below an application layer with standardized APIs that allow easy integration of business applications.

Thus, applications that used to require standalone hardware and could only see the traffic passing through them, can now be run on a server and can manage an entire network using information available from the controller.

It's the disaggregation of the network into these logical layers that makes this possible. Intel has taken that concept one step further with its Open Network Platform announcement, which opens up key elements at each layer so that any OEM can leverage this infrastructure in the development of an SDN application. Take a look at www.intel.com/onp to get more information about ONP.

Applications bring added user features to a network, but also impact the manageability and performance of the network. SDN lays the foundation for companies like Intel to open up the network for this innovation.

Interop 2013: In Las Vegas, SDN is Not the Center of the Universe

webadmin@intel.com — Mon, 03 Jun 2013 16:13:07 GMT

In recent months, I’ve been to several events where software-defined networking has been the main topic of discussion. Now that I think about it, all of those events have been in the Silicon Valley, the epicenter of SDN.

Recently, I left that bubble to go to Interop in Las Vegas - and I’m finding that SDN is a big deal but it’s not the only thing going on in networking.

Of course, I talked about SDN because I’m focused that way. But the overall show was about all of the topics that networking managers are concerned with like application intelligence, staffing, cloud vendor selection and how to kill Spanning Tree. In fact, my recent search of the Interop site for the acronym SDN turned up only 19 references.

Why is this important? While there is a huge amount of fire behind SDN in certain circles, the market at large has only a passing acquaintance with the technology. I felt that Interop was a great opportunity for me to educate the wider audience on the benefits of the technology.

I took advantage of that opportunity by giving an overview of SDN technology and why it’s important and then discussing the Intel solution in a bit more detail. This includes top-of-rack switch reference design called the Open Network Platform, the software elements and open APIs we have for OEMs dubbed Open Network Software and finally the Intel Ethernet Switch FM6000 series, the low-latency 10G/40G switch IC that is at the heart of the entire solution.

With this solution, we want to unleash the power of SDN for data center networking. One key step is education and that’s why the presentation at Interop was important.

Update from IDF Beijing: The Value of SDN With 1.3B Potential Users

webadmin@intel.com — Tue, 23 Apr 2013 18:48:20 GMT

The Intel® Development Forum in Beijing took place two weeks ago and the interest in my two SDN-related presentations was very high.

My poster chat drew about 40 or so people who stopped by in groups of 6-8 to hear the high-level overview to the Intel SDN story. The attendance more than doubled for my conference session, where I went a bit deeper into Intel’s new data center and telecom network transformation initiative – giving a preview of the three product announcements made at the Open Networking Summit.

One challenge that is unique to China is scaling new web services for a potential market of 1.3 billion people – almost four times that of the U.S. There were a lot of questions on this topic from top service providers, which I took to indicate that scaling is very important.

The other difference I noticed is that with less of a legacy network infrastructure than in the U.S., Chinese network managers are very open to trying new things to get the scalability and performance they need to deliver great service levels.

One key element of my presentation was a deep dive into why new networking platforms, like ONP introduced at ONS, are so necessary to advance the state of the art of SDN, and to providing ease of scaling in these high performance data centers.

As the server virtualization trend expanded into network virtualization, building high-performance, low-latency networks became much more complex for enterprises and data center operators. New IP protocols like TRILL helped, but maintaining server/network coherency became very labor intensive.

To network managers dealing with this challenge, the SDN promise of separating the network control plan into a central network controller architecture was an immediate solution to a nagging problem. And, first-generation networking products delivered on this promise by layering SDN onto existing switches.

But the promise of SDN is much bigger than that; it’s nothing short of opening networks to a wave of innovation around new software functionality along with additional network cost-per-bit reductions. That’s the total story that ONP delivers on.

The potential of SDN for network innovation mirrors the transition from proprietary mini computer to the PC, which spawned countless innovations thanks to its combination of standard processors and operating systems and value-added applications.

In the network version of this story, enterprises evolve from vertically integrated networking platforms that are closed and slow to innovate, to a more open system with standardized switch silicon that has an open API to the control plane (or control planes for specialized applications). These control planes then communicate through another API with apps running on a virtual server.

This means that a network that had to be architected around special appliances to do packet inspection or provide security can now have those applications running on a high-performance server. The global controller will know what packets need to be processed by that application and will direct them to the application before forwarding them to their destination.

This architecture breaks down many of the barriers to entry in this market. For new players, all they need are their software skills to develop their application. They can sell it into any network that supports the open API – regardless of the manufacturer. On the other side of the coin, an existing software company can use standard hardware to easily develop its own complete solution, speeding time to market.

For every company that needs to scale quickly and keep network costs and complexity low – especially in fast growing economies like China – this is really good news.

ONS Recap: “Changing the Way We Think And Act”

webadmin@intel.com — Fri, 19 Apr 2013 01:34:59 GMT

“An inflection point is an event that changes the way we think and act.”

With this quote from Andy Grove in her keynote speech, Rose Schooler, VP of Intel Architecture Group and GM of Intel's Communications and Storage Infrastructure Group, launched the next phase of Intel’s SDN-based data center and telecom network transformation initiative at the Open Networking Summit this week.

The speech capped a great show for me and for the Intel Communications and Storage Infrastructure Group. Our goal going into the event was to help the industry see how to get the full value out of the open networking paradigm shift.

In just under an hour, Rose accomplished that by providing an overview of our datacenter and telecom network strategies, introduced three new products and let partner VMWare and customer Verizon demonstrate how they are using products from Intel.

Here’s a summary of the key products that were launched at the show (you can read more in our press release):

Intel® Open Network Platform Switch Reference Design: You’ve read about “Seacliff Trail” in this blog before. What’s new is a tight integration with Wind River Open Network Software and a customizable software stack using Wind River Linux. Seacliff Trail is now the ideal reference design for OEMs, offering a combination of customizable software and fast, low latency merchant silicon for next-generation SDN data center networking systems.

Intel® Data Plane Development Kit Accelerated Open vSwitch: With this project, Intel wants to help Open vSwitch developers speed up performance of small packets. The bulk of the packets in virtual machine networking applications are 64 Kbytes, and with the accelerated Open vSwitch we’re able to boost small-packet port-to-port performance by 10 times and accelerate virtual machine-to-virtual machine performance by five times.

Intel® Open Network Platform Server Reference Design: This innovative virtual network server reference design called “Sunrise Trail” will allow OEMs to create virtual appliances on standard Intel-architecture servers. The reference design combines the DPDK Open vSwitch, support for SDN and NFV standards along with the Intel® Xeon® processor, Intel 82599 Ethernet Controller and Intel Communications Chipset 89xx series. More to come on this new reference design as the first alpha units are due later this year.

Rose closed her speech with another Andy Grove maxim about inflection points – that they reflect a change in customer’s values and preferences.

As you can see from these significant new products, Intel is moving fast to be in a good position to address these customer value and preference changes.

Intel’s SDN Vision on Display at Open Networking Summit 2013

webadmin@intel.com — Tue, 16 Apr 2013 17:52:26 GMT

Last year Intel® participated in its first demonstration of software-defined networking (SDN) at the Open Network Summit. This year we’re coming back to the show with an expanded SDN product strategy and a new Open Networking Platform that will open up the entire SDN value chain for data centers.

The show opened yesterday in the Santa Clara Convention Center with a full day of tutorials and then an evening reception amongst the exhibits. The program starts today and runs through Wednesday.

Last year, we said that the SDN revolution “starts at the switch.” This year, we’re bringing together the other elements of an SDN solution that will enable customers to dramatically boost the fabric performance in virtualized data center environments.

Starting on Monday, I’ll be staffing the booth at the show to demonstrate our SDN solution. In addition, our Seacliff Trail 48-port 10GE top-of-rack switch will be in a multivendor demonstration of NEC’s Programmable Flow Controller.

On Wednesday, Rose Schooler, Vice President of the Intel Architecture Group and General Manager of the Communications and Storage Infrastructure Group, will make a keynote presentation that will cover key aspects of our Open Network Platform. She will announce some new components of the platform and talk about the customer need it meets.

If you are not going to the show, but would like to hear Rose speak, you can watch the live webcast of her presentation.

The world of open networking moves fast. The progress we’ve shown since ONS 2012 shows that Intel is keeping pace. Check back for more blog updates later this week.

SDN Use Cases: Virtual Network Appliances

webadmin@intel.com — Wed, 10 Apr 2013 16:09:45 GMT

We started our blog series on software defined networking (SDN) use cases by looking at how SDN might enable network virtualization (http://communities.intel.com/community/wired/blog/2013/03/01/sdn-use-cases-network-virtualization). We continue on a somewhat similar application by looking at SDN and virtual network appliances.

Many networks utilize specialized appliances, such as firewalls, load balancers, WAN accelerators and others, to provide specialized network packet processing and functionality.

Many of these are now being turned into virtual appliances. The term “virtual appliance” was coined to describe a self-contained virtual machine powered by an operating system that had a pre-configured application on top.

In the enterprise data center, one of the challenges of the virtual network appliance is that it often needs to be in the data path – either before the router, in the case of a firewall, or before a server, in the case of a load balancer.

SDN replaces IP routing functionality on each switch with a network controller that can see all data and resources on the network and directs data flows. With this global view, it can redirect data packets to virtual network appliances directly. In essence, it creates a data path for each data flow in order to direct it to the right virtual appliance.

This is also important in cloud applications where multi-tenant virtual servers may need dramatically different resources and where virtual data paths complicate the sharing of virtual appliances.

The network flow flexibility that SDN brings to datacenter and cloud networks makes virtual network appliances an even more viable and cost-effective way to deliver the network processing needed for secure and high-performance networks.

Preview of My SDN Poster Chat at IDF Beijing

webadmin@intel.com — Tue, 02 Apr 2013 18:23:55 GMT

Later this week, I’ll board a 13-hour flight from Los Angeles to Beijing to take part in the Intel® Developer Forum on April 10-11.

If you are going to the event and are interested in what Intel is doing in the data center and connected systems market, I recommend that you first go hear our General Manager Diane Bryant give her keynote talk about the future of our business, on April 10 between 9 and 11:00am.

Then, you can hear me talk at two times during the conference: at my Poster Chat on April 10 at 2pm, and at my April 11 session presentation at 3:45pm (where I will pair up with Shashi Gowda of our Wind River Systems division).

In both talks, I’m going to be sharing how Intel sees the future of the software defined network (SDN) market and what product plans are in place to help OEMs participating in this market.

In this blog post, I’ll touch on my poster chat, and next week, I’ll provide an overview of the session presentation. If you’ve never been to a poster chat, it is exactly what the words say – I have created a large poster and I describe it and answer any questions that come up.

My poster for IDF Beijing covers the following topics:

The evolution from traditional IP networks to SDN networks and the advantages that come from that.
A description of the Intel Ethernet Switch FM6000 functionality. Here I will talk about how we get low latency and discuss our Seacliff Trail 48-port 10GB/40GB Ethernet switch reference design.
From there, I’ll go into a discussion of our software architecture that starts with APIs to open the FM6000 to SDN controllers, and contains the operating system and other software components necessary to fully implement SDN switching.
Then, I want to dig deeply into our FlexPipe frame forwarding architecture, which is built with advanced frame header processing that makes it flexible for an evolving standard like SDN.

It’s a lot to talk about in an hour, but I’m looking forward to providing a high-level overview that I can then explore further in my workshop. More on that next week.

Increase Your BMC Network Performance by Over 800%!

webadmin@intel.com — Fri, 29 Mar 2013 16:54:42 GMT

Increase Your BMC Network Performance by Over 800%!

Your friendly neighborhood manageability nerd here announcing my latest whitepaper.

The NC-SI (Network Controller Sideband Interface) is a connection between a Network Controller and a BMC. This DMTF defined interface is designed to provide 100Mbps full duplex connectivity to a BMC.

Over a year ago I began researching why I was having customers were complaining to me that the NC-SI performance under some circumstances was horrible, in most reports only a few megabits per second.

After literally hundreds of tests and countless hours of research and tweaking of different things, I began to understand what the problem was and how to go about providing a solution.
Figure 1 Network Performance Streaming to BMC

What I found was that the NC-SI interface worked exactly as it was supposed to, however the BMC itself needs to take into account that it is using NC-SI and that NC-SI does not have as much buffer space as the BMC itself has.

I tested with not only Intel Network Controllers, but also another well-known manufacturer of Network Controllers. The results were pretty much identical, very poor performance until I modified the BMC to be a bit more intelligent.

Making changes detailed in the whitepaper, average performance when streaming data to the BMC went from less than 8Mbps to nearly 65Mbps. The performance would be even better, however a BMC is not a super-powerful processor and it can’t yet handle 100MBps data rates.

All my research, conclusions and actual sample data is included within the whitepaper. I also provided an overview of what NC-SI is for the uninitiated.

I hope you find it of use. If you do please comment so we know if folks actually read these docs .

The paper is available here: https://www-ssl.intel.com/content/www/us/en/ethernet-controllers/nc-si-overview-and-performance-notes.html

IPMI Ping Utility – Give that BMC a bit of a workout

webadmin@intel.com — Thu, 14 Mar 2013 00:46:06 GMT

I work extensively with BMC’s, to be more precise those that design and write the firmware that runs on BMC’s. This runs the range from initial code to make sure all the various interfaces (such as NC-SI or SMBus) are working properly to discussing advanced platform manageability features.

A few years ago I whipped up a little utility to exercise the BMC’s Ethernet interface. This simple utility sends some basic IPMI/RMCP commands to an IP address, waits for a response and sends another command once a response is received. It does so repeatedly, as a little stress test for the sideband interface to the BMC. It has proved useful over the years for those beginning implementation on BMC’s.

I recently updated this utility as part of some work I’ve been doing for a paper I’m finishing up on NC-SI performance (will post soon on that one). The utility and its brute-force code and Microsoft Windows binary is available up on sourceforge: http://sourceforge.net/projects/ipmiping

It’s pretty simple; give it an IP address and optional options for what kind of packet you want to send to the BMC.

One of the updates I recently made was to display the network bandwidth being used. What I discovered was that the standard request/response pattern used in IPMI, uses a maximum of about 0.6Mbps even at full speed.

Anyhow – just in case somebody was interested, I thought I’d post a message letting folks know that this simple utility exists and I hope it is found to be of use.

Thanx,

Patrick

How to Configure SR-IOV VFs in a VMware ESXi*

webadmin@intel.com — Thu, 07 Mar 2013 16:25:41 GMT

It has been nearly 3 years since I wrote my first blog, and it was on setting up SR-IOV in Red Hat
Xen (for reference, that blog is here).

It has been a longand interesting road for SR-IOV since then, I’ve written several documents and
made a few videos on the topic, available here).

One of the lastmajor virtualization Operating Systems has now added support for SR-IOV, VMware
now provides the capability to utilize SR-IOV.

My talented co-workers have written a very nice step-by-step guide (with lots and lots
of pictures). This very nice paper is located here.

We hope you enjoy the latest addition to our growing collection of documents for virtualization
technologies available within Intel® Ethernet Devices.

Enjoy!

- Patrick

At the Forefront of the Latest Networking Disruption

webadmin@intel.com — Wed, 06 Mar 2013 21:15:14 GMT

The success of Arista Networks* is proof that there’s always room for an innovative start up – even in markets dominated by large players that execute well. But great innovation often requires market disruption to gain a foothold with customers.

In a recent interview with Network World, Arista President and CEO Jayshree Ullal talked about the market trends that helped Arista take off. She said:

“Arista saw three disruptions in the market: a hardware disruption; a software disruption; and a customer buying disruption, which in my mind is the most important thing.”

Two of these trends are interesting to me because we’ve been participating in them. First, the hardware disruption she mentions is the rise of merchant network switch silicon that has performance and features comparable to ASIC switches.

Our Intel^® Ethernet switch family is pioneering these merchant switch devices. We not only provide throughput that is equal to or better than that of an ASIC, but our layer 3 latency is the industry’s lowest as well.

With a switch chip that provided competitive throughput and features to compete, Arista didn’t need to spend the large amount of resources on an ASIC development program, unlike some of its large competitors.

Instead, they were able to differentiate themselves with software – the second disruption on Jayshree’s list. Arista developed its own operating system – the Extensible Operating System – leveraging Linux as the foundation.

Our Intel Ethernet switch FM6000 series silicon contributes to software innovation through its programmable FlexPipe™ frame processing technology. FlexPipe’s configurable microcode allows switch manufacturers to update features or support new standards even on systems that are already in the field.

In order for our customers to evaluate the advanced FM6000 series features, we also provide our Seacliff Trail reference design, which has a Crystal Forest-based control plane processor on board. Crystal Forest can be used as a standard control plane processor, or as a SDN controller host, or even to experiment with Intel’s Data Plane Development Kit (DPDK™).

It’s been great to have played a role in the market changes that have given Arista – and other companies – a chance to launch and to flourish. Viva la Disruption!

SDN Use Cases: Network Virtualization

webadmin@intel.com — Fri, 01 Mar 2013 17:59:43 GMT

2013 is the year that software-defined networking gets its early installations, having gone through product trials and technology evolution over the past several years. Now, as vendors roll out their SDN networking offerings and companies start the buying process, the question for many is: “How can I best use this technology in my network?”

Network use cases, in fact, were one of the most asked for items at the Gartner Data Center Summit meeting my colleague Gary Lee went to in December 2012. In order to give a sense of what problems SDN can solve in your network I am starting a series of blog posts on key SDN use cases, starting with network virtualization.

First, let’s discuss server virtualization, which has helped to power cloud services by allowing data centers to scale computing power at a lower cost. Server virtualization dramatically reduces the cost of computing services and allows multiple customers to leverage a single server. Both server virtualization and SDN are tied in terms of being high-profile solutions that can have dramatic impact on a data center.

Network virtualization logically divides a 10GB Ethernet connection into multiple lower speed connections so that each virtual machine in a server can have its own dedicated connection without requiring a separate NIC and cable.

In an IP network, this is done using virtual LANs, but that doesn’t scale well across a heterogeneous network unless each vendor supports the same VLAN protocols. By replacing the per-switch IP decision making with a central SDN controller over the entire network, virtualized network connections can be more easily made from one end of the network to the other.

How does this work? In the diagram, the three virtual networks are shown in their logical grouping, but below that we see how the actual switching infrastructure is organized to make this happen. Top-of-rack switches have connections to virtual machines located in the different servers. The connections through the physical infrastructure are guided by the SDN controller. The controller must map the logical network connections to the physical network across all of the switches. This is a very complex state-management task that SDN is particularly good at.

Going forward, as server connections increase from 10GB Ethernet to 40GB Ethernet, there will be even more headroom for virtualized network connections, making for dramatically complex network designs. But SDN is intended to simplify that complexity, so that all cloud networks can use this technology to maximize their networking investment.

New Single-port 1GbE Server Adapter from Intel!

webadmin@intel.com — Tue, 26 Feb 2013 20:52:01 GMT

Intel is pleased to announce the availability of our latest Gigabit Ethernet server adapter - the Intel® Ethernet Server Adapter I210-T1. Based on the Intel® Ethernet Controller I210, this adapter facilitates efficient data center cooling within a low power design with innovative power management features, including Energy Efficient Ethernet (EEE), DMA Coalescing, and a unique ventilated bracket. This low-cost, single port adapter supports PCIe 2.1 x 1, 10/100/1000 Ethernet in an ultra-compact footprint, and offers AVB (Audio Video Bridging) support for time-sensitive traffic in entry-level servers.

Intel® Ethernet Server Adapter I210-T1 Key Features:

Low cost/Low power single port
Energy efficient technologies – EEE and DMAC
Advanced features, including Audio Video Bridging and MCTP over PCIe and SMBus
Unique ventilated bracket for maximum airflow
Low-halogen and lead-free environmentally friendly design
Reliable and proven Gigabit Ethernet technology from Intel Corporation
Compact footprint (the size of a credit card!)
10/100/1000 BASE-T(X) copper backwards compatibility
PCIe Gen 2.1 support (2.5GT/s)
Low profile and full height brackets with every board
Error Correcting Memory (ECC) protection
Broad OS Support (warning huge file!)

The Intel® Ethernet Server Adapter I210-T1 is a direct replacement for the current single-port 1GbE product, the Intel® PRO/1000 PT Server Adapter (EXPI9400PT), which will announce the end of it's run in the next year. The Intel® Ethernet Server Adapter I210-T1 is available with more than 20%* cost savings.

The new Intel® Ethernet Server Adapter I210-T1 available NOW!

Intel® 82574 Gigabit Ethernet Controller Design Success Tips

webadmin@intel.com — Wed, 13 Feb 2013 23:09:34 GMT

For those that are manufacturing their own Intel® 82574 Gigabit Ethernet Controller based hardware implementations, a key step in creating a valid configuration is selecting the correct image based on the size of the EEPROM and desired functionality. If the device will attached to a BMC via SMBus or NC-SI, a 32Kb EEPROM (or greater) must be used. If not, the No-Management image should be used. Note in table 25 in the 82574 datasheet outlines minimum sizes for those two features sets. If for some reason you want to use the Management image on a system without a BMC, make sure the design has the NC-SI/SMBus pins properly dealt with. Putting a Management image (which requires size 32Kb EEPROM) in a No-Management size EEPROM (<32Kb EEPROM size) is not a supported configuration and will cause the 82574 to have non-deterministic and/or erratic behavior. It’s like going past the end of an array, you end up in the weeds and who knows what data is now being pointed to. Data that will be used because it thinks it’s okay. Just to put these sizes into context, a 1Kb EEPROM is just 64 words. An image that small you can tell by just looking at a dump of it. 1Kb fits onto a small screen, a 32Kb image will go on for a page or three.

All an OEM has to do is use the correct image (No-Management/Management) or use the correct size EEPROM to have a valid and supported configuration. Unless the management functionality is required, the Non-management image should be used.

Here is table from the datasheet for easy reference. Here is the datasheet (http://www.intel.com/content/www/us/en/ethernet-controllers/82574l-gbe-controller-datasheet.html?wapkw=82574+datasheet). Remember the datasheet is always right, the blog is always wrong if they disagree.

You can tell if it is a management image or not by looking at Word 0x0F in the EEPROM. Here is another snippet from the datasheet:

Now be careful, the EEPROM is dumped in Linux in BYTEs and the manuals are WORDS. So in Linux the 0x0010 line, the last two bytes make the word 0x0F, with byte swapping, the last byte of the0x0010 line is the high byte of the word. This is a non-management image:

Here is a management image:

Yes, I have put a LOT of NICs in my poor system. Your eth number will vary.

So the question to ask is 1) what size is the EEPROM attached to my 82574? Then 2) What image is in it? If the first answer is 32Kb or bigger, the second is not required. If the first is <32Kb then the second is in play. The HW vendor should know how to tell them apart.

As always thanks for using Intel Ethernet.

Intel® 82574L Gigabit Ethernet Controller Statement

webadmin@intel.com — Fri, 08 Feb 2013 02:41:02 GMT

Recently there were a few stories published, based on a blog post by an end-user, suggesting specific network packets may cause the Intel® 82574L Gigabit Ethernet Controller to become unresponsive until corrected by a full platform power cycle.

Intel was made aware of this issue in September 2012 by the blogs author. Intel worked with the author as well as the original motherboard manufacturer to investigate and determine root cause. Intel root caused the issue to the specific vendor’s mother board design where an incorrect EEPROM image was programmed during manufacturing. We communicated the findings and recommended corrections to the motherboard manufacturer.

It is Intel’s belief that this is an implementation issue isolated to a specific manufacturer, not a design problem with the Intel 82574L Gigabit Ethernet controller. Intel has not observed this issue with any implementations which follow Intel’s published design guidelines. Intel recommends contacting your motherboard manufacturer if you have continued concerns or questions whether your products are impacted.