- Bridge VLAN Filtering ist der bevorzugte Weg für VLAN-Konfiguration. Auch auf CRS100/200 Series, dann jedoch kein Hardware Offloading.
- VLAN Interface: Use Service Tag nur für Q-in-Q (IEEE 802.1ad) relevant
- Bridge mit PVID: Frame Types auf „admit only VLAN tagged“
- Hinweis: Bridge auch unter Bridge VLAN in „Tagged“ aufnehmen
- Ingress Filtering: Bei Nutzung von Bridge VLAN Filtering immer aktivieren (in Kombination mit frame-types). Aktivieren auf: Bridge und Bridge Ports!
- MSTP an Stelle von RSTP verwenden!
- Hinweis: MSTP benötigt Bridge VLAN Filtering!
- Bei Bridges immer Admin. MAC Address setzen!
Schlagwort: mikrotik
MikroTik Hardware Offloading
Bei aktivem HW-Offloading:
- Bridge Filter greifen nicht
- Hinweis zu Bridge VLAN Filtering: HW-Offloading abhängig vom Switch Chip
- IP Firewall Rules greifen nicht
- Queuing ist inaktiv
- Workaround: Nutzung von Switch -> Port -> Ingress Rate / Egress Rate zur Limitierung der Datenraten
- Tools (Torch, Sniffer o.ä.) zeigen nur Traffic, der durch CPU processed wird
Features, welche HW-Offloading selbständig deaktivieren:
- Split Horizon
- (… ?)
Features, welche HW-Offloading benötigen:
- Switch Port Isolation: Forwarding Override
- (… ?)
Weitere Informationen:
- Switch Chip Features
- Bridge Hardware Offloading
- Kursunterlagen zu MTCSWE
WinBox Session & Config Folder
Wo befinden sich Session- und Konfigurationsdateien von WinBox unter macOS?
Bei manueller Installation von Wine und WinBox:
/Users/$Username/.wine/drive_c/users/$Username/Application Data/Mikrotik/Winbox
Bei nrlquaker-winbox (Brew / Cask):
/Users/$Username/Library/Application Support/com.mikrotik.winbox
RouterOS 7: OSPF Redistribute Connected Routes
/routing/filter/rule/add chain=ospf-redist rule={if [protocol connected] then={action do=accept}
/routing/ospf/instance/set default out-filter-chain=ospf-redistZudem Bug bei IP-Addresses vermutet (RouterOS 7.0.2): Erst das Ändern der IP-Adresse auf der VPN-Bridge (/24 entfernen und wieder hinzufügen) hat ein korrektes Routing über die VPN-Bridge ergeben.
Quellen:
MikroTik: CAPsMAN und CAP auf einem Device
Wenn ein MikroTik-Device als CAPsMAN fungiert und gleichzeitig die internen WLAN-Interfaces im CAP-Mode betrieben werden sollen, so muss bei den CAP-Einstellungen unter „CAPsMAN Addresses“ die lokale IP des CAPsMAN eingetragen werden.
Ansonsten ist eine Verbindung zwischen CAPsMAN und CAP nicht möglich, so dass die CAP WLAN-Interfaces nicht durch den CAPsMAN verwaltet werden.
Zudem ist eine Firewall-Freigabe in der Input-Chain erforderlich, die den Zugriff der lokalen CAPsMAN-IP auf sich selbst (Loopback) gestattet.
Hinweis zu CAPsMAN 2
Lokale Access Points werden von CAPsMAN in der neuen Version 2 nicht mehr unterstützt! (Quelle)
New capsman explicitly doesn’t support provisioning local devices (MT is very clear on that).
MikroTik: EoIP Abbrüche
Bei regelmäßigen Reconnects (teilw. mehrmals pro Minute) von EoIP-Tunneln: Keepalive bei beiden Tunnel-Endpunkten deaktivieren.
Das Problem tritt insbes. bei RouterOS Version 7 (bspw. 7.0.2) auf.
Debugging Hints (Open)VPN
- IP-Konflikt zw. lokal und remote genutzten IP-Subnetzen?
- Firewall auf Server aktiv?
- Firewall auf Client aktiv?
- Routen auf Server korrekt?
- für VPN konfigurierte Server- und Client-IP korrekt?
- VPN einer Bridge zugeordnet?
- bei OpenVPN: Client-Config fehlerhaft?