I have some good histories about routing and linux, I have a little blog to share them, I have what I believe you need regarding internet access and routing and nats and so on.
Stop by and if more help is need it, let us know. http://soad1982.blogspot.com/2010/02/advance-routing-on-linux.html -- Jose Valdivia Firewall Enginner Perot Systems CCSA CCSE WCSA NCMA NCMP On Thu, Feb 11, 2010 at 9:15 AM, green <[email protected]> wrote: > Stephan Balmer wrote at 2010-02-11 03:04 -0600: > > > I am working on setting up a router/server running Debian Squeeze. I > have had > > > a lot to learn and have managed to understand iptables and have mostly > set up > > > filtering. > > > > What sort of link are we talking about? Symmetric/Asymmetric? Bandwidth? > > Well, sorry but it could be anything. I may at times have to move the > router > and my only requirements of the connection is that it be reliable, at least > say > 20kilobytes/s, and have a public IP address. > > > > Now I would like to set up traffic control. I have been reading > documentation > > > and have been looking for an eth0 ingress way to delay packets in order > to > > > control download bandwidth, but maybe ingress shaping is not a viable > solution. > > > Perhaps it is the ACKs that I need to shape instead: delay the outgoing > ACKs to > > > control downloads and delay the outgoing data to control the uploads. > Will > > > that work? > > > > I haven't looked lately, but on Linux you'll propably have to set up imq > devices > > for ingress shaping. Ingress shaping is indeed controversial. It is also > a lot > > simpler than delaying ACK packets based on traffic going the other > direction. > > I would rather not use something controversial, or preferably anything else > not > included in standard Debian squeeze. > > > Personally I wouldn't delay ACK packets, but prioritise them over other > > packets. They don't hurt your throughput. > > I understand that ACKs won't hurt throughput, but have supposed that > delaying > them would help control downloads. If the sender does not receive an ACK > until > later hopefully they will see a low-bandwidth link and slow down. > > If I prioritize ACKs over other packets, won't that make it even harder to > control downloads? That is, ACKs go out first so the sender sends faster? > > > Take this scenario, with these interfaces: > eth0: WAN > eth1: host connected > wlan0: random > > Say the router starts downloading a Debian ISO and uses all the bandwidth > at 80 > kilobytes/s. Now the eth1 host wants to download another one. I would > like > ideally to be able to say eth1 gets 80% and local gets 20%, but that seems > to > be difficult to accomplish. It seems that it would be a while (if ever) > before > eth1 gets a significant amount of bandwidth. Add to this wlan0 which will > be > unsecured and may be using lots of bandwidth (perhaps I could just give it > a > flat limit). Is there some way to balance this, if loosely? Perhaps just > using a certain TCP congestion algorithm? Or can I prioritize ACKs from > the > different interfaces? > > > Thanks. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkt0HwQACgkQ682C+dBP+oR5owCfTWEoQXeUELvnX93RunTXQuoi > WLcAninViUZj4+7xv+Xcg9FBPg3ridO9 > =muoD > -----END PGP SIGNATURE----- > >
