For more details, please see ourCookie Policy.

Data Center

Visibility and Automation in Concert

by asardell ‎12-13-2016 02:50 PM - edited ‎12-21-2016 04:51 PM (6,502 Views)

As discussed in our announcement last week, our SLX Visibility Services are built on our use of programmable silicon (Cavium XPliant), which allows richer extensibility inside the individual SLX 9140 (leaf) and 9240 (spine) switches. The two main elements to the visibility services are rich classification and action.


If you’re thinking that classification and action sound like packet filtering, you’re right.  What’s different here is that we provide this capability right in the hardware, yet with all the flexibility of software. Using Visibility Services, you can classify and act at multiple layers, and optionally automate these procedures at any time. Finally, this agile capability is fully upgradeable between software releases. 


Why is this Needed?

Rich classification is important because you need multiple layers of visibility:

  • From the physical network (interface connections)
  • Through the overlay networks: VLANs, VXLANs, or other service tunnels
  • To the workloads (applications or compute resources) themselves

The potential actions—mirror, count, and drop—can be configured either manually or by adding an automated workflow that can react to specific events or criteria. Captured data can also be sampled through sFlow, analyzed through SPAN (switch port analysis), or streamed to other analytics tools.


Having these services available on the SLX 9140 and 9240 means that you have this enhanced visibility from the top of rack (leaf) to the spine, and from the “wire to the workflow.” Combined with simplified configuration through Brocade Workflow Composer integration, this provides some powerful options.


Dynamic Visibility Everywhere in the Network

To understand how different visibility options work together, there are at least three different perspectives (Figure 1) that we can consider:

  1. The place in the network (PIN)
  2. The required scale
  3. The required specificity or granularity of the capture

 Perspectives on Visibility Related to PIN, Scale, and Specificity

Figure 1: Perspectives on Visibility Related to PIN, Scale, and Specificity


For example, you may need different visibility requirements at the leaf, spine and super spine. Similarly, you may need only a few gigabits of traffic, or you may need to capture and analyze terabytes of data. Perhaps a statistical sampling is all that is needed, or you may need to analyze multiple consecutive packets in a flow.


You can gain a certain degree of visibility by simply gathering statistics and state information through existing protocols like SNMP and sFlow, or with streaming mechanisms like grpc or other publish/subscribe models.  These conventional methods involve collecting data in the aggregate, covering everything that’s going on in the network.


For more specificity, SLX Insight Architecture and Visibility Services provide filtered data about the payloads in your network. With this richer classification and increased specificity, you can take actions either on or off the network element.


You can use these capabilities together for a comprehensive visibility solution across your entire data center, or you can stream captured data to other Brocade tools or third party analytics applications.


Pulling Visibility and Automation Together

To see how our visibility capabilities work with our automation toolset, consider a distributed application in a data center (Figure 2). An operator gets a call from an end user complaining that an application isn’t running, or is slow.


Agility through automation and visibility

Figure 2: Agility through Automation and Visibility


The ticketing system or network operator logs the ticket, and proceeds to determine the origin of the problem: the application itself, insufficient or overloaded compute resources, a misconfigured overlay, or perhaps a faulty network connection.  Today, the operator must gather data from different places in the network with multiple tools, bring that data back and take action—there are many disparate tools and manual efforts involved in this process.


This all changes with the right combination of inbuilt visibility and automation capabilities. For instance, as the original call comes in, it now triggers a BWC workflow and uses multiple tools to gather information:

  • Conventional interface counters or SNMP traps to see (for example) where packets may be getting dropped
  • SLX Visibility Services to identify an overlay (maybe VXLAN) and which servers/VLANs are involved, then
  • SLX Insight Architecture to identify which application is involved

With the right level of information at the right time and locations, the automated workflow can take action on an individual switch or router, and/or send the data to an external tool, or perhaps again into BWC for closed-loop remediation. 


Conclusion and Call to Action

As shown here, you can use SLX Visibility Services (on leaf and spine) or SLX Insight Architecture (in the super spine), but can also leverage your existing tools. Furthermore, you don’t need to start from scratch, as we have provided pre-packaged automation suites for the Brocade Workflow Composer. More on that next week.


In the meantime, contact your sales representative to discuss how these options related to your applications and data center network.