Netzwerk mit 1793VA vernünftig einrichten

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von backslash »

Hi tar,

"natürlich" kannst du die Traces nicht mit CTRL-C abbrechen. Du mußt dazu schon ein passendes Kommando eingeben, z.B. trace - all - oder wenn du den Trace mittels # eingeschaltet hast: einmal CRSR-UP und ENTER drücken...
Wenn auf deiner Leitung so viel läuft, daß der Trace einfach durchrauscht, dann mußt du gezielter fitern, z.B. indem du ein + vor die Adressen stellst - dann werden die Filter UND verknüpft statt ODER, also z.B.:

Code: Alles auswählen

trace # ip-ro +10.0.2.10 +10.0.4.10
Und ja, ein Trace kann so viel Last erzeugen, daß die Shell quasi nicht mehr dazwischen kommt, um Zeichen anzunehmen. Traces sind halt Debug-Hilfen und man sollte sich genau überlegen, was man tracet. Und auch bereit sein, ein Fenster mit "amok laufenden" Traces abzuschießen...


Der Trace mit dem Filter "echo request" zeigt dir ja schon mal, daß das LANCOM die Pakete zum Hue-Hub routet. Ob eine Antwort zurückkommt, läßt sich daraus nicht sagen, denn die Antwort würde "echo reply" enthalten. Hättest du als Filter nur "echo" eingegeben, dann wäre direkt eine Aussage möglich...

Aber vemutlich blockt der Hue-Hub Zugriffe aus fremden Netzen - dann zeigt er dir auch keine Template-Seite im Browser an...

Gruß
Backslash
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von Jirka »

tar hat geschrieben: 09 Feb 2021, 16:50 Kleine Seitenbemerkung: Ich kann trace-Befehle nicht mittels STRG+C und auch nicht mittels der Special Commands im PuTTy-Fenstermenü (BREAK und diverse SIG-Befehle) abbrechen.
Works as designed...
Wenn Du 'trace # ip-router' eingibst, schaltest Du den Trace ein wenn er aus war und aus wenn er ein war. D. h. also wenn Du mit der Pfeiltaste nach oben den letzten Befehl noch mal aufrufst (und mit Enter bestätigst), dann ist der Trace wieder aus, wenn der letzte Befehl das Einschalten des Traces war...
tar hat geschrieben: 09 Feb 2021, 16:50 Kleine Seitenbemerkung: Ich kann ping-Befehle nicht mittels STRG+C und auch nicht mittels der Special Commands im PuTTy-Fenstermenü (BREAK und diverse SIG-Befehle) abbrechen.
Probiere es mal mit Enter...
Ich gebe aber zu, dass ich das mit dem Enter vor 15 Jahren auch noch nicht wusste, bis dato hatte ich immer stop und Enter eingegeben...

Davon abgesehen sieht es so aus, als ob Du in 2 Tagen ein Gerät konfigurieren möchtest, mit dem Du noch nie gearbeitet hast, da brauchen andere 2 Jahre für um das zu lernen... (ist jetzt nicht negativ gemeint, aber dass man da nicht alles weiß sollte man dann nicht unbedingt dem Gerät oder dem Hersteller in die Schuhe schieben...)

Zum Rest würde ich Dir auch gerne antworten, aber alleine alles zu lesen passt derzeit schon zeitlich nicht mehr. Hoffentlich lässt der Home-Office-Stress bald nach...

Viele Grüße,
Jirka
tar
Beiträge: 45
Registriert: 27 Jan 2021, 15:17

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von tar »

Okay, Laptop hängt am Switch Port 7 (Trunk, PVID 4) und vom Router erhält er die IP 10.0.4.11. Gateway auf dem Laptop ist 10.0.4.1, wie es sein soll.

Der Ping von 10.0.2.10 zu 10.0.4.11 ging nicht auf Anhieb. Erst bei ausgeschalteter Firewall auf dem Laptop.

Code: Alles auswählen

trace # ip-router @ "echo request"

[IP-Router] 2021/02/09 17:27:37,828
IP-Router Rx (LAN-1, FERTILE, RtgTag: 0):
DstIP: 10.0.4.11, SrcIP: 10.0.2.10, Len: 60, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x004d
Route: LAN-1 Tx (IOT):

usw.
Also routet er ordentlich durch.

Stutzig machte mich allerdings, dass ich auch vom Laptop den Hue weder anpingen kann, noch dessen Webseite angezeigt wird - obwohl beide im selben 10.0.4.x-er Netz mit VLAN 4 hängen. Also habe ich den Hue jetzt mal ins Management-VLAN 1 verschoben. Zack - kann ich ihn von der Workstation und vom Laptop aus anpingen und auch jeweils die Webseite sehen.

Hab ihn nun mal ins 2er Netz gehangen (10.0.2.50), wo ja auch die Workstation (10.0.2.10) hängt und das Verrückte ist: ich kann ihn hier von der Workstation aus weder anpingen noch die Webseite sehen. Dazu bräuchte er aber nichtmal den Router, da beides im selben Netz hängt. Was ist hier bloß kaputt?
backslash hat geschrieben: 09 Feb 2021, 17:47 "natürlich" kannst du die Traces nicht mit CTRL-C abbrechen. Du mußt dazu schon ein passendes Kommando eingeben, z.B. trace - all - oder wenn du den Trace mittels # eingeschaltet hast: einmal CRSR-UP und ENTER drücken...
Joa, ich hab dann auch gecheckt, dass das kein expliziter trace-mit-nem-Paket-Befehl ist, sondern nur die Paket-traces anzeigt, die halt so umherlaufen. Jetzt habe ich auch länger gebraucht, um drauf zu kommen, dass du mit CRSR "Cursor" meinst... Jesus :mrgreen:
backslash hat geschrieben: 09 Feb 2021, 17:47 Der Trace mit dem Fiter "echo request" zeigt dir ja schon mal, daß das LANCOM die Paket zum Hue-Hub routet. Ob eine Antwort zurückkommt, läßt sich daraus nicht sagen, denn die Antwort würde "echo reply" enthalten. Hättest du als Filter nur "echo" eingegeben, dann wärte direkt eine Aussage möglich...
Du wirst es nicht glauben, aber "echo reply" war ON - es hat nur eben nichts angezeigt.
backslash hat geschrieben: 09 Feb 2021, 17:47Aber vemutlich blockt der Hue Hub Zugriffe aus fremden Netzen - dann zeigt er dir auch keine Template-Seite im Browser an...
Nein, weil ich ihn im 1er-Netz (Management-VLAN) von Workstation und Laptop aus erreiche, aber bspw. innerhalb des 2er-Netzes nicht. Also im Grunde immer, wenn er einem anderen VLAN als 1 zugeordnet ist, ist die Kommunikation dahin. Es scheint so, als ob er kein VLAN akzeptiert oder keine Ahnung.
Jirka hat geschrieben: 09 Feb 2021, 17:53 Wenn Du 'trace # ip-router' eingibst, schaltest Du den Trace ein wenn er aus war und aus wenn er ein war. D. h. also wenn Du mit der Pfeiltaste nach oben den letzten Befehl noch mal aufrufst (und mit Enter bestätigst), dann ist der Trace wieder aus, wenn der letzte Befehl das Einschalten des Traces war...
Joa, gecheckt - aber es dürfte einfach zu flink durchlaufen und damit der (PfeilHoch->Enter)-Befehl nicht ankommen. Um alles zu sehen, kann man den gesamten Output ja notfalls im PuTTy-Log sichern.
Jirka hat geschrieben: 09 Feb 2021, 17:53 Davon abgesehen sieht es so aus, als ob Du in 2 Tagen ein Gerät konfigurieren möchtest, mit dem Du noch nie gearbeitet hast, da brauchen andere 2 Jahre für um das zu lernen... (ist jetzt nicht negativ gemeint, aber dass man da nicht alles weiß sollte man dann nicht unbedingt dem Gerät oder dem Hersteller in die Schuhe schieben...)
Aufregen fetzt halt - umso mehr, wenn dann merkt, dass man selbst was falsch gemacht hat (was ja meistens der Fall ist) :lol:

Im Grunde geht es bei mir um ein "simples" Heimnetz mit etwa 15 Endgeräten. Bislang hatte ich alles ganz simpel innerhalb eines Netzwerks und ohne irgendwelche Switches gehandhabt (2-3 Geräte am Router, Rest per WLAN), doch a) wurde ich darauf aufmerksam gemacht, dass man VLAN wg. Sicherheitsaspekten nutzen sollte und b) war ein Switch nun ohnehin fällig geworden, da meine neue Wohnung zentral verkabelt wurde und ich somit mehr Geräte per Ethernet zentral anbinden kann. Das verkompliziert nun alles, da ich aufgrund meines bisherigen Vorgehens eben VLANs und Routing noch nie explizit genutzt/benötigt und damit nie eingerichtet habe.

Danke trotzdem für eure Geduld mit mir... :M
tar
Beiträge: 45
Registriert: 27 Jan 2021, 15:17

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von tar »

Nochmal zurück zum VLAN, weil ich in meiner Planung womöglich völlig falsch denke.

Also mittels VLAN Tag teile ich Geräte einem gemeinsamen Netz (von anderen Netzen getrenntem Broadcast) zu - somit kann ich Geräte von anderen Geräten auf Layer-2-Ebene getrennt halten. Soweit, so gut.

Nun gibt es 3 Arten von Ports:
- Port zu Einzelgerät, dem man 1 VLAN zuordnen möchte
- Port zu Zwischengerät (Switch, Access Point), das wiederum selbst unterschiedliche VLANs an verbundene Einzelgeräte zuordnet
- Port vom Zwischengerät zum Router, der letztlich mit dem Zwischengerät und allen Einzelgeräten kommunizieren muss

Die beiden Beschreibungen in der Switch-Hilfe und in der LanConfig-Hilfe zum Router widersprechen sich bzgl. der Tagging-Modes komplett:
Switch-Hilfe:
If Access is selected, untag all frames transmitted on the port.

If Hybrid (the default value) is selected, if the classified VLAN ID of a frame transmitted on the port is different from the Port VLAN ID, a VLAN tag with the classified VLAN ID is inserted in the frame.

If Trunk is selected, a VLAN tag with the classified VLAN ID is inserted in frames transmitted on the port. This mode is normally used for ports connected to VLAN aware switches.

Router-Hilfe:
Access (Niemals): Ausgehende Pakete bekommen niemals ein Tag und ankommende Pakete werden behandelt als hätten sie keines. Ist bei ankommenden Paketen ein VLAN Tag enthalten, so wird dieses VLAN Tag nicht interpretiert, sondern das gesamte Paket inklusive VLAN Tag wird wie ein einfaches Ethernetpaket dem VLAN seines Empfangsports zugeordnet.

Hybrid (Gemischt): Erlaubt eine Mischung von Paketen mit und ohne Tag auf dem Port. Pakete ohne Tag werden dem Port VLAN zugewiesen.

Trunk (Immer): Ausgehende Pakete bekommen immer ein Tag, unabhängig davon ob sie dem Port VLAN zugehören. Ankommende Pakete ohne Tag werden verworfen
In Kürze:
- "Access": Beim Switch heißt es, dass alle etwaigen Tags entfernt werden. Beim Router heißt es aber, sie werden einfach durchgereicht.
- "Hybrid": Beim Switch heißt es, dass vom Port Tag abweichende Tags mit dem Port Tag ersetzt werden. Beim Router heißt es, bei ungetaggten wird der eigene VLAN Tag eingefügt.
- "Trunk": Beim Switch heißt es, dass alle den Port Tag erhalten. Beim Router heißt es aber, ungetaggte werden verworfen.

In Tabellenform:

Code: Alles auswählen

Tagging-Modus           ungetaggte Pakete            getaggte Pakete
-------------------------------------------------------------------------------
"Access" Switch-Hilfe   erhalten kein Tag            Tag wird entfernt
"Access" Router-Hilfe   erhalten kein Tag            Tag wird beibehalten

"Hybrid" Switch-Hilfe   erhalten das Port VLAN Tag   Tag wird zum Port VLAN Tag
"Hybrid" Router-Hilfe   erhalten das Port VLAN Tag   Tag wird beibehalten

"Trunk"  Switch-Hilfe   erhalten das Port VLAN Tag   Tag wird zum Port VLAN Tag
"Trunk"  Router-Hilfe   werden verworfen             Tag wird zum Port VLAN Tag
Was trifft denn nun wirklich für den jeweiligen Modus zu oder ist das Verhalten tatsächlich zwischen Switch und Router verschieden?

Ich frage, weil ich ja wissen muss, welchen Port ich wie korrekt einstelle und ob ein Layer-2-Zwischengerät (wie mein Switch) mit einem weiteren Zwischengerät verbunden werden kann, das wiederum selbst unterschiedliche VLANs an verbundene Einzelgeräte zuordnet (wie mein Access Point). Also dass der Switch die VLAN-Tags einfach mal komplett in Ruhe lässt und nur durchreicht. Das wäre laut Router-Hilfe der Modus "Access", den ich aber am Switch einstellen möchte, dessen Hilfe was anderes sagt.

Im Grunde müsste ich es ja so einstellen:
- Port am Router zum Switch: Pakete erhalten ihr Tag vorher (nicht durch den Port, sondern durch die Router-Software) und der Port darf das Tag nicht verändern -> entspricht "Access" Router-Hilfe
- Port am Switch zum Router: Pakete erhalten ihr Tag vorher (durch anderen Port, von dem das Paket ursprünglich stammt) und der Port darf das Tag nicht verändern -> entspricht "Access" Router-Hilfe (Sonderlocke wäre hier die Zuordnung vom Switch selbst, aber der hängt eh im Management-VLAN 1, also ist das bei der Verbindung zum Router wohl egal)
- Port am Switch zum Endgerät: Pakete erhalten das Tag durch den Port -> entspricht entweder "Hybrid" Switch-Hilfe oder "Trunk" Switch-Hilfe oder "Trunk" Router-Hilfe

Bei mir ist das aktuell aber so und funktioniert an sich (bis auf diverse Verhaltensauffälligkeiten):
- Port am Router zum Switch: "Hybrid" (identisch beim Port zum Access Point, da gleiches logisches LAN-1 genutzt wird)
- Port am Switch zum Router: "Hybrid"
- Port am Switch zum Endgerät: "Trunk"

Testweise habe ich den Port am Switch zum Router mal auf "Access" gestellt. Prompt kam ich von der Workstation (VLAN 2) nicht mehr auf den Switch. :G)

Sorry für die Textwand.
tar
Beiträge: 45
Registriert: 27 Jan 2021, 15:17

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von tar »

Okay, nach weiterer Recherche habe ich es nun wie folgt eingestellt und möchte erklären, wie ich es nun verstanden habe (mein Kenntnisstand ändert sich ja stündlich):

1. Alle Ports zu Geräten, deren Eingangskommunikation ein eindeutiges VLAN hat, sollten auf "Access" stehen, weil das Endgerät durch die Port VLAN ID genau 1 VLAN zugeordnet wird und keine weiteren Geräte dranhängen, die man mit VLAN Tags unterscheiden müsste. Das Endgerät selbst muss also mit den Tags in den Paketen nichts anzufangen wissen - sie sind daher am Endgerät irrelevant.
-> eingehende Tags können am Port ignoriert werden: alles, was ankommt, wurde durch die Port VLAN ID bereits korrekt hingeroutet
-> ausgehende Tags brauchen am Port nicht gesetzt zu werden: alles, was rausgeht, geht erstmal zum Switch bzw. (weiter) zum Router, der dann das entsprechende VLAN Tag des (Zwischen-)Zielgerätes setzt und das dann getaggte Paket weiterschickt

2. Alle Ports zu Geräten, deren Kommunikation von und zu verschiedenen VLANs läuft (Switches, Routern, Access Points), sollten auf "Trunk" stehen, weil diese unterschiedliche VLAN Tags übertragen können/sollen und das jeweils gesetzte Tag beibehalten werden soll, d.h. ungetaggte Pakete hier nicht ankommen dürfen/sollten, da klar sein muss, wo das Paket hingehen soll.
-> Tags wurden bereits durch den sendenden Switch/Router gesetzt - falls nicht, kann das Paket weg

Darüber hinaus gibt es noch "Hybrid", welches Access und Trunk zugleich unterstützt. Das nutzt man wohl, wenn man am Port angeschlossene Geräte oder deren Funktion öfters wechselt.

Zwei vor allem kurze, prägnante Erklärungen dazu findet man hier:
- IEEE 802 1Q: Tagging and Trunking 101
- VLAN and Trunking

Folglich:
- Ports am Switch zum Router und zum Access Point stehen auf "Trunk"
- Ports am Switch zu Endgeräten stehen auf "Access"
- Port am Router zum Switch steht auf "Trunk"

Nun erreiche ich auch problemlos von der Workstation (10.0.2.10) aus den Hue Hub (10.0.4.10). :D
C/5
Beiträge: 90
Registriert: 18 Jul 2019, 10:55

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von C/5 »

Hallo tar,
Sorry für die Textwand.
Ist sicherlich nicht verkehrt, dass Du so ausführlich dokumentierst. Allerdings muss ich zugeben, dass auch ich einfach nicht die Zeit habe, alles mehr als nur quer zu lesen. Als Retourkutsche hier meine Textwand .. :D

Ich will noch mal eine kleine Hilfestellung zur Konfiguration der Ports am Router und am Switch versuchen.

Vorweg: wenn das VLAN-Modul aktiviert ist, gibt es kein VLAN 0 mehr. Wenn Du den Eindruck hast, da ginge noch was, stimmt etwas nicht. Normalerweise ist dann alles erst mal VLAN 1, bis man weitere VLANs hinzufügt und zuweist.

Als Beispiel ETH1 -> LAN-1 -> darüber sollen die VLANs übertragen werden.

Dann willst Du, dass alle Pakete über LAN-1 getagged gehen. Immer. Und deshalb steht der Port in der Port-Tabelle im Bereich VLAN auf VLAN-Tagging-Modus 'Immer' sowie alle VLANs auf diesem Port zulassen und die Port-VLAN-ID auf 1.
In neueren LCOS heißt die Option nicht mehr 'Immer', aber der korrespondierende Begriff sollte klar sein.
Der Router nimmt also nur getaggte Pakete an und es verlassen auch nur getaggte Pakete den Router.

Jetzt zur Switch-Seite, dem Uplink-Port. Ich kann dazu im Moment nicht mit der Begrifflichkeit eines LANCOM Switch dienen. In einem ZyXEL wird der Uplink-Port auf 'Tagged only' (Ingress) und 'Tag all' (Egress) gesetzt. Es werden also nur getaggte Pakete akzeptiert und in Richtung Router verlassen den Switch auch nur getaggte Pakete. Wenn verfügbar, kann (muss) man die erlaubten VLANs für den Port spezifizieren. Die Port-VLAN-ID steht hier ebenfalls auf 1.

Bleibt als Muster noch ein anderer Port zu betrachten, an dem ein Endgerät in einem der VLANs stehen soll.
Dann will der ZyXEL für so einen Port 'Ingress Acceptance' 'Tagged and Untagged' haben und 'Egress Tagging' auf 'Untag Port VLAN'. Die Port-VLAN-ID ist auf das gewünschte VLAN gestellt, das an dem Port bedient werden soll.
Was bewirkt das?
Ingress ist die Regel für ein ankommendes Paket und zwar egal, ob es aus Richtung Router oder aus Richtung angeschlossenem Endgerät kommt. Egress vice versa wie das Paket den Switch-Port verlässt, gleich ob in Richtung Endgerät oder in Richtung Router. Insbesondere das 'Untag Port VLAN' sorgt dafür, dass in Richtung Endgerät dann die ungetaggten Pakete gehen, weil das Endgerät i.d.R. mit einer VLAN-ID an den Paketen nichts anfangen kann. Beim ZyXEL wird der Port auch noch durch 'Allowed VLANs' unterstützt und nicht nur durch die PVID definiert. Das stellt sicher, dass auf dem Port auch wirklich nur die Pakete für das betreffende VLAN anstehen.

Die Begrifflichkeiten irritieren allemal, auch weil jeder Hersteller ein gutes Stück weit sein eigenes Süppchen kocht.

Für das Endgerät ist normalerweise nicht erforderlich, auf der Netzwerkschnittstelle des Endgerätes ein VLAN vorzugeben. Sieht für den WL-AP je nach dem anders aus. Aber für portbasiertes VLAN ist ja gerade der Clou, dass die Endgeräte diesbezüglich nicht konfiguriert werden müssen und nichts von irgendwelchen VLANs wissen müssen.

In dem Screenshot aus Deinem Beitrag #16 zur Portkonfiguration des Switch taucht für meinen Geschmack viel zu oft 'C-Port' und 'Trunk' auf. Aus meiner Erfahrung kann ich Dir dazu mit auf den Weg geben, dass o.g. Prozedere für das portbasierte VLAN auf das jeweilige Konfigurations-Konzept und die Begrifflichkeiten des Herstellers zu übertragen. Da muss man einmal pro Hersteller durch. Ggf. durch systematisches ertesten.

Außerdem würde ich Dir gerne noch mit auf den Weg geben, dass zunächst ein einfaches Gerät vollumfänglich laufen sollte. Also der PC im entsprechenden VLAN zum Beispiel und dass Du die Konfiguration des Switch durchdrungen hast, bevor Du Dich an die Anbindung mit dem WLAN-AP machst und über den ggf. mehrere VLANs mit unterschiedlichen SSIDs ausstrahlen willst. Ansonsten wird die Gemengelage zu komplex.

Gruß
C/5

P.S.: Du hattest noch die Rückfrage zum Hinweis auf die statische Route in der Fritz!Box. Nun, wenn alles prima läuft, ist es ja gut. Aber falls Du später feststellst, dass Du auf Geräte in Deinem Transfernetz nicht richtig zugreifen kannst, die also z. B. nicht auf pings antworten, dann kann es daran liegen, dass für die IP-Pakete keine Rückroute existiert. Das Standardnetz einer Fritz!Box ist 192.168.178.1 und in dem Netzwerk ist die Fritz!Box üblicherweise auch das Standard-Gateway. Alles, was nicht für das 192.168.178.x-Netz ist, routet die FB deshalb ins Internet oder gar nicht (weil privates Netz). In dem Fall müsste man nachhelfen, damit für IP-Pakete in Richtung 10.0.x.x das Gateway eben nicht die Fritz!Box ist, sondern die WAN-IP des Lancom. Und genau das regelt eine statische Route auf dem Standard-Gateway.
tar
Beiträge: 45
Registriert: 27 Jan 2021, 15:17

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von tar »

Hallo C/5,
C/5 hat geschrieben: 10 Feb 2021, 12:25 Ist sicherlich nicht verkehrt, dass Du so ausführlich dokumentierst. Allerdings muss ich zugeben, dass auch ich einfach nicht die Zeit habe, alles mehr als nur quer zu lesen. Als Retourkutsche hier meine Textwand .. :D
Joa, hab grad nichts besseres zu tun - hält wenigstens den Kopf warm bei den Temperaturen :mrgreen:.

Danke jedenfalls für deine ausführlichen Erläuterungen. Damit hast du die Erkenntnisse, die ich vor ein paar Stunden gezogen und in meinem Vorbeitrag zusammengefasst habe, bestätigt.

Es hat mich halt die ganze Zeit verwirrt, weil man im Allgemeinen überwiegend Artikel zu tagged/untagged (ZyXEL, Netgear, ...) und nicht auf Access/Trunk/Hybrid (Cisco, LANCOM) bezogen findet bzw. nicht weiß, was nun was ist und genau tut und wieso. Als ich mir dann die LANCOM-Hilfe dazu anschaute und mir gedanklich vorstellte, wie die Pakete verlaufen, wurde ich wirr im Kopf. Erhellend waren letztlich die beiden verlinkten Videos. Zack, umgestellt und läuft.
C/5 hat geschrieben: 10 Feb 2021, 12:25In dem Screenshot aus Deinem Beitrag #16 zur Portkonfiguration des Switch taucht für meinen Geschmack viel zu oft 'C-Port' und 'Trunk' auf.
Ist bereits geändert: die Trunks sind jetzt Access und die Ports zu Router & AP sind Trunks. "C-Port" passt denke ich auch, weil "Unaware" Pakete sinnfreierweise doppelt taggt.
P.S.: Du hattest noch die Rückfrage zum Hinweis auf die statische Route in der Fritz!Box. Nun, wenn alles prima läuft, ist es ja gut. Aber falls Du später feststellst, dass Du auf Geräte in Deinem Transfernetz nicht richtig zugreifen kannst, die also z. B. nicht auf pings antworten, dann kann es daran liegen, dass für die IP-Pakete keine Rückroute existiert. Das Standardnetz einer Fritz!Box ist 192.168.178.1 und in dem Netzwerk ist die Fritz!Box üblicherweise auch das Standard-Gateway. Alles, was nicht für das 192.168.178.x-Netz ist, routet die FB deshalb ins Internet oder gar nicht (weil privates Netz). In dem Fall müsste man nachhelfen, damit für IP-Pakete in Richtung 10.0.x.x das Gateway eben nicht die Fritz!Box ist, sondern die WAN-IP des Lancom. Und genau das regelt eine statische Route auf dem Standard-Gateway.
Ah ja... also ich habe der Fritz!Box die feste IP 10.0.0.2 verpasst und im Router habe ich bei der IPOE-Einstellung die Router-IP auf 10.0.0.1 und das Gateway auf 10.0.0.2 gesetzt (Der Grund ist etwas dämlich - damit der Router in jedem Netz die 1 am Ende hat :P ).

Ich habe nun folgende Rückrouten in der Fritte eingetragen:

Code: Alles auswählen

Netzwerk  	Subnetzmaske  	Gateway  	
10.0.1.0	255.255.255.0	10.0.0.1	
10.0.2.0	255.255.255.0	10.0.0.1	
10.0.3.0	255.255.255.0	10.0.0.1	
10.0.4.0	255.255.255.0	10.0.0.1	
10.0.5.0	255.255.255.0	10.0.0.1	
10.0.6.0	255.255.255.0	10.0.0.1	
192.168.10.0	255.255.255.0	10.0.0.1
Internet läuft noch, also scheints zu klappen :lol:
tar
Beiträge: 45
Registriert: 27 Jan 2021, 15:17

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von tar »

Aloha,

ich bin's nochmal... und habe 2 Dinge, die nicht so recht klappen wollen:

1) SIP: Gesprächspartner hört mich nicht

für SIP-Telephonie nehme ich Phoner (bzw. PhonerLite), was auf der Workstation und gerade testweise auf dem Laptop läuft. Dafür nutze ich derzeit noch die SIP-Einstellungen der Fritz!Box, da die Nummer noch von meinem "alten" Provider angeboten wird. Ab April müsste ich das dann direkt auf der 1793VA mit den SIP-Daten der Telekom einrichten, da die Fritz!Box rausfliegt.

Problem: Ich kann anrufen und angerufen werden, höre dabei den Gesprächspartner, aber dieser mich nicht. Mikrofon ist allerdings aktiv und schlägt aus. Da ich lediglich den Router vorgeschalten habe, kann ja nur dieser die Ursache für dieses Verhalten sein.

In der Firewall habe ich eine explizite Allow-Regel für die Kommunikation zur Gegenstelle "INTERNET" mit keiner Einschränkung der Dienste/Ports. Testweise habe ich zusätzlich:
- eine Allow-Regel vom INTERNET zum Laptop, auf dem Phoner läuft, eingerichtet
- eine Allow-Regel vom Laptop zur Fritz!Box eingerichtet

Beides brachte keine Änderung.

2) IoT: Backofen und Geschirrspüler werden von der Handy-App nicht gefunden

Alle 3 Geräte verbinden sich per LEPS über den Access Point LW-500 und werden ihrem VLAN zugeordnet:
- mein Backofen befindet sich in VLAN #4 und hat die IP 10.0.4.20
- mein Geschirrspüler befindet sich in VLAN #4 und hat die IP 10.0.4.21
- mein Handy befindet sich in VLAN #6 und hat die IP 10.0.6.21

Nun kommt es zu einem seltsamen Verhalten. Der Geschirrspüler wird von der Handy-App gefunden, der Backofen aber nicht - obwohl die VLAN- und Firewall-Einstellungen für beide Geräte identisch sind. Nur wenn ich das Handy in dasselbe VLAN #4 schiebe (bspw. die IP 10.0.4.41 zuweise), erkennt die Handy-App beide Haushaltsgeräte. Damit würde hier aber der Sinn von VLANs verworfen.

Hat das vielleicht irgendwas mit Multicast (IGMP oder Bonjour) zu tun?

Ich habe den Bonjour-Dienst mal aktiviert und beide Subnetze eingepflegt, hat aber nichts gebracht. Dann wieder deaktiviert und beim letzten Versuch hat er dann auch den Geschirrspüler nicht mehr gefunden.

Könnt ihr mir helfen?
Pauli
Beiträge: 401
Registriert: 06 Mär 2006, 15:49

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von Pauli »

Servus,

bist Du bei den IOT Themen irgendwie weitergekommen?

Ich baue auch immer wieder an den Themen, aber da der Lancom intern nicht NATten kann bekomme ich es nicht wirklich hin. Viele IoT Geräte nehmen nur Paket aus dem eigenen Netz an und da hat man auch bei passendem Routing geloost - mal abgesehen dass ich mit dem Multicast Routing im Lancom noch nicht so wirklich klar komme ...

Gruß, Pauli
tar
Beiträge: 45
Registriert: 27 Jan 2021, 15:17

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von tar »

Pauli hat geschrieben: 05 Okt 2021, 09:06bist Du bei den IOT Themen irgendwie weitergekommen?
Hallo Pauli,

ich war dahingehend einige Wochen im Kontakt mit dem LANCOM-Support - dabei aber auch, weil mein Access Point ständig dieselben seltsamen Fehlermeldungen meldete/loggte.

Um es kurz zu machen: ich habe es nicht hinbekommen, dass meine IoT direkt im internen LAN zu meinen anderen Geräten (hier eigentlich nur die App auf dem Smartphone) kommunizieren, sondern a) ich nur zu den IoT kommunizieren kann (aber eben bei einem Event keine Meldung von diesen erhalte) oder b) per Web (Cloud-Anbindung) eine beidseitige Verbindung hinbekomme (was wir ja nicht wollen, da diese dann frei ins Netz dürften).

Die letzte Mail vom Support war diese, woraufhin ich erstmal keine Lust mehr zum Experimentieren hatte:
Bitte deaktivieren Sie für den Test alle anderen SSIDs, um ungewollte Wechselwirkungen auszuschließen.
Bitte beachten Sie, dass die Kombination von dynamischem (vom Radius oder LEPS) und statischem VLAN auf den LX Access Points aktuell noch Einschränkungen aufweist. Die gleiche VLAN-ID darf nicht gleichzeitig bei einer SSID statisch vergeben sein und zudem auf der gleichen oder einer anderen SSID dynamisch vergeben werden. Unsere Entwicklungsabteilung arbeitet daran, dies zu beheben, einen konkreten Termin zur Behebung dieses Verhaltens können wir aktuell noch nicht nennen.

Besteht die Möglichkeit nochmal mit nur einer SSID, welche das VLAN-Tagging übernimmt und einem Client ohne LEPS zu wiederholen?
Wenn ja, verändert sich da Fehlerbild?

Falls das Fehlverhalten bestehen bleibt, benötigen wir zur weiteren Analyse PCAP-Files.
Hierzu sollte es vorerst reichen, auf dem LAN und WLAN Port des LX APs mitzuschneiden. Dies geht komfortabel über die Weboberfläche unter: Diagnose > Paket-Capturing > Schnittstelle auswählen.
Pauli
Beiträge: 401
Registriert: 06 Mär 2006, 15:49

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von Pauli »

Danke, für das Feedback, auch wenn es mich wenig hoffen lässt ...

Also hats Du IoT bzw. SmartHome Systeme, die eine Verbindung zu Deinen Phone benötigen im internen LAN oder?

Ich habe ein ähnlichen Aufbau und einige IoT Geräte etc. auch in einem separaten IoT VLAN. In der Regel kommuniziere ich mit den Geräten dann nicht über das LAN sondern über extern via Cloud. Allerdings klappt das nicht immer oder mit allen Geräten. Bei Sonos kann man das genauso vergessen wie mit Philips HUE, zumindest habe ich es mit diesen Systemen noch nicht richtig hinbekommen. Hier wäre es durchaus schön, wenn sich Lancom daran versuchen würde und konkrete KB Artikel rausbringen würde - wenn es denn überhaupt funktioniert. Eine Netztrennung insbesondere der diversen IoT, Smart oder Multimedia Geschichten sollte eigentlich eine Basisanforderung sein, bei der dann auch ein Hersteller unterstützen kann ...

Was generell fehlt um manche Dinge in der Beziehung besser abbilden zu können, wäre internes NAT. Leider kann das der Lancom zwischen internen Netzen nicht, was aber bei diversen IoT Geraffel zwingend ist, da diese nur dem eigenen Netz antworten. Beim Natting könnte man das umgehen, was ich auch schon erfolgreich mit einer Sophos UTM getestet hatte.

Gruß und schönes WE, Pauli
tar
Beiträge: 45
Registriert: 27 Jan 2021, 15:17

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von tar »

Pauli hat geschrieben: 09 Okt 2021, 09:53Also hats Du IoT bzw. SmartHome Systeme, die eine Verbindung zu Deinen Phone benötigen im internen LAN oder?
Ich habe im Router 7 IPv4- & DHCPv4-VLAN-Netzwerke mit folgenden IDs eingerichtet:

Code: Alles auswählen

- 1 (10.0.1.1): "Management" (Router, Switch, Access Point)
- 2 (10.0.2.1): "Fertile" (PC, Server, Laptop, Drucker, Scanner, VMs)
- 3 (10.0.3.1): "Media" (TV, NVidia Shield Pro)
- 4 (10.0.4.1): "IoT" (Philips Hue, Siemens Küchengeräte)
- 5 (10.0.5.1): "Surveillance" (für Kameras vorbereitet)
- 6 (10.0.6.1): "Mobile" (Smartphone, Laptop-WiFi)
- 10 (192.168.10.1): "Guests" (für Gäste-Smartphones, -Laptop-WiFi, etc.)
IPv6 habe ich übrigens deaktiviert.

Dabei sind es 3 IoT-Geräte, die per WiFi-MAC-Adresse und LEPS über den Access Point dem VLAN #4 namens "IoT" zugeordnet werden:

Code: Alles auswählen

- 10.0.4.10: Philips Hue Hub
- 10.0.4.20: Siemens Backofen
- 10.0.4.21: Siemens Geschirrspüler
Philips Hue habe ich vom Smartphone und meiner Workstation (Windows-PC) aus steuern können. Wahrscheinlich saß da aber die Cloud dazwischen. Den Philips Hue habe ich mittlerweile abmontiert, weil die Lampe ständig flackerte. Das lag aber nicht am Netzwerk, weil sie das seit ca. 2 Jahren tat - also lange bevor ich mit LANCOM und VLANs hantierte.

Die Siemens-Geräte muss man umständlich mit dem Smartphone zu einem temporärem WLAN direkt am Siemens-Gerät verbinden und kann dann mit der Smartphone-App die eigentliche WLAN-Einstellung für das Siemens-Gerät vornehmen. Das ist zeitraubend und nervig, aber funktioniert an sich - hier mit und ohne LEPS ausprobiert.

Am Router habe ich noch folgende Einstellungen vorgenommen:

Code: Alles auswählen

- IP-Router -> Allgemein:
-- ICMP-Redirects senden: aktiviert
-- TCP SYN- und ACK-Pakete bevorzugt weiterleiten: aktiviert
-- DiffServ-Feld beachten: aktiviert
-- DiffServ-Tags aus Layer-2: ignorieren

- IP-Router -> N:N-Mapping: ich habe hier nichts eingestellt, könnte aber das NAT sein, von dem du sprichst?

- Multicast (das scheint essentiell für die IoT-Funktionalität zu sein)
-- Allgemein -> IPv4-Filter-Listen:
--- ANY, 0.0.0.0/0, Zulassen
-- IGMP/MLD:
--- IGMP-Proxy:
---- INTRANET, INTERNET, ANY
---- IOT, MOBILE, ANY
---- MOBILE, IOT, ANY
--- IGMP -> SSM-Bereich:
---- 10.0.4.0/8
--- IGMP -> SSM-Quell-Ip-Liste:
---- ANY, 0.0.0.0
---- BACKOFEN, 10.0.4.20
---- SPUELI, 10.0.4.21
-- PIM: aktiviert
--- Schnittstellen:
---- IOT, Ja, Ja, Ein, Aus, 30 Sekunden, 1, Nein, 2.500 Sekunden, 500 Sekunden
---- MOBILE, Ja, Ja, Ein, Aus, 30 Sekunden, 1, Nein, 2.500 Sekunden, 500 Sekunden
--- IPv4-SSM-Liste:
---- ANY, 0, BACKOFEN, BACKOFEN
---- ANY, 0, SPUELE, SPUELI
-- Bonjour: aktiviert
--- Netzwerk-Liste
---- IOT, Ja, IOT, MOBILE, TEST
---- MOBILE, Ja, MOBILE, IOT, TEST
--- Dienste-Liste
---- TEST: alle Dienste auswählen/zuordnen
--- Dienste der Netzwerk-Liste automatisch anfragen: aktivieren
--- Suchanfragen:
---- TEST1, Ja, IOT, TEST
---- TEST2, Ja, MOBILE, TEST

- Firewall/QoS
-- Allgemein:
--- IPv4-Firewall/QoS aktiviert
--- Die Layer7-Anwendungserkennung ausschalten - die funkt ggf. bei anderen Funktionen rein.
-- IPv4-Regeln (wäre natürlich geiler, falls man hier noch diffizil die wirklich nur notwendigen Ports herausfindet)
--- Smartphone usw. zu IoT zulassen 
--- IoT zu Smartphone usw. zulassen
--- ggf. IoT zu Web zulassen (damit die über die Cloud laufen, wenn sonst nichts geht)
Am Access Point gibt es dann 2 Möglichkeiten:

Code: Alles auswählen

- Variante 1: eine eigenständige SSID nur für IoT-Geräte erstellen und diese der VLAN-ID 4 zuweisen
- Variante 2: eine allgemeine SSID mit VLAN-ID 0 erstellen und per aktiviertem LEPS und zugehöriger Whitelist die WiFi-MACs der Geräte zur VLAN-ID 4 zuordnen
Egal wie, beides führt bei mir dazu, dass auf dem Acces Point die Siemens-Geräte aller paar Minuten eine Fehlerzeile werfen und keine Netzwerkdaten zu diesen angezeigt werden, obwohl sie eine korrekte IP zugewiesen bekommen. Das konnte der Support nicht lösen.

Ganz ohne VLANs habe ich es nicht probiert, weil das ja nicht Sinn der Sache ist :?
Allerdings funktioniert die Kommunikation natürlich beidseitig problemlos, falls Smartphone und IoT im selben (VLAN-)Netzwerk hängen, was ja auch wieder sinnfrei ist.

Also viel try & error und irgendwie nicht zufriedenstellend.
Pauli
Beiträge: 401
Registriert: 06 Mär 2006, 15:49

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von Pauli »

tar hat geschrieben: 09 Okt 2021, 15:02 Ich habe im Router 7 IPv4- & DHCPv4-VLAN-Netzwerke mit folgenden IDs eingerichtet:

Code: Alles auswählen

- 1 (10.0.1.1): "Management" (Router, Switch, Access Point)
- 2 (10.0.2.1): "Fertile" (PC, Server, Laptop, Drucker, Scanner, VMs)
- 3 (10.0.3.1): "Media" (TV, NVidia Shield Pro)
- 4 (10.0.4.1): "IoT" (Philips Hue, Siemens Küchengeräte)
- 5 (10.0.5.1): "Surveillance" (für Kameras vorbereitet)
- 6 (10.0.6.1): "Mobile" (Smartphone, Laptop-WiFi)
- 10 (192.168.10.1): "Guests" (für Gäste-Smartphones, -Laptop-WiFi, etc.)
IPv6 habe ich übrigens deaktiviert.
Ja so ähnlich sieht es bei mir ebenfalls aus.
tar hat geschrieben: 09 Okt 2021, 15:02Die Siemens-Geräte muss man umständlich mit dem Smartphone zu einem temporärem WLAN direkt am Siemens-Gerät verbinden und kann dann mit der Smartphone-App die eigentliche WLAN-Einstellung für das Siemens-Gerät vornehmen. Das ist zeitraubend und nervig, aber funktioniert an sich - hier mit und ohne LEPS ausprobiert.
Habe Bosch Geräte, also sollte dann Deinen Siemens sehr ähnlich sein, funktioniert das ganze schon, die Kommunikation läuft aber bei mir immer über die Cloud - stört mich aber nicht Hauptsache es funktioniert überhaupt in einem separaten VLAN. Aber ich gleiche noch mal Deine Multicast Konfig mit meiner ab.
tar hat geschrieben: 09 Okt 2021, 15:02 - IP-Router -> N:N-Mapping: ich habe hier nichts eingestellt, könnte aber das NAT sein, von dem du sprichst?
Nein, hat leider nix mit internem NATting zutun.
tar hat geschrieben: 09 Okt 2021, 15:02 Am Access Point gibt es dann 2 Möglichkeiten:

Code: Alles auswählen

- Variante 1: eine eigenständige SSID nur für IoT-Geräte erstellen und diese der VLAN-ID 4 zuweisen
- Variante 2: eine allgemeine SSID mit VLAN-ID 0 erstellen und per aktiviertem LEPS und zugehöriger Whitelist die WiFi-MACs der Geräte zur VLAN-ID 4 zuordnen
Ich habe separate SSID's für IoT, Multimedia oder Handys und fahre eigentlich ganz gut damit, zumindest funktioniert es für die genannten Geräte. Sonos z.B. in einem separaten Netz geht gar nicht und bei HUE habe ich wenig Hoffnung ...
tar hat geschrieben: 09 Okt 2021, 15:02Ganz ohne VLANs habe ich es nicht probiert, weil das ja nicht Sinn der Sache ist :?
Allerdings funktioniert die Kommunikation natürlich beidseitig problemlos, falls Smartphone und IoT im selben (VLAN-)Netzwerk hängen, was ja auch wieder sinnfrei ist.
tar hat geschrieben: 09 Okt 2021, 15:02 Also viel try & error und irgendwie nicht zufriedenstellend.
So sieht es aus, leider ...
overcast37
Beiträge: 73
Registriert: 30 Okt 2021, 09:26

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von overcast37 »

Moin, ich habe das gleiche vor wie du, aber nachdem ich deinen Threads komplett gelesen habe bin ich mir nicht mehr so sicher. Ich mag meinen Lancom Router und würde gerne bei den Hersteller bleiben. Hast du in der Zwischenzeit noch etwas verändern/verbessern können? Hast du Tipps für jemanden, der zum ersten mal VLan über Lancom einrichtet?

Ich wollte das ganze eigentlich mit einer Dream Machine Pro von Ubiquiti realisieren, weil es dort super einfach geht, aber ist halt Made in China und telefoniert auch gerne nach Hause bzw. die Sicherheit lässt zu wünschen übrig. Und jetzt bin ich unsicher (im wahrsten Sinne des Wortes)...
Pauli
Beiträge: 401
Registriert: 06 Mär 2006, 15:49

Re: Netzwerk mit 1793VA vernünftig einrichten

Beitrag von Pauli »

Naja, VLAN funktioniert schon einwandfrei und auch die 'normale' Kommunikation über VLAN hinweg funktioniert.

Nur sobald Multicast und spezielle IoT Themen kommen wird es schwierig ...

Also ich würde sagen fang mal an ud dann wird sich zeigen ob oder wo es in deiner Umgebung Problem gibt.

Pauli
Antworten