Dell OS10 SDN router demo

In this video from Dell's Network Field Day 11 (#NFD11) presentation,  Madhu Santhanam demonstrates an interesting use case for the new OS10 switch operating system that was introduced at the event.

The core of OS10 is an unmodified Linux kernel with an application development environment for Control Plane Services (CPS). These APIs allow software running on the switch: native linux applications, third party applications, and native OS10 applications to run on the core OS10 operating system.

The FIB Optimization application consists of three components: an sFlow agent to provide network visibility, Quagga for BGP routing, and the Selective Route Push agent which provides a REST API for selectively populating the hardware routing tables in the switch ASIC. The FIB Optimization application allows an inexpensive data center switch to replace a much more expensive high capacity Internet router.

In this use case, the data center is connected to a single transit provider and multiple additional peer networks. Initially all traffic is sent via a default route to the transit provider. The full Internet routing table consists of nearly 600,000 prefixes - far too many to fit in the switch hardware forwarding tables which in typical low cost switches can only handle 20,000 - 30,000 routes.

However, for any given site, only a small number the advertised prefixes are destinations for traffic. The challenge is to identify the most active prefixes so that they can be selectively installed in hardware tables. In this demonstration sFlow-RT is used to process the industry standard sFlow telemetry exported by the sFlow agent on the switch and compute the top N active prefixes. Every minute active prefixes installed and inactive prefixes are removed from the hardware using the Selective Route Push REST API.

In the demo, an IXIA traffic generator simulates a mixture of traffic to 1 peer and to other prefixes handled by the transit provides. Initially, all traffic is sent to the transit provider, but after a minute 76% of the traffic is being directed to the peer, and after two minutes over 90% of the traffic is being directed to the peer. As traffic patterns change, prefixes are automatically added and removed from the hardware forwarding table.

Analytics driven SDN is poised to disrupt the router market, replacing expensive, custom hardware with commodity switches. Solutions like the one Dell presented are already in production. Last year, David Barroso gave a talk showing that 99% of Spotify’s Internet traffic was contained in only 20,000 prefixes and started the  SDN Internet Router project which similarly combines BGP routing information with sFlow telemetry, but only updates the active routes every hour. In the Dell demo, updates occur every minute. The speed of response can be increased even further, the sFlow-RT Active Route Manager application detects and updates active routes within a second. Speed is important since the faster the application can react to changing traffic, the more effectively the hardware forwarding, opening up additional use cases for SDN routing.

Podcast with Nick Buraglio and Brent Salisbury

"Have you seen sFlow options in your router configuration or flow collector? Are you looking for alternatives to SNMP or NetFlow? Have you been curious about the instrumentation of your new white box or virtual switch? Yes? Then you will probably enjoy learning more about sFlow!"

Non-Blocking #1: SFlow With Peter Phaal Of InMon And SFlow.Org is a discussion between Brent Salisbury (networkstatic.net), Nick Buraglio (forwardingplane.net), and Peter Phaal (blog.sflow.com).

Web sites and tools mentioned in the podcast:

1. sFlow.org
2. Devices that support sFlow
3. Software to analyze sFlow
4. sFlow.org mailing list
5. sFlow structures
6. blog.sflow.com (incorrectly referenced as blog.sflow.org in the podcast)
7. Host sFlow
8. sflowtool

The podcast touches on a number of topics that have been explored in greater detail on this blog. The topics are listed in roughly the order they are mentioned in the podcast:

1. Widespread support for sFlow among switch vendors
2. Disaggregated flow cache
3. ULOG
4. Push vs Pull
5. sFlow vs SNMP for interface counters
6. Broadcom ASIC table utilization metrics, DevOps, and SDN
7. Broadcom BroadView Instrumentation
8. Rapidly detecting large flows, sFlow vs. NetFlow/IPFIX
9. SDN and large flows
10. Probes
11. Packet headers
12. Network virtualization visibility demo
13. History of sFlow
14. Standards
15. Open vSwitch performance monitoring
16. Wireless
17. Prescriptive vs descriptive standards (sFlow / IPFIX)
18. RMON (4 groups)
19. Observability
20. Host sFlow distributed agent
21. Host sFlow data model
22. Multi-tenant traffic in virtualized network environments
23. Workload placement
24. SDN router using merchant silicon top of rack switch
25. White box Internet router PoC
26. Active Route Manager
27. Leaf and spine traffic engineering using segment routing and SDN
28. CORD: Open-source spine-leaf Fabric (demo from 2015 Open Networking Summit)
29. sflowtool
30. sflowtool for packet caputure
31. sflowtool with Wireshark

Demystifying NFV Infrastructure Hotspots

Slides from the recent Dell NFV Summit 2015 are now available. Steve Wright's 7 Fallacies of NFV talk describes the importance of managing network resources in an NFV stack. The diagram above shows the complex network data paths that result from NFV as packets flow between virtual functions across physical and virtual switches.

The presentation describes how the Fallacies of Distributes Computing apply to NFV, highlighting the importance of effective management of network resources for effective NFV deployment.

Another paper, Demystifying NFV Infrastructure Hotspots by Ramki Krishnan, Anoop Ghanwani, and Michael Tien, demonstrates how industry standard sFlow instrumentation build into physical and virtual switches can provide the comprehensive real-time analytics needed to manage NFV deployments.

The vIMS (virtualized IP Multimedia Subsystem) is used as an example. The diagram below shows the functional elements of the logical architecture deployed on the hardware testbed shown above.

sFlow telemetry from the physical switches in the leaf and spine network, virtual switch instances, and hypervisors is streamed to an instance of the sFlow-RT analytics platform.

The dashboard application running on sFlow-RT demonstrates visibility into the traffic flows between virtual network functions.

The final set of charts in the dashboard shows the multi-media traffic flows running across the infrastructure. All elements are monitored and any hotspots are rapidly identified so that corrective actions can be automatically applied by the orchestration system.