MikroTik – Aktueller Ist-Stand

Archivierter Stand

Diese Seite beschreibt einen früheren oder abgelösten Aufbau. Sie dient nur zur Nachvollziehbarkeit und darf nicht als aktuelle Wiederaufbauanleitung verwendet werden. Der produktive Stand steht unter Infrastruktur.

Dieses Dokument beschreibt den aktuellen Betrieb des MikroTik-Netzes. Das Zielbild steht separat in der Zielarchitektur, der Adressplan separat im IP-Plan.

Status

• Aktueller Betrieb: WLAN und alle Server/VMs/LXCs vollständig im MikroTik-Netz. WAN noch via Fritzbox (DHCP), bis der Glasfaser-ONT direkt angebunden wird.
• Proxmox, Home Assistant, alle LXCs laufen im mgmt-VLAN (10.10.10.x)
• WLAN vollständig produktiv: Alle drei CAPsMAN-Geräte aktiv und final konfiguriert (05.08.2026): ax2 (Manager) + AP Wohnzimmer (10.10.10.2)
• AP Treppenhaus (10.10.10.3). Bridge VLAN Filtering aktiv mit port-basierter VLAN-Isolation
• Router neu gestartet am 26.07.2026 (nach CAPsMAN-Umstellung hatte sich das WLAN festgehängt – Reboot hat es gelöst)
• 27.07.2026: LAN-Interface-Liste vervollständigt (vlan10/vlan20 fehlten), Dev-WLAN-Reconnect-Loop durch altes Quick-Set-Security-Profil behoben

Hardware

Modell	MikroTik hAP ax2
RouterOS	7.23.3 (stable)
Architektur	ARM64, 4 Kerne, 864 MHz
RAM	1024 MiB
Flash	128 MiB
WAN-Adresse	192.168.178.227 (DHCP von Fritzbox)
Device Mode	advanced (seit 30.07.2026, vorher home)

Device Mode

RouterOS kennt die Modi basic, home, advanced und rose. Im home-Modus sind u.a. /tool/fetch, der Scheduler und Scripting-Features eingeschränkt. Am 30.07.2026 auf advanced umgestellt – damit laufen Scheduler und fetch-basierte Scripts (z.B. Blocklist-Update) ohne Einschränkung.

Die Umstellung erfordert den Befehl /system/device-mode/update mode=advanced und muss innerhalb von 3 Minuten durch einen physischen Tastendruck am Gerät bestätigt werden (Sicherheitsmaßnahme gegen Remote-Manipulation).

Netzaufbau

Internet
    |
    v
Fritzbox 6890 LTE (192.168.178.1)
    |
    v
MikroTik hAP ax2 - ether1/WAN (192.168.178.227)
    |
    +-- bridge (192.168.88.1/24)   <- Default-Bridge, DHCP-Server deaktiviert
    +-- vlan10 (10.10.10.1/24)     <- mgmt (Proxmox, HA, LXCs, APs)
    +-- vlan20 (10.10.20.1/24)     <- home
    +-- vlan30 (10.10.30.1/24)     <- iot
    +-- vlan40 (10.10.40.1/24)     <- guest
    |
    +-- ether2 (VLAN 10 untagged, VLAN 20 tagged)
    |       |
    |       v
    |   AP Wohnzimmer (hAP ax S, 10.10.10.2)
    |       |   ether1: Uplink zum Router (pvid=10, VLAN 10 untagged) - 1G (CAT6 5m)
    |       |   ether2: Home VLAN 20 (pvid=20, untagged) <- NICHT NUTZBAR (PHY-Bug)
    |       |   ether3: Home VLAN 20 (pvid=20, untagged) <- NICHT NUTZBAR (PHY-Bug)
    |       |   ether5: mgmt VLAN 10 (pvid=10, untagged, PoE-out)
    |       |       |
    |       |       v
    |       |   AP Treppenhaus (hAP ax S, 10.10.10.3)
    |       |       ether1: Uplink zu AP Wohnzimmer (pvid=10, VLAN 10 untagged) - 1G
    |       |       ether2: Home VLAN 20 (pvid=20, untagged) <- NICHT NUTZBAR (PHY-Bug)
    |       |       ether3: Home VLAN 20 (pvid=20, untagged) <- NICHT NUTZBAR (PHY-Bug)
    |       |       ether5: mgmt VLAN 10 (pvid=10, PoE-out, für weiteren AP)
    |
    +-- ether3 (VLAN 10 untagged) -- Proxmox-Host (10.10.10.10)
    +-- ether4 (pvid=20, VLAN 20 untagged) -- waipu-tv-Box (Workaround PHY-Bug)

Hinweis ether4 am ax2: Wurde am 05.08.2026 auf pvid=20 gesetzt und der VLAN-20-Tabelle als untagged hinzugefügt, um die waipu-Box direkt am ax2 zu betreiben (Workaround für den hAP ax S PHY-Bug, siehe unten).

hAP ax S PHY-Bug auf ether2–5

Bekannter Bug: Auf den hAP ax S Geräten (AP Wohnzimmer und AP Treppenhaus) funktioniert ether1 normal, aber ether2–5 haben einen PHY-Bug, der bestimmte Frame-Typen nicht korrekt weiterleitet. Konkret: DHCP-Offers (Unicast vom Router zurück zum Client) kommen nicht am Client an, obwohl der Client- MAC in der Bridge-Host-Tabelle gelernt wird und DHCP-Discovers den Weg zum Router schaffen. Die MAC-Adresse wird also gelernt (Frames kommen an), aber der Rückweg (Router → Client) ist blockiert.

Symptome: - DHCP-Status bleibt auf offered, wird nie bound - Statische IP funktioniert ebenfalls nicht (Client nicht per Ping erreichbar) - Betrifft alle getesteten Geräte an ether2/ether3 (waipu-Box, diverse Tests)

Einziger offizieller Workaround: Port auf 10 Mbit zwingen (nicht akzeptabel).

Forum-Referenz: https://forum.mikrotik.com/t/possible-phy-issue-on-hap-ax-s-ports-2-5-require-forced-10base-t/267700

Konsequenz: Kabel-Clients können derzeit nicht über die APs angebunden werden. waipu-Box direkt an ether4 des ax2 angeschlossen. Für den Produktivbetrieb muss MikroTik diesen Bug per Firmware-Update beheben, oder die APs werden durch andere Hardware ersetzt.

WLAN / CAPsMAN

Seit Juli 2026 läuft die WLAN-Verwaltung über CAPsMAN (/interface/wifi/..., RouterOS-7-Variante, nicht die Legacy-/caps-man-Variante). Vorher waren die Radios „standalone" konfiguriert; jetzt werden sie über CAPsMAN-Configs provisioniert. Für lokale Radios auf demselben Gerät braucht es kein /interface/wifi/cap (das ist nur für externe/fremde CAPs) – stattdessen reicht /interface/wifi/radio/provision, um die lokalen Radios an die Provisioning-Regeln zu binden.

Wichtig: Einmal auf CAPsMAN provisionierte lokale Radios lassen sich nicht mehr sauber zurück in den Standalone-Modus versetzen (/interface/wifi/set verweigert mit „can not change interface created by wifi network", auch wenn CAPsMAN deaktiviert und die Provisioning-Regel deaktiviert/neu provisioniert wird – Radios landen dann in einem unkonfigurierten „SSID not set"-Zustand und lassen sich nicht mehr manuell befüllen). Diese Migration ist also praktisch ein Einwegschritt.

Aufbau

• Manager: /interface/wifi/capsman → enabled=yes
• Datapaths (/interface/wifi/datapath):
• dp-dev → bridge=bridge, vlan-id=20
• dp-iot → bridge=bridge, vlan-id=30
• dp-guest → bridge=bridge, vlan-id=40
• Security-Profile (/interface/wifi/security):
• sec-dev (Home-WLAN) – Passphrase <im Passwortmanager hinterlegt>
• sec-iot – Passphrase war Platzhalter DEIN_PASSWORT (noch zu ändern, siehe Offene Punkte)
• sec-guest – bestehendes Profil weiterverwendet
• Configurations (/interface/wifi/configuration):
• cfg-dev → ssid=DieBrocks.home, security=sec-dev, datapath=dp-dev, channel.skip-dfs-channels=10min-cac (5 GHz)
• cfg-dev-2g → ssid=DieBrocks.home, security=sec-dev, datapath=dp-dev, channel=ch-2g-20mhz (2,4 GHz, 20 MHz Kanalbreite)
• cfg-iot → ssid=IoT@DieBrocks.home, security=sec-iot, datapath=dp-iot
• cfg-guest → ssid=Gast@DieBrocks.home, security=sec-guest, datapath=dp-guest
• Provisioning (/interface/wifi/provisioning):
• 5-GHz-Radios: master-configuration=cfg-dev, slave-configurations=cfg-iot,cfg-guest
• 2,4-GHz-Radios: master-configuration=cfg-dev-2g, slave-configurations=cfg-iot,cfg-guest
• Radios lokal provisioniert via /interface/wifi/radio/provision numbers=0,1; CAPs registrieren sich automatisch und übernehmen dieselben Configs

Hinweis zu den internen Namen: cfg-dev, sec-dev, dp-dev sind RouterOS-Objektnamen aus der Planungsphase. Die produktive SSID heißt bereits DieBrocks.home. Eine Umbenennung der Objekte ist technisch nicht nötig, kann aber später kosmetisch nachgeholt werden (dann alle Referenzen gemeinsam).

Ergebnis

wifi1/wifi2 (auf dem ax2 selbst) sind CAPsMAN-verwaltete Master-Interfaces (Home, VLAN 20). Die IoT- und Gast-SSIDs laufen als dynamische virtuelle Interfaces. Die Bridge-VLAN-Tabelle referenziert die Radios über interne IDs (nicht über Namen), bleibt also von Umbenennungen unberührt.

Hinweis DFS-Kanal: Nach dem Provisionieren macht der Radio auf 5-GHz- DFS-Kanälen automatisch einen ca. 1-minütigen Channel-Availability-Check (Radarerkennung), bevor er wieder sendet. Kurze Inaktivität danach ist normal, kein Fehler.

Instabilität Dev-WLAN (behoben, 27.07.2026)

Nach der CAPsMAN-Umstellung verband sich DieBrocks.home zwar, trennte aber im Sekundentakt wieder. Ursache war das Security-Profil Quick Set (vom RouterOS-Einrichtungsassistenten für ein spezifisches Gerät automatisch angelegt). Fix: neues Profil sec-dev manuell angelegt, cfg-dev darauf umgestellt, Radios neu provisioniert. Seitdem stabil.

Drei CAPsMAN-Geräte im Verbund (01.08.2026)

AP Wohnzimmer (hAP ax S, 10.10.10.2): - Per Kabel an ether2 (mgmt-VLAN) am ax2, automatisch DHCP → feste Lease - mcp-User/mcp-server-Gruppe angelegt, SSH-Key importiert - CAP-Modus per Reset-Button-Methode aktiviert (gedrückt halten bis LED von Blinken auf Dauerleuchten wechselt) - RouterOS 7.23.3 (stable) - Bridge VLAN Filtering aktiv seit 05.08.2026 (siehe Abschnitt unten) - LED-Einstellung: all-leds-off=after-1min (seit 07.08.2026) - ether2–5 nicht nutzbar für Kabel-Clients (PHY-Bug, siehe oben)

AP Treppenhaus (hAP ax S, 10.10.10.3): - Per PoE-out von AP Wohnzimmer ether5 versorgt (Strom + Uplink in einem) - Gleicher Setup-Ablauf wie AP Wohnzimmer (User/Gruppe/Key manuell, CAP-Modus per Reset-Button) - Bridge VLAN Filtering aktiv seit 05.08.2026 (identische Konfiguration wie AP Wohnzimmer) - RouterOS 7.23.3 (stable) - LED-Einstellung: all-leds-off=after-1min (seit 07.08.2026) - ether2–5 nicht nutzbar für Kabel-Clients (PHY-Bug, siehe oben) - Wichtig für die finale Montage: An den echten Standorten bekommt jeder AP seine eigene Stromversorgung (Wohnzimmer lokal, Treppenhaus per RBGPOE-Injektor vom HWR). Die PoE-Kaskade ist dann nicht mehr nötig – sonst hängt die Treppenhaus-Verfügbarkeit am Wohnzimmer-AP.

Ergebnis: Alle drei Geräte (Manager + 2 CAPs) senden alle drei SSIDs (DieBrocks.home, IoT@DieBrocks.home, Gast@DieBrocks.home) auf allen Radios, alle als BR (Bound + Running) bestätigt.

AP Bridge VLAN Konfiguration (05.08.2026)

Beide APs (AP Wohnzimmer und AP Treppenhaus) sind als transparente Layer-2- Bridges konfiguriert, mit aktivem Bridge VLAN Filtering für port-basierte VLAN-Isolation. Die Konfiguration ist auf beiden Geräten identisch.

Konzept: mgmt-Interface

Das Kernproblem beim Aktivieren von VLAN Filtering auf einem AP: bridgeLocal (der CPU/Management-Port der Bridge) hat standardmäßig pvid=1, d.h. der CPU-Traffic landet in VLAN 1. Wenn der Uplink-Port (ether1) aber nur in VLAN 10 (mgmt) ist, kommen DHCP-Discovers der CPU nie beim Router an.

Lösung: Ein dediziertes mgmt-VLAN-Interface als Subinterface auf bridgeLocal (vlan-id=10). Dieses Interface sendet tagged VLAN-10-Frames an bridgeLocal. Die Bridge leitet sie via ether1 weiter – ether1 ist untagged in VLAN 10, d.h. das Tag wird beim Egress entfernt. Der Router empfängt einen ungetaggten Frame auf ether2 (pvid=10) und ordnet ihn korrekt VLAN 10 zu. DHCP-Offer kommt denselben Weg zurück, mgmt bekommt die IP.

VLAN-Tabelle (identisch auf beiden APs)

VLAN	Tagged	Untagged	Zweck
10	bridgeLocal	ether1, ether5	mgmt (Uplink + PoE-Downlink)
20	ether1	ether2, ether3	Home-Geräte (wegen PHY-Bug derzeit nicht nutzbar)

Bridge-Port pvids

Port	pvid	Zweck
ether1	10	Uplink zum Router / übergeordnetem AP
ether2	20	Home-Geräte (PHY-Bug: DHCP-Offers kommen nicht durch)
ether3	20	Home-Geräte (PHY-Bug: DHCP-Offers kommen nicht durch)
ether4	1	nicht genutzt (Default)
ether5	10	PoE-out für nachgelagerten AP oder mgmt-Gerät

Interfaces auf jedem AP

/interface/vlan add interface=bridgeLocal vlan-id=10 name=mgmt
/ip/dhcp-client/set [find] interface=mgmt
/interface/bridge/set bridgeLocal vlan-filtering=yes

Der DHCP-Client läuft auf mgmt, nicht auf bridgeLocal. Die IP-Adresse des APs liegt damit auf dem mgmt-Interface:

AP	mgmt-IP
AP Wohnzimmer	10.10.10.2/24
AP Treppenhaus	10.10.10.3/24

Konfigurationsbefehle (Referenz, für neuen AP anwendbar)

# 1. VLAN-Tabelle setzen
/interface/bridge/vlan/add bridge=bridgeLocal vlan-ids=10 tagged=bridgeLocal untagged=ether1,ether5
/interface/bridge/vlan/add bridge=bridgeLocal vlan-ids=20 tagged=ether1 untagged=ether2,ether3

# 2. pvids setzen
/interface/bridge/port/set [find interface=ether1] pvid=10
/interface/bridge/port/set [find interface=ether2] pvid=20
/interface/bridge/port/set [find interface=ether3] pvid=20
/interface/bridge/port/set [find interface=ether5] pvid=10 comment="downstream AP/Gerät (PoE)"

# 3. mgmt-Subinterface anlegen
/interface/vlan add interface=bridgeLocal vlan-id=10 name=mgmt

# 4. DHCP-Client auf mgmt umziehen
/ip/dhcp-client/set [find] interface=mgmt

# 5. VLAN Filtering aktivieren (letzter Schritt!)
/interface/bridge/set bridgeLocal vlan-filtering=yes

Wichtig: Schritt 5 immer als letztes! Sobald vlan-filtering=yes gesetzt wird, filtert die Bridge VLAN-strikt. Wenn der DHCP-Client zu diesem Zeitpunkt noch auf bridgeLocal läuft (pvid=1), verliert der AP seine mgmt-IP sofort. Reihenfolge 1–5 einhalten, und die Befehle in einer SSH-Session als Block abschicken.

Interfaces

Bridge

• Name: bridge
• VLAN-Filtering: aktiviert
• PVID: 1
• Ports: ether2, ether3, ether4, ether5, wifi1, wifi2 sowie die dynamischen WLAN-Interfaces

Interface-Listen

Liste	Mitglieder
LAN	bridge, vlan30 (defconf/ursprüngliches Setup), vlan10, vlan20 (am 27.07.2026 ergänzt)
WAN	ether1

Wichtig: vlan10 und vlan20 fehlten ursprünglich in der LAN-Liste. Die Input-Chain-Regel „drop all not coming from LAN" (Regel 8) hat dadurch jede neue Verbindung von mgmt- und Home/Dev-VLAN zum Router selbst verworfen. vlan40 (Gast) ist bewusst nicht in der LAN-Liste.

VLANs

Interface	VLAN-ID	IP	Zweck
vlan10	10	10.10.10.1/24	mgmt
vlan20	20	10.10.20.1/24	home
vlan30	30	10.10.30.1/24	iot
vlan40	40	10.10.40.1/24	guest

WLAN

Interface	Master	SSID	VLAN	Konfiguration	Status
wifi1 (5 GHz)	–	DieBrocks.home	20	cfg-dev	aktiv
wifi2 (2,4 GHz)	–	DieBrocks.home	20	cfg-dev-2g	aktiv
wifi1-virtual1	wifi1	IoT@DieBrocks.home	30	cfg-iot	aktiv
wifi2-virtual1	wifi2	IoT@DieBrocks.home	30	cfg-iot	aktiv
wifi1-virtual2	wifi1	Gast@DieBrocks.home	40	cfg-guest	aktiv
wifi2-virtual2	wifi2	Gast@DieBrocks.home	40	cfg-guest	aktiv

DHCP

Server und Pools

Server	Interface	Pool	Lease-Time	Status
defconf	bridge	192.168.88.10–.254	30 min	deaktiviert
dhcp-mgmt	vlan10	10.10.10.50–.199	1 h	aktiv
dhcp-home	vlan20	10.10.20.100–.199	30 min	aktiv
dhcp-iot	vlan30	10.10.30.150–.199	30 min	aktiv
dhcp-guest	vlan40	10.10.40.50–.199	1 h	aktiv

DNS für alle VLANs: Router selbst (.1), Weiterleitung an 1.1.1.1 und 8.8.8.8.

Reservierungen

Die statischen Reservierungen mit MAC-Adressen stehen im IP-Adressplan.

Firewall

Input-Chain

#	Regel	Zweck
1	accept TCP src 10.10.10.0/24 dst-port 22	SSH aus mgmt-VLAN (inkl. MCP-Server 10.10.10.33)
2	accept established, related, untracked	Bestehende Verbindungen
3	drop invalid	Ungültige Pakete
4	drop src blocklist	Blocklist eingehend
5	accept ICMP	Ping
6	accept dst 127.0.0.1	Loopback (CAPsMAN)
7	accept TCP src 192.168.178.16 dst-port 80	WebFig via Cloudflare Tunnel ⚠️ alte IP, noch nicht auf 10.10.10.30 aktualisiert
8	drop in-interface-list != LAN	Alles andere von WAN verwerfen

Forward-Chain

#	Regel	Zweck
9	drop in vlan30 dst 10.0.0.0/8	IoT → interne Netze blockieren
10	blocklist: drop forward to C2	dst-address-list=blocklist
11	blocklist: drop forward from bad IP	src-address-list=blocklist
12	drop src 10.10.40.0/24 dst 10.0.0.0/8	Guest → interne Netze blockieren
13	drop in vlan30 dst 192.168.88.0/24	IoT → LAN-Bridge blockieren
14	drop src 10.10.40.0/24 dst 192.168.88.0/24	Guest → LAN-Bridge blockieren
15	accept ipsec policy in	IPsec eingehend
16	accept ipsec policy out	IPsec ausgehend
17	fasttrack established, related	Fasttrack
18	accept established, related, untracked	Bestehende Verbindungen
19	drop invalid	Ungültige Pakete
20	accept TCP src 10.10.10.33 dst 10.10.10.0/24 dst-port 22	MCP-Server SSH zu mgmt-VLAN
21	accept in vlan20 out ether1	Home → Internet erlauben
22	accept in vlan30 out ether1	IoT → Internet erlauben
23	accept in vlan40 out ether1	Gast → Internet erlauben
24	drop WAN new nicht-DSTNATed	WAN-Anfragen ohne DNAT verwerfen

NAT

• srcnat masquerade auf WAN (out-interface-list=WAN)

Address Lists (Blocklist)

Seit 30.07.2026 pflegt der Router eine dynamische Blockliste (blocklist) aus Feodo Tracker (~4100 Einträge, Botnet-C2) und Spamhaus DROP (~1666 Einträge), täglich um 03:00 Uhr aktualisiert. Nutzt DoH-abhängiges Fetching, fällt bei DoH-Ausfall auf den letzten bekannten Stand zurück.

DNS

Statische Server	1.1.1.1, 8.8.8.8
Dynamisch vom Fritzbox-Netz	192.168.178.1
Allow Remote Requests	ja
DoH	https://1.1.1.1/dns-query (Cloudflare)
DoH Zertifikat-Prüfung	verify-doh-cert=no (RouterOS-Bug-Workaround)

NTP

Modus	NTP-Client
Server	ptbtime1-3.ptb.de (Stratum 1, PTB Braunschweig)

UPnP

Status	aktiv, nur auf vlan20 (Home)

Dienste

Dienst	Port	Einschränkung	Status
SSH	22	nur 10.10.10.0/24	aktiv
FTP	21	–	deaktiviert
Telnet	23	–	deaktiviert
WebFig (HTTP)	80	10.10.10.0/24, 10.10.20.0/24, 192.168.178.0/24	aktiv
WWW-SSL	443	10.10.10.0/24, 10.10.20.0/24, 192.168.178.0/24	aktiv
Winbox	8291	10.10.10.0/24, 10.10.20.0/24, 192.168.178.0/24	aktiv
API	8728	10.10.10.0/24, 10.10.20.0/24, 192.168.178.0/24	aktiv
API-SSL	8729	10.10.10.0/24, 10.10.20.0/24, 192.168.178.0/24	aktiv

SSH-Zugang

Der MCP-Server hat die IP 10.10.10.33 (VLAN 10, mgmt) und SSH-Zugriff via Public Key auf allen drei Geräten:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINnnNM/CO8hnCH5W8M1dp6aPN4LrgREeRexpM72utlf9 mcp-remote

• ax2: hinterlegt für User mcp
• AP Wohnzimmer / AP Treppenhaus: eigene mcp-User in eigens angelegter mcp-server-Gruppe (Policy: local,ssh,read,write,test,winbox,web,sniff, sensitive,api,rest-api,!telnet,!ftp,!reboot,!policy,!password,!romon)

SSH-Verbindung vom MCP-Server:

ssh -i ~/.ssh/id_ed25519 mcp@10.10.10.1   # ax2 (Router)
ssh -i ~/.ssh/id_ed25519 mcp@10.10.10.2   # AP Wohnzimmer
ssh -i ~/.ssh/id_ed25519 mcp@10.10.10.3   # AP Treppenhaus

Offene Punkte

• hAP ax S PHY-Bug: MikroTik-Forum verfolgen, auf Firmware-Fix warten. Bis dahin: keine Kabel-Clients an den APs möglich. waipu-Box bleibt direkt an ether4 des ax2.
• APs an finale Standorte montieren – aktuell noch provisorisch. AP Treppenhaus danach auf eigene Stromversorgung umstellen (RBGPOE-Injektor im HWR)
• Firewall Input-Regel 7: Cloudflare-LXC ist jetzt auf 10.10.10.30 – Regel noch auf alter IP 192.168.178.16 → auf 10.10.10.30 korrigieren
• Abschließende Drop-All-Regel am Ende der Forward-Chain ergänzen
• Firewall-Regel für IoT → Home Assistant (10.10.10.20) explizit erlauben
• IoT-WLAN-Passphrase (sec-iot) von Platzhalter DEIN_PASSWORT ändern
• Admin-Inactivity-Timeout manuell auf 1 h setzen
• DoH verify-doh-cert=yes wieder aktivieren, sobald RouterOS den Bug behebt
• WAN-Uplink auf ONT umstellen (Glasfaser), Fritzbox ablösen
• S2S-VPN MikroTik ↔ SonicWall TZ670 für Dienst-Laptop einrichten

Verweise

• Zielarchitektur
• Umstellung und Migrationsplan
• IP-Adressplan