From: Bob Sinclair (bsin@cox.net)
Date: Wed Jan 05 2005 - 11:58:39 GMT-3
Tim,
That is right: the matching behavior of classes in policy-maps is like that
of access lists. If traffic matches a class higher in the policy, it is
acted upon, and will not match classes lower in the policy.
Bob Sinclair
CCIE #10427, CCSI 30427, CISSP
www.netmasterclass.net
----- Original Message -----
From: "Tim Hardwick" <tim.hardwick@talk21.com>
To: "Mike Flannagan" <mflannag@cisco.com>; "'Bob Sinclair'"
<bsinclair@netmasterclass.net>; <ccielab@groupstudy.com>
Sent: Wednesday, January 05, 2005 6:02 AM
Subject: RE: CBWFQ
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
> ---------------------------------
> ALL-NEW Yahoo! Messenger - all new features - even more fun!
>
> _______________________________________________________________________
> 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