terminator
Goto Top

Debian Neuinstallation 2.Netzwerkkarte keine Verbindung

Hallo,

ich habe ein Debian 8.8 neu installiert. Der Rechner hat 2 NIC onbord.
Die Karten sind per network/interfaces konfigurtiert.
1. Karte (eth0) funktioniert
2. Karte pingt nur localhost und die eigene IP, aber nicht in ihrem Netz oder nach draußen

network/interefaces
allow-hotplug eth0
iface eth0 inet static
        address 192.168.1.203
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        gateway 192.168.1.200
        dns-nameservers 192.168.1.200
        dns-search domain.de


allow-hotplug eth1
iface eth1 inet static
        address 192.168.6.203
        netmask 255.255.255.0
        network 192.168.6.0
        broadcast 192.168.6.255
        dns-nameservers 8.8.8.8
Ich hatte auch mal in eth1 den gateway Eintrag drin, aber das soll wohl nur für eine Karte eingetragen werden.

route
root@s03:~# route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         sgw.domain.de 0.0.0.0         UG    0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.6.0     *               255.255.255.0   U     0      0        0 eth1
Prüfungen des device namens "eth1" haben auch nichts ergeben, Kabel / Stecker ebenfalls nicht.
Was kann ich noch machen, um das Problem zu finden?

Danke & Gruß

Content-ID: 338636

Url: https://administrator.de/forum/debian-neuinstallation-2-netzwerkkarte-keine-verbindung-338636.html

Ausgedruckt am: 26.12.2024 um 01:12 Uhr

certifiedit.net
certifiedit.net 23.05.2017 aktualisiert um 11:42:45 Uhr
Goto Top
Hallo Terminator,

ifconfig eth1 up oder einfach mal ein reboot.

VG

PS: ein externer DNS Server ohne Gateway ist etwas sinnlos.
terminator
terminator 23.05.2017 aktualisiert um 12:00:40 Uhr
Goto Top
das bringt keine Rückme.ldung und keine Änderung.
Ich hatte es auch bereits mit ifdown eth1/ ifup eth1 versucht.

wie gesagt, ein ping auf die eigene IP von eth1 geht.

Einen gateway Eintrag hatte ich ebenfalls drin, das bringt aber dann Fehlermeldungen beim Aktivieren des devices. Dazu habe ich gelesen, dass nur eine Karte einen Gatewayeintrag haben darf, deswegen ist der wieder raus.
SlainteMhath
SlainteMhath 23.05.2017 um 12:01:15 Uhr
Goto Top
Moin,

PS: ein externer DNS Server ohne Gateway ist etwas sinnlos.
Der 2te DNS Eintrag für den Google-DNS ist sowie Sinnfrei. wann soll denn welcher DNS verwendet werden?

@terminator:
Zeig mal ein "ip a" und "ip linK" bitte.

lg,
Slainte
aqui
aqui 23.05.2017 um 12:17:31 Uhr
Goto Top
PS: ein externer DNS Server ohne Gateway ist etwas sinnlos.
Und über den Unsinn Google DNS zu nehmen wurde hier ja auch schon genügend diskutiert.
Den DNS Server im Interface zu setzen ist kontraproduktiv und sollte man niemals machen, dafür ibt es die resolv.conf.
Kollege SlainteMhath hat es ja schon gesagt.

Interessant wäre zu wissen ob reine IP Adressen in den jeweils lokalen Segmenten .1.0 und .6.0 pingbar sind ??
Am besten KEINE Winblows Rechner pingen, denn dort ist ICMP (Ping) immer deaktiviert !
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Besser hier also Drucker usw. nehmen...oder die lokale Win Firewall entsprechend anpassen !
Denkbar auch ein Linkspeed oder Duplex Mismatch. Also auch mal die Link LED an NIC und Switch kontrollieren.
terminator
terminator 23.05.2017 um 12:18:05 Uhr
Goto Top
Ich habe den DNS Eintrag rausgenommen, denke nicht dass es der Grund für das Problem ist.

Hier sind die Rückgaben von ip
root@s03:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 84:2b:2b:44:ce:84 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.203/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::862b:2bff:fe44:ce84/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 84:2b:2b:44:ce:85 brd ff:ff:ff:ff:ff:ff
    inet 192.168.6.203/24 brd 192.168.6.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::862b:2bff:fe44:ce85/64 scope link
       valid_lft forever preferred_lft forever
4: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
    inet 172.16.44.1/24 brd 172.16.44.255 scope global vmnet8
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fec0:8/64 scope link
       valid_lft forever preferred_lft forever
5: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
    inet 172.16.139.1/24 brd 172.16.139.255 scope global vmnet1
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fec0:1/64 scope link
       valid_lft forever preferred_lft forever
root@s03:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 84:2b:2b:44:ce:84 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 84:2b:2b:44:ce:85 brd ff:ff:ff:ff:ff:ff
4: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
5: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
freeker
freeker 23.05.2017 um 13:31:39 Uhr
Goto Top
Hallo,

Versuche mal statt "allow-hotplug ethX" mit "auto ethX" (das X natürlich ersetzen)
Debian Manual

"auto <name>" die Schnittstelle <name> während des Systemstarts aktivieren
"allow-hotplug <name>" die Schnittstelle <name> aktivieren, wenn der Kernel ein Hotplug-Ereignis von der Schnittstelle empfängt



Gruß freeker
SlainteMhath
SlainteMhath 23.05.2017 um 13:43:00 Uhr
Goto Top
@freeker
Das Interface ist ja aktiviert, an auto-* kanns also fast nicht liegen

@terminator
Sieht soweit korrekt aus. Hast du von aqui erwähnten Test schon gemacht?
terminator
terminator 23.05.2017 um 13:52:25 Uhr
Goto Top
Umstellung auf auto eth1 bringt keine Änderung

Ping ins 1er Netz geht
Ping nach draußen geht (über 1er Netz)

Ping im 6er Netz auf 3 Linux geht nicht.
Switche / LED geprüft.

Überraschung:
traceroute im 6er Netz geht. Aber mit riesigen Ping Zeiten.
Ich habe wohl ein routing Problem oder so.

Ansonsten zu Linkspeed etc. Das Gerät ist zwar neu aufgesetzt, aber nicht neu verkabelt. Vorher war alles gut.
terminator
terminator 23.05.2017 aktualisiert um 17:06:20 Uhr
Goto Top
Ich versteh es nicht.
Ping ist im 6er Netz erlaubt. Andere Maschinen dort können es auch.
Auf der Firewall gibt es keine Logs dazu.
Das trace braucht ewig, aber kommt an (sofort).
Die VMware verweigert eth1 als zusätzliches Device für das Virtuelle Netzwerk, eth1 wird nicht aufgeführt/angeboten.


Hat sich erledigt, die Verkabelung war nicht in Ordnung. Scheinbar gibt es auch halb kaputte Kabel.

Vielen Dank an die Unterstützer!
aqui
aqui 24.05.2017 um 11:19:27 Uhr
Goto Top
Ich habe wohl ein routing Problem oder so.
Das kann ja niemals sein !
Das Default gateway ist ja nur auf NIC 1 installiert, was ja auch richtig ist. NIC 2 ist ohne also kann das Routing zentral nur über NIC 1 rausgehen.
Ist ja aber auch gar nicht das Thema denn die beiden lokalen IP Netze an NIC 1 und NIC 2 werden ja niemals geroutet !! Dort kann dein rechner alle Endgeräte logischerweise direkt erreichen und macht auch kein Routing.
Zumal Routing im Debian selber per Default so oder so deaktiviert ist.
Das ist es also ganz sicher nicht.

Wenn du die Firewall sicher ausschliessen kannst (ICMP Blocking etc) dann kann es ja nur ein Autonegotiation problem mit dem Switch oder sowas sein. Dazu würden auch die grottenschlechten Traceroute Zeiten passen.
OK, Verkabelung...zu spät gelesen...
Also alles wie bereits vermutet !!!