Link to home
Start Free TrialLog in
Avatar of wfgllc
wfgllc

asked on

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?
SOLUTION
Avatar of xDUCKx
xDUCKx

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of wfgllc
wfgllc

ASKER

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
Avatar of Steve Smith
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
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of wfgllc

ASKER

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!