09-18-2014 04:06 PM
Hi everybody,
We´ve a 10G interface, this is a MPLS trunk between one ASR 9010 and a 7613, and the first thing that we do is through a policy-map TK-MPLS_TG we make a shape of 2G to the interface to the output:
interface TenGigE0/3/0/0
cdp
mtu 1568
service-policy output TK-MPLS_TG
ipv4 address 172.16.19.134 255.255.255.252
mpls
mtu 1568
!
and we´ve the policy TK-MPLS_EDGE-WAN as a service-policy inside, this new policy help us to asign bandwidth percent to 5 class-map, wich in turn match with experimental values classified when they got in to the router:
class-map match-any W_RTP
match mpls experimental topmost 5
match dscp ef
end-class-map
!
class-map match-any W_EMAIL
match mpls experimental topmost 1
match dscp cs1
end-class-map
!
class-map match-any W_VIDEO
match mpls experimental topmost 4 3
match dscp cs3 cs4
end-class-map
!
class-map match-any W_DATOS-CR
match mpls experimental topmost 2
match dscp cs2
end-class-map
!
class-map match-any W_AVAIL
match mpls experimental topmost 0
match dscp default
end-class-map
!
policy-map TK-MPLS_EDGE-WAN
class W_RTP
bandwidth percent 5
!
class W_VIDEO
bandwidth percent 5
!
class W_DATOS-CR
bandwidth percent 30
!
class W_EMAIL
bandwidth percent 15
!
class W_AVAIL
bandwidth percent 2
!
!
class class-default
!
end-policy-map
!
what we want to do is to assign a especific bandwidth to the proxy to the output using the class W_AVAIL, the proxy is 150.2.1.100. We´ve an additional requirement, wich is not apply this "rate" to some networks we are going to list only 4 in the example, so what we did was a new policy-map with a new class-map and a new ACL :
ipv4 access-list PROXY-GIT-MEX
10 deny ipv4 host 150.2.1.100 10.15.142.0 0.0.0.255
20 deny ipv4 host 150.2.1.100 10.15.244.0 0.0.0.255
30 deny ipv4 host 150.2.1.100 10.18.52.0 0.0.0.127
40 deny ipv4 host 150.2.1.100 10.16.4.0 0.0.0.255
50 permit tcp host 150.2.1.100 any
60 permit tcp host 10.15.221.100 any
policy-map EDGE-MEX3-PXY
class C_PXY-GIT-MEX3
police rate 300 mbps
!
!
class class-default
!
end-policy-map
!
class-map match-any C_PXY-GIT-MEX3
match access-group ipv4 PROXY-GIT-MEX
end-class-map
we asign a policy rate of 300 mbps to the class inside the policy EDGE-MEX3-PXY and finally we put this new policy inside the class W_AVAIL of the policy TK-MPLS_EDGE-WAN
policy-map TK-MPLS_EDGE-WAN
class W_RTP
bandwidth percent 5
!
class W_VIDEO
bandwidth percent 5
!
class W_DATOS-CR
bandwidth percent 30
!
class W_EMAIL
bandwidth percent 15
!
class W_AVAIL
service-policy EDGE-MEX3-PXY
!
!
class class-default
!
end-policy-map
and we get this:
Wed Sep 17 18:35:36.537 UTC
% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed' from this session to view the errors
RP/0/RSP1/CPU0:ED_MEX_1(config-pmap-c)#show configuration failed
Wed Sep 17 18:35:49.662 UTC
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.
!
!!% Deny ace not supported in access-list: InPlace Modify Error: Policy TK-MPLS_TG: 'km' detected the 'warning' condition 'Deny ace not supported in access-list'
end
Any kind of help is very appreciated.
Solved! Go to Solution.
09-22-2014 08:56 AM
That is correct, due to the way the class-matching is implemented in the TCAM, only permit statements in an ACL can be used for QOS class-matching based on ACL.
unfortunately, you'll need to redefine the policy class match in such a way that it takes the permit only.
if you have some traffic that you want to exclude you could do something like this:
access-list PERMIT-ME
1 permit
2 permit
3 permit
access-list DENY-me
!the exclude list
1 permit
2 permit
3 permit
policy-map X
class DENY-ME
<dont do anything> or set something rogue (like qos-group)
class PERMIT-ME
do here what you wanted to do as earlier.
eventhough the permit and deny may be overlapping in terms of match.
only the first class is matched here, DENY-ME.
cheers!
xander
09-22-2014 08:56 AM
That is correct, due to the way the class-matching is implemented in the TCAM, only permit statements in an ACL can be used for QOS class-matching based on ACL.
unfortunately, you'll need to redefine the policy class match in such a way that it takes the permit only.
if you have some traffic that you want to exclude you could do something like this:
access-list PERMIT-ME
1 permit
2 permit
3 permit
access-list DENY-me
!the exclude list
1 permit
2 permit
3 permit
policy-map X
class DENY-ME
<dont do anything> or set something rogue (like qos-group)
class PERMIT-ME
do here what you wanted to do as earlier.
eventhough the permit and deny may be overlapping in terms of match.
only the first class is matched here, DENY-ME.
cheers!
xander
12-06-2018 09:57 AM
hi Xander,
I know this is an old post , but do you know if there is any platform now implementing deny ACEs when attaching to class-maps in IOS-XR family or is there a cli to overcome this . I got an old command reference of XR12K where the command "hw-module qos acl-deny enable" can be used to have an effect of deny ACE's attached to class-map.
Any help will be much appreciated.
Thanks in advance
Regards
Aseem.
08-14-2019 02:25 AM
It doesn't work!
ipv4 access-list Deny-Upload deny ip host x.170.113.50 any ! class-map match-any Deny-Upload match access-group ipv4 Deny-Upload ! policy-map QOS-UPLOAD class Deny-Upload set qos-group 0 !
interface TenGigE0/0/2/1.32 service-policy input QOS-UPLOAD !!% 'km' detected the 'warning' condition 'Deny ace not supported in access-list'
How should I do?
Thank you very much.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide