5
Einen trunk Port (dot1q) über Wireshark monitoren, was sieht man was nicht?
Hallo!
Ich habe heute eine Monitorsession von einem Uplink Port, der getrunkt ist, auf einen Netzwerkport gelegt der in meinem Recher endet.
Sowas kann man ja prima mit Catalyst Switchen (in diesem Fall einem 3750) machen.
So kann man schön alles sehen was durch den Port huscht.
Jetzt ist dieser Port ja ein Trunk, das heisst bis auf das native Lan, fließt da ja alles "encapsulated" durch (Stichwort Vlan).
Wireshark ist fleißig am mitschneiden gewesen.
Meine Frage: Was sieht Wireshark?
Nur das native Vlan, also dass was "untagged" durch die Leitung flutscht?
Kann bei mir irgendwie nicht sein, da waren Ip's dabei die im nativen Vlan nicht vorhanden sind.
Was ist mit den getagged Vlans die durch diesen Trunk fließen?
Falls jemand einen Anhaltspunkt hat oder weiß was Wireshark alles bekommt (und was nicht und warum) möge er es mir sagen, ich stehe total auf dem Schlauch!
viele Grüße
Luc
Ich habe heute eine Monitorsession von einem Uplink Port, der getrunkt ist, auf einen Netzwerkport gelegt der in meinem Recher endet.
Sowas kann man ja prima mit Catalyst Switchen (in diesem Fall einem 3750) machen.
So kann man schön alles sehen was durch den Port huscht.
Jetzt ist dieser Port ja ein Trunk, das heisst bis auf das native Lan, fließt da ja alles "encapsulated" durch (Stichwort Vlan).
Wireshark ist fleißig am mitschneiden gewesen.
Meine Frage: Was sieht Wireshark?
Nur das native Vlan, also dass was "untagged" durch die Leitung flutscht?
Kann bei mir irgendwie nicht sein, da waren Ip's dabei die im nativen Vlan nicht vorhanden sind.
Was ist mit den getagged Vlans die durch diesen Trunk fließen?
Falls jemand einen Anhaltspunkt hat oder weiß was Wireshark alles bekommt (und was nicht und warum) möge er es mir sagen, ich stehe total auf dem Schlauch!
viele Grüße
Luc
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 101540
Url: https://administrator.de/contentid/101540
Printed on: April 19, 2024 at 21:04 o'clock
5 Comments
Latest comment
Sowas kann man nicht nur prima mit Catalysatoren machen sondern mit HP, NetGear, Foundry, Nortel usw. also allen anderen VLAN fähigen Netzwerkswitches am Markt, denn das Tagging nach 802.1q ist ein weltweiter Standard !!!
Das zeigt auch das du einen falschen Ausdruck für das benutzt was du meinst, denn "Trunking" wird gemeinhin für die Linkaggregation also das parallele Bündeln von mehreren Links benutzt.
Um für dich als Cisco Knecht zu sprechen ist Trunking was Cisco al Etherchannel oder Channeling bezeichent. Der Rest der Netzwerk Welt nennt es übrigens Trunking !
Nur soviel zu diesem Thema !
So, was sieht nun Wireshark ??
Gegenfrage: Warum hast du es nicht einfach mal ausprobiert ??? Dann hättest du dir diesen Thread ersparen können !!
Als allererstes musst du eine 802.1q (tagging) fähige Netzwerkkarte für den Wireshark haben sonst kann diese Karte .1q getaggte Frames im promiscous Modus schlicht und einfach gar nicht anzeigen und verwirft diese als sog. Giants, da diese Pakete nicht standardkonform sind für Karten die kein .1q verstehen !
Hast du aber so eine Karte im Wireshark Rechner, zeigt Wireshark dir natürlich brav auch diese getaggten Frames an wie sich das gehört für einen anständigen Sniffer.
Er nimmt dir auch den .1q Header auseinander, denn darin ist noch QoS sprich 802.1p versteckt und zeigt dir das sauber inkl. VLAN ID an so das du genau sehen kannst aus welchem VLAN diese Pakete kommen !
Der Rest ist ein normaler Ethernet Frame wie er auch bei ungetaggten Paketen angezeigt wird, denn .1q verändert das nicht.
Über den genauen Aufbau von .1q getaggten Frames kannst du dich hier informieren:
http://www.heise.de/netze/VLAN-Virtuelles-LAN--/artikel/77832
(Speziell Seite 4 !)
Das zeigt auch das du einen falschen Ausdruck für das benutzt was du meinst, denn "Trunking" wird gemeinhin für die Linkaggregation also das parallele Bündeln von mehreren Links benutzt.
Um für dich als Cisco Knecht zu sprechen ist Trunking was Cisco al Etherchannel oder Channeling bezeichent. Der Rest der Netzwerk Welt nennt es übrigens Trunking !
Nur soviel zu diesem Thema !
So, was sieht nun Wireshark ??
Gegenfrage: Warum hast du es nicht einfach mal ausprobiert ??? Dann hättest du dir diesen Thread ersparen können !!
Als allererstes musst du eine 802.1q (tagging) fähige Netzwerkkarte für den Wireshark haben sonst kann diese Karte .1q getaggte Frames im promiscous Modus schlicht und einfach gar nicht anzeigen und verwirft diese als sog. Giants, da diese Pakete nicht standardkonform sind für Karten die kein .1q verstehen !
Hast du aber so eine Karte im Wireshark Rechner, zeigt Wireshark dir natürlich brav auch diese getaggten Frames an wie sich das gehört für einen anständigen Sniffer.
Er nimmt dir auch den .1q Header auseinander, denn darin ist noch QoS sprich 802.1p versteckt und zeigt dir das sauber inkl. VLAN ID an so das du genau sehen kannst aus welchem VLAN diese Pakete kommen !
Der Rest ist ein normaler Ethernet Frame wie er auch bei ungetaggten Paketen angezeigt wird, denn .1q verändert das nicht.
Über den genauen Aufbau von .1q getaggten Frames kannst du dich hier informieren:
http://www.heise.de/netze/VLAN-Virtuelles-LAN--/artikel/77832
(Speziell Seite 4 !)
Hallo!
Danke schonmal! (Auch für die kleine Lektüre über trunking und .1q ;).
Meine Netzwerkkarte ist NICHT dot1q fähig und ich habe schon mal mitgeschnitten.
Deswegen ja auch mein Beitrag:
Ich habe halt echt viel Verkehr mitbekommen, aber von Ip's zu Ip's die im nativen Vlan nicht vorkommen.
Und das native Vlan ist dann ja scheinbar das einzige was meine nicht .1q fähige Netzwerkkarte aus so einem gemonitorten Trunk mitnehmen kann.
Du hast leider meine Frage nicht beantwortet:
"Nur das native Vlan, also dass was "untagged" durch die Leitung flutscht?"
Falls dem so wäre, würde es keinen Sinn ergeben.
Deswegen mein Beitrag.
Danke für die Antwort!
Luc
Ich hab des Rätsels Lösung gefunden:
Ich versuche es so zu formulieren, das es allgemeine Gültigkeit hat:
Ich hab ja einen mit .1q getaggten Port gemonitort, indem ich ihn über (bei Cisco heisst es so) SPAN auf meinen Port "gespiegelt" habe.
"The default configuration for local SPAN session ports is to send all packets untagged. SPAN also does not normally monitor bridge protocol data unit (BPDU) packets and Layer 2 protocols, such as Cisco Discovery Protocol (CDP), VLAN Trunk Protocol (VTP), Dynamic Trunking Protocol (DTP), Spanning Tree Protocol (STP), and Port Aggregation Protocol (PAgP). "
Soll heissen er hat in der SPAN Session einfach alles schon aus dem .1q Header entpackt was er auf meinen Port gespiegelt hat. Ist eine feine Sache, muss man halt nur wissen ;).
Gruß
Luc
Danke schonmal! (Auch für die kleine Lektüre über trunking und .1q ;).
Meine Netzwerkkarte ist NICHT dot1q fähig und ich habe schon mal mitgeschnitten.
Deswegen ja auch mein Beitrag:
Ich habe halt echt viel Verkehr mitbekommen, aber von Ip's zu Ip's die im nativen Vlan nicht vorkommen.
Und das native Vlan ist dann ja scheinbar das einzige was meine nicht .1q fähige Netzwerkkarte aus so einem gemonitorten Trunk mitnehmen kann.
Du hast leider meine Frage nicht beantwortet:
"Nur das native Vlan, also dass was "untagged" durch die Leitung flutscht?"
Falls dem so wäre, würde es keinen Sinn ergeben.
Deswegen mein Beitrag.
Danke für die Antwort!
Luc
Ich hab des Rätsels Lösung gefunden:
Ich versuche es so zu formulieren, das es allgemeine Gültigkeit hat:
Ich hab ja einen mit .1q getaggten Port gemonitort, indem ich ihn über (bei Cisco heisst es so) SPAN auf meinen Port "gespiegelt" habe.
"The default configuration for local SPAN session ports is to send all packets untagged. SPAN also does not normally monitor bridge protocol data unit (BPDU) packets and Layer 2 protocols, such as Cisco Discovery Protocol (CDP), VLAN Trunk Protocol (VTP), Dynamic Trunking Protocol (DTP), Spanning Tree Protocol (STP), and Port Aggregation Protocol (PAgP). "
Soll heissen er hat in der SPAN Session einfach alles schon aus dem .1q Header entpackt was er auf meinen Port gespiegelt hat. Ist eine feine Sache, muss man halt nur wissen ;).
Gruß
Luc
Ist aber dumm und eher hinderlich wenn man einen Trunk Port monitoren will mit dem Wireshark um auch .1q Pakete zu sehen, da nützt einem das dann nichts.
Der Wireshark hat übrigens einen Capture Filter mit dem man schon beim Capturen Traffic filtern kann den man nicht sehen will
Ein native VLAN was parallel untagged übertragen wird haben übrigens viele Hersteller gar nicht wie z.B. 3Com und andere obwohl der .1q Standard das so beschreibt...nur der Vollständigkeit halber !
Der Wireshark hat übrigens einen Capture Filter mit dem man schon beim Capturen Traffic filtern kann den man nicht sehen will
Ein native VLAN was parallel untagged übertragen wird haben übrigens viele Hersteller gar nicht wie z.B. 3Com und andere obwohl der .1q Standard das so beschreibt...nur der Vollständigkeit halber !
Hä?
"Ist aber dumm und eher hinderlich wenn man einen Trunk Port monitoren will mit dem Wireshark um auch .1q Pakete zu sehen, da nützt einem das dann nichts."
Das SPAN hat mir doch alles aus dem Trunk port aus dem .1q Header entpackt und als normale EthernetFrames rübergeschickt.
Das ist doch ne feine Sache und man kann alles sehen was komplett durch den Trunk fließt.
Hat mir schon viel geholfen, man muss halt nur wissen das es entpackt wird.
"Ist aber dumm und eher hinderlich wenn man einen Trunk Port monitoren will mit dem Wireshark um auch .1q Pakete zu sehen, da nützt einem das dann nichts."
Das SPAN hat mir doch alles aus dem Trunk port aus dem .1q Header entpackt und als normale EthernetFrames rübergeschickt.
Das ist doch ne feine Sache und man kann alles sehen was komplett durch den Trunk fließt.
Hat mir schon viel geholfen, man muss halt nur wissen das es entpackt wird.
Ok, aber wenn er das tut hast du keinerlei schnelle Kontrolle mehr wo (VLAN !) diese Pakete an diesem tagged Port herkommen.
Deine einzige Kontrolle ist dann nur die IP Adresse aus dem VLAN Subnetz um das VLAN zu identifizieren, was aber sehr hinderlich ist wenn du z.B. 30+ VLANs hast, was in großen Netzen nicht unüblich ist.
Auf alle Fälle ist es da sinnvoller auch die VLAN ID mit im Paket zu sehen.
Abgesehen davon ist in der VLAN ID auch das QoS Byte 802.1p enthalten was du dann auch nicht mehr siehst.
Damit ist das absolutes KO Kriterium wenn man im Netz VoIP hat und korrektes QoS Handling mit einem Sniffer überprüfen will.
Soviel Vorteile hat das also keineswegs auf den ersten Blick !!
Letztlich aber Geschmackssache....wer nur ein Popelnetz mit 2 VLANs z.B. hat kann sicher auch ohne VLAN ID damit leben.
Deine einzige Kontrolle ist dann nur die IP Adresse aus dem VLAN Subnetz um das VLAN zu identifizieren, was aber sehr hinderlich ist wenn du z.B. 30+ VLANs hast, was in großen Netzen nicht unüblich ist.
Auf alle Fälle ist es da sinnvoller auch die VLAN ID mit im Paket zu sehen.
Abgesehen davon ist in der VLAN ID auch das QoS Byte 802.1p enthalten was du dann auch nicht mehr siehst.
Damit ist das absolutes KO Kriterium wenn man im Netz VoIP hat und korrektes QoS Handling mit einem Sniffer überprüfen will.
Soviel Vorteile hat das also keineswegs auf den ersten Blick !!
Letztlich aber Geschmackssache....wer nur ein Popelnetz mit 2 VLANs z.B. hat kann sicher auch ohne VLAN ID damit leben.
