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’)))

  • Logical not(A&B) : not(contains(basicDeviceConfigs:local-credentials/local-credential/name , ‘admin’) and contains(basicDeviceConfigs:local-credentials/local-credential/name , ‘cisco’))

How to derive the X-path expressions

There can be two ways by which you can derive the X-path expressions

  • Navigate to the Device profile page to get the X-path Expression Details for the yang parsed entities

Resource Manager → Devices → Select a Device → Configuration → Config Data → Entities → Select Entity

For Example: If we want to write xpath expression for VRF name to match as “anuta”, then below is how condition needs to be written

l3features:vrfs/vrf/name = ‘anuta’

l3features:vrfs/vrf : This is x-path derived based on model under device

name : Attribute of vrf name.

  • Navigate to Schema Browser to see all yang models under path /controller:devices/device

Policy creation with XML Template Payload

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

  • The Fix Mutation Payload is a Jinja2 template configuration in Netconf xml RPC format written using the unmatched content from the test results tab.

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

Few examples

Scenario 12 : IP Domain name check

Template Payload:

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

<ip>

<domain>

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

</domain>

</ip>

</native>

Fix Mutation Payload :

<config>

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

{% for content in unmatched -%}

{% for device in content[“controller:devices”][“device”] -%}

<device>

<id>{{ device[“id”] }}</id>

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

<ip>

<domain nc:operation=’create’>

<name>{{ device[‘Cisco-IOS-XE-native:native’][‘ip’][‘domain’][‘name’] }}</name>

</domain>

</ip>

</native>

</device>

{%- endfor %}

{%- endfor %}

</devices>

</config>

Defining Template Payload

Here the matched and unmatched data will be stored in the backend data structure which is shown in the Test Results tab. The matched data will be stored in the condition-search-output. The unmatched data will be stored in unmatched-content.

The Fix Mutation Payload is a Jinja2 template configuration in Netconf xml RPC format written using the unmatched content from the test results tab.

Defining Fix Payload

Fix Configuration Display in Remediation

Scenario 13 : IP Name Server check

Template Payload:

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

<ip>

<name-server>

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

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

</name-server>

</ip>

</native>

Fix Mutation Payload :

<config>

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

{% for content in unmatched -%}

{% for device in content[“controller:devices”][“device”] -%}

<device>

<id>{{ device[“id”] }}</id>

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

<ip>

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

{% for name_server in device[‘Cisco-IOS-XE-native:native’][‘ip’][‘name-server’][‘no-vrf’] -%}

<no-vrf>{{ name_server }}</no-vrf>

{%- endfor %}

</name-server>

</ip>

</native>

</device>

{%- endfor %}

{%- endfor %}

</devices>

</config>

Defining Fix Payload

Fix Configuration Display in Remediation

Scenario 14 : Interface check

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>

Fix Mutation Payload :

<config>

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

{% for content in unmatched -%}

{% for device in content[“controller:devices”][“device”] -%}

<device>

<id>{{ device[“id”] }}</id>

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

<interface>

{% for loopback in device[‘Cisco-IOS-XE-native:native’][‘interface’][‘Loopback’] -%}

<Loopback nc:operation=”create”>

{% if loopback[‘ip’] -%}

<ip>

<address>

<primary>

<address>{{ loopback[‘ip’][‘address’][‘primary’][‘address’] }}</address>

<mask>{{ loopback[‘ip’][‘address’][‘primary’][‘mask’] }}</mask>

</primary>

</address>

</ip>

{%- endif %}

{% if loopback[‘ipv6’] -%}

<ipv6>

<address>

<prefix-list>

{% for prefix in loopback[‘ipv6’][‘address’][‘prefix-list’] -%}

<prefix>{{ prefix[‘prefix’] }}</prefix>

{%- endfor %}

</prefix-list>

</address>

</ipv6>

{%- endif %}

<name>{{ loopback[‘name’] }}</name>

</Loopback>

{%- endfor %}

</interface>

</native>

</device>

{%- endfor %}

{%- endfor %}

</devices>

</config>

Defining Template Payload

Defining Template Payload

Scenario 15 : VRF check

Template Payload:

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

<vrf>

<definition>

<address-family>

<ipv4>

<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>

<route-target>

<export>

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

</export>

<import>

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

</import>

</route-target>

</ipv4>

</address-family>

<name>LON2001</name>

<rd>2:2001</rd>

</definition>

</vrf>

</native>

Fix Mutation Payload :

<config>

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

{% for content in unmatched -%}

{% for device in content[“controller:devices”][“device”] –%}

<device>

<id>{{ device[“id”] }}</id>

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

<vrf>

{% for vrf_def in device[‘Cisco-IOS-XE-native:native’][‘vrf’][‘definition’] -%}

{% if vrf_def[‘name’] == ‘LON2001’ -%}

<definition nc:operation=”create”>

{% if vrf_def[‘rd’] -%}

<rd>{{ rd_2001 }}</rd>

{%- endif %}

<name>{{ vrf_def[‘name’] }}</name>

{% if vrf_def[‘address-family’] -%}

<address-family>

<ipv4>

{% if vrf_def[‘address-family’][‘ipv4’][‘route-target’] -%}

<route-target>

{% for export in vrf_def[‘address-family’][‘ipv4’][‘route-target’][‘export’] -%}

<export>

<asn-ip>{{ export[‘asn-ip’] }}</asn-ip>

</export>

{%- endfor %}

{% for import in vrf_def[‘address-family’][‘ipv4’][‘route-target’][‘import’] -%}

<import>

<asn-ip>{{ import[‘asn-ip’] }}</asn-ip>

</import>

{%- endfor %}

</route-target>

{%- endif %}

{% if vrf_def[‘address-family’][‘ipv4’][‘import’] -%}

<import>

<map>{{ vrf_def[‘address-family’][‘ipv4’][‘import’][‘map’] }}</map>

</import>

{%- endif %}

{% if vrf_def[‘address-family’][‘ipv4’][‘mdt’] -%}

<mdt>

{% if vrf_def[‘address-family’][‘ipv4’][‘mdt’][‘default’] -%}

<default>

<address>{{ vrf_def[‘address-family’][‘ipv4’][‘mdt’][‘default’][‘address’] }}</address>

</default>

{%- endif %}

{% if vrf_def[‘address-family’][‘ipv4′][‘mdt’][‘data’] -%}

<data>

{% for multicast in vrf_def[‘address-family’][‘ipv4’][‘mdt’][‘data’][‘multicast’] -%}

<multicast>

<address>{{ multicast[‘address’] }}</address>

<wildcard>{{ multicast[‘wildcard’] }}</wildcard>

</multicast>

{%- endfor %}

</data>

{%- endif %}

</mdt>

{%- endif %}

</ipv4>

</address-family>

{%- endif %}

</definition>

{%- endif %}

{%- endfor %}

</vrf>

</native>

</device>

{%- endfor %}

{%- endfor %}

</devices>

</config>

Defining Template Payload

Defining Fix Payload

How to derive the XML Template payload

  • Navigate to the Device profile page and export the XML template details for the yang parsed entities

Resource Manager → Devices → Select a Device → Configuration →Config Data → Entities → Select Abstract entity → Use Download button to export/copy the XML payload

Example : Let’s derive domain-name XML Template payload

Navigate to Devices → select a device→ configuration -> Config Data → Entities → dns-server → Export XML payload using download button.

Profiles

A profile allows one or more Policies to be grouped and executed on one or more devices either on-demand or as per Schedule. Profile execution results in a per-device compliance report included in the execution.

Steps:

a. Navigate to Resource Manager > Config Compliance -> Profiles

  • Select “+” to Create a Profile

  • ATOM opens up a new wizard and displays 2 sections.

    • Policies – Select one/more policies

    • Devices & Schedule – Select one/more devices or Device groups

b. Create profile by providing name, description and select policy which was created previously IP_Domain_Name.

c. Navigate to the next tab, Select devices and schedule. We can select either device(s) from Devices or Device Groups tab

d. After device(s) are selected, choose if the compliance checks need to be run against an archived config or current running-configuration of the device. By default Latest From Config Archive is selected.

Schedule: The profile job can be scheduled in Hours or Minutes. Alternatively, a job can be started right away by enabling Start now option.

Or the profile job can triggered at a later point of time using run job icon on the profiles view

Report

Navigate to Resource Manager > Config Compliance -> reports

Compliance report is generated upon completion of Profile run. For each device, the report lists the compliant and non-compliant policies, rules and conditions .

After profile job is run, audit details can be viewed in Report View

Since IP_Domain_Name policy has a condition named Verify_IP_Domain_name, where it didn’t meet the required criteria. The condition is marked as Non_compliant.

Severity: Severity the condition where the condition Match Action or Non Match Action is of type Raise_violation or Raise_violation_and_continue.

Upon checking the row you can see the expected and the fix commands for that condition along with action-severity, action-type and other metadata related to device & condition.

The reports section also facilitates users to filter the results of what user is interested in. The dropdown will display all the possible values for the filters. Users can try out any combination and see the results. By clicking on the apply button.

Inorder to revert the filter that are applied you can click on the clear button.

Tired of filtering the results every time for more frequent data. We got you covered ATOM provides an option to save the filter that you applied again with a single click.

  • Select filters that you are interested in and click on the save button

  • This will show a new pop-up box prompting for the filter name and the dashboard where the user wants to pin it.

  • Click on the save and apply button will save this filter and the resulting data will be populated.

We can pin to the dashboard, upon saving the filter using dropdown.we are able to see the filter under the dashboard.

From where I can access these saved filters?

  • They are easily accessible. All the filters that are saved are listed under the dropdown on the top.

  • Click on the interested filter and you see the data getting filtered.

ATOM also provides an option to view the statistics based on Pivot by Device, Device Type, Policy, Location and Device Group.

Users can opt for any view that they are interested in.

Pivot by device

Severity: The aggregated severity of that particular device.

Compliant Policies: The number of policies that are compliant against the device.

Non-Compliant Policies: The number of policies that are non-compliant against the device.

Compliant Conditions: The number of Conditions that are complaint against the device

Non-Compliant Conditions: The number of Condition that are non-compliant against the device

Device ID: Displays all Device Ids for which compliance has run. This is the context column for pivot by device.

Execution status: Based on execution on device it is updated as Successful, errors,stale config, empty config, config pull failed, offline device.

Hostname: Hostname of a device is displayed here.

Device compliance status: Based on compliance run, for a device it is updated as Compliant, non-compliant, Not applicable.

Device Type: The device type of a device is displayed(like cisco csr 1000v , cisco 891).

Vendor: vendors of device are displayed here (like cisco, juniper)

On clicking on the Device ID, Device ID filter gets applied and the user will be navigated to CRV.

Pivot By Policy

Severity: The aggregated severity of that particular policy.

Compliant Devices: The number of devices that are compliant against the policy.

Non-Compliant Devices: The number of devices that are non-compliant against the policy.

Non-Compliant Conditions: The number of conditions that are non-compliant against the policy.

Policy Name: Displays all policies for which compliance is run. This is the context column for pivot by policy.

Compliance status: Based on policy, it is updated as compliant or non-compliant.

On clicking on the policy, the policy filter gets applied and the user will be navigated to CRV.

Pivot By Device Type:

Severity:The aggregated severity of that particular device type

Device type: Displays all device types available in compliance. This is the context column for pivot by device type.

Vendor: Displays the vendors available in compliance .

Compliant Device: The number of devices that are compliant against the device type

Non-compliant device:The number of devices that are non-compliant against the device type.

Compliant policies:The number of policies that are compliant against the device type

Non-Compliant policies:The number of policies that are non-compliant against the device type

Compliant Condition:The number of conditions that are compliant against the device type.

Non-compliant Condition:The number of conditions that are non-compliant against the device type.

Click on device type> Cisco CSR 1000v here

On clicking on the Device Type, Device Type filter gets applied and the user will be navigated to CRV.

Pivot By Location:

Severity: The aggregated severity of that particular locations

Location Name: Displays all available locations over which compliance is run.This is the context column for pivot by location.

Compliant Devices: The number of devices that are compliant against locations

Non-Compliant Devices: The number of devices that are non-compliant against locations

Compliant Policies: The number of policies that are compliant against locations

Non-compliant Policies: The number of policies that are non-compliant against locations

Compliant Condition: The number of conditions that are compliant against locations

Non-Compliant Condition: The number of conditions that are non- compliant against locations

Click on any of location name

on clicking on the location name, the location filter gets applied and the user will be navigated to CRV.

Adding the same device in multiple resource pools and each RP associated with a different location, all locations will be listed in pivot views.

Adding the same device in two resource pools and associate one RP with location and another RP with no location, only location associated with RP will be listed.

Pivot By Device Group:

Severity: The aggregated severity of that particular Device group

Device Group: Displays all available device groups over which compliance is run. This is the context column for pivot by device group.

Devices in group: This gives the number of devices in a group

Compliant Devices: The number of devices that are compliant against device groups

Non-Compliant Devices: The number of devices that are non-compliant against device groups

Compliant Policies: The number of policies that are compliant against device groups

Non-compliant Policies: The number of policies that are non-compliant against device groups

Compliant Condition: The number of conditions that are compliant against device groups

Non-Compliant Condition: The number of conditions that are non- compliant against device groups.

Click on any of device groups

On clicking on the device group, the device group filter gets applied and the user will be navigated to CRV.

pivot view :

  • Single pivot view can be selected.(no multi pivot view selection)

  • Upon selecting a pivot view, further filters like device id, device type, vendor, compliance status,condition status,location,resource pool, device groups,severity,execution status,policy, rule name, condition name can be applied.

  • Just with the pivot views, a filter can’t be saved, Based on further filters applied, a filter can be saved. The saved filter can be deleted.

  • Bulk delete is not supported in pivot views

  • Remediation is not supported

  • Sorting is not supported on any column in pivot view.

  • Searching is not supported in pivot view.

  • The counts on top are related to the non- pivot views and labels are from condition status

  • Export: based on pivot views, the records can be exported.

CRV(conditional report view) :

  • The available columns are: Hostname, Severity, Execution, Device Type, Device compliance status, condition status, Device id, Vendor, Policy name, Rulename, Condition name, Configuration retrieved at, Expected pattern, Enforcement time.

  • The data can be filtered by applying filters on device id, device type, vendor, compliance status,condition-status,location,resourcepool, device groups,severity,execution status,policy, rule name and condition name.

  • Time based filtering : For timing based, user can use value and units(Days,weeks,months, hours, minutes) fields.

Date wise filter: User can choose the date from the calendar symbol and click on ‘apply’ in the calendar.

  • Count band – Represents counts for skipped, compliant, and non compliant conditions

  • Skipped conditions – Platform mismatch and Execution Status (Stale Config, Empty Config, Erros, Config Pull Failed, Offline Device) fall into this category.

  • Complaint conditions – Based on conditions meeting the criteria

  • Non- compliant conditions -Based on conditions meeting the criteria and violations chosen

  • Multi-selection on filters is supported – More than one entry for a given filter can be selected.

  • Sorting is enabled on all columns.

  • Searching is enabled for all columns.

  • The record details are listed when the checkbox for a given entry is selected. Device ID, Device host name, Device type, Vendor, Device compliance status, Execution status, Config time, Policy name, Rule name, Condition ID, Condition status, Expected pattern, Action Details, Remediation commands( if it’s non-compliant) are shown as part of details.

Remediation :

Navigate to Resource Manager > Config Compliance -> Remediation

Fix CLI Action will generate the remediation CLI to be applied for each non-compliant device. Users can schedule remediation on one or more devices or execute it right away. For each device selected, ATOM will push remediation CLI to the device.

  • Select a Report and click on the highlighted arrow for navigating to the Remediation screen.

Only if it is non- compliant, user will be taken to the remediation screen.

b. Fix Violations by providing a Job name and verify rule-input values and fix CLI commands under Fix Configurations. Click on the tick button to complete fix-job.

c. Fix Job can be scheduled using Schedule option or can be initiated immediately by enabling Start now. And click on the Tick button to initiate fix-job.

  • Fix job can be initiated from the Remediation tab as well at a later point of time.

d. After remediation, trigger profile job and validate the report to see if the device came back as a complaint.

e. Below we can see the device is now back to complaint after fixing violations.

Remediation is not supported when the user is in pivot view.

Bulk delete:

Navigate to Resource Manager > Config Compliance -> reports(CRV)

In order to delete the records at shot bulk delete is used.

Based on filters applied, records can be deleted

  • If the filter is on Device(device id/ device group/ device Type) And invoke Bulk delete, all the records related to devices are deleted.

  • If the filter is on Policy and Bulk delete is invoked,all the records Related to policies across all devices are deleted.(columns like Policy, rule, condition, expected pattern, enforcement time- empty)

  • If the filter is on device + policy and bulk delete is invoked, all the records related to policies across all devices are deleted but Device is not deleted.(columns like Policy, rule, condition, expected pattern, enforcement time- empty)

  • If the filter is policy+rule+condition, where there are many rules or many conditions, records are deleted at policy level only.(records having the selected policies are deleted irrespective of rule or condition)

Purge compliance history:

In order to delete history details, we can use purge compliance history under Monitoring–> jobs→ Maintenance→ purge compliance history..

Say, the threshold is 60 and it is set for days. When this job is run, it deletes all the record history details that are older than 60 days.

It can be set in hours too.

Export:

Navigate to Resource Manager > Config Compliance -> reports(CRV/Pivot)

Using export will get report for all the records at one shot

Upon applying filters and the user does export, then the user can get only those records.

Without applying filters, if the user does export, all records are exported.

Provide a name to export file to be saved

Export file will be saved in the archive tab.

Archive:

Navigate to Resource Manager > Config Compliance -> Archive

From here we can download the report and delete as well. File download format is CSV.

The headers of the downloaded csv report is according to the filter applied.

If pivot views are applied, the headers are according to it.

Dashboard

There are 5 Dashboards which gives a quick information about compliance status

  • Config compliance -devices: Representing the number of devices participated in compliance v/s all the available devices in ATOM.

  • Config compliance- execution status: A pie chart representing the percentage of execution status in terms of successful, config_empty, config_stale, errors, config_pull_failed, offline_device.

  • Config compliance- compliance status: A pie chart representing the percentage of compliance in terms of Complaint, Non- compliant, Not_applicable.

  • Compliance status by group: A bar graph representing compliance status such as complaint, non-compliant, not_applicable for each and every device group on which compliance profile jobs are run.

  • Execution status by device group: A bar graph representing execution status such as config pull failed, not applicable, config_stale, errors, offline device, successful, config_empty for each and every device group on which compliance profile jobs are run.

Upon clicking on any of the dashboards, the user is navigated to CRV.

Upon clicking on any of the dashboards, the user is navigated to CRV.

FAQ’s

  • We have a multi-vendor network, can ATOM help ensure compliance in my environment?

ATOM supports compliance management for Cisco, Juniper and Fortigate at this point in time.

  • We want to standardize the network configs even before introducing automation, can ATOM help?

The standard configurations can be defined explicitly in ATOM’s compliance framework. ATOM will perform compliance checks against the network and perform remediation in case of non-compliance to standardize the network configurations.

  • We already have a platform which checks for compliance, but the remediation is manual, can ATOM help ?

Yes, ATOM is capable of performing remediation on non-compliant devices. The Fix-CLI or derived CLIs can be scheduled or executed immediately to fix all non-compliance issues in the network.

  • Can we schedule compliance checks periodically using ATOM ?

Yes, the profiling section in ATOM’s compliance framework supports scheduling of compliance checks against a device or a group of devices

  • Can ATOM’s compliance help in achieving regulatory compliance ?

Yes, based on the policies that regulatory authorities specify, ATOM’s compliance management framework can be configured to meet these requirements.

  • We have multiple checks that need to be run on the network, can ATOM help handle this scenario ?

ATOM’s profiling section supports grouping of multiple policies

Appendix

  • Writing Jinja template configurations based on Test Result output

Below is a sample output from the test result obtained in Launching Test Config. This helps writing jinja2 templates as required in use case requirements.

{

“compliance-policies”: {

“highest-severity”: “”,

“rule-violation-count”: 0,

“compliance-status”: “compliant”,

“compliant-rules-output”: {

“violated-conditions”: “”,

“device-compliance-condition-output”: {

“block-start-unmatched-content”: “<![CDATA[]]>”,

“block-start-condition-search-output”: “<![CDATA[{

“block_start_matched_contents” : []

}]]>”,

“condition-search-output”: “<![CDATA[{

“matched_contents” : [ {

“groups” : [ {

“index” : 1,

“grep_content” : “1.1.1.1″,

“grep_group” : 1

} ]

}, {

“groups” : [ {

“index” : 1,

“grep_content” : “2.2.2.2”,

“grep_group” : 1

} ]

} ]

}]]>”,

“total-block-count”: 2,

“aggregated-condition-ouput”: “<![CDATA[{

“condition_contents” : [ {

“condition_id” : null,

“block_start_matched_content” : null,

“block_start_unmatched_content” : null,

“unmatched_content” : null,

“matched_content” : null

} ]

}]]>”,

“template-substituted-content”: “<![CDATA[ntp server (?!10.0.0.1)(d+.d+.d+.d+)]]>”,

“block-unmatch-count”: 0,

“cli-match-output”: “<![CDATA[ntp server 1.1.1.1

ntp server 2.2.2.2

]]>”,

“condition-status”: true,

“unmatched-content”: “<![CDATA[]]>”,

“id”: “Remove_NTP_Extra_Config”,

“block-match-count”: 2,

“cli-unmatch-output”: “<![CDATA[]]>”

},

“name”: “test-condition”,

“failed-conditions”: “”

}

}

}

Keys

Condition value

Jinja2 template

matched_contents – when matches with regex in the condition value with the test configuration.

ntp server (?!10.0.0.1)(d+.d+.d+.d+)

{% for content in matched_contents -%}

{% for group in content[“groups”] -%}

no ntp server {{ group[“grep_content”] }}

{%- endfor %}

{% endfor %}

unmatched_contents – when matches with the regex and does not match with the block config in the condition value with the test configuration.

line vty (.*)

session-timeout {{ session_timeout }}

exec-timeout {{ exec_timeout }} 0

{% for content in unmatched_contents %}

{% for group in content[“groups”] %}

line vty {{ group[“grep_content”] }}

session-timeout {{ session_timeout }}

exec-timeout {{ exec_timeout }} 0

exit

{% endfor %}

{% endfor %}

condition_contents – condition1 captured data will be accessible to condition2 using condition_contents.

condition1:

interface Loopback0

ip address (d+.d+.d+.d+) (d+.d+.d+.d+)

condition2:

router ospf (.*)

router-id {{ condition_contents[0][“matched_content”][“matched_contents”][0][“groups”][0][“grep_content”] }}

{% for content in unmatched_contents %}

{% for group in content[“groups”] %}

router ospf {{ group[“grep_content”] }}

router-id {{ condition_contents[0][“matched_content”][“matched_contents”][0][“groups”][0][“grep_content”] }}

exit

{% endfor %}

{% endfor %}