I''m trying to simply shape/prioritize upstream traffic but I don''t seem to be having any luck with Shorewall 4.4.6 (yes, I know, old, but what''s in Ubuntu''s LTS) and http://www.shorewall.net/simple_traffic_shaping.html. I''ve configured tcinterfaces and tcpri as follows: #INTERFACE TYPE IN-BANDWIDTH eth0 External 6mbit tun0 Internal #BAND PROTO PORT(S) ADDRESS INTERFACE HELPER 1 - - - - sip 1 - - 10.75.22.8 1 - - 88.117.40.1 but pinging 88.117.40.1 while my upstream is saturated doesn''t seem to be getting priority: 64 bytes from 88.117.40.1: icmp_seq=1956 ttl=255 time=1024 ms What am I missing? Cheers, b. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
Brian J. Murrell <brian <at> interlinx.bc.ca> writes:>I seem to have made some headway. I upgraded to 4.4.21 but that didn''t make any difference. I did add a 4th column to the tcinterfaces specifying the upstream bandwidth: #INTERFACE TYPE IN-BANDWIDTH eth0 External 6mbit 500kbit and that seems to have had a positive effect: 64 bytes from 88.117.40.1: icmp_seq=4 ttl=255 time=17.8 ms What''s strange is that ping to a site that I have not specified in the tcpri file, but I suppose that''s an aside. # ping www.yahoo.com PING any-fp3-real.wa1.b.yahoo.com (98.139.180.149) 56(84) bytes of data. 64 bytes from ir1.fp.vip.bf1.yahoo.com (98.139.180.149): icmp_seq=1 ttl=54 time=102 ms 64 bytes from ir1.fp.vip.bf1.yahoo.com (98.139.180.149): icmp_seq=2 ttl=54 time=106 ms 64 bytes from ir1.fp.vip.bf1.yahoo.com (98.139.180.149): icmp_seq=3 ttl=54 time=171 ms 64 bytes from ir1.fp.vip.bf1.yahoo.com (98.139.180.149): icmp_seq=4 ttl=54 time=104 ms 64 bytes from ir1.fp.vip.bf1.yahoo.com (98.139.180.149): icmp_seq=5 ttl=54 time=54.6 ms 64 bytes from ir1.fp.vip.bf1.yahoo.com (98.139.180.149): icmp_seq=6 ttl=54 time=170 ms 64 bytes from ir1.fp.vip.bf1.yahoo.com (98.139.180.149): icmp_seq=7 ttl=54 time=99.0 ms What I don''t understand is why I have to specify an upstream bandwidth in the tcinterfaces. I guess I had always thought that Shorewall''s Simple TC was simply prioritization, not bandwidth allocation. I would have thought TC didn''t need to know the upstream bandwidth to simply prioritize the de-queuing of packets in the higher bands. Cheers, b. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
On Nov 12, 2011, at 11:57 AM, Brian J. Murrell wrote:> Brian J. Murrell <brian <at> interlinx.bc.ca> writes: > > What I don''t understand is why I have to specify an upstream bandwidth in the > tcinterfaces. I guess I had always thought that Shorewall''s Simple TC was > simply prioritization, not bandwidth allocation. I would have thought TC didn''t need > to know the upstream bandwidth to simply prioritize the de-queuing of packets in > the higher bands. >You would think so, wouldn''t you? But given strong evidence to the contrary, I implemented the OUT-BANDWIDTH column, enforced through use of a token bucket filter. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1
Brian J. Murrell wrote:>What I don''t understand is why I have to specify an upstream bandwidth in the >tcinterfaces. I guess I had always thought that Shorewall''s Simple TC was >simply prioritization, not bandwidth allocation. I would have >thought TC didn''t need to know the upstream bandwidth to simply >prioritize the de-queuing of packets in the higher bands.That could be the case if the only constraint was your local link - but it isn''t in all cases. Case 1) At work we get an internet connection via fibre, nice 20Mbps uncontended, unmetered, unfiltered connection - at an eye watering price ! The bandwidth management is handled by a Cisco router somewhere upstream of us - there is at least one switch between us and the router. If we send at more than our permitted rate then initially we get to burst above it, but then it drops back. Latency rockets because the router has it''s own buffers that we''re filling up. So even though we prioritise our traffic, if we don''t keep the overall rate below the level at which queues build up in the ISP router then it won''t work. Case 2) Assume you have a PPP0E connection to the ISP - so there is no intervening router between you and the DSL line that restricts upstream bandwidth. Even though we may prioritise packets in the packet routing layer, I wouldn''t be surprised to find a queue in the PPP layer and then in the hardware/driver layer. So even though everything is notionally under your control, there are still elements that will trip you up. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1