|
Larry (and others who are interested), From what I can see here, it looks like the PIX interfaces are all set to 100/full (output of command is below). As far as the switch, it is a Netgear FS116 and only seems to work in an auto/auto mode (can't see a way to configure it specifically to 100/full). The connection lights for those ports on the Netgear switch are showing 100/full. Here are some stats i've done showing network retransmits from the 3 involved iSeries boxes before/after the hub was changed for the switch. I can see the retransmit ratio getting better for those interfaces, but the transfer speed didn't change much. The box WNDEV has 2 physical interfaces (one cabled to inside and one cabled to DMZ). The box WNDOM has 1 physical interface cabled to DMZ. The box WNPRD has 1 interface cabled to inside. Result of firewall command: "show interface" interface ethernet0 "outside" is up, line protocol is up Hardware is i82559 ethernet, address is 0005.328f.x IP address 12.161.x.x, subnet mask 255.255.255.248 MTU 1500 bytes, BW 100000 Kbit full duplex 257830633 packets input, 3481748998 bytes, 0 no buffer Received 10727302 broadcasts, 10238 runts, 0 giants 192051 input errors, 113204 CRC, 78847 frame, 0 overrun, 113204 ignored, 0 abort 219796012 packets output, 1387854806 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/70) output queue (curr/max blocks): hardware (0/45) software (0/17) interface ethernet1 "inside" is up, line protocol is up Hardware is i82559 ethernet, address is 0005.328f.x IP address 172.17.x.x, subnet mask 255.255.0.0 MTU 1500 bytes, BW 100000 Kbit full duplex 558330048 packets input, 1650087330 bytes, 0 no buffer Received 181380202 broadcasts, 716718 runts, 0 giants 595743 input errors, 302545 CRC, 291521 frame, 1677 overrun, 302545 ignored, 0 abort 577468214 packets output, 2424312736 bytes, 0 underruns 0 output errors, 0 collisions, 13 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/330) output queue (curr/max blocks): hardware (1/128) software (0/537) interface ethernet2 "dmz" is up, line protocol is up Hardware is i82559 ethernet, address is 0002.b33d.x IP address 172.18.x.x, subnet mask 255.255.255.0 MTU 1500 bytes, BW 100000 Kbit full duplex 398647963 packets input, 120745786 bytes, 0 no buffer Received 2900311 broadcasts, 124672 runts, 0 giants 3198558 input errors, 695102 CRC, 2502959 frame, 497 overrun, 695102 ignored, 0 abort 317963270 packets output, 974904398 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/377) output queue (curr/max blocks): hardware (0/128) software (0/303) interface ethernet3 "dmz1" is up, line protocol is up Hardware is i82558 ethernet, address is 00e0.b604.x IP address 10.0.x.x, subnet mask 255.255.255.0 MTU 1500 bytes, BW 100000 Kbit full duplex 78759761 packets input, 1519081523 bytes, 0 no buffer Received 156705285 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 6132878 packets output, 730480310 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/22) output queue (curr/max blocks): hardware (0/10) software (0/9) interface ethernet4 "dmz2" is up, line protocol is up Hardware is i82558 ethernet, address is 00e0.b604.x IP address 172.19.x.x, subnet mask 255.255.255.0 MTU 1500 bytes, BW 100000 Kbit full duplex 8454888 packets input, 728345841 bytes, 0 no buffer Received 6204530 broadcasts, 120008 runts, 0 giants 67640 input errors, 25078 CRC, 23784 frame, 18778 overrun, 25078 ignored, 0 abort 7973022 packets output, 748012416 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/473) output queue (curr/max blocks): hardware (0/128) software (0/44) interface ethernet5 "intf5" is up, line protocol is up Hardware is i82558 ethernet, address is 00e0.b604.x IP address 172.11.x.x, subnet mask 255.255.255.0 MTU 1500 bytes, BW 100000 Kbit full duplex 5438592 packets input, 599491324 bytes, 0 no buffer Received 4 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 5424854 packets output, 598159968 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/10) output queue (curr/max blocks): hardware (0/10) software (0/9) Larry Bolhuis <lbolhuis@arbsol. com> To Sent by: Midrange Systems Technical midrange-l-bounce Discussion s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx> cc 11/28/2005 12:53 Subject PM Re: FTP and file transfer speeds Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> Chad, Clearly you are correct in moving to a switch rather than hub environment. Setting the iSeries line description to 100Mbps and Full Duplex are also important. I don't think you have an issue on the connection from the iSeries to the inside network because 9900+ Mpbs is fairly close to full network utilization (12000KBps translates roughly to 100Mbps) You won't get anywhere close to that if the connection is poor. I would still verify that the switch port is also set to 100Mpbs and Full duplex rather than AUTO and AUTO, especially with Cisco or Dell switches. Also verify the current speed and duplex match to the iSeries. Now the PIX itself will transfer at wire speed but it too can have problems with speed and duplex. So on the Pix do to SHOW INTERFACE and observe the reported speed and duplex for the various interfaces. Then do the same on the switches and observe the ports the PIX is connected to. I have found that even with Cisco switches the dadgum PIX gets it wrong. Usually the speed is correct at 100Mpbs but the duplex on the PIX shows one thing and the switch shows the other. This of course will drag bandwidth down dramatically. Of course it makes sense to verify the speed and duplex of the target server and it's switch port as well. I'll bet you find a mismatch in there someplace and correcting it will bring speeds to the DMZ to within 10% of the inside network. - Larry ChadB@xxxxxxxxxxxxxxxxxxxx wrote: > Hello all... i'm working on an file transfer speed issue we first noticed > while installing some apps to various iSeries boxes on our network that are > plugged in to various locations/firewall zones. Through some more detailed > testing, here's what i'm finding. Originally, the 'slow' interfaces were > plugged in to a 100/half hub that provides connectivity to our DMZ zone on > our Pix 515. I've since replaced that hub with a 100/full switch and > reconfigured the *LINDs to the new speed/duplex. Some retransmits on the > various interfaces I was tracking are looking better since the change (2% > now on the DMZ boxes rather than 4% with the hub), but the file transfers > are still showing the 'SLOW' behavior. > > I'm now wondering if this is more of a firewall issue than a > hardware/config issue... is file transfer throughput between different > firewall zones impacted this much by a PIX? > > Any advice will be appreciated... details are below: > > > With 100/Full switch in place for DMZ connections: > |-----------------+-----------------+-----------------+-----------------| > |IP Address |Firewall |Time to FTP |Throughput | > | |Zone/Hub/Switch |(seconds) |(Kbytes/second) | > |-----------------+-----------------+-----------------+-----------------| > |a.a.a.a |Inside |.95 |7000.15 | > |-----------------+-----------------+-----------------+-----------------| > |b.b.b.b |DMZ |34.34 |194.26 | > |-----------------+-----------------+-----------------+-----------------| > |c.c.c.c |DMZ |19.23 |346.84 | > |-----------------+-----------------+-----------------+-----------------| > |d.d.d.d |Inside |3.55 |1880.78 | > |-----------------+-----------------+-----------------+-----------------| > |e.e.e.e |DMZ |18.63 |358.18 | > |-----------------+-----------------+-----------------+-----------------| > | | | | | > |-----------------+-----------------+-----------------+-----------------| > > > > > With 100/Half hub in place for DMZ connections: > |-----------------+-----------------+-----------------+-----------------| > | IP Address | Firewall | Time to FTP | Throughput | > | | Zone/Hub/Switch | (seconds) | (Kbytes/second) | > |-----------------+-----------------+-----------------+-----------------| > | a.a.a.a | Inside | .67 | 9927.29 | > |-----------------+-----------------+-----------------+-----------------| > | b.b.b.b | DMZ | 13.56 | 491.86 | > |-----------------+-----------------+-----------------+-----------------| > | c.c.c.c | DMZ | 32.49 | 205.35 | > |-----------------+-----------------+-----------------+-----------------| > | d.d.d.d | Inside | 2.28 | 2924.66 | > |-----------------+-----------------+-----------------+-----------------| > | e.e.e.e | DMZ | 23.25 | 286.92 | > |-----------------+-----------------+-----------------+-----------------| > -- 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:NT000335FA _____________________________________________________________________________ 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.