From: Tim Hardwick (tim.hardwick@talk21.com)
Date: Wed Jan 05 2005 - 08:02:38 GMT-3
Thanks guys,
Not sure if I could use 'match not' in this scenario but it's certainly something that I'll bear in mind. Looking at my config, I have the more specific match for HTTP traffic first, (ACL 142) so HTTP traffic over the tunnel will be shaped according to the policy. Other HTTP traffic that goes to 'any' not over the tunnel is matched against an ACL after this. (ACL143) Based on this, can I take it that the second match (ACL 143) will not include anything that was previously matched in the first match
Kind Regards
Tim
Mike Flannagan <mflannag@cisco.com> wrote:
"match not" is probably one of the most useful, and least often used,
options available. You can do fun things like match all packets (using
match-any) and then configure a match not statement against an ACL...the
combination, within a match-all class-map would allow you to match ALL
packets, except those that matched the specific ACL.
Mike
Mike Flannagan, CCIE #7651
Manager, Advanced Services
High Touch Technical Support
mflannag@cisco.com
919.392.4550
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Bob
Sinclair
Sent: Tuesday, January 04, 2005 3:23 PM
To: tim.hardwick@talk21.com; ccielab@groupstudy.com
Subject: Re: CBWFQ
Tim,
The ordering of classes within a policy is critical. The policy assesses
each class in order from top to bottom. As soon as a match is made, the
associated policy is implemented. A deny in an access-list means
"no-match", and that traffic may be matched in subsequent classes. Just as
with a regular access-list, you will probably want to arrange your classes
from most- to less- specific.
If you use the optional "match any" syntax, then traffic that is denied by
one access-list in a class-map may be permitted in a subsequent access-list
and result in a match for the class.
Along these lines, a sometimes usefull command is the "match not" class-map
syntax. This reverses the logic of the access-list > everything that
matches the access-list, is not-matched by the class. This can be useful
when you need to shape class-default, but want to exclude some traffic.
HTH,
Bob Sinclair
CCIE #10427, CCSI 30427, CISSP
www.netmasterclass.net
----- Original Message -----
From:
To:
Sent: Tuesday, January 04, 2005 12:09 PM
Subject: CBWFQ
> Hi,
>
> I have a question relating to how CBWFQ uses an ACL to match criteria
> against which a packet is checked. It is probably best to provide a
> scenario first.
>
> If I have a remote site (10.10.10.0/24) that is connecting back to HQ
> (10.20.20.0/24) over a GRE/IPSEC tunnel. Internet access for this remote
> site is directly out of the router with NAT. All other private traffic
> is routed over the GRE/IPSEC tunnel. The scenario calls to implement an
> outbound QoS policy as follows:
>
>
> 1/ HTTP traffic to the Internet is restricted to 10% of the link
> bandwidth.
>
> 2/ HTTP traffic destined to HQ over the tunnel is restricted to 10% of
> the link bandwidth.
>
> 3/ Citrix traffic to HQ is guaranteed 100k of bandwidth.
>
>
> So my first thoughts are to use CBWFQ and tie all this together in one
> policy. I guess the tricky bit is in differentiating the HTTP traffic to
> the Internet and HTTP traffic to the Intranet which goes over the tunnel.
> I would see the policy as having multiple classes in a specific order as
> Im assuming (maybe incorrectly) that the policy will match in order. (Not
> found anything on CCO referring to this) This is where I am unclear. Not
> sure how the match criteria works here, particularly in terms of ordering
> and how the class map steps through the ACL's.
>
> For instance, how does the class-map handle an ACL with a deny statement?
> Anybody got any ideas on this?
>
>
> class-map match-all CITRIX
> match access-group 141
> !
> class-map match-all Intranet_HTTP
> match access-group 142
> !
> class-map match-all Internet_HTTP
> match acccess-group 143
> !
> policy-map QOS_OUT
> class CITRIX
> bandwidth 75
> class Intranet_HTTP
> peak percent 10
> class Internet_HTTP
> peak percent 10
> class class-default
> fair-queue
> !
> crypto isakmp policy 10
> encr 3des
> hash md5
> authentication pre-share
> crypto isakmp key cisco address 150.50.100.2
> !
> crypto ipsec transform-set TRSET esp-3des esp-md5-hmac
> !
> crypto map PRODMAP 10 ipsec-isakmp
> set peer 150.50.100.2
> set transform-set TRSET
> match address 105
> qos pre-classify
> !
> interface Loopback1
> description GRE Loopback Interface
> ip address 10.136.251.78 255.255.255.255
> !
> interface Tunnel0
> description Primary GRE Tunnel to HQ
> ip address 10.136.252.78 255.255.255.252
> qos pre-classify
> tunnel source Loopback1
> tunnel destination 10.136.251.1
> !
> interface E0
> Description External Interface
> ip address 150.50.100.1 255.255.255.0
> ip nat outside
> crypto map PRODMAP
> service-policy output QOS_OUT
> !
> interface FastEthernet0
> description Internal LAN
> ip address 10.10.10.1 255.255.255.0
> ip nat inside
> !
> router eigrp 2
> network 10.136.0.0 0.0.255.255
> no auto-summary
> !
> ip nat inside source list 115 interface Ethernet0 overload
> ip route 0.0.0.0 0.0.0.0 150.50.100.2
> ip route 10.136.251.1 255.255.255.255 150.50.100.2
> !
> access-list 105 permit ip host 10.136.251.78 host 10.136.251.1
> access-list 105 permit ip host 10.136.251.78 host 10.136.251.2
>
> access-list 115 deny ip 10.10.10.0 0.0.0.255 10.0.0.0 0.255.255.255
> access-list 115 permit ip 10.10.10.0 0.0.0.255 any
> !
> access-list 141 permit tcp 10.10.10.0 0.0.0.255 10.136.129.0 0.0.0.255 eq
> 1494
> access-list 142 permit tcp 10.10.10.0 0.0.0.255 10.20.20.0 0.0.0.255 eq
> http
> access-list 143 permit tcp 10.10.10.0 0.0.0.255 any eq http
>
>
>
> Regards
>
> Tim
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Feb 02 2005 - 22:10:18 GMT-3