Incoming traffic but nothing outgoing - arp loss?

[xylodrum]

About a month ago my Terayon modem was swapped for a 250 as it developed a faulty ethernet port, apart from that it performed perfectly. Since then I have been experiencing random losses of connectivity - at best once every couple of days, at worst 2 or 3 times a day. I run a home-brew linux based firewall/router and from its logs I can see that traffic is still arriving, but none is being sent. This is the only PC exposed to the internet. The only fix so far is a power cycle on the modem.

After a litle bit of diagnosis I've seen that once in the broken state, the arp table entry for the modem has been lost. The table is normally something like this:

# arp -an
? (10.1.x.x) at xx:xx:xx:xx:xx:xx [ether] on eth1
? (82.15.x.x) at xx:xx:xx:xx:xx:xx [ether] on eth0

but once failed:

# arp -an
? (10.1.x.x) at xx:xx:xx:xx:xx:xx [ether] on eth1
? (82.15.x.x) at <incomplete> on eth0

its as if the modem has stopped responding to arp requests. manually re-adding the arp entry does not restart the connection.

From the Cable Modem web page:

Cable Modem : DOCSIS 1.0/1.1/2.0 Compliant
MAC Address : xx:xx:xx:xx:xx:xx
Serial Number : 000xxxxxxxxx
Boot Code Version : 2.1.6d
Software Version : 2.94.1010
Hardware Version : 1.19

Has anyone seen this problem? ... or, better, found a fix?

[rdhw]

What kind of firewall is this PC running? Has the firewall been opened for DHCP responses from (a) NTL's DHCP servers, and (b) the local DHCP relay agent?

Is there any conflict between your use of the 10.1.x.x network and NTL's private 10.x.x.x ranges, which include possibly the local DHCP relay agent?

[xylodrum]

Thanks for your response!

> What kind of firewall is this PC running?
iptables

> Has the firewall been opened for DHCP responses from (a) NTL's DHCP servers
It's opened for 62.253.64.3. Inspired by your question though I trawled the logs and found it had blocked DHCP from 62.253.96.21. I guess it's possible the original DHCP grant is being allowed through but the renewal is being blocked? I've added this new address anyway

> and (b) the local DHCP relay agent?
I'm not sure what you meant be this?

> Is there any conflict between your use of the 10.1.x.x network and NTL's private 10.x.x.x ranges, which include possibly the local DHCP relay agent?
My 10 range has never caused any problems before - this set up has run faultlessly for at least 3 years with the arp-loss only occuring in the last month since the replacement modem arrived.

I have seen in another thread a similar symptom:

http://www.cableforum.co.uk/board/sh...ad.php?t=37704

i.e. downstream but no upstream data. But this problem seems to be caused by using the connection with two PCs and hence a change in MAC address. Could some similar mac-confusion be occuring in my set up?

[patrickp]

If you're using a SACM and not an STB, xylodrum, the MAC address doesn't matter. A modem doesn't look for it; only an STB does.

[xylodrum]

thx for that - it narrows down the possible cause

[rdhw]

Originally Posted by xylodrum

Inspired by your question though I trawled the logs and found it had blocked DHCP from 62.253.96.21. I guess it's possible the original DHCP grant is being allowed through but the renewal is being blocked? I've added this new address anyway

Based on that experience I would add 62.253.96.20 as well, as that is another DHCP server in the same cluster

> and (b) the local DHCP relay agent?
I'm not sure what you meant be this?

DHCP broadcasts will be handled by the local DHCP agent on your local cable network: the DHCP relay agent has to be within the range of IP broadcasts between your PC and itself: the true DHCP servers are not within broadcast range. The DHCP relay agent will be the same physical machine as your local IP gateway/router (the local CMTS or UBR in Cisco-speak), but it is likely to be operating under a private IP address in the 10.x.x.x range or 172.x.x.x range, which you can normally detect as the first hop on a traceroute outside your own network. You should configure your firewall to allow all access from that private IP address. If you are getting time-outs on a traceroute hop within NTL's network, then your firewall is being too restrictive.

> Is there any conflict between your use of the 10.1.x.x network and NTL's private 10.x.x.x ranges, which include possibly the local DHCP relay agent?
My 10 range has never caused any problems before

OK, but please check that there are working routes to NTL servers in the 10.x.x.x range from PCs lying inside your firewall.

Could some similar mac-confusion be occuring in my set up?

If your router, through some malfunction, is changing the MAC address on its WAN port during normal service, then this will cause symptoms of the sort you describe. Also (moving towards the paranoid end of the spectrum) if another cable user in your area comes online with the same MAC address as the WAN port of your router, then there will be trouble.