OpenWrt Forum Archive

Topic: OpenWrt Chaos Calmer 15.05 and DSCP / QOS

The content of this topic has been archived on 26 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Can someone answer this please.

I have a Cisco 2851 IOS Router and its my VoIP Phone system (CUCME), has a dedicated Phone lan etc and is flagging packets on my 'VoIP' lan for EF (expedited forwarding through my OpenWrt Wan router.

Been testing for packet loss by using WinSCP to ftp large'ish (36Mb) file up to my ISP ftp server for my account. Doing this I see my UP Link go 'flat out' ie max speed of my uplink is (about)934Kbps reported by my modem.

When doing this upload I would have expected pack loss when trying to make SIP VoIP calls from with in my network. I expected to hear 'stutted' speech outbound from my network.

But this does not occur, in several tests the voice call quality is great, perfect even (well I cant, and others don't hear any loss of quality). But I am musterfied as to why the calls are good with out some QOS intervention.

So does this (or other)versions of OpenWrt handle DSCP 'out of the box' so to speak?
And is infact 'seeing' these frames and packets coming (from the internal Cisco Router) in with DSCP marked EF Header and placing them in an 'EF' que ahead of the Bulk ftp traffic ? I can't see an special firewall rule(s) that might handle this from the GUI tho.

I'm studying for my CVOICE cert and thus are play in the 'lab' area of this exam.

regards,
Stephen.

(Last edited by shdashley on 4 Oct 2015, 08:26)

shdashley wrote:

Can someone answer this please.

I have a Cisco 2851 IOS Router and its my VoIP Phone system (CUCME), has a dedicated Phone lan etc and is flagging packets on my 'VoIP' lan for EF (expedited forwarding through my OpenWrt Wan router.

Been testing for packet loss by using WinSCP to ftp large'ish (36Mb) file up to my ISP ftp server for my account. Doing this I see my UP Link go 'flat out' ie max speed of my uplink is (about)934Kbps reported by my modem.

When doing this upload I would have expected pack loss when trying to make SIP VoIP calls from with in my network. I expected to hear 'stutted' speech outbound from my network.

But this does not occur, in several tests the voice call quality is great, perfect even (well I cant, and others don't hear any loss of quality). But I am musterfied as to why the calls are good with out some QOS intervention.

So does this (or other)versions of OpenWrt handle DSCP 'out of the box' so to speak?
And is infact 'seeing' these frames and packets coming (from the internal Cisco Router) in with DSCP marked EF Header and placing them in an 'EF' que ahead of the Bulk ftp traffic ? I can't see an special firewall rule(s) that might handle this from the GUI tho.

I'm studying for my CVOICE cert and thus are play in the 'lab' area of this exam.

regards,
Stephen.

What is the output of "tc -d qdisc" run on your openwrt router?
Did you in the past enable either qos-scripts or sqm-scripts (both of these might explain your issue), as both try to special case traffic with features commonly encountered for VoIP?
Also does the FTP traffic also traverse the cisco, or do you feed this into your openwrt router via a different path? If the former maybe the cisco does the prioritization and second router just preserves it.

Best Regards
        M.

root@ITASH-Wan:~# tc -d qdisc
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev ifb0 root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev pppoe-wan root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc mq 0: dev wlan1 root
qdisc fq_codel 0: dev wlan1 parent :1 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan1 parent :2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan1 parent :3 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan1 parent :4 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc mq 0: dev wlan0 root
qdisc fq_codel 0: dev wlan0 parent :1 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan0 parent :2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan0 parent :3 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan0 parent :4 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn


I did have the QOS scripts and LUCI (luci-app-qus & qos-scripts) but have since removed them as I did not experience an data loss while trying the test. Might have to try some new tests, and make several calls while uploading to see if I get a some different results.

shdashley wrote:

root@ITASH-Wan:~# tc -d qdisc
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev ifb0 root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev pppoe-wan root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc mq 0: dev wlan1 root
qdisc fq_codel 0: dev wlan1 parent :1 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan1 parent :2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan1 parent :3 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan1 parent :4 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc mq 0: dev wlan0 root
qdisc fq_codel 0: dev wlan0 parent :1 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan0 parent :2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan0 parent :3 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev wlan0 parent :4 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn


Hi sdashley,

so your openwrt router at least uses fq_codel, great. But that alone can not explain the performance you see. Could you elaborate a bit more about your setup? Like, what model openwrt router you use, whether you connect via the cisco or via the openwrt, are cisco and openwrt connected by wire or wireless...

On the other hand, you definitely have a luxury problem, in that your networks seems well behaved with you having to configure it wink So maybe just accept that you got lucky wink ?

Best Regards
        M.

I did have the QOS scripts and LUCI (luci-app-qus & qos-scripts) but have since removed them as I did not experience an data loss while trying the test. Might have to try some new tests, and make several calls while uploading to see if I get a some different results.

So I have a Netgear WNDR4300 running OpenWRT, this router IS my WAN and VLAN1 (normal house) access Point, DHCP server, access router.

The Cisco 2851 is my CUCME (Cisco Voice) router, it also routes a few other internal (My Lab area, House Phone VLan, and my OOB or ILO network access VLan). The are other Csico and Procurve Layer 2 access switchers in these VLans.

They are all connected by 1Gb UTP (ie Copper) links.

So when I get off my shift, I will plan to use a few PC to flood the up link, not just one PC. And then try to make 2 out bound calls to 'really' see if the OpenWRT rtr is prioritizing my RTP packets.

I know the Cisco (7961 and 7970 'skinny' phones) will set there RTP packets with DSCP ER headers, the Cisco router will forward them out is priority que. It does seems to be working. But I will try harder to break it.



Hi sdashley,

so your openwrt router at least uses fq_codel, great. But that alone can not explain the performance you see. Could you elaborate a bit more about your setup? Like, what model openwrt router you use, whether you connect via the cisco or via the openwrt, are cisco and openwrt connected by wire or wireless...

On the other hand, you definitely have a luxury problem, in that your networks seems well behaved with you having to configure it wink So maybe just accept that you got lucky wink ?

Best Regards
        M.

The discussion might have continued from here.