Functionality Verification and Troubleshooting

https//www.racom.eu/eng/products/m/ripex/app/qos/verif.html

Print version

2. Functionality Verification and Troubleshooting

Monitoring does not display the QoS queues usage in its output. Neither does the Statistics menu show any information regarding any particular priority queue.

The only way to check the actual QoS functionality is via CLI.

NOTE:
CLI interface (Command Line Interface) is an alternative to web access. You can work with the CLI interface in text mode using an appropriate client, either SSH (putty) or Telnet.

Once logged in to the CLI environment, “cli_tcpdump“ with “-v” parameter can be used to see the DS (TOS) field. Each QoS rule in RipEX can also be configured to filter based on this field in IP packet.

In this example, only two commands are helpful for troubleshooting.

  • tc -s qdisc show dev radio

This command displays the QoS queues with statistics. Example:

CLI(admin):~$ tc -s qdisc show dev radio
qdisc prio 1: bands 9 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 2714 bytes 57 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 10: parent 1:1 limit 3p quantum 1514b perturb 10sec
 Sent 1344 bytes 32 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 20: parent 1:2 limit 5p quantum 1514b perturb 10sec
 Sent 1296 bytes 24 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 30: parent 1:3 limit 5p quantum 1514b perturb 10sec
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 40: parent 1:4 limit 5p quantum 1514b perturb 10sec
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 50: parent 1:5 limit 5p quantum 1514b perturb 10sec
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 60: parent 1:6 limit 5p quantum 1514b perturb 10sec
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 70: parent 1:7 limit 5p quantum 1514b perturb 10sec
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 80: parent 1:8 limit 5p quantum 1514b perturb 10sec
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 90: parent 1:9 limit 5p quantum 1514b perturb 10sec
 Sent 74 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
CLI(admin):~$ tc -s qdisc show dev radio | grep -A1 "sfq 20" qdisc sfq 20: parent 1:2 limit 5p quantum 1514b perturb 10sec Sent 1296 bytes 24 pkt (dropped 0, overlimits 0 requeues 0)

The first paragraph starting with “qdisc prio” represents these queues as a whole. Its statistics output displays the total packets sent and dropped in QoS system.

Paragraphs starting by “qdisc sfq” represent particular priority queues (each priority level is assigned to separate queue) and their statistics output.

The queue for ARP packets is “qdisc sfq 10” and has the highest possible priority (this level is not configurable, neither is it displayed in the web interface, for simplicity). The other queues representing priorities 1-8 are listed in paragraphs labeled from “qdisc sfq 20” to “qdisc sfq 90”.

The priority for our Modbus data example (UDP, 8881/8902) are displayed in “qdisc sfq 20” paragraph. Other traffic has the default (lowest) priority 8 and is displayed in paragraph “qdisc sfq 90”.

  • tc -s filter show dev radio

The second command displays the rules for placing packets to priority queues and their statistics. Example:

CLI(admin):~tc -s filter show dev radio
filter parent 1: protocol arp pref 1 u32
filter parent 1: protocol arp pref 1 u32 fh 800: ht divisor 1
filter parent 1: protocol arp pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1  (rule hit 33 success 33)
  match 00000000/00000000 at 0 (success 33 )
filter parent 1: protocol ip pref 2 u32
filter parent 1: protocol ip pref 2 u32 fh 1: ht divisor 1
filter parent 1: protocol ip pref 2 u32 fh 1::800 order 2048 key ht 1 bkt 0 flowid 1:2  (rule hit 24 success 24)
  match 22c622b1/ffffffff at nexthdr+0 (success 24 )
filter parent 1: protocol ip pref 2 u32 fh 801: ht divisor 1
filter parent 1: protocol ip pref 2 u32 fh 801::800 order 2048 key ht 801 bkt 0 link 1:  (rule hit 25 success 0)
  match 00110000/00ff0000 at 8 (success 24 )
  match 00000000/00001fff at 4 (success 24 )
    offset 0f00>>6 at 0  eat
filter parent 1: protocol all pref 3 u32
filter parent 1: protocol all pref 3 u32 fh 802: ht divisor 1
filter parent 1: protocol all pref 3 u32 fh 802::800 order 2048 key ht 802 bkt 0 flowid 1:9  (rule hit 1 success 1)
  match 00000000/00000000 at 0 (success 1 )

Output code starting with “filter parent 1: protocol arp” is the internal priority 0 (flowid 1:1 – corresponds to “sfq 10” in previous command) – used only for ARP, having the highest priority.

Output code starting with “filter parent 1: protocol all” is the table with the lowest priority 8 (flowid 1:9 – corresponds to “sfq 90” in previous command). In this example, this is the default priority.

Output code starting with “filter parent 1: protocol ip” are the user rules. In our example, the flowid is 1:2 (i.e. the highest user priority possible, corresponding to “sfq 20” in previous command).

If you need any further explanation and debugging help, contact our Technical support group at .

NOTE:
The QoS state is stored in Technical support package.

©  2024 RACOM s.r.o. All Rights Reserved.