From: Ejay Hire (no email)
Date: Tue Dec 06 2005 - 11:52:21 EST
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:]
> 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 <> 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:
> >> [mailto:]
> >> 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 <>
> >> 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
>
|
|
|