Once the DANZ Monitoring Fabric (DMF) Controllers are up and running, log in to the DMF Controller using the VM local console or SSH.

Enter sub-modes from config mode to provision specific monitoring fabric objects. For example, the switch command changes the CLI prompt to (config-switch)# to configure the switch identified by the switch DPID or alias.

After logging in, the CLI appears in the login mode where the default prompt is the system name followed by a greater than sign (>), as in the following example.

controller-1>

controller-1> enable
controller-1#

controller-1> enable
controller-1# configure
controller-1(config)#

controller-1(config)# switch filter-1
controller-1(config-switch)#

controller-1(config)# end
controller1#

To view a list of the commands available from the current mode or submode, enter the help command. To view detailed online help for the command, enter the help command followed by the command name.

To display the options available for a command or keyword, enter the command or keyword followed by a question mark (?).

To connect to the DANZ Monitoring Fabric GUI, use the IP address assigned to the DMF controller. The following figure shows a browser connecting to the DANZ Monitoring Fabric GUI using HTTPS at the IP address 192.168.17.233.

After accepting the prompts, the system displays the login prompt.

Use the admin username and password configured for DANZ Monitoring Fabric during installation or any user account and password configured with administrator privileges. A user in the read-only group will have access to options for monitoring fabric configuration and activity but cannot change the configuration.

The main menu for the DANZ Monitoring Fabric GUI appears in the following figure.

controller-1> enable
controller-1# config
controller-1(config)# controller
controller-1(config-controller)# virtual-ip 10.106.8.4
controller-1(config-controller)#

Verify the VIP by entering the show controller command.

controller-1(config)# show controller
Cluster Name : dmf-cluster
Cluster Virtual IP : 10.106.8.4
Redundancy Status : redundant
Last Role Change Time : 2020-11-19 18:12:49.699000 UTC
Failover Reason : Changed connection state: cluster configuration changed
Cluster Uptime : 3 weeks, 1 day
# IP@StateUptime
- |---------- |- |------- |-------------------- |
1 10.106.8.3 standby11 hours, 24 minutes
2 10.106.8.2*active 11 hourmvs, 29 minutes
controller-1(config)#

To view or change the current time zone on the DMF Controller, complete the following steps.

GUI Procedure

Select Maintenance > Clock from the main menu.

The clock displays the time on the system used to access the DMF GUI and the Controller, information about the currently configured NTP server, and provides an option for forcing immediate NTP synchronization with the NTP server, which in DMF 8.0.0 and later, runs on the DMF Master Controller.

CLI Procedure

[no] clock timezone <time-zone>

Replace time-zone with the specific string for the desired time zone. To see a list of supported values, press Tab after the clock set command. Certain values, such as America/, are followed by a slash (/). These values must be followed by a keyword for the specific time zone. View the supported time zones by pressing Tab again after selecting the first keyword.

controller-1( (config)# ntp time-zone America/Los_Angeles
Warning: Active REST API sessions will not be informed of updates to time-zone.
Warning: Please logout and login to any other active CLI sessions to
Warning: update the time-zone for those sessions.
controller-1( (config)#

controller-1(config-controller)# no clock timezone

To view the overall controller status, click the DANZ Monitoring Fabric (DMF) logo in the left corner of the GUI Main menu. The system displays the DMF GUI landing page, shown in the following figure.

The number of warnings and errors are listed and highlighted in yellow in the upper left corner of the page. This page also provides configuration options that let you view and change fabric-wide settings.

CLI Procedure

controller-1(config)# show controller details
Cluster Name : dmf-cluster
Cluster UID : 8ef968f80bd72d20d30df3bc4cb6b271a44de970
Cluster Virtual IP : 10.106.8.4
Redundancy Status : redundant
Redundancy Description : Cluster is Redundant
Last Role Change Time : 2020-11-19 18:12:49.699000 UTC
Cluster Uptime : 3 weeks, 1 day
# IP@Node IdDomain IdStateStatus Uptime
- |---------- |- |------- |--------- |------- |--------- |-------------------- |
1 10.106.8.3 5784 1standbyconnected11 hours, 6 minutes
2 10.106.8.2*253771active connected11 hours, 11 minutes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Failover History ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# New ActiveTime completedNode Reason Description
- |---------- |------------------------------ |----- |--------------------- |---------------------------- |
1 25377 2020-11-19 18:12:38.299000 UTC25377 cluster-config-changeChanged connection state:
cluster configuration changed
controller-1(config)#

Take:

curl -H -g -k "Cookie: session_cookie=<session-cookie>" https://<Controller IP>:8443/api/v1/rpc/
controller/snapshot/take -d '{"name": "snapshot://testsnap"}'

Fetch:

curl -g -k -H "Cookie: session_cookie=<session-cookie>" https://<Controller IP>:8443/api/v1/rpc/
controller/snapshot/fetch -d '{"source-url": "https://...", "name": "snapshot://testsnap"}'

Read:

curl -g -k -H "Cookie: session_cookie=<session-cookie>" https://<Controller IP>:8443/api/v1/
snapshot/testsnap/data

curl -g -k -H "Cookie: session_cookie=<session-cookie>" https://<Controller IP>:8443/api/v1/
snapshot/testsnap/data --output testfile.snp

Above curl example reads the testsnap snapshot file from Controller IP and writes to a file named testfile.snp.

Apply:

curl -g -k -H "Cookie: session_cookie=<session-cookie>" https://<Controller IP>:8443/api/v1/rpc/
controller/snapshot/apply -d '{"name": "snapshot://testsnap"}'

List:

curl -g -k -H "Cookie: session_cookie=<session-cookie>" https://<Controller IP>:8443/api/v1/data/
controller/snapshot/available

Delete:

curl -g -k -H "Cookie: session_cookie=<session-cookie>" 'https://<Controller IP>:8443/api/v1/data/
controller/snapshot/available[name="testsnap"]'

A keyword is added to the copy running-config snapshot://sample command to convert text running-config commands into a JSON snapshot.

Use the keyword transaction to perform the conversion. The keyword can also create a snapshot with specific commands included.

While similar, the following workflows describe two applications of the copy running-config snapshot://sample command and the new transaction keyword.

Workflow - Create a Snapshot

Create a snapshot using the following command:

> copy file://text-commands snapshot://new-snapshot

Use this choice to convert a collection of text commands into a working snapshot. The resulting snapshot has several advantages over the collection of text commands:

• Snapshots have version details as part of the file format, allowing the configuration to be rewritten based on changes in the new versions of the product.
• REST APIs post the configuration in large chunks, applying snapshots more quickly. A single text command typically updates a specific amount of configuration parameters while writing the resulting modification to the persistent storage.

The conversion process will:

• Create a new transaction with all the configuration parameters removed.
• Replay each command and apply the configuration changes to the active transaction.
• Invoke the snapshot REST API, which builds a snapshot from the current transaction.
• Delete the current transaction, preventing any of the applied configuration changes from the replayed command from becoming active.

Workflow - Create a Snapshot containing a Specific Configuration

Manually create a snapshot that contains a specific configuration using the following steps.

1. Enter the configuration mode that supports changes to the configuration.
2. Create a new transaction using an empty or a current configuration by running one of the following command options.

# begin transaction erase

# begin transaction append

• Add a new configuration, for example, new switches, new policies, new users, etc.,
• Modify the configuration.
• Delete the configuration.
• The local configuration should not be changed, as transactions do not currently manage it. The local system configuration is updated immediately (for example, the hostname).

The new transaction keyword can be used with the copy command, requesting that the configuration within the transaction be copied or applied to the snapshot and not to the current system configuration. For example, using the following command:

# copy running-config snapshot//:sample transaction

# delete transaction

To check the active transaction on the system, use the following command:

# show transaction

Sample Sessions

The examples below will familiarize the reader with converting a text-based running-config into a snapshot.

Example One

Convert a collection of text commands into a working snapshot using the following command:

> copy file://text-commands snapshot://new-snapshot
Controller1(config)# show file
# Name Size Created
-|--------------------|----|-----------------------|
1 textcommands 3560 2023-08-15 21:37:44 UTC
Controller1(config)# copy file://textcommands snapshot://snap_textcommands
Lines applied: 175, snap_textcommands: Snapshot updated
Controller1(config)# show snapshot snap_textcommands

Example Two

Manually create a snapshot containing a specific configuration to be added to the existing running configuration. The commands begin transaction or begin transaction append add the commands executed on the transaction to the existing running configuration.

Controller1(config)# begin transaction
id : 5gMoJ6uu7mcA3j3Gs5fGyLRT8ZJW7CI9
Controller1(config)#
Controller1config)#
Controller1(config)# policy policy15
Controller1(config-policy)# action forward
Controller1(config-policy)#
Controller1(config-policy)# exit
Controller1(config)# copyrunning-config snapshot://snap_policy15 transaction
Controller1(config)#
Controller1(config)# delete transaction
Controller1(config)# show snapshot snap_policy15
!
! Saved-Config snap_policy15
! Saved-Config version: 1.0
! Version: 8.4.0
! Appliance: bmf/dmf-8.4.x
! Build-Number 133
!
version 1.0
! ntp
ntp server ntp.aristanetworks.com
! snmp-server
snmp-server enable traps
snmp-server community ro 7 02161159070f0c
! local
local node
hostname Controller1
interface management
!
ipv4
ip 10.93.194.145/22 gateway 10.93.192.1
method manual
!
ipv6
method manual
! deployment-mode
deployment-mode pre-configured
! user
user admin
full-name 'Default admin'
hashed-password method=PBKDF2WithHmacSHA512,salt=qV-1YyqWIZsYc_SK1ajniQ,rounds=25000,ph=true,0vtPyup3h5JThGFLff-1zw-42-BV7tG7Sm99ROT1OmZCZjlzcWLJj9Lc28mxkQI1-assfW2e-OPDhZbu9qCE2Q
! group
group admin
associate user admin
group read-only
! aaa
aaa accounting exec default start-stop local
! controller
controller
cluster-name dmf204
virtual-ip 10.93.194.147
access-control
!
access-list api
10 permit from 10.93.194.145/32
15 permit from 10.93.194.146/32
!
access-list gui
1 permit from ::/0
2 permit from 0.0.0.0/0
!
access-list ntp
1 permit from ::/0
2 permit from 0.0.0.0/0
!
access-list snmp
1 permit from 0.0.0.0/0
!
access-list ssh
1 permit from ::/0
2 permit from 0.0.0.0/0
!
access-list sync
1 permit from ::/0
2 permit from 0.0.0.0/0
!
access-list vce-api
1 permit from ::/0
2 permit from 0.0.0.0/0
! auto-vlan-mode
auto-vlan-mode push-per-filter
! service-node
service-node dmf204-sn
mac e4:43:4b:48:58:ac
! switch
switch gt160
mac c4:ca:2b:47:97:bf
admin hashed-password $6$ppXOyA92$0hibVW63R0t1T3f7NRUFxPEWUb4b64l4dTGEayrrXcw5or/ZDxm/ZNvotQ7AQfVMo7OZ1I.yDLwrnlVXrZkV3.
!
interface Ethernet1
speed 10G
!
interface Ethernet5
speed 25G
switch hs160
mac c4:ca:2b:b7:44:83
admin hashed-password $6$McgvJd94$vRxDNkr2OSz3kiZSYPFCfuIbcaBuIcoC7ywlVeFFd7oAgLn1eVcV6NyEFZnykje4ILUjmJPWdWeu3LaF4sWzd/
!
interface Ethernet4
speed 10G
!
interface Ethernet47
role delivery interface-name veos2-delivery
!
interface Ethernet48
loopback-mode mac
speed 10G
role both-filter-and-delivery interface-name veos1-filter strip-no-vlan
switch smv160
mac 2c:dd:e9:4e:5e:f5
admin hashed-password $6$RyahYdXx$bUXeQCZ1bHNLcJBA9ZmoH/RmErwpDXvJE20UnEXKoLQffodjsyIlnZ1nG54X5Cq5qgb6uTGXs1TMYkqBWurLh1
!
interface Ethernet31/1
rate-limit 100
speed 10G
role delivery interface-name veos6-delivery ip-address 10.0.1.11 nexthop-ip 10.0.1.10 255.255.255.0
! crypto
crypto
!
http
cipher 1 ECDHE-ECDSA-AES128-GCM-SHA256
!
ssh
cipher 1 aes192-ctr
mac 1 hmac-sha1
! policy
policy policy15
action forward

Example Two

Manually create a snapshot that contains a specific configuration.

Controller1(config)# begin transaction erase
id : GAOGEuLS26I67bqJ7J2NcpOtORfflUn_
Controller1(config)#
Controller1(config)# policy policy16
Controller1(config-policy)# action forward
Controller1(config-policy)#
Controller1(config-policy)# exit
Controller1(config)#
Controller1(config)# copy running-config snapshot://snap_policy16 transaction
Controller1config)#
Controller1(config)#
Controller1(config)# delete transaction
Controller1(config)#
Controller1(config)# show snapshot snap_policy16
!
! Saved-Config snap_policy16
! Saved-Config version: 1.0
! Version: 8.4.0
! Appliance: bmf/dmf-8.4.x
! Build-Number 133
!
version 1.0
! local
local node
hostname Controller1
interface management
!
ipv4
ip 10.93.194.145/22 gateway 10.93.192.1
method manual
!
ipv6
method manual
! policy
policy policy16
action forward

Limitations

With the external Syslog server configured and the logging switch-remote option enabled, the fabric switches send Syslog messages only to the configured external Syslog servers but not to the Controllers. When the logging switch-remote option is enabled, the Controller does not have a local copy of the switch logs.

The Controllers do not share their syslog with the other Controller in the cluster. In other words, the active Controller does not send its syslogs to the standby Controller, and the standby Controller does not share its syslogs with the Active Controller. Access the individual Controller logs from either the Active or Standby node.

To configure the syslog server for a Controller node, enter the logging remote command using the following syntax:

..code-block:: none

logging remote <ip-address>

controller-1(config)# logging remote 192.168.100.1

This example exports the syslog entries from the Controller node to the syslog server at IP address 192.168.100.1.

CLI Commands

controller-1# show logging controller | grep "cmd_args"
Sep 4 21:23:10 BT2 floodlight: INFO [net.bigdb.auth.AuditServer:Dispatcher-3] AUDIT EVENT: bigcli.
command application_id=bigcli cmd_args=enable
Sep 4 21:23:10 BT2 floodlight: INFO [net.bigdb.auth.AuditServer:Dispatcher-4] AUDIT EVENT: bigcli.
command application_id=bigcli cmd_args=configure
Sep 4 21:23:16 BT2 floodlight: INFO [net.bigdb.auth.AuditServer:Dispatcher-3] AUDIT EVENT: bigcli.
command application_id=bigcli cmd_args=bigtap policy policy3
Sep 4 21:23:20 BT2 floodlight: INFO [net.bigdb.auth.AuditServer:Dispatcher-6] AUDIT EVENT: bigcli.
command application_id=bigcli cmd_args=bigchain chain hohoh
Sep 4 21:23:22 BT2 floodlight: INFO [net.bigdb.auth.AuditServer:Dispatcher-3] AUDIT EVENT: bigcli.
command application_id=bigcli cmd_args=ext
Sep 4 21:23:24 BT2 floodlight: INFO [net.bigdb.auth.AuditServer:Dispatcher-3] AUDIT EVENT: bigcli.
command application_id=bigcli cmd_args=configure
Sep 4 21:23:30 BT2 floodlight: INFO [net.bigdb.auth.AuditServer:Dispatcher-5] AUDIT EVENT: bigcli.
command

controller-1(config)# aaa accounting exec default start-stop local

controller-1(config)# aaa accounting exec default start-stop {local [group tacacs+] | [group
            radius]}

controller-1# show logging controller | grep AUDIT

If accounting is remote only, consult the administrator for the TACACS+ server for more information.

The NIST-800-63b compliance mode needs to be set separately on the Controller and the Arista Analytics Node to enforce password compliance for the entire DANZ Monitoring Fabric (DMF) cluster.

Controller(config)# aaa authentication password-compliance nist-800-63b
Warning: A password compliance check has been enabled. This enforces compliance
Warning: rules for all newly chosen passwords, but it doesn't retroactively
Warning: apply to existing passwords. Please choose new passwords for
Warning: all local users, managed appliances, switches, and the recovery user.

Controller(config)# no aaa authentication password-compliance

FIPS versions always enforce NIST 800-63b password compliance by default unless explicitly configured not to do so.

Controller(config)# aaa authentication password-compliance no-check

Controller(config)# show running-config aaa
! aaa
aaa authentication password-compliance nist-800-63b

Controller# configure
Controller(config)# user admin
Controller(config-user)# password <nist-compliant-password>

Controller(config)# service-node <service-node-name>
Controller(config-service-node)# admin password <nist-compliant-password>

Controller(config)# packet-recorder <packet-recorder-name>
Controller(config-packet-recorder)# admin password <nist-compliant-password>

Controller(config)# switch <switch-name>
Controller(config-switch)# admin password <nist-compliant-password>

Configure the following on the Controller to enforce Intra-Fabric Only Access (IFOA) for the API service (i.e., port 8443) on all managed devices.

C1> en
C1# conf
C1(config)# managed-devices
C1(config-managed-devices)# access-control
C1(config-managed-devices-access)# service api
C1(config-managed-devices-access-service)# intra-fabric-only-access
Reminder: IP address/method of the management interface cannot be changed,
when a service has intra-fabric only access enforced.

Several services can have IFOA enforced on them. The list of services and their corresponding ports are shown in the table below. An ❌ means enforcing IFOA on that port on that managed device type is impossible.

Conversely, an ✅ means enforcing IFOA on that port on that managed device type is possible. There may be some information beside the ✅ indicating what runs on that port on the managed device.

C1(config)# switch switch-name
C1(config-switch)# access-control override-global
C1(config-switch)# access-control
C1(config-switch-access)# service api
C1(config-switch-access-service)# no intra-fabric-only-access

As illustrated below, push a similar configuration for the managed appliances, i.e., the Recorder and Service nodes.

Recorder Node

C1(config)# recorder-node device rn1
C1(config-recorder-node)#
C1(config-recorder-node)# access-control override-global
C1(config-recorder-node)# access-control
C1(config-recorder-node-access)# service api
C1(config-recorder-node-access-service)# no intra-fabric-only-access

Service Node

C1(config)# service-node sn1
C1(config-service-node)#
C1(config-service-node)# access-control override-global
C1(config-service-node)# access-control
C1(config-service-node-access)# service api
C1(config-service-node-access-service)# no intra-fabric-only-access

It is also possible to push a configuration that does not override the entire configuration under managed devices but instead merges with it on a per-service basis, for example:

C1(config)# switch core1
C1(config-switch)# access-control merge-global
C1(config-switch)# access-control
C1(config-switch-access)# service api
C1(config-switch-access-service)# no intra-fabric-only-access

This action will merge the global/default config specified under the config-managed-devices CLI submode with the config set for this specific managed device (in this case, the device is a switch, and its name on the Controller is core1).

There are several helpful show commands.

When merging the global/default access-control configuration with the device-specific configuration, understanding the effective configuration (the configuration used in generating the appropriate ACLs) may not be obvious. To see the effective configuration for a specific device, perform the following command:

C1(config)# show effective-config switch core1
! switch
switch core1
access-control
!
service api
intra-fabric-only-access

While displaying the managed device's effective configuration, check the running-config generated by ZTN (the configuration sent to the device), confirming the configuration pushed to the managed device.

C1(config)# show service-node rn1 running-config
.
.
.
interface ma1 acl subnet 10.243.254.20/32 proto tcp port 8443 accept
interface ma1 acl subnet fe80::5054:ff:fef8:b844/128 proto tcp port 8443 accept
interface ma1 acl subnet 0.0.0.0/0 proto tcp port 8443 drop
interface ma1 acl subnet ::/0 proto tcp port 8443 drop
interface ma1 acl subnet ::/0 proto udp port 161 accept
interface ma1 acl subnet 0.0.0.0/0 proto udp port 161 accept
interface ma1 acl subnet 0.0.0.0/0 proto udp port 161 drop
interface ma1 acl subnet ::/0 proto udp port 161 drop
interface ma1 acl subnet 10.243.254.20/32 proto tcp port 22 accept
interface ma1 acl subnet fe80::5054:ff:fef8:b844/128 proto tcp port 22 accept
interface ma1 acl subnet ::/0 proto tcp port 22 accept
interface ma1 acl subnet 0.0.0.0/0 proto tcp port 22 accept
interface ma1 acl subnet 0.0.0.0/0 proto tcp port 22 drop
interface ma1 acl subnet ::/0 proto tcp port 22 drop
interface ma1 acl default accept
.
.
.

The main limitation of this feature is the inability to change the management interface's IP address (on the CLI) once enforcing IFOA for any of the services on any managed devices so that the Controller does not inadvertently get locked out from the managed devices.