Discussion:
Ping-Mysterium
(zu alt für eine Antwort)
Michael Landenberger
2017-02-14 11:22:35 UTC
Permalink
Raw Message
Hallo,

gegeben sei ein kleines Firmen-LAN mit einem Draytek Vigor2860 als "Zentrale".
Das LAN arbeitet im Subnetz 192.168.0.0/24.

An den Draytek ist ein TP-Link-Router angeschlossen, der aber nur als Switch
und WLAN-Accesspoint arbeitet. D. h. der TP-Link ist über einen seiner
LAN-Ports mit dem Draytek verbunden, sein WAN-Port ist unbenutzt.

Im Web-Interface des Draytek gibt es die Möglichkeit, LAN-Clients anzupingen.
Bei fast allen Clients im LAN funktioniert das auch, alle antworten auf Pings
vom Draytek. Nur Pings vom Draytek- zum TP-Link-Router laufen in einen
Timeout. Ich schließe aus, dass die Ursache dafür beim Draytek-Router liegt,
denn andere Clients kann er ja anpingen.

Am TP-Link-Router liegt es allerdings auch nicht, denn der antwortet brav auf
Pings von anderen Clients im LAN. Nur die Pings vom Draytek beantwortet er
nicht.

Ansonsten funktioniert alles wie es soll. Der Draytek routet und der TP-Link
switcht ;-)

Hat jemand eine Erklärung für das merkwürdige Verhalten des TP-Link-Routers?

Gruß

Michael
Shinji Ikari
2017-02-14 11:29:56 UTC
Permalink
Raw Message
Guten Tag
Post by Michael Landenberger
Nur Pings vom Draytek- zum TP-Link-Router laufen in einen
Timeout.
Am TP-Link-Router liegt es allerdings auch nicht, denn der antwortet brav auf
Pings von anderen Clients im LAN.
Antworten denn die Clients hinter dem TP-Link auch auf Pings von
anderen Clients im Lan (vor dem TP-Link)?
Post by Michael Landenberger
Ansonsten funktioniert alles wie es soll. Der Draytek routet und der TP-Link
switcht ;-)
Ggf. blockt aber der TP-Link alle Pings, die durch ihn hindurch gehen
sollen?
Michael Landenberger
2017-02-14 12:55:35 UTC
Permalink
Raw Message
Post by Shinji Ikari
Antworten denn die Clients hinter dem TP-Link auch auf Pings von
anderen Clients im Lan (vor dem TP-Link)?
Ja, das funktioniert in beiden Richtungen.

Am TP-Link hängt u. a. ein Server, auf dem eine Netzwerk-Monitoring-Software
läuft. Die schickt u. a. Pings an verschiedene Clients im LAN, darunter auch
an den TP-Link selbst, aber auch andere Clients wie z. B. Arbeitsstationen und
Drucker, die z. T. an anderen LAN-Ports des Draytek hängen und teilweise an
weitere Switches angeschlossen sind. Und natürlich pingt die
Monitoring-Software auch den Draytek-Router an. Das alles funktioniert
reibungslos. Ebenso kann man vom Draytek-Router aus den Server anpingen (das
wäre dann die umgekehrte Richtung durch den TP-Link). Einzig und allein Pings
vom Draytek zum TP-Link laufen in einen Timeout.
Post by Shinji Ikari
Post by Michael Landenberger
Ansonsten funktioniert alles wie es soll. Der Draytek routet und der
TP-Link switcht ;-)
Ggf. blockt aber der TP-Link alle Pings, die durch ihn hindurch gehen
sollen?
Wenn er das täte, würde das Netzwerk-Monitoring nicht funktionieren, denn der
dafür zuständige Server hängt ja wie geschrieben auch an dem TP-Link-Router,
monitort aber Clients sowohl vor als auch hinter dem TP-Link. Es würde mich
auch wundern, wenn ein einfacher Router (der in diesem Fall außerdem nur als
Switch genutzt wird) Pings zwischen einzelnen LAN-Ports nicht durchlassen
würde. AFAIK kann man bei solchen Geräten Pings nur WAN-seitig blockieren.

Gruß

Michael
kay
2017-02-14 13:59:12 UTC
Permalink
Raw Message
Post by Michael Landenberger
Post by Shinji Ikari
Antworten denn die Clients hinter dem TP-Link auch auf Pings von
anderen Clients im Lan (vor dem TP-Link)?
Ja, das funktioniert in beiden Richtungen.
Da du den als Wlan-Accesspoint nutzt, meinte er sicher WLAN-Clients -
was du aber nicht explizit bestätigst. Nur FYI.
Post by Michael Landenberger
Post by Shinji Ikari
Post by Michael Landenberger
Ansonsten funktioniert alles wie es soll. Der Draytek routet und der
TP-Link switcht ;-)
Und dessen DHCP und firewall sind auch ausgeschaltet, ebenso
DMZ-Optionen u.a. was pakete Blockieren oder manipulieren könnte?
Post by Michael Landenberger
Post by Shinji Ikari
Ggf. blockt aber der TP-Link alle Pings, die durch ihn hindurch gehen
sollen?
Wenn er das täte, würde das Netzwerk-Monitoring nicht funktionieren, denn der
dafür zuständige Server hängt ja wie geschrieben auch an dem TP-Link-Router,
An einem von dessen LAN-Ports, richtig?
Hast du da mal verschiedene Ports probiert und dann getestet. Nur zur
Sicherheit.
Post by Michael Landenberger
monitort aber Clients sowohl vor als auch hinter dem TP-Link. Es würde mich
auch wundern, wenn ein einfacher Router (der in diesem Fall außerdem nur als
Switch genutzt wird) Pings zwischen einzelnen LAN-Ports nicht durchlassen
würde. AFAIK kann man bei solchen Geräten Pings nur WAN-seitig blockieren.
Oder über die Bridge die LAN und WLAN miteinander verbindet! Das wäre
meine Vermutung das diese Bridge nicht 100% transparent ist und darum
Pakete von ihren eigenen LAN Ports annimmt, aber eventuell einen
speziellen DMZ (oder ähnlichen) Port hat von dem sie einiges Blockiert.

Sonst bliebe IMHO nur noch die Vermutung das TP-Link geräte pakete von
DrayTek Geräten abblocken - evtl. über deren MAC-Adresse. Glaube ich
eher nicht. Oder die Ping-option in deinem DrayTek ist kaputt. Eher
warscheinlich.

Kay
--
Posted via SN
Michael Landenberger
2017-02-15 09:22:36 UTC
Permalink
Raw Message
Post by kay
Post by Michael Landenberger
Post by Shinji Ikari
Antworten denn die Clients hinter dem TP-Link auch auf Pings von
anderen Clients im Lan (vor dem TP-Link)?
Ja, das funktioniert in beiden Richtungen.
Da du den als Wlan-Accesspoint nutzt, meinte er sicher WLAN-Clients -
was du aber nicht explizit bestätigst. Nur FYI.
Es funktionieren WLAN- und Ethernet-Clients.
Post by kay
Post by Michael Landenberger
Post by Shinji Ikari
Post by Michael Landenberger
Ansonsten funktioniert alles wie es soll. Der Draytek routet und der
TP-Link switcht ;-)
Und dessen DHCP und firewall sind auch ausgeschaltet, ebenso
DMZ-Optionen u.a. was pakete Blockieren oder manipulieren könnte?
DHCP ist natürlich ausgeschaltet. Der einzige DHCP-Server im LAN ist der
Draytek. Firewall und DMZ spielen beim Betrieb des TP-Link als Switch keine
Rolle, denn beides wirkt sich nur auf WAN-LAN-Verbindungen aus, nicht auf
LAN-LAN-Verbindungen (und nur solche gibt es bei einem Switch). Aber selbst
wenn es sich auswirken würde: warum ist dann nur eine einzige Verbindung
betroffen, nämlich der Uplink vom Draytek zum TP-Link?
Post by kay
Post by Michael Landenberger
Wenn er das täte, würde das Netzwerk-Monitoring nicht funktionieren, denn
der dafür zuständige Server hängt ja wie geschrieben auch an dem
TP-Link-Router,
An einem von dessen LAN-Ports, richtig?
Hast du da mal verschiedene Ports probiert und dann getestet. Nur zur
Sicherheit.
Das habe ich noch nicht getan, werde ich mal versuchen. Wobei ich hier nicht
den Server an einen anderen LAN-Port hängen müsste (auf Pings vom Server
antwortet der TP-Link ja), sondern den Draytek-Router. Der Uplink von diesem
hängt ja auch an einem LAN-Port des TP-Link, und genau auf dieser Strecke
funktionieren die Pings nicht. Wobei ich das hier nur in einer Richtung testen
kann, denn nur der Draytek verfügt über die Möglichkeit, LAN-Clients über sein
Web-Interface anzupingen.
Post by kay
Oder über die Bridge die LAN und WLAN miteinander verbindet! Das wäre
meine Vermutung das diese Bridge nicht 100% transparent ist und darum
Pakete von ihren eigenen LAN Ports annimmt, aber eventuell einen
speziellen DMZ (oder ähnlichen) Port hat von dem sie einiges Blockiert.
Der Uplink vom Draytek zum TP-Link (das ist wie geschrieben die einzige
Verbindung, auf der Pings nicht beantwortet werden) ist kabelgebunden. Über
alle anderen Verbindungen, egal ob LAN oder WLAN, funktionieren die Pings.
Post by kay
Sonst bliebe IMHO nur noch die Vermutung das TP-Link geräte pakete von
DrayTek Geräten abblocken - evtl. über deren MAC-Adresse. Glaube ich
eher nicht.
Ich auch nicht, zumal der TP-Link als Switch arbeitet und (als popeliger
SoHo-Router) gar nicht die Möglichkeit bietet, den Datenverkehr zwischen
seinen LAN-Ports irgendwie zu filtern.
Post by kay
Oder die Ping-option in deinem DrayTek ist kaputt. Eher
warscheinlich.
Könnte zwar sein, aber alle anderen Clients antworten auf Pings vom Draytek.

Nunja, solange sonst alles funktioniert, kann mir das eigentlich egal sein.
Trotzdem wüsste ich gerne, was solche Phänomene verursacht. Vielleicht kann
man dieses Wissen ja an anderer Stelle mal brauchen ;-)

(Edit: Sorry für Doppelpost, irgendwie hat's die References zerhackstückt)

Gruß

Michael
Michael Landenberger
2017-02-15 09:21:09 UTC
Permalink
Raw Message
Post by kay
Post by Michael Landenberger
Post by Shinji Ikari
Antworten denn die Clients hinter dem TP-Link auch auf Pings von
anderen Clients im Lan (vor dem TP-Link)?
Ja, das funktioniert in beiden Richtungen.
Da du den als Wlan-Accesspoint nutzt, meinte er sicher WLAN-Clients -
was du aber nicht explizit bestätigst. Nur FYI.
Es funktionieren WLAN- und Ethernet-Clients.
Post by kay
Post by Michael Landenberger
Post by Shinji Ikari
Post by Michael Landenberger
Ansonsten funktioniert alles wie es soll. Der Draytek routet und der
TP-Link switcht ;-)
Und dessen DHCP und firewall sind auch ausgeschaltet, ebenso
DMZ-Optionen u.a. was pakete Blockieren oder manipulieren könnte?
DHCP ist natürlich ausgeschaltet. Der einzige DHCP-Server im LAN ist der
Draytek. Firewall und DMZ spielen beim Betrieb des TP-Link als Switch keine
Rolle, denn beides wirkt sich nur auf WAN-LAN-Verbindungen aus, nicht auf
LAN-LAN-Verbindungen (und nur solche gibt es bei einem Switch). Aber selbst
wenn es sich auswirken würde: warum ist dann nur eine einzige Verbindung
betroffen, nämlich der Uplink vom Draytek zum TP-Link?
Post by kay
Post by Michael Landenberger
Wenn er das täte, würde das Netzwerk-Monitoring nicht funktionieren, denn
der dafür zuständige Server hängt ja wie geschrieben auch an dem
TP-Link-Router,
An einem von dessen LAN-Ports, richtig?
Hast du da mal verschiedene Ports probiert und dann getestet. Nur zur
Sicherheit.
Das habe ich noch nicht getan, werde ich mal versuchen. Wobei ich hier nicht
den Server an einen anderen LAN-Port hängen müsste (auf Pings vom Server
antwortet der TP-Link ja), sondern den Draytek-Router. Der Uplink von diesem
hängt ja auch an einem LAN-Port des TP-Link, und genau auf dieser Strecke
funktionieren die Pings nicht. Wobei ich das hier nur in einer Richtung testen
kann, denn nur der Draytek verfügt über die Möglichkeit, LAN-Clients über sein
Web-Interface anzupingen.
Post by kay
Oder über die Bridge die LAN und WLAN miteinander verbindet! Das wäre
meine Vermutung das diese Bridge nicht 100% transparent ist und darum
Pakete von ihren eigenen LAN Ports annimmt, aber eventuell einen
speziellen DMZ (oder ähnlichen) Port hat von dem sie einiges Blockiert.
Der Uplink vom Draytek zum TP-Link (das ist wie geschrieben die einzige
Verbindung, auf der Pings nicht beantwortet werden) ist kabelgebunden. Über
alle anderen Verbindungen, egal ob LAN oder WLAN, funktionieren die Pings.
Post by kay
Sonst bliebe IMHO nur noch die Vermutung das TP-Link geräte pakete von
DrayTek Geräten abblocken - evtl. über deren MAC-Adresse. Glaube ich
eher nicht.
Ich auch nicht, zumal der TP-Link als Switch arbeitet und (als popeliger
SoHo-Router) gar nicht die Möglichkeit bietet, den Datenverkehr zwischen
seinen LAN-Ports irgendwie zu filtern.
Post by kay
Oder die Ping-option in deinem DrayTek ist kaputt. Eher
warscheinlich.
Könnte zwar sein, aber alle anderen Clients antworten auf Pings vom Draytek.

Nunja, solange sonst alles funktioniert, kann mir das eigentlich egal sein.
Trotzdem wüsste ich gerne, was solche Phänomene verursacht. Vielleicht kann
man dieses Wissen ja an anderer Stelle mal brauchen ;-)

Gruß

Michael
Chr. Maercker
2017-02-16 08:01:46 UTC
Permalink
Raw Message
Post by Michael Landenberger
Ansonsten funktioniert alles wie es soll. Der Draytek routet und der TP-Link
switcht ;-)
Hat jemand eine Erklärung für das merkwürdige Verhalten des TP-Link-Routers?
Für ähnliche Aufgaben suche ich seit langem eine Art Traceroute für OSI
level 2, mit dem also zu sehen ist, welche Switches die Pakete bis zum
angegebenen Ziel durchlaufen.

Pack mal einen Minihub in die Leitung am Routerport (also der, der nicht
antwortet) und zapfe dort den Datenstrom mit Wireshark an. Dort müsste
ja zu sehen sein, ob die ICMP-Pakete am Router überhaupt ankommen.
--
CU Chr. Maercker.
Sven Hartge
2017-02-16 10:26:43 UTC
Permalink
Raw Message
Post by Chr. Maercker
Post by Michael Landenberger
Ansonsten funktioniert alles wie es soll. Der Draytek routet und der
TP-Link switcht ;-)
Hat jemand eine Erklärung für das merkwürdige Verhalten des TP-Link-Routers?
Für ähnliche Aufgaben suche ich seit langem eine Art Traceroute für
OSI level 2, mit dem also zu sehen ist, welche Switches die Pakete bis
zum angegebenen Ziel durchlaufen.
Da Switche ja auf Layer 2 transparent sind, ist das so nicht einfach
möglich.

Am ehesten mit Geräten die CDP/LLDP sprechen und einer entsprechenden
Management-Software dazu. Hier an $arbeit kann ich mit den
HPE-Switchen soetwas machen und mir über die zentrale
Verwaltungssoftware den Pfad von Port A nach Port B genau aufzeigen
lassen, welche Geräte über welche Verbindungen durchlaufen werden.

Die ganze Chose kostet allerdings xx.000€/Jahr und die Geräte selbst
fangen auch im 4-stelligen Bereich an.


--
Sigmentation fault. Core dumped.
Friedemann Stoyan
2017-02-16 11:59:08 UTC
Permalink
Raw Message
Post by Sven Hartge
Am ehesten mit Geräten die CDP/LLDP sprechen und einer entsprechenden
Management-Software dazu. Hier an $arbeit kann ich mit den
HPE-Switchen soetwas machen und mir über die zentrale
Verwaltungssoftware den Pfad von Port A nach Port B genau aufzeigen
lassen, welche Geräte über welche Verbindungen durchlaufen werden.
Die ganze Chose kostet allerdings xx.000€/Jahr und die Geräte selbst
fangen auch im 4-stelligen Bereich an.
Die kleinen Cisco Catalysts (hier WS-C2960G-8TC-L) können das auch (traceroute
mac …). Sind "etwas" günstiger als 4-stellig.

mfg Friedemann
kay
2017-02-16 14:03:23 UTC
Permalink
Raw Message
Post by Friedemann Stoyan
Post by Sven Hartge
Am ehesten mit Geräten die CDP/LLDP sprechen und einer entsprechenden
Management-Software dazu. Hier an $arbeit kann ich mit den
HPE-Switchen soetwas machen und mir über die zentrale
Verwaltungssoftware den Pfad von Port A nach Port B genau aufzeigen
lassen, welche Geräte über welche Verbindungen durchlaufen werden.
Macht die dann so eine art netflow auswertung?
Post by Friedemann Stoyan
Post by Sven Hartge
Die ganze Chose kostet allerdings xx.000€/Jahr und die Geräte selbst
fangen auch im 4-stelligen Bereich an.
Ja, es war schon immer etwas teurer einem guten Geschmack zu fröhnen. :)
Post by Friedemann Stoyan
Die kleinen Cisco Catalysts (hier WS-C2960G-8TC-L) können das auch (traceroute
mac …). Sind "etwas" günstiger als 4-stellig.
Hmm, ich erinnere mich das ich in meinem Switch auch ein "traceroute"
kommando sah. Ist doch vermutlich von der IOS Version abhängig, nicht
von der Hardware oder?

Bei mir: Catalyst 2924-XL-EN mit IOS 12.0 und der hat AFAIR maximal 35
Euro gekostet. Gibt es zuhauf in der eBucht.

Als "Testgerät" natürlich etwas unhandlich... ulkigerweise finden sich
diekompakten 8-Port Modelle in höheren Preisregionen :-)

Kay
--
Posted via SN
Sven Hartge
2017-02-16 14:07:27 UTC
Permalink
Raw Message
Post by kay
Post by Sven Hartge
Am ehesten mit Geräten die CDP/LLDP sprechen und einer
entsprechenden Management-Software dazu. Hier an $arbeit kann ich
mit den HPE-Switchen soetwas machen und mir über die zentrale
Verwaltungssoftware den Pfad von Port A nach Port B genau aufzeigen
lassen, welche Geräte über welche Verbindungen durchlaufen werden.
Macht die dann so eine art netflow auswertung?
Nein. Das arbeitet intern mit SNMP und LLDP, um die Vernetzungsstruktur
der Geräte zu erfahren und den Laufweg der Pakete zu ermitteln.


--
Sigmentation fault. Core dumped.
Falk Duebbert
2017-02-16 20:22:09 UTC
Permalink
Raw Message
Post by Friedemann Stoyan
Die kleinen Cisco Catalysts (hier WS-C2960G-8TC-L) können das auch (traceroute
mac …). Sind "etwas" günstiger als 4-stellig.
Die HPE V-Serien auch. A-Serie sowieso.

Falk D.

Loading...