WAN Port des Routers Sniffen. DSL Modem und WAN Port per VLAN verbinden ?
Hallo,
ich habe einen HP Procurve 2524 Switch und einen Funkwerk R1200 Router.
Am Router hängt ein Devolo DSL Modem.
Ich möchte den WAN Port des Routers Sniffen, mit einem Hub ist das ja problemlos möglich. Aber ich würde mir den Hub gerne sparen.
Am Switch habe ich noch 4 Ports frei und der Switch ist Aktiv Vlan fähig.
Ich wollte jetzt 2 Ports vom Switch zu einem Vlan zusammenführen und einen davon dann per Port Monitor sniffen.
Leider funktioniert das ganze nicht. Ich habe ständig Verbindungsabbrüche und 80 % der Webseiten sind gar nicht erreichbar.
Ist es überhaupt möglich, den Wan Port so zu sniffen, oder muss das Modem auch Vlan fähig sein ?
Um gleich mal eventuelle "erhobene Zeigefinger" loszuwerden :
Ich möchte den WAN Port sniffen, um zu sehen wie gross die Pakete sind, die rausgehen. Ich habe teilweise extrem schlechte Durchsatzraten auf meinem VPN Tunnel zu einem Freund.
Wenn ich irgendjemanden in unserem Lan ausspionieren wollte, brauche ich nicht den Wan Port sniffen, sondern könnte im Switch einfach die Port festlegen, die gesnifft werden sollen.
Vieleicht hat jemand schon etwas ähnliches probiert oder soger am Laufen. Habe von VLAN (noch) null Ahnung.
Lg
Chris
ich habe einen HP Procurve 2524 Switch und einen Funkwerk R1200 Router.
Am Router hängt ein Devolo DSL Modem.
Ich möchte den WAN Port des Routers Sniffen, mit einem Hub ist das ja problemlos möglich. Aber ich würde mir den Hub gerne sparen.
Am Switch habe ich noch 4 Ports frei und der Switch ist Aktiv Vlan fähig.
Ich wollte jetzt 2 Ports vom Switch zu einem Vlan zusammenführen und einen davon dann per Port Monitor sniffen.
Leider funktioniert das ganze nicht. Ich habe ständig Verbindungsabbrüche und 80 % der Webseiten sind gar nicht erreichbar.
Ist es überhaupt möglich, den Wan Port so zu sniffen, oder muss das Modem auch Vlan fähig sein ?
Um gleich mal eventuelle "erhobene Zeigefinger" loszuwerden :
Ich möchte den WAN Port sniffen, um zu sehen wie gross die Pakete sind, die rausgehen. Ich habe teilweise extrem schlechte Durchsatzraten auf meinem VPN Tunnel zu einem Freund.
Wenn ich irgendjemanden in unserem Lan ausspionieren wollte, brauche ich nicht den Wan Port sniffen, sondern könnte im Switch einfach die Port festlegen, die gesnifft werden sollen.
Vieleicht hat jemand schon etwas ähnliches probiert oder soger am Laufen. Habe von VLAN (noch) null Ahnung.
Lg
Chris
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 172137
Url: https://administrator.de/contentid/172137
Ausgedruckt am: 13.11.2024 um 08:11 Uhr
16 Kommentare
Neuester Kommentar
Nein, das Modem muss natürlich nicht "VLAN fähig" sein ! Was soll das überhaupt bedeuten "VLAN fähig" ist ja eigentlich Unsinn den wenn du alle Port untagged in das VLAN hängst dann funktioniert der am Monitor Port wie ein Hub !
Wichtig ist also das du KEIN Tagging aktivierst an diesem Sniffer VLAN. Damit funktioniert das dann fehlerlos.
Grundlagen dazu siehe auch hier:
http://www.heise.de/netze/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22 ...
Um von VLAN etwas Ahnung zu bekommen solltest du ggf. das hier mal lesen:
http://www.heise.de/netze/VLAN-Virtuelles-LAN--/artikel/77832
http://de.wikipedia.org/wiki/Virtual_Local_Area_Network
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Danach solltest du annähernd genau wissen was VLANs sind !
Bei DSL hast du das MTU Problem, d.h. die MTU auf dem WAN Port muss kleiner sein als die klassischen 1500 Byte bei Ethernet weil der DSL Frame Overhead dazukommt. Wird das nicht richtig ausgehandelt mit einer MTU Path Discovery gibts schon Probleme. Wenn dir die IP Protokolle geläufig sind dann findest du hier eine sehr gute Erklärung zu dem Problem:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a ... -->> "Why MTU must be changed"
In einem VPN Tunnel hast du dann also eine quasi "Verdopplung" dieses Problem und solltest die MTU also entsprechend anpassen auf den Router Interfaces. Gute Router machen das immer sauber mit einer Path Discovery. Billig DSL Router haben da manchmal Probleme, was bei deinem Modell aber eben nicht der Fall sein sollte da er eher zu den gehobeneren Herstellern gehört !
Wie du die max. MTU für deinen Anschluss rausbekommst kannst du hier nachlesen:
http://www.gschwarz.de/mtu-wert-ermitteln
Mit dem Wissen solltest du das problem dann schnell in den Griff bekommen !
Wichtig ist also das du KEIN Tagging aktivierst an diesem Sniffer VLAN. Damit funktioniert das dann fehlerlos.
Grundlagen dazu siehe auch hier:
http://www.heise.de/netze/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22 ...
Um von VLAN etwas Ahnung zu bekommen solltest du ggf. das hier mal lesen:
http://www.heise.de/netze/VLAN-Virtuelles-LAN--/artikel/77832
http://de.wikipedia.org/wiki/Virtual_Local_Area_Network
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Danach solltest du annähernd genau wissen was VLANs sind !
Bei DSL hast du das MTU Problem, d.h. die MTU auf dem WAN Port muss kleiner sein als die klassischen 1500 Byte bei Ethernet weil der DSL Frame Overhead dazukommt. Wird das nicht richtig ausgehandelt mit einer MTU Path Discovery gibts schon Probleme. Wenn dir die IP Protokolle geläufig sind dann findest du hier eine sehr gute Erklärung zu dem Problem:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a ... -->> "Why MTU must be changed"
In einem VPN Tunnel hast du dann also eine quasi "Verdopplung" dieses Problem und solltest die MTU also entsprechend anpassen auf den Router Interfaces. Gute Router machen das immer sauber mit einer Path Discovery. Billig DSL Router haben da manchmal Probleme, was bei deinem Modell aber eben nicht der Fall sein sollte da er eher zu den gehobeneren Herstellern gehört !
Wie du die max. MTU für deinen Anschluss rausbekommst kannst du hier nachlesen:
http://www.gschwarz.de/mtu-wert-ermitteln
Mit dem Wissen solltest du das problem dann schnell in den Griff bekommen !
Das kann dann nur ein Port Autonegotiation Problem am Switch sein, also die falsche dynamische Aushandlung von Speed und Duplex Modus !
Sieh dir dazu einmal mit "show int" oder "show int brie" den genauen Interface Status an und ob Speed und Duplex korrekt ausgehandelt wurden mit den Endgeräten. Das ist vermutlich nicht der Fall ! Ebenso sieh dir mal die Collision Counter an pro Interface. Normal müssen alle Error Counter auf 0 sein und auch so bleiben.
Da liegt vermutlich das Problem. Wenn ja solltest du Speed und Duplex Mode statisch auf den Switchports einstellen.
Wenn es mit dem Hub dazwischen geht muss es auch mit einem Switch dazuwischen klappen...keine Frage !
Sieh dir dazu einmal mit "show int" oder "show int brie" den genauen Interface Status an und ob Speed und Duplex korrekt ausgehandelt wurden mit den Endgeräten. Das ist vermutlich nicht der Fall ! Ebenso sieh dir mal die Collision Counter an pro Interface. Normal müssen alle Error Counter auf 0 sein und auch so bleiben.
Da liegt vermutlich das Problem. Wenn ja solltest du Speed und Duplex Mode statisch auf den Switchports einstellen.
Wenn es mit dem Hub dazwischen geht muss es auch mit einem Switch dazuwischen klappen...keine Frage !
Ist ja auch Blödsinn den WAN Port tagged zu setzen. Der WAN Traffic bzw. DSL Pakete können mit der VLAN ID ja so oder so nichts anfangen. Ausserdem würden die Eingangsgeräte (DSLAM, Router etc.) beim Provider damit nix anfangen können und droppen diese Frames oder interpretieren sie schlicht als Fehler, da sie die 802.1q Extension der Frames nicht verstehen.
Ist die Frage was der Switch da macht. Möglich ist das bei Billigswitches des Monitoren sprich spiegeln der Ports über die CPU laufen und diese überlasten so das solche Switches diese Pakete schlicht verschlucken.
Das müsste man mit einem eingeschleiften Sniffer mal genau ansehen. Ggf. Solltest du mal den Hub vor bzw. Hinter den Switchport klemmen und dir das mal ansehen. Normal ist das wenigstens nicht und spricht eher für ein Problem am Switch bzw. Seiner Firmware.
Ist die Frage was der Switch da macht. Möglich ist das bei Billigswitches des Monitoren sprich spiegeln der Ports über die CPU laufen und diese überlasten so das solche Switches diese Pakete schlicht verschlucken.
Das müsste man mit einem eingeschleiften Sniffer mal genau ansehen. Ggf. Solltest du mal den Hub vor bzw. Hinter den Switchport klemmen und dir das mal ansehen. Normal ist das wenigstens nicht und spricht eher für ein Problem am Switch bzw. Seiner Firmware.
Na ja für eine Provider Verbindung mit max 16 Mbit DSL muss man ja nun wahrlich auch keine Gigabit Ports haben...das wäre ja nun auch überkandidelter Unsinn !
Wenn HP zu den besseren Switches gehören zu was gehört denn dein Cisco 2900XL deiner Meinung nach ?? HP ProCurve ist Billigheimer. Zwar nicht ganz so auf dem Niveau wie NetGear, D-Link & Co. aber immerhin. Ob die Cisco Switches empfehlenswert sind muss man wohl nicht weiter kommentieren oder fragst du bei Autos auch in Foren die Allgemeinheit ob Wagen von Daimler Benz empfehlenswert sind oder nicht ?
Testweise solltest du also mal deinen Cisco 2900XL probieren und mal checken ob der sich anders verhält. Gigabit Port benötigst du für langsame WAN Ports ja nun wahrlich nicht. Abgesehen davon ist deine Aussage auch technisch schlicht falsch, denn der 2900XL hat mit 2 Gigabit WS-G5482 GBICs:
http://mtmnet.com/WS-G5482.htm
sehr wohl wenigstens 2 Gig Ports. Diese GBICs gibt es preiswert bei eBay z.B.
Ein Connection Reset bedeutet das im Layer 4 massiv Pakete verloren gehen. Wenns mit einem Hub sauber rennt kann der böse Buhmann also nur der HP Switch sein.
Wenn HP zu den besseren Switches gehören zu was gehört denn dein Cisco 2900XL deiner Meinung nach ?? HP ProCurve ist Billigheimer. Zwar nicht ganz so auf dem Niveau wie NetGear, D-Link & Co. aber immerhin. Ob die Cisco Switches empfehlenswert sind muss man wohl nicht weiter kommentieren oder fragst du bei Autos auch in Foren die Allgemeinheit ob Wagen von Daimler Benz empfehlenswert sind oder nicht ?
Testweise solltest du also mal deinen Cisco 2900XL probieren und mal checken ob der sich anders verhält. Gigabit Port benötigst du für langsame WAN Ports ja nun wahrlich nicht. Abgesehen davon ist deine Aussage auch technisch schlicht falsch, denn der 2900XL hat mit 2 Gigabit WS-G5482 GBICs:
http://mtmnet.com/WS-G5482.htm
sehr wohl wenigstens 2 Gig Ports. Diese GBICs gibt es preiswert bei eBay z.B.
Ein Connection Reset bedeutet das im Layer 4 massiv Pakete verloren gehen. Wenns mit einem Hub sauber rennt kann der böse Buhmann also nur der HP Switch sein.
Von HP solltest du aber besser die Finger lassen in diesem Umfeld, besonders von den ProCurve Gurken !
Das Forwarding bei Monitor Ports und Broadcast/Multicast ist bei den ProCurve Kisten CPU basierend und damit nicht performant ! (Darf ja nix kosten...). Da die ProCurves bekanntermassen deshalb sehr schwachbrüstig sind kann es sein das denen die Luft ausgeht....ohne das genauer zu analysieren ist das aber nur geraten erstmal.
Das Forwarding bei Monitor Ports und Broadcast/Multicast ist bei den ProCurve Kisten CPU basierend und damit nicht performant ! (Darf ja nix kosten...). Da die ProCurves bekanntermassen deshalb sehr schwachbrüstig sind kann es sein das denen die Luft ausgeht....ohne das genauer zu analysieren ist das aber nur geraten erstmal.
Soviel zum Thema HP ProCurve....aber was will man erwarten ?!
Wenns das denn war bitte
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !
Wenns das denn war bitte
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !
Sollte eigentlich nicht so sein ! Hast du wirklich alles beherzigt was hier steht ??:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_not ...
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_not ...