HELP. Unsubscribe
Thanks
Vyas
lartc-request@mailman.ds9a.nl wrote:
> Send LARTC mailing list submissions to
> lartc@mailman.ds9a.nl
>
> 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
> lartc-request@mailman.ds9a.nl
>
> You can reach the person managing the list at
> lartc-admin@mailman.ds9a.nl
>
> 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" <mabrown-lartc@securepipe.com>
> To: Marco Balle <mb@monster-server.de>
> Cc: lartc@mailman.ds9a.nl
> 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. --- mabrown@securepipe.com
>
> --__--__--
>
> Message: 2
> From: "Marco Balle" <mb@monster-server.de>
> To: "''Martin A. Brown''"
<mabrown-lartc@securepipe.com>
> Cc: <lartc@mailman.ds9a.nl>
> 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 <tack@auc.ca>
> To: lartc@mailman.ds9a.nl
> 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 :: tack@auc.ca :: 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 <arindamhaldar@inbox.lv>
> To: Tomasz Wrona <tw@eter.tym.pl>
> Cc: LARTC <lartc@mailman.ds9a.nl>
> 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" <kbohling@birddog.com>
> To: Jason Tackaberry <tack@auc.ca>
> Cc: lartc@mailman.ds9a.nl
> 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 :: tack@auc.ca :: 705-949-2301 x330
> > Academic Computing Support Specialist
> > Information Technology Services
> > Algoma University College :: www.auc.ca
> >
> >
> > _______________________________________________
> > LARTC mailing list / LARTC@mailman.ds9a.nl
> > 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" <GregScott@InfraSupportEtc.com>
> To: "Jason Tackaberry" <tack@auc.ca>,
<lartc@mailman.ds9a.nl>
>
> 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:tack@auc.ca]
> Sent: Wednesday, October 09, 2002 8:55 PM
> To: lartc@mailman.ds9a.nl
> 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 :: tack@auc.ca :: 705-949-2301 x330=20
> Academic Computing Support Specialist
> Information Technology Services
> Algoma University College :: www.auc.ca
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
> --__--__--
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc
>
> End of LARTC Digest
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/