From: Pavel Bykov (slidersv@gmail.com)
Date: Sun Nov 09 2008 - 17:47:14 ARST
Couple of notes:
1. You are using "match protocol http" meaning NBAR would have to be turned
on on the interface.
2. The point of NBAR and deep packet inspection is to use more than just
L2/L3/L4 headers. Because you are matching "http host facebook.com", the ACL
would only have to match source address in your network (the
135.15.11.0/24subnet) Combination of ACL and NBAR should more general.
3. ACL is not correct for directions provided.
4. For the web, the general rule is that doenload traffic is much larger
than upload.
Consider packet flow. We have a station X in your network, that sends an
HTTP requuest from INSIDE fa0/0 to facebook.com.
Question: Do we want to limit it on the inside side?
Well, no, not really since we want to provide "bandwidth guarantee" for HTTP
requests, HTTP uploads (e.g. photos), etc. So we want to use buffers for
congestion management.
Question: Where are buffers for congestion management located?
Well, where the congestion occurs! Probably in the bottle neck! fa0/1 is
probably a slow interface, because if it's not slow and about same speed as
inside fa 0/0, then all we are doing is pointless, because no congestion
will occur in the first place.
Question: Why are we doing all the queueing in the first place?
To manage congestion, not reorder the packets. So if there is no bottle
neck, there is no congestion, no queues, and nothing to manage! (very
simplified, there could be bursts, non real-time operating system related
bursts, etc)
So the answer where the congestion that we want to manage is and where the
queues are become obvious: on outside interface of fa 0/1.
So it can be like this:
class-map match-all FACEBOOK
match protocol http host *facebook.com
match access-group 10
policy-map CORP
class FACEBOOK
bandwidth 128
access-list 10 permit 132.15.11.0 0.0.0.255
int fa0/1
service-po output CORP
So we are matching SOURCE of the packets (which is our local network) and
deep packet information - the host in HTTP.
It could have also been the following:
class-map match-all FACEBOOK
match access-group 100
policy-map CORP
class FACEBOOK
bandwidth 128
access-list 100 permit ip 132.15.11.0 0.0.0.255 host 1.1.1.1
int fa0/1
service-po output CORP
Because if we know the destination (facebook's ip of 1.1.1.1) and the source
(local network) then we don't have to do inspection, unless we want to match
ONLY HTTP traffic between these particular sites.
In revers direction you also need to think about the logic.
Hope this helps.
On Sun, Nov 9, 2008 at 8:24 PM, Usama Pervaiz <chaudri@gmail.com> wrote:
> Hello all,
>
> I had a question on limiting and or policing traffic from a particular
> website. So lets take 2 scenarios:
>
> INSIDE ---------- R1 --------- OUTSIDE
> fa0/0 fa0/1
>
> 1. We want only user in a particular subnet (subnet 132.15.11.0/24) to
> have access to facebook (and we found the ip for facebook to be
> 1.1.1.1) so we are going to guarantee 128K to it for facebook for
> that subnet. Following is the config:
>
> class-map match-all FACEBOOK
> match protocol http host *facebook.com*
> match access-group 100
>
> policy-map CORP
> class FACEBOOK
> bandwidth 128
>
> access-list 100 permit ip host 1.1.1.1 132.15.11.0 0.0.0.255
>
> int fa0/0
> service-po output CORP
>
> 2. We want to limit the RETURN TRAFFIC from facebook to 64K to subnet
> 132.15.12.0/24. Following config
>
> class-map match-all FACEBOOK-LIMIT
> match protocol http host *facebook.com*
> match access-group 101
>
> policy-map CORP-IN
> class FACEBOOK-LIMIT
> police 64000
>
> access-list 101 permit ip host 1.1.1.1 132.15.12.0 0.0.0.255
>
> int fa0/1
> service-policy input CORP-IN
>
>
>
> Is the above config correct for the 2 scenarios. I am a little
> confused on the direction that its applied. I have sees some solutions
> apply the service-policy for policing in the output direction. Which
> does not make sense to me with that same access-list.
>
> Any and all help will be appreciated!!
>
> Thanks.
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
-- Pavel Bykov ------------------------------------------------- Stop the braindumps! http://www.stopbraindumps.com/Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:30 ARST