WLAN/Switch-Problem (ETH/DSL und ETH/LAN in eine Switch)

[Jirka]

Hallo zusammen,

ich habe hier eine sehr spezielle Frage:

Kurz zum Aufbau (damit die Sache verständlicher wird): Eine Firma in der Nähe von Ingolstadt hat mehrere Produktions- und Lagerhallen, jede Halle hat eine 48-Port Switch (Netgear/LANCOM). An der höchsten Lagerhalle befindet sich ein OAP (LANCOM Outdoor AP), der den Internetzugang bereitstellt (kein DSL verfügbar). Vom OAP führt ein Kabel in die Switch dieser Lagerhalle. Die Switche zwischen den Hallen sind vernetzt. Im Bürogebäude steht ein LANCOM 1821n, der die Einwahl ins Internet über den OAP macht und ins LAN per NAT routet, d. h. am 1821n ist ETH-4 für DSL-1 konfiguriert und ETH-1 bis ETH-3 für LAN-1. ETH-4 (DSL-1) und ETH-3 (LAN-1) führen beide in denselben nicht managebaren Netgear-Switch. Die Einwahl über den (W)ISP erfolgt per PPPoE (= Kommunikations-Layer T-DSL oder PPPoE). Das WLAN im 1821n ist als Bridge konfiguriert.

Problem: Clients im WLAN können keine DNS-Auflösung machen, weil sie die DNS-Server im LAN quasi nie oder sehr selten erreichen. Die ARP-Auflösung der IP-Adressen der DNS-Server schlägt fehl.

Problemanalyse: Es wurde festgestellt, dass das Problem nicht nur im WLAN auftritt. An ETH-1 oder ETH-2 des LANCOMs tritt das Problem ebenso auf. Clients, die dort angesteckt werden, haben das gleiche Problem.
Wird ETH-4 (DSL-1) am LANCOM ausgezogen (-> Internet weg), funktioniert die ARP-Auflösung einwandfrei.

Im Rahmen der Problemanalyse wurde die Gegenstelle fürs Internet im LANCOM mit einer benutzerdefinierten MAC-Adresse versehen - das hat leider nichts gebracht.
Ebenso wurden viele andere Sachen probiert, leider erfolglos.
Das LANCOM selber ist von dem Problem nicht betroffen.
Ethernet-Traces zeigen, dass die Clients regelmäßig ARP-Anfragen stellen, eine Antwort aus dem LAN kommt aber höchst selten beim LANCOM wieder an. Ich habe die Vermutung, dass - warum auch immer - die Antwortpakete am DSL-Port des LANCOMs aufschlagen.

Kann mir jemand sagen, ob eine solche Konfiguration unzulässig ist bzw. wie jetzt vorzugehen ist oder ob es sich dabei um einen Bug handeln könnte?

Vielen Dank und viele Grüße,
Jirka

Ach ja, an Firmwares wurde durchprobiert: 8.62-RU7 bis 8.82-RU1.

[backslash]

Hi Jirka

wenn du dem DSL-Port keine eigene MAC-Adresse gegeben hast (z.B. indem du in der DSL-Gegenstellen-Liste den den MAC-Adreß-Typ auf "lokal" stellst), dann hängst du nun mit zwei Ports, die die gleiche MAC-Adresse haben, an dem einen Switch - Da sit es reiner Zufall, an welchen Port dieser eine Switch Pakete weiterleitet...

Gruß
Backslash

[Jirka]

Hi Backslash,

auf lokal stand es von Anfang an, das kann demnach eigentlich nicht sein. Zwischenzeitlich hatte ich es auf Benutzerdefiniert mit MAC 00:a0:57:12:34:56. Das brachte aber leider, wie oben schon geschrieben, auch nichts.

Im ETH-Trace steht jetzt, nachdem ich wieder von benutzerdefiniert auf lokal umgestellt habe (und die WAN-Verb. neu aufgebaut habe) auch eine "lokale" MAC:

Source : 02:a0:57:14:95:ef (LANCOM(local-0) 14:95:ef)

Wenn die Pakete das LANCOM so verlassen, wie es im Trace aussieht, dann muss es was anderes sein...

Vielen Dank und viele Grüße,
Jirka

[alf29]

Moin,

bei so einem Problem wird man wohl nicht umhinkommen, sich durch die Adreßtabellen in den Switches zu wühlen. Da Du sagst, daß das auch bei einem Client auftritt, der direkt an einem der als LAN konfigurierten Ports des 1821 hängt, wäre das das Szenario, das ich mir näher anschauen würde, da sind die wenigsten Parteien beteiligt

Die Adreßtabelle des Switches im LANCOM kann man mit einem 'show eth atu' auslesen. Du solltest zwei Adressen mit <fixed> und Host-0 als Port sehen, das sind die eigenen MAC-Adressen (LAN und WAN), die das LCOS fix an den Port des Switches bindet, der zur CPU führt. Alle anderen Adressen werden dynamisch gelernt. Im Ethernet-Trace sieht man zusätztlich, vom welchem physischen Port ein Paket gekommen ist bzw. ob das LCOS ein Paket an einen bestimmten physischen Port schickt.

Gruß Alfred