HELP. Unsubscribe Thanks Vyas
[EMAIL PROTECTED] wrote: > Send LARTC mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.ds9a.nl/mailman/listinfo/lartc > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of LARTC digest..." > > Today's Topics: > > 1. RE: ipchains iproute2 and port based routing (Martin A. Brown) > 2. RE: ipchains iproute2 and port based routing (Marco Balle) > 3. Can't keep up with all these file sharing programs! (Jason Tackaberry) > 4. Re: IMQ (Arindam Haldar) > 5. Re: Can't keep up with all these file sharing programs! (Kirby C. Bohling) > 6. RE: Can't keep up with all these file sharing programs! (Greg Scott) > > --__--__-- > > Message: 1 > Date: Wed, 9 Oct 2002 15:28:00 -0500 (CDT) > From: "Martin A. Brown" <[EMAIL PROTECTED]> > To: Marco Balle <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: RE: [LARTC] ipchains iproute2 and port based routing > > Hi again, Marco, > > : I made every new try a ipchains -F - there was no other chain(s). > > Got it. > > : Okay, it seems there is a problem. In this DENY chain I get after every > : ping 4 more packets (one ping - 4 tries). > : It seems ipchains deny the incoming icmp packets on eth2. But why? > : I tried also to specify the source ip with some other chains, and it is > : the packet, that comes from the host 62.154.89.102 - exactly the packet > : I am waiting for. > : > : A ipchains -nML shows a open masq connection to the host, I ping'd: > : > : IP masquerading entries > : prot expire source destination ports > : ICMP 00:57.85 192.168.0.31 62.154.89.102 512 (61009) -> 8 > > All is well. > > : 0: from all lookup local > : 32765: from all fwmark 2 lookup 10 > : 32766: from all lookup main > : 32767: from all lookup 253 > : > : there is a timeout. It shows me, the marking of packets works and the ip > : rules can see the marked packets. > > Looks right. > > : >By the way, you are using "ip route flush cache" every time you make > : >changes to the routing tables/RPDB, right? > : > : Yes, i do. > > This is just a common problem--so I wanted to ask. > > : >Aigh! I think I may have spotted the problem. > : >Your routing table number 10 doesn't know anything about 192.168.0.0/24 > : >does it? > : >Make sure that each routing table has routes for the destinations it is > : >supposed to be able to reach! > : > : ipchains -A input -p icmp -s 192.168.0.0/24 -m 2 > : > : ip ru add fwmark 2 table 10 > : > : ip route add default via x.x.x.x dev eth2 table 10 > : > : ipchains -A forward -s 192.168.0.0/24 -j MASQ > : > : * x.x.x.x is the default gateway! > : Well, if I look into the rules table I see: > : 0: from all lookup local > : 32765: from all fwmark 2 lookup 10 > : 32766: from all lookup main > : 32767: from all lookup 253 > > <I snipped much of your mail with which I agree> > > : But okay. This is not the problem. > : It seems, ipchains DENY this packet. But why? > : > : Here a ipchains -L: > > : Chain input (policy ACCEPT): > : target prot opt source destination > : ports > : - icmp ------ 192.168.0.0/24 anywhere any > : -> any > : DENY all ----l- anywhere anywhere n/a > : Chain forward (policy DENY): > : target prot opt source destination > : ports > : MASQ all ------ 192.168.0.0/24 anywhere n/a > : Chain output (policy ACCEPT): > > I was suggesting the "ipchains -A input -j DENY -l" chain to make sure > that any packet passing through is explicitly logged and dropped instead > of implicitly. I'm sure you'll see lots of DENY traffic in your > /var/log/messages when using this rule, and things definitely won't work. > Sorry if that was at all unclear--this was intended as a diagnosing tool. > > : The deny chain, is your chain to monitor :) > : Without it (the deny chain) it is exactly the same siduation. > : Wth denys ipchains this incoming packet on eth2? > > It doesn't look to me like the input chain is your problem, but rather > your forward chain. The default policy is deny. Try changing that to > allow specifically what you want to allow. > > You could always try that very same diagnosing ipchains rule in your > forward chain, i.e. "ipchains -A forward -j DENY -l". Then you'll see > that the de-masqueraded packet is denied passing through the forward > chain. (At least that's my guess....) > > This, of course, is the beauty of using iptables--much less worrying with > iptables rules than with ipchains rules (in general), but you are using > kernel 2.2.19, I believe, so iptables is not an option for you. > > Let us know how you fare, > > -Martin > > -- > Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] > > --__--__-- > > Message: 2 > From: "Marco Balle" <[EMAIL PROTECTED]> > To: "'Martin A. Brown'" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Subject: RE: [LARTC] ipchains iproute2 and port based routing > Date: Wed, 9 Oct 2002 23:31:00 +0200 > > Next:) > > >You could always try that very same diagnosing ipchains rule in your > >forward chain, i.e. "ipchains -A forward -j DENY -l". Then you'll see > >that the de-masqueraded packet is denied passing through the forward > >chain. (At least that's my guess....) > > I did. I understand the deny chain now - it was my mistake. > > In the forward chain, I added the deny chain: > ipchains -A input -i eth2 -j DENY -l > But no packets arrive there. > > I write it down, the short version: > > Chain input (policy ACCEPT): > target prot opt source destination > ports > - icmp ------ 192.168.0.0/24 anywhere any > -> any > Chain forward (policy ACCEPT): > target prot opt source destination > ports > MASQ all ------ 192.168.0.0/24 anywhere n/a > DENY all ----l- anywhere anywhere n/a > Chain output (policy ACCEPT): > > So the default policy is accept. With a ping of 4 tries, the forward - > MASQ chain added 4 pakets and the icmp mark chain added also 4 packets. > But no one in the DENY chain. > > The same with the deny chain in the input chain: > ipchains -A forward -j DENY -l > > Chain input (policy ACCEPT): > target prot opt source destination > ports > - icmp ------ 192.168.0.0/24 anywhere any > -> any > DENY all ----l- anywhere anywhere n/a > Chain forward (policy ACCEPT): > target prot opt source destination > ports > MASQ all ------ 192.168.0.0/24 anywhere n/a > Chain output (policy ACCEPT): > > There with the same ping, 4 packets added in the MASQ, in the icmp _and_ > in the input deny chain. > > Hmm, if I don't make anything wrong, the packets get lost after the > input and before the forward chain. > > What do you think? > > Now it is time to go to bed, its 11:30pm here. > I am at home tomorrow at 5pm CET (hope so) and will try again - so long > to it works, the next day is free for me, so I have the whole night > tomorrow. > > Marco > > --__--__-- > > Message: 3 > From: Jason Tackaberry <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Organization: > Date: 09 Oct 2002 21:54:39 -0400 > Subject: [LARTC] Can't keep up with all these file sharing programs! > > Hi everyone, > > I'm using HTB to shape traffic for students in our residences. We're an > extremely small college (about 50 Internet users in our residences) and > we don't have a good deal of bandwidth to work with, so I must do what I > can to make what we do have tolerable to our students. > > I am right now using the following approach: I have allotted a portion > of our total bandwidth (R) to the residence subnet on the upstream > interface on our router. This class is sub-divided into two classes: a > p2p class for all those pesky file sharing programs, which has a ceiling > of about R/2, and an "everything else" class, which has a guaranteed > rate of R/2, and a ceililng of R. I have put SYN and ACK packets in a > separate class (under root) to improve responsiveness. > > In theory, this scheme works pretty good. The problem is that every day > some of these p2p programs are using different ports, and they manage to > suck up all available downstream bandwidth. So, the student who wants > to send their friend a file over ICQ is going to get starved by every > other student running Kazaa-du-jour. > > Now it would be _really_ nice if there was some ability to examine > packets at layer 7 to determine what class a particular session belongs > in (like, for instance, the way Packeteer's Packet Shaper works). I'm > assuming I can't get this functionality (unless I write it myself), so > can someone suggest a remedy to my problem? Is there some magic > adjustment I can make? Or, perhaps I should try a different approach, > and give each IP a guaranteed rate? The only drawback I see with this > is that with 50 users, I could only guarantee each user 5kbps. :) > > Any guidance would be appreciated. > > Best, > Jason. > > -- > Jason Tackaberry :: [EMAIL PROTECTED] :: 705-949-2301 x330 > Academic Computing Support Specialist > Information Technology Services > Algoma University College :: www.auc.ca > > --__--__-- > > Message: 4 > Date: Thu, 10 Oct 2002 09:15:03 +0530 > From: Arindam Haldar <[EMAIL PROTECTED]> > To: Tomasz Wrona <[EMAIL PROTECTED]> > Cc: LARTC <[EMAIL PROTECTED]> > Subject: Re: [LARTC] IMQ > > Tomasz Wrona wrote: > > On Wed, 9 Oct 2002, Arindam Haldar wrote: > > > >>what i have to do to enable IMQ with iptables 1.2.7a for linux kernel > >>2.4.19 ? > > > > launch ./runme extra > i did that ! > i first patched IMQ going into iptables1.2.7a directory & then changing > to patch-o-matic directory did--> ./runme extra > but the IMQ option didnt come !! > did i miss any step ?? > > > > > tw > > --__--__-- > > Message: 5 > Subject: Re: [LARTC] Can't keep up with all these file sharing programs! > From: "Kirby C. Bohling" <[EMAIL PROTECTED]> > To: Jason Tackaberry <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Date: 09 Oct 2002 23:00:00 -0500 > > On Wed, 2002-10-09 at 20:54, Jason Tackaberry wrote: > > Hi everyone, > > > > I'm using HTB to shape traffic for students in our residences. We're an > > extremely small college (about 50 Internet users in our residences) and > > we don't have a good deal of bandwidth to work with, so I must do what I > > can to make what we do have tolerable to our students. > > > > I am right now using the following approach: I have allotted a portion > > of our total bandwidth (R) to the residence subnet on the upstream > > interface on our router. This class is sub-divided into two classes: a > > p2p class for all those pesky file sharing programs, which has a ceiling > > of about R/2, and an "everything else" class, which has a guaranteed > > rate of R/2, and a ceililng of R. I have put SYN and ACK packets in a > > separate class (under root) to improve responsiveness. > > > > In theory, this scheme works pretty good. The problem is that every day > > some of these p2p programs are using different ports, and they manage to > > suck up all available downstream bandwidth. So, the student who wants > > to send their friend a file over ICQ is going to get starved by every > > other student running Kazaa-du-jour. > > > > Now it would be _really_ nice if there was some ability to examine > > packets at layer 7 to determine what class a particular session belongs > > in (like, for instance, the way Packeteer's Packet Shaper works). I'm > > assuming I can't get this functionality (unless I write it myself), so > > can someone suggest a remedy to my problem? Is there some magic > > adjustment I can make? Or, perhaps I should try a different approach, > > and give each IP a guaranteed rate? The only drawback I see with this > > is that with 50 users, I could only guarantee each user 5kbps. :) > > > > Any guidance would be appreciated. > > > > Jason, > > It sounds like your using a black list to get you moved into the "P2P" > bandwidth.... Why not turn it around and review /etc/services and say: > > http,smtp,pop3,imap,news,https,rsync,icq,irc,ssh and other services get > into the white list of "Non-P2P" bandwidth. It's much easier to qualify > the things you like, instead of the things you don't like in this case. > I'd also shift the percentage to 75/25 whitelist/blacklist. > > Now if anybody abuses this, by trying to run P2P over a well-known > port, there are ways of solving that too. First just bandwidth limit > them into you get 2.5K unless there is bandwidth to spare.... > > Another idea, is keep stats on "abused ports". Any source or dest port > that consumes more then X% of the total bandwidth gets put onto the > blacklist ports. Script the whole stats, and adding removing ports from > the list. Possibly just keep port 80 on the it's okay post list it will > always exceed X% for reasonable values of X. > > There's also a certain amout of fairness in just splitting the > bandwidth guaranteed evenly. It's about as fair as you can be. > > An interesting thing could be split the bandwith cap inversely > proportional to usage. So for someone who rarely uses the network > connection, they have a higher hard cap then someone who uses it > constantly. Just order everyones network usage, give the first 5% > guaranteed access to 30% of the bandwidth. Give the next 60% guaranteed > access to 60%, give the last 20% access to 10% of the bandwidth as a > guaranteed limit. So when everyone is on, the people who generally don't > use it much get on an abundance of bandwidth during the few times they > want it. Maybe do that with 80% of the bandwidth, leave the other 20% > uncontrolled for anyone to use at any rate they can get it at just so > there is burstable bandwidth available to anybody when they need it. > > The people who use more then their fair share most of the day, can wait > while the people who generally don't take their portion are attempting > to use it. This is even more fair then picking "bad" services. It > doesn't make any difference if I'm consuming all the bandwidth > downloading web pages to build the next google index, or if I'm > consuming all the bandwidth using Kazaa. I'm still using too much of > the shared resource. What I'm using it on is relatively irrelavent. Me > using it for anything keeps someone else from using it productively. > > Keep the stats and re-categorize the users say every 6/12/24 hours. > Maybe do it just once a week. You might have to shuffle the > percentages, and user count a bit, but it should work to give people a > fair chance at using up their portion of the bandwidth when they need > it. Yeah it's a fair amount of scripting, but should be relatively > stable setup once you are done with it. > > Thanks, > Kirby > > > Best, > > Jason. > > > > -- > > Jason Tackaberry :: [EMAIL PROTECTED] :: 705-949-2301 x330 > > Academic Computing Support Specialist > > Information Technology Services > > Algoma University College :: www.auc.ca > > > > > > _______________________________________________ > > LARTC mailing list / [EMAIL PROTECTED] > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > -- > Real Programmers view electronic multimedia files with a hex editor. > > --__--__-- > > Message: 6 > Subject: RE: [LARTC] Can't keep up with all these file sharing programs! > Date: Wed, 9 Oct 2002 23:28:26 -0500 > From: "Greg Scott" <[EMAIL PROTECTED]> > To: "Jason Tackaberry" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > > You could try a completely different approach: > > First, set up an iptables rule that redirects anything outbound that's = > port 80 or 20 or 21 to, say, squid or some other proxy server. Then = > block **everything** else going out. > > So for the outbound web stuff, get one of the commercial filtering = > packages and put that on top of the proxy server redirected above. That = > will do the layer 7 filtering within the context of outbound web access = > and will block inappropriate sites. This will also solve your Kazaah du = > jor problem cuz nothing will go out except legit web and ftp stuff. > > Just a thought - facing similar issues myself. I don't think you can = > fight this problem with low level traffic shaping. > > - Greg Scott > > -----Original Message----- > From: Jason Tackaberry [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 09, 2002 8:55 PM > To: [EMAIL PROTECTED] > Subject: [LARTC] Can't keep up with all these file sharing programs! > > Hi everyone, > > I'm using HTB to shape traffic for students in our residences. We're an > extremely small college (about 50 Internet users in our residences) and > we don't have a good deal of bandwidth to work with, so I must do what I > can to make what we do have tolerable to our students. > > I am right now using the following approach: I have allotted a portion > of our total bandwidth (R) to the residence subnet on the upstream > interface on our router. This class is sub-divided into two classes: a > p2p class for all those pesky file sharing programs, which has a ceiling > of about R/2, and an "everything else" class, which has a guaranteed > rate of R/2, and a ceililng of R. I have put SYN and ACK packets in a > separate class (under root) to improve responsiveness. > > In theory, this scheme works pretty good. The problem is that every day > some of these p2p programs are using different ports, and they manage to > suck up all available downstream bandwidth. So, the student who wants > to send their friend a file over ICQ is going to get starved by every > other student running Kazaa-du-jour. > > Now it would be _really_ nice if there was some ability to examine > packets at layer 7 to determine what class a particular session belongs > in (like, for instance, the way Packeteer's Packet Shaper works). I'm > assuming I can't get this functionality (unless I write it myself), so > can someone suggest a remedy to my problem? Is there some magic > adjustment I can make? Or, perhaps I should try a different approach, > and give each IP a guaranteed rate? The only drawback I see with this > is that with 50 users, I could only guarantee each user 5kbps. :) > > Any guidance would be appreciated. > > Best, > Jason. > > --=20 > Jason Tackaberry :: [EMAIL PROTECTED] :: 705-949-2301 x330=20 > Academic Computing Support Specialist > Information Technology Services > Algoma University College :: www.auc.ca > > _______________________________________________ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > --__--__-- > > _______________________________________________ > LARTC mailing list > [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc > > End of LARTC Digest _______________________________________________ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
