Debian und 4 Netzwerkkarten

Folgendes Problem: Ich habe hier einen Debian Rechner stehen der mit 4 Netzwerkarten ausgerüstet ist. Wenn ich nun ein Netzwerkkabel in eth0 stecke so lassen sich sämtliche IP´s auf dem Debianrechner von aussen anpingen. Sprich es werden alle Packete über eth0 angenommen. Wenn ich das Kabel nun in eth1-3 stecke kann ich die Karten gar nicht anpingen (arpcache vorher natürlich gelöscht). Das selbe vom Debian Rechner aus. Wenn eth0 eingestöpselt ist kann ich ins Netz pingen, aber halt von keiner anderen Karte aus?!? Wieso trennt das System die Karten nicht richtig??

Debian Minimalinstallation
4 Netzwerkkarten 3com 905x
IP´s 192.168.1.1-4

Habe schon mehrfach Rechner mit 3 Karten eingerichtet, derartiges aber noch nie gesehen...

Kennt jemand das Problem?? Habe ich einen Denkfehler?? Danke!
 
Poste mal bitte den Inhalt der /etc/network/interfaces und den Output von route und ifconfig (ggf. kommentiert). Das ist mir fuer eine Diagnose zu wage.
 
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# The first network card - this entry was created during the Debian installation
# (network, broadcast and gateway are optional)
auto eth0 eth1 eth2 eth3
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

iface eth1 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

iface eth2 inet static
address 192.168.1.3
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

iface eth3 inet static
address 192.168.1.4
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255



Der Output von route:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth2
192.168.1.0 * 255.255.255.0 U 0 0 0 eth3



und von ifconfig:

eth0 Link encap:Ethernet HWaddr 00:04:75:F3:15:7A
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3644 errors:0 dropped:0 overruns:0 frame:0
TX packets:1411 errors:0 dropped:0 overruns:0 carrier:1378
collisions:0 txqueuelen:100
RX bytes:533408 (520.9 KiB) TX bytes:86346 (84.3 KiB)
Interrupt:11 Base address:0xa400

eth1 Link encap:Ethernet HWaddr 00:04:75:F3:10:CB
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1602 errors:0 dropped:0 overruns:0 frame:0
TX packets:68 errors:0 dropped:0 overruns:0 carrier:66
collisions:0 txqueuelen:100
RX bytes:227930 (222.5 KiB) TX bytes:5676 (5.5 KiB)
Interrupt:10 Base address:0xa000

eth2 Link encap:Ethernet HWaddr 00:04:75:E9:88:30
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:62066 errors:0 dropped:0 overruns:1 frame:0
TX packets:507 errors:0 dropped:0 overruns:0 carrier:505
collisions:0 txqueuelen:100
RX bytes:9014677 (8.5 MiB) TX bytes:31256 (30.5 KiB)
Interrupt:5 Base address:0x9400

eth3 Link encap:Ethernet HWaddr 00:10:4B:C1:A7:8F
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:85294 errors:0 dropped:0 overruns:0 frame:0
TX packets:50 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:12401548 (11.8 MiB) TX bytes:4710 (4.5 KiB)
Interrupt:9 Base address:0x9800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1388 errors:0 dropped:0 overruns:0 frame:0
TX packets:1388 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:134858 (131.6 KiB) TX bytes:134858 (131.6 KiB)


Ich muss sagen ich kann nichts auffäliges entdecken...

Übrigens kriege ich die Karten erwartungsgemäss sauber getrennt wenn ich ihnen unterschiedliche Netze zuweise, also eth0 192.x.x.x, eth1 172.x.x.x usw.
 
Sieht wirklich sehr unauffaellig auf und koennte fast ein Bug sein. Ich habe gerade noch ein bischen rumge'google't und auch nichts passendes gefunden. Da ein Mantainer den man hier belaestigen koennte nicht klar abzustecken ist wuerd ich vorschlagen das du den Fehler mal ins BTS einspeist. http://www.debian.org/Bugs/Reporting

Vieleicht ist auch den Mailinglisten auch noch jemand der Rat weis. http://lists.debian.org/


"Eine wirklich gute Frage"

Leicht verwirrt,
YoDa
 
Du koenntest vieleicht auch noch versuchen die proposed-updates fuer woody zu installieren. Vieleicht ist das Problem dort schon geloest, auch wenn ich im BTS nichts passendes gefunden habe.

deb ftp://ftp.de.debian.org/debian/ woody-proposed-updates main contrib
 
Aktueller Stand:

Ich habe nun eth0 und eth1 für verschiedene Subnetze konfiguriert worauf diese nun sauber von einander getrennt agieren. eth2 und eth3 sind im selben Subnetz und haben das Problem übernommen. eth2 reagiert auf beide Adressen und antwortet, eth3 reagiert auf nichts empfängt jedoch die Packete. Interessant hierbei der arp-reply den ich per tcpdump aufgezeichnet habe:

Ping auf eth2 mit Reply:

12:13:41.086953 arp who-has 192.168.1.170 tell 192.168.1.175
12:13:41.086964 arp reply 192.168.1.170 is-at 0:4:75:f3:10:cb
12:13:41.087169 192.168.1.175 > 192.168.1.170: icmp: echo request (DF)
12:13:41.087208 192.168.1.170 > 192.168.1.175: icmp: echo reply
12:13:42.087332 192.168.1.175 > 192.168.1.170: icmp: echo request (DF)
12:13:42.087349 192.168.1.170 > 192.168.1.175: icmp: echo reply
12:13:46.084121 arp who-has 192.168.1.175 tell 192.168.1.170
12:13:46.084282 arp reply 192.168.1.175 is-at 0:0:e2:2c:1e:d1
12:13:52.002406 arp who-has 192.168.1.180 tell 192.168.1.175
12:13:52.002413 arp reply 192.168.1.180 is-at 0:4:75:f3:10:cb
12:13:52.002582 192.168.1.175 > 192.168.1.180: icmp: echo request (DF)
12:13:52.002598 192.168.1.180 > 192.168.1.175: icmp: echo reply
12:13:52.998714 192.168.1.175 > 192.168.1.180: icmp: echo request (DF)
12:13:52.998727 192.168.1.180 > 192.168.1.175: icmp: echo reply


Ping auf eth3 ohne Reply:

12:15:50.313285 arp who-has 192.168.1.170 tell 192.168.1.175
12:15:50.313299 arp reply 192.168.1.170 is-at 0:4:75:e9:88:30
12:15:50.313472 192.168.1.175 > 192.168.1.170: icmp: echo request (DF)
12:15:51.353912 192.168.1.175 > 192.168.1.170: icmp: echo request (DF)
12:16:08.747577 arp who-has 192.168.1.180 tell 192.168.1.175
12:16:08.747586 arp reply 192.168.1.180 is-at 0:4:75:e9:88:30
12:16:08.747757 192.168.1.175 > 192.168.1.180: icmp: echo request (DF)
12:16:09.766254 192.168.1.175 > 192.168.1.180: icmp: echo request (DF)


Wie man sieht sehen sich beide Interfaces als Inhaber der IP´s, während jedoch nur eth2 antwortet.
An den Karten liegt es nicht (nur proforma ausprobiert) da ich eth2 und eth3 getauscht habe, zumal sich das Problem vorher auf alle vier Karten erstreckt hat (als sie alle im selben Subnetz waren).

Aktuelle Konfiguration:

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# The first network card - this entry was created during the Debian installation
# (network, broadcast and gateway are optional)
auto eth0 eth1 eth2 eth3
iface eth0 inet static
address 192.168.1.4
netmask 255.255.255.248
network 192.168.1.0
broadcast 192.168.1.7
gateway 192.168.1.3

iface eth1 inet static
address 192.168.1.13
netmask 255.255.255.248
network 192.168.0.8
broadcast 192.168.255.15

iface eth2 inet static
address 192.168.1.170
netmask 255.255.255.128
network 192.168.1.128
broadcast 192.168.1.255

iface eth3 inet static
address 192.168.1.180
netmask 255.255.255.128
network 192.168.1.128
broadcast 192.168.1.255


eth0 Link encap:Ethernet HWaddr 00:50:BF:D6:91:7C
inet addr:192.168.1.4 Bcast:192.168.1.7 Mask:255.255.255.248
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6021 errors:0 dropped:0 overruns:0 frame:0
TX packets:500 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1286340 (1.2 MiB) TX bytes:32057 (31.3 KiB)
Interrupt:5 Base address:0xa000

eth1 Link encap:Ethernet HWaddr 00:04:75:F3:15:7A
inet addr:192.168.1.13 Bcast:192.168.255.15 Mask:255.255.255.248
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2039 errors:0 dropped:0 overruns:0 frame:0
TX packets:34 errors:0 dropped:0 overruns:0 carrier:30
collisions:0 txqueuelen:100
RX bytes:304715 (297.5 KiB) TX bytes:2040 (1.9 KiB)
Interrupt:11 Base address:0xa400

eth2 Link encap:Ethernet HWaddr 00:04:75:F3:10:CB
inet addr:192.168.1.170 Bcast:192.168.1.255 Mask:255.255.255.128
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15112 errors:0 dropped:0 overruns:0 frame:0
TX packets:402 errors:0 dropped:0 overruns:0 carrier:63
collisions:0 txqueuelen:100
RX bytes:2215659 (2.1 MiB) TX bytes:32366 (31.6 KiB)
Interrupt:10 Base address:0xa000

eth3 Link encap:Ethernet HWaddr 00:04:75:E9:88:30
inet addr:192.168.1.180 Bcast:192.168.1.255 Mask:255.255.255.128
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12990 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:3
collisions:0 txqueuelen:100
RX bytes:1921705 (1.8 MiB) TX bytes:360 (360.0 b)
Interrupt:9 Base address:0x9800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:393 errors:0 dropped:0 overruns:0 frame:0
TX packets:393 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:37578 (36.6 KiB) TX bytes:37578 (36.6 KiB)


Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.248 U 0 0 0 eth0
192.168.1.8 * 255.255.255.248 U 0 0 0 eth1
localnet * 255.255.255.128 U 0 0 0 eth2
localnet * 255.255.255.128 U 0 0 0 eth3
default 192.168.1.3 0.0.0.0 UG 0 0 0 eth0


Ein Update habe ich noch nicht ausprobiert. Werde es aber tun und das Ergebniss posten...
 
das ganze problem besteht meines erachtens wegen deiner ip bzw subnet wahl....2 karten dürfen unter normalen umständen nicht im selben netzt sein, da dein system dann keine ahnung hat auf welchem device die daten verschickt werden.
unter openbsd kannst du die netzwerkkarten so einrichten, dass sie einen switch/bridge ersetzen (also alle im gleichen netz sind). unter linux gibt es mit sicherheit einen entsprechenden kernel patch.
 
DelumaX:
Nur Interessehalber.. warum möchte man 4 NICs in einem Netz?
Und bei deinem Problem tippe ich ganz einfach mal auf ein RoutingProblem, da du mit Sicherheit nicht der erste bist, der das versucht (hat).
 
aber langen da nicht zwei? Außerdem bringt das routen ja nichts wenn du im selben netzt bleibst. Dann ist dein router ja einfach zu umgehen.
 
@soox: Bei ausgehenden Verbindungen würde ich dies noch verstehen wenn beide einen connect haben. In meiner Anordnung hat jedoch immer nur eine der beiden Karten einen connect gehabt und zumindest diese Tatsache sollte bemerkt werden anstatt ein Interface einfach tot zu schalten. Jedoch eingehende Verbindungen sollten jawohl ohne Probleme korrekt behandelt werden können. Ich sehe kein Problem zumindest einen geordneten arp-reply zustande zu bringen! Ich bin zumindest noch am forschen und werde posten wenn ich mehr weiss!!

@the void: Neben dem Anwendungsbeispiel von soox hat das etwas mit gewachsenen Netzwerkstrukturen sowie routing und Kundenwünschen etc. zu tun. Auf nähere Einzelheiten möchte ich jedoch nicht eingehen... Zumal du vieleicht gesehen hast das ich in der zweiten Beschreibung bereits Subnetze gebildet habe und mir das Prob nur zufällig aufgefallen ist während alle im selben Netz waren.
 
Zurück
Oben