Member Avatar for bungilo

I have a linux box (2.6.9 kernel). problembox has 2 nics, A and B, with A's IP = and B's IP = 10.1.1.1. I want to be the default (for things such downloads via apt-get and to be used for communications to other boxes on the network.

The network is used for backups and admin with backupbox that has the IP of and webbox that has the IP of 10.1.1.3. The 10.1.1.x network is connected to a unmanaged switch. Backupbox is the backup manager and can connect to and do its backup, but cannot connect to at all. I have no firewall on 10.1.1.1.

For problembox, my interface config file looks like:

eth0

ip
sub
gw

eth1

ip
sub
gw

I've tried to put in:

ip route add default via dev eth0 tab 1
ip route add default via dev eth1 tab 2


ip rule add to tab 1 priority 500
ip rule add to tab 2 priority 600

ip route flush cache

but no go; I've even tried to put in two gateways (where eth1 gw=).

What am I missing?

  • 1 Contributor
  • 2 Replies
  • 110 Views
  • 1 Week Discussion Span
  • Latest Post Latest Post by bungilo

Dani AI

Generated

The symptom reported by — ARP requests being sent but ARP replies never arriving — strongly points to a receive-path failure (hardware/PHY/PCI/driver), not a routing or policy issue. That observation was the key to the real fix: reseating/powering the riser/PCI connection resolved the RX failures. When ARP replies reach the wire but never reach the kernel, start with physical and driver-level checks before reworking routing rules.

Useful diagnostic checklist and commands to run (replace ethX with the actual interface name):

sudo ethtool ethX
ip -s link show ethX
cat /sys/class/net/ethX/statistics/{rx_errors,rx_dropped,tx_errors,tx_dropped}
dmesg | egrep -i 'eth|rx|tx|e1000|igb|ixgbe'
cat /proc/interrupts | egrep -i 'eth|e1000|igb|ixgbe'
sudo tcpdump -n -i ethX arp

What those checks reveal and what to try next:

  • No link lights, persistent rx_errors or rx_dropped → bad cable, switch port, or PHY/power to riser; swap cable/port or move the NIC to a different slot.
  • Interrupt counters not increasing on incoming traffic → IRQ/riser/PCI bus problem or driver stuck; reseat hardware, test in another slot, or try a different NIC.
  • Driver messages in dmesg or large counts in ethtool -S → driver/firmware bug; update kernel/driver or use a vendor driver.
  • If everything hardware/driver looks OK but packets still not forwarded, verify net.ipv4.ip_forward and policy routing configuration.

Preventive notes: powered risers or direct PCI slots avoid power/IRQ oddities; always test with a live Linux image to separate OS/driver issues from hardware. For command references see the ethtool and ip man pages and the kernel networking docs: ethtool(8), ip(8), Linux kernel networking docs.

Member Avatar for bungilo

Follow up:

I sniffed on both the problembox and the backupbox and started pings from the problembox to the backupbox. On the problembox I can see arp requests going out for whohas the backupbox IP, on the backupbox I can see the arp requests come in and the backupbox arp replies with the correct MAC address but the problembox never receives it. When I ping from the backupbox to the problembox, I can see the arp request going out fromt the backupbox, the problembox never receives the request. So, long story short, the problembox can send requests, but not receive replies (it can transmit but not receive). Hardware issue???

Member Avatar for bungilo

Alright. The issue was hardware related. I believe that the riser card was not getting enough juice and spliced in longer wires so that I could plug in both of the pci-slot connections and since I was plugging the riser into slot 3 vice slot 1, i changed the jumpers from A to B - not sure this really did anything but now I'm able to ping away. So I am saying this is complete and the problem of the one nic dropping incoming packets is due to a power issue.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.