Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit
GELÖST

Ping funktioniert im gleichen IP-Adressenbereich nur teilweise

Frage Netzwerke Router & Routing

Mitglied: daarma

daarma (Level 1) - Jetzt verbinden

23.12.2014, aktualisiert 02.01.2015, 3623 Aufrufe, 20 Kommentare

Ich bin's mal wieder mit meinem Miktotik-Setup

Um jetzt nicht auf ältere Beiträge verweisen zu müssen, hier kurz mein Setup (vereinfacht dargestellt).

  
(WAN--------Fritzbox--------)-Router(Mikrotik 2011)---------Switch(Zyxel1910)-----------AP (SSID1...4) 
                                                             RasPi (VLAN4)
Das mit der Fritzbox und WAN kann man für diese Frage ausklammern.
Über VLANs(1...4) werden im Prinzip vier verschiedene Netze implementiert, mit jeweils einem eigenen IP-Adressbereich.
Die meisten Teilnehmer sind über den AP verbunden, der bis zu vier SSIDs bedienen kann und die Pakete jeweils taggt.
DHCP-Server und jeweiliges Gateway ist immer auf dem Mikrotik. (192.168.x.1)
Eine der SSIDs (VLAN1) wird über einen Hotspot bedient, aber das tut hier nichts zur Sache.

SSID1/VLAN1
192.168.1.0/24

SSID2/VLAN2
192.168.2.0/24
usw,

Wie man oben sehen kann, ist direkt am Switch ein RasPi (wegen XBMC) angeschlossen. Über die entsprechende Switch-Konfiguration ist dieser Teil des VLAN4.
Für dieses VLAN sind hinsichtlich des Routings keinerlei Beschränkungen (Firewall, Hotspot etc.) konfiguriert.

Die Anforderung ist nun die, dass die Clients im VLAN4 an den Raspi Bild-/Ton-Material streamen können.

Leider finden die entsprechenden Apps den Raspi nicht.

Ich habe mich erstmal mittels Ping auf die Suche gemacht und dabei festgestellt, dass Clients aus einem anderen IP-Bereich (z.B. VLAN3) den RasPi problemlos anpingen können. Sobald der Client sich aber im gleichen IP-Adressbereich befindet (über den AP), funktioniert das nicht mehr. "Benachbarte" Clients (AP, gleiche SSID) können einander erfolgreich anpingen.

Klar, eine Lösung wäre, den Raspi ebenfalls ins WLAN zu hängen. Bevor ich das tue, würde ich gerne das "warum" verstehen, und ob man das Problem auch irgendwie per Konfiguration in Griff kriegen kann.

Danke und viele Grüße
daarma
Mitglied: aqui
24.12.2014, aktualisiert um 11:58 Uhr
Halte dich strikt an die Setups hier:
http://www.administrator.de/wissen/vlan-installation-und-routing-mit-m0 ...
besonders:
http://www.administrator.de/contentid/245872#comment-942279
http://www.administrator.de/contentid/245872#comment-942279
Letztere beiden zeigen das runtergebrochen auf HP bzw. TP Link. Das Setup ist für deinen Zyxel vollkommen identisch nur eben mit dessen Syntax.

Wichtig für dich sind folgende zwingende ToDos:
  • RasPi Port am Zyxel untagged in VLAN 4
  • RasPi IP Adresse sollte in so einen Setup immer statisch ! sein aus IP Netz an VLAN 4, Gateway RasPi zeigt auf die MT IP im VLAN 4 sofern du das VLAN 4 routetest, DNS RasPi auf deine interne DNS IP (Router ?) IP Adress Setup Tips des RasPis kannst du auch hier nachlesen.
  • AP (mSSID ?) Port tagged an den Zyxel. Es sieht ja so aus als wenn du mit mSSID APs arbeitest die ihre mSSID dann mit einem entsprechenden VLAN Tag versehen, deshalb muss der Zyxel Port tagged sein ! Sind diese APs über einen anderen Switch zusammengeschaltet müssen alle Ports immer tagged sein ! Logisch sonst kann die mSSID infos über die VLAN IDs (Tagging) nicht weitergegeben werden !
  • MT Port zum Zyxel auch tagged aber nur sofern du mit mehreren VLANs als Trunk arbeitest vom Zyxel auf den MT. (VLAN Routing über MT). Sollte das einzig NUR das VLAN 4 sein reicht es natürlich einen ganz normalen untagged Port ins VLAN 4 zu hängen entsprechend dann auch untagged auf dem MT !
  • MT MUSS eine statische Default Route auf die FB haben (LAN IP der FB) !
  • FB MUSS eine statische Route auf das VLAN 4 IP Netz eingetragen haben via IP MT im FB LAN !
Zur reinen non tagged Routing Konfig des MT siehe dieses Forumstutorial:
http://www.administrator.de/wissen/routing-mit-2-netzwerkkarten-unter-w ...
Dort steht all das oben genannte im Detail !
Das Praxisbeispiel mit tagged mSSID APs und Routing:
http://www.administrator.de/wissen/vlan-installation-und-routing-mit-m0 ...

Das der RasPi Endgeräte im gleichen VLAN nicht findet deutet ganz klar auf eine Fehlkonfiguration, vermutlich des Switches im VLAN Setting, hin !!
Wenn der RasPi im gleichen VLAN 4 ist, also in der gleichen L2 Domain wie die Endgeräte dort, MUSS dieser natürlich problemlos pingbar und erreichbar sein ! Hängen ja quasi dann alle am "gleichen Draht" !
Das solltest du erstmal mit einem kabelgebundenen Endgerät was sich ebenfalls im VLAN 4 befindet sicher mit Ping und Tracreroute oder Pathping verifizieren !
Idealerweise auch über einen tagged Uplink am Switch wenn die NIC des Testrechners das supportet:
http://www.administrator.de/wissen/vlan-routing-über-802-1q-trunk- ...
Erst wenn das sauber funktioniert wird auch der Rest fehlerfrei funktionieren !

Damit hast du nun alles Werkzeug an der Hand um das ohne Probleme zum Fliegen zu bringen ! Den RasPi ins WLAN zu bringen als Workaround ist natürlich völliger Unsinn ! Du willst ja wohl sicher nicht ein falsches oder fehlerhaftes Setup der Infrastruktur durch eine schlechte Anbing kompensieren ?! Das wäre ja sinnfrei !
Bitte warten ..
Mitglied: daarma
29.12.2014 um 15:22 Uhr
Danke Dir aqui für deine Antwort/Zeit - das schätze ich sehr!

Halte dich strikt an die Setups hier:
http://www.administrator.de/wissen/vlan-installation-und-routing-mit-m0 ...
besonders:
http://www.administrator.de/contentid/245872#comment-942279
http://www.administrator.de/contentid/245872#comment-942279
Letztere beiden zeigen das runtergebrochen auf HP bzw. TP Link. Das Setup ist für deinen Zyxel vollkommen identisch nur eben
mit dessen Syntax.

Die meisten Tutorials habe ich gelesehen und versucht auf mein Setup zu übertragen und anzuwenden.

Wichtig für dich sind folgende zwingende ToDos:
  • RasPi Port am Zyxel untagged in VLAN 4

Ist passiert.
Der betreffende Zyxel Port hat die folgenden Settings:

PVID=4
Ingress filtering=FALSE
Ingress acceptance=Untagged only (hier bietet Zyxel als weitere Optionen "Tagged only" und "Tagged and Untagged")
Egress tagging=Untag all (hier bietet Zyxel als weitere Optionen "Tag all" und "Untag Port VLAN")
Allowed VLANs=4
Forbidden VLANs=<leer>

* RasPi IP Adresse sollte in so einen Setup immer statisch ! sein aus IP Netz an VLAN 4, Gateway RasPi zeigt auf die MT IP im VLAN
4 sofern du das VLAN 4 routetest, DNS RasPi auf deine interne DNS IP (Router ?) IP Adress Setup Tips des RasPis kannst du auch
hier nachlesen.

Warum würdest du die IP-Adresse des Raspi statisch vergeben?
Gateway ist auf dem Raspi korrekterweise 192.168.4.1 (per DHCP vergeben)

* AP (mSSID ?) Port tagged an den Zyxel. Es sieht ja so aus als wenn du mit mSSID APs arbeitest die ihre mSSID dann mit einem
entsprechenden VLAN Tag versehen, deshalb muss der Zyxel Port tagged sein ! Sind diese APs über einen anderen Switch
zusammengeschaltet müssen alle Ports immer tagged sein ! Logisch sonst kann die mSSID infos über die VLAN IDs (Tagging)
nicht weitergegeben werden !

Die APs (Draytek Vigor AP900) hängen direkt am Zyxel. Es handelt sich um mSSID (Multi-SSID) Geräte.
Die Einstellungen der betreffenden Ports lauten

PVID=1 (ist ja eigentlich Quatsch, denn der Port "gehört" ja allen vier VLANs gleichermassen, aber irgendeinen Wert musste ich in der UI angeben)
Ingress filtering=FALSE
Ingress acceptance=Tagged only
Egress tagging=Tag all
Allowed VLANs=1-4
Forbidden VLANs=<leer>

* MT Port zum Zyxel auch tagged aber nur sofern du mit mehreren VLANs als Trunk arbeitest vom Zyxel auf den MT. (VLAN Routing
über MT). Sollte das einzig NUR das VLAN 4 sein reicht es natürlich einen ganz normalen untagged Port ins VLAN 4 zu
hängen entsprechend dann auch untagged auf dem MT !

Ist so eingestellt - der MT bekommt den Traffic aller VLANs zu sehen und routet dazwischen (und auch ins Internet)

PVID=1
Ingress filtering=FALSE
Ingress acceptance=Tagged only
Egress tagging=Tag all
Allowed VLANs=1-4
Forbidden VLANs=<leer>

* MT MUSS eine statische Default Route auf die FB haben (LAN IP der FB) !
  • FB MUSS eine statische Route auf das VLAN 4 IP Netz eingetragen haben via IP MT im FB LAN !

Ist beides der Fall, aber für das Problem ist dies IMO nicht relevant (lass mich gerne eines besseren belehren )

So weit so gut.

Heute habe ich meinen Laptop an den Switch gehängt und versucht, aus dem WLAN (per Smartphone) ihn anzupingen. Dabei habe ich auf dem Laptop einen Wireshark-Mitschnitt gemacht.
Fazit: Der Laptop sieht die ARP-Pakete des Phones und laut Wireshark schickt er auch jeweils eine Antwort mit der eigenen MAC-Adresse. Da dies im Ping-Takt erfolgte, gehe ich davon aus, dass die ARP-Antwort das Phone nicht erreicht.

Klingt also tatsächlich nach einem Switch-VLAN-Konfigurationsproblem, allerdings bin ich ratlos, denn ich meine, dass die obigen Einstellungen korrekt sein müssten.

Folgende Beobachtungen/Tests habe ich noch gemacht:
- Ping vom MT aus auf den Raspi --> OK
- Ping vom MT aus auf ein WLAN-Gerät, welches über den AP verbunden ist --> OK
- Ping vom WLAN-Gerät auf ein anderes WLAN-Gerät (gleiches VLAN, gleicher AP) --> OK
- Ping vom WLAN-Gerät auf den Raspi (oder alternativ Laptop) --> NICHT OK (außer wenn beide in unterschiedlichen IP-Bereichen sind, dann OK, weil der MT routet)


Ich bin mit meiner Weisheit am Ende ,,,
Bitte warten ..
Mitglied: aqui
29.12.2014 um 17:06 Uhr
Warum würdest du die IP-Adresse des Raspi statisch vergeben?
Gibt eine goldene Regel bei Netzwerkern: Server (egal wie groß) haben immer statische IPs oder über die Mac Adresse festgelegte. Von einem Server hängt immer eine Funktion ab. Sollte sich dessen IP aufgrund der Dynamik von DHCP mal ändern ist Schicht im Schacht.
Außerdem gibt es oft Security Filter auf Server usw. in FW und da ist dann klar das eine dyn. IP immer ein NoGo ist !
Zum Testen kannst du das aber erstmal so lassen....
Kannst du von dem RasPi andere Endgeräte im .4.0er VLAN anpingen ?? Das ist sehr wichtig das sicherzustellen ! Ganz sicher MUSS er z.B. die 4.x MT IP Adresse pingen können, denn das ist ja eine reine Kabelverbindung !!

Du solltest ggf. jedes VLAN und zwar tagged und untagged Ports so testen sofern die NIC deines Testrechners ein 802.1q Tagging zulässt ?!
Die Zyxel Konfigs klingen sehr krank und kryptisch (...fast so übel wie NetGear ) es ist möglich und auch wahrscheinlich das da noch der Wurm in den Port Taggings steckt.
Das kann man aber mit einem Rechner wasserdicht ausprobieren. So ust man dann wenigstens ganz sicher das die VLAN Tagging Einstellungen auf dem Switch richtig sind und kann die als potentiellen Fehler ausschliessen.
PVID=1 (ist ja eigentlich Quatsch, denn der Port "gehört" ja allen vier VLANs gleichermassen, aber irgendeinen Wert musste ich in der UI angeben)
Sollte richtig sein ! Als Default ist das Default VLAN immer untagged an tagged Ports vorhanden. Aller ungetaggter Traffic der an diesen Ports auftaucht wird ins VLAN 1 geforwardet sofen man es nicht anders einstellt.
Folgende Beobachtungen/Tests habe ich noch gemacht:
Ping vom MT aus auf den Raspi --> OK
Klingt schonmal gut ! Klappt es auch umgedreht RasPi auf MT ? Wenn ja ist die Connectivity im VLAN 4 OK !
Diesen Test solltest du ggf. von einem VLAN 1-4 untagged Port auf den MT machen. Das zeigt dann das der MT mit seinen IPs richtig in jedem VLAN hängt und auch die tagged Konfig vom MT auf den Switch richtig ist !
Ping vom MT aus auf ein WLAN-Gerät, welches über den AP verbunden ist --> OK
Ist auch gut und solltest du für ALLE mSSIDs verifizieren und.... auch immer die Gegenrichtung checken !
Ping vom WLAN-Gerät auf ein anderes WLAN-Gerät (gleiches VLAN, gleicher AP) --> OK
OK, sollte auch so klappen und zeigt das die VLANs bzw. mSSIDs soweit richtig sind.
Ping vom WLAN-Gerät auf den Raspi (oder alternativ Laptop) --> NICHT OK (außer wenn beide in unterschiedlichen IP-Bereichen sind, dann OK, weil der MT routet)
Würde bedeuten das der RasPi nicht transparent im VLAN 4 ist ! Zum MT schon aber scheinbar nicht zu den mSSIDs.
mit apt-get install wireshark kannst du auch einen Wireshark auf dem RasPi installieren.
Wenn du vom WLAN das in der mSSID 4 (VLAN 4) ist den RasPi pingst musst du zuallererst ein ARP Request sehen. Das WLAN Gerät fragt an wer die IP xyz hat. Das ist ein Broadcast und der MUSS am RasPi ankommen !
Der RasPi antwortet darauf mit einem ARP Reply das er das ist und teilt dem Absender seine Mac Adresse mit.
Erst dann verschickt der Absender einen ICMP Eche Request an den RasPi (Ping). Der Raspi antwortet darauf mit einem ICMP Echo Reply.
Das musst du sehen !
Außerdem solltest du noch alle anderen Broadcast Pakete aus dem VLAN 4 sehen am RasPi Wireshark. Das kannst du daran verifizieren das bei ihm nur Absender IPs aus dem VLAN 4 Netz ankommen.
Bitte warten ..
Mitglied: daarma
30.12.2014, aktualisiert um 15:15 Uhr
@aqui: Danke für die Erklärung zur statischen IP-Adressvergabe. Macht natürlich Sinn, werde ich zukünftig auch so machen.

Ich habe jetzt die Tests gemacht: Ein Notebook (anstelle des Raspi) per Kabel direkt am Switch und als Ping-Gegenpart ein Notebook per WLAN über den AP. Beide immer im gleichen VLAN.

Ergebnis: Ping geht weder in die eine noch in die andere Richtung durch. In jedem VLAN dasselbe Verhalten.

Während des Pings (Testfall: Ping von der "WLAN-Seite" aus) habe ich auf beiden Notebook Wireshark mitlaufen lassen.
Man sieht ganz klar, dass die Zielstation den Broadcast sieht, sie diesen auch beantwortet, er aber beim Gegenüber (also WLAN-Gerät am AP) nicht ankommt.
Seltsamerweise klappt genau dieses Szenario gegenüber dem MT-Router offensichtlich problemlos, sonst würde ja kein WLAN-Gerät eine IP-Adresse vom MT beziehen können, ganz zu schweigen vom Internetzugriff.

Ich hänge mal ein Screenshot der Switch-Konfiguration an. Zur Erklärung:

- die oben erwähnten VLAN1..4 sind tatsächlich 11..14
- VLAN 10 ist das LAN, wo die Fritzbox dran hängt. Der WAN-Port des MT (eth1) ist dort angeschlossen (Port 3 am Switch)
- Port 4: "Eingangsport" des MT (eth2). Darüber läuft sämtliche Kommunikation von/nach "Innen"
- Port 5/6: Trunk-Port zu jeweils einem AP
- Port 7-10: Für kabelgebundene Geräte im VLAN12
- Port 11-20: Für kabelgebundene Geräte im VLAN14
- Port 21-23: Für kabelgebundene Geräte im VLAN13
- Port 24: Default-VLAN Port

Eine weitere Beobachtung, die vermutlich mit dem oben genannten zusammenhängt:
Die Management-IP des Switches befindet sich im VLAN13. Diese kann ich ebenso nur von den Ports 21-23 erreichen, nicht aber von einem WLAN-Gerät an einem der APs.

ab5b1792f80b017475aa29e2eeb975ab - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: daarma
30.12.2014 um 19:52 Uhr
Achso, was ich noch vergessen habe:

Als weiteren Test habe ich mich mit meinem Notebok an einen der Trunk-Ports (5/6) quasi anstelle des APs drangehängt. Netzwerkkarte auf die jeweilige VLAN ID eingestellt und das andere Notebook (per Kabel im gleichen VLAN) angepingt. Ping war in beide Richtungen jeweils OK.

Bin irgendwie am Ende mit meinem Latein...
Bitte warten ..
Mitglied: aqui
31.12.2014, aktualisiert um 12:47 Uhr
Man sieht ganz klar, dass die Zielstation den Broadcast sieht, sie diesen auch beantwortet, er aber beim Gegenüber (also WLAN-Gerät am AP) nicht ankommt.
Oha...das sieht dann aber ganz klar nach einem Firmware Bug aus oder das Broadcast im AP irgendwie in Unicaszs gewandelt werden oder sowas.
Auf alle Fälle die aktuellste Firmware auf den AP flashen und nochmal dessen Setup durchsehen ob dort irgendwelche Features in der Richtung aktiviert ist.
Das darf so niemals sein und wäre gegen den Standard. Da ist es dann auch klar das du mit deinem Latein am Ende bist denn das ist ein Firmware Bug und da hilft auch noch so intensieves Suchen nicht !
Das ist dann ein klarer Fall für einen Umtausch !!!
Interessant wäre aber noch den Fall Kabel ins WLAN mal mitzusniffern. Der Kabel PC muss ja erst einen ARP Broadcast aussenden bevor er den ICMP Echo Request sendet.
So, und hier bringen wir wieder unser Wireshark in Stellung.....
Diesen schliesst du jetzt statt des APs einmal an dessen tagged Port an und snifferst die Pakete dort mit.
Dort MUSST du dann zwingend ein mit der VLAN ID tagged Paket dieses ARP Broadcasts sehen !!!
Ist das der Fall dann kannst du davon ausgehen das der Switch diese Frames richtig behandelt und forwardet. Das musst du sicher klären !!!
Dann schliesst du deinen mSSID AP wieder an und checkst ob du auf dem Wireshark (dann am WLAN Interface) auch diesen Broadcasts siehst !! Diesmal natürlich ohne VLAN Tag !
Das wäre ein sehr wichtiger Test zum Troubleshooting der Ursache !!
ACHTUNG !:
Tagged Frames werden im Wireshark nicht bei allen NICs angezeigt. NICs mit billigem Realtek Chipsatz sind meist unproblematisch. Intel basierte Chipsätze droppen aber alle tagged Frames und zeigen sie im Wireshark alles ohne Tags an.
Das kannst du immer sicher sehen das dein Wireshark an einem tagged Switchport niemals 802.1q tagged Pakete anzeigt.
Aber keine Sorge... ein kurzer Eingriff in die Registry fixt das Problem bei Intel ganz schnell:
http://wiki.wireshark.org/CaptureSetup/VLAN
bzw. im speziellen:
http://www.intel.com/support/network/sb/CS-005897.htm
Für Broadcom und andere Chipsätze gilt das entsprechend dort vermerkte.
Ansonsten den Wireshark auf dem RasPi nehmen der zeigt die 802.1q Tags auch sauber an

Zu deiner Switch Konfig:
Die Port Konfig für die Endgeräte in den VLANs solltest du bei der "Ingress Acceptance" unbedingt auf Untagged only stellen. Dort können ja niemals tagged Pakete auftauchen, denn Endgräte machen kein Tagging. Das verhindert das falsche tagged Frames über diese Ports Traffic senden können !
Die Management-IP des Switches befindet sich im VLAN13
Das ist ungewöhnlich und weist ebenfalls auf einen Fehlkonfiguration hin ! Die Management IP des Switches ist in der Regel IMMER im Default VLAN 1. Es sei denn....
Du stellst das im Admin Setup um !
Dort muss also irgendwo stehen das deine Switch Management IP nur über VLAN 13 erreicht werden kann ! Das ist definitiv ein Fehler in der Konfig wenn du den Switch immer im Default VLAN 1 erreichen willst zum Setup.
Ggf. machst du mal einen Factory Reset mit dem Switch und fängst nochmal ganz sauber an....?!
Als weiteren Test habe ich mich mit meinem Notebok an einen der Trunk-Ports (5/6) quasi anstelle des APs drangehängt. Netzwerkkarte auf die jeweilige VLAN ID eingestellt und das andere Notebook (per Kabel im gleichen VLAN) angepingt.
War das "andere" Notebook dann immer untagged in dem jeweiligen VLAN ?
Dieser positive Test würde erstmal zeigen das der Switch soweit alles richtig macht und der Fehler wirklich auf dem AP bzw. dessen Firmware liegt (Konfig Fehler des APs deinerseits jetzt mal ausgeschlossen ?!)
Deshalb mache mal den beschriebenen Test mit dem Wireshark oben am tagged AP Port ob du dort die ARP Broadcasts mit den entsprechenden Tags sehen kannst.
Ist das der Fall dann ist der pöhse Puhmann in jedem Falle der AP der sich nicht standardkonform verhält !
Kreist die Fehlerquelle dann jedenfalls genau ein !
Zur Not kannst du natürlich auch den RasPi tagged an den Switch hängen:
http://www.administrator.de/wissen/netzwerk-management-server-mit-raspb ...
Das würde aber nicht die eigentliche Ursache beseitigen sondern ist nur ein quick and dirty Workaround für einen fatalen Bug.
Bitte warten ..
Mitglied: daarma
01.01.2015 um 12:04 Uhr
Ein gutes Neues ersteinmal!

Den von dir vorgeschlagenen Test werde ich heute noch machen.

Was mich allerdings noch stutzig macht: Ein WLAN-Gerät (also am AP) kann immer den MT Router erfolgreich anpingen. Aus Sicht des APs ist es doch das gleiche Szenario. Erst aus Sicht des Switches haben wir eine andersartige Verbindung: der MT "hängt" an einem getaggten Port und der Raspi/Notebook oder was auch immer hängt an einem ungetaggten.

Übrigens: Das mit dem Management-Port des Zyxel im VLA13 habe ich gemacht. VLAN13 ist generell fürs Management der Geräte vorgesehen.
Bitte warten ..
Mitglied: aqui
01.01.2015, aktualisiert um 14:44 Uhr
Ein WLAN-Gerät (also am AP) kann immer den MT Router erfolgreich anpingen. Aus Sicht des APs ist es doch das gleiche Szenario.
Da hast du natürlich Recht.
Das lässt latent die Vermutung zu das du doch irgendwo einen Fehler in der Switch Konfig gemacht hast, da zwischen WLAN AP und MT ja immer nur tagged Ports am Switch verwendet werden. Es sähe damnach dann so aus als ob tagged tagged geht aber nicht auf untagged Ports am Switch bzw. die Pakets aus diesen VLANs nicht auf die vermeintlich untagged Ports geforwardet werden !
Das riecht nach einem Konfig Fehler dann.
Wie gesagt mach mal den Kabelhai Test....dann kannst du das schnell testen. Am besten immer Kabel basierend das du einen Test PC tagged dran hast und einen untagged am Switch.
> VLAN13 ist generell fürs Management der Geräte vorgesehen.
Ziemlich krank aber wenn Zyxel meint das macht Sinn haben die sicher ihre Gründe.... Welche das auch immer sein mögen ?!
Das bedeutet dann ja das Zyxel dann immer fest in der Default Konfig das VLAN 13 fest fürs Management einrichtet ?! Was machen denn User die Produktivtraffic im VLAN 13 haben ? Eigentlich ist diese Option purer Unsinn aber egal...wenn man weiss das die das machen ist ja gut.
Laien suchen sich da dann einen Wolf.
Bitte warten ..
Mitglied: sk
01.01.2015, aktualisiert um 14:40 Uhr
Zitat von aqui:

> VLAN13 ist generell fürs Management der Geräte vorgesehen.
Ziemlich krank aber wenn Zyxel meint das macht Sinn haben die sicher ihre Gründe.... Welche das auch immer sein mögen
?!
Das bedeutet dann ja das Zyxel dann immer fest in der Default Konfig das VLAN 13 fest fürs Management einrichtet ?! Was
machen denn User die Produktivtraffic im VLAN 13 haben?

Nicht ZyXEL hat dies vorgegeben, sondern der TO möchte dies so und hat dies daher so eingestellt!


@daarma: Warum sehe ich in Deinem obigen Screenshot nirgends ein VLAN mit der VLAN-ID 4 auftauchen, wenn doch der RasPi untagged in diesem VLAN sein soll?


Gruß
sk
Bitte warten ..
Mitglied: aqui
01.01.2015, aktualisiert um 14:47 Uhr
Oha, sorry, das müssen noch die Spätfolgen von gestern gewesen sein.
Wer lesen kann.....
Ich nehm' alles zurück und behaupte das Gegenteil !!! Wäre auch sehr ungewöhnlich gewesen...!
Warum sehe ich in Deinem obigen Screenshot nirgends ein VLAN mit der VLAN-ID 4 auftauchen
Das ist in der Tat sehr richtig !! Manchmal sieht man den Wald vor lauter Bäumen nicht...!
Bitte warten ..
Mitglied: layer8slayer
01.01.2015 um 14:51 Uhr
Hi und Frohes Neues Jahr!!!

Die ID 4 könnt ihr nicht sehen, weil das eigentlich ID 14 ist.

Hat der Kollege aber auch oben erklärt

Gruß

l8s
Bitte warten ..
Mitglied: aqui
01.01.2015 um 15:35 Uhr
Ächz....na dann ist ja alles gut
Bitte warten ..
Mitglied: sk
01.01.2015, aktualisiert um 15:51 Uhr
Zitat von layer8slayer:

Die ID 4 könnt ihr nicht sehen, weil das eigentlich ID 14 ist.
Hat der Kollege aber auch oben erklärt

Dachte ich mir schon. Hatte ich beim Überfliegen nur nicht gefunden.

@daarma: Bitte auch mal die relevanten Screenshots vom Accesspoint beisteuern (jeweils zumindest die Unterpunkte "General Setup" von "LAN" und den beiden Wireless-Interfaces)!

Gruß
sk
Bitte warten ..
Mitglied: daarma
02.01.2015, aktualisiert um 23:19 Uhr
Ich habe jetzt am Kabel zum AP mitgeschnitten und bin genau so schlau wie zuvor...

Also, nochmal kurz das Setup:

Ein PC (X) hängt untagged direkt am Switch-Port.
Ein anderer PC (Y) hängt am AP per WLAN. Der Switch-Port (5 oder 6 oben) ist tagged. Auf Y wird per Wireshark mitgeschnitten.
Beide im VLAN14.

X versucht Y anzupingen. Im Wireshark auf Y sehe ich die ARP-Pakete als zum VLAN14 gehörend. Der Ping kommt zustande (ebenso in die Rückrichtung).

Nun wieder den AP angeschlossen und Y per Kabel am A2 Port des AP angeklemmt (per A1 Port ist der AP an den Switch angeschlossen). X versucht immer noch zu pingen und ich sehe dessen ARP-Requests mit korrekter VLAN ID im Wireshark.
--> das sagt mir, dass der Switch eigentlich korrekt konfiguriert sein müsste (offensichtlich spiegelt der AP dessen eingehenden? Traffic auf die LAN-Ports)

Nun Y per WLAN verbunden und ich sehe am entsprechenden Interface keine ARP-Broadcasts mehr. Nicht einen einzigen.

Aaaaaber: Warum kann das gleiche WLAN-Geräte eine IP-Adresse beziehen (vom MT) und den Default-Gateway (ebenfalls MT) erfolgreich anpingen? Der einzige Unterschied ist: MT ist an einem tagged Port angeschlossen (Port4) und die anderen (wo es nicht klappt) am Port 11-20.

AP Konfiguration folgt noch...
Bitte warten ..
Mitglied: daarma
02.01.2015 um 23:16 Uhr
Hier noch die AP Settings

Als genereller Betriebsmode ist "AP" eingestellt.

General setup

5b435fe00b906c85b56d77594a745f07 - Klicke auf das Bild, um es zu vergrößern

2,4 GHz General settings (das Gleiche gibt's nochmal für 5 GHz)

cf524b61049918cd6086d7c5d5b18047 - Klicke auf das Bild, um es zu vergrößern


Im Management-Menü des AP habe ich ansonsten keinerlei Settings entdeckt, die mit dem Problem zu tun haben könnten.
Bitte warten ..
Mitglied: aqui
03.01.2015, aktualisiert um 14:47 Uhr
Ich habe jetzt am Kabel zum AP mitgeschnitten und bin genau so schlau wie zuvor...
Schade... hier hätte uns etwas detailierte und profundere Ergebnisse WAS und ob du da tagged Frames welcher Couleur auch immer, gesehen hast oder auch nicht sicher sehr weitergeholfen
X versucht Y anzupingen. Im Wireshark auf Y sehe ich die ARP-Pakete als zum VLAN14 gehörend. Der Ping kommt zustande (ebenso in die Rückrichtung).
OK, das sieht dann schonmal gut aus wenn der Ablauf ARP Broadcast, ARP Reply, ICMP Echo Request und ICMP Echo Answer dort sichtbar sind was vermutlich ja der Fall ist ?!
Nun wieder den AP angeschlossen und Y per Kabel am A2 Port des AP angeklemmt (per A1 Port ist der AP an den Switch angeschlossen).
Generell ein Problem denn du weisst NICHT wie sich der AP zwischen den Ports A1 und A2 verhält !!
Generell verhalten sich APs hier NICHT als 802.1q kompatible Switches ! Ein Port ist häufig ein optionaler PPPoE Port um den AP an ein DSL Modem zu klemmen usw.
Hast du das wasserdicht im Handbuch überprüft ???
Sehr viel besser und sinnvoller wäre es gewesen Y an einen parallelen tagged Port DIREKT am Switch anzuschliessen, der identisch zu dem Port konfiguriert ist wie der betreffende AP !
Dann auf dem Wireshark zu sehen WAS dort ankommt wenn X wieder die Ping Prozedur startet !
Dort MUSS dann ein 802.1q tagged Frame mit der VLAN ID 14 ankommen mit den entsprechenden 4 Paketen von oben !
Wenn das der Fall ist kann man wasserdicht davon ausgehen das der Switch sich Standard konform verhält und das der Fehler dann klar auf EINZIG auf dem AP liegen muss !
Idealerweise setzt man den Test PC Y nochmal tagged ins VLAN 14 (sofern die NIC das supportet) und checkt ob ein initiierter Ping von X dort fehlerfrei ankommt !
X versucht immer noch zu pingen und ich sehe dessen ARP-Requests mit korrekter VLAN ID im Wireshark.
OK das würde dann bedeuten das zwischen den Ax Ports des APs ein Switching stattfindet. Ungewöhnlich aber dann OK.
Zeigt dann das der Switch dann vermutlich korrekt arbeitet und der Fehler tatsächlich einzig nur im AP zu sehen ist !
Nun Y per WLAN verbunden und ich sehe am entsprechenden Interface keine ARP-Broadcasts mehr. Nicht einen einzigen.
Zeigt ja dann ganz klar das der AP diese Multivasts mit dem VLAN ID Tag 14 NICHT richtig forwardet !
VORSICHT hier: Billige mSSID fähige APs supporten oft nur eine Handvoll SSIDs. Es ist möglich das die z.B. VLAN IDs > 8 nicht mehr richtig detektieren.
Ein klarer Bug dann wäre das der Fall, aber zur Sicherheit solltest du deine VLAN IDs mit diesen APs mal im Bereich <8 halten nur um auf Nummer sicher zu gehen !
Sicher scheint aber zu sein das der AP ganz klar der Verursacher ist !
Warum kann das gleiche WLAN-Geräte eine IP-Adresse beziehen (vom MT) und den Default-Gateway (ebenfalls MT) erfolgreich anpingen?
Das ist in der Tat vollkommen unverständlich und total widersinnig. Allerdings muss man hier sagen das auch hier wieder der Broadcast (DHCP Request) wieder vom WLAN aus initiiert wird !!! Und eben wieder nicht vom LAN.
Es sieht demnach so aus also ob Broadcasts die vom LAN bzw. VLAN Draht Segment initiiert werden nicht durch den AP ins dazu koresspondierende mSSID WLAN geforwardet werden was dann diesen einseitigen Fehler verursacht !

Das AP Settings sieht soweit korrekt aus nur das du den Mixed Betrieb mit 802.11b immer vermeiden solltest. Wenn dann also nur .n oder .g mit .n.
Das ist aber WLAN technisch und hat mit dem eigentlichen Problem hier gar nichts zu tun !
Ist die Firmware dieses APs auf dem aktuellsten Stand ? (Hersteller Webseite)
Bitte warten ..
Mitglied: sk
04.01.2015, aktualisiert um 22:51 Uhr
Hallo Daarma,

für mein Gefühl bewegen wir uns hier noch immer zu sehr auf der Ebene von Mutmaßungen. Bitte richte am Switch einen Mirrorport ein, spiegle darauf den Traffic zwischen Switch und Accesspoint (also von Port 5 bzw. 6; siehe ftp://ftp.zyxel.com/GS1910-48/user_guide/GS1910-48_.pdf, Kapitel 5.10.1) und schneide diesen Traffic per pcap mit. Dieses Capture bitte auf einem Filehoster ablegen, so dass wir uns das selbst ansehen können.

Gruß
sk
Bitte warten ..
Mitglied: daarma
07.01.2015, aktualisiert um 18:40 Uhr
Hi sk (et al)

danke fürs Angebot... vllt werde ich nochmal drauf zurückkommen. Man weiß ja nie.

Das aktuelle Problem hat sich insofern erledigt, als ich neulich einen anderen AP (Linksys LAPN600) testweise besorgt habe. Mit diesem geht alles problemlos bei gleicher Switch-Konfiguration. Zyxel scheint also nicht an dem Disaster schuld zu sein, sonder definitiv der Draytek AP.
BTW, ich habe die aktuellste Firmware draufgehabt, weil ja schon die Frage danach im Verlauf des Threads aufkam.

Auf jeden Fall habe ich durch die Fehlersuche viel gelernt.

Danke euch allen auf jeden Fall für eure Zeit und Mühe!

Grüße
daarma
Bitte warten ..
Mitglied: aqui
07.01.2015 um 19:39 Uhr
Da ist man natürlich nicht gefeit vor wenn die HW einem solch grundlegende Streiche spielt...aber gut wenns nun klappt !

Dann fehlt ja nur noch ein beherztes
http://www.administrator.de/faq/32
Bitte warten ..
Mitglied: sk
08.01.2015 um 18:57 Uhr
Zitat von daarma:

Das aktuelle Problem hat sich insofern erledigt, als ich neulich einen anderen AP (Linksys LAPN600) testweise besorgt habe. Mit
diesem geht alles problemlos bei gleicher Switch-Konfiguration. Zyxel scheint also nicht an dem Disaster schuld zu sein, sonder
definitiv der Draytek AP.

Das war naheliegend. Ich hätte gerne noch das Verhalten des DrayDreck eingehender untersucht und konkret gewusst, was da falsch läuft.

Gruß
sk
Bitte warten ..
Neuester Wissensbeitrag
Ähnliche Inhalte
Netzwerkgrundlagen
gelöst Ping im gleichen Rechnernetz ohne Gateway möglich? (8)

Frage von CHRISTI4N zum Thema Netzwerkgrundlagen ...

Windows Server
SBS2008 AD funktioniert nur im LAN mit bestimmter IP. wie ändern? (13)

Frage von tomeknfr zum Thema Windows Server ...

LAN, WAN, Wireless
gelöst Wake on LAN funktioniert teilweise nicht (11)

Frage von DarkScabs zum Thema LAN, WAN, Wireless ...

Netzwerke
gelöst Ping zu Windows Server funktioniert im OpenVPN netz nicht (5)

Frage von ketanest112 zum Thema Netzwerke ...

Heiß diskutierte Inhalte
Windows Userverwaltung
Ausgeschiedene Mitarbeiter im Unternehmen - was tun mit den AD Konten? (33)

Frage von patz223 zum Thema Windows Userverwaltung ...

LAN, WAN, Wireless
FritzBox, zwei Server, verschiedene Netze (21)

Frage von DavidGl zum Thema LAN, WAN, Wireless ...

Viren und Trojaner
Aufgepasst: Neue Ransomware Goldeneye verbreitet sich rasant (20)

Link von Penny.Cilin zum Thema Viren und Trojaner ...