Cisco-Router für Segmentierung: VRF Lite und Multi-Tenant-Design

VRF Lite auf Cisco-Routern ist ein bewährtes Segmentierungs- und Multi-Tenant-Design, wenn Sie Routing-Tabellen strikt trennen müssen: unterschiedliche Mandanten, getrennte Sicherheitszonen (Prod/Dev), Partnernetze oder isolierte Betriebsnetze (OT/IoT/MGMT). Im Gegensatz zu VLAN-Segmentierung mit ACLs schafft VRF Lite eine harte Trennung auf Layer 3: Jede VRF hat ihre eigene Routing-Tabelle, eigene Default-Routen und eigene Policies. Das reduziert Blast Radius, verhindert ungewollte Route-Leaks und macht Governance leichter. Dieser Leitfaden zeigt Designprinzipien, typische Muster und ein praxisnahes VRF-Lite-Konfigurationsgerüst.

VRF Lite: Was es ist und was es nicht ist

VRF Lite bedeutet: mehrere getrennte Routing-Instanzen auf einem Gerät – ohne MPLS-Core. Es ist ideal für Edge- und Aggregationsrouter, wenn Mandanten/Segmente logisch getrennt, aber auf derselben Hardware betrieben werden.

• VRF = separate Routing-Tabelle pro Mandant/Zone
• VRF Lite = VRF ohne MPLS-Provider-Core
• VLAN + ACL = Segmentierung innerhalb einer Routing-Tabelle (weicher)
• VRF Lite = harte Trennung, Inter-VRF nur kontrolliert über definierte Kopplung

Wann VRF Lite sinnvoll ist (Enterprise-Use-Cases)

VRF Lite ist sinnvoll, wenn Sie nicht nur „Traffic blocken“, sondern Routing-Domänen wirklich trennen müssen. Das ist typisch bei Multi-Tenant- oder Compliance-Anforderungen.

• Mandantenfähigkeit: Kunde A und Kunde B auf gemeinsamer Infrastruktur
• Partnernetze: B2B-Zugänge getrennt von internen Netzen
• Security-Zonen: Prod vs. Dev/Test, getrennte Defaults
• OT/IoT/MGMT: Betriebsnetze strikt separiert (geringer Trust)
• Hybrid-Cloud: getrennte VRFs für Cloud-Connectivity vs. Corporate

Designprinzipien: VRF als „Policy Boundary“

Die größte Stärke von VRF Lite ist Governance: Jede VRF hat eigene Defaults, eigene Routing-Policies und eigene Monitoring-Objekte. Definieren Sie VRFs daher bewusst als Policy Boundaries.

• Eigene Default-Route pro VRF (kein „global default“)
• Separates Routing pro VRF (Static/OSPF/BGP je nach Bedarf)
• Eigene NAT-Policy pro VRF (wenn Internetzugang nötig ist)
• Eigene Logging/Monitoring-Sicht (VRF-spezifische KPIs)

IP-Planung: Overlaps möglich, aber governance-intensiv

VRFs erlauben überlappende RFC1918-Netze zwischen Mandanten. Das ist ein Vorteil bei Multi-Tenant, aber erhöht die Komplexität bei Inter-VRF-Services (z. B. Shared DNS). Planen Sie Overlaps nur, wenn notwendig.

• Ohne Overlaps: einfacher Betrieb, weniger Ausnahmefälle
• Mit Overlaps: klare Tenant-IDs, disziplinierte Dokumentation
• Shared Services: bevorzugt in eigener VRF (z. B. VRF-SHARED)

Basis-Konfiguration: VRFs anlegen und Interfaces zuordnen

Die Grundkonfiguration besteht aus VRF-Definitionen und der Zuordnung von Interfaces/Subinterfaces. Wichtig: Die VRF-Zuordnung erfolgt pro Interface und muss konsistent dokumentiert sein.

CLI: VRFs definieren (Muster)

vrf definition VRF-TENANT-A
 rd 65010:10
 !
 address-family ipv4
 exit-address-family
vrf definition VRF-TENANT-B

rd 65010:20

!

address-family ipv4

exit-address-family

CLI: Interfaces in VRF legen (Beispiel)

interface GigabitEthernet0/1.10
 description TENANT-A-LAN
 encapsulation dot1Q 10
 vrf forwarding VRF-TENANT-A
 ip address 10.10.10.1 255.255.255.0
interface GigabitEthernet0/1.20

description TENANT-B-LAN

encapsulation dot1Q 20

vrf forwarding VRF-TENANT-B

ip address 10.20.20.1 255.255.255.0

Routing pro VRF: Static als Startpunkt, BGP/OSPF für Skalierung

Jede VRF braucht ihr eigenes Routing. Für kleine Mandanten reichen statische Routen. Für größere Umgebungen sind OSPF/BGP pro VRF üblich, um Skalierung und Failover besser zu steuern.

• Static: übersichtlich, aber driftanfällig bei Wachstum
• OSPF pro VRF: gut für interne Domänen mit klaren Areas
• BGP pro VRF: policy-stark, sinnvoll bei Multi-Tenant und komplexen Kopplungen

CLI: Default-Route pro VRF (Beispiel)

ip route vrf VRF-TENANT-A 0.0.0.0 0.0.0.0 10.10.10.254
ip route vrf VRF-TENANT-B 0.0.0.0 0.0.0.0 10.20.20.254

CLI: Routing-Verifikation pro VRF

show ip route vrf VRF-TENANT-A
show ip route vrf VRF-TENANT-B

Inter-VRF-Connectivity: Nur bewusst und minimal

Der häufigste Designfehler ist „VRFs erstellen und dann alles wieder verbinden“. Inter-VRF sollte nur über definierte Dienste erfolgen, typischerweise über eine Firewall oder kontrollierte Route-Leaks (wenn wirklich nötig).

• Best Practice: Inter-VRF über Firewall (Zonen/Policies, stateful)
• Ausnahme: Route-Leaking (kontrolliert, minimal, auditierbar)
• Shared Services: eigene VRF, Zugriff nur per Allow-List

NAT pro VRF: Internetzugang mandantensicher machen

Wenn Mandanten Internetzugang benötigen, muss NAT pro VRF klar geregelt sein. Der NAT-Owner (Router vs. Firewall) muss eindeutig sein, sonst entsteht Doppel-NAT und Troubleshooting wird schwierig.

• NAT-Whitelist pro VRF: nur erlaubte Subnetze
• No-NAT für VPN/Inter-Site in der jeweiligen VRF
• Logging: policy-relevante Events, keine Logflut

Security-Governance: Management Plane und RBAC bei Multi-Tenant

Multi-Tenant erhöht Sicherheitsanforderungen: Managementzugriff darf nie aus Tenant-VRFs erfolgen. Nutzen Sie ein dediziertes MGMT-Netz (eigene VRF) und AAA/RBAC, damit Adminaktionen auditierbar sind.

• Eigene VRF-MGMT (oder physisch getrennt) für Adminzugriff
• SSH-only, VTY Access-Class nur MGMT
• AAA/Accounting: Exec und Commands für Audit Trail
• CoPP: wenn Router exponiert ist oder viele Tenants Noise erzeugen

CLI: Managementzugriff restriktiv (Auszug)

ip access-list standard MGMT_ONLY
 permit 10.10.10.0 0.0.0.255
 deny any
line vty 0 4

transport input ssh

access-class MGMT_ONLY in

Monitoring und Troubleshooting: VRF-spezifische Checks

Im Betrieb müssen Sie konsequent „vrf-aware“ troubleshoot’en. Viele „Internet down“ Fälle sind nur in einer VRF und werden mit globalen Checks übersehen.

• Routes prüfen pro VRF (Default, spezifische Prefixe)
• Pings/Traceroutes vrf-aware ausführen
• Interface-Errors und Drops pro Uplink/Tenant
• Syslog/NTP zentral, damit Events korrelierbar sind

CLI: VRF-aware Ping/Traceroute

ping vrf VRF-TENANT-A 1.1.1.1 repeat 10
traceroute vrf VRF-TENANT-A 1.1.1.1
show ip route vrf VRF-TENANT-A 0.0.0.0
show ip route vrf VRF-TENANT-B 0.0.0.0

UAT/Acceptance: Tests für Multi-Tenant-Design

VRF Lite ist erst abgenommen, wenn Isolation nachweisbar ist: Tenant A erreicht Tenant B nicht, Management ist exklusiv, und Shared Services sind nur via Allow-List erreichbar.

• Isolation: Tenant A → Tenant B blockiert (kein Routing/kein Policy-Leak)
• Services: jeder Tenant erreicht nur seine erlaubten Ziele
• Internet: pro VRF korrekt (NAT/Default/Policies)
• Monitoring: VRF-spezifische KPIs sichtbar, Logs korrekt

CLI: Evidence-Set (Copy/Paste)

show ip interface brief
show ip route vrf VRF-TENANT-A
show ip route vrf VRF-TENANT-B
ping vrf VRF-TENANT-A 1.1.1.1 repeat 10
traceroute vrf VRF-TENANT-A 1.1.1.1
show access-lists
show ntp status
show logging | last 50

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.