MikroTik über LBS steuern | Edomi

[saegefisch]

Okay, einen Schritt weiter, ich Ursache habe ich wohl gefunden, bin mir aber unsicher, ob's ein Bug im MT ist oder eine Fehlkonfiguration von mir:

• Habe für die Haustechnik als wichtigsten Datenverkehr einen Switch mit 5 Ports spendiert, u.a. für KNX-IP-Router und edomi. Die Ports habe ich als Acces-Ports meines VLAN020 konfiguriert - so dachte ich.
• Heute Nacht ist mir per Torch aufgefallen, dass zwar der ganze UDP-Verkehr getagged wird, aber der http-Verkehr nur teilweise(!?!). Das scheint die Wurzel des Übel zu sein; das warum und die Systematik, warum mal mehr, mal weniger ungetagged, ist mir unklar.
• Stecke ich edomi an einen Access-Port meines manged Switches, wird alles sauber getagged als Trunk vom Switch an den RB3011 und weiter an die hAP geliefert. Damit funktioniert der Zugriff auf edomi an allen Orten nun verlässlich. Ich kann den gleichen Effekt bei einem DALI-Interface ebenfalls reproduzieren.

Ich war der Auffassung, dass ein Access-Port in den Switch-Einstellungen erfolgt: z.B. "ether03 | switch1 | fallback | always strip | 20", doch das war wohl ein Trugschluss. Auch mit "check" oder "secure" bleibt ein Teil des http-Verkehrs ungetagged.

Fazit: Erst einmal geht es - aber es bleibt ein "Geschmäckle" und es ist für mich nicht zielführend, da ich mir mit der Portaufteilung ja etwas dachte. Stellt sich die Frage, wie man einen verlässlichen Access-Port konfiguriert und ob das mit der neuen VLAN-Lösung an den Bridges (ab 6.41) vielleicht richtiger geht. Der manged Switch kann's ja auch...

Kann jemand am MT reproduzieren, dass die Access-Ports nicht 100% sauber taggen am ether des edomi (Szenario: edomi <--access--> MT <--trunk--> hAP <--access--> PC oder WLAN mit obigen Switch-Einstellungen an MT und hAP), wann man am PC/WLAN das edomi-WebFrontend aufruft?

[jonofe]

Erklärt das denn, warum es am hAP1 funktioniert hat und am hAP2 nicht? Oder tritt das Problem an beidem hAPs auf ubd dann nur in unterschiedlicher Intensität. Wenn es nur an hAP2 passiert, dann wäre meine Frage, ob du schon mal die beiden Stecker im RB3011 von hAP1 und hAP2 getauscht hast, um zu sehen, ob das Problem dann beim hAP1 (stärker) auftritt?

[Klaus007]

Wie hast du die Anschlüsse am RB3011 verteilt? Er hat hardwaremäßig zwei Switchchips (P1-5, P6-10) und vielleicht liegt darin das Problem.

Nachtrag: Grundsätzlich sollte man sich bei MikroTik immer auch das Blockschaltbild ansehen, dort sieht man dann auch, wie und mit welcher Geschwindigkeit die einzelnen Switchgruppen mit der CPU/untereinander verbunden sind.

[Marha]

Hallo,

ich kann nur von einem RB2011 berichten. Bei mir hängt Edomi am Fast Ethernet Switch. Die Ports sollten bei mir alle am vlan40 hängen und sind ausgangsseitig auf "Always Strip" eingestellt. Den Mode Fallback/Check/Secure habe ich auch versucht. Sobald der Switch Port oder die SwitchCPU am VLAN teilnehmen, habe ich kein Zugriff mehr auf Edomi. Ich hatte auch die Kabel in Verdacht. Bei gleichen Einstellungen, allerdings beim Gigabit Ethernet des RB2011 ist Edomi problemlos erreichbar. Das Verhalten hört sich ähnlich an. Mir war es bisher nicht möglich, das ganze näher zu untersuchen, deshalb läuft Edomi im Moment wieder auf dem Fast Ethernet Switch, der aber komplett nicht am VLAN teilnimmt (disabled). Wie kann ich am besten überprüfen, ob die Protokolle getaggt werden?
Ansonsten läuft mein Netzwerk mit MikroTik Komponenten recht gut.

[vento66]

Wen Du das VLan Tagst, musst Du auf Deiner EDOMi Kiste das VLAN auch einrichten, sonst muss der Port auf untagt stehen.

[Marha]

Die Einstellung am Switch Port
"Always Strip" sollte den Tag doch eigentlich wieder entfernen.

[coliflower]

Grundsätzlich (ist bei mir default) ist der VLAN-Trunk der vom Router/Switch am AP ankommt, TAGGED, sonst funkt es nicht. Der AP wandelt dann die VLANs von TAGGED in UNTAGGED, damit die Clients (Edomi) die Daten empfangen können und umgekehrt, wenn zB: Edomi etwas sendet, dann UNTAGGED zum AP und der AP wandelt es in TAGGED und sendet es weiter an den Router/Switch.

Hier ein Bildchen:

Netzwerk Topologie 20170905.jpg

[saegefisch]

Klaus007 : siehe hier - das habe ich mit viel Bedacht so gewählt, genau wie Du vroschlägst mit Blockschaltbild. Daher hatte ich eigens den 1. Switch (1-5) nur für mein Haus-VLAN vorgesehen (5 Ports benötigt) , damit das als mein wichtigster Traffic komplett im Switch abgewickelt werden kann. Da ich den (einzigen) PoE-Ausgang 10 für einen hAP benötige, musste ich dafür alles andere in den 2. Switch legen und damit WAN auch auf eth6, nicht dem üblichen eth1.

jonofe : Habe alles probiert und getauscht, mit gleichen Kabeln und gelichem Port und getauschtem Port und jede Kombination davon der beidne hAP. Am Ende haben sie sich gleich verhalten - aber ledier nicht immer nachvollziehbar. So hatte ich manchmal einen "D" (statt "DC") in der ARP-Liste des einen, mal des anderen. Mal hatte ich bei einem ein traceroute-problem, mal beim anderen, mal bei beiden. Es gab auch in edomi immer wieder fehlende Request, KNX war weg,... obwohl beide direkt nebeneinander am 1. Switch mit den obigen Einstellungen "ether03 | switch1 | fallback | always strip | 20" als Access-Ports konfiguriert hatte. Zumindest dachte ich das.

Seit ich jetzt gestern KNX-IP-Router und edomi an Access-Ports des managed Switch habe, habe ich keinen einzigen Abbruch oder Fehler mehr zwischen edomi und KNX-IP-Router. Ich kann per beider hAP (CAP oder LAN) verlässlich auf edomi zugreifen. Der manged Switch, wie auch die hAP sind als Trunk-Ports im 2. Switch des RB3011 verbunden.

Es sieht für mich so aus, dass neben tcp auch andere Protokolle sporadisch ungetagged aus dem Access-Port kamen und so das Ziel nicht erreichten; anders kann ich mir die sporadischen KNX-Abbrüche oder den sporadischen traceroute-Verlust nicht erklären. Warum und warum das wechslend viel war, vermag ich weder zu verstehen, noch eine Ursache mir vorstellen zu können. Eigentlich sollte derlei gehen oder nicht. Aber doch nicht so! Arrgh! Naja, ich mach lang genug (andere) IT, um zu wissen: Computer sind halt auch nur Menschen und Zicken!

Ich muss jetzt unerwartet doch ins Auto zum Kunden steigen (vermutlich ganz in Deiner Nähe, jonofe) und werde den Rest der Woche aus der Ferne hoffen müssen, dass edomi, TV, Musik, Internet für meine Familie so gut laufen, wie die letzten 24h. Aber ich bin zuversichtlich; Szene, ZSU und der ganze Rest geht bislang...

Marha : bei "fallback (oder check oder secure) | always strip" würde ich erwarten, dass im outbound immer gestripped = ungetagged der Port ausliefert, und jeder inbound-Traffic getagged wird, damit der Switch-CPU und Router sauber mit den getagged Paketen arbeiten können. Mir scheint aber, dass vermutlich der outbound ging, aber der inbound (=Daten von edomi) nur teilweise getagged wurden.

[saegefisch]

• Es bleibt für mich die Frage, warum die Konfiguration des Access-Ports nicht sauber funktioniert. --> Bug? Oder habe ich die Paramter falsch verwendet? Hier dient es sicher auch anderen, wenn es von den MikroTik-Experten eine Meinung gibt.
• Die aktuelle Lage ist okay, aber ich werde das neue Bridge-VLAN (ab 6.41) dennoch mal testen, denn ich will nich 5 Ports meines RB3011 brach liegen lassen. Mit Backup des aktuellen Stand und einem anderen Script-Satz kann man das ja rasch testen und wieder zurück.
• Firewall-Scripte kommen dann vermutlich kommende Woche auch als Vorlage; gerade das inter-VLAN ist ganz spannend.
• Meine Frage zum Multicast (siehe oben) bleibt auch spannend, weil mir derzeit diverse Informationen in edomi fehlen aus anderen VLAN --> HIer wäre ich sehr dankbar für Input...

[coliflower]

Ich weiß das hilft jetzt nicht aber für die die es noch überlegen ...
Bin echt froh, meine APs bei meconet.de gekauft zu haben (war damals eine Empfehlung von MarkusS) ... Dort hilft dir der Chefe selbst, solange bis das Ding läuft (ist eine Service und ein MT-Spezialist).

[saegefisch]

Hey Dariusz, für die gleiche Zielgruppe merke ich an: Ich habe echt viel Frust mit dem MT gehabt und unfassbar viel Zeit dafür investiert, es recht tief zu begreifen. Und ich habe nicht damit gerechnet, in so eine fuzzy-Falle zu tappen. Aber egal: Was jetzt daheim läuft, ist wirklich geil mit allen Möglichkeiten. Gegenüber meiner FB ist es ein riesen Fortschritt, ich würde mir den RB mit den hAP sofort wieder kaufen. Egal wo...

Jetzt hätt' ich nur noch gerne die letzten Baustellen gelöst: verlässliche Access-Ports und interVLAN-Multicast. Aber bei der Community hier und andernorts und auch der Intensität der Entwicklung seitens MT habe ich keinen Zweifel, dass es ein wunderbares Produkt ist und sich das auch noch auflöst...
Immerhin konnte ich gestern endlich mal wieder 2 neue Visu-Seiten in edomi machen...

PS: Dank' auch an André, dass er mir damals zum MT geraten hat. Viel Beitrag zum Erfolg - und sogar geholfen bei Problemen, die ich ohne Deinen Rat nicht gehabt hätte...

[Janncsi]

Genau so geht es mir mit Mikrotik auch. Selbst wenn man noch nicht alles beendet hat, auf dem Stand, auf dem es läuft, läuft es sauber.

[jonofe]

PS: Dank' auch an André, dass er mir damals zum MT geraten hat. Viel Beitrag zum Erfolg - und sogar geholfen bei Problemen, die ich ohne Deinen Rat nicht gehabt hätte...

Haha ... ich helfe gerne bei Problemen, die man ohne mich nie gehabt hätte.

[saegefisch]

wieder daheim vom KUnden...rechtzeitig zum WE - vielleicht schaffe ich ja das MT-Thema zu finalisieren:

• Hat jemand eine Rückmeldung, ob für die Access-Ports ich falsche Paramter nutzte (s.o.) und wie es besser geht oder ob die Parameter richtig erscheinen und jemand das Verhalten bestätigen kann oder eben nicht?
• Und die Frage: Multicast von einem VLAN in ein anderes VLAN - wie geht das...? Mein edomi vermisst wirklich seine Werte vom Energymeter...

[urknall]

Hallo genaue Lösung habe ich jetzt nicht parat, aber vielleicht einen Hinweis in die richtige Richtung.

Als Destination Adress Type gibt es Broadcast und Multicast, vielleicht muss man den explizit erlauben/forwarden, oder sonstiges mit anstellen zwischen den entsprechenden VLANs:

Verwerfen kann man z.B. so:

chain=forward action=jump jump-target=drop dst-address-type=broadcast,multicast log=no log-prefix=""

Edit: Geht wohl doch ganz anders, per PIM Routing:

https://wiki.mikrotik.com/wiki/Manual:Routing/Multicast

Evtl. geht es auch mit IGMP-Proxy:

https://wiki.mikrotik.com/wiki/Manua...ing/IGMP-Proxy

https://mum.mikrotik.com/presentations/ID13/asnul.pdf