Nexus Dashboard Search and Explore

What query — Answers how the different networking entities are related to each other.

Examples:

Can query — Answers whether the entities in the ACI policy can communicate with each other. Can queries allow you to determine if the entities in the ACI policy can communicate using protocols such as TCP, UDP, or ICMP and the source and destination ports used for communication.

Examples:

Show query — Allows you to view any of the various objects across any fabric currently visible in Nexus Dashboard.

Primarily supports single-word searches for MAC and IP addresses.

Auto-suggest provides detailed results including switch, interface, and VLAN information.

Results are limited to 10,000 entries and display fabric names.

The Details column provides additional information with links to external resources.

You can view the details of remote resources within the context of the current clusters.

Clicking an endpoint loads its details page within the search view; external links from this page are restricted.

Redirecting to a remote cluster does not retain endpoint filters, takes you only to the fabric-level, and provides no direct return to the search view.

A What X to any association query is only supported for single fabrics.

The retention period for a What query is seven days. After that, the What query does not display in historical searches.

A Can any-to-any query is not supported.

For a Can query between prefixes, if the number of EPGs shared by the prefixes is greater than 25, the endpoint table fails to load the data and displays an error message.

To explore the Cisco APIC resources successfully using the Search and Explore feature, the Cisco APIC policy must contain either valid endpoints such as fv:CEp or valid EPGs.

Can query is supported only on ACI fabric and it is not available on NX-OS.

Queries for Nexus Dashboard resources (such as interfaces, VRFs, or vPCs) are unavailable on Nexus Dashboard clusters integrated when telemetry is enabled on the local cluster.

Specific queries, such as show anomalies on interface, show anomalies on vpc, or show endpoints on interface, are unavailable on Nexus Dashboard clusters running on the same Nexus Dashboard instance when the controller is present on the local cluster.

A What X to any association query is only supported for single fabrics. Additionally, Can queries are not supported for NX-OS fabrics.

The retention period for a What query is seven days. After that, the What query does not display in historical searches.

For NX-OS fabrics, this feature provides a switch-wide view of VRFs, VLANs, interfaces, endpoints, and leaf switch resources in the fabric. Search and Explore also provides Layer 2 VNI and Layer 3 VNI as resources.

Resource aggregation is supported for VLAN and VRF resources. With resource aggregation, resources like VRF and VLAN are discovered for the entire fabric and all the leaf switches are aggregated by these resources. If you query What VLANs are associated with any? in the Query Results area, you see a list of all the VLANs available across the fabric. EP and LEAF counts are aggregated by VLAN, and you can find all the EPs and LEAFs associated with a single VLAN by clicking the aggregated resource counts.

Additionally, as the VLAN and VRF queries are fabric-wide, if you want to explore resources for a VLAN on a specific leaf switch, you must use the AND operator in your query.

Example: What EPs are associated with VRF:vrf-vrf_51020 and LEAF:CANDID-SYS-S1-L1

A networking asset, such as interfaces on a leaf switch, must be associated with an endpoint in the leaf switch for you to be able to explore it in Search and Explore.

When a VRF is not operational, Search and Explore discovers the endpoints as a Layer 2 endpoint. Search and Explore discovers endpoints as Layer 3 or Layer 2 endpoints. All endpoints present in a VLAN are discovered, and other endpoints are ignored.

In Search and Explore, if you do not see endpoints or other network assets, look for system anomalies in the associated snapshot. Verify that the collection has succeeded in all the leaf switches. If the collection failed, it may result in endpoints not being discovered.

Nexus Dashboard-based fabrics must have endpoints available in the VNIs or VRFs for certain What queries to work, since this feature is based on the endpoints that are learnt on VNIs and/or VRFs. If the endpoints are not available, the What query for the VRF or L3 VNI does not display accurate results.

If you choose EPGs, Tenants, and Both, the outer ring represents the tenants, the inner ring represents the application profiles, and arced lines in the middle show the health of the contracts.

If you choose EPGs, VRFs, and Both, the outer ring represents the VRFs, the inner ring represents the bridge domains, and arced lines in the middle show the health of the contracts.

If you choose Prefixes and VRFs, and Both, the outer ring represents the VRFs, the inner ring represents the bridge domains or L3Outs, and arced lines in the middle show the health of the contracts.

Connectivity — Displays the source EPG, destination EPG, source prefix, destination prefix, source VRF and destination VRF between the entities.

Policy — Displays the security flows between the source and destination. It lists the source EPG, destination EPG, policy enforcement VRF, policy owner (contract), ether type, protocol, source port from, source port to, destination port from, destination port to, TCP rules and rule action. For a non PBR contract, it displays one rule while for a PBR enabled rule, it displays two.

Forwarding — Displays the prefix table between the source and destination. You can click Subnet/Route to see information regarding the prefixes.

When you create a PBR, you can configure a BD for the provider/consumer connector of the service node, which allows us to see the service BD and the service BD subnet in addition to the consumer and provider BD information.

Endpoints — Displays the endpoint details of the source and destination. For a PBR enabled rule, an additional EPG (service EPG) will be listed with the EPG column and BD column populated.

Anomalies — Lists all the anomalies generated from the query. You can click the anomaly to determine the objects in your fabric that are affected by the issue. Pass or fail checks are performed on the anomaly and the suggested steps to resolve the issue are displayed.

In the permit rule, there is only a direct contract, so there is no PBR. Since no PBR, the columns such as service graph, are hidden and not available in Table configuration options.

In the redirect rule, the policy table displays the columns such as service graph instance, redirect IP address, and redirect device information. Additionally, the graph has been enhanced to include the PBR node.

The Policy table displays the redirect rule from EPG_A to EPG_B and the permit rule from service EPG to EPG_B.

The Forwarding table also displays subnets from a service EPG.

The Endpoint table displays endpoints from a service EPG.

Can serviceEPG_name talk to regularEPG_name

What endpoints are associated with serviceEPG_name

After running your query, when you view the Connectivity Table and the Policy Table, in the Source EPG and Destination EPG columns, a shadow tag to an EPG displays if the EPG is a shadow in the corresponding fabric. For example, epgname(shadow). If an EPG is not a shadow, there will be no shadow tag after the EPG name. However, if you have a version of APIC/Orchestration that does not have the shadow annotation, the shadow tag does not display even for shadow EPGs.

In the Endpoints, Forwarding, and the Policy tables, you can click a fabric for specific anomaly details.

The Anomalies table displays individual, aggregated, or inter-fabric anomalies based on the queries that you have chosen.