Anuta ATOM

Configuration Compliance 8.7

Table of Contents

Configuration Compliance

Configuration Compliance feature allows users to Define & Enforce Configuration Compliance Standards. This is realized within ATOM using the following primitives.

  • Policies – Define Configuration standards & Remediation Policy by Device Family, Device Type, OS Type etc.,

  • Profiles – Group multiple policies and apply configuration standards on one or more devices

  • Reports – Comprehensive compliance reporting view at device level

  • Remediation – Fix Policy Violations on one or more devices

Following diagram summarizes the overall flow.

ATOM supports Configuration Compliance for the following Vendors:

  • Cisco Systems

  • Juniper Networks

  • Fortinet

  • Force10 Networks

  • Brocade

  • PaloAlto Networks

  • Riverbed Technology

  • F5 Networks

Policies

Compliance policy allows configuration standards to be defined in CLI format and YANG format(x-path or xml). Following provides a high level overview of a Policy:

  • Policy is a collection of Rules

  • A Rule contains one or more Conditions

  • Condition describes

    • Expected Configuration. Configuration can be parameterized through Rule Variables.

    • Action to be taken on a condition evaluation includes CLI commands or Netconf XML RPC format to be used to remediate a violation.

  • A Rule can be attached to one or More device platforms – Vendor, OS Type, Device Family, Device Type and OS Version

Use Cases

#

Configuration Standard Style

Example

Reference

1

Static Configuration

Example: All Devices in Target Network should Contain a specific Domain Name

Expected Configuration:

ip domain-name anutacorp.com

Fix Configuration:

<<If missing, configure the above command>>

Scenario1

X-path Expression

Xpath Expression:

Cisco-IOS-XR-native:native/ip/domain/name=`anutacorp.com’

Scenario6

XML Template Payload

Template Payload:

<native xmlns=”http://cisco.com/ns/yang/Cisco-IOS-XE-native“>

<ip>

<domain>

<name>net.disney.com</name>

</domain>

</ip>

</native>

Scenario11

2

Dynamic Configuration with User provided values

Example: Devices in Target Network should have a specific Loopback interface – Loopback0 or Loopback1 based on user input.

Expected Configuration:

interface {{ interface_name }}

Fix Configuration:

<<If missing, Configure the specific Loopback interfaces>>

Scenario3

X-path Expression

Xpath Expression:

Cisco-IOS-XE-native:native/interface/Loopback/name=’0′ and

Cisco-IOS-XE-native:native/interface/Loopback[name=0]/ip/address/primary/address='{{ lo0_ipv4addr }}’ and

Cisco-IOS-XE-native:native/interface/Loopback[name=0]/ip/address/primary/mask=’255.255.255.255′ and

Cisco-IOS-XE-native:native/interface/Loopback[name=0]/ipv6/address/prefix-list/prefix='{{ lo0_ipv6addr }}’

Scenario9

XML Template Payload

Template Payload:

<native xmlns=”http://cisco.com/ns/yang/Cisco-IOS-XE-native”>

<interface>

<Loopback>

<ip>

<address>

<primary>

<address>10.100.99.98</address>

<mask>255.255.255.255</mask>

</primary>

</address>

</ip>

<ipv6>

<address>

<prefix-list>

<prefix>2605:30C0::3B/128</prefix> </prefix-list>

</address>

</ipv6>

<name>0</name>

</Loopback>

</interface>

</native>

Scenario13

3

Configuration with Patterns, Wildcards, etc.that require Regular expressions

Example: All the VTY lines should have specific exec-timeout and session-timeout configured.

Expected Configuration:

line vty (.*)

session-timeout 10

exec-timeout 10 0

Fix Configuration:

<<If missing, Configure the timeouts under all matching VTY lines>>

Scenario4

4

Configuration with sub-modes

Example: The physical Interface should not be shut down and show be in auto-negotiation mode

Expected Configuration:

interface {{ interface_name }}

no shutdown

negotiation auto

Fix Configuration:

<<If missing, Configure the above commands for one or more interfaces>>

Scenario3

5

Removing unwanted extra configuration

Example: Finding the Devices having extra ntp-server addresses configured and removing those other than expected server addresses.

Expected Configuration:

ntp-server 10.1.1.1

Fix Configuration:

<< Configure above ntp-server if not found. Remove any ntp server other than 10.1.1.1 >>

Scenario2

6

Advanced: Presence of an entity value from one block in another

Example: Finding the devices in the network which doesn’t contain the OSPF router-id configured as per loopback0 ip address.

Expected Configuration:

interface Loopback0

ip address 45.45.45.5 255.255.255.255

!

router ospf 100

router-id 45.45.45.5

Fix Configuration:

router ospf 100

router-id 45.45.45.5

Scenario5

Scenario 1: IP Domain Name

Scenario: Network Devices must have domain name configured. In this example we are looking for the domain name as anutacorp.com across all devices in the lab.

Platform:

Cisco IOS-XE

Expected Configuration:

ip domain-name anutacorp.com

Fix-CLI Configuration:

ip domain-name anutacorp.com

Follow the steps below to configure Compliance Policy for the above scenario.

  • Configure Policy

Steps:

  • Navigate to Resource Manager > Config Compliance -> Policies

  • Click ‘+’ to create new Policy and provide the following information

    • Policy Name

    • Description

  • Configure Rules

One or more rules can be configured to express configuration standards. Based on the complexity of the scenario, configuration standards can be broken up into more than one condition.

Steps:

  • Navigate to Resource Manager > Config Compliance -> Policies

  • Create/Select a Policy

  • Click ‘+’ to create new Rule

  • ATOM opens up new wizard as shown below

  • Rule has four components

    • Basic Information

    • Platform Selection

    • Rule Variables

    • Conditions & Actions

Basic Information

Provide basic information as described below. Information provided here is for documentation purposes only.

Rule Name: Provide any Name

Description: Brief explanation of the configuration evaluation that the rule is going to perform.

Impact: If the device configuration does not meet the rule or rules in the policy, type it in the Impact field.

Suggested Fix: Using which non-compliance can be corrected and device returns to a state of

Compliance.

Platform Selection

Rules contain configuration standards expressed in CLI Configuration format. Configuration standard can be at Vendor level, Device Type, Device Platform, OS Type or OS Version.

Steps:

  • Navigate to Config Manager > Config Compliance -> Policies -> Rules

  • Create/Select a Rule & Provide the following information

    • Vendor

    • OS type

    • Device Family

    • Device Type

    • OS Version

Note: Platform Selection will be used during Policy execution. Devices that don’t match the above criteria are skipped.

Note: It’s not common to have more than one Platform

Rule Variables

Rule variables allow configuration to be parameterized.

Steps:

  • Navigate to Resource Manager > Config Compliance -> Policies -> Rules

  • Create/Select a Rule Variables

    • Key – Provide unique name to identify rule variable

    • Description – Describe rule-input configuration

    • Default Value – Default value. Can be overridden during Policy execution time

Conditions and Actions

Expected configuration & actions to be taken when violations are detected are specified in the Conditions & Actions section.

Based on the complexity of the scenario, configuration standards can be broken up into more than one condition.

Steps:

  • Navigate to Resource Manager > Config Compliance -> Policies -> Rules

  • Create/Select Conditions & Actions

    • Condition Details – Described Below

    • Action Details – Described Below

Condition Details

Condition section provides users to specify the expected configuration and various options on how to match the expected configuration including option to identify sub mode configuration blocks.

Condition Name: Name of the Condition

Sequence Number : Order of the condition execution.

Scope Details

Condition scope details: Scope could be either full configuration copy or configuration matched in prior condition.

  • Configuration – Full Configuration

  • Previously_Matched_Blocks – Subset of configuration matched by prior condition

Block Options

Start Expression – Regular expression indicating the start of the sub-block.

End Expression – Regular expression indicating the end of the sub-block.

Condition Match Criteria

Operator:

MATCHES_THE_EXPRESSION – Checks whether the condition value exactly matches with device configuration or not.

DOESNOT_MATCHES_THE_EXPRESSION – Checks whether the condition value does not match with the device configuration or not.

CONTAINS_STRING – Checks whether the device configuration contains condition value config or not.

Rule-Pass-Criteria:

All_SubBlocks – Checks whether the condition value matches in all the blocks or not.

Any_SubBlock – Checks whether the condition value matches in any of the blocks or not.

Value: Value field accepts Configuration Standard as CLI Configuration. Following types of configuration can be provided:

  • Static Configuration

  • Dynamic/Parameterized Configuration

  • Configuration with Regular Expressions

  • Configuration coupled with Jinja2 Templating

Note: For some Vendor Configurations like Cisco IOS-Style, whitespace in command prefix is mandatory to identify commands at sub-mode level.

For Scenario 1 – Provide value as ip domain-name anutacorp.com to search for a given domain name in the running configuration.

Test Config

Based on the complexity of the configuration standard, Value may be complex and may need to build up iteratively. Test Config utility helps the CLI configuration condition to be validated against Test Configuration.

Steps:

  • Navigate to Resource Manager > Config Compliance -> Policies -> Rules ->

  • Create/Select Conditions & Actions

  • Click “Launch Test Config” will launch a form to Test Condition

Condition Match Operator:

MATCHES_THE_EXPRESSION

DOESNOT_MATCHES_THE_EXPRESSION

CONTAINS_STRING

Value: Sample configuration to be tested. Value will be shown from the Condition Details. Value can be further refined

Note: Any Edits to Value will reflect in the Condition Details -> Value and Vice-versa.

Test Configuration: Sample device configuration

Rule Variables: The rule variables created in the rule will be shown here with default values. Values can be modified.

Note: Any Edits to Values will not be reflected in the Rule Variable default values provided in Rule Variables Section.

Test Results: Based on Condition Match Operator test results will be shown on the right hand side

Action Details

Action can be taken after Condition evaluation. Condition can result in either a “Match” or “Non-Match”. Depending on the scenario one or both criteria may apply.

Select Match Action – This option is applicable when Condition evaluates to a Match

Select action:

Continue – continue execution to next condition

Donot_raise_violation – skip execution and don’t raise violation

Raise_violation_and_continue – raise violation and continue execution to next conditions

Raise_violation – raise violation and skip execution

For Scenario 1, no action needs to be taken during a match condition, so select continue as action.

Violation severity:

LOW

MEDIUM

HIGH

CRITICAL

Violation message type:

Default_violation_message

User_defined_violation_message

Derive fix cli commands:

Use_unmatched_block – unmatched config from the block

Use_matched_block – matched config from the block

Use_complete_block – total block config

Select Non-Match Action

Select action:

Continue

Don’t raise violation

Raise violation and continue

Raise violation

For Scenario 1, Action is required when Condition is not matched. Select Raise violation and continue.

Violation severity:

LOW

MEDIUM

HIGH

CRITICAL

Violation message type:

Default_violation_message

User_defined_violation_message

Fix CLI: Provide the CLI Configuration to be used for remediation. Fix CLI can be either provided here or derived.

Option – 1 – Explicit Remediation / Fix CLI

For Scenario 1, Provide “ip domain-name anutacorp.com” in Fix CLI.

Option – 2 – Remediation Commands can be derived from Condition evaluation.

Derive fix cli commands:

Options below:

Use_unmatched_block

Use_matched_block

Use_complete_block

For Scenario 1, Select “Use_unmatched_block”. Since this is non-match Action, unmatched_block will be Condition Details->Value and can be used as Fix CLI.

Scenario 2: NTP Server configuration check

Scenario:

  • All devices in the network should contain the designated ntp server.

  • Remove all other ntp servers

  • In this example

    • Expected ntp-server = 10.0.0.1

Platform:

Cisco IOS-XE

Expected Configuration:

ntp server 10.0.0.1

Fix-CLI Configuration:

ntp server 10.0.0.1

<<Remove Any Other ntp server other than 10.0.0.1>>

This use case uses regular expressions and contains two conditions.

  • Condition-1 – Check for expected config & if not found remediate using Fix CLI.

Fix-cli Configuration :

ntp server 10.0.0.1

  • Condition 2- Check for unwanted ntp-servers and remove them.

Fix-cli Configuration :

no ntp server 10.0.0.2 //Derived

no ntp server 10.0.0.3 //Derived

Steps:

  • Navigate to Resource Manager > Config Compliance -> Policies

  • Click ‘+’ to create new Policy and provide the following information

    • Policy Name – NTP_Common_Peer_Configuration

    • Description

  • Select the Policy and Click ‘+’ to create new Rule

    • Rule Name – Check_NTP_Common_Peer_Configuration

  • Navigate to Config Manager > Config Compliance -> Policies -> Rules

  • Select a Rule & Provide the following information

    • Vendor – Cisco Systems

    • OS type – IOSXE

    • Device Family – ALL

    • Device Type – ALL

    • OS Version – ALL

  • Rule variables are not required for this scenario.

  • Now fill the Conditions and Actions

Condition1

The Verify_NTP condition will check if the NTP server config is present in the device or not.

Here Non-Match Action can be done either using the commands in Fix CLI or using the Derive fix cli commands.

  • Using the Fix CLI user needs to provide the configuration commands manually.

  • Using the Derive Fix CLI Commands user needs to select the use_unmatched_block as shown below.

Here on Match Action it will Continue and on Non-Match Action the Derive fix cli commands uses the use-unmatched-block to remediate the device.

Condition2

Remove_NTP_Extra_Config condition will use the regex to match and capture the extra NTP server ip configured in the device other than the expected ip.

The extra NTP server ip captured will be stored in the backend data structure which is shown in the Test Results tab.

The captured data will be stored in the condition-search-output

On Match Action write a jinja2 configuration template to remove the extra ip’s captured using the above test-result data structure.

Finally if different NTP servers are present on the device, for Non-Compliant device Fix CLI will show up as below

Scenario 3: Interface configuration check

Scenario: All devices in the network should have a specific interface in no shutdown state with auto negotiation enabled. The interface block can have extra configuration commands under it but should be in no shutdown state and auto negotiation enabled.

Platform:

Cisco IOS-XE

Expected Configuration:

interface {{ interface_name }}

no shutdown

negotiation auto

Fix-CLI Configuration:

interface {{ interface_name }}

no shutdown

negotiation auto

This use case is an interface block configuration having rule variables. In this use case as no shutdown is generally not visible on device running config, we will check whether the interface is in shutdown or not. If shutdown it will remediate to no shutdown.

Steps:

  • Navigate to Resource Manager > Config Compliance -> Policies

  • Click ‘+’ to create new Policy and provide the following information

    • Policy Name – Interfaces

    • Description

  • Select the Policy and Click ‘+’ to create new Rule

    • Rule Name – Check_Interfaces

  • Navigate to Config Manager > Config Compliance -> Policies -> Rules

  • Select a Rule & Provide the following information

    • Vendor – Cisco Systems

    • OS type – IOSXE

    • Device Family – ALL

    • Device Type – ALL

    • OS Version – ALL

  • Now create the Rule variables for this scenario.

In the policy we will have a jinja rule variable interface_name. Here Verify_Interfaces condition will check if the interface block config is present in the device or not and under that interface if no shutdown and negotiation auto is present.

For Scenario3 Condition Match Operator as CONTAINS_STRING will check whether the device configuration contains condition value or not. If device configuration contains value, the result will be Compliant, else Non-Compliant.

Here on Non-Match Action select Continue and on Match Action add Fix cli commands to remediate on the device

For Non-Compliant devices Fix CLI will show up later-on as below.

Scenario 4: Enforce VTY Session Timeouts

Scenario: All devices in the network should contain the network admin preferred VTY session-timeout and exec-timeout on all vty lines. If VTY session-timeout and exec-timeout is not configured on the device or mis-match with the network admin preferred timeouts, ATOM CLI compliance can configure the devices with the user preferred VTY timeouts on all the vty lines.

In this example we are considering the VTY session-timeout and exec-timeout as 10 sec.

Platform:

Cisco IOS-XE

Expected Configuration:

line vty (.*)

session-timeout 10

exec-timeout 10 10

Fix-CLI Configuration:

line vty <>

session-timeout 10

exec-timeout 10 10

This use case is using the regex and rule variables and uses jinja2 template for fix-cli configuration.

Steps:

  • Navigate to Resource Manager > Config Compliance -> Policies

  • Click ‘+’ to create new Policy and provide the following information

    • Policy Name – Enforce_VTY_Session_Timeouts

    • Description

  • Select the Policy and Click ‘+’ to create new Rule

    • Rule Name – Check_Enforce_VTY_Session_Timeouts

  • Navigate to Resource Manager > Config Compliance -> Policies -> Rules

  • Select a Rule & Provide the following information

    • Vendor – Cisco Systems

    • OS type – IOSXE

    • Device Family – ALL

    • Device Type – ALL

    • OS Version – ALL

  • Now create the Rule variables for this scenario.

Here created user defined rule variables vty_exec_timeout and vty_session_timeout with default timeout as 10. These rule variables will be used in the condition value.

The verify_session_exec_timeouts condition will check whether the device in the network is configured with user preferred VTY timeouts or not.

Here under Condition Match Criteria the Operator used was CONTAINS_STRING to check for session-timeout and exec-timeout in line vty config.

Here Rule-pass-criteria used All_SubBlocks to check the condition config in all line vty configurations of the device. If all the line vty is matching with the condition then compliant. If any of the line vty is not matching then non-compliant.

The launch Test Config will check values with the Test configuration and gives the Test Result whether compliant or not.

Here the unmatched line vty will be captured and stored in the backend data structure. The captured data structure maximizes the view shown below.

On Match action will continue and on Non-Match Action fix-cli will use the jinja2 template configuration written based on the above captured data structure.

The Non-compliant device fix-cli configurations derived from above jinja2 snippet will look like below.

Scenario 5: Enforce OSPF Router Id as Loopback0

Scenario: All devices in the network should contain the OSPF router-id configured with loopback0 ip address. If OSPF router-id is not configured on the device it will configure the OSPF router-id with the value of loopback0 ip address on the devices.

Platform:

Cisco IOS-XE

Expected Configuration:

interface Loopback0

ip address 45.45.45.5 255.255.255.255

!

router ospf 100

router-id 45.45.45.5

Fix-CLI Configuration:

router ospf 100

router-id 45.45.45.5

This use case is using the regex and contains two conditions.

  • First condition is to capture and store loopback0 ip address. It will not have a fix-cli configuration as the intention of the condition is to capture loopback0 ip address.

Fix-cli Configuration :

<< no fix cli configuration >>

  • Second condition will check whether the OSPF router id is the same as the first condition’s captured loopback0 ip address or not. if not matching then it will configure the OSPF router id with loopback0.

Fix-cli Configuration :

router ospf 100

router-id 45.45.45.5

Steps:

  • Navigate to Resource Manager > Config Compliance -> Policies

  • Click ‘+’ to create new Policy and provide the following information

    • Policy Name – Enforce_OSPF_Router_Id_as_Loopback

    • Description

  • Select the Policy and Click ‘+’ to create new Rule

    • Rule Name – Check_OSPF_Router_Id_Cisco

  • Navigate to Resource Manager > Config Compliance -> Policies -> Rules

  • Select a Rule & Provide the following information

    • Vendor – Cisco Systems

    • OS type – IOSXE

    • Device Family – ALL

    • Device Type – ALL

    • OS Version – ALL

  • Rule variables are not required for this scenario.

  • Now fill the Conditions and Actions

Condition1

Another way of writing the above block configuration using the Block Options Start Expression is shown below.

The first line “interface Loopback0” can be written in the start Expression with regex symbol ^ to indicate the block starts with interface Loopback0. The remaining configuration lines can be written in value.

The launch test config will check the condition value with the Test configuration and will give the Test Result. Here the captured loopback0 ip address will be stored in the backend data structure as shown below.

The Test result in maximize view is shown below. This output will be used in condition2.

For Non-Match Action violation is being raised and fix-cli is having no commands as this condition is to capture the loopback0 ip.

Condition2

The Verify_OSPF_Router_Id_as_Loopback condition will check whether the OSPF router id is the same as the first condtion’s captured loopback0 ip address or not. if not matching then in fix-cli it will configure the OSPF router id with loopback0.

On Match Action it will continue. On Non-Match Action it will use the jinja2 template configuration in fix-cli to configure the OSPF router id with loopback0 ip.

The Non-compliant device fix-cli configurations from the jinja2 template configuration is given below.

Scenario 6: BGP TTL Hop-count

Scenario: All devices in the network should contain the network admin preferred BGP ttl-security hops. If hops is not configured on the device or mis-match with the network admin preferred ttl-security hops, ATOM CLI compliance can configure the devices with the user preferred hops.

In this example we are considering the ttl-security hops as 5.

Platform:

Cisco IOS-XE

Expected Configuration:

router bgp 65535

bgp log-neighbor-changes

neighbor 2.3.2.6 ttl-security hops 5

Fix-CLI Configuration:

router bgp 65535

bgp log-neighbor-changes

neighbor 2.3.2.6 ttl-security hops 5

This use case is using the regex and rule variables and contains two conditions.

  • First condition is to match the block. It will not have a fix-cli configuration as the intention of the condition is to match the block.

Fix-cli Configuration :

<< no fix cli configuration >>

  • Second condition will check whether the BGP ttl-security hops is in the first condition’s matched block or not. if not matching in the block then it will configure the BGP hops.

Fix-cli Configuration :

router bgp 65535

neighbor 2.3.2.6 ttl-security hops 5

Steps:

  • Navigate to Resource Manager > Config Compliance -> Policies

  • Click ‘+’ to create new Policy and provide the following information

    • Policy Name – BGP_TTL_Hop_Count

    • Description

  • Select the Policy and Click ‘+’ to create new Rule

    • Rule Name – Check_BGP_TTL

  • Navigate to Resource Manager > Config Compliance -> Policies -> Rules

  • Select a Rule & Provide the following information

    • Vendor – Cisco Systems

    • OS type – IOSXE

    • Device Family – ALL

    • Device Type – ALL

    • OS Version – ALL

  • Now create the Rule variables for this scenario.

Condition1

The first line “router bgp (.*)” to be written in the start Expression with regex to indicate the block starts with router bgp. The remaining configuration lines can be written in value.

On Match Action execution continues to the next condition. On Non-Match Action it will raise a violation and continue next condition. The “Fix-CLI” for the condition was written based on the test results obtained from “Launch Test Config”.

When the start Expression is used the regex captured data will be stored in “condition_contents” of “aggregated-condition-ouput” in test results.

Condition2

The Verify_BGP_TTL condition will check whether the router bgp block config matched in the previous condition has the ttl-security hops or not. if not matching then in fix-cli it will configure the ttl-security hops.

This condition uses the condition scope details as Previously_Matched_Blocks to check on previous condition matched block.

YANG Compliance

Note: In order to use Yang Compliance make sure that the config-snapshot is provided in the Credential profile, which lets ATOM to parse the configuration and store it. For more information on Credential profile please refer to credential profile section in ATOM User guide.

For Yang based Configuration Compliance, make sure to select the option of Inventory_Data for Condition scope during Compliance Policy creation. This gives two ways of defining the Condition Match Criteria

  • Xpath Expressions

  • XML Template Payload

Policy creation with Xpath Expressions

  • Within Condition Match Criteria select “Matches_the_Xpath_Expression” /”Doesn’t_Matches_the_Xpath_Expression” option for Inventory Operator field

  • The Fix Mutation Payload is in Netconf xml RPC format written using the XML template details for the yang parsed entities.

Navigate to Resource Manager > Config Compliance > Policy > + (Add Policies)

Few examples

Scenario 7: IP Domain Name

In this example we are looking for the domain name as anutacorp.com across all devices in the lab using X-path expression.

Xpath Expression:

Cisco-IOS-XR-native:native/ip/domain/name=`anutacorp.com’

Fix Mutation Payload:

<config>

<devices xmlns=”https://anutanetworks.com/controller”>

<device>

<id>{{ inputDeviceId }}</id>

<native xmlns=”http://cisco.com/ns/yang/Cisco-IOS-XE-native”>

<ip>

<domain nc:operation=’create’>

<name>anutacorp.com</name>

</domain>

</ip>

</native>

</device>

</devices>

</config>

Defining Xpath Expression

Defining Fix Payload

Fix Configuration Display in Remediation

Scenario 8: IP Name-server check

Xpath Expression:

Cisco-IOS-XE-native:native/ip/name-server/no-vrf=’192.168.20.1′ and Cisco-IOS-XE-native:native/ip/name-server/no-vrf=’192.168.20.2′

Fix Mutation Payload:

<config>

<devices xmlns=”https://anutanetworks.com/controller”>

<device>

<id>{{ inputDeviceId }}</id>

<native xmlns=”http://cisco.com/ns/yang/Cisco-IOS-XE-native”>

<ip>

<name-server nc:operation=’create’>

<no-vrf>192.168.20.1</no-vrf>

<no-vrf>192.168.20.2</no-vrf>

</name-server>

</ip>

</native>

</device>

</devices>

</config>

Defining Xpath Expression

Defining Fix Payload

Scenario 9 : NTP server Check

Xpath Expression:

Cisco-IOS-XE-native:native/ntp/Cisco-IOS-XE-ntp:server/server-list/ip-address=’192.168.20.3′ and Cisco-IOS-XE-native:native/ntp/Cisco-IOS-XE-ntp:server/server-list/ip-address=’192.168.20.4′ and Cisco-IOS-XE-native:native/ntp/Cisco-IOS-XE-ntp:server/server-list/ip-address=’192.168.20.5′ and Cisco-IOS-XE-native:native/ntp/Cisco-IOS-XE-ntp:server/server-list/ip-address=’192.168.20.6′

Fix Mutation Payload:

<config>

<devices xmlns=”https://anutanetworks.com/controller”>

<device>

<id>{{ inputDeviceId }}</id>

<native xmlns=”http://cisco.com/ns/yang/Cisco-IOS-XE-native”>

<ntp>

<server nc:operation=”create”>

<server-list>

<ip-address>192.168.20.3</ip-address>

</server-list>

<server-list>

<ip-address>192.168.20.4</ip-address>

</server-list>

<server-list>

<ip-address>192.168.20.5</ip-address>

</server-list>

<server-list>

<ip-address>192.168.20.6</ip-address>

</server-list>

</server>

</ntp>

</native>

</device>

</devices>

</config>

Defining Xpath Expression

Defining Fix Payload

Scenario 10 : Interface Check with rule_variable

Xpath Expression:

Cisco-IOS-XE-native:native/interface/Loopback/name=’0′ and

Cisco-IOS-XE-native:native/interface/Loopback[name=0]/ip/address/primary/address='{{ lo0_ipv4addr }}’ and

Cisco-IOS-XE-native:native/interface/Loopback[name=0]/ip/address/primary/mask=’255.255.255.255′ and

Cisco-IOS-XE-native:native/interface/Loopback[name=0]/ipv6/address/prefix-list/prefix='{{ lo0_ipv6addr }}’

Fix Mutation Payload:

<config>

<devices xmlns=”https://anutanetworks.com/controller”>

<device>

<id>{{ inputDeviceId }}</id>

<native xmlns=”http://cisco.com/ns/yang/Cisco-IOS-XE-native”>

<interface>

<Loopback nc:operation=”create”>

<ip>

<address>

<primary>

<address>10.100.99.98</address>

<mask>255.255.255.255</mask>

</primary>

</address>

</ip>

<ipv6>

<address>

<prefix-list>

<prefix>2605:30C0::3B/128</prefix>

</prefix-list>

</address>

</ipv6>

<name>0</name>

</Loopback>

</interface>

</native>

</device>

</devices>

</config>

Defining Rule Variables

Defining Xpath Expression

Defining Fix Payload

Scenario 11 : VRF Check with rule_variable

Xpath Expression:

Cisco-IOS-XE-native:native/vrf/definition/name=’LON2001′ and

Cisco-IOS-XE-native:native/vrf/definition/rd='{{ rd_2001 }}’ and

Cisco-IOS-XE-native:native/vrf/definition/address-family/ipv4/mdt/default/address=239.232.0.1′ and

Cisco-IOS-XE-native:native/vrf/definition/address-family/ipv4/mdt/data/multicast/address=’239.232.1.0′ and

Cisco-IOS-XE-native:native/vrf/definition/address-family/ipv4/mdt/data/multicast/wildcard=’0.0.0.255′ and

Cisco-IOS-XE-native:native/vrf/definition/address-family/ipv4/route-target/export/asn-ip=’2:2001′ and

Cisco-IOS-XE-native:native/vrf/definition/address-family/ipv4/route-target/import/asn-ip=’2:2001′

Fix Mutation Payload:

<config>

<devices xmlns=”https://anutanetworks.com/controller”>

<device>

<id>{{ inputDeviceId }}</id>

<native xmlns=”http://cisco.com/ns/yang/Cisco-IOS-XE-native”>

<vrf>

<definition nc:operation=”create”>

<rd>2:2001</rd>

<name>LON2001</name>

<address-family>

<ipv4>

<route-target>

<export>

<asn-ip>2:2001</asn-ip>

</export>

<import>

<asn-ip>2:2001</asn-ip>

</import>

</route-target>

<mdt>

<default>

<address>239.232.0.1</address>

</default>

<data>

<multicast>

<address>239.232.1.0</address>

<wildcard>0.0.0.255</wildcard>

</multicast>

</data>

</mdt>

</ipv4>

</address-family>

</definition>

</vrf>

</native>

</device>

</devices>

</config>

Defining Rule Variables

Defining Xpath Expression

Defining Fix Payload

  • Snmp-string with rule_variable : basicDeviceConfigs:snmp/snmp-community-list/snmp-string = “{{ community }}”

  • Logical A|B : starts-with(vendor-string,’Cisco’) and contains(device-family-string,’Cisco 800′)

  • Logical A&B : starts-with(vendor-string,’Cisco’) or contains(device-family-string,’Cisco 800′)

  • Logical A&(B|C) : contains(vendor-string,’Cisco Systems’) and (contains(device-family-string,’Cisco 800′) or contains(device-family-string,’Cisco CSR 1000V’))

  • Logical A&(B|(C&D)) : contains(interface:interfaces/interface/if-name,’GigabitEthernet1′) and (contains(os-version,’15.6(1)S’) or (contains(vendor-string,’Cisco Systems’) and contains(device-family-string,’Cisco CSR 1000V’)))</