Home / server / Questions / 225387
In Process
M_1
Asked: 2011-01-22 14:57:50 +0800 CST

Debian Static Routing not working?

  • 772

I have to be doing something wrong.

the network is setup as below:

ST1     eth0
    192.168.254.253
    255.255.255.0
    no gate
ST1     eth1
    10.10.10.6
    255.255.255.252
    no gate
    
ST2     eth0
    172.16.200.254
    255.255.255.0
    no gate
ST2     eth1
    10.10.10.5
    255.255.255.252
    no gate
    
CLIENT
    172.16.200.100
    255.255.255.0
    172.16.200.254
    
KENTUCKY
    192.168.254.254
    255.255.255.0
    no gate

alt text

ST1:

alt text

ST2:

alt text

Can someone point out what I am doing wrong? Already tried so many configurations...

routing debian

2 Answers

  1. Have the router been told to route via setting /proc/sys/net/ipv4/ip_forward to 1? http://www.linuxdocs.org/HOWTOs/Adv-Routing-HOWTO-12.html

    If this is the problem, then setting this below will allow it to survive a reboot.

    File:/etc/sysctl.conf:
net.ipv4.ip_forward = 1

    http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/ was my source for the systcl setting

    • 1

  2. (Wow, this took a while -- I had to draw it out twice.)

    First, I don't see a route rule on Kentucky that gets packets to 172.16.200.0/24. And the no-gate implies (to me, since I've never handled this specific syntax before) that there's no default gateway on it.

    Routing 101: just because the network can get a packet to you, it doesn't mean it can get one back to where it came from. So even if you can get pings to Kentucky, the answers won't get back.

    ST1 has the same route specified twice:

    up route add -net 172.16.200.0 netmask 255.255.255.0 gw 10.10.10.5 dev eth1

    ...which is harmless because it says the same thing.

    Also, I think this line on ST2 is wrong:

    up route add -net 192.168.254.0 netmask 255.255.255.0 gw 10.10.10.5 dev eth0

    ...which I think means you are telling it that the 192.168.254.0/24 network is reachable via itself, on the wrong interface. It also contradicts the right route, which is in the first cluster on ST2:

    up route add -net 192.168.254.0 netmask 255.255.255.0 gw 10.10.10.6 dev eth1

    So. Get rid of the up route add -net 192.168.254.0 netmask 255.255.255.0 gw 10.10.10.5 dev eth0 on ST2, add a rule on Kentucky to either default-route (or just send packets for 172.16.200/24) via ST1, and it should work.

    If that doesn't work, do a netstat -rn on both ST1 and ST2 and post the output of that.

    • 1