Hello, I have the following configuration eth0(192.168.0.X -> Shorewall + NAT -> Eth1(195.112.X.X I have CentOS 4.4 on my machine Shorewall is working fine as a firewall + NAT , but I need help regarding traffic shapingb I am trying to give priority to VOIP traffic as I have asterisk running on the same machine where shorewall is running I read in the documentatuion that we can only shape outgoing traffic from a certain interface So what I did is that I defined classes for traffic going out of eth1 ( WAN side) AND traffic going out eth0 ( NAT side) I am assuming that shaping outgoing traffic on NAT side will help limit incoming browsing traffic(http downloads) to a certain level Note my link is 128k upload and 128k download My configuration files are as follows . I need to know if what i am trying to do sounds logical or not tcdvices eth0 10000kbps 10000kbps ( NAT side) eth1 128kbps 128kbps ( WAN side) tcrules (IP''s 64.X , 195.X are remote VOIP gateways used to terminate my asterisk traffic) I am assuming that voice will use UDP 1 to 64000 while browsing downloads will be using other ports classified under default 1:F 0.0.0.0/0 64.X.X.X,64.7.X.X,195.X.X.X,195.X.X.X,64.X.X.X.X,64.X.X.X UDP 1:64000 1:F 0.0.0.0/0 192.168.0.0/24 UDP 1:64000 1 $FW 0.0.0.0/0 all (i have no services hosted on the server itself except asterisk) tcclasses ( I am limiting default traffic to 20k on NAT side) eth1 1 30kbps full 1 eth1 2 full full 2 default eth0 1 30kbps full 1 eth0 2 20k 20k 2 default Thanks ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Macram Zaarour wrote:>So what I did is that I defined classes for traffic going out of >eth1 ( WAN side) AND traffic going out eth0 ( NAT side) > >I am assuming that shaping outgoing traffic on NAT side will help >limit incoming browsing traffic(http downloads) to a certain level > >Note my link is 128k upload and 128k download > >My configuration files are as follows . I need to know if what i am >trying to do sounds logical or not > >tcdvices > >eth0 10000kbps 10000kbps ( NAT side) >eth1 128kbps 128kbps ( WAN side)Those values will not help. To do any good, you will need to shape the outbound traffic on the NAT side to less than your download speed - that way, if the download rate from the outside exceeds the (line speed less a bit) you can start throttling non-priority traffic. By setting the outbound speed of the LAN I/F to 10M, you are throttling at something far higher than your line speed and so will never get to prioritise the traffic you are shaping. BUT, and that really is a BIG BUT. This doesn''t account for traffic coming into the box from the WAN, and it will also throttle traffic originating in the box and going out to the LAN. It''s something I''ve been thinking about over the last week or two. At work I have a Linux box acting as a bridge and doing traffic logging, I''ve recently added traffic shaping as our VoIP was getting a bit rough at peak times. In this case, I''m thinking of a heirarchical setup on the internal I/F along the lines of : I/F (outbound) | |\ unrestricted, unprioritised queue (A) | \ HTB root (B) | |\ priority queue (B:1) |\ normal queue (B:2) \ ''slow'' queue (B:3) By setting the rate limit on B to a little below the incoming line speed it will cause excess incoming traffic to be queued (and ultimately dropped), hopefully causing TCP sessions to back off. By prioritising VoIP traffic, it should be possible to avoid dropping the RTP traffic. Traffic generated on the box itself will be put into the unrestricted queue A, and since this is 100M ethernet we''re unlikely to manage to saturate this ! If I were doing this on a box acting as both the gateway and Asterisk server I would be inclined to tune the max rate for B down to whatever the line does, less an allowance for however many voip calls we could have running at once, and less a tad to make sure we never saturate the line. As you can see, it''s far from trivial ! For home, I''ve been toying with Xen and whether I could run a small instance running as a bridge to do only traffic logging & shaping. By using a virtual switch between the main server and the bridge, it should be possible to do like I describe above - otherwise it''s impossible to take inbound traffic to the gateway box into account.>tcrules (IP''s 64.X , 195.X are remote VOIP gateways used to >terminate my asterisk traffic) >I am assuming that voice will use UDP 1 to 64000 while browsing >downloads will be using other ports classified under defaultThere is a saying that assumption is the mother of all f**k ups ! Asterisk (or more correctly AAH/Trixbox, not sure about a ''raw'' Asterisk install)) will use the ports specified in /etc/asterisk/rtp.conf, and the default is 10,000 to 20,000. I cut this down somewhat since I can''t see us needing anything like 10,000 active calls ! I edit mine down to 10,000 to 10,999 which still allows 1000 possible calls. You can then use more effective rules for prioritising your voip traffic. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hello, I am using ulaw as VOIP codec for internal calls between asterisk extensions, while using g729 for calls to the outside Setting the device OUT-BANDWIDTH on NAT side to below 128k(my download speed) will surely affect the internal calls voice quality knowing that ulaw takes up to 80k per call and all calls are proxied on the server. So two internal calls traffic consumption will far exceed my download speed of 128k Note that my internal asterisk extensions are on the NAT side Am I saying right, or am I missing something ? Thanks -----Original Message----- From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Simon Hobson Sent: Thursday, November 16, 2006 11:32 AM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] traffic shaping on NAT side Macram Zaarour wrote:>So what I did is that I defined classes for traffic going out of >eth1 ( WAN side) AND traffic going out eth0 ( NAT side) > >I am assuming that shaping outgoing traffic on NAT side will help limit >incoming browsing traffic(http downloads) to a certain level > >Note my link is 128k upload and 128k download > >My configuration files are as follows . I need to know if what i am >trying to do sounds logical or not > >tcdvices > >eth0 10000kbps 10000kbps ( NAT side) >eth1 128kbps 128kbps ( WAN side)Those values will not help. To do any good, you will need to shape the outbound traffic on the NAT side to less than your download speed - that way, if the download rate from the outside exceeds the (line speed less a bit) you can start throttling non-priority traffic. By setting the outbound speed of the LAN I/F to 10M, you are throttling at something far higher than your line speed and so will never get to prioritise the traffic you are shaping. BUT, and that really is a BIG BUT. This doesn''t account for traffic coming into the box from the WAN, and it will also throttle traffic originating in the box and going out to the LAN. It''s something I''ve been thinking about over the last week or two. At work I have a Linux box acting as a bridge and doing traffic logging, I''ve recently added traffic shaping as our VoIP was getting a bit rough at peak times. In this case, I''m thinking of a heirarchical setup on the internal I/F along the lines of : I/F (outbound) | |\ unrestricted, unprioritised queue (A) | \ HTB root (B) | |\ priority queue (B:1) |\ normal queue (B:2) \ ''slow'' queue (B:3) By setting the rate limit on B to a little below the incoming line speed it will cause excess incoming traffic to be queued (and ultimately dropped), hopefully causing TCP sessions to back off. By prioritising VoIP traffic, it should be possible to avoid dropping the RTP traffic. Traffic generated on the box itself will be put into the unrestricted queue A, and since this is 100M ethernet we''re unlikely to manage to saturate this ! If I were doing this on a box acting as both the gateway and Asterisk server I would be inclined to tune the max rate for B down to whatever the line does, less an allowance for however many voip calls we could have running at once, and less a tad to make sure we never saturate the line. As you can see, it''s far from trivial ! For home, I''ve been toying with Xen and whether I could run a small instance running as a bridge to do only traffic logging & shaping. By using a virtual switch between the main server and the bridge, it should be possible to do like I describe above - otherwise it''s impossible to take inbound traffic to the gateway box into account.>tcrules (IP''s 64.X , 195.X are remote VOIP gateways used to terminate >my asterisk traffic) I am assuming that voice will use UDP 1 to 64000 >while browsing downloads will be using other ports classified under >defaultThere is a saying that assumption is the mother of all f**k ups ! Asterisk (or more correctly AAH/Trixbox, not sure about a ''raw'' Asterisk install)) will use the ports specified in /etc/asterisk/rtp.conf, and the default is 10,000 to 20,000. I cut this down somewhat since I can''t see us needing anything like 10,000 active calls ! I edit mine down to 10,000 to 10,999 which still allows 1000 possible calls. You can then use more effective rules for prioritising your voip traffic. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
I hope you''ve read http://shorewall.net/traffic_shaping.htm completely. On 11/16/06, Macram Zaarour <mzaarour@vocalpad.com> wrote:> Setting the device OUT-BANDWIDTH on NAT side to below 128k(my download > speed) will surely affect the internal calls voice quality knowing that ulaw > takes up to 80k per call and all calls are proxied on the server. So two > internal calls traffic consumption will far exceed my download speed of 128kYou *don''t* need traffic shaping on the LAN side. Typically it''s very unlikely that you''re going to saturate that link. You *must* always shape on the most-constrained link. And if you don''t have the most constrained link (because of massive queues at the ISP), then you must reduce the incoming bandwidth and make it the most constrained link to be able to effectively shape the traffic. On the WAN side (128K link) it doesn''t need to be far less than 128K. Just enough less that queuing is on the shorewall box and not on the ISP box.> tcclasses ( I am limiting default traffic to 20k on NAT side) > eth1 1 30kbps full 1 > eth1 2 full full 2 defaultYou can''t say give 30kbps guaranteed to class 1, and say "full" to class 2!! Please drop the guaranteed bandwidth to 128-30K.> eth0 1 30kbps full 1 > eth0 2 20k 20k 2 defaultThese are not necessary, if you shape correctly on the WAN side. Prasanna. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Macram Zaarour wrote:>I am using ulaw as VOIP codec for internal calls between asterisk >extensions, while using g729 for calls to the outside > >Setting the device OUT-BANDWIDTH on NAT side to below 128k(my download >speed) will surely affect the internal calls voice quality knowing that ulaw >takes up to 80k per call and all calls are proxied on the server. So two >internal calls traffic consumption will far exceed my download speed of 128k > >Note that my internal asterisk extensions are on the NAT side > >Am I saying right, or am I missing something ?What you are missing is that to shape the inbound WAN traffic by controlling the outbound LAN traffic you need to configure your shaping to allow line-speed for traffic that originated ON THE BOX (''A'' in the example I gave) and constrain traffic that originated FROM THE WAN (''B'' in the example). Since you can''t take account of traffic originating from the WAN and terminating in the box, the best you could do for that is to estimate the maximum (ie n calls * x bps/call). In practice I think it''s probably better, and far simpler, to just police the inbound rate on the WAN side.>It''s something I''ve been thinking about over the last week or two. At work I >have a Linux box acting as a bridge and doing traffic logging, I''ve recently >added traffic shaping as our VoIP was getting a bit rough at peak times. In >this case, I''m thinking of a heirarchical setup on the internal I/F along >the lines of : > >I/F (outbound) > | > |\ unrestricted, unprioritised queue (A) > | > \ HTB root (B) > | > |\ priority queue (B:1) > |\ normal queue (B:2) > \ ''slow'' queue (B:3) > >By setting the rate limit on B to a little below the incoming line speed it >will cause excess incoming traffic to be queued (and ultimately dropped), >hopefully causing TCP sessions to back off. By prioritising VoIP traffic, it >should be possible to avoid dropping the RTP traffic. > >Traffic generated on the box itself will be put into the unrestricted queue >A, and since this is 100M ethernet we''re unlikely to manage to saturate this >!And Prasanna Krishnamoorthy replied:>You *don''t* need traffic shaping on the LAN side. Typically it''s very >unlikely that you''re going to saturate that link. You *must* always >shape on the most-constrained link. And if you don''t have the most >constrained link (because of massive queues at the ISP), then you must >reduce the incoming bandwidth and make it the most constrained link to >be able to effectively shape the traffic.But the discussion was about how to (approximate) traffic shaping/control on the inbound wan link by applying controls to the outbound queue of the lan side - as opposed to simply policing the inbound rate and indiscriminately dropping packets. Trying to shape traffic on a 128k link by specifying a rate of 10M isn''t going to work. I proposed a method that I believe would work (with enough provisos) but is harder to set up (would need a manual tcstart file). The reason I''ve been contemplating it is so that I can drop packets on the non-voip traffic and try to get it to slow down, whilst leaving the voip traffic as intact as possible. The inbound policing available doesn''t have that capability AFAIK, and in any case, the place to do it is at the ISP end but we don''t have any control over that. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV