• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 689
  • Last Modified:

Network Overload

I work for a bank with 2 buildings, connected with Cisco 1900 routers and talking via a Cisco ASA VPN riding over a DSL connection.  One branch has four employees, six workstations, one windows 2003 domain controller and the main building has about 30 employees, a variety of servers, workstations and networked printers.

We have various problems that I like to attribute mostly to latency.  If I do a continuous ping to our B2B partner, most responses are fast, some are 100-700 ms.  Meanwhile, other applications work, but slowly.  The speeds are inconsistent, sometimes fast, and sometimes slow.

All http traffic rides the VPN from branch to main and then out to the Internet, as does the B2B traffic (basically a telnet session).

Major changes include adding the ATMs to the network, using an online backup service, WSUS, Symantec Endpoint and the bank image software.

I contend the culmination of the changes is saturating the DSL pipe on the VPN.  The end users often complain about things being slow, stuff not working, etc.  However, the problems are intermittent.

So, here’s the question:
How can I inexpensively monitor the network from a speed perspective, without using the ASA – I’m not conversant enough in Cisco IOS.  If you were to try to prove my point (about the DSL being saturated) then how would you go about it?  The DSL is showing 640K up speed and 3Mbps down, but the provider only promises 70% of those rates.  This is a rural area, so no other networking options are available, save installing a second DSL line and perhaps dividing the traffic (http on one, VPN on another).

Any suggestions?
0
wfgllc
Asked:
wfgllc
2 Solutions
 
xDUCKxCommented:
MRTG will provide some pretty graphs that you can review over some time to see when your peaks and lulls are.  

http://oss.oetiker.ch/mrtg/

It's SNMP based so you won't need to install anything on your egress/ingress points.  Just allow SNMP polling from the IP Address of the monitoring machine.

Have you configured the Antivirus to update after hours?  Usually this clogs up the pipe first thing in the morning when people boot up their computers.  If the machine is off during the update then it will do the update when it's turned on (while everyone is trying to browse gmail and CNN for the latest news  :-)
0
 
wfgllcAuthor Commented:
Thanks, I'll take a look.

In the meantime, here's one ASA stats.  See any anomalies?

---# sho int
Interface Ethernet0/0 "outside", is up, line protocol is up
  Hardware is i82546GB rev03, BW 100 Mbps
        Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
        MAC address 001a.2f94.4a16, MTU 1500
        IP address xxxxx, subnet mask 255.255.255.248
        121571597 packets input, 101630779809 bytes, 0 no buffer
        Received 1815972 broadcasts, 0 runts, 0 giants
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 L2 decode drops
        115259993 packets output, 61732371284 bytes, 0 underruns
        0 output errors, 0 collisions, 0 interface resets
        0 babbles, 0 late collisions, 0 deferred
        0 lost carrier, 0 no carrier
        input queue (curr/max blocks): hardware (0/0) software (0/0)
        output queue (curr/max blocks): hardware (0/26) software (0/0)
  Traffic Statistics for "outside":
        121571588 packets input, 99323313841 bytes
        115259993 packets output, 59410428380 bytes
        1056652 packets dropped
      1 minute input rate 50 pkts/sec,  3033 bytes/sec
      1 minute output rate 63 pkts/sec,  71522 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 50 pkts/sec,  2996 bytes/sec
      5 minute output rate 61 pkts/sec,  71265 bytes/sec
      5 minute drop rate, 0 pkts/sec
Interface Ethernet0/1 "inside", is up, line protocol is up
  Hardware is i82546GB rev03, BW 100 Mbps
        Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
        MAC address 001a.2f94.4a17, MTU 1500
        IP address 172.31.255.1, subnet mask 255.255.255.252
        117984865 packets input, 61280629580 bytes, 0 no buffer
        Received 2467129 broadcasts, 0 runts, 0 giants
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 L2 decode drops
        118979860 packets output, 99953163300 bytes, 0 underruns
        0 output errors, 0 collisions, 0 interface resets
        0 babbles, 0 late collisions, 0 deferred
        0 lost carrier, 0 no carrier
        input queue (curr/max blocks): hardware (0/0) software (0/0)
        output queue (curr/max blocks): hardware (0/63) software (0/0)
  Traffic Statistics for "inside":
        117825001 packets input, 58855478967 bytes
        118979860 packets output, 97608003033 bytes
        732908 packets dropped
      1 minute input rate 68 pkts/sec,  68832 bytes/sec
      1 minute output rate 53 pkts/sec,  2810 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 61 pkts/sec,  71049 bytes/sec
      5 minute output rate 49 pkts/sec,  2608 bytes/sec
      5 minute drop rate, 0 pkts/sec
Interface Ethernet0/2 "fdatm", is down, line protocol is down
 
Interface Ethernet0/3 "", is administratively down, line protocol is down
 
Interface Management0/0 "management", is down, line protocol is down
0
 
SteveIT ManagerCommented:
Have you considered a bandwidth analyser like solarwinds ? - http://rdsrc.us/QtXj51

Have you tried moving the online backup service and WSUS to update out of hours for a few days as a test and try to isolate the root cause.

If you do find it is the bandwidth there's always the option of Etherstream, SDSL or fibre to give you that extra bandwidth
0
 
iconnectuCommented:
I would try to monitor the traffic with PRTG from Paessler (Free Version available) and check the WAN Port Usage with an SNMP Bandwith Sensor. This give you an overview of the WAN Usage.

The next Would be a Ping Jitter. This give you an overview to the VPN and DSL quality. Point to an Device/Serve in the branch. When you have a high packet lost or ping latency when you have high traffic, this is normal. but when you have high packet lost by low WAN usage, then check the DSL connection.

Next, 640/3k is not that high. I mean, you push updates, Mail, Files, AV-Updates, Profiles (?) and all the webtraffic to this tiny small internet connection!

Try to increase Internetspeed. If not possible, change the local branch setup. Use the local Server as local WSUS to shrink the update speed over WAN. Use an other AV Software, who only one Computer download the update and share it to the other computer, etc.
0
 
wfgllcAuthor Commented:
All good suggestions, many are already in place (av updates, wsus after hours, etc).  PRTG looks like a viable solution and I've already found some things needing attention.  Thanks, experts!
0
Tackle projects and never again get stuck behind a technical roadblock.
Join Now