|
midrange.com
What I did this morning is:
Plugged a laptop into the DMZ and configured it for an IP within that
scheme. I then performed the same file copies I had before and the same
set of FTPs that I did before and saw 'reverse' results. When I copied
from/FTP'd to DMZ servers while plugged into the DMZ things were quick,
and when I copied from/FTP'd to INSIDE servers while plugged into the DMZ
things were slow. Then from my PC, which is plugged into the inside, I
could copy from/FTP to inside servers quickly and DMZ servers slowly. The
websphere install that triggered this whole project works quickly now while
plugged into the DMZ from that laptop (still was slow when the hub was
there instead of the current switch, so at least i've made some progress);
it is still a slow install when done from the inside. It looks like it's
pretty PIX-centric to me at this point... I'm going to call Cisco and see
if I can get some direction on how to proceed with narrowing the problem
down from here...
Larry Bolhuis
<lbolhuis@arbsol.
com> To
Sent by: Midrange Systems Technical
midrange-l-bounce Discussion
s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx>
cc
11/29/2005 01:39 Subject
PM Re: FTP and file transfer speeds
Please respond to
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>
Well the numbers aren't as low as I'd like to see but this quantity of
errors over this time period isn't going to drop speeds by the amount
your statistics shown. It might hurt by a few percentage points at
worst. So now you need to find a new place to look, perhaps one of the
servers on the DMZ that you are taking to. Can you FTP between servers
in the DMZ and test speed there? That would test those servers
connection to the switch there and eliminate that as a problem. Make
sure you push data both in and out of the target server just to be sure.
- Larry
ChadB@xxxxxxxxxxxxxxxxxxxx wrote:
> Ok... update time... here are the interface stats on the PIX from this
> morning since clearing them yesterday... i'm seeing the input errors more
> on the inside interface than the DMZ... should I be suspecting that
> instead? I still see some runts on the DMZ also, though...
>
> Result of firewall command: "show interface"
>
> interface ethernet0 "outside" is up, line protocol is up
> Hardware is i82559 ethernet, address is 0005.328f.cf66
> IP address 12.161.209.241, subnet mask 255.255.255.248
> MTU 1500 bytes, BW 100000 Kbit full duplex
> 253378 packets input, 184274615 bytes, 0 no buffer
> Received 112 broadcasts, 0 runts, 0 giants
> 151 input errors, 97 CRC, 54 frame, 0 overrun, 97 ignored, 0 abort
> 231092 packets output, 69124183 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 (128/128) software (0/5)
> output queue (curr/max blocks): hardware (0/37) software (0/4)
> interface ethernet1 "inside" is up, line protocol is up
> Hardware is i82559 ethernet, address is 0005.328f.cf67
> IP address 172.17.1.25, subnet mask 255.255.0.0
> MTU 1500 bytes, BW 100000 Kbit full duplex
> 559103 packets input, 117982246 bytes, 0 no buffer
> Received 99499 broadcasts, 1048 runts, 0 giants
> 1875 input errors, 955 CRC, 920 frame, 0 overrun, 955 ignored, 0
> abort
> 617775 packets output, 427740103 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 (128/128) software (0/38)
> output queue (curr/max blocks): hardware (1/35) software (0/4)
> interface ethernet2 "dmz" is up, line protocol is up
> Hardware is i82559 ethernet, address is 0002.b33d.3be0
> IP address 172.18.1.25, subnet mask 255.255.255.0
> MTU 1500 bytes, BW 100000 Kbit full duplex
> 453436 packets input, 284576767 bytes, 0 no buffer
> Received 3269 broadcasts, 679 runts, 0 giants
> 27 input errors, 15 CRC, 12 frame, 0 overrun, 15 ignored, 0 abort
> 333512 packets output, 94196932 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 (128/128) software (0/12)
> output queue (curr/max blocks): hardware (0/8) software (0/2)
> interface ethernet3 "dmz1" is up, line protocol is up
> Hardware is i82558 ethernet, address is 00e0.b604.f78b
> IP address 10.0.0.25, subnet mask 255.255.255.0
> MTU 1500 bytes, BW 100000 Kbit full duplex
> 98743 packets input, 26035505 bytes, 0 no buffer
> Received 90331 broadcasts, 0 runts, 0 giants
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> 8236 packets output, 513548 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 (128/128) software (0/2)
> output queue (curr/max blocks): hardware (0/1) software (0/1)
> interface ethernet4 "dmz2" is up, line protocol is up
> Hardware is i82558 ethernet, address is 00e0.b604.f78a
> IP address 172.19.1.25, subnet mask 255.255.255.0
> MTU 1500 bytes, BW 100000 Kbit full duplex
> 3380 packets input, 226451 bytes, 0 no buffer
> Received 381 broadcasts, 0 runts, 0 giants
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> 10641 packets output, 838371 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 (128/128) software (0/1)
> output queue (curr/max blocks): hardware (0/3) software (0/1)
> interface ethernet5 "intf5" is up, line protocol is up
> Hardware is i82558 ethernet, address is 00e0.b604.f789
> IP address 172.11.1.25, subnet mask 255.255.255.0
> MTU 1500 bytes, BW 100000 Kbit full duplex
> 7732 packets input, 463920 bytes, 0 no buffer
> Received 0 broadcasts, 0 runts, 0 giants
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> 7712 packets output, 462720 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 (128/128) software (0/1)
> output queue (curr/max blocks): hardware (0/1) software (0/1)
>
>
>
--
Larry Bolhuis IBM eServer Certified Systems Expert:
Vice President iSeries Technical Solutions V5R3
Arbor Solutions, Inc. iSeries LPAR Technical Solutions V5R3
1345 Monroe NW Suite 259 iSeries Linux Technical Solutions V5R3
Grand Rapids, MI 49505 iSeries Windows Integration Technical
Solutions V5R3
IBM eServer Certified Systems Specialist
(616) 451-2500 iSeries System Administrator for
OS/400 V5R3
(616) 451-2571 - Fax AS/400 RPG IV Developer
(616) 260-4746 - Cell iSeries System Command Operations V5R2
If you can read this, thank a teacher....and since it's in English,
thank a soldier.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by MessageLabs.
For more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
ForwardSourceID:NT00033802
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by MessageLabs. For
more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
