Ping funktioniert im gleichen IP-Adressenbereich nur teilweise

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.
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.
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 !
Ist auch gut und solltest du für ALLE mSSIDs verifizieren und.... auch immer die Gegenrichtung checken !
OK, sollte auch so klappen und zeigt das die VLANs bzw. mSSIDs soweit richtig sind.
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.

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 !
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....?!
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:
Netzwerk Management Server mit Raspberry Pi
Das würde aber nicht die eigentliche Ursache beseitigen sondern ist nur ein quick and dirty Workaround für einen fatalen Bug.

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.

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

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...!
Das ist in der Tat sehr richtig !! Manchmal sieht man den Wald vor lauter Bäumen nicht...!

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

Ächz....na dann ist ja alles gut

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

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
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 ?!
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 !
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 !
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 !
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)

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

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
How can I mark a post as solved?