RE: strange network problems

["Kenneth Goodwin" <kgoodwin datamarktech com>]

I posted an answer to your problem before hours ago, saw it myself, assumed you got it as well
I will rephrase.

Your problem has nothing to do with broadcast addresses. 0.0.0.0 , 255.255.255.255,
x.y.z.255 and x.y.z.0 are all valid forms of broadcast address if I remember Comer correctly.
The latter two forms are (sub)Net specific broadcasts, the first two are network wide broadcasts
that cross all networks (All Ones, ALL ZEROS). The latter two are normally specified to keep broadcast traffic locally. The former two while valid, are no longer in general use - who wants broadcast storms
anyway..........

If I understand the issue correctly.
	A) On the firewall, you can up/down load files without a problem.
	B) On the PC, with the firewall "quiet", you can up/down load files without a problem.
	C) If both the PC and the firewall are independantly up/downloading, the PC system
	gets a high degree of failures with no problems showing in the tcp/ip logs.

In other words, everything works until you try to have both systems ftp'ing in tandem,
upon which the workstation pc breaks.

A + B indicate no probably cause to suspect an hardware issue. But since your firewall is a P2-350
it has more than enough horsepower to totally absorb all TCP/IP buffers in the kernel
for doing an FTP connection.
Your incoming connections from the PC will tend to get a lower priority than ON system requests.
What I basically think
is happeninng on the firewall is that you start up an FTP PUT (or GET depending on remote system speed)
on your 10mbps - 45mbps Cable connection. Because the firewall is faster than the network bandwidth,
it is probably absorbing the majority, if not all, of the TCp/IP IO buffers doing this FTP.

It will tend to fill up as many as possible very quickly until it hits a high water mark
resource limit configured on your system. This will
leave none or almost none (depends on kernel resource enforcement) of the TCP buffer resources
for your client PC's needs. If you installed the firewall as a Linux workstation instead of a server
it may have also set resource limits as per a workstation.

when the PC tries to transmit (FTP) through
the firewall while it has its own FTP process going, the TCP driver in the firewall will use the sliding
window protcol and source quench requests to throttle down your PC's TCP/IP traffic to it.
what I believe you need to do is to is fix a resource limitation issue. Your dropped Pings
are being caused by timeouts in getting the ICMP message reply back in time as it is competing
with the bandwidth being used on the cable channel by the firewall as well as all the io buffers
being absorbed by that FTP process. Think of your situation this way - Your firewall is more than
likely saturating the full bandwidth of the cable modem side to the internet, leaving little or no
bandwidth left for other connections. It is absorbing as much resources as possible to maintain
the throughput. What's left over, your client PC gets to use. First try to eliminate a resource
contention possibility -

1) Tweak the kernel parameters to increase the number of allocated
TCP/IP buffers and other resources.

2) make sure the high water mark for tcp/ip buffer usage per process is low enough to
leave spare buffers for other processes.

perhaps someone with more expertise in linux kernel configuration / network controls can point
you in the right direction in this regards.


Kenneth Goodwin
Director of IT Operations
Datamark Technology, Inc.


>>> -----Original Message-----
>>> From: enigma-list-admin redhat com
>>> [mailto:enigma-list-admin redhat com]On Behalf Of Avery Pierce
>>> Sent: Wednesday, October 30, 2002 12:51 PM
>>> To: enigma-list redhat com
>>> Subject: Re: strange network problems
>>> 
>>> 
>>> > eth1      Link encap:Ethernet  HWaddr 00:E0:29:95:60:60
>>> >           inet addr:X.X.X.X  Bcast:255.255.255.255  
>>> Mask:255.255.255.0
>>> 
>>> >This looks like where your problem is, why does it have a /24 mask
>>> >but an all-ones broadcast address?  It should be X.X.X.255 (where
>>> >the X's refer to the inet address).
>>> >
>>> >If that public interface is configured via dhcp (eg, cable), then
>>> >there could be a problem with your ISP's configuration (which would
>>> >be unforgivable :-)
>>> 
>>> eth1 is configured for dhcp.  I know if I call them they 
>>> will just tell me they dont support linux.
>>> Heres some more info if it helps.  Thanks for your time.
>>> 
>>> here is a "ip -s a"
>>> 
>>> eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
>>> link/ether 00:e0:29:1d:98:6e brd ff:ff:ff:ff:ff:ff
>>> inet 192.168.200.1/24 brd 192.168.200.255 scope global eth0
>>> 
>>> eth1: <BROADCAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 100
>>> link/ether 00:e0:29:95:60:60 brd ff:ff:ff:ff:ff:ff
>>> inet x.x.x.x/24 brd 255.255.255.255 scope global eth1
>>> 
>>> Here is a "ip route"
>>> 
>>> 24.53.194.0/24 dev eth1  proto kernel  scope link  src x.x.x.x
>>> 192.168.200.0/24 via 192.168.200.1 dev eth0  scope link
>>> 192.168.200.0/24 dev eth0  scope link
>>> 127.0.0.0/8 dev lo  scope link
>>> default via 24.53.194.1 dev eth1
>>> 
>>> *********** REPLY SEPARATOR  ***********
>>> 
>>> On 10/30/2002 at 3:30 PM Tony Nugent wrote:
>>> 
>>> >On Tue Oct 29 2002 at 23:16, "Avery Pierce" wrote:
>>> >
>>> >> Im using a PII 350 with 2 SMC 1211TX Nics (realtek 8139).  Its
>>> >> used for a firewall / NAT Gateway with 1 pc behind it.  If im
>>> >> uploading a file on the firewall my pc behind the firewall had no
>>> >> internet access on tiemouts.  I get heavy packet loss when I ping
>>> >> an outside server..like google.com.  When uploading from my pc
>>> >> through the firewall everything works just fine.  
>>> Downloading also
>>> >> works fine .  Im logging all dropped packets with iptables and
>>> >> nothing is behind dropped.  There isnt any errors in
>>> >> /var/log/messages pertaining to the network interfaces.  
>>> ive tried
>>> >> updating anything that might be causing this.
>>> >
>>> >(please wrap your text to make it readable, like I've just done).
>>> >
>>> >> System:
>>> >> Redhat 7.2 Enigma
>>> >> Kernel 2.4.18-17.x
>>> >> Nic Driver 8139too
>>> >> iptables 1.2.5-3
>>> >> 
>>> >> I connect to the internet with a SurfBoard sb4100 
>>> cablemodem through
>>> >Adelphia.
>>> >> My pc connects to the firewall using a crossover cable.  
>>> My pc has an
>>> >smc 1211tx nic also.
>>> >> Any ideas would be appreciated.  Thanks in advance.
>>> >> 
>>> >> Heres an ifconfig on the firewall
>>> >
>>> >/sbin/ifconfig is becoming obselete.  Use "/sbin/ip -s 
>>> link" (and/or
>>> >"ip -s a") to get a better output.
>>> >
>>> >
>>> >> eth0      Link encap:Ethernet  HWaddr 00:E0:29:1D:98:6E
>>> >>           inet addr:192.168.200.1  Bcast:192.168.200.255 
>>> >Mask:255.255.255.0
>>> >>           UP BROADCAST RUNNING MULTICAST  MTU:1500 Metric:1
>>> >>           RX packets:35202 errors:6 dropped:0 overruns:0 frame:0
>>> >
>>> >(I'd check what is causing these errors if they persist).
>>> >
>>> >>           TX packets:24688 errors:0 dropped:0 overruns:0 
>>> carrier:0
>>> >>           collisions:0 txqueuelen:100
>>> >>           RX bytes:2402686 (2.2 Mb)  TX bytes:2912915 (2.7 Mb)
>>> >>           Interrupt:5 Base address:0xc000
>>> >> 
>>> >> eth1      Link encap:Ethernet  HWaddr 00:E0:29:95:60:60
>>> >>           inet addr:X.X.X.X  Bcast:255.255.255.255  
>>> Mask:255.255.255.0
>>> >
>>> >This looks like where your problem is, why does it have a /24 mask
>>> >but an all-ones broadcast address?  It should be X.X.X.255 (where
>>> >the X's refer to the inet address).
>>> >
>>> >What have you got in /etc/sysconfig/network-scripts/ifcfg-eth1 ?
>>> >That interface doesn't seem to be configured right.
>>> >
>>> >If that public interface is configured via dhcp (eg, cable), then
>>> >there could be a problem with your ISP's configuration (which would
>>> >be unforgivable :-)
>>> >
>>> >>           UP BROADCAST NOTRAILERS RUNNING  MTU:1500  Metric:1
>>> >>           RX packets:26893 errors:0 dropped:0 overruns:0 frame:0
>>> >>           TX packets:35608 errors:0 dropped:0 overruns:0 
>>> carrier:0
>>> >>           collisions:0 txqueuelen:100
>>> >>          RX bytes:3045857 (2.9 Mb)  TX bytes:2968880 (2.8 Mb)
>>> >>          Interrupt:10 Base address:0xe000
>>> >
>>> >Yeah, the itself card is working fine.
>>> >
>>> >The problem could be elsewhere (in your routing table, 
>>> which you can
>>> >see with "/sbin/ip route") or in your actual firewall rules (which
>>> >you haven't shown here, but not likely to be the cause if some
>>> >packets are getting through).
>>> >
>>> >But the bad 255.255.255.255 broadcast address needs to be fixed (if
>>> >that is what it really showing up as).
>>> >
>>> >> Avery Pierce
>>> >> Camteq Professional Systems
>>> >> www.camteq.com
>>> >
>>> >Cheers
>>> >Tony
>>> >
>>> >
>>> >
>>> >_______________________________________________
>>> >enigma-list mailing list
>>> >enigma-list redhat com
>>> >https://listman.redhat.com/mailman/listinfo/enigma-list
>>> 
>>> 
>>> 
>>> Avery Pierce
>>> Camteq Professional Systems
>>> www.camteq.com
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> enigma-list mailing list
>>> enigma-list redhat com
>>> https://listman.redhat.com/mailman/listinfo/enigma-list
>>>