Linux route command giving error 'SIOCADDRT: Network is unreachable'

Basically trying to provide a route from eth1 to eth0 and getting an error when trying to issue the command:
route add -net 10.40.40.0 netmask 255.255.255.0 gw 192.168.0.10 dev eth1
Yeilds response:"SIOCADDRT: Network is unreachable"  
Relevant settings:
eth0  inet addr:192.168.0.167  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3329 errors:0 dropped:0 overruns:0 frame:0
          TX packets:259 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:424167 (414.2 KiB)  TX bytes:33542 (32.7 KiB)
eth1  inet addr:10.40.40.2  Bcast:10.40.40.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:63 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:476 (476.0 b)  TX bytes:9490 (9.2 KiB)
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1428 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1428 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2271504 (2.1 MiB)  TX bytes:2271504 (2.1 MiB)
route:Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.40.40.0      *               255.255.255.0   U     0      0        0 eth1
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth1
default         192.168.0.10    0.0.0.0         UG    0      0        0 eth0
~~~~~
I can ping 192.168.0.10 and 10.40.40.7 (servers on both the subnets) and SSH to the server from the 192 subnet then SSH to the 10.40.40.7 server.
I get this regardless of whether I have set a 1 or a 0 to the ip_forward  
# echo 1 > /proc/sys/net/ipv4/ip_forward
I also get this if I take out the default gateway from eth0.
I am on RHEL5U2 and have tried it with iptables off, iptables -F (detault) and various NAT/forwarding.
~~~~~
Any ideas on how to make this work?
nodozenoAsked:
Who is Participating?
 
kyleb84Connect With a Mentor Commented:
You do not need a "route" command as the linux box already knows how to get to each network.

Making a linux router is relatively easy...

Attached is a script that routes from the 192.168.1.0 network to the 172.16.0.0 network

ip_forward must be 1...

For different networks just change the last 2 lines....

#!/bin/sh
 
. /etc/functions.sh
WAN="eth0"
WANDEV="eth0"
LAN="eth1"
 
## CLEAR TABLES
for T in filter nat; do
  iptables -t $T -F
  iptables -t $T -X
done
 
iptables -N input_rule
iptables -N input_wan
iptables -N output_rule
iptables -N forwarding_rule
iptables -N forwarding_wan
 
iptables -t nat -N NEW
iptables -t nat -N prerouting_wan
iptables -t nat -N prerouting_rule
iptables -t nat -N postrouting_rule
 
iptables -N LAN_ACCEPT
[ -z "$WAN" ] || iptables -A LAN_ACCEPT -i "$WAN" -j RETURN
[ -z "$WANDEV" -o "$WANDEV" = "$WAN" ] || iptables -A LAN_ACCEPT -i "$WANDEV" -j RETURN
iptables -A LAN_ACCEPT -j ACCEPT
 
### INPUT
###  (connections with the router as destination)
 
  # base case
  iptables -P INPUT DROP
  iptables -A INPUT -m state --state INVALID -j DROP
  iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  iptables -A INPUT -p tcp --tcp-flags SYN SYN --tcp-option \! 2 -j  DROP
 
  #
  # insert accept rule or to jump to new accept-check table here
  #
  iptables -A INPUT -j input_rule
  iptables -A INPUT -i $WAN -j input_wan
 
  # allow
  iptables -A INPUT -j LAN_ACCEPT       # allow from lan/wifi interfaces
  iptables -A INPUT -p icmp     -j ACCEPT       # allow ICMP
  iptables -A INPUT -p gre      -j ACCEPT       # allow GRE
 
  # reject (what to do with anything not allowed earlier)
  iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
  iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable
 
### OUTPUT
### (connections with the router as source)
 
  # base case
  iptables -P OUTPUT DROP
  iptables -A OUTPUT -m state --state INVALID -j DROP
  iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
 
  #
  # insert accept rule or to jump to new accept-check table here
  #
  iptables -A OUTPUT -j output_rule
 
  # allow
  iptables -A OUTPUT -j ACCEPT          #allow everything out
 
  # reject (what to do with anything not allowed earlier)
  iptables -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
  iptables -A OUTPUT -j REJECT --reject-with icmp-port-unreachable
 
### FORWARDING
### (connections routed through the router)
 
  # base case
  iptables -P FORWARD DROP
  iptables -A FORWARD -m state --state INVALID -j DROP
  iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
  iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
 
  #
  # insert accept rule or to jump to new accept-check table here
  #
  iptables -A FORWARD -j forwarding_rule
  iptables -A FORWARD -i $WAN -j forwarding_wan
 
  # allow
  iptables -A FORWARD -i br0 -o br0 -j ACCEPT
  iptables -A FORWARD -i $LAN -o $WAN -j ACCEPT
 
iptables -F input_rule
iptables -F output_rule
iptables -F forwarding_rule
 
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p tcp -j ACCEPT
iptables -A INPUT -p udp -j ACCEPT
 
iptables -t nat -F
iptables -t nat -X
 
iptables -A FORWARD -s 192.168.1.0/24 -d 172.16.0.0/24 -j ACCEPT
iptables -A FORWARD -s 172.16.0.0/24 -d 192.168.1.0/24 -j ACCEPT

Open in new window

0
 
ravenplConnect With a Mentor Commented:
> route add -net 10.40.40.0 netmask 255.255.255.0 gw 192.168.0.10 dev eth1
> eth1  inet addr:10.40.40.2  Bcast:10.40.40.255  Mask:255.255.255.0
You don't need to add this route - the route is already there (as a link scope)
but even though "gw 192.168.0.10" is accesible only via eth0, not the eth1 You specified.
0
 
nodozenoAuthor Commented:
Thanks gents for the info.  I was able to get most of what I needed.  I do still have some remaining issues but I think they are related to the fact that these servers are on a virtual infrasture (virt blade networking in a chassis as well as virtual networking on XEN on top of the blades).  I found tons of IPtables entries under the covers in the virt infrastructure and there may be some interaction.  Until I replicate this on a physical infrastructure I will have to assume that is the cause.  
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.