„Campus“ und „WAN Edge“ werden in Enterprise-Architekturen 2026 stärker getrennt geplant als früher: Der Campus optimiert Nutzer-Experience, Segmentierung und automatisierten Betrieb (z. B. SD-Access/Fabric), während die WAN Edge Multi-Transport, Internet-/Cloud-Anbindung, VPN/SD-WAN und Security-Controls bündelt. Die wichtigste Designentscheidung ist daher nicht „welcher Router“, sondern „welche Rolle an welcher Grenze“ – und welche Funktionen bewusst nicht in den Campus verlagert werden.
Rollenklärung 2026: Campus ist Access/Policy – WAN Edge ist Transport/Security
Im Campus liegt der Schwerpunkt auf stabiler Layer-3-Access-Architektur, konsistenter Segmentierung (Identity/Policy) und automatisierter Provisionierung. An der WAN Edge liegt der Schwerpunkt auf Underlay-Transporten (MPLS/Internet/LTE/Sat), Overlay (SD-WAN/DMVPN/IPsec), Internet-Breakout, Cloud-Onramps und Failover.
- Campus: deterministisches Routing, Segmentierung, Campus-Services (DHCP, DNS-Relay), geringe State-Komplexität
- WAN Edge: SD-WAN/VPN, NAT, Zonen-/Firewall-Policy, QoS/Shaping, Dual-ISP, Cloud/SaaS-Pfade
- Pitfall: „Alles am Campus-Core terminieren“ → Policy-Spaghetti und schwieriges Troubleshooting
Campus-Architektur 2026: Fabric-Ansatz vs. klassisches Routed Access
Im Cisco-Umfeld wird SD-Access als intent-basierte Campus-Fabric weiterhin als Referenzmodell dokumentiert und designiert, inklusive Unterlay/Overlay und klaren Rollen (Border, Control-Plane, Edge). :contentReference[oaicite:0]{index=0}
Wann SD-Access/Fabric im Campus sinnvoll ist
- Viele Standorte/Segmente: standardisierte Policy und Automatisierung (z. B. über Catalyst Center) :contentReference[oaicite:1]{index=1}
- Strikte Segmentierung: „Default Deny“ und explizite Freigaben via Policy-Mechanismen (z. B. SGACL-Ansatz) :contentReference[oaicite:2]{index=2}
- Hohe Change-Frequenz: konsistente Templates und wiederholbare Provisionierung
Wann klassisches Routed Access oft besser passt
- Kleine/mittlere Campus-Umgebungen mit stabilen VLANs/Segmentation
- Teams ohne Fabric-Betriebserfahrung (Ops-Komplexität vermeiden)
- Sehr spezifische Legacy-Anforderungen, die in Fabrics zusätzliche Designarbeit erfordern
WAN Edge 2026: Multi-Transport, Overlay und Cloud-/SaaS-Optimierung
An der WAN Edge geht es um „Pfadwahl“ und „Resilienz“: mehrere Provider, mehrere Transporttypen, Quality-of-Experience und Security-Controls. Cisco positioniert dafür u. a. Catalyst-8000-Edge-Plattformen (inkl. virtueller Varianten) auf IOS XE für Routing, VPN, Firewall, NAT, QoS und Failover-Funktionen. :contentReference[oaicite:3]{index=3}
Typische WAN-Edge-Patterns
- Dual-ISP mit Tracking: Primary/Backup oder Active/Active (ECMP) je nach State/NAT
- SD-WAN/Overlay: zentrales Policy-Management, App-Erkennung, Pfad-Policy
- Cloud Edge: direkte Cloud-Onramps und kontrollierter Internet-Breakout
Minimalpattern: Dual-ISP Failover mit IP SLA
ip sla 1
icmp-echo 1.1.1.1 source-interface gigabitEthernet0/1
frequency 5
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1
ip route 0.0.0.0 0.0.0.0 198.51.100.1 10
SASE und Zero Trust 2026: Entscheidungspunkt „wo endet die Edge?“
2026 ist die Frage häufig nicht mehr nur „Router oder Firewall“, sondern „On-Prem Edge oder Cloud-delivered Edge“. Cisco beschreibt mit Secure Access einen SASE-/Zero-Trust-Ansatz, der Zugriffskontrolle und Sichtbarkeit cloudbasiert bündelt (inkl. aktuellen Schwerpunkten wie Kontrolle von Third-Party-AI-Apps). :contentReference[oaicite:4]{index=4}
- Wenn viele Remote-User/SaaS: Cloud-Policy kann Betriebsaufwand reduzieren
- Wenn Branches stark standardisiert: Edge-Templates + zentral gemanagte Policies
- Pitfall: SASE einführen, aber Campus/WAN-Rollen nicht neu schneiden → Doppelpolicies
Security-Realität 2026: Management-Exposure ist der häufigste „Edge-Killer“
Für WAN-Edge-Architekturen gilt: Management-Interfaces dürfen nicht internetexponiert sein, und Patch-/Hardening-Prozesse müssen besonders strikt sein. Sicherheitsmeldungen zu aktiv ausgenutzten Schwachstellen in SD-WAN-Komponenten zeigen, dass Angreifer gezielt die Kontroll- und Management-Ebene angreifen. :contentReference[oaicite:5]{index=5}
Baseline: Management-Plane strikt begrenzen
ip ssh version 2
ip access-list standard VTY_MGMT
permit 10.255.0.0 0.0.255.255
deny any
line vty 0 15
login local
transport input ssh
access-class VTY_MGMT in
exec-timeout 10 0
Wo segmentierst du was? Campus-Segmentierung vs. Edge-Policy
Ein bewährtes Pattern ist: Mikrosegmentierung und Identitäts-/Rollenpolicy im Campus, Grobsegmentierung und Internet-/WAN-Policy an der Edge. So bleibt die Data-Plane im Campus sauber, während die WAN Edge State (NAT, VPN, Firewall) kontrolliert bündelt.
- Campus: „Wer darf wohin intern?“ (User/IoT/Server/OT-Segmente)
- WAN Edge: „Wie geht Traffic raus?“ (NAT, Breakout, Zonen, VPN)
- Pitfall: NAT oder komplexe Zonenpolicy im Campus-Core → Debug-Hölle
QoS-Aufteilung 2026: Campus markiert, WAN Edge shaped und priorisiert
Im Campus ist QoS häufig Marking/Trust-Grenzen (z. B. Voice/Video). An der WAN Edge wird QoS wirksam, weil dort Congestion entsteht: Shaping auf Provider-Rate und LLQ/CBWFQ für kritische Klassen.
WAN-Edge-Pattern: Shaper + Voice-LLQ
class-map match-any CM_VOICE
match dscp ef
policy-map PM_CHILD
class CM_VOICE
priority 1000
class class-default
fair-queue
policy-map PM_PARENT
class class-default
shape average 9500000
service-policy PM_CHILD
interface gigabitEthernet0/1
service-policy output PM_PARENT
Observability 2026: Campus und WAN Edge brauchen unterschiedliche Telemetrie
Campus-Teams brauchen Sicht auf Client-/Fabric-Zustände und Segmentierungseffekte; WAN-Edge-Teams brauchen Sicht auf Pfade, Underlay-Qualität, NAT/VPN und App-Performance. Minimum auf Routern bleibt: Syslog, SNMPv3 und (bei Bedarf) NetFlow.
- Campus: Interface/Client-/Policy-Sicht, Events und Health
- WAN Edge: Pfadmetriken, IPsec/SD-WAN Status, NAT- und QoS-Counters
- Pitfall: Nur SNMP-Bandbreite → keine Aussage „wer verursacht den Engpass“
Syslog- und NTP-Baseline
service timestamps log datetime msec localtime
ntp server 10.255.0.10 prefer
logging host 10.255.0.20
logging source-interface loopback0
logging trap warningsEntscheidungsfragen: So triffst du 2026 die Architekturwahl
Diese Fragen helfen, Campus und WAN Edge sauber zu schneiden, ohne sich in Produktdetails zu verlieren.
- Wo entsteht Congestion? (meist WAN) → dort QoS/Shaping und Pfadsteuerung
- Wo ist State nötig? (NAT/VPN/Firewall) → möglichst an der Edge terminieren
- Wie hoch ist Change-Frequenz im Campus? → Automatisierung/Fabric vs. klassisch
- Wie viele Standorte? → Templates/SD-WAN/DMVPN-Patterns
- Wie kritisch ist Remote Access/SaaS? → SASE/Zero Trust vs. On-Prem Edge :contentReference[oaicite:6]{index=6}
Praktisches Pattern: „Clean Campus, Strong Edge“ als Baseline
Ein praxistaugliches Enterprise-Muster ist: Campus als routed access mit klarer Segmentierung und minimalem State, WAN Edge als Policy-/Transport-Knoten mit Dual-ISP, VPN/SD-WAN, NAT und Security-Hardening. In Cisco-Designguides wird die Campus-Fabric als strukturierter Ansatz beschrieben, während Edge-Plattformen Funktionen für Routing/VPN/NAT/QoS bündeln. :contentReference[oaicite:7]{index=7}
- Campus: L3-Access, Summarization, klare Default-Gateway-Strategie
- WAN Edge: Shaper + QoS, IP SLA Tracking, VPN/SD-WAN Policies, OOB
- Betrieb: Golden Config, Drift Detection, zentrale Logs/Monitoring
Konfiguration speichern
Router# copy running-config startup-config::contentReference[oaicite:8]{index=8}
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.
