Login
- Released At: 21-02-2023
- Page Views:
- Downloads:
- Related Documents
-
|
|
|
H3C S6805 & S6825 & S6850 & S9850 |
|
MC-NAT and PTP Configuration Guide for HD Audio and Video Data Transmission |
|
|
|
|
Document version: 6W100-20230214
Copyright © 2023 New H3C Technologies Co., Ltd. All rights reserved.
No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd.
Except for the trademarks of New H3C Technologies Co., Ltd., any trademarks that may be mentioned in this document are the property of their respective owners.
The information in this document is subject to change without notice.
Contents
Configuring the OpenFlow instance mode
Configuring inband management VLANs
Configuring flow tables and flow entries
Setting the controller connection mode
Preventing an OpenFlow instance from reporting the specified types of ports to controllers
Activating an OpenFlow instance
Configuring controllers for an OpenFlow instance
Configuring flow table settings on the controller
Connecting the controller to a device
Restrictions and guidelines: MC-NAT configuration
Grandmaster clock selection and master-member/subordinate relationship establishment
Restrictions: Hardware compatibility with PTP
Restrictions and guidelines: PTP configuration
PTP (SMPTE ST 2059-2) tasks at a glance
Specifying PTP for obtaining the time
Configuring an OC to operate only as a member clock
Configuring the role of a PTP port
Configuring the mode for carrying timestamps
Specifying a delay measurement mechanism for a BC or an OC
Configuring PTP message transmission and receipt
Setting the interval for sending Pdelay_Req messages
Setting the interval for sending Sync messages
Setting the minimum interval for sending Delay_Req messages
Configuring parameters for PTP messages
Configuring a source IP address for multicast PTP message transmission over IPv4 UDP
Configuring a destination IP address for unicast PTP message transmission over IPv4 UDP
Setting a DSCP value for PTP messages transmitted over IPv4 UDP
Specifying a VLAN tag for PTP messages
Adjusting and correcting clock synchronization
Setting the delay correction value
Setting the cumulative offset between the UTC and TAI
Setting the correction date of the UTC
Configuring a priority for a clock
Configuring the PTP time locking and unlocking thresholds
Display and maintenance commands for PTP
PTP configuration examples (IPv4 UDP transport, multicast transmission)
Overview
To ensure high quality and reliability for data transmission in a large-scaled video/audio data transmission scenario (for example, TV station, studio, or OB van), you can deploy an SDN-based MC-NAT network based on media over IP defined in SMPTE ST 2110/2022 and PTP defined in SMPTE ST 2059-2.
In this architecture, the media scheduling platform uses SDN controllers to deploy standard OpenFlow entries to the switch network. MC-NAT schedules and controls the media flows, and does not depend on peripheral IP devices. Peripheral IP devices do not need to exchange protocol packets, and only need to send or receive data complying with the related standards, for example, SMPTE 2022/2110. This solution decouples IP endpoints from the scheduling system, and provides more powerful openness and scalability for the system.
Figure 1 SDN-based MC-NAT network
This document mainly describes the MC-NAT and PTP configuration for high-definition audio/video data transmission. For how to configure Ethernet interfaces and VLANs in the basic configuration, see the following documents:
· For how to configure Ethernet interfaces, see Ethernet interface configuration in Layer 2—LAN Switching Configuration Guide in H3C S6805 & S6825 & S6850 & S9850 Switch Series Configuration Guides-Release 66xx or H3C S6805 & S6825 & S6850 & S9850 Switch Series Configuration Guides-Release 67xx.
· For how to configure VLANs, see VLAN configuration in Layer 2—LAN Switching Configuration Guide in H3C S6805 & S6825 & S6850 & S9850 Switch Series Configuration Guides-Release 66xx or H3C S6805 & S6825 & S6850 & S9850 Switch Series Configuration Guides-Release 67xx.
Configuring MC-NAT
About MC-NAT
Different from the traditional multicast architecture that uses PIM and IGMP, Multicast Network Address Translation (MC-NAT) uses a controller to issue OpenFlow flow entries and group entries to a device. These OpenFlow flow entries and group entries enable the device to forward traffic from a source device on the public network to different endpoints on the private network as needed. Before forwarding a packet, the device uses group entries to modify the IP addresses, port numbers, VLAN, and MAC addresses of the packet to those of the target endpoints on the private network.
MC-NAT forwarding process
MC-NAT can replicate multicast packets to different outgoing interfaces, modify the destination IP address and port number of multicast packets, and forward them. Figure 2 shows the MC-NAT forwarding process.
Figure 2 MC-NAT forwarding process
The device can use group entries to modify the source and destination IP addresses, source and destination UDP port numbers, and source and destination MAC addresses. Typically, only the destination IP address and destination UDP port number need to be modified.
MC-NAT configuration includes device-side configuration and controller-side configuration. This chapter uses a SeerEngine-DC controller as an example.
Configuring device settings
Tasks at a glance
To configure MC-NAT, perform the following tasks:
1. Creating an OpenFlow instance
2. Configuring the OpenFlow instance mode
3. (Optional.) Configuring inband management VLANs
4. (Optional.) Configuring flow tables and flow entries
5. (Optional.) Setting the controller connection mode
6. (Optional.) Preventing an OpenFlow instance from reporting the specified types of ports to controllers
7. Activating an OpenFlow instance
8. Configuring controllers for an OpenFlow instance
Creating an OpenFlow instance
1. Enter system view.
system-view
2. Create an OpenFlow instance, and enter its view.
openflow instance instance-id
3. (Optional.) Set a datapath ID for the OpenFlow instance.
datapath-id id
By default, the datapath ID of an OpenFlow instance contains the instance ID and the bridge MAC address of the device. The upper 16 bits are the instance ID and the lower 48 bits are the bridge MAC address of the device.
The datapath ID uniquely identifies an OpenFlow instance. Do not set the same datapath ID for different OpenFlow instances.
4. (Optional.) Set a DSCP value for OpenFlow packets.
tcp dscp dscp-value
By default, no DSCP value is set for OpenFlow packets.
Configuring the OpenFlow instance mode
Restrictions and guidelines
When you associate an OpenFlow instance with VLANs, follow these restrictions and guidelines:
· For VLAN traffic to be processed correctly, do not associate a VLAN with multiple OpenFlow instances.
· When you activate an OpenFlow instance that is associated with nonexistent VLANs, the system automatically creates these VLANs.
· Do not associate VLANs permitted on a port with different OpenFlow instances. If you do that, port modification messages of different OpenFlow instances deployed by controllers overwrite each other.
· Do not configure BFD MAD on the VLAN interface for a VLAN that is associated with an OpenFlow instance. For more information about BFD MAD, see Virtual Technologies Configuration Guide in H3C S6805 & S6825 & S6850 & S9850 Switch Series Configuration Guides-Release 66xx or H3C S6805 & S6825 & S6850 & S9850 Switch Series Configuration Guides-Release 67xx.
Enabling the global mode for an OpenFlow instance
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Enable the global mode for the OpenFlow instance.
classification global
By default, the OpenFlow instance mode is not configured.
Enabling the VLAN mode for an OpenFlow instance
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Configure the OpenFlow instance mode.
classification vlan vlan-id [ mask vlan-mask ] [ loosen ]
By default, the OpenFlow instance mode is not configured.
Configuring inband management VLANs
About this task
Traffic in the inband management VLANs are forwarded in the normal forwarding process instead of the OpenFlow forwarding process. Inband management VLANs are used by an OpenFlow instance to establish secure channels to controllers.
Restrictions and guidelines
If a controller connects to a switch through a management Ethernet interface (out-of-band management interface), you do not need to configure an inband management VLAN. As a best practice, connect a controller to a switch through a management Ethernet interface.
The ports that are assigned only to inband management VLANs are not OpenFlow ports.
Inband management VLANs configure for an OpenFlow instance in VLAN mode must be within the list of the VLANs associated with the OpenFlow instance.
If an OpenFlow instance in VLAN mode connects to a controller through a non-management Ethernet interface, configure the VLANs to which the interface belongs as inband management VLANs.
If an OpenFlow instance in global mode connects to a controller through a non-management Ethernet interface, perform either of the following tasks:
· Configure the VLANs to which the interface belongs as inband management VLANs.
· Execute the default table-miss permit command.
Procedure
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Configure inband management VLANs.
in-band management vlan vlan-id-list
By default, no inband management VLANs are configured.
Configuring flow tables and flow entries
Restrictions and guidelines
If you configure a VLAN tagging flow table, make sure the flow table has the smallest ID among all flow tables. If you configure a VLAN untagging flow table, make sure the flow table has the largest ID among all flow tables.
The VLAN tagging and untagging flow tables take effect when the OpenFlow instance meets the following requirements:
· The OpenFlow instance operates in standalone mode.
· The OpenFlow instance is enabled to perform QinQ tagging for double-tagged packets passing an extensibility flow table.
An extensibility flow table ID must be greater than a MAC-IP flow table ID.
Procedure
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Configure flow tables for the OpenFlow instance.
flow-table { ingress-vlan ingress-table-id | mac-ip mac-ip-table-id | extensibility extensibility-table-id&<1-2> | egress-vlan egress-table-id }*
By default, an OpenFlow instance contains one extensibility flow table with an ID of 0.
4. Enable the OpenFlow instance to perform QinQ tagging for double-tagged packets passing an extensibility flow table.
qinq-network enable
By default, a double-tagged packet becomes single-tagged after it passes an extensibility flow table.
To use QinQ flow tables together with extensibility flow tables for an OpenFlow instance, you must execute the qinq-network enable command on the OpenFlow instance.
5. Set the maximum number of flow entries that each extensibility flow table supports.
flow-entry max-limit limit-value
By default, the maximum number of flow entries that each extensibility flow table supports is 65535.
When the maximum number is reached in a table, the OpenFlow instance does not accept new flow entries for that table and sends a deployment failure notification to the controller.
6. Configure the OpenFlow instance to allow dynamic ARP entries to overwrite OpenFlow ARP entries.
precedence dynamic arp
By default, an OpenFlow instance does not allow dynamic ARP entries to overwrite OpenFlow ARP entries.
Only MAC-IP flow tables support this feature.
7. Allow the deployed flow tables to include link aggregation member ports.
permit-port-type member-port
By default, the deployed flow tables cannot include link aggregation member ports.
8. Configure the OpenFlow instance to drop slow protocol packets.
protocol-packet filter slow
By default, an OpenFlow instance does not drop slow protocol packets.
The slow protocols include LACP and OAM.
9. Configure the default action of table-miss flow entries to forward packets to the normal pipeline.
default table-miss permit
By default, the default action of table-miss flow entries is to drop packets.
In the MC-NAT application scenario, after you configure the default action to forward packets to the normal pipeline, unknown traffic will be broadcast in VLANs. This configuration affects the expected results. As a best practice, do not configure the default action to forward packets to the normal pipeline.
Setting the controller connection mode
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Set the controller connection mode.
controller mode { multiple | single }
By default, the multiple mode is used.
Preventing an OpenFlow instance from reporting the specified types of ports to controllers
About this task
Perform this task to prevent an OpenFlow instance from reporting to controllers information about the following types of interfaces that belong to an OpenFlow instance:
· Layer 3 Ethernet interface.
· Layer 3 aggregate interface.
· VLAN interface.
Procedure
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Prevent an OpenFlow instance from reporting the specified types of ports to controllers.
forbidden port { l3-physical-interface | vlan-interface | vsi-interface } *
By default, no port types are prevented from being reported to the controllers. All ports that belong to an OpenFlow instance are reported to the controllers.
The device does not support the vsi-interface keyword in the current software version.
Activating an OpenFlow instance
About this task
After you create or modify an OpenFlow instance, you must activate or re-activate the OpenFlow instance to make the configuration take effect. When an OpenFlow instance is reactivated, it disconnects from all controllers, clears the deployed flow tables, updates the capability set, and then reconnects to controllers.
Procedure
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Activate the OpenFlow instance.
active instance
By default, OpenFlow instances are not activated.
Configuring controllers for an OpenFlow instance
Restrictions and guidelines
To successfully establish an auxiliary connection, make sure the configuration of the auxiliary connection does not conflict with the configuration of the main connection.
Procedure
1. Enter system view.
system-view
2. Enter OpenFlow instance view.
openflow instance instance-id
3. Specify a controller and configure the main connection to the controller.
controller controller-id address { ip ipv4-address | ipv6 ipv6-address } [ port port-number ] [ local address { ip local-ipv4-address | ipv6 local-ipv6-address } [ port local-port- number ] ] [ ssl ssl-policy-name [ access-control-policy acp-policy-name ] ] [ vrf vrf-name ]
To successfully establish a connection to the specified controller, make sure the source IP address is the IP address of a port in the OpenFlow instance.
The access-control-policy keyword is supported only in release 6635 and later.
4. (Optional.) Specify a controller and configure an auxiliary connection to the controller.
controller controller-id auxiliary auxiliary-id transport { tcp | udp | ssl ssl-policy-name } [ address { ip ipv4-address | ipv6 ipv6-address } ] [ port port-number ]
By default, an OpenFlow instance does not have auxiliary connections to controllers.
5. (Optional.) Set the connection interruption mode.
fail-open mode { secure | smart | standalone }
By default, the secure mode is used.
6. (Optional.) Enable OpenFlow connection backup.
tcp-connection backup
By default, OpenFlow connection backup is enabled.
This feature prevents connection interruption when a master/subordinate switchover occurs.
This feature is available only on an IRF fabric with two member devices.
This feature is available for only OpenFlow connections established over TCP.
Configuring flow table settings on the controller
This section uses a SeerEngine-DC controller as an example.
Connecting the controller to a device
# Execute the connection command on the controller.
[root@openflowvm:~/controller1]# ./ovs-controller ptcp: -v &
Configuring meter entries
A meter table contains meter entries. Meter entries are referenced by flow entries to rate-limit packets matching flow entries.
Add
Restrictions and guidelines
· To successfully add a meter entry, make sure the specified meter_id is not in use.
· For the configured burst_size field to take effect, add burst in the flags field. If burst does not exist in the flags field, the actual burst_size value deployed is half the rate.
· The minimum rate granularity is 8.
Configuration example on the controller
# Create meter entry 1 on the controller. Set the rate limit to 1024 kbps and burst size to 1024000 kb.
[root@openflowvm:~/controller1]# ./ovs-appctl send_meter_mod 'command(add),flags
(kbps,burst),meter_id(1),bands(drop(rate(1024),burst_size(1024000)))'
20:54:48|tcp:172.16.144.135:33603: sent (Success): OFPT_METER_MOD (xid:9, len:32
)
20:54:48|OFPT_METER_MOD (xid:9)
|- command = add
|- flags = kbps|burst
|- meter_id = 1
|- bands
|- drop, rate(1024), burst_size(1024000)
# Verify the configuration on the device side.
[Sysname] display openflow instance 1 meter
Meter flags: KBPS -- Rate value in kb/s, PKTPS -- Rate value in packet/sec
BURST -- Do burst size, STATS -- Collect statistics
Instance 1 meter table information:
Meter entry count: 1
Meter entry 1 information:
Meter flags: KBPS|BURST
Band 1 information:
Type: drop, rate: 1024kbps, burst size: 1024000kb, prec_level:--
Byte count: 0, packet count: 0
Referenced information:
Count: 0
# Create meter entry 2 on the controller. Set the rate limit to 1024 kbps and burst size to 1024 kb.
[root@openflowvm:~/controller1]# ./ovs-appctl send_meter_mod 'command(add),flags
(kbps),meter_id(2),bands(drop(rate(1024),burst_size(1024)))'
23:58:33|tcp:172.16.144.135:33611: sent (Success): OFPT_METER_MOD (xid:7, len:32
)
23:58:33|OFPT_METER_MOD (xid:7)
|- command = add
|- flags = kbps
|- meter_id = 2
|- bands
|- drop, rate(1024), burst_size(1024)
# Verify the configuration on the device side.
[Sysname] display openflow instance 1 meter
Meter flags: KBPS -- Rate value in kb/s, PKTPS -- Rate value in packet/sec
BURST -- Do burst size, STATS -- Collect statistics
Instance 1 meter table information:
Meter entry count: 1
Meter entry 2 information:
Meter flags: KBPS
Band 1 information:
Type: drop, rate: 1024kbps, burst size: 512kb, prec_level:--
Byte count: 0, packet count: 0
Referenced information:
Count: 0
Modify
Restrictions and guidelines
Make sure the specified meter_id is that of an existing meter entry.
Configuration example on the controller
# Modify meter entry 1 on the controller. Modify the rate limit to 2048 kbps and burst size to 2048 kb.
[root@openflowvm:~/controller1]# ./ovs-appctl send_meter_mod 'command(modify),fl
ags(kbps,burst),meter_id(1),bands(drop(rate(2048),burst_size(2048)))'
23:51:10|tcp:172.16.144.135:33611: sent (Success): OFPT_METER_MOD (xid:5, len:32
)
23:51:10|OFPT_METER_MOD (xid:5)
|- command = modify
|- flags = kbps|burst
|- meter_id = 1
|- bands
|- drop, rate(2048), burst_size(2048)
# Verify the configuration on the device side.
[Sysname] display openflow instance 1 meter
Meter flags: KBPS -- Rate value in kb/s, PKTPS -- Rate value in packet/sec
BURST -- Do burst size, STATS -- Collect statistics
Instance 1 meter table information:
Meter entry count: 1
Meter entry 1 information:
Meter flags: KBPS|BURST
Band 1 information:
Type: drop, rate: 2048kbps, burst size: 2048kb, prec_level:--
Byte count: 0, packet count: 0
Referenced information:
Count: 0
Delete
Restrictions and guidelines
Make sure the specified meter_id is that of an existing meter entry.
Configuration example on the controller
# Delete meter entry 1 from the controller.
[root@openflowvm:~/controller1]# ./ovs-appctl send_meter_mod 'command(delete),me
ter_id(1)'
00:13:09|tcp:172.16.144.135:33612: sent (Success): OFPT_METER_MOD (xid:29, len:1
6)
00:13:09|OFPT_METER_MOD (xid:29)
|- command = delete
|- flags = 0
|- meter_id = 1
|- bands
Configuring group entries
A group table contains group entries. Group entries are referenced by flow entries to provide additional methods of forwarding.
Add
Restrictions and guidelines
· Make sure the specified group_id is not in use. A group ID identifies a group entry.
· A group entry can contain multiple different buckets, output actions, and set-field actions.
· To view the index of the port of an output action, execute the display system internal ifmgr list command in probe view.
· The set-field actions support modifying the source/destination MAC addresses, source/destination IP addresses, and source/destination UDP port numbers of packets.
· The set-field actions are optional.
Configuration example on the controller
# On the controller, create group entry 1.
· For bucket 1, specify the output port as 368. Set the source MAC, destination MAC, source IP, destination IP, source UDP port, and destination UDP port of packets to 00:ff:94:00:00:22, 00:ff:94:00:00:33, 100.0.0.8, 100.0.0.8, 12345, and 12345, respectively.
· For bucket 2, specify the output port as 367. Set the source MAC, destination MAC, source IP, destination IP, source UDP port, and destination UDP port of packets to 00:ff:94:00:00:22, 00:ff:94:00:00:33, 100.0.0.8, 100.0.0.8, 12345, and 12345, respectively.
[root@openflowvm:~/controller1]# ./ovs-appctl send_group_str 'command(add),type(
all),group_id(1),bucket(actions(output(368),set_field(eth_src(00:ff:94:00:00:22)
),set_field(eth_dst(00:ff:94:00:00:33)),set_field(ipv4_src(100.0.0.8)),set_field
(ipv4_dst(100.0.0.8)),set_field(udp_src(12345)),set_field(udp_dst(12345)))),buck
et(actions(output(367),set_field(eth_src(00:ff:94:00:00:22)),set_field(eth_dst(0
0:ff:94:00:00:33)),set_field(ipv4_src(100.0.0.8)),set_field(ipv4_dst(100.0.0.8))
,set_field(udp_src(12345)),set_field(udp_dst(12345))))'
00:30:05|tcp:172.16.144.135:33612: sent (Success): OFPT_GROUP_MOD (xid:32, len:2
72)
00:30:05|OFPT_GROUP_MOD (xid:32)
# Group_Mod
|- command = add
|- type = all
|- group_id = 1
|- bucket
|- weight = 0
|- watch_port = any
|- watch_group = any
|- actions
|- output,368 [max_len = 128]
|- set_field,eth_src,00:ff:94:00:00:22
|- set_field,eth_dst,00:ff:94:00:00:33
|- set_field,ipv4_src,100.0.0.8
|- set_field,ipv4_dst,100.0.0.8
|- set_field,udp_src,12345
|- set_field,udp_dst,12345
|- bucket
|- weight = 0
|- watch_port = any
|- watch_group = any
|- actions
|- output,367 [max_len = 128]
|- set_field,eth_src,00:ff:94:00:00:22
|- set_field,eth_dst,00:ff:94:00:00:33
|- set_field,ipv4_src,100.0.0.8
|- set_field,ipv4_dst,100.0.0.8
|- set_field,udp_src,12345
|- set_field,udp_dst,12345
# Verify the configuration on the device side.
[Sysname] display openflow instance 1 group
Instance 1 group table information:
Group count: 1
Group entry 1:
Type: All, byte count: 0, packet count: 0
Bucket 1 information:
Action count 2, watch port: any, watch group: any
Byte count 0, packet count 0
Set field:
Ethernet destination MAC address: 00ff-9400-0033
Ethernet source MAC address: 00ff-9400-0022
IPv4 source address: 100.0.0.8
IPv4 destination address: 100.0.0.8
UDP source port: 12345
UDP destination port: 12345
Output interface: WGE3/0/48
Bucket 2 information:
Action count 2, watch port: any, watch group: any
Byte count 0, packet count 0
Set field:
Ethernet destination MAC address: 00ff-9400-0033
Ethernet source MAC address: 00ff-9400-0022
IPv4 source address: 100.0.0.8
IPv4 destination address: 100.0.0.8
UDP source port: 12345
UDP destination port: 12345
Output interface: WGE3/0/47
Referenced information:
Count: 0
Modify
Restrictions and guidelines
· Make sure the specified group_id is that of an existing group entry.
· You can modify the output and set_field actions and add or delete buckets.
Configuration example on the controller
# On the controller, modify group entry 1.
· For bucket 1, specify the output port as 368. Set the source MAC, destination MAC, source IP, destination IP, source UDP port, and destination UDP port of packets to 00:ff:94:00:00:11, 00:ff:94:00:00:44, 200.0.0.8, 200.0.0.8, 54321, and 54321, respectively.
· For bucket 2, specify the output port as 366.
[root@openflowvm:~/controller1]# ./ovs-appctl send_group_str 'command(modify),ty
pe(all),group_id(1),bucket(actions(output(368),set_field(eth_src(00:ff:94:00:00:
11)),set_field(eth_dst(00:ff:94:00:00:44)),set_field(ipv4_src(200.0.0.8)),set_fi
eld(ipv4_dst(200.0.0.8)),set_field(udp_src(54321)),set_field(udp_dst(54321)))),b
ucket(actions(output(366)))'
01:25:48|tcp:172.16.144.135:33612: sent (Success): OFPT_GROUP_MOD (xid:33, len:1
76)
01:25:48|OFPT_GROUP_MOD (xid:33)
# Group_Mod
|- command = modify
|- type = all
|- group_id = 1
|- bucket
|- weight = 0
|- watch_port = any
|- watch_group = any
|- actions
|- output,368 [max_len = 128]
|- set_field,eth_src,00:ff:94:00:00:11
|- set_field,eth_dst,00:ff:94:00:00:44
|- set_field,ipv4_src,200.0.0.8
|- set_field,ipv4_dst,200.0.0.8
|- set_field,udp_src,54321
|- set_field,udp_dst,54321
|- bucket
|- weight = 0
|- watch_port = any
|- watch_group = any
|- actions
|- output,366 [max_len = 128]
# Verify the configuration on the device side.
[Sysname] display openflow instance 1 group
Instance 1 group table information:
Group count: 1
Group entry 1:
Type: All, byte count: 0, packet count: 0
Bucket 1 information:
Action count 2, watch port: any, watch group: any
Byte count 0, packet count 0
Set field:
Ethernet destination MAC address: 00ff-9400-0044
Ethernet source MAC address: 00ff-9400-0011
IPv4 source address: 200.0.0.8
IPv4 destination address: 200.0.0.8
UDP source port: 54321
UDP destination port: 54321
Output interface: WGE3/0/48
Bucket 2 information:
Action count 1, watch port: any, watch group: any
Byte count 0, packet count 0
Output interface: WGE3/0/46
Referenced information:
Count: 0
Delete
Restrictions and guidelines
Make sure the specified group_id is that of an existing group entry.
Configuration example on the controller
# Delete group entry 1 from the controller.
[root@openflowvm:~/controller1]# ./ovs-appctl send_group_str 'command(delete),ty
pe(all),group_id(1)'
01:49:35|tcp:172.16.144.135:33612: sent (Success): OFPT_GROUP_MOD (xid:36, len:1
6)
01:49:35|OFPT_GROUP_MOD (xid:36)
# Group_Mod
|- command = delete
|- type = all
|- group_id = 1
Configuring flow entries
OpenFlow uses flow tables to match and process packets. Packets are matched against flow entries in the same table according to the priorities of flow entries.
Add
Restrictions and guidelines
· The table_id argument specifies a flow table.
· By default, a table-miss flow entry exists to drop all traffic (except protocol packets) that does not match any rule.
· You can configure the match rules as needed.
· Meter entries are optional in the instruction field. For a write_actions instruction, you can specify a group ID or a specific output port.
Configuration example on the controller
# Create extensibility flow table 1 on the controller. Configure match criteria to match IP packets with the following fields:
· Source MAC address 00:10:94:00:00:22/ff:ff:ff:ff:ff:ff:ff:ff.
· Destination MAC address 00:10:94:00:00:44/ff:ff:ff:ff:ff:ff:ff:ff.
· Source IP address 192.85.1.2/255.255.255.255.
· Destination IP address 192.0.0.1/255.255.255.255.
· Source UDP port number 1024/65535.
· Destination UDP port number 1024/65535.
Specify meter entry 1 for the instruction field, and specify group entry 1 for the write_actions instruction.
[root@openflowvm:~/controller1]# ./ovs-appctl send_flow_str 'command(add),table_
id(1),priority(0),match(eth_type(0x0800),ip_proto(0x11),eth_src(00:10:94:00:00:2
2,ff:ff:ff:ff:ff:ff:ff:ff),eth_dst(00:10:94:00:00:44,ff:ff:ff:ff:ff:ff:ff:ff),ip
v4_src(192.85.1.2,255.255.255.255),ipv4_dst(192.0.0.1,255.255.255.255),udp_src(1
024,65535),udp_dst(1024,65535)),instruction(meter(1),write_actions(group(1)))'
01:56:35|tcp:172.16.144.135:33612: sent (Success): OFPT_FLOW_MOD (xid:42, len:16
0)
01:56:35|OFPT_FLOW_MOD (xid:42)
# Flow_Mod (48)
|- cookie = 0x0000000000000000
|- cookie_mask = 0x0000000000000000
|- table_id = 1
|- command = add
|- idle_timeout = 0
|- hard_timeout = 0
|- priority = 0
|- buffer_id = no_buffer
|- out_port = any
|- out_group = any
|- flags = 0
|- match
|- eth_type,0x0800
|- ip_proto,17
|- eth_src,00:10:94:00:00:22[ff:ff:ff:ff:ff:ff]
|- eth_dst,00:10:94:00:00:44[ff:ff:ff:ff:ff:ff]
|- ipv4_src,192.85.1.2[255.255.255.255]
|- ipv4_dst,192.0.0.1[255.255.255.255]
|- udp_src,1024[65535]
|- udp_dst,1024[65535]
|- instructions
|- meter, 1
|- write_actions
|- group,1
# Verify the configuration on the device side.
[Sysname] display openflow instance 1 flow-table
Instance 1 flow table information:
Table 1 information:
Table type: Extensibility, flow entry count: 1, total flow entry count: 2
MissRule (default) flow entry information:
cookie: 0x0, priority: 0, hard time: 0, idle time: 0, flags: reset_counts,
byte count: 0, packet count: 0
Create time:04:27:25 01/11/2011, Last modified time:04:27:25 01/11/2011
Match information: any
Instruction information:
Write actions:
Drop
Flow entry 1 information:
cookie: 0x0, priority: 0, hard time: 0, idle time: 0, flags: none,
byte count: 0, packet count: 0
Create time:06:20:06 01/11/2011, Last modified time:06:20:06 01/11/2011
Match information:
Ethernet destination MAC address: 0010-9400-0044
Ethernet destination MAC address mask: ffff-ffff-ffff
Ethernet source MAC address: 0010-9400-0022
Ethernet source MAC address mask: ffff-ffff-ffff
Ethernet type: 0x0800
IP protocol: 17
IPv4 source address: 192.85.1.2, mask: 255.255.255.255
IPv4 destination address: 192.0.0.1, mask: 255.255.255.255
UDP source port: 1024, mask: 0xffff
UDP destination port: 1024, mask: 0xffff
Instruction information:
Set meter: 1
Write actions:
Group: 1
Modify
Restrictions and guidelines
You can only modify the instruction and write_actions contents of a flow entry. You cannot modify the match criteria of a flow entry.
Configuration example on the controller
# On the controller, modify flow table 1. Set the write_actions field to output (368).
[root@openflowvm:~/controller1]# ./ovs-appctl send_flow_str 'command(modify),tab
le_id(1),priority(0),match(eth_type(0x0800),ip_proto(0x11),eth_src(00:10:94:00:0
0:22,ff:ff:ff:ff:ff:ff:ff:ff),eth_dst(00:10:94:00:00:44,ff:ff:ff:ff:ff:ff:ff:ff)
,ipv4_src(192.85.1.2,255.255.255.255),ipv4_dst(192.0.0.1,255.255.255.255),udp_sr
c(1024,65535),udp_dst(1024,65535)),instruction(meter(1),write_actions(output(368
)))'
02:18:05|tcp:172.16.144.135:33612: sent (Success): OFPT_FLOW_MOD (xid:48, len:16
8)
02:18:05|OFPT_FLOW_MOD (xid:48)
# Flow_Mod (48)
|- cookie = 0x0000000000000000
|- cookie_mask = 0x0000000000000000
|- table_id = 1
|- command = modify
|- idle_timeout = 0
|- hard_timeout = 0
|- priority = 0
|- buffer_id = no_buffer
|- out_port = any
|- out_group = any
|- flags = 0
|- match
|- eth_type,0x0800
|- ip_proto,17
|- eth_src,00:10:94:00:00:22[ff:ff:ff:ff:ff:ff]
|- eth_dst,00:10:94:00:00:44[ff:ff:ff:ff:ff:ff]
|- ipv4_src,192.85.1.2[255.255.255.255]
|- ipv4_dst,192.0.0.1[255.255.255.255]
|- udp_src,1024[65535]
|- udp_dst,1024[65535]
|- instructions
|- meter, 1
|- write_actions
|- output,368 [max_len = 128]
# Verify the configuration on the device side.
[Sysname] display openflow instance 1 flow-table
Instance 1 flow table information:
Table 1 information:
Table type: Extensibility, flow entry count: 1, total flow entry count: 2
MissRule (default) flow entry information:
cookie: 0x0, priority: 0, hard time: 0, idle time: 0, flags: reset_counts,
byte count: 0, packet count: 0
Create time:04:27:25 01/11/2011, Last modified time:04:27:25 01/11/2011
Match information: any
Instruction information:
Write actions:
Drop
Flow entry 1 information:
cookie: 0x0, priority: 0, hard time: 0, idle time: 0, flags: none,
byte count: 0, packet count: 0
Create time:06:20:06 01/11/2011, Last modified time:06:45:37 01/11/2011
Match information:
Ethernet destination MAC address: 0010-9400-0044
Ethernet destination MAC address mask: ffff-ffff-ffff
Ethernet source MAC address: 0010-9400-0022
Ethernet source MAC address mask: ffff-ffff-ffff
Ethernet type: 0x0800
IP protocol: 17
IPv4 source address: 192.85.1.2, mask: 255.255.255.255
IPv4 destination address: 192.0.0.1, mask: 255.255.255.255
UDP source port: 1024, mask: 0xffff
UDP destination port: 1024, mask: 0xffff
Instruction information:
Set meter: 1
Write actions:
Output interface: WGE3/0/48
Delete
Restrictions and guidelines
A flow table is identified by its match criteria. When deleting a flow table, you do not need to specify the instruction field.
Configuration example on the controller
# Delete flow table 1 from the controller.
[root@openflowvm:~/controller1]# ./ovs-appctl send_flow_str 'command(delete),tab
le_id(1),priority(0),match(eth_type(0x0800),ip_proto(0x11),eth_src(00:10:94:00:0
0:22,ff:ff:ff:ff:ff:ff:ff:ff),eth_dst(00:10:94:00:00:44,ff:ff:ff:ff:ff:ff:ff:ff)
,ipv4_src(192.85.1.2,255.255.255.255),ipv4_dst(192.0.0.1,255.255.255.255),udp_sr
c(1024,65535),udp_dst(1024,65535)),instruction(meter(1),write_actions(output(368
)))'
02:29:59|tcp:172.16.144.135:33612: sent (Success): OFPT_FLOW_MOD (xid:57, len:16
8)
02:29:59|OFPT_FLOW_MOD (xid:57)
# Flow_Mod (48)
|- cookie = 0x0000000000000000
|- cookie_mask = 0x0000000000000000
|- table_id = 1
|- command = delete
|- idle_timeout = 0
|- hard_timeout = 0
|- priority = 0
|- buffer_id = no_buffer
|- out_port = any
|- out_group = any
|- flags = 0
|- match
|- eth_type,0x0800
|- ip_proto,17
|- eth_src,00:10:94:00:00:22[ff:ff:ff:ff:ff:ff]
|- eth_dst,00:10:94:00:00:44[ff:ff:ff:ff:ff:ff]
|- ipv4_src,192.85.1.2[255.255.255.255]
|- ipv4_dst,192.0.0.1[255.255.255.255]
|- udp_src,1024[65535]
|- udp_dst,1024[65535]
|- instructions
|- meter, 1
|- write_actions
|- output,368 [max_len = 128]
Restrictions and guidelines: MC-NAT configuration
MC-NAT is supported only in F6619 and later. For how to upgrade the software version, see the release notes.
MC-NAT is not supported on an IRF fabric containing three or more member devices.
For a port in an OpenFlow instance in global mode to forward Layer 2 traffic, execute the default table-miss permit command on the OpenFlow instance.
For the device-side configuration, this chapter only describes basic OpenFlow configuration related to MC-NAT. For more information about OpenFlow configuration, see OpenFlow Configuration Guide in H3C S6805 & S6825 & S6850 & S9850 Switch Series Configuration Guides-Release 66xx or H3C S6805 & S6825 & S6850 & S9850 Switch Series Configuration Guides-Release 67xx.
In the current software version, the following packet editing modes are supported (the smac and dmac fields are not limited and can cooperate with any of the following modes):
· 0—Does not edit.
· 1—Edits dip.
· 2—Edits sip.
· 3—Edits sip+dip.
· 4—Edits dip+dport.
· 5—Edits sip+sport.
· 6—Edits sip+sport+dip+dport.
Example: Configuring MC-NAT
Network configuration
As shown in Figure 3, Switch A receives traffic from video source Source 1 on Internet. Configure the SeerEngine-DC controller to deploy OpenFlow flow entries and group entries to meet the following requirements:
· Switch A translate the public network address to a private network address for a packet received from Source 1 in VLAN 4081.
· Switch A sets the destination IP, destination MAC, and destination UDP port number of a packet according to each target host IP.
· Switch A sends the NATed packets to Host A and Host B on the private network.
|
Device name |
MAC |
IP |
UDP |
|
Source 1 |
00:02:fc:00:22:2b |
10.110.5.100 |
6457 |
|
Host A |
00:e0:4c:68:0e:d4 |
192.168.4.2 |
4488 |
|
Host B |
00:50:56:c0:00:08 |
192.168.5.2 |
2356 |
Analysis
· Make sure Switch A and the controller can reach each other so that the OpenFlow instance can establish an OpenFlow channel with the controller. In this example, Switch A uses the management interface to communicate with the controller.
· For the receiver hosts to receive traffic from the source, configure the controller to issue the OpenFlow flow entry and group entry that meets the following requirements:
¡ Switch A can use the flow entry to match packets from Source 1.
¡ Switch A can use the group entry to change the VLAN ID, destination IP address, destination MAC address, and destination UDP number of the matching packets to those of Host A and Host B.
¡ Switch A can use the group entry to forward the matching packets out of Twenty-FiveGigE 1/0/4 and Twenty-FiveGigE 1/0/5.
Procedure
Configure Switch A
# Create VLANs. Assign Ethernet interfaces to VLANs as needed.
<SwitchA> system-view
[SwitchA] vlan 4 5 4081
[SwitchA] interface twenty-fivegige 1/0/1
[SwitchA-Twenty-FiveGigE1/0/1] port link-type trunk
[SwitchA-Twenty-FiveGigE1/0/1] undo port trunk permit vlan 1
[SwitchA-Twenty-FiveGigE1/0/1] port trunk permit vlan 4081
[SwitchA-Twenty-FiveGigE1/0/1] quit
[SwitchA] interface twenty-fivegige 1/0/4
[SwitchA-Twenty-FiveGigE1/0/4] port link-type trunk
[SwitchA-Twenty-FiveGigE1/0/4] undo port trunk permit vlan 1
[SwitchA-Twenty-FiveGigE1/0/4] port trunk permit vlan 4
[SwitchA-Twenty-FiveGigE1/0/4] quit
[SwitchA] interface twenty-fivegige 1/0/5
[SwitchA-Twenty-FiveGigE1/0/5] port link-type trunk
[SwitchA-Twenty-FiveGigE1/0/5] undo port trunk permit vlan 1
[SwitchA-Twenty-FiveGigE1/0/5] port trunk permit vlan 5
[SwitchA-Twenty-FiveGigE1/0/5] quit
# Configure M-GigabitEthernet 0/0/0 on Switch A for communicating with the controller.
[SwitchA] interface M-GigabitEthernet 0/0/0
[SwitchA-M-GigabitEthernet0/0/0] ip address 172.16.147.136 255.255.0.0
[SwitchA-M-GigabitEthernet0/0/0] quit
# Create OpenFlow instance 1 and configure it to operate in global mode.
[SwitchA] openflow instance 1
[SwitchA-of-inst-1] classification global
# Specify controller 0 with IP address 172.16.147.101 for OpenFlow instance 1 and activate the instance.
[SwitchA-of-inst-1] controller 0 address ip 172.16.147.101
[SwitchA-of-inst-1] active instance
[SwitchA-of-inst-1] quit
Configure the controller
# Create group entry 1 that contains the following buckets to OpenFlow instance 1:
· Bucket 1 that contains the following actions:
¡ Send the packets out of Twenty-FiveGigE 1/0/4.
¡ Change the following fields in the packets: VLAN ID (4), destination IP address (192.168.4.2), destination MAC address (00:e0:4c:68:0e:d4), and destination UDP port number (4488).
· Bucket 2 that contains the following actions:
¡ Send the packets out of Twenty-FiveGigE 1/0/5.
¡ Change the following fields in the packets: VLAN ID (5), destination IP address (192.168.5.2), destination MAC address (00:50:56:c0:00:08), and destination UDP port number (2356).
[root@openflowvm:~/controller0]# ./ovs-appctl send_group_str 'command(add),type(
all),group_id(1),bucket(actions(output(742),set_field(vlan_vid(4+1)),set_field(eth_dst(00:e0:4c:68:0e:d4)),set_field(ipv4_dst(192.168.4.2)),set_field(udp_dst(4488)))),bucket(actions(output(743),set_field(vlan_vid(5+1)),set_field(eth_dst(00:50:56:c0:00:08)),set_field(ipv4_dst(192.168.5.2)),set_field(udp_dst(2356))))'
22:46:56|tcp:172.16.147.136:4425: sent (Success): OFPT_GROUP_MOD (xid:31, len:16
0)
22:46:56|OFPT_GROUP_MOD (xid:31)
# Group_Mod
|- command = add
|- type = all
|- group_id = 1
|- bucket
|- weight = 0
|- watch_port = any
|- watch_group = any
|- actions
|- output,742 [max_len = 128]
|- set_field,vlan_vid,4+1
|- set_field,eth_dst,00:e0:4c:68:0e:d4
|- set_field,ipv4_dst,192.168.4.2
|- set_field,udp_dst,4488
|- bucket
|- weight = 0
|- watch_port = any
|- watch_group = any
|- actions
|- output,743 [max_len = 128]
|- set_field,vlan_vid,5+1
|- set_field,eth_dst,00:50:56:c0:00:08
|- set_field,ipv4_dst,192.168.5.2
|- set_field,udp_dst,2356
[root@openflowvm:~/controller0]#
# Issue flow entry 1 of table 0 to OpenFlow instance 1. The flow entry contains the following match fields: input port Twenty-FiveGigE 1/0/1, VLAN ID 4081, source IP address 10.110.5.100, source MAC address 00:02:fc:00:22:2b, and source UDP port 6457. Group entry 1 is specified to process the matching packets.
[root@openflowvm:~/controller0]# ./ovs-appctl send_flow_str 'command(add),table_
id(0),priority(1),match(in_port(739),vlan_vid(4081+1),eth_src(00:02:fc:00:22:2b),eth_type(0x800),ipv4_src(10.110.5.100),ip_proto(17),udp_src(6457)),instruction(write_actions(group(1)))'
23:08:24|tcp:172.16.147.136:4425: sent (Success): OFPT_FLOW_MOD (xid:35, len:120
)
23:08:24|OFPT_FLOW_MOD (xid:35)
# Flow_Mod (48)
|- cookie = 0x0000000000000000
|- cookie_mask = 0x0000000000000000
|- table_id = 0
|- command = add
|- idle_timeout = 0
|- hard_timeout = 0
|- priority = 1
|- buffer_id = no_buffer
|- out_port = any
|- out_group = any
|- flags = 0
|- match
|- in_port,739
|- vlan_vid,4081+1
|- eth_src,00:02:fc:00:22:2b
|- eth_type,0x0800
|- ipv4_src,10.110.5.100
|- ip_proto,17
|- udp_src,6457
|- instructions
|- write_actions
|- group,1
[root@openflowvm:~/controller0]#
Verifying the configuration
Verify the configuration on Switch A.
# Display group entry information for OpenFlow instance 1 on Switch A.
[SwitchA] display openflow instance 1 group
Instance 1 group table information:
Group count: 1
Group entry 1:
Type: All, byte count: 0, packet count: 0
Bucket 1 information:
Action count 2, watch port: any, watch group: any
Byte count 0, packet count 0
Set field:
Ethernet destination MAC address: 00e0-4c68-0ed4
VLAN ID: 4
IPv4 destination address: 192.168.4.2
UDP destination port: 4488
Output interface: WGE1/0/4
Bucket 2 information:
Action count 2, watch port: any, watch group: any
Byte count 0, packet count 0
Set field:
Ethernet destination MAC address: 0050-56c0-0008
VLAN ID: 5
IPv4 destination address: 192.168.5.2
UDP destination port: 2356
Output interface: WGE1/0/5
Referenced information:
Count: 1
Flow table: 0
Flow entry: 1
The output shows that OpenFlow instance 1 has created the group entry issued by the controller. Group entry 1 is configured to set the specified fields in matching packets and send the modified packets out of Twenty-FiveGigE 1/0/4 and Twenty-FiveGigE 1/0/5.
# Display flow entry information for OpenFlow instance 1 on Switch A.
[SwitchA] display openflow instance 1 flow
Instance 1 flow table information:
Table 0 information:
Table type: Extensibility, flow entry count: 1, total flow entry count: 2
MissRule (default) flow entry information:
cookie: 0x0, priority: 0, hard time: 0, idle time: 0, flags: reset_counts,
byte count: 383689, packet count: 3330
Create time:19:07:20 01/06/2019, Last modified time:19:07:20 01/06/2019
Match information: any
Instruction information:
Write actions:
Drop
Flow entry 1 information:
cookie: 0x0, priority: 1, hard time: 0, idle time: 0, flags: none,
byte count: 0, packet count: 0
Create time:19:30:33 01/06/2019, Last modified time:19:30:33 01/06/2019
Match information:
Input interface: WGE1/0/1
Ethernet source MAC address: 0002-fc00-222b
Ethernet source MAC address mask: ffff-ffff-ffff
Ethernet type: 0x0800
VLAN ID: 4081, mask: 0xfff
IP protocol: 17
IPv4 source address: 10.110.5.100, mask: 255.255.255.255
UDP source port: 6457, mask: 0xffff
Instruction information:
Write actions:
Group: 1
The output shows that OpenFlow instance 1 has created the flow entry issued by the controller in table 0. The instance will use the flow entry to match packets from Source 1 and use group entry 1 to process the matching packets.
Configuration files
· Switch A:
#
interface M-GigabitEthernet0/0/0
ip address 172.16.147.136 255.255.0.0
#
openflow instance 1
classification global
controller 0 address ip 172.16.147.101
active instance
#
interface Twenty-FiveGigE1/0/1
port link-mode bridge
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 4081
#
interface Twenty-FiveGigE1/0/4
port link-mode bridge
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 4
#
interface Twenty-FiveGigE1/0/5
port link-mode bridge
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 5
#
Configuring PTP
About PTP
Precision Time Protocol (PTP) provides time synchronization among devices with submicrosecond accuracy. It provides also precise frequency synchronization.
Basic concepts
PTP profile
PTP profiles (PTP standards) include:
· IEEE 1588 version 2—1588v2 defines high-accuracy clock synchronization mechanisms. It can be customized, enhanced, or tailored as needed. 1588v2 is the latest version.
· IEEE 802.1AS—802.1AS is introduced based on IEEE 1588. It specifies a profile for use of IEEE 1588-2008 for time synchronization over a virtual bridged local area network (as defined by IEEE 802.1Q). 802.1AS supports only point-to-point full-duplex Ethernet, IEEE 802.11, and IEEE 802.3 EPON links.
· SMPTE ST 2059-2—ST2059-2 is introduced based on IEEE 1588. It specifies a profile specifically for time synchronization of audio or video equipment in a professional broadcast environment. It includes a self-contained description of parameters, their default values, and permitted ranges. It provides time and frequency synchronization among devices with nanosecond accuracy.
· AES67-2015—AES67-2015 is introduced based on IEEE 1588. It specifies a profile specifically for time synchronization of professional equipment for broadcast, music production, and film and television post-production. It includes a self-contained description of parameters, their default values, and permitted ranges.
This document is based on ST2059-2 to describe the PTP mechanism
PTP domain
A PTP domain refers to a network or part of a network that is enabled with PTP. A PTP domain has only one reference clock called "grandmaster clock (GM)." All devices in the domain synchronize to the clock.
PTP instance
When the device belongs to multiple PTP domains, you need to configure and associate a PTP instance to each PTP domain. In PTP instance view, you can configure PTP settings such as PTP profile and clock node type. The settings take effect only on the PTP domain associated with the PTP instance. PTP instances are isolated from each other, allowing different PTP timing systems running on a network without affecting each other.
Optimal PTP domain
Each PTP instance has a reference clock and clock information. For a device that has multiple PTP instances running simultaneously, you need to select an optimal PTP instance and use the clock source traced by this PTP instance to synchronize the system time of the device. The domain to which the optimal PTP associates is the optimal domain.
Clock node and PTP port
A node in a PTP domain is a clock node. A port enabled with PTP is a PTP port. PTP defines the following types of basic clock nodes:
· Ordinary Clock (OC)—A PTP clock with a single PTP port in a PTP domain for time synchronization. It synchronizes time from its upstream clock node through the port. If an OC operates as the clock source, it sends synchronization time through a single PTP port to its downstream clock nodes.
· Boundary Clock (BC)—A clock with more than one PTP port in a PTP domain for time synchronization. A BC uses one of the ports to synchronize time from its upstream clock node. It uses the other ports to synchronize time to the relevant upstream clock nodes. If a BC operates as the clock source, such as BC 1 in Figure 4, it synchronizes time through multiple PTP ports to its downstream clock nodes.
· Transparent Clock (TC)—A TC does not keep time consistency with other clock nodes. A TC has multiple PTP ports. It forwards PTP messages among these ports and performs delay corrections for the messages, instead of performing time synchronization. TCs include the following types:
¡ End-to-End Transparent Clock (E2ETC)—Forwards all P2P PTP packets in the network and calculates the delay of the entire link.
¡ Peer-to-Peer Transparent Clock (P2PTC)—Forwards only Sync, Follow_Up, and Announce messages, terminates other PTP messages, and calculates the delay of each link segment.
|
|
IMPORTANT: OC and BC clock nodes do much more work than TCs. When multiple PTP domains are configured on the device, the synchronization performance might fluctuate or decrease, and synchronization failure might occur due to limitation of hardware resources. As a best practice, configure the device operating in multiple domains as an OC or BC clock node in a maximum of one PTP instance, to decrease calculations, minimize mutual influences between the domains, and optimize the synchronization performance. |
Figure 4 shows the positions of these types of clock nodes in a PTP domain.
Figure 4 Clock nodes in a PTP domain
In addition to these basic types of clock nodes, PTP introduces hybrid clock nodes. For example, a TC+OC has multiple PTP ports in a PTP domain. One port is the OC type, and the others are the TC type.
A TC+OC forwards PTP messages through TC-type ports and performs delay corrections. In addition, it synchronizes time through its OC-type port. TC+OCs include these types: E2ETC+OC and P2PTC+OC.
Master-member/subordinate relationship
The master-member/subordinate relationship is automatically determined based on the Best Master Clock (BMC) algorithm. You can also manually specify a role for the clock nodes.
The master-member/subordinate relationship is defined as follows:
· Master/Member node—A master node sends a synchronization message, and a member node receives the synchronization message.
· Master/Member clock—The clock on a master node is a master clock (parent clock) The clock on a member node is a member clock.
· Master/Subordinate port—A master port sends a synchronization message, and a subordinate port receives the synchronization message. The master and subordinate ports can be on a BC or an OC.
A port that neither receives nor sends synchronization messages is a passive port.
Clock source type
A clock node supports the following clock sources:
· Local clock source—38.88 MHz clock signals generated by a crystal oscillator inside the clock monitoring module.
· External clock source—Clock signals generated by an external clock device. The signals are received and sent by a 1PPS/ToD port on the MPU. It is also called a ToD clock source.
Grandmaster clock
As shown in Figure 4, the grandmaster clock (GM) is the ultimate source of time for clock synchronization in a PTP domain. It is elected automatically by the clock nodes in the PTP domain. The clock nodes exchange PTP messages and elect the GM by comparing the clock priority, time class, and time accuracy carried in the PTP messages.
You can also specify a GM manually.
Clock source
The clock source used by clock nodes is 38.88 MHz clock signals generated by a crystal oscillator inside the clock monitoring module of the device.
Grandmaster clock selection and master-member/subordinate relationship establishment
A GM can be manually specified. It can also be elected through the BMC algorithm as follows:
1. The clock nodes in a PTP domain exchange announce messages and elect a GM by using the following rules in descending order:
a. Clock node with higher priority 1.
b. Clock node with higher time class.
c. Clock node with higher time accuracy.
d. Clock node with higher priority 2.
e. Clock node with a smaller port ID (containing clock number and port number).
The master nodes, member nodes, master ports, and subordinate ports are determined during the process. Then a spanning tree with the GM as the root is generated for the PTP domain.
2. The master node periodically sends announce messages to the member nodes. If the member nodes do not receive announce messages from the master node, they determine that the master node is invalid, and they start to elect another GM.
Optimal domain selection
If only one PTP instance is configured on the device, this PTP instance is the optimal instance of the device. If multiple PTP instances are configured on the device, the optimal PTP instance (domain) is selected by using the following rules in descending order:
1. Instance activated.
2. Instance on which the device is an OC or BC clock node.
3. Instance on which the clock source has a higher priority 1 value
4. Instance on which the clock source has a higher time class.
5. Instance on which the clock source has a higher time accuracy.
6. Instance on which the clock source has a lower offset from the GM.
7. Instance on which the clock source has a higher priority 2 value.
8. Instance associated with a PTP domain that has a smaller domain ID.
The PTP instance on which the ptp active force-state command is configured has the lowest priority.
Synchronization mechanism
After master-member relationships are established between the clock nodes, the master and member clock nodes exchange PTP messages and record the message transmit and receive time. Based on the timestamps, each member clock calculates the path delay and time offset between them and the master clock and adjusts their time accordingly for time synchronization with the master clock.
PTP defines two path delay measurement mechanisms: Request_Response_ and Peer Delay, both of which are based on network symmetry.
Request_Response
The Request_Response mechanism measures the average path delay between the master and member clock nodes by using the PTP messages as shown in Figure 5. A TC between master and member clock nodes does not calculate the path delay. It forwards PTP messages and carries the Sync message residence time on it to the downstream clock node.
This mechanism can be implemented in one of the following two modes:
· Two-step mode—t1 is carried in the Follow_Up message as shown in Figure 5.
· Single-step mode—t1 is carried in the Sync message, and no Follow_Up message is sent.
This mode is not supported in the current software version.
Figure 5 shows the Request_Response mechanism in two-step mode.
1. The master clock sends a Sync message to the member clock, and records the sending time t1. Upon receiving the message, the member clock records the receiving time t2.
2. After sending the Sync message, the master clock immediately sends a Follow_Up message that carries time t1.
3. The member clock sends a Delay_Req message to the master clock, and records the sending time t3. Upon receiving the message, the master clock records the receiving time t4.
4. The master clock returns a Delay_Resp message that carries time t4.
After this procedure, the member clock obtains all the four timestamps and can make the following calculations:
· Round-trip delay between the master and member clocks: (t2 – t1) + (t4 – t3)
· One-way delay between the master and member clocks: [(t2 – t1) + (t4 – t3)] / 2
· Offset between the member and master clocks: (t2 – t1) – [(t2 – t1) + (t4 – t3)] / 2 or [(t2 – t1) – (t4 – t3)] / 2
Figure 5 Request_Response mechanism (two-step node)
Peer Delay
The Peer Delay mechanism measures the average path delay between two clock nodes. The two clock nodes (BC, TC, or OC) implementing this mechanism send Pdelay messages to each other, and calculate the one-way link delay between them independently. The message interaction process and delay calculation method are identical on the two nodes. TCs that exist between master and member clock nodes divide the synchronization path into multiple links and participate in delay calculation. The link delays and Sync message residence time on the TCs are carried to downstream nodes.
This mechanism can be implemented in one of the following two modes:
· Two-step mode
As shown in Figure 6, Pdelay messages include Pdelay_Req, Pdelay_Resp, and Pdelay_Resp_Follow_Up messages. t2 is carried in the Pdelay_Resp message, and t3 is carried in the Pdelay_Resp_Follow_Up message.
· Single-step mode:
¡ t1 is carried in the Sync message, and no Follow_Up message is sent.
¡ The offset between t5 and t4 is carried in the Pdelay_Resp message, and no Pdelay_Resp_Follow_Up message is sent.
This mode is not supported in the current software version.
Figure 6 uses Clock node B as an example to describe the Peer Delay mechanism.
1. Clock node B sends a Pdelay_Req message to Clock node A, and records the sending time t1. Upon receiving the message, Clock node A records the receiving time t2.
2. Clock node A sends a Pdelay_Req message that carries t2 to Clock node B, and records the sending time t3. Upon receiving the message, Clock node B records the receiving time t4.
3. Clock node A immediately sends a Pdelay_Resp_Follow_Up message carrying t3 to Clock node B after sending the Pdelay_Req message.
After this procedure, Clock node B obtains all the four timestamps and can make the following calculations:
· Round-trip delay between Clock node A and Clock node B: (t2 – t1) + (t4 – t3)
· One-way delay between Clock node A and Clock node B: [ (t2 – t1) + (t4 – t3)] / 2 = [ (t4 – t1) - (t3 – t2) ] / 2
· Time offset between the member clock and the master clock: Sync message receiving time on the member clock – Sync message sending time on the master clock – Total one-way delays on all links – Total Sync message residence time on all TCs.
Figure 6 Peer Delay mechanism (two-step mode)
Protocols and standards
SMPTE ST 2059-2, SMPTE Profile for Use of IEEE-1588 Precision Time Protocol in Professional Broadcast Applications
Restrictions: Hardware compatibility with PTP
The device does not provide ToD interfaces or support external clock sources.
Restrictions and guidelines: PTP configuration
On a network that uses PTP for time synchronization, do not specify NTP for obtaining the time or use the system time as the clock source on a device. If you do so, PTP time might jump and a PTP lock loss error might be reported because of low accuracy of NTP and system time.
As a best practice, assign the interface that connects to a cloud source to a different VLAN than other service interfaces on a network that uses PTP for time synchronization. Violation of this rule might cause time synchronization failure, because the cloud source might send the received packets back to the interface.
PTP (SMPTE ST 2059-2) tasks at a glance
1. Specifying PTP for obtaining the time
Specify the SMPTE ST 2059-2 PTP profile.
¡ Specifying a clock node type
¡ (Optional.) Configuring an OC to operate only as a member clock
4. (Optional.) Specifying a PTP domain
5. Enabling PTP
To run PTP on an interface, enable PTP globally and on the interface.
¡ (Optional.) Configuring the role of a PTP port
¡ Configuring the mode for carrying timestamps
¡ Specifying a delay measurement mechanism for a BC or an OC
7. (Optional.) Configuring PTP message transmission and receipt
¡ Setting the interval for sending Pdelay_Req messages
¡ Setting the interval for sending Sync messages
¡ Setting the minimum interval for sending Delay_Req messages
8. (Optional.) Configuring parameters for PTP messages
¡ Configuring a source IP address for multicast PTP message transmission over IPv4 UDP
¡ Configuring a destination IP address for unicast PTP message transmission over IPv4 UDP
¡ Setting a DSCP value for PTP messages transmitted over IPv4 UDP
¡ Specifying a VLAN tag for PTP messages
9. (Optional.) Adjusting and correcting clock synchronization
¡ Setting the delay correction value
¡ Setting the cumulative offset between the UTC and TAI
¡ Setting the correction date of the UTC
10. (Optional.) Configuring a priority for a clock
11. (Optional.) Configuring the PTP time locking and unlocking thresholds
Specifying PTP for obtaining the time
1. Enter system view.
system-view
2. Specify PTP for obtaining the time.
clock protocol ptp
By default, the device uses NTP to obtain the system time.
Creating a PTP instance
About this task
A PTP instance is uniquely identified by its ID on a device. For easy identification and management, you can also set a name for a PTP instance.
Restrictions and guidelines
Do not set a same name for different PTP instances.
If you create PTP instances with the same ID but different names, the most recent configuration takes effect.
PTP instance 0 is the default PTP instance. You cannot create or delete PTP instance 0. PTP settings configured in system view take effect only on PTP instance 0. To configure settings for a PTP instance other than PTP instance 0, enter PTP instance view.
Procedure
1. Enter system view.
system-view
2. Create a PTP instance.
ptp instance ptp-instance-id [ name ptp-instance-name ]
By default, PTP instance numbered 0 and named default-instance exists.
Specifying a PTP profile
Restrictions and guidelines
You must specify a PTP profile before configuring PTP settings. Changing the PTP profile clears all settings under the profile.
Procedure
1. Enter system view.
system-view
2. (Optional.) Enter PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
3. Specify a PTP profile.
ptp profile { 1588v2 | 8021as | aes67-2015 | st2059-2 }
By default, no PTP profile is configured, and PTP is not running on the device.
Configuring clock nodes
Specifying a clock node type
Restrictions and guidelines
You can specify only one clock node type for the device. The clock node types include OC, BC, E2ETC, P2PTC, E2ETC+OC, and P2PTC+OC.
Before you specify a clock node type, specify a PTP profile.
You cannot specify the E2ETC+OC or P2PTC+OC clock node type.
Changing or removing the clock node type restores the default settings of the PTP profile.
In the high-resolution audio and video data transmission scenario, you can specify the BC or TC clock node type for the device. As a best practice, specify the BC clock node type for the device and specify the OC clock node type for IP endpoints.
Procedure
1. Enter system view.
system-view
2. (Optional.) Enter PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
3. Specify a clock node type for the device.
ptp mode { bc | e2etc | oc | p2ptc }
By default, no clock node type is specified.
Configuring an OC to operate only as a member clock
About this task
An OC can operate either as a master clock to send synchronization messages or as a member clock to receive synchronization messages. This task allows you to configure an OC to operate only as a member clock.
If an OC is operating only as a member clock, you can use the ptp force-state command to configure its PTP port as a master port or passive port.
Restrictions and guidelines
This task is applicable only to OCs.
Procedure
1. Enter system view.
system-view
2. (Optional.) Enter PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
3. Configure the OC to operate only as a member clock.
ptp slave-only
By default, an OC operates as a master or member clock.
Specifying a PTP domain
About this task
Within a PTP domain, all devices follow the same rules to communicate with each other. Devices in different PTP domains cannot exchange PTP messages.
Procedure
1. Enter system view.
system-view
2. (Optional.) Enter PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
3. Specify a PTP domain for the device.
ptp domain value
By default, no PTP domain exists.
Do not configure a same domain on different PTP instances.
Enabling PTP globally
Restrictions and guidelines
For PTP to run on an interface, you must enable PTP globally and on the interface.
Procedure
1. Enter system view.
system-view
2. Enable PTP globally.
ptp global enable
By default, PTP is enabled globally.
Enabling PTP on a port
About this task
A port enabled with PTP becomes a PTP port.
Restrictions and guidelines
You can enable PTP on only one port on an OC.
To enable PTP on a Layer 3 Ethernet interface that has been assigned to a VPN instance, you must specify this VPN instance in the ptp source ip-address vpn-instance vpn-instance-name command if PTP messages are to be transmitted in multicast mode over IPv4 UDP.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Enable PTP on the port.
ptp enable
By default, PTP is disabled on a port.
Configuring PTP ports
Configuring the role of a PTP port
About this task
You can configure the master, passive, or slave role for a PTP port.
For an OC that operates in slave-only mode, you can perform this task to change its PTP port role to master or slave.
Restrictions and guidelines
By default, the PTP port roles are automatically negotiated based on the BMC algorithm. If you use this task to change the role of one PTP port, all the other PTP ports in the PTP domain stop working. For these PTP ports to function, you must specify roles for each of them. As a best practice, enable automatic negotiation of PTP port roles based on the BMC algorithm.
Only one subordinate port is allowed to be configured for a device.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Configure the role of the PTP port.
ptp force-state { master | passive | slave }
By default, the PTP port role is automatically calculated through BMC.
5. Return to system view.
quit
6. (Optional.) Enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
7. Activate the port role configuration.
ptp active force-state
By default, the port role configuration is not activated.
Configuring the mode for carrying timestamps
About this task
Timestamps can be carried in either of the following modes:
· Single-step mode—The Sync message (in the Request_Response or Peer Delay mechanism) and Pdelay_Resp message (in the Peer Delay mechanism) carry their sending timestamps by themselves.
· Two-step mode—The Sync message (in the Request_Response or Peer Delay mechanism) and Pdelay_Resp message (in the Peer Delay mechanism) do not carry their sending timestamps by themselves. The subsequent messages carry their sending timestamps.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Configure the mode for carrying timestamps.
ptp clock-step two-step
By default, the two-step mode is used for carrying timestamps.
Specifying a delay measurement mechanism for a BC or an OC
About this task
PTP defines two transmission delay measurement mechanisms: Request_Response and Peer Delay. For correct communication, ports on the same link must share the same delay measurement mechanism.
Restrictions and guidelines
When the PTP profile is IEEE 1588 version 2, SMPTE ST 2059-2, or AES67-2015, the following restrictions apply:
· You can configure this task only for a BC or OC clock node.
· You cannot configure this task for an E2ETC, E2ETC+OC, P2PTC, or P2PTC+OC clock node. The E2ETC and E2ETC+OC clock nodes support both Request_Response and Peer Delay measurement mechanisms. A P2PTC clock node supports only the Peer Delay measurement mechanism.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Specify a delay measurement mechanism for a BC or an OC.
ptp delay-mechanism { e2e | p2p }
The default delay measurement mechanism is Request_Response delay measurement.
Configuring PTP message transmission and receipt
Setting the interval for sending announce messages and the timeout multiplier for receiving announce messages
About this task
A master node sends announce messages to the member nodes at the specified interval. If a member node does not receive any announce messages from the master node within the specified interval, it determines that the master node is invalid.
The timeout for receiving announce messages is the announce message sending interval for the subordinate node × multiple-value.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Set the interval for sending announce messages.
ptp announce-interval interval
The interval argument value is –2 and the interval for sending announce messages is 1/4 (2-2) seconds.
5. Set the number of intervals before a timeout occurs.
ptp announce-timeout multiple-value
By default, a timeout occurs when three intervals are reached.
Setting the interval for sending Pdelay_Req messages
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Set the interval for sending Pdelay_Req messages.
ptp pdelay-req-interval interval
By default, the interval argument value is 0 and the interval for sending peer delay request messages is 1 (20) second.
As a best practice, set the interval argument to a value in the range of ptp syn-interval interval to ptp syn-interval interval plus 5.
Setting the interval for sending Sync messages
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Set the interval for sending Sync messages.
ptp syn-interval interval
The interval argument value is –3 and the interval for sending Sync messages is 1/8 (2-3) seconds.
Setting the minimum interval for sending Delay_Req messages
About this task
When receiving a Sync or Follow_Up message, an interface can send Delay_Req messages only when the minimum interval is reached. This task allows you to set the minimum interval for sending Delay_Req messages.
Restrictions and guidelines
In PTP multicast transport mode, this setting takes effect only when configured on the master clock. The master clock sends the value to a member clock through PTP messages to control the interval for the member clock to send Delay_Req messages. To view the interval, execute the display ptp interface command on the member clock.
In PTP unicast transport mode, this setting takes effect when configured on member clocks. It does not take effect when configured on the master clock.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Set the minimum interval for sending Delay_Req messages.
ptp min-delayreq-interval interval
The interval argument value is 0 and the minimum interval for sending delay request messages is 1 (20) second.
As a best practice, set the interval argument to a value in the range of ptp syn-interval interval to ptp syn-interval interval plus 5.
Configuring parameters for PTP messages
Configuring a source IP address for multicast PTP message transmission over IPv4 UDP
About this task
To transport multicast PTP messages over IPv4 UDP, you must configure a source IP address for the messages.
Restrictions and guidelines
If both a source IP address for multicast PTP message transmission over IPv4 UDP and a destination address for unicast PTP message transmission over IPv4 UDP are configured, the system unicasts the messages.
Procedure
1. Enter system view.
system-view
2. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
3. Configure a source IP address for multicast PTP message transmission over IPv4 UDP.
ptp source ip-address [ vpn-instance vpn-instance-name ]
By default, no source IP address is configured for multicast PTP message transmission over IPv4 UDP.
Configuring a destination IP address for unicast PTP message transmission over IPv4 UDP
About this task
To transport unicast PTP messages over IPv4 UDP, you must configure a destination IP address for the messages.
Restrictions and guidelines
If both a source IP address for multicast PTP message transmission over IPv4 UDP and a destination address for unicast PTP message transmission over IPv4 UDP are configured, the system unicasts the messages.
Prerequisites
Configure an IP address for the current interface, and make sure the interface and the peer PTP interface can reach each other.
Procedure
1. Enter system view.
system-view
2. Enter Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Configure a destination IP address for unicast PTP message transmission over IPv4 UDP.
ptp unicast-destination ip-address
By default, no destination IP address is configured for unicast PTP message transmission over IPv4 UDP.
Setting a DSCP value for PTP messages transmitted over IPv4 UDP
About this task
The DSCP value determines the sending precedence of PTP messages transmitted over IPv4 UDP.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Set a DSCP value for PTP messages transmitted over IPv4 UDP.
ptp dscp dscp
By default, the DSCP value is 56.
Specifying a VLAN tag for PTP messages
About this task
Perform this task to configure the VLAN ID and the 802.1p precedence in the VLAN tag carried by PTP messages.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Specify a VLAN tag for PTP messages.
ptp vlan vlan-id [ dot1p dot1p-value ]
By default, PTP messages do not have a VLAN tag.
Adjusting and correcting clock synchronization
Setting the delay correction value
About this task
PTP performs time synchronization based on the assumption that the delays in sending and receiving messages are the same. However, this is not practical. If you know the offset between the delays in sending and receiving messages, you can set the delay correction value for more accurate time synchronization.
Procedure
1. Enter system view.
system-view
2. Enter Layer 2 Ethernet interface view or Layer 3 Ethernet interface view.
interface interface-type interface-number
3. (Optional.) Assign the interface to a PTP instance and enter interface PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
4. Set a delay correction value.
ptp asymmetry-correction { minus | plus } value
The default is 0 nanoseconds. Delay correction is not performed.
Setting the cumulative offset between the UTC and TAI
About this task
An offset exists between Coordinated Universal Time (UTC) and International Atomic Time (TAI). The device displays the UTC time. However, PTP uses TAI for time synchronization. For the device to synchronize correct time to other clock nodes in the PTP domain when its local clock is selected as the GM, configure this task to correct the offset between UTC and TAI.
Procedure
1. Enter system view.
system-view
2. (Optional.) Enter PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
3. Set the cumulative offset between the UTC and TAI.
ptp utc offset utc-offset
The default is 0 seconds.
Setting the correction date of the UTC
About this task
This task allows you to adjust the UTC at the last minute (23:59) of the specified date.
Restrictions and guidelines
If you configure the setting multiple times, the most recent configuration takes effect.
This setting takes effect only when it is configured on the master clock node and when the local clock of the master clock node is the GM.
Procedure
1. Enter system view.
system-view
2. (Optional.) Enter PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
3. Set the correction date of the UTC.
ptp utc { leap59-date | leap61-date } date
By default, the correction date of the UTC is not configured.
Configuring a priority for a clock
About this task
Priorities for clocks are used to elect the GM. The smaller the priority value, the higher the priority.
Procedure
1. Enter system view.
system-view
2. (Optional.) Enter PTP instance view.
ptp instance ptp-instance-id
To configure settings for PTP instance 0, skip this step.
3. Configure the priority for the specified clock for GM election through BMC.
ptp priority clock-source local { priority1 priority1 | priority2 priority2 }
The priority 1 and priority 2 values are both 128.
Configuring the PTP time locking and unlocking thresholds
About this task
This task enables the system to output logs that indicate the time-locked or time-unlocked state.
· When the time offset of the PTP reference clock crosses the PTP time locking threshold, the PTP time is put into unlocked state. The system outputs a time-unlocked log for notification.
· When the time offset of the PTP reference clock drops to or below the PTP time locking threshold, the PTP time is put into locked state. The system outputs a time-locked log for notification.
Procedure
1. Enter system view.
system-view
2. Configure the PTP time locking and unlocking thresholds.
ptp alarm-threshold { time-lock lock-value | time-unlock unlock-value } *
By default, the PTP time locking threshold is 200 ns and the unlocking threshold is 300 ns.
Display and maintenance commands for PTP
Execute display commands in any view and the reset command in user view.
|
Task |
Command |
|
Display PTP clock information. |
display ptp clock [ all | instance ptp-instance-id ] |
|
Display the delay correction history. |
display ptp corrections [ all | instance ptp-instance-id ] |
|
Display information about foreign master nodes. |
display ptp foreign-masters-record [ interface interface-type interface-number ] [ all | instance ptp-instance-id ] |
|
Display PTP information for one or all PTP interfaces. |
display ptp interface [ interface-type interface-number | brief ] [ all | instance ptp-instance-id ] |
|
Display brief PTP information for all PTP interfaces. |
display ptp interface brief |
|
Display parent node information for the PTP device. |
display ptp parent [ all | instance ptp-instance-id ] |
|
Display historical role change information for PTP ports. |
display ptp port-history [ interface interface-type interface-number ] |
|
Display PTP statistics. |
display ptp statistics [ interface interface-type interface-number ] [ all | instance ptp-instance-id ] |
|
Display PTP clock time properties. |
display ptp time-property [ all | instance ptp-instance-id ] |
|
Clear PTP statistics. |
reset ptp statistics [ interface interface-type interface-number ] [ all | instance ptp-instance-id ] |
PTP configuration examples (IPv4 UDP transport, multicast transmission)
Network configuration
As shown in Figure 7, configure PTP to enable time synchronization between Device A and Device C:
· Specify the SMPTE ST 2059-2 PTP profile and multicast IPv4 UDP transport of PTP messages for Device A, Device B, and Device C.
· Specify the OC clock node type for Device A and Device C, and the BC clock node type for Device B. All clock nodes elect a GM through BMC.
· Use the peer delay measurement mechanism on all clock nodes in the PTP domain.
Procedure
|
|
IMPORTANT: The SMPTE ST 2059-2 PTP profile transports PTP messages over IPv4 UDP rather than IEEE 802.3/Ethernet. The profile supports both multicast and unicast transmission modes. |
1. Configure Device A:
# Specify the SMPTE ST 2059-2 PTP profile.
<DeviceA> system-view
[DeviceA] ptp profile st2059-2
# Specify the OC clock node type.
[DeviceA] ptp mode oc
# Create a PTP domain.
[DeviceA] ptp domain 0
# Enable PTP globally.
[DeviceA] ptp global enable
# Configure the source IP address for multicast PTP message transmission over IPv4 UDP.
[DeviceA] ptp source 10.10.1.1
# Specify PTP for obtaining the time.
[DeviceA] clock protocol ptp
# Enable PTP on Twenty-FiveGigE 1/0/1.
[DeviceA] interface twenty-fivegige 1/0/1
[DeviceA-Twenty-FiveGigE1/0/1] ptp enable
# Set the interval for sending announce messages on Twenty-FiveGigE 1/0/1.
[DeviceA-Twenty-FiveGigE1/0/1] ptp announce-interval 0
# Set the interval for sending Sync messages on Twenty-FiveGigE 1/0/1.
[DeviceA-Twenty-FiveGigE1/0/1] ptp syn-interval -1
# Set the minimum interval for sending delay request messages on Twenty-FiveGigE 1/0/1.
[DeviceA-Twenty-FiveGigE1/0/1] ptp min-delayreq-interval -1
[DeviceA-Twenty-FiveGigE1/0/1] quit
2. Configure Device B:
# Specify the SMPTE ST 2059-2 PTP profile.
<DeviceB> system-view
[DeviceB] ptp profile st2059-2
# Specify the BC clock node type.
[DeviceB] ptp mode bc
# Create a PTP domain.
[DeviceB] ptp domain 0
# Enable PTP globally.
[DeviceB] ptp global enable
# Configure the source IP address for multicast PTP message transmission over IPv4 UDP.
[DeviceB] ptp source 10.10.10.2
# Specify PTP for obtaining the time.
[DeviceB] clock protocol ptp
# On Twenty-FiveGigE 1/0/1, enable PTP.
[DeviceB] interface twenty-fivegige 1/0/1
[DeviceB-Twenty-FiveGigE1/0/1] ptp enable
# Set the interval for sending announce messages on Twenty-FiveGigE 1/0/1.
[DeviceB-Twenty-FiveGigE1/0/1] ptp announce-interval 0
# Set the interval for sending Sync messages on Twenty-FiveGigE 1/0/1.
[DeviceB-Twenty-FiveGigE1/0/1] ptp syn-interval -1
# Set the minimum interval for sending delay request messages on Twenty-FiveGigE 1/0/1.
[DeviceB-Twenty-FiveGigE1/0/1] ptp min-delayreq-interval -1
[DeviceB-Twenty-FiveGigE1/0/1] quit
# On Twenty-FiveGigE 1/0/2, enable PTP.
[DeviceB] interface twenty-fivegige 1/0/2
[DeviceB-Twenty-FiveGigE1/0/2] ptp enable
# Set the interval for sending announce messages on Twenty-FiveGigE 1/0/2.
[DeviceB-Twenty-FiveGigE1/0/2] ptp announce-interval 0
# Set the interval for sending Sync messages on Twenty-FiveGigE 1/0/2.
[DeviceB-Twenty-FiveGigE1/0/2] ptp syn-interval -1
# Set the minimum interval for sending delay request messages on Twenty-FiveGigE 1/0/2.
[DeviceB-Twenty-FiveGigE1/0/2] ptp min-delayreq-interval -1
[DeviceB-Twenty-FiveGigE1/0/2] quit
3. Configure Device C:
# Specify the SMPTE ST 2059-2 PTP profile.
<DeviceC> system-view
[DeviceC] ptp profile st2059-2
# Specify the OC clock node type.
[DeviceC] ptp mode oc
# Create a PTP domain.
[DeviceC] ptp domain 0
# Enable PTP globally.
[DeviceC] ptp global enable
# Configure the source IP address for multicast PTP message transmission over IPv4 UDP.
[DeviceC] ptp source 11.10.10.1
# Specify PTP for obtaining the time.
[DeviceC] clock protocol ptp
# On Twenty-FiveGigE 1/0/1, enable PTP.
[DeviceC] interface twenty-fivegige 1/0/1
[DeviceC-Twenty-FiveGigE1/0/1] ptp enable
# Set the interval for sending announce messages on Twenty-FiveGigE 1/0/1.
[DeviceC-Twenty-FiveGigE1/0/1] ptp announce-interval 0
# Set the interval for sending Sync messages on Twenty-FiveGigE 1/0/1.
[DeviceC-Twenty-FiveGigE1/0/1] ptp syn-interval -1
# Set the minimum interval for sending delay request messages on Twenty-FiveGigE 1/0/1.
[DeviceC-Twenty-FiveGigE1/0/1] ptp min-delayreq-interval -1
[DeviceC-Twenty-FiveGigE1/0/1] quit
Verifying the configuration
When the network is stable, perform the following tasks to verify the PTP configuration:
· Use the display ptp clock command to display PTP clock information.
· Use the display ptp interface brief command to display brief PTP running information for all PTP interfaces.
# Display PTP clock information on Device A.
[DeviceA] display ptp clock
PTP global state : Enabled
PTP profile : SMPTE ST 2059-2
PTP mode : OC
Slave only : No
Lock status : Unlocked
Clock ID : 000FE2-FFFE-FF0000
Clock type : Local
Clock domain : 0
Number of PTP ports : 1
Priority1 : 128
Priority2 : 128
Clock quality :
Class : 248
Accuracy : 254
Offset (log variance) : 65535
Offset from master : 0 (ns)
Mean path delay : 0 (ns)
Steps removed : 0
Local clock time : Sun Jan 15 20:57:29 2019
# Display brief PTP running information for all PTP interfaces on Device A.
[DeviceA] display ptp interface brief
Name InstID State Delay mechanism Clock step Asymmetry correction
WGE1/0/1 0 Master E2E Two 0
# Display PTP clock information on Device B.
[DeviceB] display ptp clock
PTP global state : Enabled
PTP profile : SMPTE ST 2059-2
PTP mode : BC
Slave only : No
Lock status : Locked
Clock ID : 000FE2-FFFE-FF0001
Clock type : Local
Clock domain : 0
Number of PTP ports : 2
Priority1 : 128
Priority2 : 128
Clock quality :
Class : 248
Accuracy : 254
Offset (log variance) : 65535
Offset from master : 25 (ns)
Mean path delay : 2791000 (ns)
Steps removed : 1
Local clock time : Sun Jan 15 20:57:29 2019
# Display brief PTP running information for all PTP interfaces on Device B.
[DeviceB] display ptp interface brief
Name InstID State Delay mechanism Clock step Asymmetry correction
WGE1/0/1 0 Slave E2E Two 0
WGE1/0/2 0 Master E2E Two 0
The output shows that Device A is elected as the GM and Twenty-FiveGigE1/0/1 on Device A is the master port.
