Cisco Extensible Network Controller (XNC)

Cisco Nexus Data Broker: Scalable and Cost-Effective Solution for Network Traffic Visibility Solution Overview

  • Viewing Options

  • PDF (595.1 KB)
  • Feedback

What You Will Learn

This document discusses a software-defined approach to network traffic monitoring and visibility: a packet-broker solution. The solution uses Cisco Nexus® Data Broker software and Cisco Nexus switches. This approach extends the use of Cisco Nexus 3000 and 9000 Series Switches, using them to provide full-function network traffic monitoring without the limitations observed in some conventional approaches that exist today.


Visibility into application traffic has traditionally been important for infrastructure operations to maintain security, resolve problems, and perform resource planning. Now, however, as a result of technological advances and the ubiquity of the Internet, organizations increasingly are seeking not just visibility. They also want real-time feedback about their business systems to more effectively engage their customers. In addition, with the rapid evolution of cloud-based technologies, they also have a strong need for scalable and cost-effective network traffic aggregation and monitoring solutions.

Why Matrix Switches?

To understand the need for matrix switches, consider some of the methods commonly deployed in the data center to monitor network traffic and flows.


For a long time, hubs were used for network monitoring in the Ethernet segment. The use of hubs to monitor network data traffic presents numerous fundamental problems. The most notable problem is that hubs forward all traffic on all ports to all other ports. Hubs also increase the total size of the collision domain, preventing the network from operating efficiently. In contrast, a network switch reduces this domain by learning MAC addresses connected to each physical interface and therefore can forward traffic destined for each of those ports respectively. The end nodes connected to the switch do not all see all traffic on other devices, and they each receive only the frames that they are intended to receive. In general, hubs support only half-duplex and 10- and 100-Mbps transfer speeds.

Cisco Switched Port Analyzer

The Cisco® Switched Port Analyzer (SPAN) feature was introduced on switches to address the fundamental difference between switches and hubs. When a hub receives a packet on one port, the hub sends a copy of that packet from all ports except the one on which the hub received the packet. The switch builds a Layer 2 forwarding table on the basis of the source MAC addresses of the various packets that the switch receives. After this forwarding table is built, the switch forwards traffic destined for a MAC address directly to the corresponding port. To be able to monitor traffic on the switches, the SPAN feature is needed (Figure 1).

Figure 1.      Cisco SPAN

SPAN uses the following terminology:

   Ingress traffic: Traffic that enters the switch

   Egress traffic: Traffic that leaves the switch

   Source (SPAN) port: A port that is monitored with the SPAN feature

   Source (SPAN) VLAN: A VLAN whose traffic is monitored with the SPAN feature

   Destination (SPAN) port: A port that monitors source ports, usually ports with a sniffer connected

SPAN, however, also has limitations. In most common hardware switching architectures that exist today, a single application-specific integrated circuit (ASIC), or multiple ASICs grouped together to build a switching fabric, forwards packets at the hardware level, and very little data-plane information is sent to the CPU. Even modular chassis today have adopted the distributed forwarding model; however, when the software needs to tell the hardware to duplicate and redirect packets as in the case of SPAN, that process consumes additional CPU cycles. As a result, the number of SPAN and port monitoring sessions that can be configured on the switch is limited. Numerous factors affect network device performance when using SPAN:

   Process of sending packets to the CPU and forwarding them to their destinations

   Basic monitoring of the interface

   Volume of SPAN traffic (even more crucial on a 10 Gigabit Ethernet network)

Network Taps

Another method of packet monitoring uses physical hardware taps. These network taps can be extremely useful in monitoring traffic because they provide direct inline access to data flowing through the network. In many cases, it is desirable for a third party to monitor the traffic between two points in the network. If the network between points A and B consists of a physical cable, a network tap may be the best way to accomplish this monitoring. The network tap has at least three ports: an A port, a B port, and a monitor port. A tap inserted between the A and B ports passes all traffic through unimpeded, but it also copies that same data to its monitor port, enabling a third party to listen (Figure 2).

Figure 2.      Network Tap

Taps have many benefits:

   They can handle full-duplex data transmission.

   They are unobtrusive and cannot be detected by the network, and they do not use physical or logical addressing.

   Some support full inline power with the capability to build a distributed tap.

Whether you are trying to gain visibility into the server-to-server data communication at the edge or virtual edge of your network or to provide a copy of traffic to the intrusion prevention system (IPS) appliance at the Internet edge of your network, you can use network taps nearly anywhere in the environment. However, this deployment can add significant costs and operation complexities, introducing cabling challenges in a large-scale environment.

The Solution: Cisco Nexus Data Broker

The traditional approach to traffic-monitoring and troubleshooting tasks in the data center is to use purpose-built matrix switches that can aggregate multiple network taps and SPAN and also connect to multiple systems for security, compliance, and application performance monitoring. The traditional approach poses three primary challenges:

   The approach is too expensive to scale the visibility to meet today’s business requirements.

   The purpose-built switches are statically programmed with predetermined filtering and forwarding rules, so they cannot act in an event-based way to provide traffic visibility in real time.

   Support for interconnection of multiple switches for a scalable deployment that meets the needs of your data center architecture is limited.

Using Cisco Nexus Data Broker, Cisco’s approach replaces the purpose-built matrix switches with one or more Cisco Nexus 3000 or 9000 Series Switches. The traffic is tapped into this bank of switches in the same manner as in a matrix network. However, with Cisco Nexus Data Broker, you can interconnect these Cisco Nexus switches to build a scalable network tap and SPAN aggregation infrastructure. You also can combine tap and SPAN sources to bring the copy of the production traffic to this infrastructure. In addition, you can distribute the tap and SPAN sources and traffic monitoring and analysis tools across multiple Cisco Nexus switches.

In Figure 3, the Cisco Nexus switches are connected to various points in the network at which packet monitoring is advantageous. From each network element, SPAN ports or optical taps can be used to send traffic flows directly to this matrix switch. The matrix switch itself is directly connected to all the tools used to monitor the events in the network fabric. These monitoring devices include application analysis tools, security intrusion detection systems (IDSs), recording devices, and packet-sniffer tools.

Figure 3.      Tap and SPAN Aggregation with Cisco Nexus Data Broker

The Cisco Nexus Data Broker application discovers the tap and SPAN aggregation network topology and maintains the state of this network. It also maintains the mapping information of the monitoring tools connected to the Cisco Nexus switch and port.

Using Cisco Nexus Data Broker, the network administrator can aggregate the tap and SPAN traffic from multiple input sources, replicate this traffic, and forward the traffic to multiple monitoring tools, which may be connected to different Cisco Nexus switches. Also, the network administrator can filter traffic based on Layer 1 through Layer 4 header information and forward the traffic to multiple monitoring tools.

These functions allow you to build a fully distributed traffic-monitoring network that works as one logical device, with the capability to change the filtering and forwarding rules dynamically. Additionally, because Cisco Nexus Data Broker provides a Representational State Transfer (REST) interface, network operators can write applications to detect and capture unique traffic according to administrative requirements or traffic-monitoring needs. This solution thus allows unique and important traffic patterns to flow directly to the analysis tools in real time. With the elasticity and ease of use of the complete monitoring solution, the data broker application can provide greater business agility through a cost-effective and scalable approach for traffic monitoring.

All these features can be very attractive to organizations that have or require some type of monitoring solution today. Table 1 provides a summary of the Cisco Nexus Data Broker functions.

Table 1.       Cisco Nexus Data Broker Functions



Supported topology for tap and SPAN aggregation network

  Cisco Nexus Data Broker software discovers the Cisco Nexus switches and associated topology for tap and SPAN aggregation.
  The software allows you to configure ports as monitoring tool ports or input tap and SPAN ports.
  You can set end-device names for easy identification in the topology.

Support for IEEE 802.1ad QinQ to tag input source tap and SPAN port

  You can tag traffic with a VLAN for each input tap or SPAN port.
  QinQ support in edge tap and SPAN ports allows you to uniquely identify the source of traffic and preserve production VLAN information.

Symmetric hashing or symmetric load balancing*

  You can configure hashing based on Layer 3 (IP address) or Layer 3 plus Layer 4 (protocol ports) to load balance the traffic across a PortChannel link.
  You can spread the traffic across multiple tool instances to support high traffic volume.

Rules for matching monitored traffic

  You can match traffic based on Layer 1 through Layer 4 criteria.
  You can configure the software to send only the required traffic to the monitoring tools without flooding the tools with unnecessary traffic.
  You can configure actions to set the VLAN ID for the matched traffic.

Traffic replication and forwarding

  You can configure the software to aggregate traffic from multiple input tap and SPAN ports that can be spread across multiple Cisco Nexus switches.
  You can replicate and forward traffic to multiple monitoring tools that can be connected across multiple Cisco Nexus switches.
  This solution is the only one currently available that supports any-to-many forwarding across a topology.

Time stamping**

  You can time-stamp a packet at ingress using the Precision Time Protocol (PTP; IEEE 1588), thereby providing nanosecond accuracy. You can use this capability to monitor critical transactions and archive data for regulatory compliance and advanced troubleshooting.

Packet truncation**

  You can configure the software to truncate a packet beyond a specified number of bytes.
  The minimum packet size is 64 bytes.
  You can retain a header for only analysis and troubleshooting.
  You can configure the software to discard the payload for security or compliance reasons.

Response to changes in the tap and SPAN aggregation network states

  You can monitor and keep track of changes in the network condition.
  You can configure the software to respond to link or node failures by automatically reprogramming the flows through an alternative path.

End-to-end path visibility

  For each traffic-forwarding rule, the solution provides complete end-to-end path visibility all the way from source ports to the monitoring tools, including the path through the network.

Management for multiple disjointed monitoring networks

  You can manage multiple independent traffic monitoring networks, which may be disjointed, using the same Cisco Nexus Data Broker instance. For example, if you have five data centers and you want to deploy an independent monitoring network for each data center, you can manage all five independent deployments using a single data broker instance by creating a logical partition (network slice) for each monitoring network.

Role-based access control (RBAC)

  Application access can be integrated with the organization’s authentication, authorization, and accounting (AAA) server for both authentication and authorization.
  You can create port groups and associate them with specific user roles.
  You can assign users to specific roles and port groups. Users can manage only those ports to which they are assigned.
*Feature supported on Cisco Nexus 3100 platform and Cisco Nexus 9000 Series.
**Feature supported only on Cisco Nexus 3500 Series.

Cisco’s solution also provides various access mechanisms to the Cisco Nexus Data Broker functions:

   Web-based GUI for all configuration and user management (Figure 4)

   Robust REST API for programmatic access to functions and enablement of event-directed filtering and forwarding (Figure 5)

Figure 4.      Cisco Nexus Data Broker Web GUI Access Mechanisms

Figure 5.      Cisco Nexus Data Broker REST API Access Mechanisms

Cisco Nexus Data Broker Embedded Option

To reduce the overhead involved in deploying the traffic-monitoring solution and to keep the process simple when customers want to deploy the solution using a single switch (Cisco Nexus 3000 or 3500 Series or 3100 platform switch), you can use the data broker’s embedded option, which allows you to run the software on the Cisco Nexus 3000 or 3500 Series or 3100 platform Linux container without any need for a separate virtual machine (Figure 6). This option provides a special open virtual appliance (OVA); the OVA needs to be deployed on the Cisco Nexus switch and activated. This option also includes all the features of the application except:

   You can use it to manage flows only on the switch on which the Embedded OVA is deployed.

   You can deploy only one instance in each switch (high-availability configuration is not supported).

Figure 6.      Cisco Nexus Data Broker Embedded Deployment

Device Support Matrix for Cisco Nexus Data Broker

Table 2 lists the Cisco Nexus switches that support Cisco Nexus Data Broker.

Table 2.       Cisco Nexus Data Broker Device Support Matrix

Device Model

Cisco Nexus Data Broker Software

Deployment Mode Supported

Cisco Nexus 3000 Series

All Cisco Nexus Data Broker releases

Centralized and Embedded

Cisco Nexus 3100 platform

All Cisco Nexus Data Broker releases

Centralized and Embedded

Cisco Nexus 3500 Series

Cisco Nexus Data Broker 2.0 and later

Centralized and Embedded

Cisco Nexus 9300 platform

Cisco Nexus Data Broker 2.1

Centralized only

Cisco Nexus 9500 platform

Cisco Nexus Data Broker 2.1

Centralized only

Cisco Nexus Data Broker Features

Table 3 presents the main features of Cisco Nexus Data Broker.

Table 3.       Cisco Nexus Data Broker Features





Cisco Nexus Data Broker software provides a web-based GUI for management of all configurations and functions. The GUI provides access features, including:

  Topology and device management and assignment of port type
  Mapping of the ports to the end monitoring or analysis tools
  Configuration of filters to match traffic according to business needs
  Set up of traffic flows from network-edge ports to tool-delivery ports
  Event logging and troubleshooting
  Flow and port statistics
  RBAC user and role management

Northbound API

Cisco Nexus Data Broker REST-based API provides access to all functions that can be performed through the GUI.

Port-type assignment

Ports must be designated as edge tap or SPAN (input) or delivery (output) ports to be used to configure network connections. This feature, in combination with RBAC, increases network security.

InterSwitch Link (ISL) discovery

ISLs are ports that interconnect two switches. These ISLs can use individual ports or PortChannels. These ISLs are automatically discovered by the data broker software, and the state of these ISLs is automatically maintained.

Traffic Delivery (Basic)

One-to-one connection

This connection type establishes a one-to-one connection from an edge-network port to a tool-delivery port across the network with no oversubscription.

One-to-many connection

This connection type establishes a one-to-many connection from an edge-network port to multiple tool-delivery ports.

Many-to-one connection

This connection type establishes a many-to-one connection from multiple edge-network ports to a single tool-delivery port.

Combination connection

One-to-one, one-to-many, and many-to-one connections can be established for different flows at the same time in the same monitored network.

Port-speed adaptation

One-to-one, one-to-many, and many-to-one connections can be established between ports with different speeds. For instance, a 40-Gbps (40G) port can deliver traffic to a 10-Gbps (10G) tool port to allow use of traditional tools over high-speed production network interfaces.

Symmetric load balancing

You can configure symmetric hashing based on Layer 3 (IP address) information or Layer 3 and Layer 4 (protocol and port) information to load-balance the traffic to multiple monitoring tools.

Failure resiliency

If a path fails, each flow is automatically rerouted to an alternative path by the controller. If rerouting is not possible, an event is logged.

Traffic Delivery (Advanced)

Packet filtering

Traffic forwarding is based on the full-flow specification, allowing detailed traffic filtering to limit the traffic to the delivery port to only the traffic that is strictly necessary.

VLAN tag rewrite

You can change the original VLAN tag from the edge port to the delivery port either through the filter mechanism or by tagging at the edge port.

VLAN tag insertion

You can add a VLAN tag to the original packet to be delivered to allow a tool to identify the origin of the traffic.

QinQ support

If the packet is already tagged, Cisco Nexus Data Broker software can add a second tag that allows you to preserve the original tag information and also identify the edge tap or SPAN port from which the traffic is received.

Time stamping

You can configure the software to time-stamp packets using PTP with nanosecond accuracy for compliance, troubleshooting, or application-performance management.

Packet truncation

You can strip packet payloads for security and compliance purposes. The minimum packet length is 64 bytes, and you can specify the number of bytes to be retained. The packet payload is then truncated beyond the specified byte size and delivered to the monitoring tools.

Network Design

Multilevel design

Cisco Nexus Data Broker software can support multiple Cisco Nexus switches connected in any topology. Analysis and monitoring devices can be connected anywhere in the topology. Typical tapping network architectures follow:

  Two - or three-level networks (edge, distribution layer [optional], and core) in which the delivery ports are connected to the core switches
  Nonblocking leaf-and-spine architectures, in which both the edge and the delivery ports are connected to the leaf switches

Loop prevention

Built-in logic prevents creation of network loops. This feature supports one-to-one, one-to-many, many-to-one, and any-to-many replication and redirection policies.


Cisco Nexus Data Broker can support up to 100 switches and 4000 edge and delivery ports per instance.

High availability

Cisco Nexus Data Broker supports high availability through active-active clustering. Using the current release, up to five instances can be part of the same cluster.

Security and Operations


Each port can be exclusively assigned to one or more user groups.


Cisco Nexus Data Broker provides system logs as well as user audit logs. In addition, it supports different logging levels depending on administrator needs.

Path rerouting to guarantee delivery

If traffic is critical, data loss can impair compliance. In this case, if a network link or node failure occurs, the data flow is automatically rerouted using an alternative network path to prevent data loss and to meet compliance requirements.

System Requirements

Cisco Nexus Data Broker software

The minimum system requirements are:

  64-bit Linux OS (Fedora, Ubuntu, or Red Hat)
  8 GB of RAM, 6-core CPU, and 40 GB of free space in the partition in which the controller will be installed
  Java Release 1.8.0_45 or later recommended

Cisco Capital

Financing to Help You Achieve Your Objectives

Cisco Capital can help you acquire the technology you need to achieve your objectives and stay competitive. We can help you reduce CapEx. Accelerate your growth. Optimize your investment dollars and ROI. Cisco Capital financing gives you flexibility in acquiring hardware, software, services, and complementary third-party equipment. And there’s just one predictable payment. Cisco Capital is available in more than 100 countrie. Learn more.

For More Information

For more information, see the Cisco Nexus Data Broker webpage:

Cisco Nexus Data Broker configuration guide:

Cisco Nexus Data Broker Quick Start Implementation guides: