From: tim.hardwick@talk21.com
Date: Tue Jan 04 2005 - 14:09:18 GMT-3
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
This archive was generated by hypermail 2.1.4 : Wed Feb 02 2005 - 22:10:18 GMT-3