Linux network routing woes

Civilian_Target

I'm having problems with a Linux routing setup - and was wondering if any of you Linux networking gurus could help.

The setup
I'm forwarding an internal network of 7 machines though a Linux gateway (& firewall) onto the net, with a single IP address. Currently, I'm doing this using Debian Sarge Linux, with a Shorewall-based setup. The problem I'm having is this - the connection to the internet from the gateway cuts out at random intervals, (but the more traffic is flowing, the more likely a cut out is) and is then re-established a few minutes later, for no apparant reason.

The connection hardware appears to be fine - the modem works perfectly on another network, as do both network cards in the gateway machine, and I replaced all the cabling in a desperate attempt to sort things. Despite this, resetting the modem will fix the connection instantly, albeit temporarily.

The shorewall setup is very simple - IP forwarding is enabled for all addresses from eth0 to eth1, traffic control is not enabled. However, as an experiment, I pulled off shorewall for a while, loaded up with Knoppix and set up routing using iptables, and the problem persisted.

My suspicions
Ironicly, right now the connection has just died...
OK - so when I run ifconfig I get the following output. eth0 is internal, eth1 is external and static (ip's been changed):

eth0      Link encap:Ethernet  HWaddr 00:04:61:5B:59:68
          inet addr:192.168.123.1  Bcast:192.168.123.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4042688 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3963880 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1768098338 (1.6 GiB)  TX bytes:2272921800 (2.1 GiB)
          Interrupt:22 Base address:0x6000

eth1      Link encap:Ethernet  HWaddr 00:08:A1:28:3E:53
          inet addr:84.141.98.219  Bcast:84.141.98.223  Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3731504 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3857860 errors:19484 dropped:0 overruns:0 carrier:0
          collisions:3858 txqueuelen:1000
          RX bytes:2210846949 (2.0 GiB)  TX bytes:1747509419 (1.6 GiB)
          Interrupt:16 Base address:0xc000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:6925 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6925 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:655592 (640.2 KiB)  TX bytes:655592 (640.2 KiB)

Look at the stats for eth1 - we're getting a lot of errors and collisions, despite the fact that the cabling and network hardware is fine, and the ISP is not dropping the connection.

Also - when pinging just before a failure I can see messages appear in the piped output, saying, for example:

Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 3f00 63c5   0 0000  7f  11 aedb 192.168.123.2  62.231.32.10
UDP: from port 1141, to port 53 (decimal)

Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst Data
 4  5  00 3000 a41d   0 0040  7f  06 41d0 192.168.123.6  64.178.145.129
TCP: from port 4378, to port 24965 (decimal)

62.231.32.10 is, as you would expect, the primary DNS server - I have no idea of what is causing the second sample.

Anyway - suffice to say, I'm suspicious of the collisions being the cause of my woes, but even if they are, I have no idea how to prevent them occuring. All help and suggestions welcome, and config files available on request.

WizZard

Hmm, that's a strange one alright...
Try running ethtool to narrow down the types of errrors occuring on the affected NIC.

Civilian_Target

Gave ethtool a lash there - it doesn't support the network card on eth1

niallb

Just to take a closer look at that second address.
It's in Canada, probably in this town...
Fox Creek.

Any legitimate connection with it?

For the connection problem, try this:
ifconfig eth1 mtu 1380

See if that makes a difference. If it does,
you can raise the mtu slowly towards 1500
until it breaks again, and take a closer look
.

What type of physical link is it? (DSL, wireless, LL)

NiallB

Civilian_Target

I just changed a digit of the IP, which I guess makes it officially made up
But while we're on the subject, where did you get the free geoIP service?

The link is, in case you haven't guessed, wireless. But the signal is strong with it, it's licensed frequency, yadda yadda. One possibility I am looking into though, is that we're right beside the main Dublin-Belfast train line, so its possible that either the train is interfering with it. I'll check if the time of disconnection corresponds with the time table of the train...

Civilian_Target

Oh - and changing the MTU didn't appear to help

niallb

Pity, I've seen that work on a wireless link before, then had the provider turn on their "VOIP tweaks" after which they worked fine
with ethernet defaults.

Try to have your provider check your radio
settings remotely - you may need a firmware update.

it doesn't support the network card on eth1

This caught my eye. Do you mean it wouldn't run on the second interface ( as in ethtool eth1 didn't work ) or it came up with an unsupported device error. Can you try changing that NIC?
I've had weird behaviour with a card recently,
a National Semiconductors chip build by Netgear.

One last thing, is that interface autonegoatiating speed with the router?
Lock them both to 10Mb if possible, and
make sure their duplex settings match.

As for the GeoIP, I just got lucky with whois. Some countries are better than others, but this time it turned up a small (innocent :-) ) company in Canada...

Good luck,
NiallB

PS: I hope it's the train!

democrates

Civilian_Target wrote:

I'll check if the time of disconnection corresponds with the time table of the train...

You might be better off checking if the disconnection corresponds with the times the trains pass...