> 1. Re: FW Through Put (Dennis Stephens) > 2. DCD, icmp & NAT ??? (Michael D. Schleif) > 3. RE: Testing IPsec pass-through (Eric B Kiser) > 4. RE: Testing IPsec pass-through (Tom Eastep) > 5. relay-ctrl (Bill Hults) > 6. RE: Testing IPsec pass-through (Eric B Kiser) > 7. RE: Testing IPsec pass-through (Tom Eastep) > 8. proxy arp diagram for shorewall (Victor McAllister) > 9. Re: relay-ctrl (Ray Olszewski) > 10. Re: proxy arp diagram for shorewall (Tom Eastep) > 11. Re: DCD, icmp & NAT ??? (Ray Olszewski) > 12. Re: DCD, icmp & NAT ??? (Michael D. Schleif) > >--__--__-- > >Message: 1 >Date: Wed, 01 May 2002 09:13:21 -0500 >To: [EMAIL PROTECTED],[EMAIL PROTECTED] >From: Dennis Stephens <[EMAIL PROTECTED]> >Subject: Re: [leaf-user] FW Through Put
This is the first time I've used mailing lists, so if I'm doing anything wrong, or doing something that is considered ill-mannered, please tell me. I am under the impression that to contribute to the mailing list, you use an email client, and reply to messages (after changing the subject to something more specific.) Is this so? And if so, then how come it seems in a single digest it seems issues can be brought up and resolved in a single email? Hopefully someone can tell me exactly how this works...I'm a bit confused atm. Sorry for asking so many questions...below is my contribution. >First thanks all for feedback As usual for me, my haste injects >problems. As a new information lead in I specifically suspect the cable >company. The cable modem over a period of time of low to no use, that is, >when I'm away will be displaying upon my return an indication that it is >having a signal strength problem. Connectivity to the outside world from >the workstation will have been lost. A modem reset, svi dhclient restart >and svi network reload will get the firewall back up. An ipconfig /renew >on the workstation and I'm back in business. The cable company will be out >Monday morning to check this out. I don't know how relevant this is, but it might be something you might want to consider. A friend of mine had a similar problem, using a cable service and using Coyote Linux. His internet would drop out for no reason occasionally if he used Coyote, but using his pre-bought Netgear standalone router, there would be no problems. As a result, he specifically suspected the cable company somehow blocking his Linux machine. (I never agreed, but found no other explanation at the time.) His idea was because the Linux box was always still working on the LAN side. To get back onto the internet, a modem reset, and restarting the DHCP client etc (as described in your situation) was required. However, after I proved my image worked on my hardware (with his connection), he discovered it was a problem with his hardware. He said something about having Full Duplex Enabled (via a utility for the card) instead of disabled, and also said something to the effect that that card couldn't handle Full Duplex. Once he used the utility to disable Full Duplex, it worked perfectly. Just thought the situation sounded similar. Might not be exactly the same problem, but, it might help. >At 11:39 AM 4/30/2002 -0700, you wrote: > >At 12:04 PM 4/30/02 -0500, Dennis Stephens wrote: > > >Have started this morning with a cable modem problem and worked through it > > >with Tech Support. Now the through put is less than half of what it > should > > >be. How can I determine that the problem is on the provider's side of the > > >system and not in my firewall or home network? > > > >For our purposes, a good starting place would be describing what you mean by > >"through put is less than half of what it should be". What throughput are > >you expecting, what are you getting, and how are you measuring it (include > >between where and where)? > >The system in question is a Win 2k workstation behind a Dachstein firewall >connected to a cable modem. This provides me email, news and web surfing >access. The VPN is client software run on the workstation that is port >forwarded to/through the firewall and connects to a VPN server at the >company I work for. No real VPN on the firewall except using >ip_masq_ipsec. The advertised rate the cable company is supposed to be >supporting is 764k down and 128k up. Now that is bits so I need to divide >by eight (give or take a bit) that would be ~95.5kb/sec. A sample 5mb file >they have at their site comes over at 45kb/sec peak to a low in single >digits and sometimes times out. A lot of internet surfing can time out, >accessing the email account can time out. I have been able to document >speeds on a test file in the past, one and two months ago, that were closer >to 900k down and 200k up. > > >I ask because the traceroute result you report below is not really a local > >throughput measure, and response delays of the sort you mention there are > >far from surprising. I couldn't repliacte your experience this morning, but > >then I'm "closer" to Yahoo (only 10 steps) than you apparently are. > > > >snip, snip... > > >In practice, with equipment of the quality you are using, I've seen about a > >10% hirt on throughput. But only at the higher levels of LAN-to-LAN routing > >(nominally 10 Mbps; in practice, about 5 Mbps). The usual range of offsite > >connections -- 384 Kbps to 1544 Kbps -- does not normally induce > >router-based throughput losses. > > > > >They are taking the > > >position (of course they would), that they can not see a reason for the > > >reduction. The Dachstien floppy is working fine, with only a slight hole > > >poked through it for my VPN connection to the corporation. > > > >A 486/66 is plenty fast for a normal NAT'ing router, but it isn't very much > >horsepower for running a VPN. From what you wrote, I can't tell where in the > >system the VPN'ing is being done. If on the router, that could be slowing > >things down. > > > >When you are having speed problems, what does the router's CPU utilization > >look like? (Can someone remind me how to check this in Dachstein? I usually > >use top for this, but I don't think Dachstein includes it.) > >I give, that was the basis of my question(s). How do I document what the >firewall is doing other than the packet handling results in system logs. > > > > >Everything is > > >working, the weblet, the bandwidth monitor et al. Just working > > >slowly. > > > >Do you really mean that a connection from the Weblet to a host on the LAN is > >"working slowly"? If so, this suggests a local problem, not a cable-side > >problem. > >No, that (weblet page) pops up crisp and fast. > > > > >How do I determine where a bottleneck or degradation is > > >occurring? Did a traceroute from here to yahoo and had a hop that was > 200+ > > >ms and one other of the 22 hops that was 700+.ms. > > > >Where was "here"? The router or a host on the LAN behind the router? Was the > >VPN involved? > >As described above here is where this email was created a workstation >behind the Dachstein firewall. > > > >Depending on time of day and other details, delays of this sort can occur > >without the cable company (or anything else local) being at fault. > > > > >Truly appreciate any > > >guidance and greatly appreciate the programming and work of all that > helped > > >with this great application. > > > > >snip... > >Ditto the last paragraph. This forum always shows up in spades and for >that I am grateful. > >As Always... > > > >--__--__-- _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
