North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: QoS for ADSL customers
There are quite a few modules for iptables that will reach up to Layer 7, including several specifically for file sharing applications... And one really nifty one that makes non-passive ftp work through NAT. -e > -----Original Message----- > From: william(at)elan.net [mailto:[email protected]] > Sent: Tuesday, December 06, 2005 10:50 AM > To: Joe Shen > Cc: Ejay Hire; 'Kim Onnel'; 'NANGO' > Subject: RE: QoS for ADSL customers > > > On Wed, 7 Dec 2005, Joe Shen wrote: > > > Could IPtables control traffic with inspecting layer7 > > information? > > Not layer 7. IPtables works on L3 & L4 (and another similar system > for linux called ebtables provides filtering at L2) but it can > be used for setting up qos depending on where from (and to) the > traffic is going and what port is being used. > > For layer7 filtering on linux you need protocol proxies, and you > can use iptables to redirect all http traffic from subnet to squid > (although its not designed to be a filter, it can be used to > implement L7 filtering for http, but I'm not sure it can be used > for prioritization though). > > > As someone suggested, bandwidth allocation could be > > done with TCP protocol control ( ACK dropping or so); > > How can we do that? NBAR only limit the bandwidth, and > > to our experience with cisco7609 it cost a lot of cpu > > time! > > > > Where can I find QoS experiemnt result and sample > > configuration of ERX14xx? > > > > Joe > > > > > > --- Ejay Hire <[email protected]> wrote: > > > >> > >> Hello. > >> > >> Going back to your original question, how to keep > >> from > >> saturating the network with residential users using > >> bittorrent/edonkey et al, while suffocating business > >> customers. Here goes. > >> > >> Netfilter/IpTables (and a slew of commercial > >> products I'm > >> sure) has a Layer 7 traffic classifier, meaning it > >> can > >> identify specific file transfer applications and set > >> a > >> DiffServ bit. This means it can tell between a real > >> http > >> request and a edonkey transfer, even if they are > >> both using > >> http. It also has rate-limiting capability. So... > >> If you > >> pass all of the traffic destined for your DSL > >> customers > >> through an iptables box (single point of failure) > >> then you > >> can classify and rate-limit the downstream rate on a > >> per-application basis. > >> > >> Fwiw, if you are using diffserv bits, you could push > >> the > >> rate-limits down to the router with a qos policy in > >> it > >> instead of doing it all in the iptables box. > >> > >> References on this.. The netfilter website (for > >> classification info) and the Linux advanced router > >> tools > >> (LART) (qos info/rate limiting) > >> > >> -e > >> > >> > >>> -----Original Message----- > >>> From: [email protected] > >> [mailto:[email protected]] > >> On > >>> Behalf Of Kim Onnel > >>> Sent: Thursday, December 01, 2005 3:26 AM > >>> To: NANGO > >>> Subject: Re: QoS for ADSL customers > >>> > >>> Can any one please suggest to me any commercial or > >> none > >>> solution to cap the download stream traffic, our > >> upstream > >>> will not recieve marked traffic from us, so what > >> can be > >> done ? > >>> > >>> > >>> On 11/29/05, Kim Onnel <[email protected]> > >> wrote: > >>> > >>> Hello everyone, > >>> > >>> We have Juniper ERX as BRAS for ADSL, its GigE > >>> interface is on an old Cisco 3508 switch with an > >> old IOS, > >> its > >>> gateway to the internet is a 7609, our transit > >> internet > >> links > >>> terminate on GigaE, Flexwan on the 7600 > >>> > >>> The links are now almost always fully utilized, > >> we > >> want > >>> to do some QoS to cap our ADSL downstream, to give > >> room > >> for > >>> the Corp. customers traffic to flow without pain. > >>> > >>> I'm here to collect ideas, comments, advises and > >>> experiences for such situations. > >>> > >>> Our humble approach was to collect some p2p ports > >> and > >>> police traffic to these ports, but the traffic > >> wasnt much, > >> > >>> one other thing is rate-limiting per ADSL > >> customers IPs, > >> but > >>> that wasnt supported by management, so we thought > >> of > >> matching > >>> ADSL www traffic and doing exceed action is > >> transmit, and > >>> police other IP traffic. > >>> > >>> Doing so on the ERX wasnt a nice experience, so > >> we're > >>> trying to do it on the cisco. > >>> > >>> Thanks >
|