OpenStack

The recently launched OpenStack project aims to provide an open source stack for cloud computing service providers. The project's backers include NASA and Rackspace, along with Citrix, Dell, NTT Data, Peer1, Intel, AMD and a number of other companies.

The OpenStack project is focused on the tools needed to manage and deploy cloud services on a large scale. By creating an ecosystem of service providers sharing common standards and open source tools, the project aims to create an environment that increases acceptance of cloud computing by eliminating the threat of vendor or service provider lock in. The project is hypervisor agnostic, targeting KVM, Xen and XenServer with the initial release.

A previous blog entry described the  Xen Cloud Platform. The Open Stack and Xen Cloud Platform projects are largely complementary and since both projects share a number of major contributors, the efforts should be well coordinated. For example, a critical part of any cloud computing architecture is the virtualization and isolation of networking among tenants in the cloud. The Xen Cloud Platform has already adopted the Open vSwitch since it provides the open, standards-based, visibility and control needed to manage cloud networking. Based on comments from Citrix (a participant in both projects), it appears that OpenStack project will also incorporate the Open vSwitch as part of its networking stack.

The Open vSwitch supports the sFlow standard, extending the network visibility provided by most switch vendors into the virtualization layer. The sFlow standard is uniquely placed to become the standard of choice for cloud performance monitoring. The scalability of sFlow monitoring allows all the physical and virtual switches in a large cloud data center to be centrally monitored, providing the visibility needed to manage performance and account for network usage.

The recent extension of sFlow into server monitoring (see server) delivers the "single pane of glass" visibility into the network, storage and system resources that cloud service providers need to optimize service, reduce costs and charge for metered services.

Configuring Allied Telesis switches

The recent Allied Ware Plus 2.1.1 release adds sFlow support to Allied Telesis switches.

The following commands configure an Allied Telesis switch to sample packets at 1-in-512, poll counters every 30 seconds and send sFlow to an analyzer (10.0.0.50) over UDP using the default sFlow port (6343):

awplus> enable
awplus# configure terminal
awplus(config)# sflow collector ip 10.0.0.50 port 6343
awplus(config)# interface port1.0.1-port1.0.24
awplus(config-if)# sflow sampling-rate 512
awplus(config-if)# sflow polling-interval 30
awplus(config-if)# set sflow collector ip 10.0.0.50
awplus(config-if)# exit
awplus(config)# sflow enable

A previous posting discussed the selection of sampling rates. Additional information can be found on the Allied Telesis web site.

See Trying out sFlow for suggestions on getting started with sFlow monitoring and reporting.

RMON (4 groups)

Diagram highlighting 4 RMON groups supported by most switch vendors

If you look carefully at the data sheets for almost any managed switch you are likely to see RMON mentioned as a network management feature with one of the following qualifiers: mini-RMON, RMON (4 groups), RMON (groups 1,2,3 and 9) or RMON (statistics, history, alarm and event). The RMON feature is almost never used, it's a bit like the human appendix, a remnant left behind by evolution.

The RMON standard was developed by the IETF during the early 1990's to provide an SNMP interface to probes used for remotely monitoring Ethernet and Token Ring LANs. At the time, LANs consisted of coax cables that where shared by a number of hosts. Repeaters were used to connect the the cables and extend the network. In this environment, a single RMON probe would see all the traffic on the shared network, providing complete network visibility.

In the mid 1990's demand for bandwidth increased and switches started to become popular. However, while segmenting the network using switches helped improve performance, segmentation dramatically increased the number of probes needed to monitor the network since a probe was required for each segment. Many customers depended on the visibility that RMON probes provided and switch vendors felt pressure to provide embedded RMON functionality.

The RMON standard defines 20 different types (groups) of measurement, including: traffic matrices, top talkers, top protocols, trending etc. Implementing all these features on a switch is difficult, requiring a significant area on the switch ASIC, resources that the switch vendors wanted to allocate to more advanced switching features like QoS, rate limiting, VLANs etc.

Four RMON groups were identified that were easy to implement, requiring minimal ASIC resources. Since the RMON standard allowed a vendor to claim RMON compliance by implementing any of the RMON groups, many switch vendors decided to implement the four RMON groups in order to be able to market their products as supporting the RMON standard. The proliferation of devices, many with very limited capabilities, all claiming RMON compliance undermined the value of the RMON standard and it has fallen out of favor as a network monitoring technology.

Today, even though hardly anyone uses the four RMON groups they are now part of the design of most switch ASICs and leaving the feature in is easier than going to the trouble of redesigning the chip to remove it.

In 2001, the sFlow standard was developed to address the need to monitor network traffic in switched LAN environments. The sFlow standard describes a minimum set of functions (packet sampling and counter polling) that are easily implemented in a switch ASIC. Requiring that all sFlow compliant switches implement these features, ensures that every sFlow compliant switch delivers the full range of features needed for network visibility.

Diagram highlighting RMON functional areas addressed by sFlow

The sFlow monitoring architecture provides the full range of traffic monitoring functions by shifting complexity from the switches to a central sFlow analyzer (see Choosing an sFlow analyzer). The architecture has proven successful and today most switch vendors embed sFlow monitoring.