Configure RTR Entity

Configuration Condition

Before configuring the RTR entity, first complete the following task:

Enable RTR.

Create RTR Entity

One entity corresponds to one type of detection. After creating the RTR entity and entering the entity configuration mode, we can configure the parameters of the entity.

Table 3-3 Create the RTR entity

Step	Command	Description
Enter the global configuration mode	configure terminal	-
Create the RTR entity	rtr entity-id entity-type	Mandatory

Configure ICMP-echo Entity

The ICMP-echo entity is to detect the network communication. It regularly sends the ICMP echo request packet to one destination address in the network, so as to get the delay and packet loss of the packet transmission from the detection end to the destination end. In one detection period, as long as the ICMP-echo entity receives one ICMP echo request response packet, the entity status is reachable.

The general network devices all support ping, so the entity can take effect in detecting the network communication. With the rich scheduling policies and log recording function, we can let the network administrator get to know the network communication status and history information in time and reduce inputting the common ping command frequently at the same time.

Table 3-4 Configure the ICMP-echo entity

Step	Command	Description
Enter the global configuration mode	configure terminal	-
Enter the ICMP- echo entity configuration mode	rtr entity-id [ icmpecho ]	Mandatory
Configure the detection attribute	set [ vrf vrf-name ] target-ip-address [ npacket ] [ data-size ] [ timeout ] [ frequency-value ] [ extend source-ip- address [ tos ] [ set-DF ] [ verify-data ] ]	Mandatory By default, do not configure the detection attribute of the entity.
Configure RTT value as the judgment basis to detect whether the entity is reachable	status-care rtt	Optional By default, RTT value is not used to determine whether it is reachable.
Configure the common configuration of the entity	Refer to “Configure Common Configuration of the Entity”	Optional

The scheduling interval (frequency-value) of the ICMP-echo entity needs to meet the following requirement: scheduling interval > npacket * timeout
If configuring the scheduler for the entity, the age time of the scheduler should be larger than the scheduling interval of the entity.

Configure ICMPV6-echo Entity

The function of ICMPv6 echo entity is to detect the basic network communication. It regularly sends ICMP echo request packet to a destination address in the network, so as to get the delay and packet loss of packet transmission from detection end to destination. In a detection cycle, as long as an ICMP echo request response packet is received by an ICMP V6 echo entity, the status of the entity is reachable.

Because the general network devices support ping, this entity can play a role in detecting the basic communication of the network. Through abundant scheduling polities and logging functions, network administrators can know the network communication situation and historical information in time, and reduce the tedious input of the common ping command.

Table 3-5 Configure the ICMPV6-echo entity

Step	Command	Description
Enter the global configuration mode	configure terminal	-
Enter the ICMP- echo entity configuration mode	rtr entity-id [ icmpv6echo ]	-
Configure the detection attributes	set [ vrf vrf-name ] target-ip-address [ npacket ] [ data-size ] [ timeout ] [ frequency-value ] [ extend source-ip- address [ tos ] [ verify-data ] ]	Mandatory By default, do not configure the detection attribute of the entity.
Configure RTT value as the judgment basis to detect whether the entity is reachable	status-care rtt	Optional By default, RTT value is not used to determine whether it is reachable.
Configure the common configuration of the entity	Refer to “Configure Common Configuration of the Entity”	Optional

The scheduling interval (frequency-value) of the ICMPv6-echo entity needs to meet the following requirement: scheduling interval > npacket * timeout
If configuring the scheduler for the entity, the age time of the scheduler should be larger than the scheduling interval of the entity.

Configure ICMP-path-echo Entity

The ICMP-path-echo entity is to detect the network communication. It regularly sends the ICMP echo request packet to one destination address in the network, so as to get the delay and packet loss of the packet transmission from the detection end to the destination end, as well as the delay and packet loss between the detection end and the intermediate devices from the detection end to the destination. In one detection period, as long as the ICMP-path-echo entity receives one ICMP echo request response packet, the entity status is reachable.

The general network devices all support ping, so the entity can take effect in detecting the network communication. With the rich scheduling policies and log recording function, we can let the network administrator get to know the network communication status (for example, which network device on the path has serious delay) and history information in time.

Table 3-6 Configure the ICMP-path-echo entity

Step	Command	Description
Enter the system configuration mode	configure terminal	-
Enter the ICMP- path-echo entity configuration mode	rtr entity-id [ icmp-path-echo ]	Mandatory
Configure the detection attribute	set dest-ipaddr target-ip-address [ source-ipaddr source-ip-address ]	Mandatory
Configure the loose source route selection	lsr-path [ hop-ip-address-list \| none ]	Optional By default, do not configure the loose source route selection.
Configure only detecting the network status from the source to the destination	targetOnly [ true \| false ]	Optional By default, if targetOnly is true, only detect the network status from the source to the destination. If targetOnly is false, detect the network status from the source to the destination hop by hop.
Configure whether to verify the content of the response packet	verify-data [ true \| false ]	Optional By default, do not verify the data content.
Configure the common configuration of the entity	Refer to “Configure Common Configuration of the Entity”	Optional

Configure ICMP-path-jitter Entity

The ICMP-path-jitter entity is to detect the network communication. It regularly sends the ICMP echo request packet to one destination address in the network, so as to get the delay, jitter, and packet loss of the packet transmission from the detection end to the destination end, as well as the delay, jitter and packet loss between the detection end and the intermediate devices from the detection end to the destination. In one detection period, as long as the ICMP-path-jitter entity receives one ICMP echo request response packet, the entity status is reachable.

The general network devices all support ping, so the entity can take effect in detecting the network communication. With the rich scheduling policies and log recording function, we can let the network administrator get to know the network communication status (for example, which network device on the path has serious delay) and history information in time.

Table 3-7 Configure the ICMP-path-jitter entity

Step	Command	Description
Enter the system configuration mode	configure terminal	-
Enter the ICMP- path-jitter configuration mode	rtr entity-id [ icmp-path-jitter ]	Mandatory
Configure the detection attribute	set dest-ipaddr target-ip-address [ pkt-number ] [ pkt-interval ] [ source-ipaddr source-ip-address ]	Mandatory
Configure the IP address of the loose source route selection	lsr-path [ hop-ip-address-list \| none ]	Optional By default, do not configure the loose source route selection.
Configure only detecting the network status from the source to the destination	targetOnly [ true \| false ]	Optional By default, if targetOnly is true, only detect the network status from the source to the destination. If targetOnly is false, detect the network status from the source to the destination hop by hop.
Configure the jitter threshold and over- limit rule	threshold-jitter jitter direction { be \| se }	Optional By default, the jitter threshold is 6000ms and the over-limit rule is be.
Configure whether to verify the content of the response packet	verify-data [ true \| false ]	Optional By default, do not verify the data content.
Configure the common configuration of the entity	Refer to “Configure Common Configuration of the Entity”	Optional

When the over-limit rule is be and the actual value is larger than or equal to the threshold, it judged as over-limit; when the over-limit rule is se and the actual value is smaller than or equal to the threshold, it is judged as over-limit.

Configure VoIP-jitter Entity

The VoIP-jitter entity is the RTR entity used to measure the transmission quality of the VoIP packet in the general IP network.

The VoIP-jitter entity can simulate the G.711 A Law, G.711 mu Law, and G.729A codec or the customized codes to send the UDP packet with the corresponding rate, packet interval and size from the source device to the destination device, measure the turnaround time, uni-directional packet loss and uni-directional delay of the packet, and calculates the ICPIF value based on the statistics information. At last, estimate the MOS value according to the ICPIF value. In the detection period, as long as the VoIP-jitter entity receives one detection response packet, the status of the entity is reachable.

Table 3-8 Configure the VoIP-jitter entity

Step	Command	Description
Enter the system configuration mode	configure terminal	-
Enter the VoIP- jitter configuration mode	rtr entity-id [ jitter ]	Mandatory If the entity already exists, directly enter the entity configuration mode.
Configure the detection attribute	set dest-ipaddr target-ip-address dest-port target-port { g711alaw \| g711ulaw \| g729a \| user_defined packet-size packet-number packet- interval schedule-interval } [ source- ipaddr source-ip-address ] [ source- port source-port ]	Mandatory
Configure the uni- directional delay threshold from the source to the destination and over-limit rule	threshold-sd-delay sd-delay direction { be \| se }	Optional By default, the sd delay threshold is 5000ms and the over-limit rule is be.
Configure the uni- directional jitter threshold from the source to the destination and over-limit rule	threshold-sd-jitter sd-jitter direction { be \| se }	Optional By default, the sd jitter threshold is 6000ms and the over-limit rule is be.
Configure the packet loss threshold and over- limit rule from the source to the destination	threshold-sd-pktloss sd-packet direction { be \| se }	Optional By default, the sd packet loss threshold is 60000 and the over-limit rule is be.
Configure the uni- directional delay threshold from the destination to the source and over- limit rule	threshold-ds-delay ds-delay direction { be \| se }	Optional By default, the ds delay threshold is 5000ms and the over-limit rule is be.
Configure the uni- directional jitter threshold from the destination to the source and over- limit rule	threshold-ds-jitter ds-jitter direction { be \| se }	Optional By default, the ds unit- directional jitter threshold is 6000ms and the over-limit rule is be.
Configure the packet loss threshold from the destination to the source and over- limit rule	threshold-ds-pktloss ds-packet direction { be \| se }	Optional By default, the ds packet loss threshold is 60000 and the over-limit rule is be.
Configure the icpif threshold and the over-limit rule	threshold-icpif icpif-value direction { be \| se }	Optional By default, the icpif threshold is 100000000 and the over- limit rule is be.
Configure the mos threshold and the over-limit rule	threshold-mos mos-value direction { be \| se }	Optional By default, the mos threshold is 10000000 and the over- limit rule is be.
Configure the common configuration of the entity	Refer to “Configure Common Configuration of the Entity”	Optional

When using the VoIP-jitter entity detection, besides configuring the VoIP-jitter entity, we also need to configure the RTR responder at the destination.
By default, the VoIP-jitter entity sends many packets, which occupy the network bandwidth, so when configuring the entity exceeds one hour, the shell prompts.
When the VoIP-jitter entity detects the network transmitting the VoIP packet, the clocks of the source and the destination need to be consistent, so before scheduling the VoIP-jitter entity, we also need to configure the NTP server at the destination and NTP client at the source. After the clocks are synchronized, configure the RTR responder, and at last, configure the scheduler. For the configuration of NTP, refer to NTP Configuration Manual.
When the over-limit rule is be and the actual value is larger than or equal to the threshold, it judged as over-limit; when the over-limit rule is se and the actual value is smaller than or equal to the threshold, it is judged as over-limit.

Configure UDP-echo Entity

The UDP-echo entity mainly detects the UDP packet transmitted in the IP network. In the entity, we need to specify the destination address and port of the sent packet. We can monitor the transmission of the UDP packet in the IP network by scheduling the entity. In one detection period, as long as the UDP-echo entity receives one detection response packet, the entity status is reachable.

The UDP-echo entity can monitor efficiently to record the turnaround delay, packet loss and other information of the UDP packet in the IP network, even record the monitored history information by logs so that the network administrator can get to know the network communication and fix the fault.

Table 3-9 Configure the UDP-echo entity

Step	Command	Description
Enter the system configuration mode	configure terminal	-
Enter the UDP-echo entity configuration mode	rtr entity-id [ udpecho ]	Mandatory If the entity already exists, directly enter the entity configuration mode.
Configure the detection attribute	set dest-ipaddr target-ip-address dest-port target-port [ source-ipaddr source-ip-address ] [ source-port source-port ]	Mandatory By default, do not configure the detection attribute.
Configure the filling content of the packet	data-pattern pad	Optional By default, the filling content is “ABCD”.
Configure the common configuration of the entity	Refer to “Configure Common Configuration of the Entity”	Optional

When using the UDP-echo entity detection, besides configuring the UDP-echo entity, we also need to configure the RTR responder at the destination.

Configure FLOW-statistics Entity

The FLOW-statistics entity is to detect the interface traffic and one entity corresponds to one interface. We can monitor the traffic on the interface by scheduling the entity. In one detection period, as long as there are packets passing the interface monitored by the FLOW-statistics entity, the entity status is reachable.

The interval of the FLOW-statistics entity monitoring the interface traffic is 10s-10min. We can record the traffic peak value information on the interface by monitoring, even can record the history information of the traffic statistics during each monitoring, so as to make the network administrator get to know the network communication status and fix the fault.

Table 3-10 Configure the FLOW-statistics entity

Step	Command	Description
Enter the system configuration mode	configure terminal	-
Enter the FLOW- statistics entity configuration mode	rtr entity-id [ flow-statistics ]	Mandatory If the entity already exists, directly enter the entity configuration mode.
Configure the detection attribute	flow-statistics interface interface- name interval interval	Mandatory
Configure the traffic threshold received by the interface and the over-limit rule	threshold-inflow flow-value direction { be \| se }	Optional By default, the traffic threshold received by the interface is 200000000bps (bit/s) and the over-limit rule is be.
Configure the threshold of the packets received by the interface and the over-limit rule	threshold-inpacket packet-value direction { be \| se }	Optional By default, the threshold of the packets received by the interface is 200000000 and the over-limit rule is be.
Configure the threshold of the traffic received by the interface and the over-limit rule	threshold-outflow flow-value direction { be \| se }	Optional By default, the traffic threshold sent by the interface is 200000000 bps (bit/s) and the over-limit rule is be.
Configure the threshold of the packets received by the interface and over-limit rule	threshold-outpacket packet-value direction { be \| se }	Optional By default, the threshold of the packets received by the interface is 200000000 and the over-limit rule is be.
Configure the common configuration of the entity	Refer to “Configure Common Configuration of the Entity”	Optional

When the over-limit rule is be and the actual value is larger than or equal to the threshold, it judged as over-limit; when the over-limit rule is se and the actual value is smaller than or equal to the threshold, it is judged as over-limit.

Configure Common Configuration of Entities

Table 3-11 Configure the common configuration of the entities

Step	Command	Description
Configure the alarm type	alarm-type [ log \| log-and- trap \| trap \| none ]	Optional By default, the alarm mode is none, that is, do not alarm.
Configure the number of the saved history records	number-of-history-kept history-number	Optional By default, save one history record.
Configure the period of saving the history records	periods periods	Optional By default, after each scheduling ends, save one history record.
Configure the timeout	timeout timeout	Optional By default, the timeout is: ICMP-path-echo entity 5000ms ICMP-path-jitter entity 5000ms VoIP-jitter entity 50000ms UDP-echo entity 5000ms The entity not supporting the command: ICMP-echo entity ICMPv6-echo entity FLOW-statistics entity
Configure the TOS value of the packet	tos tos-value	Optional By default, the TOS value is 0. The entity not supporting the command: ICMP-echo entity ICMPv6-echo entity
Configure the VRF attribute of the entity	vrf vrf-name	Optional By default, do not configure the VRF attribute of the entity. The entities not supporting the command: ICMP-echo entity ICMPv6-echo entity FLOW-statistics entity
Configure the scheduling interval of the entity	frequency seconds	Optional By default, the scheduling interval is: ICMP-path-echo entity 60s ICMP-path-jitter entity 60s UDP-echo entity 60s The entities not supporting the command: ICMP-echo entity ICMPv6-echo entity VoIP-jitter entity FLOW-statistics entity
Configure the length of the detection packet	request-data-size data-size	Optional By default, the length of the detection packet: ICMP-path-echo entity 70 bytes ICMP-path-jitter entity 70 bytes UDP-echo entity 16 bytes The entities not supporting the command: ICMP-echo entity ICMPv6-echo entity VoIP-jitter entity FLOW-statistics entity
Configure the packet loss threshold and the over-limit rule	threshold-pktloss pktloss direction { be \| se }	Optional By default, the packet loss threshold: ICMP-echo entity 150 ICMPv6-echo entity 150 ICMP-path-echo entity 1 ICMP-path-jitter entity 100 UDP-echo entity 1 The over-limit rule is be. The entities not supporting the command: VoIP-jitter entity FLOW-statistics entity
Configure the bi- directional delay threshold and the over-limit rule	threshold-rtt rtt direction { be \| se }	Optional By default, the bi-directional delay threshold is: ICMP-echo entity 9000ms ICMPv6-echo entity 9000ms ICMP-path-echo entity 9000ms ICMP-path-jitter entity 9000ms VoIP-jitter entity 9000ms UDP-echo entity 9000ms The over-limit rule is be. The entities not supporting the command: FLOW-statistics entity

If the RTR entity already exists and the entity is in the un-scheduled state, execute the rtr entity-id command to enter the entity configuration mode directly.
When the over-limit rule is be and the actual value is larger than or equal to the threshold, it judged as over-limit; when the over-limit rule is se and the actual value is smaller than or equal to the threshold, it is judged as over-limit.

The scheduling interval of the ICMP-path-echo entity needs to meet the following requirement: scheduling interval > timeout.
The scheduling interval of the ICMP-path-jitter entity needs to meet the following requirement: scheduling interval > timeout; timeout needs to meet the following requirement: timeout > pkt-number * pkt-interval; For the pkt-number parameter and the pkt-interval parameter, refer to the set command of the ICMP-path-echo entity.
When the scheduling interval of the VoIP-jitter entity selects simulating G.711ALaw, G.711muLaw, and G.729A codec, it is necessary to meet the following requirement: scheduling interval > timeout + 5; when selecting the customized codec, it is necessary to meet the following requirement: scheduling interval > schedule-interval + 5; schedule-interval needs to meet the following requirement: schedule-interval > packet-number * packet-interval; for the schedule-interval, packet-number and packet-interval parameters, refer to the set command of the VoIP-jitter entity.
The scheduling interval of the UDP-echo entity needs to meet the following requirement: scheduling interval > timeout + 5.