fsmirror02:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
10.10.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3
10.10.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 10.10.2.1 0.0.0.0 UG 0 0 0 eth3

hmmm,
ist mir extrem schleiherhaft. wenn ich mal davon ausgehe, dass die arp-liste des rechners leer ist (und keine speziellen iptables-regeln existieren) , es also auch noch keinen kontakt von den clienten aus gegeben hat (dhcp, etc), wie entscheidet er, ob er ein paket an die ip 10.10.2.1 über eth0 oder eth3 ausgibt?

naja, geht ueber den ersten Routingeintrag den man findet...

also eth3 - nachdem keine Prios vergeben sind.

(Wuerde ich sagen)

Was meine These bestaetigt, ist dass wir mal folgende routings aufgebaut hatten

route add -net 192.168.1.0/24 192.168.1.1 eth0
route add -net 192.168.0.0/16 192.168.200.120 eth1

und er brav alles ans 192.168.1.0er-Netz ueber eth0 geschickt hat...und den Rest ueber eth1.... (War fuer so ein daemliches VPN....)

/Bernd

@ren22
+
mach mal ein
ifconfig eth0 down
und versuche einen rechner hinter der netzwerkkarte eth1 anzupingen!

Zitat

Original von bonsai
naja, geht ueber den ersten Routingeintrag den man findet...

also eth3 - nachdem keine Prios vergeben sind.

hmm
und was ist, wenn der rechner sich nicht hinter diesem device befindet, sondern hinter eth0?

ansonsten wäre es bestimmt sinnvoll, das modul mit einem debuglevel zu starten, also zb mit
modprobe tulip tulip_debug=5 oder höher und dann mal in der logdatei zu schauen, was das modul meldet.

Zitat

und was ist, wenn der rechner sich nicht hinter diesem device befindet, sondern hinter eth0?

???? Was meinst Du ????

Wenn der Rechner, den man erreichen will, sich nicht in einem Netz befindet, in das man routed - dann macht man beim Routing was falsch. (Den Satz sollte ich patentieren lassen!)

Wieso? Das Routing sagt doch aus, dass beide Rechner im selben Segment zu finden sind. - Wenn man nun natuerlich die Netzwerkkabel in zwei verschiedene (gleichlautende) Netzwerksegmente legt....dann braucht man mindestens NAT... *rotfl*

Quatsch - auch mit NAT kann es nicht gehen, .....da er ja immer in die eine Richtung routed....also selbst wenn er eine Anfrage auf der einen Seite bekommt......wird er die Antwort evtl. auf seiner "Default-Seite" rausschicken...

....wobei, da kommt wiederrum die ARP-Table ins Spiel....wenn er einen ARP-eintrag hat, koennte es klappen..

....aber da liegt der Clou:

fsmirror02:~# arp -a
notesserv.nbg.ct.dom (10.10.1.6) at 00:02:A5:EE:C4:8B [ether] on eth3
lx015.nbg.ct.dom (10.10.100.15) at 00:0A:5E:20:1B:3B [ether] on eth3
vpngate.nbg.ct.dom (10.10.2.1) at 00:04:75:74:A2:BA [ether] on eth3
fileserv.nbg.ct.dom (10.10.1.2) at 00:02:E3:00:02:5A [ether] on eth3
gateway2.nbg.ct.dom (10.10.0.2) at 00:04:75:FC:7B:69 [ether] on eth3
lx102.nbg.ct.dom (10.10.100.102) at 00:11:11:E6:B9:8C [ether] on eth3
fsntp01.nbg.ct.dom (10.10.16.31) at 00:04:23:BC:29:C1 [ether] on eth3
? (10.10.150.102) at 00:0D:60:F8:8D:49 [ether] on eth3
w002.nbg.ct.dom (10.10.101.2) at 00:0A:5E:20:1B:2A [ether] on eth3
mw040.nbg.ct.dom (10.10.101.140) at 00:15:58:2A:A7:60 [ether] on eth3
fsmirror01.nbg.ct.dom (10.10.16.1) at 00:04:23:BC:29:C1 [ether] on eth3
lx017.nbg.ct.dom (10.10.100.17) at 00:04:76:F3:24:0C [ether] on eth3