Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Wie bekommt man die den im Hex S deaktiviert, wenn man so wie ich ein Kabelmodem im Bridge Mode angeschlossen hat ? Die sind bei mir fest hinterlegt und ausgegraut.
Nachdem ich den Pihole aktualissiert habe, funktioniert nun dadurch wieder mal die Namensauflösung nicht.. .Wie hast du das im RouterOS hinterlegt, dass er das macht ?
Per Ping kann ich zwar die Gerätenamen anpingen, aber nslookup finde ich die nicht.Bin mir da jetzt auch nicht so sicher ob dass nur NetBIOS ist...
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Die Dynamic DNS musst Du an dem Interface deaktivieren, wo der MT sie bezieht.
Wenn er eine PPPoE Verbindung nutzt im PPPoE Client.
Wenn er per DHCP eine IP bekommt, dann im DHCP Client.
Hat jemand Erfahrung mit dem IGMP-Proxy in RouterOS?
Ich habe einen Windows-Anwendung im LAN/WLAN, die per Mulitcast auf ein Endgerät (PV-Wechselrichter) zugreifen muss.
Den Wechselrichter habe ich in VLAN gepackt.
Das Upstream-Interface ist das LAN (querier), downstream das VLAN.
Wenn der WR auch im LAN ist geht es.
Routerkonfiguration beachten Beim Einsatz von Routern oder Netzwerk-Switches mit Routerfunktionalität ist zu beachten, dass Speedwire neben der direkten Kommunikation mit einzelnen IP-Netzwerkteilnehmern auch Adressen aus dem Multicastbereich 239/8 nutzt. Die Multicast-Adressgruppe 239/8 (239.0.0.0 bis 239.255.255.255) wird von der RFC 2365 als ein lokal verwalteter Adressraum mit lokaler, örtlich begrenzter, oder organisationsweiter Ausdehnung definiert. Stellen Sie sicher, dass die Router und Switches in Ihrem Speedwire-Netzwerk die für die Speedwire-Verbindung benötigten Multicast-Telegramme (Telegramme mit der Zieladresse 239.0.0.0 bis 239.255.255.255) an alle Teilnehmer des Speedwire-Netzwerks weiterleiten
@martingo
Nachdem ich erst mal eine reihe an problemen auschließen konnte, sieht es soweit rellativ gut aus.
Dein Script ist hinterlegt, bzgl. der Wahl zum DNS Server (fallback).
Eine Sache ist mir aufgefallen, wenn ich von egal welchem Cient einen continuous Ping zu Google (8.8.8.8) starte, gehen die ersten ca. 10 Anfragen (schwankend) problemlos durch.
Dann erscheint eine Zeile Zeitüberschreitung, danach geht der Ping wieder für um die 4 bis 10 Anfragen druch.
Es kommt immer mal wieder dazwischen eine oder mehrere Zeilen zur Zeitüberschreitung.
Zufällig auch hier eine Idee was ich hier machen könnte? Sollte der Ping nicht solange die PPPoE verbindung besteht dauerhaft durchgehen?
Beitrag automatisch zusammengeführt:
Glaub ich habs gefunden, es war wohl die Leitung zum moment des Pings rellativ ausgelastet. Somit sind wohl einzelne Anfragen nicht durchgegangen.
Muss mir wohl das QOS mal näher anschauen.
Naja, ICMP wird normalerweise nicht besser priorisiert als der Rest. Du pingst, super Latenz, kein Loss, alles sieht toll aus und trotzdem läuft die Leitung am Limit.
Außerdem kannst Du Priorisierungen immer nur in Senderichtung vornehmen. Heißt, Du kannst es Upstream priorisieren, aber den Downstream priorisiert Dein ISP (oder auch nicht). Häufig ist ICMP dort sogar niedriger priorisiert, weil es eben keine Nutzdaten sind.
Das einzige, was Du dann machen kannst, wenn Dir ein guter Pingdurchsatz wichtig ist:
Angenommen, Deine Leitung bringt immer konstant 16MBit im Downstream durch.
Dann kannst Du das Senden von Router zu Deinen Endgeräten auf 15.5 MBit reduzieren (für alles außer ICMP) und hast auf Deiner Downstream Leitung noch ein halbes MBit für ICMP übrig. Im Voip Umfeld macht man das manchmal, aber für ICMP ist es meiner Meinung nach Käse.
Naja, ICMP wird normalerweise nicht besser priorisiert als der Rest. Du pingst, super Latenz, kein Loss, alles sieht toll aus und trotzdem läuft die Leitung am Limit.
Außerdem kannst Du Priorisierungen immer nur in Senderichtung vornehmen. Heißt, Du kannst es Upstream priorisieren, aber den Downstream priorisiert Dein ISP (oder auch nicht). Häufig ist ICMP dort sogar niedriger priorisiert, weil es eben keine Nutzdaten sind.
Ok, vermutlich sollte ich versuchen eine Lösung zu finden, da er ja mit deinem Script versucht 8.8.8.8 aufzulösen, und wenn kein respond, dann weitere schritte unternimmt. Somit sollte der Ping möglichst stabil bleiben, da er sonst unnötiger weise versucht den DNS anzupassen (obwohl eigentlich verfügbar, nur auf grund der belegten Leitung nicht sofort reagiert).
Auf jeden fall sollte ich mal den voip Traffic priorisieren. Also den Traffic meiner Telefonanlage.
Habe ich es richtig verstanden, das man erst mal die betroffene Connection , bzw die betroffenen Pakete per Mangle Regel markiert?
Der Traffic zählt auf jeden Fall schon mal hoch wenn ein Telefonat nach extern geht. So weit so gut.
Sollte man es ggf auf die einzelnen Protokolle / Ports herunterbrechen, also einzelne Regeln anlegen?
Es sieht mir nun so aus als würde die Simple Queue Regel no-mark mir nicht den gesamten Traffic über pppoe-out1 auswerten.
Diese ist wie folgt angelegt:
Zusätzlich noch die Frage kann man irgendwie die Verbindung via MAC-Addrese per Winbox unterbinden?
Danke
Grüße
Elektromat
Beitrag automatisch zusammengeführt:
Oder kann man ggf. in das Script so anpassen, das es erst reagiert, wenn der respond über einen bestimmten Zeitraum nicht kommt? Da wie mir aufgefallen ist es auf jeden Fall vorkommen kann, das die ersten Pings nicht direkt durch gehen, wenn die Leitung ausgelastet ist.
1. Fangen wir mit dem leichtesten an: winbox Server. Ja, du kannst die zulässigen Interfaces unter Tools > MAC Server > MAC WinBox Server ändern. Alternativ brauchst Du Level 2 Firewall Regeln.
2. DNS Skript: mein Skript macht keine Pings. Es versucht eine vordefinierte Domain per DNS aufzulösen. Wenn bei Dir regelmäßig DNS Requests hängen bleiben, hast Du mehr Probleme.
Was ich jetzt aber auch überhaupt nicht verstehe: Du wolltest doch deinen lokalen Pihole als primären DNS. Der sollte doch immer antworten, wenn er an ist, egal was auf der Leitung los ist.
Sicher könnte man auch mehr Versuche machen, aber ich sehe da keinen Sinn drin.
3. Queues: zunächst das Connection Mark nur auf Connections ohne Connection Mark setzen, sonst markiert er die Verbindung bei jedem einzelnen Paket erneut, was auf die Performance geht. Was er markiert, siehst Du unter IP > Firewall > Connections.
Für Queueing miss glaube ich Fastpath aus sein. Und wenn kein Limit hinterlegt ist, ist die ganze Regel inaktiv, soweit ich mich erinnere. Zumindest war das früher so.
2. DNS Skript: mein Skript macht keine Pings. Es versucht eine vordefinierte Domain per DNS aufzulösen. Wenn bei Dir regelmäßig DNS Requests hängen bleiben, hast Du mehr Probleme.
Was ich jetzt aber auch überhaupt nicht verstehe: Du wolltest doch deinen lokalen Pihole als primären DNS. Der sollte doch immer antworten, wenn er an ist, egal was auf der Leitung los ist.
Sicher könnte man auch mehr Versuche machen, aber ich sehe da keinen Sinn drin.
Sorry ein DNS macht natürlich die Namensauflösung. Hatte Nur die 8.8.8.8 gesehen und wohl das falsche rein interpretiert, nicht wirklich nachgedacht.
Wo ich mir den Log so anschaue, muss da tatsächlich was im argen liegen. Hatte vor nicht allzu langer zeit ein update auf 20.04 LTS gemacht. Da kann irgendwas nicht stimmen. Würde den Fehler dementsprechend nicht im Script suchen.
Ich mach die PiHole VM mal neu. Sollte ja schnell gehen.
3. Queues: zunächst das Connection Mark nur auf Connections ohne Connection Mark setzen, sonst markiert er die Verbindung bei jedem einzelnen Paket erneut, was auf die Performance geht. Was er markiert, siehst Du unter IP > Firewall > Connections.
Nachdem ich den Pihole aktualissiert habe, funktioniert nun dadurch wieder mal die Namensauflösung nicht.. .Wie hast du das im RouterOS hinterlegt, dass er das macht ?
Per Ping kann ich zwar die Gerätenamen anpingen, aber nslookup finde ich die nicht.Bin mir da jetzt auch nicht so sicher ob dass nur NetBIOS ist...
Im Mikrotik unter IP/DNS/static DNS, IP-Adresse und zugehörigen FDQN hinterlegen.
Dann im PiHole natürlich den Router noch als Upstream-DNS einfügen, damit du die Auflösung zentral hast.
Bin momentan nicht zuhause, mache morgen Abend oder am Sonntag mal Screenshots davon.
Es ist eingetragen im Schedule mit intervall 00:01:00
So PiHole ist nun auch frisch installiert, inkl. statischer IP. Snaps hab ich entsprechend angelegt. So ist ein rückwechseln auf einen sauberen Stand immer möglich. Oder auch sollte ich auf die Idee kommen den PiHole als Unbound einzurichten.
Ich habe mal alle meine MikroTik Geräte resettet. Und von Hand bzw. mit ausgewählten Konsoleneinträgen wieder auf Stand gebracht.
Seit heute Mittag ist die DNS problematik nicht mehr aufgetreten. Es bleibt nun so wie es sein sollte der PiHole als DNS Eintrag bestehend (solange dieser online ist).
Verstehe zwar absolut nicht an was es nun gelegen hat, aber jetzt funktioniert es problemlos.
Der Ping bleibt bisher auch stabil selbst wenn ein Download läuft, was vorher nicht funktioniert hatte. Und das ohne weiteres Regelwerk oder Limitierung.
Danke für eure Geduld.
Nutzt ihr einen USB stick oder ähnliches für Logfiles etc. an euren MT Geräten?
MikroTik DHCP Server lease script, which automatically updates static DNS records, based on assigned DHCP leases. Script also has some additional features.
blog.pessoft.com
So arbeiten Namensauflösung und DNS Failover (Dank Martingo) gemeinsam ^^.
@Elektromat Hatte ja ein so ähnliches Problem (paar Seiten vorher). Konnte auch nie ergründen was es war leider, nach nem Reset waren mit gleichen einstellungen die Probleme weg.
Es war mir leider nicht direkt aufgefallen, aber es besteht die Problematik mit den auftretenden DNS Änderungen auch weiterhin. :-(
Also habe ich weiter getestet:
- PiHole auf einem Pi 4 Modell B installiert, und nur diesen als Nr1 hinterlegt im MT - der DNS Wechsel bleibt bestehend. Somit sollte der ESXI (meine PiHole VM) nicht das Problem sein
Der Fehler besteht egal ob Pihole in einer VM oder PiHole auf nem Raspi 4B.
Wenn ich den Cloudflare DNS im Sript als nr. 1 hinterlege bleibt der DNS stabil. Einen Wechsel konnte ich nicht feststellen.
Ebenfalls hab ich mir ein neues Modem bestellt. Ein Draytek Vigor165. als Ersatz für den Vigor2860 der leider EOL ist. Werde testen sobald er da ist, vermutlich Morgen, ob damit das Problem weiterhin besteht.
Sollte das Problem hier auch fortbestehen bin ich so ziemlich ratlos.
Dann würde mir nur die Möglichkeit einfallen die Einwahl komplett von dem Vigor vornehmen zu lassen. Und an den MT übergeben. Wobei dies die allerletzte Wahl wäre, sollten alle weiteren Versuche scheitern.
Jemand noch ideen?
Nach viel hin und her ausprobieren läuft es nun stabil mit meinem Draytek Vigor 165.
Ich kann auf die Vergabe des VLAN7 im hEX S verzichten. Dies wird wohl über das DrayTek Modem gemanaged.
Ebenfalls hatte sich wohl der Fehler eingeschlichen, das die IP des hEX S auf die Bridge gelegt wurde. Dies hab ich nun auf den Uplink Port zum CRS317 gelegt.
Beim Testen war mir aufgefallen das im Log permanent versucht wurde der Bridge eine IP per DHCP zu vergeben. Dies aber dauerhaft gescheitert ist. Es war kein DHCP Client aktiv hinterlegt, auch nicht auf die Bridge.
Nach etwas längerem beobachten ist es nun stabil. Der DNS wechselt nur noch bei der PPPoE Einwahl / Reconnect. Oder Downtime der PiHole VM. Sollte sich zeigen, das doch ein localer DNS Backup benötigt wird, kann ich ja noch immer den Raspi mit ins Netz hängen. Wobei das vermutlich etwas übertrieben wäre. Da ja Cloudflare oder Google als Backup bereitstehen. Also so lange der hEX S eingewählt ist. Und wenn die Einwahl nicht steht gibts eh kein Internet/DNS.
Ich halte es weiter unter Beobachtung.
Eine Frage zu VLANs. Ich habe mehrere über einen Port am Laufen und diese sind entweder per Filter rule voneinander getrennt oder einzelne Geräte oder vlans verbunden. Ich habe aber keine Bridge am Laufen. Im Internet findet man nur Anleitungen mit der Bridge. Was ist der Vorteil an einer Bridge?
Mein Mikrotik steht leider 600 km entfernt aktuell, deshalb ist der Zugriff momentan nicht so einfach.
Was ich habe:
192.168.0.x: VLAN 1: "normales LAN"
192.168.10.x: VLAN 10: hier sind die services, Zugriff auf VLAN 1
192.168.30.x VLAN 30: weitere Services, die aber KEINEN Zugriff auf VLAN 1 und VLAN 10 haben
192.168.100.x: DMZ, kein VLAN, kein Routing zu VLANs. Nur vereinzelte Weiterleitung von Port 443 und 80 an einzelne Geräte.
Ich habe dabei keine Bridge im Einsatz, sondern schreibe in den Filter Rules vor, dass 192.168.0.0 und 192.168.10.0 miteinander kommunizieren können, während ich die Verbindung von 192.168.30.0 und 192.168.100.0 zu VLAN 1 und VLAN10 verbiete.
In den ganzen Tutorials ist jedoch der erste Schritt eine Bridge anzulegen. So wie ich das verstanden habe, wird dabei in etwa das gleiche gemacht wie meine Filter Rules, die die Verbindung zwischen VLAN1 und VLAN 10 erlauben, korrekt? Die Bridge würde dabei aber auch Verbindung zu VLAN 30 erlauben, die man dann separat in den Filter Rules verbieten müsste, oder?
Das sind einfach zwei Paar Schuhe.
Du hast noch immer nicht geschrieben, was Du eigentlich erreichen willst, insofern kann ich jetzt nur allgemeine Hinweise geben.
Eine Bridge hat den Vorteil, dass Du Deine Netze über mehrere Ports spannen kannst.
Konkret habe ich einen CRS mit einer einzigen Bridge (das ist auch sinnvoll, weil bei den CRS nur eine Bridge hardwarebeschleunigt ist). Der arbeitet nur als Switch. Auf die einzelnen Interfaces konfiguriere ich dann, welche Netze dort tagged oder untagged erlaubt sind. Damit wird keinerlei Zugriff untereinander geregelt - nachdem es wie bei Dir unterschiedliche Subnetze sind, muss das ohnehin geroutet werden. Auf dem Switch sind auch keine VLAN Interfaces angelegt (bzw. nur eines für die Switch Wartung).
Ein Mitglied der Bridge ist der sogenannte Trunk Port, das ist ein 10GBit DAC zu meinem CCR (Router). Ich denke etwa ab da fängt die Konfiguration an, die Du auch hast:
Routerseitig sind auf den Trunk Port dann VLAN Interfaces angelegt mit der Gateway IP der einzelnen VLANs/Subnetze. Der Internet Uplink hat logischerweise ein separates PPPoE Interface.
Wie bei Dir regelt den Zugriff dann die IP>Firewall>Filter.
Ob man hier mittels IP filtert oder auf Interfaces ist mehr oder minder Geschmackssache. Großteils erlaube ich per Interface über Interface Listen. Nur spezielle Dinge dann über IP/Port. Zum Beispiel Zugriff aus dem Gast-WLAN-VLAN nur auf den DNS des Domänen-Netzwerks.
So, dann ein kleiner Unterschied: mein Trunk Port ist auch auf dem Router eine Bridge. Hat nur ein physikalisches Interface (SFP+). Der große Vorteil ist, dass ich ohne weitere Konfigurationsänderung einen zweiten Switch anschließen könnte. Der zweite Trunk Port würde dann auch ein Bridge-Member und die gesamte Config gälte auch für diesen. In Deinem Fall wäre es nur sehr sehr umständlich möglich, das VLAN 100 auch auf dem zweiten Switch zur Verfügung zu stellen. Dafür macht die Bridge Sinn.
In meinem Fall nutze ich noch capsman für meine Accesspoints und die APs werden auch dynamisch in diese Bridge eingehängt, d.h. ich kann jede konfigurierte SSID einem separaten VLAN zuweisen.
Ohne vernünftige Anforderungsschilderung leider auch keine sinnvolle Antwort möglich.
Ich habe bisher cAP ac, wAP ac, cAP lite und wAP 60G im Einsatz. Alles je nach Anwendungsgebiet sinnvoll.
Insofern kann ich Dir leider erstmal nicht weiterhelfen. Das gesamte Wireless Sortiment kannst Du hier einsehen inklusive Abstrahldiagrammen etc:
MikroTik makes networking hardware and software, which is used in nearly all countries of the world. Our mission is to make existing Internet technologies faster, more powerful and affordable to wider range of users.
Grundsätzlich das "beste" Produkt von MikroTik hierfür ist der cAP ac. Ich hatte allerdings auch den cAP lite für mehrere Monate oder gar Jahre zur Versorgung unseres Obergeschosses dort hängen. Jedoch mit sehr idealen Voraussetzungen: hing exakt in der Mitte des offenen Treppenhauses mit offenem Rundgang und von dort aus gehen jeweils nur einzelne Zimmer weg, in denen auch nur wenig Bedarf nach Bandbreite ist. Paar Shellys (IoT Schalter etc) und abends im Bett noch bissl am Handy daddeln.
Der Cap Lite wirkt imho etwas billig, ist echt winzig und hat dementsprechend auch keine besonders dollen Antennen. Er hat bei mir getaugt, aber ich verwende ihn nur noch für einzelne Räume oder zum testen.
Wenn das Budget da ist, würde ich zum Cap ac greifen oder alternativ noch zum normalen Cap. Nachdem Du wahrscheinlich keine idealen Bedingungen hast, würde ich den Cap Lite außen vor lassen, auch wenn er sicher ginge.
Mal die preislichen Unterschiede (bei meinem bevorzugten MT Dealer Senetic):
- cAP ac: ca 62€
- cAP: ca 42€
- cAP lite: ca 26€
Den Rest musst Du Dir überlegen
Andere Modelle (wAP - für außen, mAP etc. Würde ich nicht weiter betrachten).
Entweder capsman oder direkt auf dem AP. Capsman ist etwas komplexer zu Beginn, macht aber später vieles einfacher, wenn man weitere APs hinzufügen will oder spezielle ssids in eigene vlans verfrachten.
