Use a valid DANZ Monitoring Fabric (DMF) Controller username and password to authenticate with a DMF Recorder Node over its REST API. The recorder node delegates authentication to the DMF Controller. If the username and password provided are valid, the recorder node authorizes the user for the invoked recorder node REST endpoint.

$ curl https://1.2.3.4/query/window -u admin:12345 -k | python -m json.tool
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 79 100 79 0 0 143 0 --:--:-- --:--:-- --:--:-- 143
{
"begin": "2019-01-23 15:15:23 +0000 UTC",
"end": "2019-02-04 17:39:52 +0000 UTC"
}

In this example, the recorder node IP address is 1.2.3.4. The username on the DMF Controller is admin, and the password is 12345.

/ready

• Description: Is the DANZ Monitoring Fabric (DMF) Recorder Node able to accept queries? Return payload indicates progress towards start up completion.
• HTTP Method: GET
• Request Payload:
• Return MIME Type:
• Return Payload:

  {
  "current-value": <int>,
  "max-value": <int>,
  "percent-complete": <float>
  }

• Return Status Code:
  • 200, ready
  • 503, not ready

/query/window

• Description: Get timestamp of oldest and newest packet available for query.
• HTTP Method: GET
• Request Payload:
• Return MIME Type: application/json
• Return Payload:

  {
  "begin" : <RFC-3339>,
  "end" : <RFC-3339>
  }

• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/query/size

• Description: Get count and aggregate size of packets matching provided filter.
• HTTP Method: POST
• Request Payload: Stenographer query string
• Return MIME Type: application/json
• Return Payload:

  {
  "packet-count" : <int>,
  "aggregate-size" : <int>
  }

• Return Status Code:
  • 200, success 400, input error
  • 500, internal error
  • 503, not ready

/query/application

• Description: Perform DPI on packets matching provided filter. DPI is performed using nDPI.
• HTTP Method: POST
• Request Payload: Stenographer query string
• Return MIME Type: application/json
• Return Payload: Defined by nDPI
• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/query/packet

• Description: Download pcap of packets matching provided filter.
• HTTP Method: POST
• Request Payload: Stenographer query string
• Return MIME Type: application/vnd.tcpdump.pcap
• Return Payload: .pcap file
• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/query/analysis[filter="<stenographer-query-string>"][type ="<analysis-type>"]

• Description: Perform an analysis on the packets matching the stenographer query string. Supported values for analysis-type are:
  • analysis_http_tree
  • analysis_http_stat
  • analysis_http_req_tree
  • analysis_http_srv_tree
  • analysis_dns_tree
  • analysis_hosts
  • analysis_conv_ipv4
  • analysis_conv_ipv6
  • analysis_conv_tcp
  • analysis_conv_udp
  • analysis_rtp_streams
  • analysis_sip_stat
  • analysis_conv_sip
  • analysis_tcp_packets
  • analysis_tcp_flow_health
• HTTP Method: GET
• Request Payload:
• Return MIME Type: application/json
• Return Payload: Determined by the analysis type selected.
• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/query/replay/request[filter="<stenographer-query-string>"][real-time="<boolean>"]

• Description: Asynchronously request packets matching filter be replayed into the monitoring fabric. Replay is performed using tcp replay.
• HTTP Method: POST
• Request Payload:
• Return MIME Type: application/json
• Return Payload:

  {
  "id" : <int>,
  "message": <string>
  }

• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/query/replay/request[filter="<stenographer-query-string>"][speed-mbps="<int>"]

• Description: Asynchronously request packets matching filter be replayed into the monitoring fabric. Replay is performed using tcp replay.
• HTTP Method: POST
• Request Payload:
• Return MIME Type: application/json
• Return Payload:

  {
  "id" : <int>,
  "message": <string>
  }

• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/query/replay/done

• Description: Check the status of a replay matching the provided ID. Message contains replay result from tcp replay.
• HTTP Method: POST
• Request Payload: Replay ID
• Return MIME Type: application/json
• Return Payload:

  {
  "id" : <int>,
  "done" : <boolean>,
  "message": <string>
  }

• Return Status Code:
  • 200, success
  • 400, input error
  • 404, replay ID unknown
  • 406, replay not done
  • 500, internal error
  • 503, not ready

/erase/packet[filter="<stenographer-query-string>"]

• Description: Erase packets matching the provided filter. Note that any packet not matching the filter but in the same packet file of a packet matching the filter will also be deleted.
• HTTP Method: POST
• Request Payload:
• Return MIME Type: application/json
• Return Payload:

  {
  "bytes-erased" : <int>,
  "message" : <string>
  }

• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/event/update[trigger="<boolean>"][name="<string>"][pre-buffer-minutes="<int>"]

• Description: Trigger or terminate the named event. Set pre-buffer-minutes to 0 to use the available pre-buffer.
• HTTP Method: POST
• Request Payload:
• Return MIME Type: application/json
• Return Payload:

  {
  "message" : <string>,
  "event-queued" : <boolean>
  }

• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/abort/query

• Description: Terminate a particular query defined by the provided Stenographer query string.
• HTTP Method: POST
• Request Payload:
• Return MIME Type: application/json
• Return Payload:

  {
  "message" : <string>
  }

• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/abort-all/query

• Description: Terminate all running queries.
• HTTP Method: POST
• Request Payload:
• Return MIME Type: application/json
• Return Payload:

  {
  "message" : <string>
  }

• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/queries

• Description: Determine the currently running queries, enumerated by the Stenographer query string of the query.
• HTTP Method: GET
• Request Payload:
• Return MIME Type: application/json
• Return Payload:

  {
  "queries" : [
  <stenographer-query-string>, ...
  ]
  }

• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/status/query

• Description: Determine how far a given query has progressed. This can be used to estimate the time remaining to run the query.
• HTTP Method: GET
• Request Payload:
• Return MIME Type: application/json
• Return Payload:

  {
  "query" : <stenographer-query-string>, "current-value" : <int>,
  "max-value" : <int>, "percent-complete" : <float>
  }

• Return Status Code:
  • 200, success
  • 400, input error
  • 500, internal error
  • 503, not ready

/status/all

• Description: Determine how far all queries have progressed. This can be used to estimate the time remaining to run the queries.
• HTTP Method: GET
• Request Payload:
• Return MIME Type: application/json
• Return Payload:

  {
  "queries" : [
  {
  "query" : <stenographer-query-string>,
  "current-value" : <int>,
  "max-value" : <int>,
  "percent-complete" : <float>
  },
  ...
  ]
  }

• • Return Status Code:
    • 200, success
    • 400, input error
    • 500, internal error
    • 503, not ready

The following summarizes the different match criteria available:

• src-ip, dst-ip, src-mac, and dst-mac are maskable. If the mask for src-ip, dst-ip, src-mac, or dst-mac is not specified, it is assumed to be an exact match.
• For src-ip and dst-ip, specify the mask in either CIDR notation (for example, /24) or dotted-decimal notation (255.255.255.0).
• For src-ip and dst-ip, the mask must be contiguous. For example, a mask of 255.0.0.255 or 0.0.255.255 is not supported.
• For TCP, the tcp-flags option allows a match on the following TCP flags: URG, ACK, PSH, RST, SYN, and FIN.

DANZ Monitoring Fabric (DMF) supports matching on user-defined L3/L4 offsets instead of matching on these criteria. However, it is not possible to use both matching packet methods in the same DMF. Switching between these match modes may cause policies defined under the previous mode to fail.

Apply match rules to the following fields in the packet header:

dscp-value Match on DSCP value. Value range is 0..63
dst-ip Match dst ip
dst-port Match dst port
is-fragment Match if the packet is IP fragmented
is-not-fragment Match if the packet is not IP fragmented
l3-offset Match on l3 offset
l4-offset Match on l4 offset
range-dst-ip Match dst-ip range
range-dst-port Match dst port ramge
range-src-ip Match src-ip range
range-src-port Match src port range
src-ip Match src ip
src-port Match src port
untagged Untagged (no vlan tag)
vlan-id Match vlan-id
vlan-id-range Match vlan-id range
<ip-proto> IP Protocol

1 match ip src-ip 1.1.1.1 255.255.255.255 dst-ip 2.2.2.2 255.255.255.255

1 match ip src-ip 1.1.1.1 255.255.255.255
2 match ip dst-ip 2.2.2.2 255.255.255.255

controller-1(config)# policy dmf-policy-1
controller-1(config-policy)# 10 match any

1 match tcp tcp-flags 2 2
2 match tcp tcp-flags 18 18

The value of the EtherType field determines whether the src-ip field to match is IPv4 or IPv6. The DANZ Monitoring Fabric (DMF) Controller displays an error if there is a mismatch between the EtherType and the IP address format.

DMF does not support the IPv4 address embedded in the IPv6 address format. For example, neither 0:0:0:0:0:0:101.45.75.219 nor ::101.45.75.219 can be used.

Both IPv4 and IPv6 masks must be in CIDR format. For example, FFFF:FFFF:FFFF:FFFF:0:0:0:0 is valid in DMF, but FFFF:0:0:FFFF:FFFF:0:0:0:0 is not a valid mask.

controller-1(config)# policy dmf-ipv6-policy
controller-1(config-policy)# 10 match ip6 src-ip 2001::0 ffff:ffff:ffff:ffff:0:0:0:0
controller-1(config-policy)# 11 match ip6 dst-ip 2001:db8:122:344::/64
controller-1(config-policy)# filter-interface all
controller-1(config-policy)# action drop

Selecting the User Defined Offsets option when the L3-L4 Offset Match switching mode is not enabled, the system displays a message to enable the correct match mode.

Configure each switch with a maximum of eight different offsets matching two bytes each, used in a single policy or any combination in different policies. In the example below, the policy matches on a value of 0x00001000 at offset 40 from the start of the L3-header and a value of 0x00002000 at offset 64 from the start of the L4-header.

controller-1(config-policy)# 1 match udp dst-port 2152 l3-offset 40 length 4 value 0x00001000 mask
0xffffffff l4-offset 64 length 4 value 0x00002000 mask 0xffffffff

controller-1# show user-defined-offset
# Switch Slot Anchor Offset Length Policy
-|--------------|----|--------|------|------|-------------------------------------------------------|
1 DMF-FILTER-SW1 0l4-start 64 2DMF-UDF-TEST-1, _DMF-UDF-TEST-1_o_SAVE-TO-RECORDER-NODE
2 DMF-FILTER-SW1 1l4-start 66 2DMF-UDF-TEST-1, _DMF-UDF-TEST-1_o_SAVE-TO-RECORDER-NODE
3 DMF-FILTER-SW1 2l3-start 40 2DMF-UDF-TEST-1, _DMF-UDF-TEST-1_o_SAVE-TO-RECORDER-NODE
4 DMF-FILTER-SW1 3l3-start 42 2DMF-UDF-TEST-1, _DMF-UDF-TEST-1_o_SAVE-TO-RECORDER-NODE
controller-1#

switch DMF-FILTER-SWITCH-1
admin hashed-password
$6$5niT1gPm$Jc24qOMF.hxNPI20DvnKaFZKYD6lIo59IMp3O4xIdwVTu2hx0s8Djpvz9xXAXXndiSkKe5jH.9PKoHHrWviSl0
mac 70:72:cf:dc:99:5c
interface ethernet1
role filter interface-name TAP-PORT-1
interface ethernet13
role delivery interface-name TOOL-PORT-1
interface ethernet15
role delivery interface-name TOOL-PORT-1
interface ethernet17
role delivery interface-name TOOL-PORT-3
interface ethernet19
role delivery interface-name TOOL-PORT-4
interface ethernet25
loopback-mode mac
role both-filter-and-delivery interface-name LOOPBACK-PORT-1
interface ethernet26
loopback-mode mac
role both-filter-and-delivery interface-name LOOPBACK-PORT-2
interface ethernet27
loopback-mode mac
role both-filter-and-delivery interface-name LOOPBACK-PORT-3
interface ethernet28
loopback-mode mac
role both-filter-and-delivery interface-name LOOPBACK-PORT-4

! policy
policy TAP-NETWORK-1
action forward
delivery-interface LOOPBACK-PORT-1
delivery-interface LOOPBACK-PORT-2
delivery-interface LOOPBACK-PORT-3
delivery-interface LOOPBACK-PORT-4
filter-interface TAP-PORT-1
1 match any
!
policy DUPLICATED-TRAFFIC-1
action forward
delivery-interface TOOL-PORT-1
filter-interface LOOPBACK-PORT-1
1 match ip src-ip 100.1.1.1 255.255.255.252
!
policy DUPLICATED-TRAFFIC-2
action forward
delivery-interface TOOL-PORT-2
filter-interface LOOPBACK-PORT-2
1 match ip dst-ip 100.1.1.1 255.255.255.252
!
policy DUPLICATED-TRAFFIC-3
action forward
delivery-interface TOOL-PORT-3
filter-interface LOOPBACK-PORT-3
1 match tcp src-port 1234
!
policy DUPLICATED-TRAFFIC-4
action forward
delivery-interface TOOL-PORT-4
filter-interface LOOPBACK-PORT-4
1 match tcp dst-port 80

Use the show policy command to verify the policy configuration.

CLI Procedure

CONTROLLER-1(config)#switch DMF-DELIVERY-SWITCH-1
CONTROLLER-1(config-switch)# interface ethernet1
CONTROLLER-1(config-switch-if)# role delivery interface-name TOOL-PORT-1
CONTROLLER-1(config-switch-if)# rate-limit 10240

CONTROLLER-1(config-switch-if)# show this
! switch
switch DMF-DELIVERY-SWITCH-1
!
interface ethernet1
rate-limit 10000
role delivery interface-name TOOL-PORT-1
CONTROLLER-1 (config-switch-if)#

lag-interface lag1
hash-type l3
member ethernet43
member ethernet45
interface ethernet43
rate-limit 10000 <------ set the rate-limit to 10 Mbps
interface ethernet45
rate-limit 128000 <---------- set the rate-limit to 128 Mbps

To display the configured rate limit, use the show topology and show interface-names commands, as in the following examples:

Note: In the current release, the Rate Limit column does not show the configured value for LAG and tunnel interfaces.

By default, the number of overlapping policies allowed is four. The maximum number to configure for overlapping policies is ten. Set the overlap policy limit to zero to disable the overlapping policy feature.

controller-1(config)# overlap-policy-limit integer

Replace integer with the maximum number of overlapping policies to support fabric-wide.

controller-1(config)# overlap-policy-limit 10

controller-1(config)# overlap-policy-limit 0

The Policy Overlap Limit Strict option, enabled by default, strictly limits the number of overlapping policies to the maximum configured. For example, when setting the maximum number of overlapping policies to 4 (the default) and users create a fifth policy using the same filter interface, the operation fails with a validation error.

controller-1(config)# no overlap-limit-strict

controller-1(config)# overlap-limit-strict

DANZ Monitoring Fabric (DMF) supports the timestamping feature on 7280R3 switches.

# show switch all property
# Switch                      ...   PTP Timestamp Supported Capabilities  
-|----------------------------| ...  |-------------------------------------|
1 S1 (00:00:2c:dd:e9:96:2b:ff)...   ptp-timestamp-cap-replace-smac,
                                ...   ptp-timestamp-cap-header-64bit, 
                                ...   ptp-timestamp-cap-header-48bit,
                                ...   ptp-timestamp-cap-flow-based, 
                                ...   ptp-timestamp-cap-add-header-after-l2 
2 S2 (00:00:cc:1a:a3:91:a7:6c)...   
2 S3 (00:00:cc:1a:a3:c0:94:3e)...  

The following three sections describe the configuration for PTP and timestamping:

• PTP Switch Configuration

• PTP Interface Configuration

• Policy Configuration for Timestamping

Configure the switch at a global level under the config submode in the CLI or for each switch under the config-switch submode. Irrespective of the place, it has the following options:

1. Domain: Set the data plane PTP domain. The default value is 0. Valid values are [0 to 255] inclusive.

2. Priority1: Set the value of priority1 data plane PTP. The default value is 128. Valid values are [0 to 255] inclusive.

3. Source-ipv4-address: This is the source IPv4 address used to restamp PTP messages from this switch to the endpoints. Some master clock devices do not accept default source IP (0.0.0.0). If so, configureit can to sync with such devices. The default is 0.0.0.0 .

4. Source-ipv6-address: This is the source IPv6 address used to restamp PTP messages from this switch to the endpoints. Some master clock devices do not accept default source IP (::/0). If so, configure it to sync with such devices. The default is ::/0 .

All fields are optional, and default values are selected if not configured by the user.

Global Configuration

The global configuration is a central place to provide a common switch config for PTP. It only takes effect after creating a ptp-interface for a switch. Under the config submode, provide PTP switch properties using the following commands:

> enable
# config
(config)# ptp priority1 0 domain 1 source-ipv4-address 1.1.1.1

Local Configuration

The local configuration provides a local PTP configuration or overrides a global PTP config for a selected switch. Select the switch using the command switch switch name. PTP switch config (local or global) only takes effect after creating a ptp-interface for a switch. Under the config-switch submode, provide local PTP switch properties using the following commands:

(config)# switch eos
(config-switch)# ptp priority1 1 domain 2

Global Configuration

To view or edit the global PTP configuration, navigate to the DANZ Monitoring Fabric (DMF) Features page by clicking the gear icon.

The DMF Feature page is new in DMF release 8.4. It provides fabric-wide settings management for DMF.

Scroll to the PTP Timestamping card and click the edit button (pencil icon) to configure or modify the global PTP Timestamping settings.

Local Configuration

Provide a local PTP configuration for the switch or override the global PTP configuration for a selected switch while configuring or editing a switch configuration (under the PTP step) using the Monitoring > Switches page.

PTP Interface Configuration

Configure a PTP Interface on the Monitoring > Interfaces page.

Timestamping Policy Configuration

DMF supports flow-based timestamping. This function requires programming a policy to match relevant traffic and enable timestamping for the matched traffic. In the Create/Edit Policy workflow (on the Monitoring > Policies page), use the PTP Timestamping toggle to enable or disable timestamping.

A switch that syncs its hardware clock using PTP requires a physical front panel interface configured as a PTP interface. This interface is solely responsible for communication with the master clock and has no other purpose.

To configure the PTP interface, select an interface on the switch, as illustrated in the following command.

(config-switch)#interface Ethernet6/1

Use the role command to assign a ptp role and interface name and select switchport-mode for the specified interface.

(config-switch-if)# role ptp interface-name ptp1 access-mode announce-interval 1 delay-request-interval 1 sync-message-interval 1

The switchport mode configuration for a PTP interface is necessary to match the PTP master switch's interface configuration. Configure the master switch to communicate PTP messages with or without a vlan tag. Use the trunk-mode with the appropriate ptp vlan when configuring the neighbor similarly. If the neighbor's interface is in switch-port access mode or routed mode, use either of these to match it on the filter switch.

Other fields are optional, using default values when no configuration is provided.

(config-switch-if)# ptp vlan 1
(config-switch-if)# ptp vlan 2

In routed switchport mode, we ignore the configured VLANs. In access switchport mode, the first VLAN is used for programming while ignoring the rest. In trunk switchport mode, all configured VLANs are programmed into the switch.

DANZ Monitoring Fabric (DMF) supports flow-based timestamping. This function requires programming a policy to match relevant traffic and enable timestamping for the matched traffic.

Create a policy using the command policy policy name.

Under config-policy submode, enable timestamping using the following command:

(config-policy)# use-timestamping

L2GRE encapsulation of packets with Arista timestamp headers is an extension of an existing feature allowing DANZ Monitoring Fabric (DMF) to use intra-fabric L2GRE tunnels.

These tunnels enable forwarding unmodified production network packets over intermediate L3 networks used by DMF, which can now forward packets with Arista Networks Timestamp headers across L2GRE tunnels defined on EOS switches.

When a PTP header-based timestamping capable filter switch is in a remote location, and the remote filter switches connect to the centralized tool farm via L2GRE tunnels, timestamp the packets using PTP timestamping. These packets are encapsulated in an L2GRE header and sent to the core switch via the L2GRE tunnel. The timestamped packets will properly decapsulate at the remote end and be forwarded to the destination tools.

Please refer to the Tunneling Between Data Centers section on using L2GRE tunnels in DMF.

PTP State Show Commands

Use the show switch switch name ptp info| masters | interface | local-clock command to obtain the PTP state of the selected switch.

The show switch switch name ptp info command summarizes the switch's PTP state and the PTP interfaces' status.

Controller# show switch eos ptp info
PTP Mode: Boundary Clock
PTP Profile: Default ( IEEE1588 )
Clock Identity: 0x2c:dd:e9:ff:ff:96:2b:ff
Grandmaster Clock Identity: 0x44:a8:42:ff:fe:34:fd:7e
Number of slave ports: 1
Number of master ports: 1
Slave port: Ethernet1
Offset From Master (nanoseconds): -128
Mean Path Delay (nanoseconds): 71
Steps Removed: 2
Skew (estimated local-to-master clock frequency ratio): 1.0000080070748882
Last Sync Time: 00:52:44 UTC Aug 09 2023
Current PTP System Time: 00:52:44 UTC Aug 09 2023
Interface StateTransportDelay
Mechanism
--------------- ------------ --------------- ---------
Et1 Slaveipv4 e2e
Et47Master ipv4 e2e

The show switch switch name ptp master command provides information about the PTP master and grandmaster clocks.

Controller# show switch eos ptp master
Parent Clock:
Parent Clock Identity: 0x28:99:3a:ff:ff:21:81:d3
Parent Port Number: 10
Parent IP Address: N/A
Parent Two Step Flag: True
Observed Parent Offset (log variance): N/A
Observed Parent Clock Phase Change Rate: N/A

Grandmaster Clock:
Grandmaster Clock Identity: 0x44:a8:42:ff:fe:34:fd:7e
Grandmaster Clock Quality:
Class: 127
Accuracy: 0xfe
OffsetScaledLogVariance: 0x7060
Priority1: 120
Priority2: 128

The show switch switch name ptp interface interface name command provides the PTP interface configuration and state on the device.

Controller# show switch eos ptp interface Ethernet1
Ethernet1
Interface Ethernet1
PTP: Enabled
Port state: Slave
Sync interval: 1.0 seconds
Announce interval: 2.0 seconds
Announce interval timeout multiplier: 3
Delay mechanism: end to end
Delay request message interval: 2.0 seconds
Transport mode: ipv4
Announce messages sent: 3
Announce messages received: 371
Sync messages sent: 4
Sync messages received: 739
Follow up messages sent: 3
Follow up messages received: 739
Delay request messages sent: 371
Delay request messages received: 0
Delay response messages sent: 0
Delay response messages received: 371
Peer delay request messages sent: 0
Peer delay request messages received: 0
Peer delay response messages sent: 0
Peer delay response messages received: 0
Peer delay response follow up messages sent: 0
Peer delay response follow up messages received: 0
Management messages sent: 0
Management messages received: 0
Signaling messages sent: 0
Signaling messages received: 0

The show switch switch name ptp local-clock command provides PTP local clock information.

Controller# show switch eos ptp local-clock
PTP Mode: Boundary Clock
Clock Identity: 0x2c:dd:e9:ff:ff:96:2b:ff
Clock Domain: 0
Number of PTP ports: 56
Priority1: 128
Priority2: 128
Clock Quality:
Class: 248
Accuracy: 0x30
OffsetScaledLogVariance: 0xffff
Offset From Master (nanoseconds): -146
Mean Path Delay: 83 nanoseconds
Steps Removed: 2
Skew: 1.0000081185368557
Last Sync Time: 01:01:41 UTC Aug 09 2023
Current PTP System Time: 01:01:41 UTC Aug 09 2023

Policy State Show Commands

Use the show policy command to view the timestamping status for a given policy.

> 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 p1unspecified action inactive Configured 10001 - - - - True

In push-per-policy mode, a validation exception occurs if a policy uses NetFlow managed-service with records-per-interface option and the same policy also uses timestamping. The following message appears:

Validation failed: Policy policy1 cannot have timestamping enabled along with header modifying netflow service. 
Netflow service netflow1 is configured with records-per-interface in push-per-policy mode

In push-per-policy mode, a validation exception occurs if a policy uses the ipfix managed-service (using a template with records-per-dmf-interface key) and the same policy also uses timestamping. The following message appears:

Validation failed: Policy policy1 cannot have timestamping enabled along with header modifying ipfix service. 
Ipfix service ipfix1 is configured with records-per-dmf-interface in push-per-policy mode

Only unicast source-ipv4-address or source-ipv6-address are allowed in the switch PTP config.

Examples of invalid ipv6 addresses: ff02::1, ff02::1a, ff02::d, ff02::5

Validation failed: Source IPv6 address must be a unicast address

Examples of invalid ipv4 addresses: 239.10.10.10, 239.255.255.255, 255.255.255.255

Validation failed: Source IPv4 address must be a unicast address

A policy programmed to use timestamping can fail for the following reasons:

1. The filter switch does not support syncing its hardware clock using PTP.

2. An unconfigured PTP interface or the interface is inactive.

3. The PTP switch configuration or PTP interface configuration is invalid or incomplete.

4. Configuring the PTP interface on a logical port (Lag or Tunnel).

Reasons for failure will be available in the runtime state of the policy and viewed using the show policy policy name command.

As the Platform Compatibility Section describes, use the show switch all properties command to confirm a switch supports the feature.

The source MAC address of the user packet is re-written with a 48-bit timestamp value on the filter switch. This action can exhibit the following behavior changes or limitations:

1. Dedup managed service will not work as expected. A high-precision timestamp can be different for duplicate packet matching on two different filter interfaces. Thus, the dedup managed service will consider this duplicate packet to be different in the L2 header. To circumvent this limitation, use an anchor/offset in the dedup managed-service config to ignore the source MAC address.

2. Any Decap managed service except for decap-l3-mpls will remove the timestamp information header.

3. The user source MAC address is lost and unrecoverable when using this feature.

4. The rewrite-dst-mac feature cannot be used on the filter interface that is part of the policy using the timestamping feature.

5. In push-per-filter mode, if a user has src-mac match condition as part of their policy config, the traffic will not be forwarded as expected and can get dropped at the core switch.

6. The in-port masking feature will be disabled for a policy using PTP timestamping.

7. Logical ports (Lag/Tunnel) as PTP interfaces are not allowed.