Management and Control Plane Security

This chapter describes options for increasing the security of management access to the DMF Controller node.

 

Management Plane Security

The management plane network is used by the administrator, whether locally or remotely, to reach the Controller management interfaces. DANZ Monitoring Fabric (DMF) uses standard, well-known cryptographic technology, such as RSA and AES. Still, system administrators must choose strong passwords and change them frequently, according to well-established security best practices.

All services the Controller uses are enabled by default except for SNMP, which is disabled by default. Refer to the Protocol Access Required to the DMF Controller section to block or permit specific protocols to the management interface.

For example, the control plane is the network between the Controllers and the switches to carry OpenFlow control traffic. The following are general requirements and recommendations for deployment:

  • The Controller must be on the same Layer 2 network as the switches—physically isolated data, control, and management plane networks.
  • The only devices on the control plane are switches and Controllers.
  • Make the control plane network not routed or minimally IP access restricted via its egress router.
  • Physically secure the management and data plane networks (for example, locks on the cage doors).

Many of the Zero-Touch Networking (ZTF) protocols (DHCP, Controller discovery, and image download) and the OpenFlow protocol are not authenticated. They are subject to spoofing in an untrusted network. The following are best practices regarding securing the control plane within the switched fabric.

  • The control plane network is “Layer 2 trusted,” meaning the attacker cannot spoof Layer 2 messages on the control network. In practice, this means the control plane network should be an isolated VLAN, ideally containing only the Controller and switches.
  • Harden the switch management interface against Layer 3 attacks (all services are authenticated, unnecessary services are turned off, and so forth).
  • The network should not be reachable by Layer 3 protocols. If Layer 3 access is required, the administrator should maintain a Layer 3 allowlist of hosts that can access the control network, for example, using an ACL on the edge router.

Importing the Controller Private Key and Certificate

This section describes how to import a private key and a certificate to the Controller after copying it to the Controller using the copy command.

Note: DMF does not support the use of encrypted private keys, so decrypt an encrypted private key before importing/copying it to DMF, as shown in the following example: 
root@Ubuntu-12:~/openssl-ca/admin/pkcs1# openssl rsa -in ../pkcsl.key -out decrypt-pcsl.key
Enter pass phrase for ../pkcsl.key: ********
writing RSA key
root@Ubuntu-12:~/openssl-ca/admin/pkcs1#
To import a private key to the Controller, enter the private-key command in the config-controller submode: 
[no] private-key <controller-key-name>

Replace controller-key-name with the name of the private key. Use the no version of the command to remove the private-key.

To import the Controller certificate, use the certificate command in config-controller submode. 
[no] certificate <name>

Replace the name with the name assigned to the Controller certificate. Use the no version of the command to remove the certificate.

Import the private key and certificate to the Controller using the copy command.

Using Certificates Signed by a CA for GUI Access to the Controller

By default, SSL is enabled on the Controller using a self-signed certificate. Complete the following steps to install a certificate signed by a public or private CA.

Procedure

  1. Generate the Certificate Signing Request (CSR) and the private key for the Controller.
    Perform this operation on any workstation that supports OpenSSL. The following example shows the operation performed on a Linux workstation. 
    root@Ubuntu-12:~/openssl-ca/admin#openssl req -newkey rsa:2048 -nodes -keyout controller.
key -new -out controller.csr
Generating a 2048 bit RSA private key
.......................................+++
...............................+++
writing new private key to 'controller.key'
-----
You are about to be asked to enter information that will be incorporated into your
certificate request.
What you are about to enter is what is called a Distinguished Name or a DN. There are
quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:Santa Clara
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Arista Networks Organizational
Unit Name (eg, section) []:Engineering
Common Name (e.g. server FQDN or YOUR name) []:DMF Secure Certificate
Email Address []:This email address is being protected from spambots. You need JavaScript enabled to view it.
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:anet1234
An optional company name []:Arista
root@Ubuntu-12:~/openssl-ca/admin#
root@Ubuntu-12:~/openssl-ca/admin# ls -ltr
total 8
-rw-r--r-- 1 root root 1708 Feb 7 15:39 controller.key
-rw-r--r-- 1 root root 1184 Feb 7 15:39 controller.csr
root@Ubuntu-12:~/openssl-ca/admin#
    Important: A Subject Alternate Name (SAN) is required to access the DMF controller using the IP addresses of the active/standby controllers or any FQDN names other than the Common Name (CN). The SAN needs to be defined as part of the CSR generation process.

     

    The following is an example of CSR generation with SAN using the openssl command.

    You can generate a new private key and a CSR, explicitly defining the SAN in the command parameters. First,generate a private key:

    openssl genrsa -out controller.key 2048
    Then generate a CSR for a specified subjectAltName (SAN): 
    openssl req -new -key controller.key -out controller.csr -addext "subjectAltName = DNS:example.com,DNS:www.example.com,DNS:sub.example.com"
    Alternatively, you can create a req.conf file to include the SAN definition. For example: 
    [req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = State
L = City
O = Organization
CN = example.com
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
IP.1 = 192.168.1.1 <active controller IP>
IP.2 = 203.0.113.100 <standby controller IP>
    Then run: 
    openssl req -new -out controller.csr -key controller.key -config req.conf.
  2. Submit the CSR to the CA and get the certificate signed.

    Submit the CSR to the trusted CA for browsers used to access the DMF GUI. For organizations using GUI-based CAs, copy the contents of the CSR to the CA for signature.

    The following example shows the operation performed on a Linux workstation. 
    root@Ubuntu-12:~/openssl-ca# openssl ca -config openssl-ca.cnf -policy signing_policy -
extensions signing_req -out admin/controller.pem -infiles admin/controller.csr
Using configuration from openssl-ca.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :Printable:'US'
stateOrProvinceName :ASN.1 12:'California'
localityName :ASN.1 12:'Santa Clara'
organizationName :ASN.1 12:'Arista Networks'
organizationalUnitName:ASN.1 12:'Engineering'
commonName :ASN.1 12:'DMF Secure Certificate'
Certificate is to be certified until Nov 3 23:41:17 2020 GMT (1000 days) Sign the
certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new
entries
Data Base Updated
root@Ubuntu-12:~/openssl-ca#
root@Ubuntu-12:~/openssl-ca/admin# ls -ltr
total 16
-rw-r--r-- 1 root root 1708 Feb 7 15:39 controller.key
-rw-r--r-- 1 root root 1184 Feb 7 15:39 controller.csr
-rw-r--r-- 1 root root 5882 Feb 7 15:41 controller.pem
root@Ubuntu-12:~/openssl-ca/admin#
  3. Copy the signed certificate to the Controller: 
    controller-1# copy scp://This email address is being protected from spambots. You need JavaScript enabled to view it..3:/root/openssl-ca/admin/controller.pem cert://
This email address is being protected from spambots. You need JavaScript enabled to view it..3's password:
controller.pem
5.74KB - 00:00
controller-1# copy scp://This email address is being protected from spambots. You need JavaScript enabled to view it..3:/root/openssl-ca/admin/controller.key private-key:/
/controller- private.key
This email address is being protected from spambots. You need JavaScript enabled to view it..3's password:
controller.key
1.67KB - 00:00
controller-1#
  4. Verify that the certificate was copied correctly: 
    controller-1# show secure
<SNIP>
~~~~~~~~~ Cert ~~~~~~~~~
# Name
-|----------------------|
1 DMF Secure Certificate 2 QA CA
3 ovsclient
~~~~~~~~~~~ Csr ~~~~~~~~~~~
#  Name
- |------------------------ |
1  12358.controller.cluster
2  32591.controller.cluster
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Private Keys~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Name                    Algorithm  Value 
---------------------- |--------- |-----------------------------------------------------------------------------------------------|
controller-private.key  sha256     DB:6D:C1:01:E2:CD:71:C4:AA:54:FA:6F:3F:80:4E:C7:25:4C:A9:2A:CA:7F:F5:44:CF:37:3C:C7:67:93:19:BB
ovsclient               sha256     EB:88:0C:9D:EE:37:AA:BA:1A:6E:7B:F9:6E:7F:89:45:69:C4:7F:58:D3:18:D2:DC:49:16:2E:1D:2A:2B:94:89
controller-1#
  5. Apply the certificate and private key. 
    controller-1(config-controller)# certificate DMF\Secure\Certificate
controller-1(config-controller)# private-key controller-private.key
  6. Display the Controller security configuration. 
    controller-1(config-controller)# show this
! controller
controller
certificate 'DMF Secure Certificate'
cluster-name DMF_Cluster
private-key controller-private.key
access-control
!
access-list api
1 permit from ::/0
2 permit from 0.0.0.0/0
!
access-list gui
1 permit from ::/0
2 permit from 0.0.0.0/0
!
access-list ssh
1 permit from ::/0
2 permit from 0.0.0.0/0
controller-1(config-controller)#
  7. Access the DMF GUI using a browser and display the certificate.
     
  8. After connecting to the Controller, click the padlock icon to the left of the location field to display information about the certificate.

Replacing the Certificate

Please use the following steps to replace the Controller's certificate.

Scenario 1: Using the same CSR used to sign the current certificate.

Obtain a newly signed certificate from CA using the same CSR and copy it to the Controller using the following command:

# copy new certificate from the source cert://
For example: 
# copy scp://This email address is being protected from spambots. You need JavaScript enabled to view it./root/openssl-ca/certificate.pem cert:// This email address is being protected from spambots. You need JavaScript enabled to view it. password certificate.pem 
6.49KB - 00:00 
#
No other action is needed as the current certificate will be overwritten when copying the new one.

Scenario 2: Does not have the same CSR for the current certificate.

  1. Generate a new CSR and the private key.
  2. Sign the CSR to get the new certificate.
  3. Import/copy the certificate to the Controller. The current certificate will be overwritten if the Common Name matches the new one.
  4. Import/copy the new private key to the Controller. The private key will be overwritten if the file name is the same as the old one. In that case, there is no need for any config changes.
Assuming the Common Name and the private key dest file names are different from the original ones, remove the old certificate and private key and install a new certificate and private key.
To remove the old certificate and private key, use the following commands: 
C1(config)# controller
C1(config-controller)# no certificate certificate name
C1(config-controller)# no private-key private-key name
C1(config-controller)#
To configure the new certificate and private key, use the following commands: 
C1(config)# controller
C1(config-controller)# certificate new certificate name
C1(config-controller)# private-key new private-key name
C1(config-controller)#

Manage Certificates and Private Keys in the DMF UI

Please use the following steps to manage certificates and private keys in DMF.

Overview

 

Navigate to Maintenance → Certificates and select Certificates.

Figure 1. Maintenance > Certificates
Figure 2. DMF UI Certificate

 

Certificates

DMF displays a list of available certificates and features to manage the certificates, including search, certificate import, deletion, data export, and filtering by column.

Figure 3. List of Available Certificates

To delete individual certificates, select Delete on the row action menu, followed by Yes.

Figure 4. How to Delete Certificates
Figure 5. Confirmation Window

 

 

Table Actions:

Figure 6. Certificates > Import Certificate

  • Import Certificate: To import a certificate, use Select File, choose the file, and click Import.

Figure 7. Import Certificate Window
  • Delete Selected Certificates: Select a table row checkbox to delete the specific certificates, followed by Yes to confirm the deletion.
Figure 8. Confirmation Window

Private Keys

DMF displays a list of available private keys and features to manage the private keys, including search, private key import, deletion, data export, and filtering by column.

Figure 9. List of Private Keys

To delete private keys, select Delete on the row action menu, followed by Yes.

Figure 10. How to Delete Private Keys
Figure 11. Confirmation Window

 

Table Actions:

Figure 12. Private Keys > Import Private Key

  • Import Private Key: To import a private key, use Select File, choose the file, enter the name, and click Import.

    Figure 13. Import Private Key Window

     

  • Delete Selected Private Keys: Select a table row checkbox to delete the specific private keys, followed by Yes to confirm the deletion.

     

    Figure 14. Confirmation Window

     

DMF UI Certificate

Figure 15. DMF UI Certificate

To configure DMF UI certificates, use the Edit button. Choose the Certificate Name and Private key Name, followed by Submit.

Figure 16. Edit DMF UI Certificate Configuration
Figure 17. DMF UI Certificate Selection

 

Figure 18. Selected DMF UI Certificate

Generate Public/Private Keys and CSRs on DMF Appliances

Starting from DMF release 8.9.0, this feature enables the direct generation of public/private key pairs and TLS Certificate Signing Requests (CSRs) on DMF appliances. With prior releases the workflow required generating keys and CSRs externally, followed by importing the private key and CA-signed certificate. This enhancement simplifies the process by securely retaining the private key on the appliance, eliminating the need for external key management.

 

Procedure

Install a new TLS certificate by following these steps:
  1. Generate Key Pair
    Create a new private/public key pair on the appliance. The supported encryption algorithms include:
    • RSA: 2048, 3072, or 4096-bit modulus
    • Elliptic-Curve DSA (ECDSA): P-256, P-384, or P-521 curve.
  2. Create Certificate Signing Request (CSR)
    Using the generated public key, create a CSR containing the required information for the Certificate Authority (CA).
  3. Obtain Signed Certificate
    Submit the CSR to the CA to obtain a signed certificate.
  4. Import Certificate
    Import the signed certificate onto the appliance.
     
Usage: The certificates secure GUI access and REST API queries.

Securing DMF Appliance Communications Using Custom Certificates

Configuration Summary

To secure appliance communications using custom certificates, follow this general workflow:

  1. Generate Key Pair: Create a unique public/private key pair on the appliance.

  2. Create CSR: Generate a Certificate Signing Request (CSR) linked to the generated public key.

  3. Sign Certificate: Export the CSR content and submit it to the Certificate Authority (CA) for signing.

  4. Import Certificate: Upload the signed certificate returned by the CA to the appliance.

  5. Apply Configuration: Update specific system services (such as the Controller UI, Syslog, or RADIUS) to use the new certificate by referencing its SHA256 fingerprint.

CLI Configuration

Create Public/Private Key Pairs

Generate key pairs using the create key-pair command.

# create key-pair mykeyname rsa3072
Fingerprint           : 37:4E:2F:82:08:45:88:C6:2D:6B:43:FD:73:EC:9A:08:CF:8C:41:E2:62:1A:DB:3E:19:34:CB:18:7C:5B:07:F7
Fingerprint algorithm : sha256
Name                  : test-key

 

Parameters

  • Nickname (Required): A unique name associated with the key pair (e.g., mykeyname). Duplicate nicknames trigger an error.

  • Algorithm (Optional): Specifies the encryption algorithm and key size. If omitted, the default is rsa2048.

  • RSA: rsa2048, rsa3072, rsa4096

  • Elliptic-Curve DSA: ecdsa256 (P-256), ecdsa384 (P-384), ecdsa521 (P-521)

 

Example Output

 

Output Details

  • Fingerprint: The SHA256 hash of the newly created public key.

  • Fingerprint algorithm: Always displays sha256.

  • Name: The unique nickname assigned to the key pair.

 

Note: The system reserves the names self-signed-mgmt and device-api-token. Do not use these names for new key pairs.

Show Public Keys

Display all public keys present on the appliance using the show public-key command.

# show public-key 
# Name             Algorithm Fingerprint                                                                                     
-|----------------|---------|-----------------------------------------------------------------------------------------------|
1 self-signed-mgmt sha256    7A:9C:F3:BE:79:BB:A2:C1:9F:03:4C:BD:93:EA:12:9B:5A:6A:82:85:24:26:25:B7:F0:5F:B3:F6:B9:A5:90:48
2 test-key         sha256    69:92:63:DA:C7:F9:B4:91:BD:92:3F:D3:87:14:4E:B0:88:DB:42:42:DF:0A:D5:33:3C:32:95:32:A7:78:E3:B0

# show public-key 7A:9C:F3:BE:79:BB:A2:C1:9F:03:4C:BD:93:EA:12:9B:5A:6A:82:85:24:26:25:B7:F0:5F:B3:F6:B9:A5:90:48 
Name        : self-signed-mgmt
Algorithm   : sha256
Fingerprint : 7A:9C:F3:BE:79:BB:A2:C1:9F:03:4C:BD:93:EA:12:9B:5A:6A:82:85:24:26:25:B7:F0:5F:B3:F6:B9:A5:90:48

Delete Private/Public Key Pair

Delete a key pair via the CLI using the delete public-key command.

# delete public-key 37:4E:2F:82:08:45:88:C6:2D:6B:43:FD:73:EC:9A:08:CF:8C:41:E2:62:1A:DB:3E:19:34:CB:18:7C:5B:07:F7

Procedure

  1. Retrieve Fingerprint: Identify the target key's SHA256 fingerprint using the show public-key command.

  2. Execute Deletion: Run the delete public-key command with the specific fingerprint.

Warning: Do not delete the self-signed-mgmt or device-api-token key pairs. Deleting these reserved keys results in undefined system behavior.

Create Certificate Signing Request

Generate the Certificate Signing Request (CSR) using the create csr command.

# create csr mycn.com 37:4E:2F:82:08:45:88:C6:2D:6B:43:FD:73:EC:9A:08:CF:8C:41:E2:62:1A:DB:3E:19:34:CB:18:7C:“Arista Inc.” “Customer Service” “Santa Clara” California US san-ip “1.1.1.1,2.2.2.2” san-dns “cs.mycn.com,en.mycn.com” certificate-purpose webserver digest sha256
Content : -----BEGIN CERTIFICATE REQUEST-----
MIIEMDCCApgCAQAwfDERMA8GA1UEAwwIbXljbi5jb20xFDASBgNVBAoMC0FyaXN0
YSBJbmMuMRkwFwYDVQQLDBBDdXN0b21lciBTZXJ2aWNlMRQwEgYDVQQHDAtTYW50
YSBDbGFyYTETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMwggGiMA0G
CSqGSIb3DQEBAQUAA4IBjwAwggGKAoIBgQDzBygBEa30Zq0PywZmi+IQcNJ4I8IP
tJVMQxK0ynjqTWrDcjolIA9GuoFHEtIfA2+ja3xvoFRXIFMyVUuITLkwhhZeEOUP
kyD61WPNX+DUg4ANpYW/nu2LGjQtbz24iS6In3Udi2Nvh1pn+8uM3p//GsMy7kK0
jwRHKmB9UynXFoaVkMF6XjxAJ4/n4+ck2inP29BW+q1hPlpjiXwLVmVPTpDNvAXE
H/+3zk4t8PTUlMD7xoFHghx7moV3R5A6cIT21wFae9VjjY78B6PcaP4pzZ5VV05B
aJ89559W2Mzd0HjMEv8OhkNV+xFBy6eyh6tT/FgxR7PceNzt7BwkNQ/zCIgqDv+z
NqzymK+T96sXtxrywlyVJWJmNwilqJeYVcRQ7bqItzq59OS4g0m41hi4O6IBIbZG
ngKB9g6RdXjb5oN5XGfnilCCGkq6v3f75nkPhJB4fyVvkNJWy7svNxGEbgIRHXt8
xzrIy/Qy3i8nQMw3aPVarM2UhcYlwWT8e2UCAwEAAaBvMG0GCSqGSIb3DQEJDjFg
MF4wLwYDVR0RBCgwJocEAQEBAYcEAgICAoILY3MubXljbi5jb22CC2VuLm15Y24u
Y29tMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgOoMBMGA1UdJQQMMAoGCCsGAQUFBwMB
MA0GCSqGSIb3DQEBCwUAA4IBgQBUMqrUgKw6pDK4uE8lhjSArdxx5QkRwJdvszWj
WS6Tb+p6qs5yDcp4KJyxcGoyn2tp33C06AhRvAZ+ZQgsz+4wHH06b5FxtDKVBLv5
SWR9GEn8u5ZOhACUNKNh1tAAQOyLyoFKwBvFQ6IaWP8YICeXO3Jg6+uzinpN3DQx
yS8Z1nJ6c2FkjiPYHWmAaWib7iBMEnFvqkrfoFXvZBIwLV4nFYq3ZfcRlL7oQFRg
hNougNuW/KKgJ+S95RJCLnqEgmm5XhIcgXTZU262wF0ctdt3Jzpwbwvf6VnMRjMr
whxt+2wsqqqWYty0MxgTbqpqjy4nSw6eSh36NvsdA9ExCxaj24LEHomfZlRHzLl/
C5HHAeplJ8l79cDlGThnjz1qU+iRfccuqw2JSCiqUo2zMy41y+Fr38jAF7vv4RwU
xC63pe+haiVcx1H6MNgHJgGTe+tjoPvo3wpQyt9W09vXwH9Y0j6/YAWH53qFz7El
rKLrNMjwaarJrE4hv+BUC1UV/ZQ=
-----END CERTIFICATE REQUEST-----
Fingerprint :
69:CB:DD:49:7D:64:FF:DE:EA:C4:C6:E2:C9:03:E6:ED:74:A
3:49:44:88:5E:98:0D:AE:C3:46:77:0F:8B:55:69
Fingerprint algorithm : sha256
Name : mycn.com

Input Parameters

The input requires a JSON object containing the following fields:

  • cn (Common Name): Requires a valid domain name.

  • org (Organization): The legal name of the organization.

  • ou (Organization Unit): The division or department within the organization.

  • city: The city or locality name.

  • state: The state or province name.

  • country: The two-letter ISO country code.

  • san-ip: A list of IPv4 or IPv6 addresses to use as Subject Alternative Names (SANs).

  • san-dns: A list of domain names to use as Subject Alternative Names (SANs).

  • public-key-fingerprint: The fingerprint of the previously created public key.

  • certificate-purpose: Defines the Key Usage and Extended Key Usage for the certificate. The only supported value is web-server.

  • digest: The signature algorithm. Supported values include:

    • sha256

    • sha384

    • sha512

Response Fields

The system returns a response with the following fields:

  • fingerprint-algorithm: Always returns sha256.

  • fingerprint: The SHA256 fingerprint of the generated CSR.

  • name: The Common Name (CN) of the CSR.

  • content: The CSR content in PEM format. Copy this content to the Certificate Authority (CA) to request a signed certificate.

Note:The system automatically removes any existing CSR associated with the provided public key from the appliance.

Show Certificate Signing Requests

Display all Certificate Signing Requests (CSRs) present on the appliance using the show csr command.

# show csr 
# Name     Algorithm Fingerprint                                                                                     
-|--------|---------|-----------------------------------------------------------------------------------------------|
1 mycn.com sha256    69:CB:DD:49:7D:64:FF:DE:EA:C4:C6:E2:C9:03:E6:ED:74:A3:49:44:88:5E:98:0D:AE:C3:46:77:0F:8B:55:69

# show csr 69:CB:DD:49:7D:64:FF:DE:EA:C4:C6:E2:C9:03:E6:ED:74:A3:49:44:88:5E:98:0D:AE:C3:46:77:0F:8B:55:69 
Name        : mycn.com
Algorithm   : sha256
Fingerprint : 69:CB:DD:49:7D:64:FF:DE:EA:C4:C6:E2:C9:03:E6:ED:74:A3:49:44:88:5E:98:0D:AE:C3:46:77:0F:8B:55:69
Content     : -----BEGIN CERTIFICATE REQUEST-----
MIIEMDCCApgCAQAwfDERMA8GA1UEAwwIbXljbi5jb20xFDASBgNVBAoMC0FyaXN0
YSBJbmMuMRkwFwYDVQQLDBBDdXN0b21lciBTZXJ2aWNlMRQwEgYDVQQHDAtTYW50
YSBDbGFyYTETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMwggGiMA0G
CSqGSIb3DQEBAQUAA4IBjwAwggGKAoIBgQDzBygBEa30Zq0PywZmi+IQcNJ4I8IP
tJVMQxK0ynjqTWrDcjolIA9GuoFHEtIfA2+ja3xvoFRXIFMyVUuITLkwhhZeEOUP
kyD61WPNX+DUg4ANpYW/nu2LGjQtbz24iS6In3Udi2Nvh1pn+8uM3p//GsMy7kK0
jwRHKmB9UynXFoaVkMF6XjxAJ4/n4+ck2inP29BW+q1hPlpjiXwLVmVPTpDNvAXE
H/+3zk4t8PTUlMD7xoFHghx7moV3R5A6cIT21wFae9VjjY78B6PcaP4pzZ5VV05B
aJ89559W2Mzd0HjMEv8OhkNV+xFBy6eyh6tT/FgxR7PceNzt7BwkNQ/zCIgqDv+z
NqzymK+T96sXtxrywlyVJWJmNwilqJeYVcRQ7bqItzq59OS4g0m41hi4O6IBIbZG
ngKB9g6RdXjb5oN5XGfnilCCGkq6v3f75nkPhJB4fyVvkNJWy7svNxGEbgIRHXt8
xzrIy/Qy3i8nQMw3aPVarM2UhcYlwWT8e2UCAwEAAaBvMG0GCSqGSIb3DQEJDjFg
MF4wLwYDVR0RBCgwJocEAQEBAYcEAgICAoILY3MubXljbi5jb22CC2VuLm15Y24u
Y29tMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgOoMBMGA1UdJQQMMAoGCCsGAQUFBwMB
MA0GCSqGSIb3DQEBCwUAA4IBgQBUMqrUgKw6pDK4uE8lhjSArdxx5QkRwJdvszWj
WS6Tb+p6qs5yDcp4KJyxcGoyn2tp33C06AhRvAZ+ZQgsz+4wHH06b5FxtDKVBLv5
SWR9GEn8u5ZOhACUNKNh1tAAQOyLyoFKwBvFQ6IaWP8YICeXO3Jg6+uzinpN3DQx
yS8Z1nJ6c2FkjiPYHWmAaWib7iBMEnFvqkrfoFXvZBIwLV4nFYq3ZfcRlL7oQFRg
hNougNuW/KKgJ+S95RJCLnqEgmm5XhIcgXTZU262wF0ctdt3Jzpwbwvf6VnMRjMr
whxt+2wsqqqWYty0MxgTbqpqjy4nSw6eSh36NvsdA9ExCxaj24LEHomfZlRHzLl/
C5HHAeplJ8l79cDlGThnjz1qU+iRfccuqw2JSCiqUo2zMy41y+Fr38jAF7vv4RwU
xC63pe+haiVcx1H6MNgHJgGTe+tjoPvo3wpQyt9W09vXwH9Y0j6/YAWH53qFz7El
rKLrNMjwaarJrE4hv+BUC1UV/ZQ=
-----END CERTIFICATE REQUEST-----

Delete a CSR

Delete a Certificate Signing Request (CSR) via the CLI using the delete csr command.

# delete csr 37:4E:2F:82:08:45:88:C6:2D:6B:43:FD:73:EC:9A:08:CF:8C:41:E2:62:1A:DB:3E:19:34:CB:18:7C:5B:07:F7
Procedure

  1. Retrieve Fingerprint: Identify the target CSR's SHA256 fingerprint using the show csr command.

  2. Execute Deletion: Run the delete csr command with the specific fingerprint.

Import a Signed Certificate

After the Certificate Authority (CA) produces a signed certificate, import it onto the appliance using Secure Copy Protocol (SCP) from an external device.

(external)$ scp ./mycert.pem username@10.0.0.1://cert

 

Import Behavior and Constraints

  • CSR Cleanup: If the imported certificate matches an existing CSR's Common Name and Public Key, the system successfully imports the certificate and removes the pending CSR.

  • Partial Match Error: If an existing CSR matches only the Common Name or only the Public Key (but not both), the system rejects the import and raises an error.

  • Unique Public Keys: Every certificate must use a unique public key. If the imported certificate uses a public key already associated with an existing certificate, the system removes the older certificate.

Show Certificates

Display all certificates present on the appliance using the show certificate command.

# show certificate 
# Certificate name Algorithm Fingerprint                                                                                     Not before              Not after               
-|----------------|---------|-----------------------------------------------------------------------------------------------|-----------------------|-----------------------|
1 self-signed-mgmt sha256    BA:64:1A:5D:02:B1:3F:34:43:C1:02:B1:CF:7F:4C:7D:AF:99:65:E9:9C:68:75:FE:6A:57:1F:BF:43:42:6E:4C 2025-09-18 20:16:33 UTC 2027-12-18 20:16:33 UTC
2 test-certificate sha256    CA:FD:BF:AB:0D:54:25:59:7A:BE:28:33:A1:BE:B8:FC:0A:77:79:2B:85:97:46:D2:30:4D:C3:94:3B:1F:60:8D 2022-09-23 18:26:30 UTC 2027-09-22 18:26:30 UTC

# show certificate BA:64:1A:5D:02:B1:3F:34:43:C1:02:B1:CF:7F:4C:7D:AF:99:65:E9:9C:68:75:FE:6A:57:1F:BF:43:42:6E:4C 
Certificate name : self-signed-mgmt
Algorithm        : sha256
Fingerprint      : BA:64:1A:5D:02:B1:3F:34:43:C1:02:B1:CF:7F:4C:7D:AF:99:65:E9:9C:68:75:FE:6A:57:1F:BF:43:42:6E:4C
Not before       : 2025-09-18 20:16:33 UTC
Not after        : 2027-12-18 20:16:33 UTC
Content          : -----BEGIN CERTIFICATE-----
MIIEtjCCAx6gAwIBAgIGAZljnxIAMA0GCSqGSIb3DQEBCwUAMIGGMRkwFwYDVQQD
DBBzZWxmLXNpZ25lZC1tZ210MREwDwYDVQQLDAhQbGF0Zm9ybTEeMBwGA1UECgwV
QXJpc3RhIE5ldHdvcmtzLCBJbmMuMRQwEgYDVQQHDAtTYW50YSBDbGFyYTETMBEG
A1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMwHhcNMjUwOTE4MjAxNjMzWhcN
MjcxMjE4MjAxNjMzWjCBhjEZMBcGA1UEAwwQc2VsZi1zaWduZWQtbWdtdDERMA8G
A1UECwwIUGxhdGZvcm0xHjAcBgNVBAoMFUFyaXN0YSBOZXR3b3JrcywgSW5jLjEU
MBIGA1UEBwwLU2FudGEgQ2xhcmExEzARBgNVBAgMCkNhbGlmb3JuaWExCzAJBgNV
BAYTAlVTMIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEAouf2xtJlWzMr
6rOJTInEip/qq7TAMLJtGT4d4yGx6t5PPIwAGZoVvwp7COg/nB6ZInlOIRTqbMCD
vv83cAV/P+e98BHQpBipQ2evp1QPZ0E9mI8+KuNtt+LryjHYrHgkyO2i7IIPgibB
+pftX9SjnZeqrq8ZkncMvLAVreKKSAHxkMXbkyxNfM0kGJGtmn4wwkqP2g8y39an
YPvXM+2CqRD716AQc3GPtUBLiQ3hzUA9fp9MlCGQBH++oDU8wV2HMNcY9KtjJz7G
+3sz6XIUgYSO9EjOmtAgyB3S5LwDrpctDhatFL/g70j06RtA/RvA/vxJXqd6wiqQ
n7ugC9JbqQFxzCbQlQZYT6QhD7A8T9tMeXMs0JRqQjqoUeDoLvTO9j4ILipY6EV/
iyiEgJwED7GA5ZGqqLvSHMaiG9KGjtL+oNavxpnLS04BvU3g7vuThdmfmXMIvKqI
PSMlw+RKXze+yigaQY34K3nVqS6JKNg4YH+wPrwXxvHqVxloUdo3AgMBAAGjKDAm
MA8GA1UdEQQIMAaHBArz/ZQwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcN
AQELBQADggGBAGHeakL0sSZzgNTH77baC7LJBVfycIDOx4iD7HFOgy3C+ubi0JBM
Zg+OkEGkfrB3QQO6oEyDbMm4EfhjiqMAHjlifMLgsa0/W3dTBj6VWtAkT8Iad/6M
X1NeljmPop8nHVjUM+qDuRUbwFepdyMRcIuwhKeUAU++ZSpPey3+YyWQozecZND6
0f6iSaue2PN2zCvoV5S6v0GT3ywDQ3uKlnJpBfFSwVGYiPhjybNZf+CTeE1Gs+N5
uedJpsmOk1rF3UXRxbMhhj8EeuHDohxm7wc+pHHj3Kw5aj7FNP15fj4YJn8Ywf0+
c4IessbrdCJsOv6YRJX00tUX0+v+ZZv2TaYWdOLSCSLtngpebYdGCY5pLGUNZzmW
/zrvYptwuACuK92iy43wJmrsxskX9aoC+DzzpOllWuKE3dB3WKIwJF5cUIyQspQF
+CTqDCoD3mUl2aKXiSqEZq+2v+zh4ivq+k76aBg0LYP2gh26EHqxNKhvpnMLDubH
8nFnO+UT86NpzQ==
-----END CERTIFICATE-----

Delete a Certificate

Delete a certificate via the CLI using the delete cert command.

# delete cert CA:FD:BF:AB:0D:54:25:59:7A:BE:28:33:A1:BE:B8:FC:0A:77:79:2B:85:97:46:D2:30:4D:C3:94:3B:1F:60:8D
Procedure

  1. Retrieve Fingerprint: Identify the target certificate's SHA256 fingerprint using the show certificate command.

  2. Execute Deletion: Run the delete cert command with the specific fingerprint.

Controller TLS Certificate Configuration

Configure the TLS certificate used for HTTPS access (GUI and REST API) within the DMF Controller configuration mode.

(config)# controller
(config-controller)# certificate CA:FD:BF:AB:0D:54:25:59:7A:BE:28:33:A1:BE:B8:FC:0A:77:79:2B:85:97:46:D2:30:4D:C3:94:3B:1F:60:8D

Configuration Behavior

  • Fingerprint: The command requires the SHA256 fingerprint of the target certificate.

  • Automatic Private Key Association: The system automatically infers the private key from the certificate’s public key. Consequently, the separate private key configuration command found in previous versions has been removed.

Note: Ensure the private key associated with the certificate exists on the appliance. If the private key is missing, this configuration has no effect.

Other Configurations

This feature updated the CLI configuration commands described in the following sections. As a consequence, all those commands now reference certificates on the appliance using their SHA256 fingerprint.

 

TLS Settings for Syslog

Configure the certificate and CA for secure logging.

# TLS settings for syslog
(config)# logging secure cert CA:FD:BF:AB:0D:54:25:59:7A:BE:28:33:A1:BE:B8:FC:0A:77:79:2B:85:97:46:D2:30:4D:C3:94:3B:1F:60:8D
(config)# logging secure ca CA:FD:BF:AB:0D:54:25:59:7A:BE:28:33:A1:BE:B8:FC:0A:77:79:2B:85:97:46:D2:30:4D:C3:94:3B:1F:60:8D

 

RADIUS CA Certificate

Configure the CA certificate for RADIUS EAP-TLS/TTLS.

# CA certificate for RADIUS EAP-TLS/TTLS
(config)# radius ca-cert CA:FD:BF:AB:0D:54:25:59:7A:BE:28:33:A1:BE:B8:FC:0A:77:79:2B:85:97:46:D2:30:4D:C3:94:3B:1F:60:8D

 

Secure Control Plane Certificate

Configure the secure control plane certificate.

# Secure control plane certificate
(config)# secure control plane CA:FD:BF:AB:0D:54:25:59:7A:BE:28:33:A1:BE:B8:FC:0A:77:79:2B:85:97:46:D2:30:4D:C3:94:3B:1F:60:8D

 

Configuration Notes

  • Fingerprint Reference: All commands referencing certificates now require the SHA256 fingerprint.

  • Private Key Removal: Configuration commands related specifically to private keys have been removed.

  • Key Requirement: Any non-CA certificate must have its associated private key present on the appliance for the configuration to function correctly.

 

Syslog Messages

 
Level Message Situation
INFO TLSMGR1030: Adding key pair <name> <information> A new public/private key pair is being added to the appliance
ERROR TLSSTR7002: Failed to sync a key pair update The key pair hasn’t been synced to other nodes in the cluster
ERROR TLSSTR7001: Failed to sync a key pair delete The key pair deletion hasn’t been synced to other nodes in the cluster
INFO TLSMGR1007: Adding a CSR <CN> <fingerprint> A new CSR is being added to the appliance
WARNING TLSMGR4002: Attempted to add CSR <fingerprint> but an existing CSR with that fingerprint exists. An already existing CSR is being added to the appliance
WARNING TLSMGR4009: Attempted to add CSR <fingerprint X> that was generated by the same key pair as existing CSR <fingerprint Y>. Removing CSR <fingerprint Y>. A new CSR is being added, but an existing CSR uses the same public key. The existing CSR will be removed.
ERROR TLSMGR7003: Failed to sync CSR The new CSR hasn’t been synced to other nodes in the cluster
INFO TLSMGR1009: Removing a CSR <fingerprint> A CSR is being removed from the appliance
ERROR TLSMGR7006: Failed to sync a CSR delete The CSR deletion hasn’t been synced to other nodes in the cluster
ERROR TLSMGR1008: Adding a certificate <CN> A new certificate is being added to the appliance
WARNING TLSMGR4003: Added certificate <CN X> (<fingerprint>) is overwriting certificate <CN Y> (<fingerprint>) A new certificate is replacing another certificate with a matching public key
INFO TLSMGR1006: CSR <fingerprint> has been satisfied by Cert <CN> A CSR matching the imported certificate has been found and will be removed.
ERROR TLSMGR7008: Failed to sync cert update A new certificate hasn’t been synced to other nodes in the cluster
ERROR TLSMGR7015: Failed to sync cert delete The certificate deletion hasn’t been synced to other nodes in the cluster

Troubleshooting

If certificate configurations do not take effect, verify the presence of certificates and matching public keys using the show public-key and show certificate commands.

  • Cluster Consistency: In clustered environments, ensure all nodes share the same certificates and public keys.

  • Persistent Issues: If problems persist or the system generates frequent syslog errors, create a support bundle and contact Arista TAC.

Limitations

  • The system supports Certificate Signing Requests (CSRs) only for web-server certificates.

DMF User Interface Configuration for Custom Certificates

Create CSRs and Public/Private Keys using the DMF GUI.

Navigate to Monitoring → Certificates.

 

Figure 19. Monitoring > Certificates

Public / Private Keys

The Public/Private Keys table displays existing keys, including the Name, Fingerprint Algorithm, and Fingerprint.

  • Import: Select Import Private key in the Actions drop-down menu to import the Public/Private Key if you have it.

  • Create: Select Generate Key Pair in the Actions drop-down menu to open the creation window.

  • Delete: Select one or more keys using the table checkboxes, then Delete to remove them.

 

Figure 20. Public/Private Keys

Create

 

Figure 21. Generate Key Pair Action

 

Figure 22. Create Key Pair Window

Delete Action

 

Figure 23. Deletion Confirmation Request

Certificate Signing Requests

The Certificate Signing Requests table displays existing CSRs, including the Name, Fingerprint Algorithm, and Fingerprint.

  • Create: Select Create CSR in the Actions drop-down menu to open the creation window.

  • Delete: Select one or more CSRs using the table checkboxes, then Delete to remove them.

  • Download: Click on the created CSR’s Actionscolumn and select the Download option to download the CSR file to a local downloads folder. Submit the CSR to the signing authority.

 

Figure 24. Certificate Signing Requests

Create Action

 

Figure 25. Create CSR Action

 

Figure 26. Create CSR Window

Delete Action

 

Figure 27. Deletion Confirmation Request

Certificates

The Certificates table displays existing certificates, including the Name, Fingerprint Algorithm, and Fingerprint.

  • Import: Select Import Certificate (Import CA Signed Certificate) in the Actions drop-down menu to open the import window.

  • Delete: Select one or more certificates using the table checkboxes, then Delete to remove them.

  • Download: Click on the certificate’s Actions column and select the Download option to download the certificate file to a local downloads folder, for backup purposes.

 

Figure 28. Certificate List

Import a Certificate

 

Figure 29. Import Action

 

Figure 30. Import Certificate Window

Delete Action

 

Figure 31. Certificate Deletion Confirmation

DMF UI Certificate

This section displays the active DMF UI certificate.

 

Figure 32. DMF UI Certificate

  • Add or Edit: Select Edit near the title to open the certificate list. Choose the desired certificate and select Submit to apply it.

  • Reset: Select Reset to revert the certificate configuration.

 

Figure 33. Edit DMF UI Certificate Configuration

Managing the Controller HTTP and SSH Ciphers, Protocols, and Data Integrity Algorithms

Use the crypto command to enter the config-crypto submode to configure settings for HTTP and SSH. Use the http and ssh commands in the config-crypto submode to configure the ciphers and protocols. Configure the list of enabled ciphers, protocols, or algorithms by appending to the list.

Use the no version of this command with any keyword to remove the specific cipher, protocol, or algorithm. Use the no version of the command without a keyword to restore the list to the default value. Use the CLI help feature to identify the supported ciphers, protocols, or data integrity (MAC) algorithms.

Configuring HTTP Ciphers

Enter the following commands to configure the ciphers for HTTP: 
controller-1(config)# crypto
controller-1(config-crypto)# http
controller-1(config-crypto-http)# cipher <index> <cipher-name>
Note: When you configure a set of ciphers instead of using the default set, please make sure to configure at least one or all the three ciphers mentioned below in addition to your choice. ECDHE-RSA-CHACHA20-POLY1305, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384.

 

Example: 
controller-1(config)# crypto
controller-1(config-crypto)# http
controller-1(config-crypto-http)# cipher 1 <your choice of cipher-name>
controller-1(config-crypto-http)# cipher 2 <your choice of cipher-name>
controller-1(config-crypto-http)# cipher 3 <your choice of cipher-name>
controller-1(config-crypto-http)# cipher 21 ECDHE-RSA-CHACHA20-POLY1305
controller-1(config-crypto-http)# cipher 22 ECDHE-RSA-AES128-GCM-SHA256
controller-1(config-crypto-http)# cipher 23 ECDHE-RSA-AES256-GCM-SHA384

Configuring HTTP Protocols

Starting in the DANZ Monitoring Fabric 8.4 release, the TLSv1.3 HTTPS protocol is supported. DMF supports TLSv1.3 and TLSv1.2 by default, with the TLSv1.3 protocol preferred for TLS connections.

Enter the following commands to configure the protocols for HTTP: 
controller-1(config)# crypto
controller-1(config-crypto)# http
controller-1(config-crypto-http)# protocol <index> <protocol-name>

Configuring SSH Ciphers

Configured SSH ciphers and MAC algorithms on the Controller are pushed to the switches running Switch Light OS via ZTN. With this enhancement, users can also restrict the SSH ciphers and MAC algorithms on the switches.

Enter the following commands to configure the ciphers for SSH: 
controller-1(config)# crypto
controller-1(config-crypto)# ssh
controller-1(config-crypto-ssh)# cipher <index> <cipher-name>

Configuring SSH Data Integrity Algorithms

Enter the following command to configure data integrity (MAC) algorithms for SSH: 
controller-1(config)# crypto
controller-1(config-crypto)# ssh
controller-1(config-crypto-ssh)# mac <index> <mac-name>

Configuring SSH Host Key Algorithms

Starting from DMF release 8.7.0 it is possible to enable and configure the SSH host key algorithms. Moreover, this capability enables SSH demon (sshd) configurations managed by DMF not to use obsolete SHA-1-based algorithms. DMF imposes the default sshd configuration in the absence of configured SSH host key algorithms and MACs, which excludes SHA-1-based algorithms by default.

Configuration of the SSH host key algorithm is optional.

DMF uses the built-in default set of algorithms if no host key algorithms are explicitly configured. The default set of host key algorithms does not contain any algorithms that use the SHA-1 hash algorithm.

Configuration of SSH host key algorithms follows the same pattern as the existing SSH MACs and cipher configuration under the crypto and ssh submodes.

While in the crypto-ssh submode, specify the host key algorithm to use after an index number.

controller-1> enable
controller-1# configure
controller-1(config)# crypto
controller-1(config-crypto)# ssh
controller-1(config-crypto-ssh)# 
cipher host-key-algorithm mac
controller-1(config-crypto-ssh)# host-key-algorithm 1 rsa-sha2-512
controller-1(config-crypto-ssh)# host-key-algorithm 2 ssh-ed25519

 

Remove the SSH host key algorithm from the enabled algorithm using the no command option specifying the index number.

After removing all algorithms, DMF uses the default set of algorithms.

controller-1(config-crypto-ssh)# show this

! crypto
crypto
  !
  ssh
    host-key-algorithm 1 rsa-sha2-512
    host-key-algorithm 2 ssh-ed25519
controller-1(config-crypto-ssh)# no host-key-algorithm 2
controller-1(config-crypto-ssh)# show this

! crypto
crypto
  !
  ssh
    host-key-algorithm 1 rsa-sha2-512
controller-1(config-crypto-ssh)#

 

Show Commands

Specific CLI commands display explicitly configured SSH host key algorithms. These appear in the show running-config output in the crypto ssh section.

controller-1> show running-config crypto ssh
! crypto
crypto
  !
  ssh
    host-key-algorithm 1 rsa-sha2-512
    host-key-algorithm 2 ssh-ed25519
controller-1(config-crypto-ssh)#

In the absence of a host-key-algorithm in the running config, it is implied the default set of algorithms are in effect.

controller-1> show running-config crypto ssh
controller-1(config-crypto-ssh)#

When the CLI is in the crypto-ssh configuration submode, display the current configuration using the show this command:

controller-1(config-crypto-ssh)# show this
! crypto
crypto
  !
  ssh
    host-key-algorithm 1 rsa-sha2-512
    host-key-algorithm 2 ssh-ed25519

Troubleshooting

To troubleshoot issues connecting to DMF over SSH, enable the debug output of the SSH client to view the details.

For example, if using OpenSSH, adding the option ssh -vv displays information about the handshake process.

$ ssh -vv This email address is being protected from spambots. You need JavaScript enabled to view it.
…
debug2: local client KEXINIT proposal
…
debug2: host key algorithms: rsa-sha2-512
…
debug2: peer server KEXINIT proposal
…
debug2: host key algorithms: ssh-ed25519
…
debug1: kex: host key algorithm: (no match)
Unable to negotiate with 10.243.255.120 port 22: no matching host key type found.
Their offer: ssh-ed25519

Default SSH MACs, Ciphers, Keys, and TLS Ciphers

This section specifies the default lists of supported SSH MACs, ciphers, and host-key algorithms in the DANZ Monitoring Fabric as well as the TLS versions and ciphers available by default.
  • Starting from DMF release 8.7.0, the default list of SSH MACs is: 
    This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
hmac-sha2-512
hmac-sha2-256
This email address is being protected from spambots. You need JavaScript enabled to view it.

     

  • Starting from DMF release 8.7.0, the SSH ciphers available by default are: 
    This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
aes256-ctr
aes192-ctr
aes128-ctr

     

  • Starting from DMF release 8.7.0, the default list of SSH host-key algorithms is: 
    This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
This email address is being protected from spambots. You need JavaScript enabled to view it.
ssh-ed25519
This email address is being protected from spambots. You need JavaScript enabled to view it.
rsa-sha2-512
rsa-sha2-256

     

  • Starting from DMF release 8.7.0, the default set of supported TLS versions is: 
    TLSv1.2
TLSv1.3

     

  • Starting from DMF release 8.8.0, the default list of supported TLS ciphers is: 
    TLS_AES_256_GCM_SHA384         TLSv1.3  Kx=any   Au=any   Enc=AESGCM(256)            Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256   TLSv1.3  Kx=any   Au=any   Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256         TLSv1.3  Kx=any   Au=any   Enc=AESGCM(128)            Mac=AEAD
TLS_AES_128_CCM_SHA256         TLSv1.3  Kx=any   Au=any   Enc=AESCCM(128)            Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDH  Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305    TLSv1.2  Kx=ECDH  Au=RSA   Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA Enc=AESGCM(256)            Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA   Enc=AESGCM(256)            Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA Enc=AESGCM(128)            Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA   Enc=AESGCM(128)            Mac=AEAD

     

    Note: The following ciphers have been removed from the default list but are still available for configuration if needed: 
    ECDHE-ECDSA-AES128-SHA256    TLSv1.2 
ECDHE-RSA-AES128-SHA256      TLSv1.2 
AES128-GCM-SHA256            TLSv1.2 
AES128-SHA256                TLSv1.2
ECDHE-ECDSA-AES256-SHA384    TLSv1.2 
ECDHE-RSA-AES256-SHA384      TLSv1.2 
AES256-GCM-SHA384            TLSv1.2 
AES256-SHA256                TLSv1.2

Inherit MAC and Cipher Configuration

This feature provides the ability to mirror the SSH/HTTPS cryptographic configuration of the DMF Controller to the managed appliances (i.e., service nodes and recorder nodes) and the SSH cryptographic configuration of the Controller to the EOS switches.

Using the CLI to Configure SSH and HTTPS

The configuration that a managed appliance or EOS/Switch Light OS switch receives is intended for the Controller itself. Configuring a cipher or message authentication code (MAC) on the Controller will automatically be reflected onto a managed appliance or EOS/Switch Light OS switch.

SSH and HTTPS Cryptographic Configuration Syntax

(config)# crypto
(config-crypto)# ssh
(config-crypto-ssh)# cipher number algorithm
(config-crypto-ssh)# mac number algorithm
(config-crypto-ssh)# http
(config-crypto-http)# cipher number algorithm
(config-crypto-http)# protocol number algorithm

 

The following is a configuration example using common algorithms.

(config)# crypto
(config-crypto)# ssh
(config-crypto-ssh)# cipher 1 aes256-cbc
(config-crypto-ssh)# mac 1 hmac-sha2-512
(config-crypto-ssh)# http
(config-crypto-http)# cipher 1 AES128-GCM-SHA256
(config-crypto-http)# cipher 2 ECDHE-RSA-CHACHA20-POLY1305
(config-crypto-http)# protocol 2 TLSv1.2

 

Note: The Controller pushes both the HTTP/TLS and the SSH cryptographic configuration to managed appliances but it only pushes the SSH cryptographic configuration to EOS/Switch Light OS switches.

Verify the Cryptographic Configuration

Check the cryptographic configuration of the Controller using the show running-config command, as shown in the example below, and verify the settings in the crypto section.

# show running-config
.
.
.
! crypto
crypto
!
ssh
cipher 1 3des-cbc
mac 1 hmac-md5
.
.
.

All ciphers/protocols/MACs of the HTTPS/SSH cryptographic configuration supported on the Controller are supported on the managed appliances, with one caveat listed in the Limitations section below. Check the HTTPS/SSH cryptographic configuration by reviewing the running-config of a managed appliance, as shown below for a Recorder Node.

# show recorder-node device rn1 running-config
.
.
.
! crypto
crypto
!
ssh
cipher 1 3des-cbc
mac 1 hmac-md5
.
.
.
Note: EOS does not support all SSH ciphers and MACs that the Controller does.

 

The following SSH MAC algorithms supported by the Controller are not supported by EOS:
  1. This email address is being protected from spambots. You need JavaScript enabled to view it. (HMAC-MD5 in “encrypt-then-mac” mode)
  2. This email address is being protected from spambots. You need JavaScript enabled to view it. (HMAC-MD5 in “encrypt-then-mac” mode)
  3. This email address is being protected from spambots. You need JavaScript enabled to view it. (HMAC-SHA1 in “encrypt-then-mac” mode)
  4. This email address is being protected from spambots. You need JavaScript enabled to view it. (message authentication code based on universal hashing (UMAC) in “encrypt-then-mac” mode)
  5. This email address is being protected from spambots. You need JavaScript enabled to view it. (UMAC)

 

The following SSH cipher algorithm supported by the Controller is not supported by EOS:

  • This email address is being protected from spambots. You need JavaScript enabled to view it. (Rijndael in CBC mode)

This difference can be seen when reviewing the running-config of the Controller and the ZTN-generated running-config of an EOS switch:

# show running-config
.
.
.
.
! crypto
crypto
!
ssh
cipher 1 This email address is being protected from spambots. You need JavaScript enabled to view it.
cipher 2 3des-cbc
mac 1 This email address is being protected from spambots. You need JavaScript enabled to view it.
mac 2 This email address is being protected from spambots. You need JavaScript enabled to view it.
.
.
.
.

 

 

# show switch switch-name running-config
.
.
.
cipher 3des-cbc
mac This email address is being protected from spambots. You need JavaScript enabled to view it.
.
.
.

Only the ciphers/MACs that are supported get added to the running-config of the EOS switch. To review the disallowed MACs/ciphers when generating the running-config of the switch, use the following show command:

# show fabric warnings feature-unsupported-on-device
# Name  Warning
-|-----|---------------------------------------------------------------------|
1 core1 This email address is being protected from spambots. You need JavaScript enabled to view it. is not a supported cipher on EOS switches
2 core1 This email address is being protected from spambots. You need JavaScript enabled to view it. is not a supported mac on EOS switches

Syslog Messages

No syslog messages are generated when the DMF Controller’s cryptographic configuration is mirrored to the managed appliances and EOS switches.

Limitations

  1. There are limitations to the HTTPS configuration (some options may cause ZTN protocol/communication and controller-to-controller communication failures). The following HTTPS protocol versions are required to be used to avoid communication failures:
    1. TLSv1.2
    2. TLSv1.3
  2. It is not apparent when a cipher/MAC is not reflected onto an EOS switch (due to it being unsupported). To ascertain this scenario,check the Controller's running-config and the switch's ZTN-generated running-config and compare them (alternatively, check the “show fabric warnings” command output to review any generated warnings).
  3. An ECDSA-based cryptographic cipher configuration inherited by the managed appliances will cause a failure in communication with the Controller.

Protocol Access Required to the DMF Controller

Management Plane Access

You can control access to the DMF Controller for specific protocols, and in the case of SSH, you can allow access only from specific IP addresses or subnetworks. The following table summarizes the TCP/UDP protocol ports that DMF uses. The CLI access-list option column shows the options for the ports that can be enabled or disabled using the CLI access-list command (config-controller-access submode). The ports listed are open by default on the Controller, except for SNMP, which is disabled by default.

These ports must also be open on any device, such as a router or firewall, that connects the management console or application to the DMF Controller.
Table 1. List of Open Ports
Protocol Port Application

CLI access-list option

 Match criteria
HTTP TCP 80 GUI auto-redirect    
HTTPS TCP 443 GUI remote access gui, applicable to Controller, Service Node, Recorder Node, Analytics Node

Default any, configurable
HTTPS TCP 8443 REST API api, applicable to Controller, Service Node, Recorder Node, Analytics Node

Default any, configurable
ICMP/ICMPv6 ICMP/ICMPv6     selected ICMP types
ICMP/ICMPv6 ICMP/ICMPv6     selected ICMP types
SNMP UDP 161, 162 SNMP, applicable to Controller, Service Node, Analytics Node snmp

Default none, configurable
SSH TCP 22 CLI remote access ssh, applicable to Controller, Service Node, Recorder Node, Analytics Node

Default any, configurable
syslog UDP 514      
vce-api UDP 7443 vCenter integration vce-api Enabled by default
Note: Be careful when configuring firewall rules for the SSH protocol, which is permitted from all subnetworks by default. The option exists to restrict SSH access to one or more specific subnetworks. However, this denies access from all other subnetworks. If no connectivity from a specified subnetwork is available, accessing the Controller is only through the local console.

Control Plane Access for DMF Controller

The following ports must be open between the DMF Controller and any connected devices. No further configuration is required if all devices are in the same Layer 2 network as the DMF Controller. However, if any DMF nodes or fabric switches connect over a Layer 3 network, these ports must be open on any firewalls or routers that connect the devices to the DMF Controller.
Table 2. DMF Controller
Protocol Port Direction Application In Flows Out Flows
TCP 22 Both Directions SSH Customer

Switches, managed appliances
TCP 49 Out TACACS+  

Customer

TACACS+ server
TCP 53 Out DNS   Customer DNS server
UDP 53 Out DNS   Customer DNS server
UDP 67 Out DHCP   Customer DHCP server
UDP 68 In DHCP Customer DHCP server  
TCP 80 In HTTP Switches  
UDP 123 Both Directions NTP

Switches, Service Node, Recorder Node, Analytics Node

 Customer NTP server
UDP 161 In SNMP Customer  
UDP 162 Out SNMP Traps   Customer
TCP 443 In GUI Customer  
UDP 514 Out Syslog   Customer Syslog server
UDP 1813 Out RADIUS  

Default RADIUS accounting port
UDP 5353 In ZTN MDNS

Switches, Service Node, Recorder Node

  
TCP 6379 Out Controller Stats   Analytics Nodes
TCP 6642 Both Directions Cluster Sync Controller HA Controller HA
TCP 6653 In OpenFlow

Switches, Recorder Node, Service Node

  
TCP 7443 In VCE API vCenter API  
TCP 8443 Both Directions

Floodlight

REST API

 Customer, Recorder Node

Recorder Node, Service Node
TCP 8443 Out Controller-to-switch traffic   Fabric switches using the Switch Light OS
TCP 8843 In ZTN

Switches, Service Node, Recorder Node

  
TCP 9379 Out

Analytics Node Replicated Redis

   Analytics Node
Note:Starting from DMF release 8.5.0, Controllers use port 8443 to apply configurations to fabric switches using the Switch Light OS. In earlier releases it was port 443. If using Switch Light OS, network administrators must update the firewall configuration to permit traffic on port 8443 between Controllers and fabric switches.
To enable SNMP access to the Controller or to restrict access to the Controller for the REST API, web-based GUI access, or SSH applications, complete the following steps.

Procedure

  1. Enter the controller command from config mode to enter config-controller submode. 
    controller-1(config)# controller
controller-1(config-controller)#
  2. Enter the access-control command from config-controller submode. 
    controller-1(config-controller)# access-control
controller-1(config-controller-access)#
  3. Enter the access-list command from config-controller-access submode followed by the protocol for which you want to configure a rule.
    The protocols for which you can configure rules include the following:
    • api: Enter the config-controller-access-list submode for REST/API access to the Controller.
    • gui: Enter the config-controller-access-list submode for web-based GUI access to the Controller.
    • ns-api: Enter the config-controller-access-list submode to manage NS-API access to the Controller, for example, from OpenStack or vCenter.
    • ssh: Enter the config-controller-access-list submode for SSH access to the Controller.
    • snmp: Enter the config-controller-access-list submode for SNMP access to the Controller.

    By default, the access list for all services except for SNMP is 0.0.0.0/0, which allows access from any IPv4 subnetwork and ::/0, which allows access from any IPv6 subnetwork. For SNMP, the access list is empty, meaning access is not permitted unless specifically enabled. SNMP UDP port 161 is blocked on Controllers and fabric switches by default. You must configure an SNMP access list using the Controller's CLI to communicate using SNMP.

    For example, the following command enters config-controller-access-list submode for the SSH protocol: 
    controller-1(config-controller-access)# access-list ssh
              controller-1(config-controller-access-list)#
    When configuring the following access list on the Controller, the ACL is pushed to all connected switches, and the SNMP ACL is applied to each switch ma1 management interface. 
    controller-1(config-controller-access)# access-list snmp
controller-1(config-controller-access-list)# 1 permit from ::/0
controller-1(config-controller-access-list)# 2 permit from 10.0.0.0/8
  4. Specify the subnetworks from which access is permitted for the specified protocol. Specify the subnetwork followed by a slash and the number of bits in the subnet mask.
    For example, the following commands allow access to the SSH protocol only from the subnetwork 192.168.1.0: 
    controller-1(config-controller-access)# access-list
ssh controller-1(config-controller-access-list)# 10 permit from 192.168.1.0/24
  5. To view the current firewall configuration for the Controller, enter the show running-config command and see the access-control section.

Protocol Access Required to the DMF Controller - Sync

Sync has been added to the access list. All traffic is permitted for IPv4 (0.0.0.0/0) and IPv6 (::/0) by default. If the active standby Controller High Availability (HA) pair is deployed in different L3 subnets, permitting all traffic for sync services can be a security risk. For a secure connection between the active and standby Controller, the access list for syncing should only permit the active and standby Controller's management IP addresses.

Procedure

  1. Add a rule to permit active Controller management IP address. Do not overwrite the existing default rule for sync. Use a different rule number when adding a new rule for the sync access list. The example below shows how to configure Rule ID 3 (3 permit from 10.240.130.17/32). 
    DMF-CTL2(config)# show controller access-control access-list
#   Access-list  Rule  Action  Source
-- |----------- |---- |------ |--------- |
1  api          1     permit  ::/0
2  api          2     permit  0.0.0.0/0
3  gui          1     permit  ::/0
4  gui          2     permit  0.0.0.0/0
5  ntp          1     permit  ::/0
6  ntp          2     permit  0.0.0.0/0
7  snmp         1     permit  0.0.0.0/0
8  ssh          1     permit  ::/0
9  ssh          2     permit  0.0.0.0/0
10 sync         1     permit  ::/0
11 sync         2     permit  0.0.0.0/0
12 vce-api      1     permit  ::/0
13 vce-api      2     permit  0.0.0.0/0
DMF-CTL2(config-controller-access-list)# controller
DMF-CTL2(config-controller)# access-control
DMF-CTL2(config-controller-access)# access-list sync
DMF-CTL2(config-controller-access-list)# 3 permit from 10.240.130.17/32
DMF-CTL2(config-controller-access-list)#
  2. Add another rule to permit standby Controller management IP address. Do not overwrite the existing default rule for sync. Use a different rule number when adding a new rule for sync access list. The example below shows how to configure Rule ID 4 (4 permit from 10.240.130.16/32). 
    DMF-CTL2(config-controller-access-list)# 4 permit from 10.240.130.16/32
DMF-CTL2(config-controller-access-list)# show controller access-control access-list
#  Access-list  Rule  Action  Source
-- |----------- |---- |------ |----------------|
1  api          1     permit  ::/0
2  api          2     permit  0.0.0.0/0
3  gui          1     permit  ::/0
4  gui          2     permit  0.0.0.0/0
5  ntp          1     permit  ::/0
6  ntp          2     permit  0.0.0.0/0
7  snmp         1     permit  0.0.0.0/0
8  ssh          1     permit  ::/0
9  ssh          2     permit  0.0.0.0/0
10 sync         1     permit  ::/0
11 sync         2     permit  0.0.0.0/0
12 sync         3     permit  10.240.130.17/32
13 sync         4     permit  10.240.130.16/32
14 vce-api      1     permit  ::/0
15 vce-api      2     permit  0.0.0.0/0
DMF-CTL2(config-controller-access-list)#
  3. Remove the default permit entry. 
    DMF-CTL2(config-controller-access-list)# no 1 permit
DMF-CTL2(config-controller-access-list)# no 2 permit
DMF-CTL2(config-controller-access-list)# show controller access-control access-list
#  Access-list  Rule  Action  Source
-- |----------- |---- |------ |---------------- |
1  api          1     permit  ::/0
2  api          2     permit  0.0.0.0/0
3  gui          1     permit  ::/0
4  gui          2     permit  0.0.0.0/0
5  ntp          1     permit  ::/0
6  ntp          2     permit  0.0.0.0/0
7  snmp         1     permit  0.0.0.0/0
8  ssh          1     permit  ::/0
9  ssh          2     permit  0.0.0.0/0
10 sync         3     permit  10.240.130.17/32
11 sync         4     permit  10.240.130.16/32
12 vce-api      1     permit  ::/0
13 vce-api      2     permit  0.0.0.0/0
DMF-CTL2(config-controller-access-list)#
  4. Verify cluster state using show controller details and make sure cluster state is redundant. 
    DMF-CTL2(config)# show controller details
Cluster Name : DMF-7050
Cluster UID : a5de38214971de42aa7b51b96ac7345f4f228b20
Cluster Virtual IP : 10.240.130.18
Redundancy Status : redundant
Redundancy Description : Cluster is Redundant
Last Role Change Time : 2022-11-05 00:56:04.862000 UTC
Cluster Uptime : 2 months, 1 week
# IP            Hostname @ Node Id Domain Id State   Status    Uptime
-|-------------|--------|-|-------|---------|-------|---------|---------------|
1 10.240.130.17 DMF-CTL2 * 22049           1 active  connected 2 weeks, 2 days
2 10.240.130.16 DMF-CTL1   27671           1 standby connected 2 weeks, 2 days
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Failover History ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# New Active Time completed                 Node  Reason                Description
-|----------|------------------------------|-----|---------------------|-------------------------------------------------------|
1 22049      2022-11-05 00:55:35.994000 UTC 22049 cluster-config-change Changed connection state: cluster configuration changed
DMF-CTL2(config)#

    Removing default rules before adding the new sync access-list rules can break Controller cluster communication. To recover from this, please refer to Controller Cluster Recovery.

Control Plane Access for DMF Switches

The following ports must be open for DMF Switches to communicate with DMF Controller, Analytics Node, and other services (e.g., NTP, DHCP, etc.). No further configuration is required if all devices are in the same Layer 2 network as the DMF Controller. However, if any DMF Controller and fabric switches connect over a Layer 3 network, these ports must be open on any firewalls or routers that connect the devices to the DMF Controller.
Table 3. DMF Switch
Protocol Port Direction Application In Flows Out Flows
TCP 22 In SSH Customer, DMF Controller  
TCP/UDP 53 Out DNS   Customer DNS Server
UDP 67 Out DHCP   Customer DHCP Server
UDP 68 In DHCP Customer DHCP Server  

 

TCP

 

443*

 

In

 

cAPI*

 

DMF Controller		  
UDP 123 Out NTP   Customer NTP Server
UDP 161 In SNMP Customer  
UDP 162 Out SNMP Trap   Customer
UDP 514 Out Syslog   Customer Syslog Server
UDP 5353 Out ZTN MDNS   DMF Controller

 

TCP

 

6030

 

In

 

Telemetry*		    

 

UDP

 

6343

 

Out

 

sFlow®*		  

 

Analytics Node
UDP 6380 Out Control Packets   Analytics Nodes
TCP 6653 Out OpenFlow   DMF Controller
TCP 8443 In BigDB DMF Controller  
TCP 8843 Out ZTN   DMF Controller

Use Port 443 as Default cAPI Port

Starting from DMF Release 8.9.0, the Command-API (cAPI) client on the DMF Controller utilizes port 443 for EOS connectivity. Follow the procedure below when upgrading from using port 80.

Show Commands

Verify the HTTPS protocol and the port assignment on core switches by executing the following command:

dmf-controller-1# show switch core1 running-config | grep https
protocol https port 443

Pre-upgrade Validation

Upgrading from previous DMF versions that depend on port 80 requires configuring HTTPS on port 443 on EOS switches to maintain the ZTN functionality. A cAPI client can use port 443 for connectivity after the upgrade.

The bigtap_eos_https_port_validate utility validates this configuration as a pre-upgrade step, ensuring port availability before the upgrade rather than after it:

  • Action: Verifies port 443's availability on EOS switches.

  • Reason: Necessary for post-upgrade cAPI client connectivity.

  • Impact: Inaccessible ports result in ZTN initialization failure.

A pre-validation failure triggers the following upgrade launch error:

POST /api/v1/rpc/controller/os/upgrade/launch
Response 
{  
   "description": "Error launching upgrade: launch aborted: 
validation failed: EOS devices:   <switch_names> cannot be 
upgraded, the https port 443 is not open for connection, fix 
and retry the upgrade- Completed upgrade state cleanup on 
exception",
   "error-code": 500
}

Troubleshooting

Perform the following validation procedures to resolve ZTN state issues:

  • Verify ZTN Configuration Synchronization - Confirm the configuration sync status on managed devices by executing the following command:

    dmf-controller-1# show managed-devices all zerotouch 
# Name  Device                        Ip address     Platform                   Serial number                    Last update                    Zerotouch state 
-|-----|-----------------------------|--------------|--------------------------|--------------------------------|------------------------------|---------------
1 core1 52:54:00:58:86:3a (Linux KVM) 10.243.254.71  x86-64-bigswitch-bs3240-r0 SN-MAC-5c:16:c7:1d:bb:97         2025-09-19 12:19:37.455000 UTC ok
2 core2 52:54:00:5f:f9:a8 (Linux KVM) 10.243.254.214 x86_64-cloudeos-eos        49E66AEBA5054CA1D825B37D5B534FF6 2025-09-19 12:19:48.985000 UTC ok
3 rn1   52:54:00:88:17:cc (Linux KVM) 10.243.254.38                             Not Specified                    2025-09-19 12:19:33.533000 UTC ok
4 sn1   52:54:00:c6:66:a7 (Linux KVM) 10.243.253.62                             Not Specified                    2025-09-19 12:19:32.534000 UTC ok

  • Verify the EOS HTTPS Server Status - Validate that the HTTPS server on an EOS switch is active and listening on port 443 using the following command:

    core1(config)# show management api http-commands
Enabled: Yes
HTTPS server: running, set to use port 443
HTTP server: running, set to use port 80
Local HTTP server: shutdown, no authentication, set to use port 8080
Unix Socket server: shutdown, no authentication
VRFs: default
Hits: 62
Last hit: 0:00:10 ago
Bytes in: 11775
Bytes out: 9785
Requests: 58
Commands: 86
Duration: 8.851 seconds
SSL Profile: none
FIPS Mode: No
QoS DSCP: 0
Session Timeout: 1440 minutes
Log Level: none
CSP Frame Ancestor: None
TLS Protocols: 1.0 1.1 1.2 1.3

Control Plane Access for DMF Service Node

The following ports must be open for the DMF Service Node to communicate with the DMF Controller, Analytics Node, and other services (e.g., NTP, DHCP, etc.). No further configuration is required if all devices are in the same Layer 2 network as the DMF Controller. However, if the DMF Controller and Service Nodes connect over a Layer 3 network, these ports must be open on any firewalls or routers.

Table 4. DMF Service Node
Protocol Port Direction Application In Flows Out Flows
TCP 22 In SSH Customer, DMF Controller  
TCP 49 Out TACACS+  

Customer TACACS+ Server
TCP/UDP 53 Out DNS   Customer DNS Server
UDP 67 Out DHCP   Customer DHCP Server
UDP 68 In DHCP Customer DHCP  
UDP 123 Out NTP   Customer NTP Server
UDP 161 In SNMP Customer  
UDP 162 Out SNMP Trap  

Customer SNMP Trap Server
UDP 514 Out Syslog   Customer Syslog Server
UDP 1812 Out

Default RADIUS

Authentication port

   Customer RADIUS Server
UDP 1813 Out

Default RADIUS

Accounting port

   Customer RADIUS Server
UDP 5353 Out ZTN MDNS   DMF Controller
TCP 6030 In Telemetry    
TCP 6634 In Telemetry    
TCP 6653 Out OpenFlow   DMF Controller
TCP 8443 Both Direction

Floodlight REST

API

 DMF Controller DMF Controller
TCP 8843 Out ZTN   DMF Controller

Control Plane Access for DMF Recorder Node

The following ports must be open between the DMF Recorder Node and any connected devices. No further configuration is required if all devices are in the same Layer 2 network as the DMF Recorder Node. However, if the DMF Controller, Analytics Node, or fabric switches connect over a Layer 3 network, these ports must be open on any firewalls or routers that connect the devices to the DMF Recorder Node.

Table 5. DMF Recorder Node
Protocol Port Direction Application In Flows Out Flows
TCP 22 In SSH Customer, DMF Controller  
TCP 49 Out TACACS+  

Customer TACACS+ Server
TCP/UDP 53 Out DNS   Customer DNS Server
UDP 67 Out DHCP   Customer DHCP Server
UDP 68 In DHCP Customer DHCP Server  
UDP 123 Out NTP   Customer NTP Server
UDP 161 In SNMP Customer  
UDP 162 Out SNMP Trap  

Customer SNMP Trap Server
TCP 443 In

Stenographer

Query API

 Customer, DMF Controller  
UDP 514 Out Syslog   Customer Syslog Server
UDP 1812 Out

Default RADIUS

Authentication port

   Customer RADIUS Server
UDP 1813 Out

Default RADIUS

Accounting port

   Customer RADIUS Server
TCP 2049 Both NFS   Customer NSF Server
UDP 2049 Both NFS   Customer NFS Server
UDP 5353 Out ZTN MDNS   DMF Controller
TCP 6653 Out OpenFlow   DMF Controller
TCP 8443 Both Direction

Floodlight REST

API

 DMF Controller DMF Controller
TCP 8843 Out ZTN   DMF Controller

Control Plane Access for Analytics Node

The following ports must be open between the Analytics Node and any connected devices. No further configuration is required if all devices are in the same Layer 2 network as the Analytics Node. However, if the Analytics Node connects over a Layer 3 network, these ports must be open on any firewall or router.

Table 6. DMF Analytics Node
Protocol Port Direction Application In Flows Out Flows
TCP 22 In SSH Customer  
TCP 25   SMTP  

Analytics Nodes to Mail

Server
TCP 49 Out TACACS+  

Customer TACACS+ Server
TCP/UDP 53 Out DNS   Customer DNS Server
UDP 67 Out DHCP   Customer DHCP Server
UDP 68 In DHCP Customer DHCP Server  
UDP 123 Out NTP   Customer NTP Server
UDP 161 In SNMP Customer  
UDP 161 In SNMP

from Analytics Nodes to

DMF switch

  
UDP 162 Out SNMP Trap   Customer
UDP 162 Out SNMP Trap   From Analytics Nodes to DMF switch
TCP 443 In GUI Customer  
TCP 467   SMTP   Analytics to Mail Server
UDP 514 Out Syslog   Customer Syslog Server
UDP 1812 Out

Default RADIUS

Authentication port

   Customer RADIUS Server
UDP 1813 Out

Default RADIUS

Accounting port

   Customer RADIUS Server
UDP 2055 In NetFlow v5

DMF Service Nodes and

Switches

  
UDP 4739 In

IPFIX & NetFlow

v9

DMF Service Nodes and

Switches

  
TCP 5043 Both Direction Active Directory

Customer Active Directory

Server

Customer Active Directory

Server
UDP 6343 In

sFlow®*

 DMF Switches  
TCP 6379 Both Direction Controller Stats

Controller to Analytics

VIP

  
UDP 6380 In Control Packets DMF Switches  
TCP 6642 Both Direction

Analytics Cluster

sync

 HA controller HA controller
TCP 8443 Both Direction

Floodlight REST

API

 Customer Managed Appliances
TCP 9379 Both Direction Replicated Redis

DMF Controller to Analytics Node VIP

  
TCP 9379 Out Analytics Node

Replicated Re- dis Server (for dpid.port -> Filter Name)

   Analytics Node
* Starting from DMF release 8.9.0 the cAPI port on the Controller is automatically changed to 443 for EOS connectivity. It used to be 80 in prior releases.
*Port to be opened on firewalls for Arista switches running EOS to communicate with the DMF Controller.
*sFlow® is a registered trademark of Inmon Corp.
*sFlow® is a registered trademark of Inmon Corp.