IT Operations Management (ITOM)

How to take the headache out of QFabric network management

How to take the headache out of QFabric network management


Guest post by Tapan Shah, Customer Assist Engineer (NMC), HP Software


Data centers are facing all kinds of challenges with legacy multi-tier switching architecture. Providing applications and users with predictable latency and sustained bandwidth is a big issue, especially in virtualized environments, where physical location of the host machines impacts the performance of the guest virtual machines.


Network administrators and designers—particularly those in private, public and hybrid cloud service providers—are presented with other hurdles as well:

  • Power consumption of network elements
  • Outages due to misconfigurations
  • Modern-day network load due to increased number of MAC and IP addresses on each port
  • Need for a separate network for Ethernet data and storage traffic


A solution and a new challenge

Given all these challenges, data center operators are seeking new ways of networking within the data center by adopting technologies like Juniper Networks QFabric. QFabric technology is a next-generation data center switching architecture, intended to radically transform the economics and performance of networking in the data center.


Managing this architecture can present some challenges of its own. Traditionally, network management primarily uses an SNMP request/response mechanism. However, given the architecture and design of QFabric infrastructure, SNMP-only network management is not sufficient. Discovering the complete QFabric infrastructure and how QFabric components associate with each other is a headache.


Using Spiral Discovery HP's Solution

The good news is HP has an answer. HP Network Node Manager i (NNMi) (starting version 9.10) supports the Juniper QFabric infrastructure discovery as part of its Spiral Discovery.


As my colleague Balaji Venkatraman blogged previously, NNMi’s patented Spiral Discovery process is responsible for continuous Layer-2 and Layer-3 discovery:


“NNMi’s Spiral discovery engine avoids any episodic or batch discovery and allows NNMi to track dynamic changes in near real-time.  Spiral Discovery uses a variety of MIBs and protocols to reduce overhead and manage multivendor environments. This means that NNMi can discover network topology changes, and use that information to drive additional value added analysis.”



How NNMi works with QFabric architecture

The QFabric architecture is supposed to behave as a single logical switch. Figure 1 shows how QFabric components are connected (the left side illustrates the physical connectivity while the right side shows its iconized logical form):



Fig. 1: Physical topology and logical icon for QFabric architecture (Source: Juniper QFabric architecture whitepaper)


In NNMi, the entire Juniper QFabric system is discovered and shown as a single NNMi Node. Here is how each component is represented in NNMi:

  • Each physical chassis (Interconnect and QFabric Node) in the logical QFabric System is discovered and shown as a “card” in the NNMi Node Details inventory for the QFabric NNMi Node
  • Within each QFabric Chassis, each line card is shown as a daughter card hosted on the respective ‘chassis as card’ inventory
  • CPU, Memory, Fan, Power and Temp components are discovered for the QFabric Node and named according to the QFabric Chassis they are physically on
  • Internal QFabric connectivity is also discovered and listed in the Interfaces tab of the NNMi Node Details view and in NNMi L2 Connections Inventory views, but is not shown in L2 Neighbor Views (maps).
  • Only "external" connectivity between the QFabric and other non-QFabric devices is shown in L2 Neighbor Views (maps)


Discovery of QFabric

If you’re using NNMi discovery on QFabric infrastructure, there are three key things to remember:


  1. Juniper QFabric support requires JUNOS 12.2X50-D40 or later as it resolves Juniper SNMP issue PR#840144
  2. When setting SNMP Community string configurations (n NNMi Communications Configurations), disable GetBulk based SNMP requests for Juniper QFabric devices because Juniper QFabric components have a known issue of not handling SNMP GetBulk requests well
  3. NNMi requires Juniper NETCONF/XML (over SSH — a hyperlink from Juniper for NETCONF configuration) to be configured on the Juniper QFabric Director and corresponding access credentials in NNMi Communications Configuration to supplement information obtained via SNMP.


Both SNMP and NETCONF management information is necessary to provide complete discovery of the Juniper QFabric in NNMi. NETCONF is currently used to primarily to discover the Internal Fabric Connectivity.


Learn more

There’s no question that QFabric is a powerful solution to the challenges data centers face with legacy multi-tier switching architecture. But from a network management perspective, it’s important to have the right tools on hand to discover the complete QFabric infrastructure and how the components associate.


Explore HP Network Management Center

  • infrastructure management
0 Kudos
About the Author


This account is for guest bloggers. The blog post will identify the blogger.


nice content !!

HPE Expert

Excellent information! Thank you Tapan!