Re: OT: When to upgrade bandwidth?

I do not recommend doing this in production or at least not in the middle of
the day, but i would take a look at the following to see if you could do
better than the default 'Queueing strategy: weighted fair'

i would also run that int s0/0 cli output through the cisco support output
interpreter, and double check what they have to say about those input
errors....

interface Serial0/0
 ip address 1.1.1.2 255.255.255.0
 ip nbar protocol-discovery
 auto discovery qos

R1#sh auto discovery qos
Serial0/0
 AutoQoS Discovery enabled for applications
 Discovery up time: 7 minutes, 57 seconds
 AutoQoS Class information:
 Class Voice:
  No data found.
 Class Interactive Video:
  No data found.
 Class Signaling:
  No data found.
 Class Streaming Video:
  No data found.
 Class Transactional:
  Recommended Minimum Bandwidth: 0 Kbps/0% (AverageRate)
  Detected applications and data:
  Application/ AverageRate PeakRate Total
  Protocol (kbps/%) (kbps/%) (bytes)
  ----------- ----------- -------- ------------
  telnet 0/0 0/0 1013
 Class Bulk:
  No data found.
 Class Scavenger:
  No data found.
 Class Management:
  No data found.
 Class Routing:
  Recommended Minimum Bandwidth: 10 Kbps/<1% (AverageRate)
  Detected applications and data:
  Application/ AverageRate PeakRate Total
  Protocol (kbps/%) (kbps/%) (bytes)
  ----------- ----------- -------- ------------
  icmp 10/<1 249/16 624968
  ospf 0/0 0/0 4320
 Class Best Effort:
  No data found.
Suggested AutoQoS Policy for the current uptime:
 !
 class-map match-any AutoQoS-Routing-Se0/0
  match protocol icmp
  match protocol ospf
 !
 policy-map AutoQoS-Policy-Se0/0
  class AutoQoS-Routing-Se0/0
   bandwidth remaining percent 1
   set dscp cs6
  class class-default
   fair-queue
R1#sh run int s0/0
Building configuration...
Current configuration : 148 bytes
!
interface Serial0/0
 ip address 1.1.1.2 255.255.255.0
 ip nbar protocol-discovery
 ip ospf 1 area 0
 auto discovery qos
 clock rate 2000000
end

R1#sh ip nbar protocol-discovery stats bit-rate top-n 10
% NBAR Warning: Protocol-Discovery statistic collection was started by 'auto
discovery'
 Serial0/0
                            Input Output
                            ----- ------
   Protocol 5min Bit Rate (bps) 5min Bit Rate (bps)
   ------------------------ ------------------------
------------------------
   icmp 170000 96000
   ospf 0 0
   telnet 0 0
   rtp-other 0 0
   rtp-audio 0 0
   rtp-video 0 0
   bgp 0 0
   citrix 0 0
   cuseeme 0 0
   custom-01 0 0
   unknown 0 0
   Total 170000 96000

interface Serial0/0
 ip address 1.1.1.2 255.255.255.0
 ip nbar protocol-discovery
 ip ospf 1 area 0
 auto discovery qos
 clock rate 2000000
 service-policy output AutoQoS-Policy-Se0/0
end

R1#sh int s0/0
Serial0/0 is up, line protocol is up
  Hardware is GT96K Serial
  Internet address is 1.1.1.2/24
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 26/255, rxload 26/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations 0/1/256 (active/max active/max total)
     Reserved Conversations 1/1 (allocated/max allocated)
     Available Bandwidth 1158 kilobits/sec
  5 minute input rate 158000 bits/sec, 21 packets/sec
  5 minute output rate 159000 bits/sec, 21 packets/sec
     5341 packets input, 7701194 bytes, 0 no buffer
     Received 80 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     5340 packets output, 7699878 bytes, 0 underruns
     0 output errors, 0 collisions, 7 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up DSR=up DTR=up RTS=up CTS=up

On Wed, Oct 7, 2009 at 7:39 PM, Haroon <itguy.pro_at_gmail.com> wrote:

> Hi Garry,
>
> Thanks for the reply. Most of the traffic is email (exchange server,
> webmail), http, VPN tunnels, microsoft-ds (active dirctory) so all of it is
> needed. Slow means the users complain... The connection is fast (t1
> connection speeds) when there is little or no traffic. Here is output from
> the show interface on serial on a 2821:
>
> Serial0/2/0 is up, line protocol is up
> Hardware is GT96K with integrated T1 CSU/DSU
> Internet address is 12.12.12.12/30
> MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
> * reliability 255/255, txload 65/255, rxload 183/255
> * Encapsulation PPP, LCP Open
> Listen: CDPCP
> Open: IPCP, loopback not set
> Keepalive set (10 sec)
> Last input 00:00:13, output 00:00:09, output hang never
> Last clearing of "show interface" counters 14w2d
> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:
> 103131
> Queueing strategy: weighted fair
> Output queue: 0/1000/64/99613 (size/max total/threshold/drops)
> Conversations 0/64/256 (active/max active/max total)
> Reserved Conversations 0/0 (allocated/max allocated)
> Available Bandwidth 1158 kilobits/sec
> 5 minute input rate 1111000 bits/sec, 189 packets/sec
> 5 minute output rate 394000 bits/sec, 167 packets/sec
> 454757217 packets input, 3768278802 bytes, 0 no buffer
> Received 0 broadcasts, 0 runts, 301 giants, 0 throttles
> * 280932 input errors, 280932 CRC, 134763 frame, 88871 overrun, 0
> ignored, 121798 abort
> 428469700 packets output, 315029173 bytes, 0 underruns*
> 0 output errors, 0 collisions, 186 interface resets
> 0 output buffer failures, 0 output buffers swapped out
> 304 carrier transitions
> DCD=up DSR=up DTR=up RTS=up CTS=up
>
>
> What concerns me is the input and CRC errors... I've had the line tested
> couple of times and there are no issues with it so it must be
> receiving/sending more traffic than the connection allows? Also, when I
> download something from remote sites or even from the internet, the *
> reliability* figures spike up, never seen that happening on a T1.
>
> Thanks,
>
> Haroon
>
> On Wed, Oct 7, 2009 at 12:12 PM, garry baker <baker.garry_at_gmail.com>wrote:
>
>> do you have any methods of QoS on these links?
>>
>> which specific applications are slow? and does slow mean they do not work
>> or do users complain?
>>
>> What traffic is causing these 95th % spikes and for how long are they
>> sustained? Can you get rid of this traffic? Or police down so the other
>> 'mission critical' traffic can utilize these spikes of bandwidth?
>>
>> if you have the money to spend why not more bandwidth is never a bad
>> thing, but not always the correct answer either...
>>
>> you say the connection is 'slow' to the Internet, is it fast when your
>> monitoring tools say there is no traffic on your T1 or is this a contention
>> ratio issue with your ISP to the "Internet"?
>>
>> HTH,
>>
>> thanks..
>> garry..
>>
>> On Wed, Oct 7, 2009 at 6:23 PM, Haroon <itguy.pro_at_gmail.com> wrote:
>>
>>> Hi Experts,
>>>
>>> Is there a golden rule as to when an organization should do bandwidth
>>> upgrade? We have a few T1s that we use for different purposes and on one
>>> of
>>> them I have seen increased utilization and often the connection is slow
>>> (to
>>> the internet). I am using netflow, Netflow analyzer Pro to collect the
>>> data.
>>>
>>> How many "Ws" should I see in the graphs consistently before considering
>>> bandwidth upgrade or move certain services to another T1? How many spikes
>>> into the 95th percentile utilization should there be per day, week,
>>> month?
>>>
>>> We have 4 (maybe more later) site to site VPNs (to a concentrator) for
>>> our
>>> remote locations, about 100 employees all together.
>>>
>>> I personally, would like to move the VPNs, etc. to a dedicated T1.
>>>
>>> Thanks,
>>>
>>> Haroon
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Garry L. Baker
>>
>> "There is no 'patch' for stupidity." - www.sqlsecurity.com
>>
>
>

-- 
Garry L. Baker
"There is no 'patch' for stupidity." - www.sqlsecurity.com
Blogs and organic groups at http://www.ccie.net