cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
127
Views
0
Helpful
2
Replies
Highlighted
Beginner

QoS does not seem to be wokring

This is what I have configured on my Router at head office (only relevant information). 

class-map match-any EXCHANGE
 match access-group 102
class-map match-any SCCM
 match access-group name SCCMRules
!
!
policy-map LimitTraffic
 class EXCHANGE
  shape peak 8000
!

interface GigabitEthernet0/0
 description ***LAN***
 ip address 172.16.4.21 255.255.252.0
 service-policy output LimitTraffic

access-list 102 permit ip host 172.16.4.30 172.16.108.0 0.0.3.255

When I do show policy-map int gi0/0 I show no results for this:

 

show policy-map int gi0/0
 GigabitEthernet0/0

  Service-policy output: LimitTraffic

    Class-map: EXCHANGE (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 102
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
      shape (peak) cir 8000, bc 32, be 32
      target shape rate 16000

    Class-map: class-default (match-any)
      661219 packets, 364005586 bytes
      5 minute offered rate 3405000 bps, drop rate 0 bps
      Match: any

      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 661219/362197011

I know that there is traffic going from 172.16.4.30 to that network, this is our mail server and everyone is running a mail client. Am I missing something? 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Hall of Fame Guru

Your acl matches the source IP of 172.16.4.30 and the destination subnet of 172.16.108.0 0.0.3.255.

If you apply it to the 172.16.4.x interface as an outbound policy which you have then the acl is the wrong way round ie. the source IPs would be 172.16.108.x.

If your policy was applied inbound to the 172.16.4.x interface then the source IP would indeed be 172.16.4.30.

So either your policy is applied the wrong way round or your acl is written the wrong way round.

Jon

View solution in original post

2 REPLIES 2
Highlighted
Hall of Fame Guru

Your acl matches the source IP of 172.16.4.30 and the destination subnet of 172.16.108.0 0.0.3.255.

If you apply it to the 172.16.4.x interface as an outbound policy which you have then the acl is the wrong way round ie. the source IPs would be 172.16.108.x.

If your policy was applied inbound to the 172.16.4.x interface then the source IP would indeed be 172.16.4.30.

So either your policy is applied the wrong way round or your acl is written the wrong way round.

Jon

View solution in original post

Highlighted

Thanks for the comment. I realized that I had the outbound policy set to the wrong interface. I added it to my WAN interface and it started working.

Thanks

Content for Community-Ad