eth0: 192.168.0.0/24 - local lan A
eth1: 220.127.116.11 - internet link - default route
eth2: 192.168.10.0/24 - local lan B
eth3: 192.168.20.0/24 - local lan C
Lan A - Default routing to eth0
Lan B - Default routing to eth2
Lan c - Default routing to another server but the workstations has static routing to this server too.
Everything is working fine on Opensuse 11.1 until I upgrade this sever to Opensuse 11.2 ( Reinstall, not update at all ). After upgrade to 11.2 the routing across local lan interfaces simply not work, if you try to ping lan-to-lan you got the message: Network unreachable, even with the IP Forward enable, but the default route is working fine trough the SNAT.
I’ve come back to Opensuse 11.1 and everything become normal, does anyone have an problem like this? Maybe a bug?
PS: I do not try to disable the AppArmor, next weekend I will try Opensuse 11.2 without the AppArmor and post here anyway.
I will not say that your explanation does not conform to what there is going on in the system, but I see it as just an explanation of what the routing table is. But the routing table itself is missing. So we can not do our own assessment, but are bound to your interpretation (which may be faulty, because you have a problem).
So please the ouput of
Also I may add that on different places in your story you call things ‘default route’ where you mean ‘route’. There is but one default route in a system, that is why it is named default, the route to be taken when no others are found for a packet.
Even /sbin/route shows the exact same routing table as stated above but unfortunately the service (loadbalancer) only returns packets from eth0 to the requesting client. I figured it goes something like this:
1.) Request received by <CLIENT_IP> going to <LOADBALANCER_IP> (src=CLIENT_IP, dst=LOADBALANCER_IP)
2.) Since configuration states, that the service is now serving in the 172.17.x.x subnet, the LB redirects to eth1 (src=CLIENT_IP, dst=172.17.2.x)
3.) actual server gets request, tries to send the answer but for whatever reason now uses the default gateway (src=172.17.2.x, dst=CLIENT_IP via 172.16.0.1)
4.) Loadbalancer receives package initially sent to 172.17.2.x from 172.16.2.x subnet and discards the package due to the ip/subnet clash
So I assume there must be a change in how SuSE handles the packages from versions 11.0/11.1 to 11.2 but I just can’t figure it out.
Can anyone give me a hint of what I can do to make it work again the way it worked in 11.0/11.1?
Not sure why there’s a problem with 11.2 vs. 11.1 but have you used Wire Shark to trace the packets from the “who has” requests?
For both of you what happens in 11.2 with traceroute?
AFAIG, it sounds to me like 11.1 had the fault and 11.2 is operating properly as a lan, ie, doesn’t know the other networks and forwards packets to the router.
So, 11.2 should be set up as a Vlan that treats 172.16.2 and 172.17.2 as one lan. Is that possible?
When I do a traceroute on eth0 to my local systems internet address I get a perfect connection to my IP over 7 hops. However with eth1 this does not work at all.
1 * * *
2 * * *
3 * * *
# repeated several times
Unfortunately I’m not allowed to change the subnet masks in this network I don’t know why the server refuses to answer the request when incoming over eth1. On eth0 everything works perfectly but as soon as the services switch to the other interface we only get timeouts from the outside
I even put the ssh-daemon into verbose logging mode to see if he prints any useful messages but the daemon itself does not get the connection at all. So my request gets discarded somewhere between the OSI layer 4 and 7 of my server I guess.
Unfortunately my /var/log/messages and /var/log/warn does not give me any hint on discarded packages.
When I initially set up the server I forgot to enter the DNS/Routing configuration and I got a lot of “martian source” messages but now I don’t get any hint on what’s going on with my packets.
I forgot to mention. I’ve had a problem or 2 when the DHCP lease expires, then the connection will not automatically reconnect.
It shouldn’t be the case for fallover servers but that could be part of your problem if you’re using DHCP to obtain IP address.