Status in source: current.
Technical details
{
"smi_kind": "OBJECT-TYPE",
"definition": [
"tmnxPtpPeerConfigEntry",
"OBJECT-TYPE",
"SYNTAX",
"TmnxPtpPeerConfigEntry",
"MAX-ACCESS",
"not-accessible",
"STATUS",
"current",
"DESCRIPTION",
"\"The tmnxPtpPeerConfigEntry contains information pertaining to an individual PTP 1588 peer. Individual PTP peers are identified by the virtual router identifier and IP address of the peer PTP clock. Entries may be created on the base router. In order for an entry to be created on a virtual router, there must be a corresponding entry in the tmnxPtpVRtrTable for the virtual router instance. If tmnxPtpClockClockType is 'ordinarySlave (1)', entries may be created and deleted via SNMP set operations using tmnxPtpPeerRowStatus. The tmnxPtpPeerRemoteMaster attribute will be created with a value of 'true', and the tmnxPtpPeerRemoteSlave attribute will be created with a value of 'false'. Neither or these attributes may be subsequently changed. These entries correspond to PTP grandmaster or boundary clocks providing timing information to the local clock. In order to delete an entry, tmnxPtpPeerAdminState must first be set to 'outOfService (3)'. Entries created via SNMP set operations may only be created on a single virtual router instance. If tmnxPtpClockClockType is 'ordinaryMaster (2)', entries are automatically created upon receipt of PTP signaling packets requesting unicast transmission of PTP packets. Entries cannot be created or deleted via SNMP set operations. These entries correspond to PTP slave boundary clocks receiving timing information from the local clock. These entries are created by the system with tmnxPtpPeerRemoteMaster set to 'false' and tmnxPtpPeerRemoteSlave set to 'true'. If tmnxPtpClockClockType is 'boundary (3)', entries corresponding to grandmaster or boundary PTP clocks providing timing to the local clock may be created and deleted via SNMP set operations, in the same manner as when tmnxPtpClockClockType is 'ordinarySlave (1)'. As well, entries corresponding to slave or boundary PTP clocks receiving timing from the local clock may be automatically created by the system, in the same manner as when tmnxPtpClockClockType is 'ordinaryMaster (2)'. For an individual entry, the value of tmnxPtpPeerRemoteMaster along with tmnxPtpPeerRemoteSlave indicates the direction of flow of timing information between the local PTP clock and the peer PTP clock. There are three cases: 1) If tmnxPtpPeerRemoteMaster is 'true', and tmnxPtpPeerRemoteSlave is 'false', the peer PTP clock is providing timing to the local PTP clock. In this case, PTP Announce, Sync, and Delay Response packets are sent from the peer PTP clock to the local PTP clock, and PTP Delay Request packets are sent from the local PTP clock to the peer PTP clock. This type of PTP peer may exist when tmnxPtpClockClockType is either 'ordinarySlave (1)' or boundary (3)'. 2) If tmnxPtpPeerRemoteMaster is 'false', and tmnxPtpPeerRemoteSlave is 'true', the local PTP clock is providing timing to the peer PTP clock. In this case, PTP Announce, Sync, and Delay Response packets are sent from the local PTP clock to the peer PTP clock, and PTP Delay Request packets are sent from the peer PTP clock to the local PTP clock. This type of PTP peer may exist when tmnxPtpClockClockType is either 'ordinaryMaster (2)' or boundary (3)'. 3) If tmnxPtpPeerRemoteMaster and tmnxPtpPeerRemoteSlave are both set to 'true', the local clock and remote PTP clock have a peer relationship. Timing information may flow in either direction, depending on the decision of the PTP Best Master Clock Algorithm running on each PTP clock. This type of PTP peer may only exist when tmnxPtpClockClockType is 'boundary (3)'. There is a system limit to the number of PTP peers that can be configured via SNMP set operations, and another limit to the number of PTP peers that can be automatically created upon reception of PTP signaling packets. When tmnxPtpClockClockType is 'boundary (3)', a peer entry may be changed from one that is only receiving timing from the local clock, to one that may either receive or provide timing, by setting tmnxPtpPeerRemoteMaster to 'true'.\"",
"INDEX",
"{",
"vRtrID",
",",
"tmnxPtpPeerIpAddrType",
",",
"tmnxPtpPeerIpAddress",
"}",
"::=",
"{",
"tmnxPtpPeerConfigTable",
"1",
"}"
],
"syntax_tree": [
[
"row",
"TmnxPtpPeerConfigEntry"
],
null,
[
"MaxAccessPart",
"not-accessible"
],
[
"Status",
"current"
],
[
"DESCRIPTION",
"The tmnxPtpPeerConfigEntry contains information pertaining to an individual PTP 1588 peer. Individual PTP peers are identified by the virtual router identifier and IP address of the peer PTP clock. Entries may be created on the base router. In order for an entry to be created on a virtual router, there must be a corresponding entry in the tmnxPtpVRtrTable for the virtual router instance. If tmnxPtpClockClockType is 'ordinarySlave (1)', entries may be created and deleted via SNMP set operations using tmnxPtpPeerRowStatus. The tmnxPtpPeerRemoteMaster attribute will be created with a value of 'true', and the tmnxPtpPeerRemoteSlave attribute will be created with a value of 'false'. Neither or these attributes may be subsequently changed. These entries correspond to PTP grandmaster or boundary clocks providing timing information to the local clock. In order to delete an entry, tmnxPtpPeerAdminState must first be set to 'outOfService (3)'. Entries created via SNMP set operations may only be created on a single virtual router instance. If tmnxPtpClockClockType is 'ordinaryMaster (2)', entries are automatically created upon receipt of PTP signaling packets requesting unicast transmission of PTP packets. Entries cannot be created or deleted via SNMP set operations. These entries correspond to PTP slave boundary clocks receiving timing information from the local clock. These entries are created by the system with tmnxPtpPeerRemoteMaster set to 'false' and tmnxPtpPeerRemoteSlave set to 'true'. If tmnxPtpClockClockType is 'boundary (3)', entries corresponding to grandmaster or boundary PTP clocks providing timing to the local clock may be created and deleted via SNMP set operations, in the same manner as when tmnxPtpClockClockType is 'ordinarySlave (1)'. As well, entries corresponding to slave or boundary PTP clocks receiving timing from the local clock may be automatically created by the system, in the same manner as when tmnxPtpClockClockType is 'ordinaryMaster (2)'. For an individual entry, the value of tmnxPtpPeerRemoteMaster along with tmnxPtpPeerRemoteSlave indicates the direction of flow of timing information between the local PTP clock and the peer PTP clock. There are three cases: 1) If tmnxPtpPeerRemoteMaster is 'true', and tmnxPtpPeerRemoteSlave is 'false', the peer PTP clock is providing timing to the local PTP clock. In this case, PTP Announce, Sync, and Delay Response packets are sent from the peer PTP clock to the local PTP clock, and PTP Delay Request packets are sent from the local PTP clock to the peer PTP clock. This type of PTP peer may exist when tmnxPtpClockClockType is either 'ordinarySlave (1)' or boundary (3)'. 2) If tmnxPtpPeerRemoteMaster is 'false', and tmnxPtpPeerRemoteSlave is 'true', the local PTP clock is providing timing to the peer PTP clock. In this case, PTP Announce, Sync, and Delay Response packets are sent from the local PTP clock to the peer PTP clock, and PTP Delay Request packets are sent from the peer PTP clock to the local PTP clock. This type of PTP peer may exist when tmnxPtpClockClockType is either 'ordinaryMaster (2)' or boundary (3)'. 3) If tmnxPtpPeerRemoteMaster and tmnxPtpPeerRemoteSlave are both set to 'true', the local clock and remote PTP clock have a peer relationship. Timing information may flow in either direction, depending on the decision of the PTP Best Master Clock Algorithm running on each PTP clock. This type of PTP peer may only exist when tmnxPtpClockClockType is 'boundary (3)'. There is a system limit to the number of PTP peers that can be configured via SNMP set operations, and another limit to the number of PTP peers that can be automatically created upon reception of PTP signaling packets. When tmnxPtpClockClockType is 'boundary (3)', a peer entry may be changed from one that is only receiving timing from the local clock, to one that may either receive or provide timing, by setting tmnxPtpPeerRemoteMaster to 'true'."
],
null,
null,
[
"INDEX",
[
[
0,
"vRtrID"
],
[
0,
"tmnxPtpPeerIpAddrType"
],
[
0,
"tmnxPtpPeerIpAddress"
]
]
],
null
]
}