Integrity Check Guidelines

1. To perform an integrity check on a full running configuration file, the user must supply a running configuration generated by an NX-OS system and should not use the partial keyword. The partial keyword treats the input candidate as a subset of the running configuration.

Release Specific Guidelines

1. Beginning with Cisco NX-OS Release 10.2(3)F, Candidate config integrity check option is introduced on all Cisco Nexus switches.

2. Beginning from Cisco NX-OS Release 10.4(3)F, you can also use polymorphic commands in candidate configuration to perform partial diff.

Partial Diff of Default Commands for Multicast Components Guidelines

The content of this section is applicable from Cisco NX-OS Release 10.4(3)F.

If the default commands of multicast components are present in the candidate CONFIG_FILE, they are seen in show diff as follows:

ip access-list copp-system-p-acl-pim
10 permit pim any 224.0.0.0/24
20 permit udp any any eq pim-auto-rp
ip access-list copp-system-p-acl-pim-mdt-join
ip access-list copp-system-p-acl-pim-reg
10 permit pim any any

ipv6 access-list copp-system-p-acl-pim6
10 permit pim any ff02::d/128
20 permit udp any any eq pim-auto-rp
ipv6 access-list copp-system-p-acl-pim6-reg
10 permit pim any any

ip access-list copp-system-p-acl-igmp
10 permit igmp any 224.0.0.0/3
class-map copp-system-p-class-normal-igmp

ipv6 access-list copp-system-p-acl-mld
10 permit icmp any any mld-query
20 permit icmp any any mld-report
30 permit icmp any any mld-reduction
40 permit icmp any any mldv2

show diff running-config file_url [ unified ] [ partial ] [ merged ] Command Guidelines

• When using the unified , partial , and merged option to review the differences for the following PBR commands, the diff outputs are as mentioned below:

  • set ip next-hop

  • set ip default next-hop

  • set ip default vrf next-hop

  • set ipv6 next-hop

  • set ipv6 default next-hop

  • set ipv6 default vrf next-hop

  1. If the candidate next-hops are a subset of running next-hops (in the same order and sequence), and candidate additive flags are a subset of running flags, then the diff output is empty as shown in the following table:

     Candidate Config	Running Config	Partial Unified Merged Diff Output
     route-map rmap1 permit 10 set ip next-hop 1.1.1.1 2.2.2.2 load-share	route-map rmap1 permit 10 set ip next-hop 1.1.1.1 2.2.2.2 3.3.3.3 load-share force-order	<no-diff>

  2. If the candidate next-hops are a subset of running next-hops (in the same order and sequence), and the candidate has some extra additive flags which are not present in running config, then the diff output appends any additional flags present in the candidate config to the running config, similar to command line behavior as shown in the following table:

     Candidate Config	Running Config	Partial Unified Merged Diff Output
     route-map rmap1 permit 10 set ip next-hop 1.1.1.1 2.2.2.2 load-share force-order	route-map rmap1 permit 10 set ip next-hop 1.1.1.1 2.2.2.2 3.3.3.3 load-share drop-on-fail	route-map rmap1 permit 10 - set ip next-hop 1.1.1.1 2.2.2.2 3.3.3.3 load-share drop-on-fail + set ip next-hop 1.1.1.1 2.2.2.2 3.3.3.3 load-share force-order drop-on-fail

  3. If candidate next-hops are not a subset of running next-hops (in the same order and sequence), and the candidate and running record can have any additive flag, then the diff output indicates this with a '–' for the running config record and a '+' for the candidate config record.

     This distinction is important, particularly when using with PBR commands, where the sequence of next-hops is critical. Even if the next-hops IP addresses are identical, their order affects functionality.

     For example, ‘1.1.1.1 2.2.2.2’ is different from ‘2.2.2.2 1.1.1.1’.

     Important

     If there is an additive flag in the running config that you wish to retain after merging with the candidate config, you must explicitly include that flag in the candidate config. This ensures that the needed flags are preserved in the final, merged configuration.

     Candidate Config	Running Config	Partial Unified Merged Diff Output
     route-map rmap1 permit 10 set ip next-hop 1.1.1.1 2.2.2.2 load-share drop-on-fail	route-map rmap1 permit 10 set ip next-hop 2.2.2.2 1.1.1.1 load-share force-order	route-map rmap1 permit 10 - set ip next-hop 2.2.2.2 1.1.1.1 load-share force-order + set ip next-hop 1.1.1.1 2.2.2.2 load-share drop-on-fail

• When Partial Unified or Partial Unified Merged option is used, all the PBR commands are mutually exclusive and cannot coexist within the same parent route-map. Therefore, if a candidate configuration specifies multiple mutually exclusive PBR commands under a single route-map, only the last command variant will be shown in the partial diff output.

  Example-1: In this example, the candidate configuration includes multiple PBR commands under a single route-map rmap1 :

  route-map rmap1 permit 10
    set ip next-hop 1.1.1.1 2.2.2.2
    set ipv6 next-hop 3::3
    set ip next-hop verify-availability 4.4.4.4
    set ip next-hop verify-availability 5.5.5.5
    set ip vrf green next-hop 6.6.6.6
    set ip vrf blue next-hop 7.7.7.7 8.8.8.8

  Before the generation of the partial-diff output, the above candidate configuration is automatically converted to the following:

  route-map rmap1 permit 10
    set ip vrf green next-hop 6.6.6.6
    set ip vrf blue next-hop 7.7.7.7 8.8.8.8

  Example-2: In this example, the candidate configuration includes multiple 'set ip next-hop verify-availability' commands with different track IDs specified for the route-map rmap2 . Since track IDs cannot be modified for the same next-hop, these commands are mutually exclusive:

  route-map rmap2 permit 10
    set ip next-hop verify-availability 1.1.1.1 track 1
    set ip next-hop verify-availability 2.2.2.2 track 20
    set ip next-hop verify-availability 2.2.2.2 track 30
    set ip next-hop verify-availability 2.2.2.2 track 40
    set ip next-hop verify-availability 3.3.3.3 track 3

  Before generating the partial-diff output, the system will automatically consolidate these commands by retaining only the last set ip next-hop verify-availability command for each next-hop IP address as shown below:

  
                                  route-map rmap2 permit 10
    set ip next-hop verify-availability 1.1.1.1 track 1
                                  set ip next-hop verify-availability 2.2.2.2 track 40
    set ip next-hop verify-availability 3.3.3.3 track 3
                              

• When the Partial Unified Merged option is used, to review the differences for the verify-availability command variants, the track ID for a given next-hop is not modifiable.

  Therefore, if the candidate and running configurations contain the same next-hop but have different track IDs under the same parent route-map, the candidate record cannot simply be merged with the running record, as per command line behavior. Therefore, to apply the candidate record with different track ID for the same next-hop, the corresponding running config record must be removed first ( '–' for the running configuration record in the diff) and then when the candidate record is merged, it will be appended at the end of the last record under the same parent route-map ('+' for the candidate config record).

  The following table shows the sample candidate and running configuration with the 'Partial Unified Merged' output for different use cases as mentioned below:

  1. If the track ID is different for the same next-hop under candidate and running config, then the diff output is as shown in the following table:

     Candidate Config	Running Config	Partial Unified Merged Diff Output
     route-map rmap1 permit 10 set ip next-hop verify-availability 1.1.1.1 track 1 set ip next-hop verify-availability 2.2.2.2 track 20 set ip next-hop verify-availability 3.3.3.3 track 3 load-share	route-map rmap1 permit 10 set ip next-hop verify-availability 1.1.1.1 track 1 set ip next-hop verify-availability 2.2.2.2 track 2 set ip next-hop verify-availability 3.3.3.3 track 3 load-share	route-map test permit 10 set ip next-hop verify-availability 1.1.1.1 track 1 - set ip next-hop verify-availability 2.2.2.2 track 2 set ip next-hop verify-availability 3.3.3.3 track 3 + set ip next-hop verify-availability 2.2.2.2 track 20 load-share

  2. If track ID is not present under candidate config but present in running config for the same next-hop, then the diff output is empty as shown in the following table:

     Candidate Config	Running Config	Partial Unified Merged Diff Output
     route-map rmap1 permit 10 set ip next-hop verify-availability 1.1.1.1 track 1 set ip next-hop verify-availability 2.2.2.2 set ip next-hop verify-availability 3.3.3.3 track 3	route-map rmap1 permit 10 set ip next-hop verify-availability 1.1.1.1 track 1 set ip next-hop verify-availability 2.2.2.2 track 2 set ip next-hop verify-availability 3.3.3.3 track 3	no-diff

  3. If track ID is not present under running config but present in candidate config for the same next-hop, then the diff output is as shown in the following table:

     Candidate Config	Running Config	Partial Unified Merged Diff Output
     route-map rmap1 permit 10 set ip next-hop verify-availability 1.1.1.1 track 1 set ip next-hop verify-availability 2.2.2.2 track 20 set ip next-hop verify-availability 3.3.3.3 track 3	route-map rmap1 permit 10 set ip next-hop verify-availability 1.1.1.1 track 1 set ip next-hop verify-availability 2.2.2.2 set ip next-hop verify-availability 3.3.3.3 track 3	route-map rmap1 permit 10 set ip next-hop verify-availability 1.1.1.1 track 1 - set ip next-hop verify-availability 2.2.2.2 set ip next-hop verify-availability 3.3.3.3 track 3 + set ip next-hop verify-availability 2.2.2.2 track 20

Partial Diff of RPM Commands Guidelines

The content of this section is applicable from Cisco NX-OS Release 10.4(3)F.

When using the unified, partial, and merged option to review the differences for the following RPM commands, the diff outputs are as follows:

• In the candidate configuration, the RPM commands will undergo syntactic validation as reflected in the diff output. However, semantic validation will not be performed in the diff output. It is the user's responsibility to ensure that the commands in the candidate configuration are semantically accurate.

  If the command in the Candidate-config is semantically incorrect, the diff may incorrectly indicate that the command is executable, but in actual it may not.

• Ensure that you provide the sequence number mandatorily for the following commands in the Candidate-config file:

  • ip prefix-list list-name seq seq { deny | permit } prefix

  • ipv6 prefix-list list-name seq seq { deny | permit } prefix

  • mac-list list-name seq seq { deny | permit } prefix

  • ip community-list { standard | expanded } list-name seq seq { deny | permit } expression

  • ip extcommunity-list { standard | expanded } list-name seq seq { deny | permit } expression

  • ip large-community-list { standard | expanded } list-name seq seq { deny | permit } expression

  • ip-as-path access-list list-name seq seq { deny | permit } expression

• When the following commands include an expression string that has spaces enclosed in quotes within the Candidate-config, there will be no differences displayed in the diff output:

  • ip community-list expanded list-name seq seq { deny | permit } expression

  • ip extcommunity-list expanded list-name seq seq { deny | permit } expression

  • ip large-community-list expanded list-name seq seq { deny | permit } expression

  • ip-as-path access-list list-name seq seq { deny | permit } expression

  Candidate Config	Running Config	Partial Unified [Merged] Diff Output
  ip community-list expanded list_abc seq 10 permit "1:1 "	ip community-list expanded list_abc seq 10 permit "1:1"	no-diff
  ip extcommunity-list expanded list_abc seq 10 permit "1:1 "	ip extcommunity-list expanded list_abc seq 10 permit "1:1"	no-diff
  ip large-community-list expanded list_abc seq 10 permit "1:1:1 "	ip large-community-list expanded list_abc seq 10 permit "1:1:1"	no-diff
  ip as-path access-list list_abc seq 10 permit "1 "	ip as-path access-list list_abc seq 10 permit "1"	no-diff