Select Aggregate GRETAP from the Action drop-down to open the configuration menu. Configure the following fields:

• Delivery Interface - select from a list of available interfaces.
• UDP Port - Default value of4739
• Collector IP - Configure an IP address as the Collector IP.
• MTU - Default value of 1500
• Idle Timeout - Default value of5000 ms

Select Aggregate sFlow from the Action drop-down to open the configuration menu. Configure the following fields:

• Delivery Interface
• UDP Port (Default: 4739)
• Collector IP
• MTU (Default: 1500)
• Idle Timeout (Default: 5000 ms)

Application Identification - Early Field Trial (EFT)

Select App ID from the Action drop-down to open the configuration menu. Configure the following fields:

• Delivery Interface
• UDP Port (Default: 4739)
• Collector IP
• MTU (Default: 1500)

App ID Filter

Application Identification Filter - Early Field Trial (EFT)

Restriction: The Application Identification features described in the Managed Service section are Early Field Trial (EFT) and should not be used in production networks.

Select App ID Filter from the Action drop-down to open the configuration menu. Configure the following fields:

• Filter
• App Categories
• App Names

The DANZ Monitoring Fabric (DMF) Service Node enhances the efficiency of network monitoring tools by eliminating duplicate packets. Duplicate packets can be introduced into the out-of-band monitoring data stream by receiving the same flow from multiple TAP or SPAN ports spread across the production network. Deduplication eliminates these duplicate packets and enables more efficient use of passive monitoring tools.

GUI Configuration

Choose the desired managed service from the Managed Service Dashboard and select + Add Action.

Use the Configured Managed Service Action (name) and enter a sequence number and select Deduplication from the drop-down Action list.

Select the following fields as required:

• Anchor Offset: Packet Start, L3 Header Start, L4 Header Start, or L4 Payload Start fields.
• Offset: Applies to Anchor Offset function and is the number of bytes from the anchor where the deduplication check begins.
• Full Packet: All bytes in packet.
• Header Routed Packet: Header routed frame.
• Payload Routed Packet: Payload routed frame.
• Window Size: Applies to all Packet Handling functions. The time window in which the service looks for duplicate packets is configurable. Select a value among these choices: 2ms (the default), 4ms, 6ms, and 8ms.

After completing the necessary configuration, select Save followed by Done in the Managed Service Details window.

Select Filter from the Action drop-down to open the configuration menu. Configure a Default Action and optionally a Forwarding VLAN for forward actions.

• The default action applies to all ACL rules upon installation but can be overridden for individual rules.
• Select Add ACL to configure multiple ACL rules.

1. Enter a Sequence number.
2. Select an IP protocol from the IP Protocol list.
3. Select an action, Drop or Forward, from the Action list.
4. Enter a forwarding VLAN number in the Push VLAN field.
5. Enter a source IP address in the Source IP Address field.
6. Enter a source IP mask in the Source IP Mask field.
7. Add a source port number ora range of source ports using the Source Port menu.
8. Enter a destination IP address in the Dest. IP Address field.
9. Enter a destination IP mask in the Dest. IP Mask field.
10. Add a source port number ora range of source ports using the Dest. Port menu.
11. Click Save to save the configuration on the switch.

Latency and drop information help determine if there is a loss in a particular flow and where the loss occurred. A Service Node action configured as a DANZ Monitoring Fabric (DMF) managed service has multiple separate taps or spans in the production network and can measure the latency of a flow traversing through any pair of these points. It can also detect packet drops between any two points in the network if the packet only appears on one point within a specified time frame, currently set to 200ms.

Latency and drop analysis require Precision Time Protocol (PTP) time-stamped packets. The DMF PTP timestamping feature applies these timestamps as packets enter the monitoring fabric.

The Service Node accumulates latency values by flow and sends IPFIX data records with each flow's 5-tuple and ingress and egress identifiers. It sends IPFIX data records to the Analytics Node after collecting a specified number of values for a flow or when a timeout occurs for the flow entry. The threshold count is 10,000 packets, and the flow timeout is 4 seconds.

Use the DMF Analytics Node to build custom dashboards to view and check the data.

Select Flow Latency and Drops from the Action drop-down. The configuration menu is divided into the following tabs:

• Info
• Tap Point Pair
• Tap Point Multicast Groups

Info Tab

Select the Info tab to open the configuration menu. Configure the following fields:

• Delivery Interface
• Collector IP
• UDP Port
• MTU
• Delivery Requirement
• Report Types

Tap Point Pair Tab

Select the Tap Point Pair tab to view the configuration table. The table displays the following columns:

• Source Type
• Source Name
• Destination Type
• Destination Name

Add Entry: Select Add to open the configuration menu.

Source Type: The Source Type drop-down includes the following options:

• Filter Interface
• Policy Name
• Filter Interface Group

Name Selection: The Name drop-down options update dynamically based on the selected Source Type.

Tap Point Multicast Groups Tab

Select the Tap Point Multicast Groups tab to access the configuration.

• Use the multi-select drop-down to integrate Multicast groups with Flow Latency and Drops actions.

Select GTP Correlation from the Action drop-down to open the configuration menu. Configure the following fields:

• Idle Timeout
• Sampling Rate
• Correlation Profile
• APN Group
• Rewrite Option
• Drop Control

Correlation Profile Selection

Select one of the following options for the Correlation Profile. The menu updates dynamically to display the corresponding drop-down field:

• IMSI Group
• IMEI Group
• MSISDN Group

See GTP Correlation Profiles for more information about configuring profiles.

Select Header Strip from the Action drop-down to open the configuration menu. Configure the Anchor, Offset, and L2 Header options.

L2 Header Options

Choose one of the following configurations for the L2 Header:

• Option 1: Use Existing L2 Header
  • Assumes an existing L2 header is present.
  • Retains the existing Source MAC, Destination MAC, and EtherType without modification.
• Option 2: Inherit from Stripped L2 Header
  • Inherits Source MAC and Destination MAC from the stripped L2 header.
  • Select one of the following EtherType options:
    • Use original EtherType
    • Insert Inet EtherType
    • Use custom EtherType
• Option 3: Add Custom L2 Header
  • Adds a completely custom L2 header.
  • Select one of the following EtherType options:
    • Insert Inet EtherType
    • Add custom EtherType

Header Strip Actions

GUI Configuration

Under the Action drop-down, select the desired Header Strip action.

After assigning the required actions to the header stripping service, select Next or Post-Service Match.

The system displays the Post Service Match page, used in conjunction with the header strip service action.

 

Select IPFIX from the Action drop-down to open the configuration menu. Configure the following fields:

• Delivery Interface
• UDP Port
• Collector IP
• MTU
• Inactive Timeout
• Active Timeout
• Template Timeout
• IPFIX Template

The Masking action can hide specific characters in a packet, such as a password or credit card number, based on offsets from different anchors and by matching characters using regular (regex) expressions. The Mask Service Action applies the specified mask to the matched packet region.

Select Mask from the Action drop-down to open the configuration menu. Configure the following fields:

• Match Pattern
• Anchor
• Offset
• Match Characters

Match Characters Configuration

Enable Match Characters to display and configure the following additional fields:

• Mask Start
• Mask End

Select NetFlow from the Action drop-down to open the configuration menu. Configure the following fields:

• Delivery Interface
• UDP Port
• Collector IP
• MTU
• Inactive Timeout
• Active Timeout
• Flows
• Per-Interface Records

Select Pattern Drop from the Action drop-down to open the configuration menu. Configure the following fields:

• Pattern
• Anchor
• Offset

The Pattern Drop Service Action drops matching traffic.

Pattern matching allows Session-aware Adaptive Packet Filtering (SAPF) to identify HTTPS transactions on non-standard SSL ports. It can filter custom applications and separate control traffic from user data traffic.

Pattern matching is also helpful in enforcing IT policies, such as identifying hosts using unsupported operating systems or dropping unsupported traffic. For example, the Windows OS version can be identified and filtered based on the user-agent field in the HTTP header. The user-agent field may appear at variable offsets, so a regular expression search is used to identify the specified value wherever it occurs in the packet.

GUI Configuration

Select Pattern Match from the Action drop-down to open the configuration menu. Configure the following fields:

• Pattern
• Anchor
• Offset

The pattern-match service action matches and forwards matching traffic and is similar to the pattern-drop service action.

Pattern matching allows Session-aware Adaptive Packet Filtering (SAPF) to identify HTTPS transactions on non-standard SSL ports. It can filter custom applications and separate control traffic from user data traffic.

Pattern matching is also helpful in enforcing IT policies, such as identifying hosts using unsupported operating systems or dropping unsupported traffic. For example, the Windows OS version can be identified and filtered based on the user-agent field in the HTTP header. The user-agent field may appear at variable offsets, so a regular expression search is used to identify the specified value wherever it occurs in the packet.

GUI Configuration

This release adds a new managed service action, called Record, to the Service Node (SN). This action enables packet recording using an SN similar to a Recorder Node (RN) and supports basic packet recording and querying capabilities.

The SN accumulates packets, writes packet data to local storage disks, and indexes information based on configured fields. Various query types retrieve recorded packets, analyze traffic patterns, and investigate network issues.

The Controller includes the managed service action record to enable packet recording on an SN.

Select Record from the Action drop-down to open the configuration menu.

Select Regex Session from the Action drop-down to open the configuration menu. Configure the following fields:

• Anchor
• Offset
• Pattern
• IP Protocol
• Regex Session Table Size
• TCP Idle Timeout
• UDP Timeout

Select SIP Mask from the Action drop-down to open the configuration menu. Configure the following fields:

• UDP Port
• TCP Port

Select Sample from the Action drop-down to open the configuration menu. Configure the following fields:

• Max Tokens
• Tokens Per Refresh

Session-slice keeps track of TCP and UDP sessions (distinguished by source and destination IP address and port) and counts the number of packets sent in each direction (client-to-server and vice versa). After recognizing the session, the action transmits a user-configured number of packets to the tool node.

For TCP packets, session-slice tracks the number of packets sent in each direction after establishing the TCP handshake. Slicing begins after the packet count in a direction has reached the configured threshold in both directions.

For UDP packets, slicing begins after reaching the configured threshold in either direction.

By default, session-slice will operate on both TCP and UDP sessions but is configurable to operate on only one or the other.

Refer to the DANZ Monitoring Fabric (DMF) Verified Scale Guide for session-slicing performance numbers.

Select Session Slice from the Action drop-down to open the configuration menu. Configure the following fields:

• Slice After (based on number of Packets)
• Idle Timeout

Select Slice from the Action drop-down to open the configuration menu. Configure the following fields:

• Insert Original Packet length
• Anchor
• Offset

This page allows inserting an additional header containing the original header length.

The Dapper action (derived from Brown University research) identifies TCP session issues by measuring specific connection attributes. This analysis determines whether performance degradation stems from the client, server, or network devices. All current Service Node platforms support the Dapper action.

The action monitors TCP session packets, tracks extensive statistics, and periodically exports them via IPFIX records to a collector. For every session direction, the system generates:

• One Start-Session record.
• One or more Data records.
• One End-Session record.

The collector evaluates these statistics, utilizing six distinct IPFIX templates to diagnose the root cause of network problems.

Select TCP Analysis from the Action drop-down to open the configuration menu. Configure the following fields:

• Delivery Interface
• UDP Port
• Collector IP
• MTU
• Include Dapper Elements
• Max Samples

Select Timestamp from the Action drop-down to open the configuration menu.

GUI Configuration

The UDP-replication service action copies UDP messages, such as Syslog or NetFlow messages, and sends the copied packets to a new destination IP address.

Configure a rate limit when enabling UDP replication. When upgrading from a version of DANZ Monitoring Fabric (DMF) before release 6.3.1, the UDP-replication configuration is not applied until a rate limit is applied to the delivery interface.

CONTROLLER-1(config)# switch DMF-DELIVERY-SWITCH-1
                CONTROLLER-1(config-switch)# interface ethernet1
                CONTROLLER-1(config-switch-if)# role delivery interface-name udp-delivery-1
                CONTROLLER-1(config-switch-if)# rate-limit 256000

GUI Configuration

Select UDP Replication from the Action drop-down to open the configuration menu. Configure the following fields:

• Delivery Interface
• Input Packet Destination IP
• Output Packet Destination IP

Use the UDP-replication service to copy UDP traffic, such as Syslog messages or NetFlow packets, and send the copied packets to a new destination IP address. This function sends traffic to more destination syslog servers or NetFlow collectors than would otherwise be allowed.

Add the IP address in the dialog that appears.

Adding Multiple Output IPs

For the header-strip service action only, configure the policy rules for matching traffic after applying the header-strip service action. After completing pages 1-4, select Append and enable the checkbox to apply the policy.

Select Save to save the managed service.

controller-1# show managed-service-device SN-Name interfaces
controller-1# show managed-service-device SN-Name stats

For example, the following command shows the managed services handled by the Service Node Interface (SNI):

The Load column shows no, low, moderate, high, and critical health indicators. These health indicators are represented by green, yellow, and red under DANZ Monitoring Fabric > Managed Services > Devices > Service Stats . They reflect the processor load on the service node interface at that instant but do not show the bandwidth of the respective data port (SNI) handling traffic, as shown in the following sample snapshot of the Service Stats output.

The following table provides a consolidated reference of the Filter Managed Service Action specifications, configuration limits, and operational behaviors.

There are no new configurations in the Sharing Managed Services Across Policies feature, but several configuration validations surrounding the managed service configuration within a policy have changed:

• Removed the validation that prevented adding an L3 header modifying managed service to multiple policies.
• A validation was added to enforce the order of shared managed services.

When sharing multiple managed services with at least one action that requires an L3 delivery interface, the only valid case is where non-UDP replicate L3 services are followed by UDP replicate:

• Invalid: any non UDP replicate → any non UDP replicate.
• Invalid: UDP replicate → any non UDP replicate.
• Invalid: UDP replicate → UDP replicate.
• Valid: any non UDP replicate → UDP replicate.

There are two fundamental exceptions to the earlier examples:

• The push-per-filter mode doesn’t allow multiple header modifying services in a policy.
• Flow diff is only supported in push-per-filter mode and cannot be chained with UDP replicate.

The following is a sample configuration sharing a Netflow managed service across two policies.

Configure an L3 delivery interface:

dmf-controller> enable
dmf-controller# configure
dmf-controller(config)# switch sw1
dmf-controller(config-switch)# interface ethernet31
dmf-controller(config-switch-if)# role delivery interface-name l3-d1 ip-address 0.0.0.1 nexthop-ip 0.0.0.1 255.255.255.0 nexthop-arp-interval 5
dmf-controller(config-switch-if)# rate-limit 1000

Create two managed services, one that is non-shareable and one with netflow, which can be shared:

Non-shared Managed Service

dmf-controller> enable
dmf-controller# configure
dmf-controller(config)# managed-service ms-non-shareable
dmf-controller(config-managed-srv)# service-interface switch sw1 ethernet2
dmf-controller(config-managed-srv)# 1 action sample
dmf-controller(config-managed-srv-sample)# max-tokens 100
dmf-controller(config-managed-srv-sample)# tokens-per-refresh 10

Shared Managed Service

dmf-controller> enable
dmf-controller# configure
dmf-controller(config)# managed-service ms-netflow
dmf-controller(config-managed-srv)# service-interface switch sw1 ethernet1
dmf-controller(config-managed-srv)# 1 action netflow
dmf-controller(config-managed-srv-netflow)# collector 0.0.0.2 udp-port 2055 mtu 1500
dmf-controller(config-managed-srv-netflow)# l3-delivery-interface l3-d1

Configure two policies, where the first policy, p1, has both ms-non-shareable and ms-netflow in order, and the second policy, p2, only has ms-netflow:

Policy 1

dmf-controller> enable
dmf-controller# configure
dmf-controller(config)# managed-service policy p1
dmf-controller(config-policy)# action forward
dmf-controller(config-policy)# 1 match any
dmf-controller(config-policy)# filter-interface f1
dmf-controller(config-policy)# use-managed-service ms-non-shareable sequence 1
dmf-controller(config-policy)# use-managed-service ms-netflow sequence 2

Policy 2

dmf-controller> enable
dmf-controller# configure
dmf-controller(config)# managed-service policy p2
dmf-controller(config-policy)# action forward
dmf-controller(config-policy)# 1 match any
dmf-controller(config-policy)# filter-interface f2
dmf-controller(config-policy)# use-managed-service ms-netflow sequence 1

In push-per-policy mode, both p1 and p2 are expected to be installed to send traffic to the ms-netflow pre-service interface, and a dynamic post-service policy p1_p2__post_to_delivery__ is created to carry the traffic from the post-service interface of ms-netflow to l3-d1.

In push-per-filter mode, a post service policy is created regardless of whether a managed service is shared or not. The result is two post service policies, p1__post_to_delivery__ and p2__post_to_delivery__, which will carry traffic from their respective configured policies to the delivery interface via the configured services.

The following section shows the runtime state of these policies.

While no new show commands accompany the Sharing Managed Services Across Policies feature, use the following existing commands to verify the configuration.

Use the show running-config switch sw1 interface l3 interface command to view the configured L3 interface:

dmf-controller> show running-config switch sw1 interface ethernet31

! switch
switch sw1
  !
  interface ethernet31
    force-link-up
    rate-limit 1000
    role delivery interface-name l3-d1 ip-address 0.0.0.1 nexthop-ip 0.0.0.2 255.255.255.0 nexthop-arp-interval 5

Use the show running-config managed-service command to view the managed service running config:

dmf-controller> show running-config managed-service

! managed-service
managed-service ms-netflow
  service-interface switch sw1 ethernet1
  !
  1 action netflow
    collector 10.0.0.2 udp-port 2055 mtu 1500
    l3-delivery-interface l3-d1

managed-service ms-non-shareable
  service-interface switch sw1 ethernet2
  !
  1 action sample
    max-tokens 100
    tokens-per-refresh 10

Use the show running-config policy to view the policy running config:

dmf-controller> show running-config policy

! policy
policy p1
  action forward
  filter-interface f1
  use-managed-service ms-netflow sequence 2
  use-managed-service ms-non-shareable sequence 1
  1 match any

policy p2
  action forward
  filter-interface f2
  use-managed-service ms-netflow sequence 1
  1 match any

Use the show switch sw1 interface l3 interface command to view the runtime status of the interface:

dmf-controller> show switch sw1 interface ethernet31
# IF Name    MAC Address                Config State Adv. Features Curr Features Supported Features
-|----------|--------------------------|------|-----|-------------|-------------|------------------|
1 ethernet31 5c:16:c7:14:46:bb (Arista) up     up    10g           10g           10g

Use the show managed-service command to view the runtime status of the managed services:

dmf-controller># show managed-service
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Managed-service ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Service Name     Switch Switch Interface Installed Max Post-Service BW Max Pre-Service BW Total Post-Service BW Total Pre-Service BW
-|----------------|------|----------------|---------|-------------------|------------------|---------------------|--------------------|
1 ms-netflow       sw1    ethernet1        True      10Gbps              10Gbps             974bps                66bps
2 ms-non-shareable sw1    ethernet2        True      10Gbps              10Gbps             960bps                66bps

Push-per-policy Mode

The show policy command displays a brief version of runtime state of all policies, including those created dynamically:

dmf-controller> show policy
# Policy Name               Action  Runtime Status Type       Priority Overlap Priority Push VLAN Filter BW Delivery BW Post Match Filter Traffic Delivery Traffic Services         Installed Time          Installed Duration  Ptp Timestamping
-|-------------------------|-------|--------------|----------|--------|----------------|---------|---------|-----------|-------------------------|----------------|----------------|-----------------------|-------------------|----------------|
1 p1                        forward installed      Configured 100      0                1         10Gbps    10Gbps      -                         -                ms-non-shareable 2025-02-20 18:18:33 UTC 20 minutes, 46 secs False
2 p2                        forward installed      Configured 100      0                2         10Gbps    10Gbps      -                         -                                 2025-02-20 18:18:33 UTC 20 minutes, 46 secs False
3 p1_p2__post_to_delivery__ forward installed      Dynamic    100      0                3         10Gbps    10Gbps      -                         -                                 2025-02-20 18:18:33 UTC 20 minutes, 46 secs False

The show policy policy name command provides a more detailed view of a policy at runtime.

Since a new post-service policy is required for shared services in push-per-policy mode (in the push-per-filter mode, a post-service policy, shared or not, is always created), the configured policies are adjusted accordingly. So, p1 and p2 will neither have a ms-netflow service nor will l3-d1 be the delivery interface.

p1 carries traffic from f1 to ms-non-shareable and then delivers it to ms-netflow.

dmf-controller> show policy p1
Policy Name                            : p1
Config Status                          : active - forward
Runtime Status                         : installed
Detailed Status                        : installed - installed to forward
Priority                               : 100
Overlap Priority                       : 0
# of switches with filter interfaces   : 1
# of switches with delivery interfaces : 1
# of switches with service interfaces  : 1
# of filter interfaces                 : 1
# of delivery interfaces               : 1
# of core interfaces                   : 0
# of services                          : 1
# of pre service interfaces            : 1
# of post service interfaces           : 1
Push VLAN                              : 1
Post Match Filter Traffic              : -
Total Delivery Rate                    : -
Total Pre Service Rate                 : -
Total Post Service Rate                : -
Overlapping Policies                   : p1_p2__post_to_delivery__,
Component Policies                     : none
Runtime Service Names                  : ms-non-shareable
Installed Time                         : 2025-02-20 18:18:33 UTC
Installed Duration                     : 23 minutes, 18 secs
Timestamping enabled                   : False
~ Match Rules ~
# Rule
-|-----------|
1 1 match any

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Filter Interface(s)  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF Switch IF Name    State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|------|------|----------|-----|---|-------|-----|--------|--------|------------------|
1 f1     sw1    ethernet11 up    rx  0       0     0        -

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Delivery Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF                             Switch IF Name   State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|----------------------------------|------|---------|-----|---|-------|-----|--------|--------|------------------|
1 sw1  -ethernet1-to-managed-service sw1    ethernet1 up    tx  2       140   0        -

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Service Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Service name     Role         Switch IF Name   State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|----------------|------------|------|---------|-----|---|-------|-----|--------|--------|------------------|
1 ms-non-shareable pre-service  sw1    ethernet2 up    tx  0       0     0        -
2 ms-non-shareable post-service sw1    ethernet2 up    rx  2       140   0        -

~ Core Interface(s) ~
None.

~ Failed Path(s) ~
None.

p2 carries traffic from f2 to ms-netflow.

dmf-controller> show policy p2
Policy Name                            : p2
Config Status                          : active - forward
Runtime Status                         : installed
Detailed Status                        : installed - installed to forward
Priority                               : 100
Overlap Priority                       : 0
# of switches with filter interfaces   : 1
# of switches with delivery interfaces : 1
# of switches with service interfaces  : 0
# of filter interfaces                 : 1
# of delivery interfaces               : 1
# of core interfaces                   : 0
# of services                          : 0
# of pre service interfaces            : 0
# of post service interfaces           : 0
Push VLAN                              : 2
Post Match Filter Traffic              : -
Total Delivery Rate                    : -
Total Pre Service Rate                 : -
Total Post Service Rate                : -
Overlapping Policies                   : p1_p2__post_to_delivery__,
Component Policies                     : none
Installed Time                         : 2025-02-20 18:18:33 UTC
Installed Duration                     : 23 minutes, 21 secs
Timestamping enabled                   : False
~ Match Rules ~
# Rule
-|-----------|
1 1 match any

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Filter Interface(s)  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF Switch IF Name    State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|------|------|----------|-----|---|-------|-----|--------|--------|------------------|
1 f2     sw1    ethernet12 up    rx  0       0     0        -

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Delivery Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF                             Switch IF Name   State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|----------------------------------|------|---------|-----|---|-------|-----|--------|--------|------------------|
1 sw1-ethernet1-to-managed-service   sw1    ethernet1 up    tx  0       0     0        -

~ Service Interface(s) ~
None.

~ Core Interface(s) ~
None.

~ Failed Path(s) ~
None.

p1_p2__post_to_delivery__ receives traffic from ms-netflow, and then delivers it to l3-d1.

dmf-controller> show policy p1_p2__post_to_delivery__
Policy Name                            : p1_p2__post_to_delivery__
Config Status                          : active - forward
Runtime Status                         : installed
Detailed Status                        : installed - installed to forward
Priority                               : 100
Overlap Priority                       : 0
# of switches with filter interfaces   : 1
# of switches with delivery interfaces : 1
# of switches with service interfaces  : 0
# of filter interfaces                 : 1
# of delivery interfaces               : 1
# of core interfaces                   : 0
# of services                          : 0
# of pre service interfaces            : 0
# of post service interfaces           : 0
Push VLAN                              : 3
Post Match Filter Traffic              : -
Total Delivery Rate                    : -
Total Pre Service Rate                 : -
Total Post Service Rate                : -
Overlapping Policies                   : none
Component Policies                     : p1, p2,
Installed Time                         : 2025-02-20 18:18:33 UTC
Installed Duration                     : 23 minutes, 28 secs
Timestamping enabled                   : False
~ Match Rules ~
None.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Filter Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF                             Switch IF Name   State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|----------------------------------|------|---------|-----|---|-------|-----|--------|--------|------------------|
1 sw1-ethernet1-to-managed-service   sw1    ethernet1 up    rx  1       70    0        -

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Delivery Interface(s)  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF Switch IF Name    State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|------|------|----------|-----|---|-------|-----|--------|--------|------------------|
1 l3-d1  sw1    ethernet31 up    tx  1       70    0        -

~ Service Interface(s) ~
None.

~ Core Interface(s) ~
None.

~ Failed Path(s) ~
None.

Another way of visualizing this runtime state is illustrated in the following diagram:

Push-per-filter Mode

The show policy command displays a brief version of the runtime state of all policies, including any created dynamically:

dmf-controller> show policy
# Policy Name            Action  Runtime Status                    Type       Priority Overlap Priority Push VLAN Filter BW Delivery BW Post Match Filter Traffic Delivery Traffic Services   Installed Time          Installed Duration  Ptp Timestamping
-|----------------------|-------|---------------------------------|----------|--------|----------------|---------|---------|-----------|-------------------------|----------------|----------|-----------------------|-------------------|----------------|
1 p1                     forward installed                         Configured 100      0                0         10Gbps    10Gbps      -                         -                           2025-02-20 19:13:39 UTC 15 minutes, 29 secs False
2 p2                     forward installed                         Configured 100      0                0         10Gbps    10Gbps      -                         -                           2025-02-20 19:13:39 UTC 15 minutes, 29 secs False
3 p1__post_to_delivery__ forward installed                         Dynamic    100      0                0         10Gbps    10Gbps      -                         -                ms-netflow 2025-02-20 19:13:39 UTC 15 minutes, 29 secs                                            False
4 p2__post_to_delivery__ forward installed                         Dynamic    100      0                0         10Gbps    10Gbps      -                         -                           2025-02-20 19:13:39 UTC 15 minutes, 29 secs False

The show policy policy name command provides a more detailed view of a policy at runtime:

p1 carries traffic from f1 to ms-non-shareable service.

dmf-controller> show policy p1
Policy Name                            : p1
Config Status                          : active - forward
Runtime Status                         : installed
Detailed Status                        : installed - installed to forward
Priority                               : 100
Overlap Priority                       : 0
# of switches with filter interfaces   : 1
# of switches with delivery interfaces : 1
# of switches with service interfaces  : 0
# of filter interfaces                 : 1
# of delivery interfaces               : 1
# of core interfaces                   : 0
# of services                          : 0
# of pre service interfaces            : 0
# of post service interfaces           : 0
Push VLAN                              : 0
Post Match Filter Traffic              : -
Total Delivery Rate                    : -
Total Pre Service Rate                 : -
Total Post Service Rate                : -
Overlapping Policies                   : p1__post_to_delivery__,
Component Policies                     : none
Installed Time                         : 2025-02-20 19:13:39 UTC
Installed Duration                     : 17 minutes, 55 secs
Timestamping enabled                   : False
~ Match Rules ~
# Rule
-|-----------|
1 1 match any

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Filter Interface(s)  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF Switch IF Name    State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|------|------|----------|-----|---|-------|-----|--------|--------|------------------|
1 f1     sw1    ethernet11 up    rx  0       0     0        -

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Delivery Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF                             Switch IF Name   State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|----------------------------------|------|---------|-----|---|-------|-----|--------|--------|------------------|
1 sw1-ethernet2-to-managed-service   sw1    ethernet2 up    tx  0       0     0        -

~ Service Interface(s) ~
None.

~ Core Interface(s) ~
None.

~ Failed Path(s) ~
None.

p2 carries traffic from f1 to ms-netflow service.

dmf-controller> show policy p2
Policy Name                            : p2
Config Status                          : active - forward
Runtime Status                         : installed
Detailed Status                        : installed - installed to forward
Priority                               : 100
Overlap Priority                       : 0
# of switches with filter interfaces   : 1
# of switches with delivery interfaces : 1
# of switches with service interfaces  : 0
# of filter interfaces                 : 1
# of delivery interfaces               : 1
# of core interfaces                   : 0
# of services                          : 0
# of pre service interfaces            : 0
# of post service interfaces           : 0
Push VLAN                              : 0
Post Match Filter Traffic              : -
Total Delivery Rate                    : -
Total Pre Service Rate                 : -
Total Post Service Rate                : -
Overlapping Policies                   : p2__post_to_delivery__,
Component Policies                     : none
Installed Time                         : 2025-02-20 19:13:39 UTC
Installed Duration                     : 18 minutes, 44 secs
Timestamping enabled                   : False
~ Match Rules ~
# Rule
-|-----------|
1 1 match any

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Filter Interface(s)  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF Switch IF Name    State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|------|------|----------|-----|---|-------|-----|--------|--------|------------------|
1 f2     sw1    ethernet12 up    rx  0       0     0        -

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Delivery Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF                             Switch IF Name   State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|----------------------------------|------|---------|-----|---|-------|-----|--------|--------|------------------|
1 sw1-ethernet1-to-managed-service   sw1    ethernet1 up    tx  0       0     0        -

~ Service Interface(s) ~
None.

~ Core Interface(s) ~
None.

~ Failed Path(s) ~
None.

p1__post_to_delivery__ carries traffic from ms-non-shareable to ms-netflow and then to l3-d1.

dmf-controller> show policy p1__post_to_delivery__
Policy Name                            : p1__post_to_delivery__
Config Status                          : active - forward
Runtime Status                         : installed
Detailed Status                        : installed - installed to forward
Priority                               : 100
Overlap Priority                       : 0
# of switches with filter interfaces   : 1
# of switches with delivery interfaces : 1
# of switches with service interfaces  : 1
# of filter interfaces                 : 1
# of delivery interfaces               : 1
# of core interfaces                   : 0
# of services                          : 1
# of pre service interfaces            : 1
# of post service interfaces           : 1
Push VLAN                              : 0
Post Match Filter Traffic              : -
Total Delivery Rate                    : -
Total Pre Service Rate                 : -
Total Post Service Rate                : -
Overlapping Policies                   : none
Component Policies                     : p1,
Runtime Service Names                  : none
Timestamping enabled                   : False
~ Match Rules ~
None.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Filter Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF                             Switch IF Name   State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|----------------------------------|------|---------|-----|---|-------|-----|--------|--------|------------------|
1 sw1-ethernet2-to-managed-service   sw1    ethernet2 up    rx  0       0     0        -

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Delivery Interface(s)  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF Switch IF Name    State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|------|------|----------|-----|---|-------|-----|--------|--------|------------------|
1 l3-d1  sw1    ethernet31 up    tx  0       0     0        -

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Service Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Service name Role         Switch IF Name   State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|------------|------------|------|---------|-----|---|-------|-----|--------|--------|------------------|
1 ms-netflow   pre-service  sw1    ethernet1 up    tx  0       0     0        -
2 ms-netflow   post-service sw1    ethernet1 up    rx  0       0     0        -

~ Core Interface(s) ~
None.

~ Failed Path(s) ~
None.

p2__post_to_delivery__ carries traffic from ms-netflow to l3-d1.

dmf-controller> show policy p2__post_to_delivery__
Policy Name                            : p2__post_to_delivery__
Config Status                          : active - forward
Runtime Status                         : installed
Detailed Status                        : installed - installed to forward
Priority                               : 100
Overlap Priority                       : 0
# of switches with filter interfaces   : 1
# of switches with delivery interfaces : 1
# of switches with service interfaces  : 0
# of filter interfaces                 : 1
# of delivery interfaces               : 1
# of core interfaces                   : 0
# of services                          : 0
# of pre service interfaces            : 0
# of post service interfaces           : 0
Push VLAN                              : 0
Post Match Filter Traffic              : -
Total Delivery Rate                    : -
Total Pre Service Rate                 : -
Total Post Service Rate                : -
Overlapping Policies                   : none
Component Policies                     : p2,
Installed Time                         : 2025-02-20 19:13:39 UTC
Installed Duration                     : 22 minutes, 19 secs
Timestamping enabled                   : False
~ Match Rules ~
None.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Filter Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF                             Switch IF Name   State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|----------------------------------|------|---------|-----|---|-------|-----|--------|--------|------------------|
1 sw1-ethernet1-to-managed-service   sw1    ethernet1 up    rx  0       0     0        -

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Delivery Interface(s)  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF Switch IF Name    State Dir Packets Bytes Pkt Rate Bit Rate Counter Reset Time
-|------|------|----------|-----|---|-------|-----|--------|--------|------------------|
1 l3-d1  sw1    ethernet31 up    tx  0       0     0        -

~ Service Interface(s) ~
None.

~ Core Interface(s) ~
None.

~ Failed Path(s) ~
None.

Another way of visualizing this runtime state is illustrated in the following diagram:

If any failures occur by the sharing of L3 managed services between policies, ensure the order of services shared by all policies is the same, i.e., the order of services matters and partially sharing the sequence is not allowed:

• Policy p1 cannot have ms1 → ms2, while policy p2 already has ms2 → ms1.
• Policy p1 cannot have ms1 → ms2, while policy p2 only has ms1.

Configure the feature through the Controller in managed services.

Follow the configuration steps described in the services earlier to configure app-id-filter and app-id together. However, in this case, app-id should use a higher seq num than app-id-filter. Thus, the traffic is processed through the app-id-filter policy first, then through app-id.

This behavior can be helpful to monitor certain types of traffic. The following example illustrates a combined app-id-filter and app-id configuration.

! managed-service
managed-service MS1
service-interface switch CORE-SWITCH-1 ethernet2
!
!
1 action app-id-filter
app facebook
filter-mode forward
!
2 action app-id
collector 1.1.1.1
l3-delivery-interface L3-INTF-1

Syslog messages for configuring the app-id and app-id-filter services appear in a service node’s syslog through journalctl.

A Service Node syslog registers events for the app-id add, modify, and delete actions.

These events contain the keywords dpi and dpi-filter, which correspond to app-id and app-id-filter.

For example:

Adding dpi for port, 
Modifying dpi for port, 
Deleting dpi for port,
Adding dpi filter for port, 
Modifying dpi filter for port, 
Deleting dpi filter for port, 
App appname does not exist - An invalid app name was entered.

The addition, modification, or deletion of app names in an app-id-filter managed-service in the Controller node’s CLI influences the policy refresh activity, and these events register in floodlight.log.

• Max concurrent sessions are currently set to permit less than 200,000 active flows per core. Performance may drop the more concurrent flows there are. This value is a maximum value to prevent the service from overloading. Surpassing this threshold may cause some flows not to be processed, and the new flows will not be identified or filtered. Entries for inactive flows will time out after a few minutes for ongoing sessions and a few seconds after the session ends.
• If there are many inactive sessions, DMF holds the flow contexts, reducing the number of available flows used for DPI. The timeouts are approximately 7 minutes for TCP sessions and 1 minute for UDP.
• Heavy application traffic load degrades performance.

• When using a drop filter, a few packets may slip through the filter before determining an application ID for a flow, and when using a forward filter, a few packets may not be forwarded. Such a small amount is estimated to be between 1 and 6 packets at the beginning of a flow.
• When using a drop filter, add the unknown app ID to the filter list to drop any unidentified traffic if these packets are unwanted.
• The Controller must be connected to a Service Node for the app-id-filter app list to appear. If the list does not appear and the application names are unknown, use the app-id to send reports to the analytics node. Use the application names seen there to configure an app-id-filter. The name must match exactly.
• Since app-category does not currently show the applications included in that category, do not use it when targeting specific apps. Categories like basic, which include all basic networking protocols like TCP and UDP, may affect all flows.
• For app-id, a report is only generated for a fully classified flow after that flow has been fully classified. Therefore, the number of reported applications may not match the total number of flows. These reports are sent after enough applications are identified on the Service Node. If many applications are identified, DMF sends the reports quickly. However, DMF sends these reports every 10 seconds when identifying only a few applications.
• DMF treats a bidirectional flow as part of the same n-tuple. As such, generated reports contain the client's source IP address and the server's destination IP address.
• While configuring many ports with the app-id, there may occasionally be a few Rx drops on the 16 port machines at a high traffic rate in the first couple of seconds.
• The feature uses a cache that maps dest ip and port to the application. Caching may vary the performance depending on the traffic profile.
• The app-id and app-id-filter services are more resource-intensive than other services. Combining them in a service chain or configuring many instances of them may lead to degradation in performance.
• At scale, such as configuring 16 ports on the R740 DCA-DM-SEL, app-id may take a few minutes to set up on all these ports, and this is also true when doing a dynamic signature update.
• The show analytics app-info command only works in push-per-filter VLAN mode.

• Mapping an interface-name with identified application IDs from source traffic received via the filter interface at Analytics Dashboard is allowed in Push-Per-Filter Mode only.

The DMF Controller supports a payload-routed-packet deduplication option. This feature allows service nodes to combine the L4 payload start anchor point with routed salt (L3 IP addresses, L4 source/destination ports, and other L3 header fields).

Anchoring the deduplication range at the L4 payload start ensures that frames with identical payload content are identified as duplicates, even when TCP headers—such as frequently updated timestamps—differ. This method effectively skips TCP/UDP headers and options during hash computation.

All dedup supporting Service Nodes support Routed Deduplication with L4 Payload and Salt.

The DMF Controller supports a payload-routed-packet deduplication option. This feature allows service nodes to combine the L4 payload start anchor point with routed salt (L3 IP addresses, L4 source/destination ports, and other L3 header fields).

Anchoring the deduplication range at the L4 payload start ensures that frames with identical payload content are identified as duplicates, even when TCP headers—such as frequently updated timestamps—differ. This method effectively skips TCP/UDP headers and options during hash computation.

All dedup supporting Service Nodes support Routed Deduplication with L4 Payload and Salt.

dmf-controller-1(config)# managed-service managed_service_1
dmf-controller-1(config-managed-srv)# service-interface switch delivery1 ethernet1
dmf-controller-1(config-managed-srv)# 1 action dedup
dmf-controller-1(config-managed-srv-dedup)# region [header-routed-packet | payload-routed-packet]

Unicast Tap Points

dmf-controller-1(config-managed-srv-flow-diff)# tap-point-pair source <Tab>
filter-interface         filter-interface-group

The filter-interface-group option takes in any configured filter interface group used to represent a collection of tap points in push-per-filter mode. This is an optional command to use when a group of tap points exists, all expecting traffic from the same source or group of source tap points for ease of configuration. For example:

1. Instead of having two separate tap-point-pairs to represent A → B, A → C, use a filter-interface-group G = [B, C], and only one tap-point-pair A → G.

   dmf-controller-1(config-managed-srv-flow-diff)# tap-point-pair source type A destination filter-interface-group G

2. With a topology like A → C and B → C, configure a filter-interface-group G = [A, B], and tap-point-pair G → C.

   dmf-controller-1(config-managed-srv-flow-diff)# tap-point-pair source filter-interface-group G destination type C

Multicast Tap Points

Configure multicast tap points using tap-point-multicast-group parameters in the flow-diff submode specifying the multicast group names.

dmf-controller-1(config-managed-srv-flow-diff)# tap-point-multicast-group multicast group name

Multicast group is flattened by the group IPs and converted into tap point triplets of the form of sources, receivers, and group-ip. When a multicast group is used as a tap point, then the receiver group in the multicast group config only applies to packets destined for the group IP address. This allows the action to be configured for multiple multicast groups that have the same source, but different destinations.

Restrictions

There are some restrictions to keep in mind while configuring tap-point-pairs and tap-point-multicast-groups:

• A source and destination must exist and cannot refer to the same tap point.
• A multicast group must have sources, receivers, and group IPs configured, and the sources and receivers must not overlap.
• The configured filter-interface-group must not partially overlap with other groups, including the multicast group sources and receivers used by the same flow-diff managed service and cannot have more than 128 members. The same applies to any multicast group being used by flow-diff.
• When configuring multiple tap-point-pairs using filter-interface and filter-interface-group, or tap-point-mulitcast-group, if a filter interface is used individually, it can only be referenced in a filter-interface-group or multicast-group sources or receiver groups if these groups only consist of that one filter interface.
• The configuration supports a maximum of 4094 unique tap point groups. This limit applies globally to the fabric and encompasses all flow-diff services. Tap point group uniqueness depends on the constituent filter interfaces. For example, an individual filter interface F1 and a filter interface group FG1 containing only that same interface F1 represent the same unique group. Similarly, a multicast group utilizing either the individual interface F1 or the single-interface group FG1 as a source or receiver refers to the same underlying interface group.

If an interface group has more than one LAG grouping where each LAG contains multiple ids, only one member id of each LAG is required. Subsequent ids of the LAG will not have latency computed if they are found.

The existence of the delivery-requirement flag changes the drop reporting for interface group pairs. When set to any-destination, the packet only needs to be seen on any one of the configured destination interfaces, when set to all-destinations, the packet must arrive on all matching destinations, otherwise the system generates a drop report for each interface where the packet was unseen.

Configure the policies so that the same packet can be tapped from two independent points in the network and then sent to the Service Node.

After creating a policy, add the managed service with flow-diff action as shown in the following example:

dmf-controller-1 (config-policy)# use-managed-service service name sequence 1

There are several things to consider while configuring policies in push-per-filter mode:

• Only one policy can contain the flow-diff service action.
• A policy should have all filter-interfaces and filter-interface-groups configured as tap points in the flow-diff configuration. Any missing filter interfaces and groups in a policy may result in reporting drops as these packets do not forward from one end of the tap-point-pair to the Service Node. Similarly, for the tap-point-multicast-group, the configuration must include the filter interfaces and groups used as sources and receivers in the policy.
• It’s also advisable not to add any filter interfaces (groups) that are not in the tap-point-pairs or tap-point-multicast-groups as their latency and drop analysis will not be done, causing unnecessary packets to be forwarded to the Service Node, which are then reported as unexpected.
• Ensure accurate timestamping and avoid unexpected report types by correctly ordering the source and destination for tap point pairs. Tap point pairs are not bidirectional so to compute latencies for both directions add the reverse ordering of the tap point pair.

dmf-controller-1 (config-policy)# use-timestamping

The following show commands provide helpful information.

dmf-controller-1(config)# show running-config managed-service ms1 
! managed-service
managed-service ms1
  service-interface switch DCS-7050CX3-32S ethernet2/4
  !
  1 action flow-diff
    collector 192.168.1.1
    l3-delivery-interface AN-Data
    tap-point-pair source filter-interface ingress destination filter-interface egress
    tap-point-multicast-group mg1
    delivery-requirement any-destination
    !
    report-types
      drop
      latency

dmf-controller-1(config)# show managed-services flow-diff 
# Service Name Switch          Switch Interface Installed Max Post-Service BW Max Pre-Service BW Total Post-Service BW Total Pre-Service BW 
-|------------|---------------|----------------|---------|-------------------|------------------|---------------------|--------------------|
1 flow-diff    DCS-7050CX3-32S ethernet2/4      True      25Gbps              25Gbps             624Kbps               432Mbps

dmf-controller-1(config)# show running-config policy p1 
! policy
policy p1
  action forward
  filter-interface egress
  filter-interface ingress
  use-managed-service ms1 sequence 1
  use-timestamping
  1 match any

The show policy policy command provides detailed information about a policy and whether any errors are related to the flow-diff service. The Service Interfaces tab section shows the packets transmitted to the Service Node and IPFIX packets received from the Service Node.

dmf-controller-1 (config)# show policy flow-diff-1
Policy Name                            : flow-diff-1
Config Status                          : active - forward
Runtime Status                         : installed
Detailed Status                        : installed - installed to forward
Priority                               : 100
Overlap Priority                       : 0
# of switches with filter interfaces   : 1
# of switches with delivery interfaces : 1
# of switches with service interfaces  : 1
# of filter interfaces                 : 1
# of delivery interfaces               : 1
# of core interfaces                   : 4
# of services                          : 1
# of pre service interfaces            : 1
# of post service interfaces           : 1
Push VLAN                              : 2
Post Match Filter Traffic              : 215Mbps
Total Delivery Rate                    : -
Total Pre Service Rate                 : 217Mbps
Total Post Service Rate                : -
Overlapping Policies                   : none
Component Policies                     : none
Runtime Service Names                  : flow-diff
Installed Time                         : 2023-11-16 18:15:27 PST
Installed Duration                     : 19 minutes, 45 secs
~ Match Rules ~
# Rule        
-|-----------|
1 1 match any
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Filter Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF Switch   IF Name    State Dir Packets  Bytes       Pkt Rate Bit Rate Counter Reset Time             
-|------|--------|----------|-----|---|--------|-----------|--------|--------|------------------------------|
1 BP1    7280SR3E Ethernet25 up    rx  24319476 27484991953 23313    215Mbps  2023-11-16 18:18:18.837000 PST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Delivery Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# DMF IF  Switch    IF Name    State Dir Packets Bytes  Pkt Rate Bit Rate Counter Reset Time             
-|-------|---------|----------|-----|---|-------|------|--------|--------|------------------------------|
1 AN-Data 7050SX3-1 ethernet41 up    tx  81      117222 0        -        2023-11-16 18:18:18.837000 PST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Service Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Service name Role         Switch          IF Name     State Dir Packets  Bytes       Pkt Rate Bit Rate Counter Reset Time             
-|------------|------------|---------------|-----------|-----|---|--------|-----------|--------|--------|------------------------------|
1 flow-diff      pre-service  DCS-7050CX3-32S ethernet2/4 up    tx  23950846 27175761734 23418    217Mbps  2023-11-16 18:18:18.837000 PST
2 flow-diff      post-service DCS-7050CX3-32S ethernet2/4 up    rx  81       117546      0        -        2023-11-16 18:18:18.837000 PST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Core Interface(s) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Switch          IF Name    State Dir Packets  Bytes       Pkt Rate Bit Rate Counter Reset Time             
-|---------------|----------|-----|---|--------|-----------|--------|--------|------------------------------|
1 7050SX3-1       ethernet7  up    rx  23950773 27175675524 23415    217Mbps  2023-11-16 18:18:18.837000 PST
2 7050SX3-1       ethernet56 up    rx  81       117222      0        -        2023-11-16 18:18:18.837000 PST
3 7050SX3-1       ethernet56 up    tx  23950773 27175675524 23415    217Mbps  2023-11-16 18:18:18.837000 PST
4 7280SR3E        Ethernet7  up    tx  24319476 27484991953 23313    215Mbps  2023-11-16 18:18:18.837000 PST
5 DCS-7050CX3-32S ethernet28 up    tx  81       117546      0        -        2023-11-16 18:18:18.837000 PST
6 DCS-7050CX3-32S ethernet28 up    rx  23950846 27175761734 23418    217Mbps  2023-11-16 18:18:18.837000 PST
~ Failed Path(s) ~
None.

The show running-config multicast-group name displays the user-configured multicast groups.

dmf-controller-1(config)# show running-config multicast-group 

! multicast-group
multicast-group mg1
  group-ip 224.0.0.1
  group-ip 224.0.0.2
  receiver filter-interface f3
  receiver filter-interface f6
  source filter-interface f1
  source filter-interface f2

The Flow Diff Latency and Drop Analysis feature does not create Syslog messages.

• This feature is only supported in push-per-filter mode. Any config in push-per-policy mode will not work as intended.
• A maximum of 4094 distinct tap points are allowed.
• Only 40 timestamped instances of a packet are allowed.
• The filter-interface-group used as a tap point must not overlap with any other group within the same managed service and must not have more than 128 members.
• The multicast-group used as a tap point must not have its sources and receivers overlap with any other group within that managed service and must not have more than 128 members each.
• A filter interface cannot be used as a tap point and simultaneously as a part of a filter-interface-group or multicast-group source or receiver, unless the groups have this filter interface as the only member and no other interface.
• There is no chaining if a packet flows through three or more tap points in an A->B->C->...->Z topology. The only computed latency reports is for tap-point-pairs A->B, A->C, …, and A->Z if these links are specified, but B->C, C->D, etc., will not be computed.
• Service Node interfaces can have multiple lcores depending on the SKU. An lcore is a logical core which processes traffic on an interface. Hardware RSS firmware in some Service Node SKU currently cannot parse L2 header timestamps, so all packets are sent to the same lcore; however, RSS does distribute packets correctly to multiple lcores when using src-mac timestamping.
• Each packet from the L3 header and onward gets hashed to a 64-bit value; if two packets hash to the same value, assume the underlying packets are the same.
• Currently, on the flow-diff action in the Service Node, if packets are duplicated so that N copies of the same packet are received:
  • N-1 latencies are computed.
  • The ingress identifier is the earliest timestamp.
• The system reports timestamps as unsigned 32-bit values, with the maximum timestamp being 2^32-1, corresponding to approximately 4.29 seconds.
• Only min mean max latencies are currently reported.
• If there are switch timestamping issues, then these statistics may have high outliers.
• Synchronize the time between switches for this feature to work properly, or latency calculation may be inaccurate.
• Packets are hashed from the L3 header onward, meaning if there is any corrupted data past the L3 header, it will lead to drop reports. The same packet must appear at two tap points to generate a computed latency report.
• In A->B, if B packets appear before A, an unexpected type report is generated.
• At whichever tap point the packet first appears with the earliest timestamp, it is considered the source.
• While switching the latency configuration, the system may generate a couple of unexpected or drop reports at the beginning.
• A LAG may affect RSS on the service node which may affect performance.
• Users must have good knowledge of network topology when setting up tap points and configuring timeout or sample threshold values. Improper configuration may lead to drop or unexpected reports.
• Occasionally switch timestamping causes the system to generate a few type 2 unexpected reports.
• The system may generate drop reports from certain protocols, such as OSPF.
• The amount of packets per second and packet size influences performance since packets are individually hashed. The amount of tap point pairs and interface groups also affects performance.

With this feature enabled, DMF knows exactly where to apply the post-service match. The following example illustrates this configuration.

! managed-service
managed-service MS-HEADER-STRIP-4
service-interface switch CORE-SWITCH-1 interface ethernet1
1 action decap-l3-mpls
!
post-service-match
1 action match ip src-ip 1.1.1.1
2 action match tcp dst-ip 2.2.2.0 255.255.255.0
! policy
policy POLICY-1
filter-interface TAP-1
delivery-interface TOOL-1
use-managed-service MS-HEADER-STRIP-4 sequence 1

Define a managed service and define the IPFIX action.

controller(config)# managed-service MS-IPFIX-SERVICE
controller(config-managed-srv)# 1 action ipfix TO-DELIVERY-INTERFACE
controller(config-managed-srv-ipfix)# collector 10.106.1.60
controller(config-managed-srv-ipfix)# template IPFIX-TEMPLATE

The active-timeout and inactive-timeout commands are optional

controller1# show running-config managed-service MS-IPFIX-ACTIVE
! managed-service
managed-service MS-IPFIX-ACTIVE
service-interface switch CORE-SWITCH-1 ethernet13/1
!
1 action ipfix TO-DELIVERY-INTERFACE
collector 10.106.1.60
template IPFIX-TEMPLATE

config# show running-config ipfix-template
! ipfix-template
ipfix-template IPFIX-IP
template-id 1974
key destination-ipv4-address
key destination-ipv6-address
key ethernet-type
key source-ipv4-address
key source-ipv6-address
field flow-end-milliseconds
field flow-end-reason
field flow-start-milliseconds
field minimum-ttl
field tcp-control-bits
------------------------output truncated------------------------

Destination MAC rewrite for the records-per-interface NetFlow and IPFIX feature is the default setting and applies to switches running Extensible Operating System (EOS) and SWL and is supported on all platforms.

A configuration option exists for using src-mac when overwriting the dst-mac isn't preferred.

c1(config)# filter-mac-rewrite rewrite-src-mac
c1(config)# filter-mac-rewrite rewrite-dst-mac

c1(config)# managed-service ms1
c1(config-managed-srv)# 1 action netflow
c1(config-managed-srv-netflow)# collector 213.1.1.20 udp-port 2055 mtu 1024 records-per-interface

c1(config)# ipfix-template i1
c1(config-ipfix-template)# field maximum-ttl 
c1(config-ipfix-template)# key records-per-dmf-interface
c1(config-ipfix-template)# template-id 300

c1(config)# managed-service ms1
c1(config-managed-srv)# 1 action ipfix
c1(config-managed-srv-ipfix)# template i1

c1(config)# show running-config managed-service 
! managed-service
managed-service ms1
  !
  1 action netflow
    collector 213.1.1.20 udp-port 2055 mtu 1024 records-per-interface

c1(config)# show ipfix-template i1
~~~~~~~~~~~~~~~~~~ Ipfix-templates  ~~~~~~~~~~~~~~~~~~
# Template Name Keys                      Fields      
-|-------------|-------------------------|-----------|
1 i1            records-per-dmf-interface maximum-ttl

c1(config)# show running-config managed-service 
! managed-service
managed-service ms1
  !
  1 action ipfix
    template i1

Troubleshooting

• If the number of packets forwarded by the Service Node interfaces is few, the max-tokens and tokens-per-refresh values likely need to be higher.
• If fewer packets than the tokens-per-refresh value forward, ensure the max-tokens value is larger than the tokens-per-refresh value. The system discards any surplus refresh tokens above the max-tokens value.
• When all traffic forwards, the initial max-tokens value is too large, or the tokens refreshed by tokens-per-refresh are higher than the packet rate.
• When experiencing packet drops after the first 10ms post commencement of traffic, it may be due to a low tokens-per-refresh value. For example, calculate the minimum value of max-tokens and tokens-per-refresh that would lead to forwarding all packets.

Calculation Example

Traffic Rate : 400 Mbps
Packet Size - 64 bytes
400 Mbps = 400000000 bps
400000000 bps = 50000000 Bps
50000000 Bps = 595238 pps (Includes 20 bytes of inter packet gap in addition to the 64 bytes)
1000 ms = 595238 pps
1 ms = 595.238 pps
10 ms = 5952 pps
max-tokens : 5952 (the minimum value)
tokens-per-refresh : 5952 ( the minimum value)