MikroTik über LBS steuern | Edomi

[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...

[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.

[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

[Marha]

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

[vento66]

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

[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.

[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.

[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?

[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?

[saegefisch]

PC und Laptop: gehen nicht. Der selbe Laptop am RB3011: geht.
Verkabelung: CAT5e - lief ja auch seit 14 Jahren unverändert... Und geht ja weiterhin mit allem anderen. Zwischen Patchfeld und RB3011 50cm Patchkabel fertig konfektioniert CAT5e (werde ich jetzt mal tauschen).
Werde jetzt auch mal die beiden hAP tauschen.

Nachtrag (Firewalls in allen RB/hAP derzeit aus):
* Kabel getauscht. Nicht besser.
* hAP getauscht. Damit wurde es oben schlechter: Nun auch per Winbox traceroute loss von 95-100%. SSH liefert jetzt "no route to host" (hat putty mir nicht gesagt und mit dem anderen hAP ging es ja. Aber wie kann die route nicht passen, wenn alle FW aus sind und andere Server im selben Subnetz erreichbar sind?
Die beiden hAP (ac und ac lite) sind fast exakt gleich aufgebaut; in den Scripten gibt es nur einen kleinen Unterschied für die VLAN, da technisch bedingt Fast-Ethernet ein Bridge-Port mehr braucht als und GBit-Ethernet (gibt dazu MT-Wiki-Doku)
* Ports der beiden hAP am RB3011 getauscht: nicht besser.

24h nutzlos und frustrierend verbracht mit der Ursachensuche, warum edomi nicht geht...werde mir jetzt mal ein Bier aufmachen und die hAPs beide auf Standard zurück setzen und dann mal schauen, was geht... an irgend etwas muss es ja liegen, nicht aufgeben...

[jonofe]

Hast du mal mit unterschiedlichen Geräten hinter dem 2. hAP versucht?
Hast mal nen Internet-DSL Speedtest gemacht ( hinter hAP1 und hAP2)?

Was genau heißt LSA+ Verkabelung? LSA+ ist ja nur eine Anschlusstechnik. Was hast du denn für ein Kabel vom hAP2 zum RB3011?

[saegefisch]

Nachtrag: edomi komplett von Grund auf mit CentOS neu installiert. An Backup gedacht und aller LBS und Einstellungen - leider vergaß ich, das Szenen und die ZSU-Zeiten nicht Teil des Projeklts sind und vermutlich anderes auch noch... Egal, Fakt ist: es hat nichts geholfen:

• edomi ist weiterhin unten erreichbar/nutzbar am RB3011 (LAN) und 1.hAP (CAP/WLAN).
• edomi ist via Winbox im 2.hAP erreichbar per Ping und traceroute mit 0% loss (>1000 Pakete) => besser geworden. ARP-Liste zeigt jetzt auch "DC". Damit kann es nicht an der LSA+-Verkabelung zwischen KG und DG liegen.
• edomi ist weiterhin oben nicht erreichbar hinter dem 2.hAP: Kein putty, kein Web, weder über LAN, noch CAP/WLAN), kein Ping am PC hinter dem 2.hAP (trotz FW komplett aus).

Es muss demnach im RB3011 oder dem 2.hAP oder deren Interaktion ein Problem geben, dass nur der edomi-Server nicht erreichbar ist, andere Server des gleichen (KNX-IP-Router, SMA energy meter) und anderer Subnetze (Linux-Server,...) aber durchaus.

[saegefisch]

• Keller: RB3011 im 19"Rack, daran (direkt) edomi, (direkt) KNX-IP-Router, (direkt) managedSwitch und an dem Switch fast der ganze Rest des Hauses inkl. Linux-Server, 2x NAS,...
• Keller: 1.hAP direkt am RB3011 und im Versorgungsschacht in EG-Höhe gehoben: nur für CAP/WLAN für unteren Hausteil
• DG: 2. hAP direkt am RB3011 (via 12m LSA+ Verkabelung und Patchfeld): CAP/WLAN für oberen Hausteil + als Arbeitszimmer-Switch (per LAN: Drucker, PC, Laptop)

edomi erreichbar...

• per WinBox->Tools->ssh von RB3011, 1. hAP und auch problemlos vom 2.hAP(!!!??!!!)
• per ping oder putty/ssh von einem PC per LAN an RB3011, nicht aber von einem PC per LAN an 2.hAP
• per Web von einem PC per LAN an RB3011, nicht aber von einem PC per LAN an 2.hAP
• per Web per WLAN (iphone) im unteren Hausteil, also CAP des 1.hAP, nicht aber oben mit CAP des 2.hAP (man sieht den cap-Wechsel im CAPsMAN)
• Alles andere im AZ-PC hinter dem 2.hAP (surfen, ETS, Zugriff auf alle anderen Server/NAS in allen Subnetzen) geht. Es ist nur edomi hinter dem 2.hAP...

Keine Queues.
2. hAP werde ich komplett wieder neu aufbauen (ist erst 3 Tage her...) - habe ja die Scripte, dauert nur 5 Minuten...
(Wenn das alles endlich final geht, gibt es hier auch einen finalen neuen Satz Scripte inkl. Firewall.)
Wenn das nix hilft, werde ich wohl edomi komplett neu installieren... :-/

Nachtrag: 2.hAP neu aufgebaut - Ergbnis unverändert: In 2.hAP per WinBox->Tool>telnet/ssh komme ich auf edomi, nicht aber hinter dem 2.hAP per CAP/WLAN ode LAN, weder mit putty, noch Web (egal, ob firewall an oder aus)... :-//

[jonofe]

Ich habe es noch nicht ganz verstanden: edomi am hAP1 und hAP2? Hängst du den EDOMI Server um? Oder meinst du wenn dein PC am hAP1 bzw. hAP2 hängt treten diese Probleme beim Zugriff auf EDOMI auf? Wo hängt der EDOMI Server denn dran?

Die denn die Ergebnisroute von traceroute korrekt, d.h. die kürzeste?

Ich glaube ich würde den zweiten hAP komplett zurücksetzen und neu konfigurieren.

Sind die Probleme nur per WALN oder auch per LAN?

Hast Du irgendwelche Queues definiert?

[coliflower]

Sorry, beim CAPsMAN kann ich absolut nichts beisteuern, da meine zwei wAP (nur) identisch konfiguriert sind und beide hängen via einem (Vlan) Trunk am Switch (HP) ... Somit ist bei mir am wAP nur das notwendigste konfiguriert (DHCP-Client für das Management VLAN1 (LAN), für alle anderen VLANs sitzt der DHCP-Server im Router, für jedes benötigte VLAN eine Bridge, die genannten VLANs und die dazugehörigen VPs ... der VLAN1 selbst hängt bei mir nicht im WLAN).
Das Routing/FW ins WAN und zwischen den VLANs macht die Firewall/Router (pfSense).

Solltest du beide hAP (grundsätzlich) gleich konfiguriert haben, dann sollte der Fehler entweder beim CAPsMAN und oder im Router zu suchen zu sein ...

Falls möglich, konfiguriere deine hAP identisch (kein Backup von einem zum Anderen, sondern Export) und nutze diese ohne CAPsMAN direkt am Router, wenn es geht, dann sollte der Router OK konfiguriert sein und du kannst dich näher mit CAPs beschäftigen - denk ich.