Hello Tom,
I am not sure if you can help with this but I am at my wits end.
If you hit this site and do a force refresh (ctrl + F5) the site will time
out
and lose connections.
Do the same on port 443 and it does not time out???
The web site I am reffering to is www.tituswill.com
I think the only problem is port 80.
Do you have any idea how to diagnose this I have sent a dump
of just the traffic between me and the troubled host with the following
command
tcpdump -nevv host 64.42.53.203 and \( 66.224.62.100 \)
I hate to bother you today but I can not leave this Dmz Host
up very long like this.
Thank you,
Mike
701 packets received by filter
269 packets dropped by kernel
[root@ns1 root]# /sbin/shorewall status > /tmp/status.txt
[root@ns1 root]# uname -r
2.4.22-1.2115.nptl
[root@ns1 root]# shorewall version
2.0.2c
[root@ns1 root]# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
5: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:04:e2:18:93:1b brd ff:ff:ff:ff:ff:ff
inet 10.19.227.20/24 brd 10.19.227.255 scope global eth1
6: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:04:e2:1c:f5:db brd ff:ff:ff:ff:ff:ff
inet 64.42.53.202/29 brd 64.42.53.207 scope global eth0
7: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 brd 192.168.100.255 scope global eth2
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1405 qdisc pfifo_fast qlen
10
link/ppp
inet 172.16.1.1 peer 172.16.1.2/32 scope global tun0
13: ipsec0: <NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 10
link/ether 00:04:e2:1c:f5:db brd ff:ff:ff:ff:ff:ff
inet 64.42.53.202/29 brd 64.42.53.207 scope global ipsec0
14: ipsec1: <NOARP> mtu 0 qdisc noop qlen 10
link/void
15: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10
link/void
16: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10
link/void
[root@ns1 root]# ip route show
172.16.1.2 dev tun0 proto kernel scope link src 172.16.1.1
64.42.53.203 dev eth2 scope link
64.42.53.200/29 dev eth0 scope link
64.42.53.200/29 dev ipsec0 proto kernel scope link src 64.42.53.202
192.168.100.0/24 dev eth2 scope link
10.192.139.0/24 via 64.42.53.201 dev ipsec0
10.201.144.0/24 via 10.19.227.193 dev eth1
10.19.227.0/24 dev eth1 scope link
10.5.198.0/24 via 172.16.1.2 dev tun0
172.30.0.0/16 via 10.19.227.190 dev eth1
127.0.0.0/8 dev lo scope link
default via 64.42.53.201 dev eth0
[root@ns1 root]#
Mike Lander wrote:> Hello Tom, > I am not sure if you can help with this but I am at my wits end. > If you hit this site and do a force refresh (ctrl + F5) the site will > time out > and lose connections. > Do the same on port 443 and it does not time out??? > > The web site I am reffering to is www.tituswill.com > I think the only problem is port 80. > Do you have any idea how to diagnose this I have sent a dump > of just the traffic between me and the troubled host with the following > command > > tcpdump -nevv host 64.42.53.203 and \( 66.224.62.100 \) > > I hate to bother you today but I can not leave this Dmz Host > up very long like this.Before you put it back, take a look at the device status on the dmz interface: ip -s link show dev eth2 I see nothing in the trace that gives a clue (although I prefer that you capture to a file so I can look at it using Ethereal). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> > Before you put it back, take a look at the device status on the dmz > interface: > > ip -s link show dev eth2[root@ns1 root]# ip -s link show dev eth2 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1412 qdisc pfifo_fast qlen 1000 link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 76377859 162493 25 0 0 0 TX: bytes packets errors dropped carrier collsns 40707803 151908 1 0 1 15 [root@ns1 root]#> I see nothing in the trace that gives a clue (although I prefer that you > capture to a file so I can look at it using Ethereal). > > -TomBTW I have been changing eth2 using mii-too trying different settings 10/100 and chaning mtu thats why mtu 1412 Still working on tcpdump to file--------------- Thanks Mike
Mike Lander wrote:> >> >> Before you put it back, take a look at the device status on the dmz >> interface: >> >> ip -s link show dev eth2 > > > [root@ns1 root]# ip -s link show dev eth2 > 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1412 qdisc pfifo_fast qlen 1000 > link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff > RX: bytes packets errors dropped overrun mcast > 76377859 162493 25 0 0 0 > TX: bytes packets errors dropped carrier collsns > 40707803 151908 1 0 1 15 > [root@ns1 root]# > > >> I see nothing in the trace that gives a clue (although I prefer that you >> capture to a file so I can look at it using Ethereal). >> >> -Tom > > > BTW I have been changing eth2 using mii-too trying different settings > 10/100 and > chaning mtu thats why mtu 1412 >I suspect that will give you more problems, not fewer.... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
>> Before you put it back, take a look at the device status on the dmz >> interface: >> >> ip -s link show dev eth2 > > [root@ns1 root]# ip -s link show dev eth2 > 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1412 qdisc pfifo_fast qlen 1000 > link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff > RX: bytes packets errors dropped overrun mcast > 76377859 162493 25 0 0 0 > TX: bytes packets errors dropped carrier collsns > 40707803 151908 1 0 1 15 > [root@ns1 root]# > > >> I see nothing in the trace that gives a clue (although I prefer that you >> capture to a file so I can look at it using Ethereal). >> >> -Tom > > BTW I have been changing eth2 using mii-too trying different settings > 10/100 and > chaning mtu thats why mtu 1412 > Still working on tcpdump to file---------------Here is dump attachment Thank you Mike
> Mike Lander wrote: >> >>> >>> Before you put it back, take a look at the device status on the dmz >>> interface: >>> >>> ip -s link show dev eth2 >> >> >> [root@ns1 root]# ip -s link show dev eth2 >> 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1412 qdisc pfifo_fast qlen 1000 >> link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff >> RX: bytes packets errors dropped overrun mcast >> 76377859 162493 25 0 0 0 >> TX: bytes packets errors dropped carrier collsns >> 40707803 151908 1 0 1 15 >> [root@ns1 root]# >> >> >>> I see nothing in the trace that gives a clue (although I prefer that you >>> capture to a file so I can look at it using Ethereal). >>> >>> -Tom >> >> >> BTW I have been changing eth2 using mii-too trying different settings >> 10/100 and >> chaning mtu thats why mtu 1412 >> > > I suspect that will give you more problems, not fewer.... > > -TomOk I set back to normall [root@ns1 root]# ip -s link show dev eth2 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 80426506 167578 25 0 0 0 TX: bytes packets errors dropped carrier collsns 41362848 156183 1 0 1 15 [root@ns1 root]# Mike
Mike Lander wrote:>>> Before you put it back, take a look at the device status on the dmz >>> interface: >>> >>> ip -s link show dev eth2 >> >> >> [root@ns1 root]# ip -s link show dev eth2 >> 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1412 qdisc pfifo_fast qlen 1000 >> link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff >> RX: bytes packets errors dropped overrun mcast >> 76377859 162493 25 0 0 0 >> TX: bytes packets errors dropped carrier collsns >> 40707803 151908 1 0 1 15 >> [root@ns1 root]# >> >> >>> I see nothing in the trace that gives a clue (although I prefer that you >>> capture to a file so I can look at it using Ethereal). >>> >>> -Tom >> >> >> BTW I have been changing eth2 using mii-too trying different settings >> 10/100 and >> chaning mtu thats why mtu 1412 >> Still working on tcpdump to file--------------- > > > > Here is dump attachment >Please use the "-w" option, Mike -- you are still producing text formatted traces rather than a binary trace that can be analyzed off-line. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> > Please use the "-w" option, Mike -- you are still producing text formatted > traces rather than a binary trace that can be analyzed off-line. > > -TomNot sure of syntax I am using this to reduce file size [root@ns1 root]# tcpdump -nevv -w host 64.42.53.203 and \( 66.224.62.100 \) >/tmp/dump Help Please Mike
Mike Lander wrote:> >> >> Please use the "-w" option, Mike -- you are still producing text >> formatted traces rather than a binary trace that can be analyzed >> off-line. >> >> -Tom > > > Not sure of syntax > > I am using this to reduce file size > [root@ns1 root]# tcpdump -nevv -w host 64.42.53.203 and \( 66.224.62.100 > \) >/tmp/dump >tcpdump -w /tmp/dump -i <interface> host 65.42.53.203 I''ll pick out TCP sessions to follow. The trace file will be large so send it to me personally. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> > > I see nothing in the trace that gives a clue (although I prefer that you > capture to a file so I can look at it using Ethereal). >Mike has forwarded me several capture files which I have looked at with Ethereal. The pattern is that: a) Connection works fine for a bit. b) Client makes a request that is received by the server. c) Server responds -- this requires several packets. d) Delay f) Client acks the sequence number of first reply packet (indicating that it didn''t get that packet). g) server retransmits that packet several times and client may re-ACK. h) Either Mike gave up or eventually the client ACKs the entire sequence of replies (indicating that it only missed the first packet). Why this happens: 1) Only with HTTP; and 2) Only with the server behind the firewall Is a mystery to me. Any ideas guys? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> Tom Eastep wrote: > >> >> >> I see nothing in the trace that gives a clue (although I prefer that you >> capture to a file so I can look at it using Ethereal). >> > > Mike has forwarded me several capture files which I have looked at with > Ethereal. The pattern is that: > > a) Connection works fine for a bit. > b) Client makes a request that is received by the server. > c) Server responds -- this requires several packets. > d) Delay > f) Client acks the sequence number of first reply packet (indicating > that it didn''t get that packet). > g) server retransmits that packet several times and client may re-ACK. > h) Either Mike gave up or eventually the client ACKs the entire sequence > of replies (indicating that it only missed the first packet). > > Why this happens: > > 1) Only with HTTP; and > 2) Only with the server behind the firewall > > Is a mystery to me. Any ideas guys? > > -Tomtransparent proxy failure? -- Jack at Monkeynoodle dot Org: It''s a Scientific Venture... Riding the Emergency Third Rail Power Trip since 1996!
Jack Coates wrote:> >> >> Why this happens: >> >> 1) Only with HTTP; and >> 2) Only with the server behind the firewall >> >> Is a mystery to me. Any ideas guys? >> >> -Tom > > > transparent proxy failure? >I''ve checked Mike''s configuration rather carefully and it looks like only internal clients are proxied transparently and the DMZ server is omitted from proxying. Local clients see good performance from the server and that doesn''t surprise me since the packet traces from the internet interface and from the dmz interface look the same; in other words, it doesn''t look like packets are being lost on the firewall (Mike -- my earlier analysis that suggested that the firewall was dropping ACKs was in error). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom, Mike and others, Tom Eastep said the following on 09-Jan-05 23:28:> Tom Eastep wrote: > >> I see nothing in the trace that gives a clue (although I prefer that you >> capture to a file so I can look at it using Ethereal). >> > Mike has forwarded me several capture files which I have looked at with > Ethereal. The pattern is that: > > a) Connection works fine for a bit. > b) Client makes a request that is received by the server. > c) Server responds -- this requires several packets. > d) Delay > f) Client acks the sequence number of first reply packet (indicating > that it didn''t get that packet). > g) server retransmits that packet several times and client may re-ACK. > h) Either Mike gave up or eventually the client ACKs the entire sequence > of replies (indicating that it only missed the first packet). > > Why this happens: > > 1) Only with HTTP; and > 2) Only with the server behind the firewall > > Is a mystery to me. Any ideas guys?Well one of the things that i find strange is the following: (copied from earlier in the thread) [root@ns1 root]# ip -s link show dev eth2 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1412 qdisc pfifo_fast qlen 1000 link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 76377859 162493 25 0 0 0 TX: bytes packets errors dropped carrier collsns 40707803 151908 1 0 1 15 [root@ns1 root]# Why would an device have 25 rx errors, 1 tx error and only 15 collisions? Even when the device is on a hub, the errors should be identical to the # of collisions. If the device is connected to a switch the # of collisions should be 0. Although I''m on a switched network: [root@hn00sia01:~]# ip -s link show bond0 2: bond0: <BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue link/ether 00:0e:0c:51:b7:74 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 3616683943 214016379 0 0 0 0 TX: bytes packets errors dropped carrier collsns 2799428048 205424512 2 0 2 0 [root@hn00sia01:~]# ip -s link show eth0 3: eth0: <BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000 link/ether 00:0e:0c:51:b7:74 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 3557248549 213552255 0 0 0 0 TX: bytes packets errors dropped carrier collsns 2799461331 205424619 2 0 2 0 [root@hn00sia01:~]# ip -s link show eth1 4: eth1: <BROADCAST,MULTICAST,NOARP,SLAVE,UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000 link/ether 00:0e:0c:51:b7:74 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 59464724 464288 0 0 0 0 TX: bytes packets errors dropped carrier collsns 3336 42 0 0 0 0 2 carriers, therefor 2 errors that''s it. Maybe the http protocol is the only trying to transmit "large" ~= mtu size packets or something. I would try switching the nic and see if the problem goes away. S -- Met Vriendelijke groet/Yours Sincerely Stijn Jonker <SJCJonker@sjc.nl>
Stijn Jonker wrote:> > > Well one of the things that i find strange is the following: > (copied from earlier in the thread) > > [root@ns1 root]# ip -s link show dev eth2 > 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1412 qdisc pfifo_fast qlen 1000 > link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff > RX: bytes packets errors dropped overrun mcast > 76377859 162493 25 0 0 0 > TX: bytes packets errors dropped carrier collsns > 40707803 151908 1 0 1 15 > [root@ns1 root]# > > > Why would an device have 25 rx errors, 1 tx error and only 15 > collisions? Even when the device is on a hub, the errors should be > identical to the # of collisions. If the device is connected to a switch > the # of collisions should be 0.But that is still an error rate of 25 * 100 / 162493 = .015%!!!! That will *not* cause a noticable performance problem. Additionally, the behavior that I described is observable on the firewall''s *external* interface -- web pages and graphics that are definitely being send are not being acknowleged by the client. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: "Mailing List for Shorewall Users" <shorewall-users@lists.shorewall.net> Sent: Sunday, January 09, 2005 7:28 PM Subject: Re: [Shorewall-users] Dmz> Stijn Jonker wrote: >> >> >> Well one of the things that i find strange is the following: >> (copied from earlier in the thread) >> >> [root@ns1 root]# ip -s link show dev eth2 >> 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1412 qdisc pfifo_fast qlen 1000 >> link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff >> RX: bytes packets errors dropped overrun mcast >> 76377859 162493 25 0 0 0 >> TX: bytes packets errors dropped carrier collsns >> 40707803 151908 1 0 1 15 >> [root@ns1 root]# >> >> >> Why would an device have 25 rx errors, 1 tx error and only 15 collisions? >> Even when the device is on a hub, the errors should be identical to the # >> of collisions. If the device is connected to a switch the # of collisions >> should be 0. > > But that is still an error rate of 25 * 100 / 162493 = .015%!!!! That will > *not* cause a noticable performance problem. > > Additionally, the behavior that I described is observable on the > firewall''s *external* interface -- web pages and graphics that are > definitely being send are not being acknowleged by the client. > > -TomHey Guy''s I am back, When I captured the trace I gave you Tom. I just let about 30 seconds go by and then Hit ctrl c. Also I would force a refresh from my end to get the capture. Would it help to get a longer trace on this? Also I noticed this article when googeling http://support.microsoft.com/default.aspx?scid=kb;en-us;263088 I tried it since my problem seems to be ack''s on the recieve side of Dmz. I entered HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\interface TcpWindowSize 8192 decimal But I still have same trouble. Mike
Tom & Others, Tom Eastep said the following on 10-Jan-05 4:28:> Stijn Jonker wrote: > >> >> >> Well one of the things that i find strange is the following: >> (copied from earlier in the thread) >> >> [root@ns1 root]# ip -s link show dev eth2 >> 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1412 qdisc pfifo_fast qlen 1000 >> link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff >> RX: bytes packets errors dropped overrun mcast >> 76377859 162493 25 0 0 0 >> TX: bytes packets errors dropped carrier collsns >> 40707803 151908 1 0 1 15 >> [root@ns1 root]# >> >> >> Why would an device have 25 rx errors, 1 tx error and only 15 >> collisions? Even when the device is on a hub, the errors should be >> identical to the # of collisions. If the device is connected to a >> switch the # of collisions should be 0. > > > But that is still an error rate of 25 * 100 / 162493 = .015%!!!! That > will *not* cause a noticable performance problem.Yes it''s minimal, but still it might indicate a HW problem, what if the card doesn''t pass all errors to the SW layer?> Additionally, the behavior that I described is observable on the > firewall''s *external* interface -- web pages and graphics that are > definitely being send are not being acknowleged by the client.Well, then run a sniffer on the client, ethereal for windows works like a charm, at least i didn''t see any mentioning of traces on the client side. (So I opened the site myself.) What I find intresting is that retrieving the html page there are no retransmits or dup acks. When downloading the gif''s there are. Are the gifs dynamicly generated or something else with them? Next to this, is traffic shaping, or any other type of rate limiting configured on the firewall, the server or any other device like the modem/router before the fw? (the shorewall config doesn''t inidcate this, but an other device might) -- Met Vriendelijke groet/Yours Sincerely Stijn Jonker <SJCJonker@sjc.nl>
----- Original Message ----- From: "Stijn Jonker" <SJCJonker@SJC.nl> To: "Mailing List for Shorewall Users" <shorewall-users@lists.shorewall.net> Sent: Sunday, January 09, 2005 9:18 PM Subject: Re: [Shorewall-users] Dmz> Tom & Others, > > Tom Eastep said the following on 10-Jan-05 4:28: >> Stijn Jonker wrote: >> >>> >>> >>> Well one of the things that i find strange is the following: >>> (copied from earlier in the thread) >>> >>> [root@ns1 root]# ip -s link show dev eth2 >>> 7: eth2: <BROADCAST,MULTICAST,UP> mtu 1412 qdisc pfifo_fast qlen 1000 >>> link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff >>> RX: bytes packets errors dropped overrun mcast >>> 76377859 162493 25 0 0 0 >>> TX: bytes packets errors dropped carrier collsns >>> 40707803 151908 1 0 1 15 >>> [root@ns1 root]# >>> >>> >>> Why would an device have 25 rx errors, 1 tx error and only 15 >>> collisions? Even when the device is on a hub, the errors should be >>> identical to the # of collisions. If the device is connected to a switch >>> the # of collisions should be 0. >> >> >> But that is still an error rate of 25 * 100 / 162493 = .015%!!!! That >> will *not* cause a noticable performance problem. > > Yes it''s minimal, but still it might indicate a HW problem, what if the > card doesn''t pass all errors to the SW layer? > >> Additionally, the behavior that I described is observable on the >> firewall''s *external* interface -- web pages and graphics that are >> definitely being send are not being acknowleged by the client. > > Well, then run a sniffer on the client, ethereal for windows works like a > charm, at least i didn''t see any mentioning of traces on the client side. > (So I opened the site myself.)I ran etheral on my client, but I am no sniffer expert . I could not find the trouble. The dmz server (Dell win2k server intel pro gigabit card) is wired directly to eth2 on shorewall box (Crossover Cable). Shorewall has Tulip driver with Smc or Realtek Card. All three cards are the same on shorewall box. (I tryed putting a $200 100 base T switch between the two and had same trouble) But I thought since the pages load on port 443 that It may not be hardware or Nic''s That is an anomoly to me!!! Also this Dmz server has worked great for years using it behind snapgear firewall using Dnat. As soon as I moved it to proxy arp this problem occured. (Dmz server was behind snapgear router virtually identical to shorewall router but a embedded device) But we needed snapgear for a failover soultion with Ipsec. So I moved this Dmz server to shorewall box. Also if I move the Dmz server to the outside of the firewall on the internet switch it works without any trouble.> What I find intresting is that retrieving the html page there are no > retransmits or dup acks. When downloading the gif''s there are. Are the > gifs dynamicly generated or something else with them?The main page gif''s are preloaded for a javascript slide show. The nav menu gif''s are optimized by fireworks (fragmented) and also are controlled with javascript.> Next to this, is traffic shaping, or any other type of rate limiting > configured on the firewall, the server or any other device like the > modem/router before the fw? (the shorewall config doesn''t inidcate this, > but an other device might)> -- > Met Vriendelijke groet/Yours Sincerely > Stijn Jonker <SJCJonker@sjc.nl>The only thing I know to try is another server if you guys don''t see any thing else obvious to try. Thank you Stijn, I really appreciate Tom''s and your time. MIke
Mike Lander wrote:> > The only thing I know to try is another server if you guys don''t see any > thing > else obvious to try. >Mike -- are you seeing a significant error rate on the ''external'' interface when you are routing the web server through the firewall? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: "Mailing List for Shorewall Users" <shorewall-users@lists.shorewall.net> Sent: Monday, January 10, 2005 8:58 AM Subject: Re: [Shorewall-users] Dmz> Mike Lander wrote: > >> >> The only thing I know to try is another server if you guys don''t see any >> thing >> else obvious to try. >> > > Mike -- are you seeing a significant error rate on the ''external'' > interface when you are routing the web server through the firewall? > > -TomHere it is! Looks good to me Thanks Mike Last login: Sun Jan 9 18:12:58 2005 from 66-224-62-100.atgi.net [root@ns1 root]# ip -s link show dev eth0 6: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:04:e2:1c:f5:db brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 176869364 571799 0 0 0 0 TX: bytes packets errors dropped carrier collsns 297981874 637121 0 0 0 0 [root@ns1 root]#
----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: "Mailing List for Shorewall Users" <shorewall-users@lists.shorewall.net> Sent: Monday, January 10, 2005 8:58 AM Subject: Re: [Shorewall-users] Dmz> Mike Lander wrote: > >> >> The only thing I know to try is another server if you guys don''t see any >> thing >> else obvious to try. >> > > Mike -- are you seeing a significant error rate on the ''external'' > interface when you are routing the web server through the firewall? > > -TomI thought I might try a Smc Nic Card in the Dmz server Since Shorewall box has one for its eth2 then they would have matched cards. Just a thought since the Dmz server has a Intel gigabit card with a mulitude of differert settings. Mike
Mike Lander wrote:> > ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> > To: "Mailing List for Shorewall Users" > <shorewall-users@lists.shorewall.net> > Sent: Monday, January 10, 2005 8:58 AM > Subject: Re: [Shorewall-users] Dmz > > >> Mike Lander wrote: >> >>> >>> The only thing I know to try is another server if you guys don''t see any >>> thing >>> else obvious to try. >>> >> >> Mike -- are you seeing a significant error rate on the ''external'' >> interface when you are routing the web server through the firewall? >> >> -Tom > > > > I thought I might try a Smc Nic Card in the Dmz server > Since Shorewall box has one for its eth2 then they would have matched > cards. > Just a thought since the Dmz server has a Intel gigabit card with > a mulitude of differert settings.I see no evidence that the problem is in the server<->firewall link. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: "Mailing List for Shorewall Users" <shorewall-users@lists.shorewall.net> Sent: Monday, January 10, 2005 10:25 AM Subject: Re: [Shorewall-users] Dmz> Mike Lander wrote: >> >> ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> >> To: "Mailing List for Shorewall Users" >> <shorewall-users@lists.shorewall.net> >> Sent: Monday, January 10, 2005 8:58 AM >> Subject: Re: [Shorewall-users] Dmz >> >> >>> Mike Lander wrote: >>> >>>> >>>> The only thing I know to try is another server if you guys don''t see >>>> any >>>> thing >>>> else obvious to try. >>>> >>> >>> Mike -- are you seeing a significant error rate on the ''external'' >>> interface when you are routing the web server through the firewall? >>> >>> -Tom >> >> >> >> I thought I might try a Smc Nic Card in the Dmz server >> Since Shorewall box has one for its eth2 then they would have matched >> cards. >> Just a thought since the Dmz server has a Intel gigabit card with >> a mulitude of differert settings. > > I see no evidence that the problem is in the server<->firewall link. > > -TomCould this be a problem ? where eth2 Denotes flow control? [root@ns1 root]# mii-tool eth0: negotiated 100baseTx-FD, link ok eth1: negotiated 100baseTx-FD, link ok eth2: negotiated 100baseTx-FD flow-control, link ok [root@ns1 root]#
> > ----- Original Message ----- > From: "Tom Eastep" <teastep@shorewall.net> > To: "Mailing List for Shorewall Users" > <shorewall-users@lists.shorewall.net> > Sent: Monday, January 10, 2005 10:25 AM > Subject: Re: [Shorewall-users] Dmz > > >> Mike Lander wrote: >>> >>> ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> >>> To: "Mailing List for Shorewall Users" >>> <shorewall-users@lists.shorewall.net> >>> Sent: Monday, January 10, 2005 8:58 AM >>> Subject: Re: [Shorewall-users] Dmz >>> >>> >>>> Mike Lander wrote: >>>> >>>>> >>>>> The only thing I know to try is another server if you guys don''t see >>>>> any >>>>> thing >>>>> else obvious to try. >>>>> >>>> >>>> Mike -- are you seeing a significant error rate on the ''external'' >>>> interface when you are routing the web server through the firewall? >>>> >>>> -Tom >>> >>> >>> >>> I thought I might try a Smc Nic Card in the Dmz server >>> Since Shorewall box has one for its eth2 then they would have matched >>> cards. >>> Just a thought since the Dmz server has a Intel gigabit card with >>> a mulitude of differert settings. >> >> I see no evidence that the problem is in the server<->firewall link. >> >> -Tom > > Could this be a problem ? where eth2 Denotes flow control? > > [root@ns1 root]# mii-tool > eth0: negotiated 100baseTx-FD, link ok > eth1: negotiated 100baseTx-FD, link ok > eth2: negotiated 100baseTx-FD flow-control, link ok > [root@ns1 root]#A switch with the so called ''broadcast protection'' enabled? Very common today and really terrible sometimes... Simon