Question about the Shape Average command on a Cisco 3825

[MATTHEW SNYDERMAN]

We recently upgraded our ISP bandwidth from 150 Mbs to 300 Mbs.    The issue that I'm having is that I made the following changes and I'm not seeing the increase in bandwidth.

Changes:

policy-map Outbound
class class-default
shape average 300000000

interface GigabitEthernet0/1
bandwidth 300000

I was told by a TAC engineer that I did not need to Shutdown the interface to make the bandwidth changes.   

Do I need to Shutdown / No Shutdown on the interface for the changes to the policy-map to take effect?

__________________________________________________________________________________________________________

We HAD the following configuration on our external interface:

class-map match-any NonInteractive
  match access-group name SQLRep 
  match access-group name FTPout
class-map match-any Management
  match access-group name Realtime-Mgmt
class-map match-any Interactive
  match access-group name App-Traffic
!
!
policy-map Outbound-Child
  class Interactive
    bandwidth 15000
    random-detect
  class NonInteractive
    bandwidth 3500
    random-detect
  class Management
    bandwidth 512
  class class-default
    fair-queue 16
    random-detect
policy-map Outbound
  class class-default
    shape average 150000000
    service-policy Outbound-Child

interface GigabitEthernet0/1
bandwidth 150000
ip address XXX.XXX.XXX.XXX 255.255.255.248
ip access-group 105 in
ip access-group 110 out
ip route-cache flow
duplex full
speed 1000
media-type rj45
max-reserved-bandwidth 90
service-policy output Outbound

________________________________________________________________________________________________

We NOW HAVE the following configuration on our external interface:

class-map match-any NonInteractive
  match access-group name SQLRep
  match access-group name FTPout
class-map match-any Management
  match access-group name Realtime-Mgmt
class-map match-any Interactive
  match access-group name CostGuard
!
!
policy-map Outbound-Child
  class Interactive
    bandwidth 30000
    random-detect
  class NonInteractive
   bandwidth 3500
   random-detect
  class Management
   bandwidth 512
  class class-default
   fair-queue 16
   random-detect
policy-map Outbound
  class class-default
   shape average 300000000
   service-policy Outbound-Child
!
buffers small permanent 65
buffers small max-free 92
buffers small min-free 19
buffers middle permanent 44
buffers middle max-free 63
buffers middle min-free 13
buffers big permanent 65
buffers big max-free 92
buffers big min-free 19
!
!
!
interface GigabitEthernet0/1
bandwidth 300000
ip address XXX.XXX.XXX.XXX 255.255.255.248
ip access-group 105 in
ip access-group 110 out
ip route-cache flow
duplex full
speed 1000
media-type rj45
max-reserved-bandwidth 90
service-policy output Outbound

[Georg Pauwen]

Hello,

the QoS policy looks good actually. How do you know it is not working, are packets getting dropped ?

Post the output of 'show service-policy interface GigabitEthernet0/1...

[MATTHEW SNYDERMAN]

I was seeing packet drops.

I have removed the command "service-policy output Outbound" from the interface eliminate the QOS as a possible slow down.  I am still seeing the issue.

[Julio E. Moisa]

Hi

The service policy has been removed, can you also remove max-reserved-bandwidth 90 and verify if the problem persists. 

[Joseph W. Doherty]

Removing your egress service policy removes the policy itself as a slowdown factor but without it, you may be bumping into the CIR limits and having drops there.  Of course, as I noted, if the shaper doesn't account for L2, you prior policy might have still allowed drops due to provider's CIR limit.

That noted, your posted stats show a very, very low drop count for class default, so low, it would seem unlikely your QoS policy was/is the problem.

The quickest way to often tell whether your CIR is correctly set (as it might not be, as suggested by Georg) is to use a traffic generator that doesn't depend on TCP and see if you can push your CIR rate across the link.

[Julio E. Moisa]

Hi

No, you don't need to reset the interface.  Have you made a speed test from the device receiving the Internet access? you could use WAN killer tool by Solarwinds. 

[MATTHEW SNYDERMAN]

I currently have a data transfer between our 2 data centers which takes about 10 hours to complete.

The Data Center #2 had a 100 Mbs pipe.  When we increased the pipe of Data Center #2 to 200 Mbs we immediately saw our data transfer from jump from 100 Mbs to 150 Mbs.  

Per our plan, 2 days later we increased Data Center #1 pipe from 150 Mbs to 300 Mbs. Using our monitoring tools the data transfer is still taking 10 hours and is maxing out at 150 Mbs

[Georg Pauwen]

Actually, and I don't know exactly what monitoring tool you use, if you can see that you are maxing out at 150MB, the most likely reason is that your ISP did not increase the pipe...

[Joseph W. Doherty]

Well, when your working with high bandwidth WAN links, two issues that come into play are hosts that don't have newer TCP stacks that support the needed RWIN sizes and/or or drops causing the flow to go into congestion avoidance.

As to your policy, the only issue you might have with the shaper is I believe on most Cisco platforms a shaper (or policer) only accounts for L3, but providers generally enforce CIR at L2.  If that's your situation, you need to shape about 15% slower to allow for average L2 overhead.

Unless you running earlier than 12.4(20)T, you don't need the max-reserved-bandwidth statement.

Unless you are a QoS expert, I advise against using random-detect.

If you IOS supports it, and you see drops within your policy, you many need to increase class queue depths to better support the BDP.

Also if your IOS supports it, you might try the "buffers tune automatic" global config command.