The VLAN ID assigned to policies or filter interfaces remains unchanged after controller reboot or failover. However, it changes if the policy is removed and added back again. Also, when the VLAN range is changed, existing assignments are discarded, and new assignments are made.

The push-per-filter feature preserves the original VLAN tag, but the outer VLAN tag is rewritten with the assigned VLAN ID if the packet already has two VLAN tags.

Tag-based forwarding, which improves traffic forwarding and reduces TCAM utilization on the monitoring fabric switches, is enabled only when choosing the push-per-policy option.

controller-1> show interface-names
~~~~~~~~~~~~~~~~~~~~~~~~ Filter Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#DMF IFSwitch IF Name Dir State SpeedVLAN Tag Analytics Ip address Connected Device
--|---------------------------|-------------|------------|---|-----|------|--------|---------|----------|----------------|
1TAP-PORT-eth1 FILTER-SW1ethernet1rxup10Gbps 5True
2TAP-PORT-eth10FILTER-SW1ethernet10 rxup10Gbps 10 True
3TAP-PORT-eth12FILTER-SW1ethernet12 rxup10Gbps 11 True
4TAP-PORT-eth14FILTER-SW1ethernet14 rxup10Gbps 12 True
5TAP-PORT-eth16FILTER-SW1ethernet16 rxup10Gbps 13 True
6TAP-PORT-eth18FILTER-SW1ethernet18 rxup10Gbps 14 True
7TAP-PORT-eth20FILTER-SW1ethernet20 rxup10Gbps 16 True
8TAP-PORT-eth22FILTER-SW1ethernet22 rxup10Gbps 17 True

Analysis tools often use VLAN tags to identify the filter interface receiving traffic. How VLAN IDs are assigned to traffic depends on which auto-VLAN mode is enabled. The system automatically assigns the VLAN ID from a configurable range of VLAN IDs from 1 to 4094 by default. Available auto-VLAN modes behave as follows:

• Push per Policy (default): Automatically adds a unique VLAN ID to all traffic selected by a specific policy. This setting enables tag-based forwarding.
• Push per Filter: Automatically adds a unique VLAN ID from the default auto-vlan-range (1-4094) to each filter interface. A new vlan range can be specified using the auto-vlan-range command. Manually assign any VLAN ID not in the auto-VLAN range to a filter interface.

The following table summarizes how VLAN tagging occurs with the different Auto VLAN modes.

The following table summarizes how different Auto VLAN modes affect supported applications and services.

Tag-based forwarding, which improves traffic forwarding and reduces TCAM utilization on the monitoring fabric switches, is only enabled when choosing the push-per-policy option.

Use the CLI or the GUI to configure Auto VLAN Mode as described in the following topics.

• Configuring Auto VLAN Mode using the CLI
• Configuring Auto VLAN Mode using the GUI

The strip VLAN option removes the outer VLAN tag before forwarding the packet to a delivery interface. Only the outer tag is removed if the packet has two VLAN tags. If it has no VLAN tag, the packet is not modified. Users can remove the VLAN ID on traffic forwarded to a specific delivery interface globally for all delivery interfaces. The strip VLAN option removes any VLAN ID applied by the rewrite VLAN option.

The strip vlan option removes the VLAN ID on traffic forwarded to the delivery interface. The following are the two methods available:

• Remove VLAN IDs fabric-wide for all delivery interfaces. This method removes only the VLAN tag added by DMF Fabric.
• On specific delivery interfaces. This method has four options:
  • Keep all tags intact. Preserves the VLAN tag added by DMF Fabric and other tags in the traffic using strip-no-vlan option during delivery interface configuration.
  • Remove only the outer VLAN tag the DANZ Monitoring Fabric added using the strip-one-vlan option during delivery interface configuration.
  • Remove only the second (inner) tag. Preserves the VLAN (outer) tag added by DMF Fabric and removes the second (inner) tag in the traffic using the strip-second-vlan option during delivery interface configuration.
  • Remove two tags. Removes the outer VLAN tag added by DMF fabric and inner vlan tag in the traffic using the strip-two-vlan option during delivery interface configuration.

By default, the VLAN ID is stripped when DMF adds it to enable the following options:

• Push per Policy
• Push per Filter
• Rewrite VLAN under filter-interfaces

Tagging and stripping VLANs as they ingress and egress DMF differs depending on whether the switch is a Trident 3-based.

Use the CLI or the GUI to configure Auto VLAN Strip as described in the following topics.

• Auto VLAN Strip using the CLI
• Auto VLAN Strip using the GUI

If the Switch CRC option is enabled, which is the default, each DMF switch drops incoming packets that enter the fabric with a CRC error. The switch generates a new CRC if the incoming packet was modified using an option that modifies the original CRC checksum, which includes the push VLAN, rewrite VLAN, strip VLAN, and L2 GRE tunnel options.

If the Switch CRC option is disabled, DMF switches do not check the CRC of incoming packets and do not drop packets with CRC errors. Also, switches do not generate a new CRC if the packet is modified. This mode is helpful if packets with CRC errors need to be delivered to a destination tool unmodified for analysis. When disabling the Switch CRC option, ensure the destination tool does not drop packets having CRC errors. Also, recognize that CRC errors will be caused by modification of packets by DMF options so that these CRC errors are not mistaken for CRC errors from the traffic source.

Enable and disable CRC Check using the steps described in the following topics.

• CRC Check using the CLI
• CRC Check using the GUI

When custom priorities are allowed, non-admin users may assign policy priorities between 0 and 100 (the default value). However, when custom priorities are not allowed, the default priority of 100 will be automatically assigned to non-admin users' policies.

Enable and disable Custom Priority using the steps described in the following topics.

• Custom Priority using the CLI
• Custom Priority using the GUI

Complete the fabric switch installation in one of the following two modes:

• Layer 2 Zero Touch Fabric (L2ZTF, Auto-discovery switch provisioning mode)

  In this mode, which is the default, Switch ONIE software automatically discovers the Controller via IPv6 local link addresses and downloads and installs the appropriate Switch Light OS image from the Controller. This installation method requires all the fabric switches and the DMF Controller to be in the same Layer 2 network (IP subnet). Also, suppose the fabric switches need IPv4 addresses to communicate with SNMP or other external services. In that case, users must configure IPAM, which provides the controller with a range of IPv4 addresses to allocate to the fabric switches.

• Layer 3 Zero Touch Fabric (L3ZTF, Preconfigured switch provisioning mode)

  When fabric switches are in a different Layer 2 network from the Controller, log in to each switch individually to configure network information and download the ZTF installer. Subsequently, the switch automatically downloads Switch Light OS from the Controller. This mode requires communication between the Controller and the fabric switches using IPv4 addresses, and no IPAM configuration is required.

All the fabric switches in a single fabric must be installed using the same mode. If users have any fabric switches in a different IP subnet than the Controller, users must use Layer 3 mode for installing all the switches, even those in the same Layer 2 network as the Controller. Installing switches in mixed mode, with some switches using ZTF in the same Layer 2 network as the Controller, while other switches in a different subnet are installed manually or using DHCP is unsupported.

Enable and disable Inport Mask using the steps described in the following topics.

• Configure Inport Mask using the CLI
• Configure Inport Mask using the GUI

Enable and disable Retain User Policy VLAN using the steps described in the following topics.

• Retain User Policy VLAN using the CLI
• Retain User Policy VLAN using the GUI

For more information about Tunneling please refer to the Understanding Tunneling section.

Enable and disable Tunneling using the steps described in the following topics.

• Configure Tunneling using the GUI
• Configure Tunneling using the CLI

In DANZ Monitoring Fabric (DMF), metadata is appended to the packets forwarded by the fabric to a tool attached to a delivery interface. This metadata is encoded primarily in the outer VLAN tag of the packets.

By default (using the auto-delivery-strip feature), this outer VLAN tag is always removed on egress upon delivery to a tool.

The VLAN preservation feature introduces a choice to selectively preserve a packet's outer VLAN tag instead of stripping or preserving all of it.

VLAN preservation works in both push-per-filter and push-per-policy mode for auto-assigned and user-configured VLANs.

Policies can reuse VLANs for policies in different switch islands. A switch island is an isolated fabric managed by a single pair of controllers; there is no data plane connection between fabrics in different switch islands. For example, with a single Controller pair managing six switches (switch1, switch2, switch3, switch4, switch5, and switch6 the option exists to create two fabrics with three switches each (switch1, switch2, switch3 in one switch island and switch4, switch5, and switch6 in another switch island), as long as there is no data plane connection between switches in the different switch islands.

There is no command needed to enable this feature. If the above condition is met, creating policies in each switch island with the same policy VLAN tag is supported.

In the condition mentioned above, assign the same policy VLAN to two policies in different switch islands using the push-vlan <vlan-tag> command under policy configuration. For example, policy P1 in switch island 1 assigned push-vlan 10, and policy P2 in switch island 2 assigned the same vlan tag 10 using push-vlan 10 under policy configuration.

When a data plane link connects two switch islands, it becomes one switch island. In that case, two policies cannot use the same policy vlan tag, so one of the policies (P1 or P2) will become inactive.

A DMF fabric comprises groups of switches, known as islands, connected over the data plane. There are no data plane connections between switches in different islands. When Push-Per-Filter forwarding is enabled, monitored traffic is forwarded within an island using the VLAN ID affiliated with a Filter Interface. These VLAN IDs are configurable. Previously, the only recommended configuration was for these VLAN IDs to be globally unique.

This feature adds official support for associating the same VLAN ID with multiple Filter Interfaces as long as they are in different islands. This feature provides more flexibility when duplicating Filter Interface configurations across islands and helps prevent using all available VLAN IDs.

Note that within each island, VLAN IDs must still be unique, which means that Filter Interfaces in the same group of switches cannot have the same ID. When trying to reuse the same VLAN ID within an island, DMF generates a fabric error, and only the first Filter Interface (as sorted alphanumerically by DMF name) remains in use.

>show fabric errors filter-interface-invalid-vlan 
~~ Invalid Filter Interface VLAN(s) ~~
# 1 
DMF Namefilter1-f1
IF Name ethernet2
Switchfilter1 (00:00:52:54:00:4b:c9:bc)
Rewrite VLAN1
Details The configured rewrite VLAN 1 for filter interface filter1-f1
is not unique within its fabric. 

>show debug switch-cluster 
# Member 
-|--------------|
1 core1, filter1

>show link all
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Links ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Active State Src switch Src IF Name Dst switch Dst IF Name Link Type Since 
-|------------|----------|-----------|----------|-----------|---------|-----------------------|
1 active filter1ethernet1 core1ethernet1 normal2023-05-24 22:31:39 UTC
2 active core1ethernet1 filter1ethernet1 normal2023-05-24 22:31:40 UTC

The DANZ Monitoring Fabric (DMF) Controller configures each switch with forwarding paths based on the most efficient links between the incoming filter interface and the delivery interface, which is connected to analysis tools. The TCAM capacity of the fabric switches may limit the number of policies to configure. The Controller can also use VLAN tag-based forwarding, which reduces the TCAM resources required to implement a policy.

Tag-based forwarding is automatically enabled when the auto-VLAN Mode is push-per-policy, which is the default. This configuration improves traffic forwarding within the monitoring fabric. DMF uses the assigned VLAN tags to forward traffic to the correct delivery interface, saving TCAM space. This feature is handy when using switches based on the Tomahawk chipset because these switches have higher throughput but reduced TCAM space.

Controller lockdown mode, when enabled, disallows user configuration such as policy configuration, inline configuration, and rebooting of fabric components and disables data path event processing. If there is any change in the data path, it will not be processed.

The primary use case for this feature is a planned management switch upgrade. During a planned management switch upgrade, DANZ Monitoring Fabric (DMF) switches disconnect from the Controller, and DMF policies are reprogrammed, disrupting traffic forwarding to tools. Enabling this feature before starting a management switch upgrade will not disrupt the existing DMF policies when DMF switches disconnect from the Controller, thereby forwarding traffic to the tools.

Controller# configure
Controller(config)# system control-plane-lockdown enable
Enabling control-plane-lockdown may cause service interruption. Do you want to continue ("y" or "yes
" to continue):yes
LOCKDOWN Controller(config)#

LOCKDOWN Controller(config)# system control-plane-lockdown disable
Disabling control-plane-lockdown will bring the fabric to normal operation. This may cause some
service interruption during the transition. Do you want to continue ("y" or "yes" to continue):
yes
Controller(config)#

Switch Light OS (SWL) switches can now report their CPU queue statistics and debug counters. To view these statistics, use the DANZ Monitoring Fabric (DMF) Controller CLI. DMF exports the statistics to any connected DMF Analytics Node.

The CPU queue statistics provide visibility into the different queues that the switch uses to prioritize packets needing to be processed by the CPU. Higher-priority traffic is assigned to higher-priority queues.

The SWL debug counters, while not strictly limited to packet processing, include information related to the Packet-In Multiplexing Unit (PIMU). The PIMU performs software-based rate limiting and acts as a second layer of protection for the CPU, allowing the switch to prioritize specific traffic.

controller-1> show switch FILTER-SWITCH-1 queue cpu
# SwitchOF Port Queue ID TypeTx Packets Tx BytesTx Drops Usage 
-|-----------------|-------|--------|---------|----------|---------|--------|---------------------------------|
1 FILTER-SWITCH-1 local 0multicast 830886 164100990 0lldp, l3-delivery-arp, tunnel-arp
2 FILTER-SWITCH-1 local 1multicast 00 0l3-filter-arp, analytics
3 FILTER-SWITCH-1 local 2multicast 00 0
4 FILTER-SWITCH-1 local 3multicast 00 0
5 FILTER-SWITCH-1 local 4multicast 00 0sflow
6 FILTER-SWITCH-1 local 5multicast 00 0
7 FILTER-SWITCH-1 local 6multicast 00 0l3-filter-icmp

controller-1> show switch FILTER-SWITCH-1 debug-counters 
#SwitchNameValue Description 
--|-----------------|-------------------------------|-------|-------------------------------------------|
1FILTER-SWITCH-1 arpra.total_in_packets1183182 Packet-ins recv'd by arpra
2FILTER-SWITCH-1 debug_counter.register79Number of calls to debug_counter_register
3FILTER-SWITCH-1 debug_counter.unregister21Number of calls to debug_counter_unregister
4FILTER-SWITCH-1 pdua.total_pkt_in_cnt 1183182 Packet-ins recv'd by pdua
5FILTER-SWITCH-1 pimu.hi.drop8 Packets dropped
6FILTER-SWITCH-1 pimu.hi.forward 1183182 Packets forwarded
7FILTER-SWITCH-1 pimu.hi.invoke1183190 Rate limiter invoked
8FILTER-SWITCH-1 sflowa.counter_request9325983 Counter requests polled by sflowa
9FILTER-SWITCH-1 sflowa.packet_out 7883772 Sflow datagrams sent by sflowa
10 FILTER-SWITCH-1 sflowa.port_features_update 22Port features updated by sflowa
11 FILTER-SWITCH-1 sflowa.port_status_notification 428 Port status notif's recv'd by sflowa

The counter values shown are based on the last time the statistics were cleared.

Add the name or the ID token and a debug counter name or ID to filter the output.

Add the details token to view more information. This includes the debug counter ID, the absolute (or raw) counter values, the last updated time, and the last cleared time.

controller-1# clear statistics debug-counters

controller-1# clear statistics

Before the DANZ Monitoring Fabric (DMF) 8.6 release, DMF performed filtering at the filter port based on policy match rules. Thus, the system delivered the same traffic to all policy deliveries and tools associated with those delivery ports.

Egress Filtering introduces an option to send different traffic to each tool attached to the policy's delivery setting. It provides additional filtering at the delivery ports based on the egress filtering rules specified at the interface.

DMF supports egress filtering on the delivery and recorder node interfaces and supports configuring IPv4 and IPv6 rules on the same interface. Only packets with an IPv4 header are subject to the rules associated with the IPv4 token, while packets with an IPv6 header are only subject to the rules associated with the IPv6 token.

Egress Filtering applies to switches running SWL OS and does not apply to Extensible Operating System (EOS) switches.

The DANZ Monitoring Fabric (DMF) allows the integration and monitoring of VMs in a VMware vCenter cluster. After integrating a vCenter with the DMF fabric, use DMF policies to select different types of traffic from specific VMs and apply managed services, such as deduplication or header slicing, to the selected traffic.

Currently, DMF supports the following versions of VMware vCenter for monitoring:

• vCenter Server 6.5.0
• vCenter Server 6.7.0
• vCenter Server 7.0.0
• vCenter Server 8.0.0

The DANZ Monitoring Fabric provides two options to monitor a VMware vCenter cluster:

This section describes the configuration required to integrate the DANZ Monitoring Fabric (DMF) Controller with one or more vCenter instances and to monitor traffic from VMs connected to the VMware vCenter after integration.

The following figure illustrates the topology required to integrate a vCenter instance with the monitoring fabric and deliver the traffic selected by DMF policies to specified delivery ports connected to different monitoring tools.

When integrated with vCenter, the DMF Controller uses Link Layer Discovery Protocol (LLDP) to automatically identify the available filter interfaces connected to the vCenter instance.

Use Remote SPAN (ERSPAN) to monitor VMs running on the ESX hosts within a VMware vCenter instance integrated with the DANZ Monitoring Fabric (DMF). ERSPAN monitors traffic to and from VMs anywhere in the network and does not require a dedicated physical interface card on the ESX host. However, ERSPAN can affect network performance, especially when monitoring VMs connected to the DMF Controller over WAN links or production networks with high utilization.

The procedure for deploying ERSPAN is similar to SPAN but requires an additional step to define the tunnel endpoints used on the DMF network to terminate the ERSPAN session.

Predefine the tunnel endpoints for creating tunnels when monitoring VMware vCenter traffic using either the GUI or the CLI.

GUI Procedure

To manage tunnel endpoints in the GUI, select Monitoring > Tunnel Endpoints.

This page lists the tunnel endpoints that are already configured and provides information about each endpoint.

To create a new tunnel endpoint, click the provision (+) control in the Tunnel Endpoints table.

To create the tunnel endpoint, enter the following information and click Save:

• Name: Type a descriptive name for the endpoint.
• Switch: Select the DMF switch from the selection list for the configured endpoint interface.
• Interface: Select the interface from the selection list for the endpoint.
• Gateway: Type the address of the default gateway.
• IP Address: Type the endpoint IP address.
• Mask: Type the subnet mask for the endpoint.

controller-1(config)# tunnel-endpoint <name> switch <switch> <interface> ip-address <address> mask
<mask> gateway <address>

controller-1(config)# tunnel-endpoint ERSPAN switch CORE-SWITCH ethernet7 ip-address 172.27.1.1
mask 255.255.255.0 gateway 172.27.1.2

Refer to the following topics to monitor VMs using Encapsulated Remote SPAN (ERSPAN) or Switch Port Analyzer (SPAN) on a locally connected vCenter instance and VMs on a second locally connected vCenter instance.

• Monitoring VMs using ERSPAN on a Locally Connected vCenter Instance
• Monitoring VMs using SPAN on a Locally Connected vCenter Instance
• Monitoring VMs on a Second Locally Connected vCenter Instance

After integrating a vCenter instance, click the link in the Name column in the vCenter table to view vCenter activity.

DANZ Monitoring Fabric (DMF) displays the vCenter Info page.

DANZ Monitoring Fabric (DMF) vCenter integration supports mirroring from vCenter hosts using the default TCP/IP stack. However, this can result in traffic drops and affect production traffic since mirror traffic can conflict with production traffic. DMF vCenter integration with Mirror Stack provides the functionality to use the mirror TCP/IP stack for mirror sessions. Mirror stack in the ESXi host allows decoupling the traffic and keeps the production traffic unaffected.

vCenter configurations in DMF will use a mirror stack by default; however, if upgrading from previous DMF versions, the already configured vCenter will be set to use the default TCP/IP stack.

The current implementation of VMware vCenter creates one tunnel interface from every ESXi host to DMF.

Using a wildcard tunnel on DMF for VMware vCenter reduces the number of tunnels created.

Platform Compatibility

This feature is only compatible with switches that support wildcard tunneling.

Match VMware vCenter-specific information in the policy. Specifically, this feature matches traffic using VMware vCenter Virtual Machine (VM) names and requires DANZ Monitoring Fabric (DMF) vCenter integration.

DANZ Monitoring Fabric (DMF) supports VXLAN tunnel type and Level-2 Generic Routing Encapsulation (L2GRE). The tunnel type is a per-switch configuration, setting the switch pipeline to VXLAN or L2GRE. Once the switch pipeline is set, all tunnels configured on the switch will use the same tunnel type.

The encapsulation type can be configured in the GUI while adding a new switch into the DMF Controller, as shown in the figure below:

The encapsulation type can be edited for an existing switch from the Fabric > Switches > Configure Switch page, as shown in the figure below:

Ctrl-1(config)# switch Switch-1
Ctrl-1(config-switch)# tunnel-type
gre Select GRE as the tunnel type of the switch. (default selection)
vxlan Select VxLAN as the tunnel type of the switch.

Ctrl-1(config)# show switch
# Switch Name IP AddressState Pipeline Mode
-|-------------------|---------------------------|---------|----------------------------------|
1 Switch-1fe80::d6af:f7ff:fef9:e2b0%9 connected l3-l4-offset-match-push-vlan-vxlan
2 Switch-2fe80::e6f0:4ff:fe69:6aee%9connected l3-l4-offset-match-push-vlan
3 Switch-3fe80::e6f0:4ff:fe78:1ffe%9connected l3-l4-offset-match-push-vlan-vxlan
Ctrl-1(config)#

In the above CLI output, Switch-1 and Switch-3 use the VXLAN tunnel type, as seen in the Pipeline Mode column. Switch-2 is using the L2GRE tunnel type.

Tunnels can be used as a core link, filter interface, or delivery interface. The most common use case is linking multiple sites, using the tunnel as a core link. If used as a core link, DMF automatically discovers the link as if it were a physical link and similarly determines connectivity (link-state). If the tunnel goes down for any reason, DMF treats the failure as it would a physical link failure.

Another typical use case for the tunnel is as a filter interface to decapsulate L2 GRE/VXLAN tunneled production traffic or a tunnel initiated by another DMF instance managed by a different DMF Controller. Use the tunnel endpoint as a delivery interface to encapsulate filtered monitoring traffic to send to analysis tools or another DANZ Monitoring Fabric managed by a different DMF Controller.

To view or modify the configuration of an existing tunnel, use the Fabric > Interfaces option. To view the tunnel configuration, expand the interface. DMF displays the tunnel configuration as illustrated in the following figure.

Tip: When multiple interfaces are present, use the Filter feature to locate tunnel interfaces after typing the first few letters of the word tunnel.

The expanded row displays the status and other properties of the tunnel configured for the selected interface. Use the Menu control and select Configure Tunnel to modify the tunnel configuration. Select Delete Tunnel to remove the tunnel.

With an L2-GRE or VXLAN tunnel, matching traffic on a user-defined offset results in dropping interesting traffic. The tunnel header throws off the offset calculation, and the selected traffic may be dropped. This behavior is due to how switch hardware calculates the anchor and offset concerning incoming packets. When the core link is a tunnel, the anchor and offset calculation differs when encapsulating packets compared to when decapsulating.

Avoid matching on user-defined offsets when the ingress filter interface is a tunnel by filtering on the user-defined offset before the traffic enters a tunnel used as a filter interface. This preserves the LLDP messaging on the core tunnel link, but it requires an extra physical loopback interface on the encapsulating switch. The figure below illustrates both of these workarounds. In either case, a UDF match is applied to the ingress traffic on filter interface F. For example, the policy might apply a match at offset 20 after the start of the L4 header. In both workarounds, the policy has been split into two policies:

P1: F to D1, match on user-defined offset P2: F1 to D, match any.

In the example on the left, the ingress interface on the decapsulating switch, which is included in a core tunnel link, no longer has to calculate the user-defined offset. This solution preserves LLDP messages on the tunnel link but requires an extra loopback interface.

In the example on the right, the tunnel endpoints are configured as filter and delivery interfaces. This solution avoids using the tunnel as a core link and does not require an extra physical loopback interface. However, LLDP updates are lost on the tunnel link.

The Wildcard tunneling feature allows the DANZ Monitoring Fabric (DMF) to decapsulate L2GRE-based tunneled traffic from any remote source. This feature, supported on Switch Light OS (SWL) based DMF switches in prior releases, now allows wildcard tunnels on Arista EOS-based DMF switches.

Platform Compatibility

EOS switches with Jericho2 or higher ASICs compatible with DMF 8.5.0 that support L2GRE tunneling. L2GRE tunneling on EOS SAND platforms is only supported on Arista 7280R3 switches.

DMF provides a configurable method of hashing for load distribution among LAG members. The enhanced hashing algorithm automatically assigns the best hashing type for the switch and traffic. This setting allows the manual selection of the packet types and fields used for load distribution among the members of a port-channel interface. Enhanced mode and symmetric hashing are enabled by default for the supported switch platforms. With symmetric hashing, bidirectional traffic between two hosts going out on a port channel is distributed on the same member port.

DMF supports Link Aggregation Groups (LAGs) that allow 2 or more physical interfaces on the same DMF switch to be aggregated into 1 logical interface to increase the aggregate bandwidth and provide link redundancy against link failure. This feature works well if all the tools connect to the same DMF delivery switch, typically when co-locating customer tools in the same physical location. However, in cases where tools reside in different data centers or physical locations, where a single DMF switch cannot connect to all the tools, load balancing across two DMF delivery switches is required.

A pseudo-multi-chassis Link Aggregation Group (MLAG) provides redundancy for each delivery switch connected to a multi-homed tool. With MLAG, traffic is hashed on the upstream DMF switch across two active-active links toward the delivery switches. If one of the switches fails, the traffic will fail over to the healthy switch.

• An MLAG domain cannot have more than two switches.
• A switch can only be a part of one MLAG domain.
• An MLAG interface can only have two member interfaces.
• An MLAG interface can only have one interface (physical interface or LAG interface) from each peer switch.
• Tunnel interfaces are not supported as members in MLAG interface configuration.

Link Layer Discovery Protocol (LLDP) is used to discover MLAG links. When the DMF Controller receives an LLDP message, it looks for the switch and interface names. If the switch is a part of an MLAG domain, and the reported interface corresponds to the MLAG interface, then it is classified as an MLAG link.

Controller-1(config)# show link all link-type mlag-member
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Links ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Active State Src switchSrc IF Name Dst switchDst IF Name Link Type Since
-|------------|-----------------|-----------|-----------------|-----------|-----------|-----------------------|
1 active CoreSwitch-1ethernet10DeliverySwitch-1ethernet50mlag-member 2022-11-11 21:54:28 UTC
2 active CoreSwitch-1ethernet20DeliverySwitch-2ethernet50mlag-member 2022-11-11 21:54:28 UTC
3 active DeliverySwitch-1ethernet50CoreSwitch-1ethernet10mlag-member 2022-11-11 21:54:28 UTC
4 active DeliverySwitch-2ethernet50CoreSwitch-1ethernet20mlag-member 2022-11-11 21:54:13 UTC
Controller-1(config)#

To configure an MLAG domain from the GUI, go to the Fabric > MLAGs tab.

Click on Create MLAG Domain and enter the following:

• Domain Name: Enter the MLAG domain alias.
  • Peer Switch 1: From the drop-down, select the first switch that will be participating in the MLAG domain.
  • Peer Switch 2: From the drop-down, select the second switch that will be participating in the MLAG domain.
• MLAG Interfaces: Enter an alias for the fabric-facing MLAG interface. This interface connects the core switch to the peer switches in the MLAG domain.
  • Peer Switch 1 and Peer Switch 2: After selecting peer switches under the domain name, the peer switches under the MLAG interface will automatically be selected.
  • Interface 1: Select the member interface that connects the core switch to DeliverySwitch-1
  • Interface 2: Select the member interface that connects the core switch to DeliverySwitch-2.
• MLAG Delivery Interfaces: Enter an alias for each MLAG delivery interface.
  • DMF Interface Name: Enter the DMF interface name for the MLAG delivery interface. This alias will be used to identify the delivery interface while configuring the DMF policy.
  • Strip VLAN on Egress: Select the strip VLAN configuration for the MLAG delivery interface
  • Peer Switch 1 and Peer Switch 2: These will be automatically selected based on the peer switches selected under the domain name.
  • Interface 1: Select the member interface on Peer Switch 1.
  • Interface 2: Select the member interface on Peer Switch 2.

Click Create to save the configuration.

The above screenshot displays the MLAG domain status. Click + to expand each MLAG interface's domain configuration and status of each MLAG interface.

To configure an MLAG policy, go to the Monitoring > Policies page.

Select + Create Policy to add a new policy.

Click + Add Ports in Destination Tools and select or drag the MLAG interface to associate with the policy.

Click Add 1 Interface and enter the following to configure the policy association.

Click Create Policy.

To view the MLAG links, go to Fabric > Links > MLAG Member Links tab.

The above screenshot shows the MLAG links established between the core switch and the peer switches that are part of the MLAG domain. The LLDP message exchange discovers the links.

An overlapping policy is dynamically configured if two configured policies share at least one filter interface and at least one of the delivery interfaces is different.

The following policies, Policy-1 and Policy-2, share the same filter interface, Filter-1, but are configured to use different delivery interfaces, MLAG-Tool-1 and MLAG-Tool-2. No priority is configured; these policies use the same default priority.

policy Policy-1
action forward
delivery-interface MLAG-Tool-1
filter-interface Filter-1
1 match ip src-ip 200.200.0.0 255.255.255.0

policy Policy-2
action forward
delivery-interface MLAG-Tool-2
filter-interface Filter-1
1 match ip dst-ip 100.100.0.0 255.255.255.0

Controller-1(config)# show policy
# Policy NameActionRuntime Status Type Priority Overlap Priy Push VLAN Filter BW Delivery BW Post Match Filt Traff Del Traffic Services
-|----------------------|-------|--------------|----------|--------|------------|---------|---------|-----------|----------------------|----------|--------|
1 Policy-1 forward installedConfigured1000 125Gbps80Gbps314Mbps315Mbps
2 Policy-2 forward installedConfigured1000 325Gbps80Gbps314Mbps315Mbps
3 _Policy-1_o_Policy-2 forward installedDynamic 1001 525Gbps80Gbps314Mbps315Mbps

• Policy-1: User-configured policy to forward packets matching source IP 200.200.0.0/24 to MLAG-Tool-1.
• Policy-2: User-configured policy to forward packets matching destination IP 100.100.0.0/24 to MLAG-Tool-2.
• _Policy-1_o_Policy-2: A dynamically configured overlapping policy with higher Overlap Priority to ensure that if a packet matches rules from both the policies (source IP of 200.200.0.1 and destination IP of 100.100.0.1), it forwards to both MLAG-Tool-1 and MLAG-Tool-2.

The following are the dynamic policies configured for each delivery switch in the MLAG Domain.

Policy-1 Dynamic Policies

• _mlag_Policy-1_DeliverySwitch-1: MLAG dynamic policy for Policy-1 for DeliverySwitch-1.
• _mlag_Policy-1_DeliverySwitch-2: MLAG dynamic policy for Policy-1 for DeliverySwitch-2.

Policy-2 Dynamic Policies

• _mlag_Policy-2_DeliverySwitch-1: MLAG dynamic policy for Policy-2 for DeliverySwitch-1.
• _mlag_Policy-2_DeliverySwitch-2: MLAG dynamic policy for Policy-2 for DeliverySwitch-2.

_Policy-1_o_Policy-2 Dynamic Policies

The following policies have higher Overlap Priority than the rest to prioritize the overlapping traffic forwarded to DeliverySwitch-1 and DeliverySwitch-2.

• _mlag Policy-1_o_Policy-2_DeliverySwitch-1: MLAG dynamic policy for overlapping policy for DeliverySwitch-1.
• _mlag Policy-1_o_Policy-2_DeliverySwitch-2: MLAG dynamic policy for overlapping policy for DeliverySwitch-2.

The DANZ Monitoring Fabric (DMF) Recorder Node (RN) integrates with the DMF for single-pane-of-glass monitoring. A single DMF Controller can manage multiple RNs, delivering packets for recording through Out-of-Band policies. The DMF Controller also provides central APIs for packet queries across one or multiple RNs and for viewing errors, warnings, statistics, and the status of connected RNs.

A DMF out-of-band policy directs matching packets for recording to one or more RNs. An RN interface identifies the switch and port used to attach the RN to the fabric. A DMF policy treats these as delivery interfaces and adds them to the policy so that flows matching the policy are delivered to the specified RN interfaces.

At a high level, follow the below three steps to use the Recorder Node (RN).

Step 1: Define the RN.

Step 2: Define a DANZ Monitoring Fabric (DMF) policy to select the traffic to forward to the RN.

Step 3: View and analyze the recorded traffic.

The Recorder Node (RN) indexing configuration defines the fields used to query packets on the RN. By default, DMF enables all indexing fields in the indexing configuration. Selectively disable the specific indexing fields not required in RN queries.

Disabling indexing fields has two advantages. First, it reduces the index space required for each packet recorded. Second, it improves query performance by reducing unnecessary overhead. Arista recommends disabling unnecessary indexing fields.

To understand leveraging an indexing configuration, consider the following examples:

Example 1: To query packets based on applications defined by unique transport ports, disable all indexing fields except source and destination transport ports, saving only transport ports as metadata for each packet recorded. This technique greatly reduces per-packet index space consumption and increases RN query speed.

However, this will impact an effective query on any other indexing field because that metadata was not saved when the packets were recorded.

Example 2: The RN supports community ID indexing, a hash of IP addresses, IP protocol, and transport ports that identify a flow of interest. Suppose the RN use case is to query based on community ID. In that case, indexing on IPv4 source and destination addresses, IPv6 source and destination addresses, IP protocol, and transport port source and destination addresses might be redundant.

The Recorder Node (RN) pre-buffer is a circular buffer recording received packets. When enabled, the pre-buffer feature allows for the retention of the packets received by the RN for a specified length of time prior to an event that triggers the recording of buffered and future packets to disk. Without an event, the RN will record into this buffer, deleting the oldest packets when the buffer reaches capacity.

When an RN event is triggered, DMF saves packets in the pre-buffer to disk. The packets received from the time of the event trigger to the time of the event termination are saved directly to disk upon termination of the event. However, the received packets are also retained in the pre-buffer until the next event is triggered. By default, the pre-buffer feature is disabled, indicated by a value of zero minutes.

For example, when configuring the pre-buffer to thirty minutes, the buffer will receive up to thirty minutes of packets. When triggering an event, DMF records the packets currently in the buffer to disk, and packets newly received by the RN bypass the buffer and are written directly to disk until the termination of the event. When terminating the event, the pre-buffer resets, accumulating received packets for up to the defined thirty-minute pre-buffer size.

The packets affiliated with an event can be queried, replayed, or analyzed using any RN query. Each triggered event is identified by a unique, user-supplied name, used in the query to reference packets recorded in the pre-buffer before and during the event.

When using a DANZ Monitoring Fabric (DMF) Controller authentication token, the Recorder Node (RN) treats the DMF Controller as an ordinary client, requiring it to present valid credentials either in the form of an HTTP basic username and password or an authentication token.

Static authentication tokens are pushed to each RN as an alternative form of authentication in headless mode when the DMF Controller is unreachable or by third-party applications that do not have or do not need Controller credentials.

To forward traffic to a Recorder Node (RN), include one or more RN interfaces as a delivery interface in a DANZ Monitoring Fabric (DMF) policy.

When creating a new policy or editing an existing policy, select the RN interfaces from the Monitoring > Policies dialog, as shown in the following screen.

To create a policy, select Destination Tools > Add Ports(s) and use the RN Fabric Interface to select a previously configured RN interface. Select or drag the Interfaces or Recorder Nodes to add Destination Tools.

View Recorder Node (RN) submitted queries using the GUI or CLI.

To view the query history using the DANZ Monitoring Fabric (DMF) GUI, select Monitoring > Recorder Nodes and scroll down to the Query History section.

The Query History section displays the queries submitted to each RN and the query status.

To download the query results, select Download Results from the Menu control for a specific query. To export the query history, click the Export control at the top of the table (highlighted in the figure above, to the right of the Refresh control).

controller-1> show recorder-node query-history
# Packet Recorder Query Type StartDuration
---|---------------|-----------------------------------------------------------------------|------------------------|----------------------------|--------|
1 HW-PR-2 after 10m ago analysis-hosts 2019-03-20 09:52:38.021000 PDT 3428
2 HW-PR-1 after 10m ago analysis-hosts 2019-03-20 09:52:38.021000 PDT 3428
3 HW-PR-2 after 10m ago abort2019-03-20 09:52:40.439000 PDT 711
4 HW-PR-1 after 10m ago abort2019-03-20 09:52:40.439000 PDT 711
---------------------------------------------------------------------output truncated---------------------------------------------------------------------

Use Role-Based Access Control (RBAC) to manage access to the DANZ Monitoring Fabric (DMF) Recorder Node (RN) by associating the RN with an RBAC group.

To restrict access for a specific RN to a specific RBAC group, use the CLI or GUI as described below.

This section describes monitoring and troubleshooting the Recorder Node (RN) status and operation. The RN stores packets on the main hard disk and the indices on the SSD volumes.

View Recorder Node (RN) statistics by clicking the RN alias from the Monitoring > Recorder Nodes page.

Click a Recorder Node to display the available recorder node statistics. All statistics are disabled or hidden by default.

Enable or view statistics by clicking on them. Selected statistics appear as highlighted in blue.

The RN shows health statistics for the following:

CPU: CPU health displays the compute resource utilization of the recorder node.

Memory: DMF displays memory-related stats such as total memory, used, free, available, etc.

Storage: Storage health displays the storage utilization percentage and total and available capacity of Index and Packet virtual disks.

Time-based Disk Utilization Statistics: Time-based Disk Utilization Statistics provides an estimated time period until the Index and Packet virtual disks reach full storage capacity. This estimate is calculated based on data points (incoming data rate) collected periodically from the RN for a certain duration.

Note: Inaccurate data may appear if the collected data points are insufficient to calculate the disk-full estimate. However, once sufficient data points are collected, the estimate recalculates and updates automatically.

Virtual Disks: Virtual Disk's health stats display the Index and Packet virtual disks' size, state, health, and RAID level configuration.

Click on the drop-down arrow next to the virtual disk name to obtain information regarding participating physical disks, such as slot numbers, type, size, state, temperature, and Dell’s Self Monitoring Analysis and Report Technology (SMART) stats, such as errors and failures, if any.

File Descriptors: the File Descriptor section displays the following:

• File Descriptors (current): Current number of files open in the entire system.
• Max System File Descriptors: Highest number of open files allowed on the entire system.
• Max Stenographer File Descriptors: Highest number of open files allowed for Stenographer application.

Mount: The Mount section displays the Index and Packet disk mount information, such as volume name, mount point, file system type, and mount health.

Stenographer: Stenographer Statistics are displayed as follows:

• Initialized: Displays the Stenographer application running state. A green check mark indicates the application was successfully initialized. When the Stenographer application starts, a red x mark appears and disallows recording and querying during this time, which is expected behavior.
• Tracked Files: Tracked files are the total number of files stored under each CPU instance thread.
• Cached Files: Cached files are the number of open files with a file descriptor.
• Max Cached Files: The maximum cached files are the total openable files allowed.

These numbers are further divided and displayed for each recording thread and viewable in the Recording Threads table:

Recording: Recording stats displays packet stats, such as dropped packets, total packets, and collection time for each CPU core.

The following displays packet size distribution stats.

The following displays interface errors, such as CRC errors, frame length errors, and back pressure errors:

controller-1(config)# recorder-node device <instance>

Replace instance with the alias to use for the RN. This alias is affiliated with the MAC hardware address using the mac command.

TACACS configuration does not have a merge option. It can either be inherited from the DMF Controller or overridden to use only the RN-specific configuration.

Access the RN via a web browser to run large PCAP queries to the Recorder Node (RN). This allows running packet queries directly to the RN without specifying the maximum byte or packet limit for the PCAP file (which is required when executing the query from the DANZ Monitoring Fabric (DMF) Controller).

To access the RN directly, use the URL https://RecorderNodeIP in a web browser, as shown below:

The following page will be displayed:

• Recorder Node IP Address: Enter the target RN IP address.
• DMF Controller Username: Provide the DMF Controller username.
• DMF Controller Password: Provide the password for authentication.
• Stenographer Query Filter: Use the query filter to filter the query results to look for specific packets. For example, to search for packets with a source IP address of 10.0.0.145 in the last 10 minutes, use the following filter:

  after 10m ago and src host 10.0.0.145

• Stenographer Query ID: Starting in DMF 8.0, a Universally Unique Identifier (UUID) is required to run queries. To generate a UUID, run the following command on any Linux machine and use the result as the Stenographer query ID:

  $ uuidgen
  b01308db-65f2-4d7c-b884-bb908d111400

• Save pcap as: Provide the file name for this PCAP query result.
• Submit Request: Sends a query to the specified RN and saves the PCAP file with the provided file name to the default download location for the browser.

The following commands are available from the Recorder Node (RN):

RecNode(config)# show version
Controller Version : DMF Recorder Node 8.1.0 (bigswitch/enable/dmf-8.1.x #5)
RecNode(config)#

RecNode(config)# show controllers
controllerRole State Aux
---------------------|------|---------|---|
tcp://10.106.8.2:6653 master connected 0
tcp://10.106.8.3:6653 slaveconnected 0
tcp://10.106.8.3:6653 slaveconnected 1
tcp://10.106.8.3:6653 slaveconnected 2
tcp://10.106.8.2:6653 master connected 1
tcp://10.106.8.2:6653 master connected 2
RecNode(config)#

Use the GUI to run multiple Recorder Node (RN) queries.

To run queries on recorded packets by the RN, navigate to the Monitoring > Recorder Nodes page.

Under the Query section, click on the Query Type drop-down to select the type of analysis to run on the recorded packets, as shown below:

After selecting the query type, use filters to limit or narrow the search to obtain specific results. Providing specific filters also helps to complete the query analysis faster. In the following example, the query result for the TCP query type will return the results for IP address 10.240.30.24 for the past 10 minutes.

After entering the desired filters, click on the Submit button. The Progress dialog will be displayed, showing the Elapsed Time and Progress percentage of the running query:

While a query is in progress, initiate another query from a new DANZ Monitoring Fabric (DMF) Controller web session. View the query progress under the Active Queries section:

For Recorder Node queries, the recorded packets matching a specified query filter may contain duplicates when packet recording occurs at several different TAPs within the same network; i.e., as a packet moves through the network, it may be recorded multiple times. The dedup feature removes duplicate packets from the query results. By eliminating redundant information, packet deduplication improves query results' clarity, accuracy, and conciseness. Additionally, the dedup feature significantly reduces the size of query results obtained from packet query types.

Enable egress sFlow^®* to sample traffic sent to any DANZ Monitoring Fabric (DMF) Recorder Node (RN) attached to the fabric. Examining these sampled packets on a configured sFlow collector allows the identification of post-match-rule flows recorded by the RNs without performing a query against the RNs. While not explicitly required, Arista Networks highly recommends using the DMF Analytics Node (AN) as the configured sFlow collector, as it can automatically identify packets sampled utilizing this feature.

The Recorder Node (RN) recording statistics API on the DANZ Monitoring Fabric (DMF) Controller includes information about the operational state of the ongoing recording.

The information is available in device/state/packet-recorder/recording/recording-state where recording-state is the container holding the opstate information.

Within the container, there are the following two values:

• state: an enumeration describing the recording opstate that has one of the following values: initializing, ready, active, and stopped.
• description: a string describing the state in more detail.

The following table lists the possible recording state values and describes how to interpret each scenario.

Additionally, the type of logical disk volume used by each recording thread is part of the RN recording statistics API on the DMF Controller.

This information is available in device/state/packet-recorder/recording/recording-thread/disk where a disk is an enumeration having one of two values, primary or backup, if the thread is recording to the primary or backup configured logical disk volume, respectively. This is a simplified version of the path. The disk type does not imply whether the disk volume is local or remote, as the storage configuration determines this.

C1> show recorder-node device <rn name> recording-health
~~~~~~~~~~~~~~~~ Recording Application~~~~~~~~~~~~~~~~
Recording Collection Time: 2024-04-23 15:12:30 UTC
Recording CRC Errors : 0
Recording Frame Length Errors: 0
Recording Back Pressure Errors : 0
Recording Undersized Frames: 0
Recording Frames 64B : 0
Recording Frames 65-127B : 0
Recording Frames 128-255B: 0
Recording Frames 256-511B: 0
Recording Frames 512-1023B : 0
Recording Frames 1024-1522B: 0
Recording Frames 1523-9522B: 0
Recording Oversized Frames : 0
Recording state: Active

~~~~~~~~~~~~~~~~~~~~~~~ Recording Instance~~~~~~~~~~~~~~~~~~~~~~~
Core DiskDropped Packets Total Packets Collection Start Time
----|-------|---------------|-------------|-----------------------|
1primary 0 204 2024-04-23 15:00:34 UTC

C1> show recorder-node device <rn name> recording-health details
~~~~~~~~~~~~~~~~ Recording Application~~~~~~~~~~~~~~~~
Recording Collection Time: 2024-04-23 15:12:30 UTC
Recording CRC Errors : 0
Recording Frame Length Errors: 0
Recording Back Pressure Errors : 0
Recording Undersized Frames: 0
Recording Frames 64B : 0
Recording Frames 65-127B : 0
Recording Frames 128-255B: 0
Recording Frames 256-511B: 0
Recording Frames 512-1023B : 0
Recording Frames 1024-1522B: 0
Recording Frames 1523-9522B: 0
Recording Oversized Frames : 0
Recording state: Active
Recording state Details: Recording traffic.

~~~~~~~~~~~~~~~~~~~~~~~ Recording Instance~~~~~~~~~~~~~~~~~~~~~~~
Core DiskDropped Packets Total Packets Collection Start Time
----|-------|---------------|-------------|-----------------------|
1primary 0 204 2024-04-23 15:00:34 UTC

C1> show recorder-node device <rn name> recording-health
~~~~~~~~~~~~~~~~ Recording Application~~~~~~~~~~~~~~~~
Recording Collection Time: 2024-04-23 15:12:30 UTC
Recording CRC Errors : 0
Recording Frame Length Errors: 0
Recording Back Pressure Errors : 0
Recording Undersized Frames: 0
Recording Frames 64B : 0
Recording Frames 65-127B : 0
Recording Frames 128-255B: 0
Recording Frames 256-511B: 0
Recording Frames 512-1023B : 0
Recording Frames 1024-1522B: 0
Recording Frames 1523-9522B: 0
Recording Oversized Frames : 0
Recording state: Active

~~~~~~~~~~~~~~~~~~~~~~~ Recording Instance~~~~~~~~~~~~~~~~~~~~~~~
Core DiskDropped Packets Total Packets Collection Start Time
----|-------|---------------|-------------|-----------------------|
1backup0 204 2024-04-23 15:00:34 UTC

C1> show recorder-node device <rn name> recording-health details
~~~~~~~~~~~~~~~~ Recording Application~~~~~~~~~~~~~~~~
Recording Collection Time: 2024-04-23 15:12:30 UTC
Recording CRC Errors : 0
Recording Frame Length Errors: 0
Recording Back Pressure Errors : 0
Recording Undersized Frames: 0
Recording Frames 64B : 0
Recording Frames 65-127B : 0
Recording Frames 128-255B: 0
Recording Frames 256-511B: 0
Recording Frames 512-1023B : 0
Recording Frames 1024-1522B: 0
Recording Frames 1523-9522B: 0
Recording Oversized Frames : 0
Recording state: Active
Recording state Details: Recording traffic.

~~~~~~~~~~~~~~~~~~~~~~~ Recording Instance~~~~~~~~~~~~~~~~~~~~~~~
Core DiskDropped Packets Total Packets Collection Start Time
----|-------|---------------|-------------|-----------------------|
1backup0 204 2024-04-23 15:00:34 UTC

C1> show recorder-node warnings

~ RAID Health Warning(s) ~
None.

~ Low Disk Space Warning(s) ~
None.

~ Full Disk Warning(s) ~
None.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Non Active Recorder Node Warning(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Recorder Node Message
-|-------------|----------------------------------------------------------------------------------|
1 rn1 Inactive Recording State: Ready - Ready to record, no recordable traffic received.

The DANZ Monitoring Fabric (DMF) Service Node has multiple interfaces connected to traffic for processing and analysis. Each interface can be programmed independently to provide any supported managed-service actions.

To create a managed service, identify a switch interface connected to the service node, specify the service action, and configure the service action options.

Configure a DMF policy to use the managed service by name. This action causes the Controller to forward traffic the policy selects to the service node. The processed traffic is returned to the monitoring fabric using the same interface and sent to the tools (delivery interfaces) defined in the DMF policy.

If the traffic volume the policy selects is too much for a single service node interface, define an LAG on the switch connected to the service node, then use the LAG interface when defining the managed service. All service node interfaces connected to the LAG are configured to perform the same action. The traffic the policy selects is automatically load-balanced among the LAG member interfaces and distributes the return traffic similarly.

controller-1(config)# service-node <service_node_alias>
controller-1(config-service-node)#

Replace service_node_alias with the alias to use for the service node. This alias is affiliated with the hardware MAC address of the service node using the mac command. The hardware MAC address configuration is mandatory for the service node to interact with the DMF Controller.

To view, edit, or create DANZ Monitoring Fabric (DMF) managed services, select the Monitoring > Managed Services option.

This page displays the service node appliance devices connected to the DMF Controller and the services configured on the Controller.