Configuration Condition
Before configuring the RTR entity, first complete the following task:
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.