Mikrotik filtert IPv6 RAs
Hallo,
ich spiele gerade mit einem Mikrotik RB5009 rum, ich hab mir jetzt mal soweit eine Config fürs VLAN Briding gebaut. Mein Uplink kommt über den sfp-sfpplus1 als LWL rein.
Wenn ich jetzt mein Testgerät an den ether1 hänge bekommt dieses eine IPv4 vom DHCP aber keine IPv6 RAs. Diese gehen im Mikrotik verloren, den wenn ich mein Testgerät direkt auf die LWL hänge bekomme ich IPv6 RAs.
Was hab ich auf dem Mikrotik vergessen?
Hier meine Config.
ich spiele gerade mit einem Mikrotik RB5009 rum, ich hab mir jetzt mal soweit eine Config fürs VLAN Briding gebaut. Mein Uplink kommt über den sfp-sfpplus1 als LWL rein.
Wenn ich jetzt mein Testgerät an den ether1 hänge bekommt dieses eine IPv4 vom DHCP aber keine IPv6 RAs. Diese gehen im Mikrotik verloren, den wenn ich mein Testgerät direkt auf die LWL hänge bekomme ich IPv6 RAs.
Was hab ich auf dem Mikrotik vergessen?
Hier meine Config.
# 1970-01-02 00:32:13 by RouterOS 7.10
# software id = 0943-3PVF
#
# model = RB5009UG+S+
# serial number = XXXXXXXXXXX
/interface bridge
add frame-types=admit-only-vlan-tagged name=bridge1 vlan-filtering=yes
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether1 pvid=488
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=488
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=488
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=488
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=488
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether6 pvid=488
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=ether7 pvid=488
add bridge=bridge1 edge=yes interface=sfp-sfpplus1 pvid=488
/ip neighbor discovery-settings
set discover-interface-list=all
/interface bridge vlan
add bridge=bridge1 tagged=sfp-sfpplus1 vlan-ids=192
add bridge=bridge1 tagged=sfp-sfpplus1 vlan-ids=202
add bridge=bridge1 tagged=sfp-sfpplus1 vlan-ids=686
add bridge=bridge1 untagged=sfp-sfpplus1 vlan-ids=488
/system identity
set name=XXXXXXXXXXXXXXX
/system note
set show-at-login=no
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7591319590
Url: https://administrator.de/contentid/7591319590
Ausgedruckt am: 05.11.2024 um 16:11 Uhr
10 Kommentare
Neuester Kommentar
Moin.
Kann ich nicht bestätigen, habe das hier so mal im Test mit der Config aufgebaut. IPv6 wird unverändert weitergeleitet. Der Mikrotik kann hier nichts filtern hier wird ja rein nur geswitcht, und es geht nichts zur CPU, fürs Filtern müsste der Traffic über die CPU laufen, ist hier aber nicht der Fall. Beim reinen switchen kann IPv6 auf dem Router sogar deaktiviert werden, er wird trotzdem sämtliche Pakete weiterleiten da rein nur transparent geswitcht wird. Also mal einen kompletten Reset ohne Defaults zu laden bei dem Device machen! Oder clean Netinstallen um evt. Überreste zu beseitigen.
Übrigens ist diese Anweisung obsolet weil der SFP+ Port über die PVID schon untagged member ist, schaden tut sie aber nicht:
Zeppel
Kann ich nicht bestätigen, habe das hier so mal im Test mit der Config aufgebaut. IPv6 wird unverändert weitergeleitet. Der Mikrotik kann hier nichts filtern hier wird ja rein nur geswitcht, und es geht nichts zur CPU, fürs Filtern müsste der Traffic über die CPU laufen, ist hier aber nicht der Fall. Beim reinen switchen kann IPv6 auf dem Router sogar deaktiviert werden, er wird trotzdem sämtliche Pakete weiterleiten da rein nur transparent geswitcht wird. Also mal einen kompletten Reset ohne Defaults zu laden bei dem Device machen! Oder clean Netinstallen um evt. Überreste zu beseitigen.
Übrigens ist diese Anweisung obsolet weil der SFP+ Port über die PVID schon untagged member ist, schaden tut sie aber nicht:
/interface bridge vlan
add bridge=bridge1 untagged=sfp-sfpplus1 vlan-ids=488
Da RA Multicast ist, wird er nur an Ports weitergeleitet, die sich in der entsprechenden Multicast-Gruppe befinden. Ich weiß nicht, wie Mikrotik per Default mit unbekannten Gruppen arbeitet, aber eventuell hat es mit dem Multicast-Handling zu tun.
Stichwörter wären MLD bei IPv6 bzw. IGMP so allgemein, ich habe leider mit Mikrotik so nie zu tun, deshalb kann ich da nichts genaueres zu sagen...
Stichwörter wären MLD bei IPv6 bzw. IGMP so allgemein, ich habe leider mit Mikrotik so nie zu tun, deshalb kann ich da nichts genaueres zu sagen...
Zitat von @LordGurke:
Da RA Multicast ist, wird er nur an Ports weitergeleitet, die sich in der entsprechenden Multicast-Gruppe befinden. Ich weiß nicht, wie Mikrotik per Default mit unbekannten Gruppen arbeitet, aber eventuell hat es mit dem Multicast-Handling zu tun.
Stichwörter wären MLD bei IPv6 bzw. IGMP so allgemein, ich habe leider mit Mikrotik so nie zu tun, deshalb kann ich da nichts genaueres zu sagen...
Wenn der Router selbst am RA beteiligt wäre oder als Router arbeiten würde ja da lässt sich das im ND festlegen, seine Config ist aber in dem Falll reines Switching ohne jegliche getaggte VLANs auf die Bridge und somit die CPU, und dabei kann er mit der Config nichts filtern. IPv6 selbst kann dabei am Router deaktiviert sein das würde in dem Fall beim Mik. auch nicht stören.Da RA Multicast ist, wird er nur an Ports weitergeleitet, die sich in der entsprechenden Multicast-Gruppe befinden. Ich weiß nicht, wie Mikrotik per Default mit unbekannten Gruppen arbeitet, aber eventuell hat es mit dem Multicast-Handling zu tun.
Stichwörter wären MLD bei IPv6 bzw. IGMP so allgemein, ich habe leider mit Mikrotik so nie zu tun, deshalb kann ich da nichts genaueres zu sagen...
Entweder ein Bug den ich hier sowohl mit der RC als mit der Stable nicht nachvollziehen kann, oder den hats intern irgendwie zerlegt ich würde dann mal ein Netinstall empfehlen um wirklich alle evt. Altlasten loszuwerden
Multicast ist reines Switching?
In der Config taucht zwar nichts auf, was so aussieht als wenn Multicast konfiguriert wird, aber das heißt nicht zwingend, dass ein Switch kein Multicast-Handling macht.
Es könnte allerdings auch sein, dass am per SFP verbundenen Switch kein MLD-Join gesehen wurde und er deswegen nichts forwarded. Das wäre etwas, was man leicht prüfen könnte, indem der Client mal für ein paar Sekunden ausgesteckt und wieder angeschlossen wird, dann sollte der Join ja komplett durchschlagen.
In der Config taucht zwar nichts auf, was so aussieht als wenn Multicast konfiguriert wird, aber das heißt nicht zwingend, dass ein Switch kein Multicast-Handling macht.
Es könnte allerdings auch sein, dass am per SFP verbundenen Switch kein MLD-Join gesehen wurde und er deswegen nichts forwarded. Das wäre etwas, was man leicht prüfen könnte, indem der Client mal für ein paar Sekunden ausgesteckt und wieder angeschlossen wird, dann sollte der Join ja komplett durchschlagen.
Ja, aber in dem Fall kann er hier nichts filtern da durch die Config keines der VLANs getagged auf den bridge-Port geführt wird und somit die CPU von dem Traffic nichts mitbekommt.
Des weiteren fehlen in der Config jegliche Switch-Anweisungen für den Switch-Chip mit irgendwelchen ACLs die verhindern könnten das die MC Pakete durchgeleitet werden. Wenn das wirklich die komplette Config ist die er uns hier gepostet hat und nicht nur ein Ausschnitt.
Vermute auch das es an dem Uplink angeschlossenen Switch liegt und nicht am Mikrotik.
Des weiteren fehlen in der Config jegliche Switch-Anweisungen für den Switch-Chip mit irgendwelchen ACLs die verhindern könnten das die MC Pakete durchgeleitet werden. Wenn das wirklich die komplette Config ist die er uns hier gepostet hat und nicht nur ein Ausschnitt.
Vermute auch das es an dem Uplink angeschlossenen Switch liegt und nicht am Mikrotik.
Ich rede auch nicht von Filtern im Sinne klassischer ACLs sondern davon, dass man bei Multicast als Client einem Switch per IGMP bzw. MLD mitteilen muss, aus welchen Multicast-Gruppen man Traffic empfangen möchte. Und nur diese Gruppen leitet der Switch dann weiter.
Das ist Standardverhalten auf jedem halbwegs besseren Switch. Ob Mikrotik dafür ein CPU-Interface braucht oder das in der Hardware passiert, weiß ich nicht.
Jedenfalls könnte dann, wenn du mehrere Switches kaskadierst, eine spezielle Config notwendig sein um diese "Uplink-Ports" von Multicast-Filterung auszunehmen — das dann aber auf beiden Switches.
Das ist Standardverhalten auf jedem halbwegs besseren Switch. Ob Mikrotik dafür ein CPU-Interface braucht oder das in der Hardware passiert, weiß ich nicht.
Jedenfalls könnte dann, wenn du mehrere Switches kaskadierst, eine spezielle Config notwendig sein um diese "Uplink-Ports" von Multicast-Filterung auszunehmen — das dann aber auf beiden Switches.
Das ist in erster Linie auch ein Router der auch switchen kann .
So lange auf dem Mikrotik nicht die Einstellung "UseIPFirewall = yes" auf der Bridge gesetzt ist interessiert ihn der Traffic zwischen Ports im selben VLAN nicht und schaltet alles auf Durchzug.
Naja mal abwarten was der TO zum Uplink Switch sagen kann.
Ob Mikrotik dafür ein CPU-Interface braucht oder das in der Hardware passiert, weiß ich nicht.
Es geht dort beides, wenn Firewall-Regeln beteiligt sind ist zwingend die CPU, in der Switch-Config selbst nur basic ACLs keine MultiCast spezifischen Einstellungen.So lange auf dem Mikrotik nicht die Einstellung "UseIPFirewall = yes" auf der Bridge gesetzt ist interessiert ihn der Traffic zwischen Ports im selben VLAN nicht und schaltet alles auf Durchzug.
Naja mal abwarten was der TO zum Uplink Switch sagen kann.
Bitte dann auch Wie kann ich einen Beitrag als gelöst markieren? nicht vergessen!