At first, I was really excited about the new version and was looking forward to seeing the new features in detail. But it looks like Cisco decided to follow its development cycle and release a new version without any significant new features.
Dynamic and auto breakout ports are now supported with the Cisco N9K-C93600CD-GX and N9K-C9316D-GX switches.
Cisco Nexus 9000 switches utilize persistent storage to maintain system software images, switch configuration, software logs, and operational history. Each of these areas can contain user-specific information such as details on network architecture and design, and potential target vectors for would-be attackers. The secure erase feature enables you comprehensively to erase this information, which you can do when you return a switch with return merchandise authorization (RMA), upgrade or replace a switch, or decommission a system that has reached its end-of-life.
This feature erases user data in the following storage devices:
Bidirectional Forwarding Detection (BFD) is now supported for static routes that are reachable using secondary IPv4/IPv6 subnets that are configured on routed interfaces. This feature was originally introduced in the 5.2(4) release and is now available in the 6.0 releases.
You can now use the PTP Telecom profile (G.8275.1) on virtual port channels (vPCs) and on remote leaf switch peer links.
You can now use SyncE on vPCs and on remote leaf switch peer links.
Transport Layer Security (TLS) version 1.3 is now supported. This feature was originally introduced in the 5.2(5) release and is now available in the 6.0 releases.
Prior to Cisco APIC Release 6.0(1), there was no option to specify a weight for each PBR destination. The capacity of the PBR destinations (service nodes) was not considered, and the weight for each destination was the same, which is the default value, 1. In the example below, consider four destinations, each destination could roughly receive the same amount of traffic because the weight for traffic load balancing is the same, approximately about 25% of the traffic.
| Destination | Weight | Traffic % |
|---|---|---|
| Destination 1 | 1 | 25 |
| Destination 2 | 1 | 25 |
| Destination 3 | 1 | 25 |
| Destination 4 | 1 | 25 |
Beginning with Cisco APIC Release 6.0(1), weight-based symmetric PBR is supported, which handles traffic more efficiently. In weight-based symmetric PBR, an administrator can set weights for a PBR destination based on the capacity of the service node, and traffic is load balanced based on the set weights. One service node can be part of multiple policies and can have different weights in different policies.
Consider, four PBR destinations with different capacities. Instead of the same amount of traffic being sent to all destinations, PBR configuration for a destination is weight-based. You can assign a weight from 1 to 10. If no weight is assigned, the default value is 1. The assigned weight determines the traffic sent to the destination. An example of the weight-based distribution of traffic is shown below.
| Destination | Weight | Traffic % |
|---|---|---|
| Destination 1 | 4 | 40 |
| Destination 2 | 3 | 30 |
| Destination 3 | 2 | 20 |
| Destination 4 | 1 | 10 |
To maintain symmetric PBR on a two-arm node configured with weights, ensure to configure the same weight for the external and internal leg.
To maintain symmetric PBR for service insertion, where each service node has two interfaces, consumer and provider connectors, ensure to configure the same weight for both consumer and provider connectors.
Limitations of weight-based PBR
For PBR destination in a bridge domain, the maximum weight per PBR policy is 128. For PBR destination in an L3Out, the maximum weight per PBR policy is 64.
System faults are raised under the following conditions:
Authentication by an external server for SAML and OAuth 2 is based on user group map rule information, in addition to the standard CiscoAVpair-based authentication.
Cisco APIC now supports the Remove Private AS option to remove private autonomous system numbers from the AS_path in an eBGP route and supports the AS-Path match clause while creating a BGP per-peer route-map.
In a SPAN session, you can now configure extended filter entries for filter groups by using either the APIC GUI, NX-OS-style CLI, or REST API.
Along with usual SPAN filter parameters such as Source/Destination IP Prefix, First/Last source port, First/Last destination port and IP Protocol, there's a way now to specify an extended filter entry that consist of:
You can either set the values for the Source/Destination range or the DSCP/Dot1P range. If you set both the Source/Destination and DSCP/Dot1P ranges, faults are displayed.
DSCP or Dot1p is not supported for the egress direction. If you select Both as the direction then either DSCP or Dot1p is supported for ingress direction only and not for egress direction.
TCP flags can be configured only if you have selected Unspecified or TCP as the IP Protocol.
Starting with the 6.0(1) release, remote leaf switches support remote pools with a subnet mask of up to /28. In prior releases, remote leaf switches supported remote pools with a subnet mask of up to /24. You can remove remote pools only after you have decommissioned and removed them from the fabric including all the nodes that are using that pool.
The new Cisco Nexus 9336C-FX2-E has been added as a leaf/spine option for your fabric. It has 36 x 40/100 Gbps QSFP ports supporting 1/10/25/40/50/100 Gbps port speeds or 16/32 Gbps FC ports with a total of 7.2 Tbps bandwidth and over 2.4 bpps. Breakout is supported on all ports.
A breakout parent port shows in the drop-down list for the SPAN source even after the port is broken out.
For a health record query using the last page and a time range, the GUI displays some health records with a creation time that are beyond the time range (such as 24h).
After migrating a VM between two hosts using VMware vMotion, EPG does not get deployed on the target leaf node. When affected, the fvIfConn managed object corresponding to the missing EPG can be seen on APIC, but it would be missing from the target leaf node when queried.
When there are more than 40 objects in the tree and you double click on an object in the BGP Peer table, then the tree does not expand because the tree does not have pagination. The APIC tries to load all objects in one query, which is drastically slows the GUI
When HBR is enabled on a source EPG's bridge domain and the subnet is configured with the private scope (advertise externally = FALSE), if there is a shared service EPG contract with an L3Out, the L3Out will not publish the subnet or the corresponding /32 host routes because of this private scope.
In this scenario, if there is also an explicit ESG leakRoute configured for the same subnet across those VRF instances, the leakRoute is faulted because the route is already shared with an EPG contract, and the leakRoute is installed in the hardware along with a pcTag, then the leakRoute should not be processed and any flags under it should not be considered.
But, if this explicit leakRoute has a public scope, the /32 host routes are still published externally out of the L3Out, which should not happen as the leakRoute itself is faulted and bridge domain subnet scope is private.
When a VRF-level subnet and instP-level subnet with a summary policy is configured for an overlapping subnet, the routes will get summarized by the configuration that was added first. But, the fault on the configuration that was added last will not be shown in the Cisco APIC GUI.
When a VRF-level subnet, fvRtSummSubnet, exists with a summary policy and an instP level subnet, , with the same subnet as the VRF-level subnet is associated with summary policy, then there won't be any fault seen on the Cisco APIC. The summarization will be done according to the VRF-level subnet .
VMM domain attachments of floating SVIs configured for dual stack with the same encapsulation and the same VMM domain attachments are not being cleaned up after downgrading from 6.0(1) to an earlier release.
Importing the routing table of a remote site carries the wrong autonomous system number (ASN).
2.2(1c) or later is required for the Cisco UCS Fabric Interconnect and other components, including the BIOS, CIMC, and the adapter.
