NetQ provides users with the ability to go back in time to replay the network state, see fabric-wide event change logs and root cause state deviations. The NetQ Telemetry Server maintains data collected by NetQ agents in a time-series database, making fabric-wide events available for analysis. This enables you to replay and analyze network-wide events for better visibility and to correlate patterns. This allows for root-cause analysis and optimization of network configs for the future.
Diagnose an Event after It Occurs
NetQ provides a number of commands for diagnosing past events.
NetQ records network events and stores them in its database. You can view the events through a third-party notification application like PagerDuty or Slack or use
netq show events to look for any changes made to the runtime configuration that may have triggered the alert, then use
netq trace to track the connection between the nodes.
netq trace command traces the route of an IP or MAC address from one endpoint to another. It works across bridged, routed and VXLAN connections, computing the path using available data instead of sending real traffic — this way, it can be run from anywhere. It performs MTU and VLAN consistency checks for every link along the path.
For example, say you get an alert about a BGP session failure. You can quickly run
netq check bgp to determine what sessions failed:
You can run a trace from spine01 to leaf02, which has the IP address 10.1.20.252:
Then you can check what's changed on the network to help you identify the problem.
Use NetQ as a Time Machine
With NetQ, you can travel back to a specific point in time or a range of times to help you isolate errors and issues.
For example, if you think you had an issue with your sensors last night, you can check the sensors on all your nodes around the time you think the issue occurred:
Or you can specify a range of times using the
between option. The units of time you can specify are second (s), minutes (m), hours (h) and days (d). Always specify the most recent time first, then the more distant time. For example, to see the changes made to the network between the past minute and 5 minutes ago, you'd run:
You can travel back in time 5 minutes and run a trace from spine02 to exit01, which has the IP address 22.214.171.124:
Trace Paths in a VRF
netq trace command works with VRFs as well:
Sample Commands for Various Components
NetQ provides network validation for the entire stack, providing algorithmic answers to many questions, both simple and intractable, that pertain to your network fabric.
Where is this container located?
Open ports? What image is being used?
Which containers are part of this service? How are they connected?
netq show docker container
netq show docker container service
Is my overlay configured correctly?
Can A reach B?
netq check|show vxlan
netq check evpn|lnv
Is OSPF working as expected?
Is BGP working as expected?
Can IP A reach IP B?
netq check|show ospf
netq check|show bgp
Is MLAG configured correctly?
Is there an STP loop?
Is VLAN or MTU misconfigured?
How does MAC A reach B?
netq check|show clag
netq show stp
netq check|show vlan
netq check mtu
Are all switches licensed correctly?
Do all switches have NetQ agents running?
netq check license
netq check|show agents
Is my link down? Are all bond links up?
What optics am I using? What's the peer for this port?
Which ports are empty? Is there a link mismatch? Are links flapping?
netq show|check interfaces
Have any components crashed?
What switches do I have in the network?
netq check sensors
netq show sensors all
netq show inventory brief