Eine Cisco-Router-Konfiguration im Enterprise-Umfeld ist mehr als „Connectivity“: Sie muss Standards erfüllen, Compliance-Anforderungen nachweisbar umsetzen und SLA-relevante Betriebsfähigkeit liefern. Entscheidend sind konsistente Templates (Golden Config), klare Segmentierung, robuste Edge- und WAN-Designs (Dual-ISP, BGP, VPN), sowie ein Betriebskonzept mit Monitoring, Auditing, Change-Prozessen und dokumentierten Abnahmetests. Dieser Leitfaden zeigt praxisnah, welche Bausteine in Enterprise-Setups Pflicht sind und wie Standards in Cisco-CLI abgebildet werden.
Enterprise-Anforderungen: Was sich gegenüber KMU wirklich ändert
Enterprise bedeutet meist: höhere Kritikalität, mehr Standorte, strengere Security- und Audit-Vorgaben sowie definierte SLAs. Dadurch steigen die Anforderungen an Nachvollziehbarkeit (Dokumentation/Logging) und Wiederholbarkeit (Templates/SOPs).
- Skalierung: viele Standorte, standardisierte Rollouts, Drift-Vermeidung
- Compliance: Audit-Logs, Zugriffskontrollen, Kryptostandards, Nachweisdokumente
- Verfügbarkeit: Dual-WAN, HA, definierte Failover-Zeiten
- Betrieb: 24×7 Monitoring/Alerting, Incident-/Change-Prozesse, Reports
Standards: Golden Config, Namenskonventionen und Template-Strategie
Enterprise-Netze werden mit Baselines betrieben: Eine Golden Config enthält unveränderliche Sicherheits- und Betriebsstandards, Standortvariablen steuern IPs, Peers, VLANs und Providerparameter. So werden Changes skalierbar und auditierbar.
- Golden Config: Hardening, Logging, NTP, SNMPv3, AAA, Standard-Banner
- Variablen: Hostname, WAN-IP, VLANs/Subnetze, VPN-Peers, Routing-Parameter
- Versionierung: Konfig-Repository, Change-Referenz (Ticket-ID), Review-Prozess
- Drift Control: regelmäßiger Abgleich Soll vs. Ist
Beispiel: Standardisierte Interface-Descriptions (Betriebswirkung)
interface GigabitEthernet0/0
description WAN-ISP1-BER-EDGE
interface GigabitEthernet0/1
description LAN-TRUNK-SW1-BERCompliance: Nachweisbare Security-Baselines als Pflicht
Compliance verlangt nicht nur „sicher“, sondern „nachweisbar sicher“. Das bedeutet: definierte Standards für Management-Zugriffe, starke Authentifizierung, zentrale Logs, sichere Protokolle und reproduzierbare Kontrollen.
- SSH-only, Management aus definierten Netzen, keine Klartextdienste
- AAA (TACACS+/RADIUS) mit Accounting, rollenbasierte Rechte
- Syslog zentral + Zeitstempel + NTP (Korrelation im SIEM)
- SNMPv3 (Auth+Priv) oder kein SNMP
- Kryptostandards für VPN (IKEv2, starke Cipher/Hash, PFS je Policy)
Beispiel: SSH-only + VTY-Restriktion (Mindeststandard)
ip domain-name example.corp
crypto key generate rsa modulus 2048
ip ssh version 2
ip access-list standard MGMT_ONLY
permit 10.10.99.0 0.0.0.255
deny any
line vty 0 4
transport input ssh
access-class MGMT_ONLY in
exec-timeout 10 0
Beispiel: AAA-Grundstruktur (Konzeptmuster)
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa accounting exec default start-stop group tacacs+Beispiel: NTP und Syslog für Audit-Trails
service timestamps log datetime msec
ntp server 192.0.2.10 prefer
ntp server 192.0.2.11
logging buffered 64000 informational
logging host 192.0.2.20
logging trap informational
Beispiel: SNMPv3 (Enterprise-Standard)
snmp-server group NMS v3 priv
snmp-server user snmpmon NMS v3 auth sha <AUTH> priv aes 128 <PRIV>
snmp-server location "BER-EDGE-01"Verfügbarkeit und SLA: Designs, die messbar liefern
SLAs werden technisch über Redundanz, Failover-Mechanismen und Monitoring umgesetzt. Ein Enterprise-Setup muss Failover nicht nur „haben“, sondern auch testen und dokumentieren (Abnahmeprotokoll, Konvergenzzeiten, Trigger).
- Dual-WAN: Link-Down und Path-Down erkennen (IP SLA + Tracking)
- HA: HSRP/VRRP oder L3-Redundanz mit definierter Präferenz
- VPN-Resilienz: Primary/Backup-Peers, DPD, sauberes Rekeying
- Monitoring: SLA-Metriken (Upstream-Health, Tunnelstatus, Flaps, Drops)
Beispiel: IP SLA + Tracking für Path-Failover
ip sla 10
icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
frequency 5
timeout 1000
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability
ip route 0.0.0.0 0.0.0.0 198.51.100.1 track 10
ip route 0.0.0.0 0.0.0.0 203.0.113.1 200
Enterprise-Routing: OSPF intern, BGP am Edge
In Enterprise-Architekturen ist OSPF häufig das interne IGP, während BGP am Edge für Provider-Anbindung, Multi-Homing und Policy-Steuerung genutzt wird. Wichtig sind Filter, klare Policies und minimale Redistribution.
- OSPF: Areas, passive Interfaces, Summarization nach Design
- BGP: Prefix-Lists, Route-Maps, Communities, klare In/Out-Policies
- Redistribution: nur wenn nötig, strikt gefiltert
Beispiel: OSPF-Basis mit passiven Interfaces
router ospf 10
router-id 10.255.255.1
passive-interface default
no passive-interface GigabitEthernet0/1
network 10.10.0.0 0.0.255.255 area 0Beispiel: eBGP mit Outbound Prefix-Filter (Pflichtprinzip)
ip prefix-list OUT-PFX seq 10 permit 203.0.113.0/24
ip prefix-list OUT-PFX seq 20 deny 0.0.0.0/0 le 32
route-map RM-OUT permit 10
match ip address prefix-list OUT-PFX
router bgp 65010
neighbor 198.51.100.1 remote-as 65001
neighbor 198.51.100.1 route-map RM-OUT out
Segmentierung und Policies: VLAN/VRF, ACLs und Trust-Grenzen
Enterprise-Umgebungen benötigen saubere Trust-Grenzen: Office, Guest, OT/IoT, Server und Management werden getrennt, häufig per VLAN und in größeren Umgebungen zusätzlich per VRF. Policies werden an den Grenzen implementiert und dokumentiert.
- Management separat (Management-VLAN/VRF) mit restriktiven Zugängen
- Guest strikt: nur Internet, kein Zugriff auf interne Netze
- OT/IoT limitiert: nur benötigte Ports zu definierten Zielen
- Policies nachvollziehbar: Zweck, Owner, Änderungsprozess
Beispiel: Guest-VLAN vom internen Netz trennen
ip access-list extended ACL-GUEST-IN
deny ip 10.10.30.0 0.0.0.255 10.10.0.0 0.0.255.255
permit ip 10.10.30.0 0.0.0.255 any
interface GigabitEthernet0/1.30
ip access-group ACL-GUEST-IN in
VPN-Standards: IKEv2/IPsec, Templates und Betriebskontrollen
Enterprise-VPNs müssen interoperabel, standardisiert und überwacht sein. Neben Kryptostandards sind MTU/MSS, No-NAT und klare Abnahmetests entscheidend, damit „Tunnel up“ auch wirklich „Traffic ok“ bedeutet.
- IKEv2 bevorzugen, standardisierte Crypto-Suites und dokumentierte Abweichungen
- No-NAT für VPN-Netze verpflichtend
- VTI + dynamisches Routing (wenn Skalierung gefordert ist)
- Monitoring: IKEv2 SA, IPsec SA, Paketzähler, Rekey/DPD
VPN-Checks (Runbook-Baustein)
show crypto ikev2 sa
show crypto ipsec sa
show crypto session detailQoS im Enterprise: SLA-relevante Applikationen schützen
QoS ist oft Bestandteil von SLAs für Voice/Video. Entscheidend ist Shaping am WAN-Egress, klare Klassen (Voice/Video/Business) und messbare Abnahme über Policy-Zähler und Drops.
- LLQ für Voice (DSCP EF), bevorzugte Klassen für Collaboration
- Shaping leicht unter Providerbandbreite
- Abnahme: policy-map Zähler, reduzierte Drops, stabile Call-Qualität
QoS-Verification (Betrieb)
show policy-map interface
show interfaces counters errorsMonitoring und Alerting: SLA braucht Telemetrie
Ohne Monitoring können SLAs nicht nachgewiesen werden. Enterprise-Monitoring nutzt Syslog, SNMPv3 und häufig zusätzliche Mechanismen wie IP SLA für Path-Health. Alarme müssen korreliert und priorisiert sein, sonst entsteht Alarmmüdigkeit.
- Pflichtalarme: WAN down/flaps, Path-down, CPU hoch, Errors/Drops, VPN down, Routing neighbor down
- Reports: Verfügbarkeit, Top Incidents, Kapazitätstrends
- Runbooks: Standardkommandos und Eskalation pro Alarmtyp
Beispiel: Monitoring-Baseline (Syslog + SNMPv3)
service timestamps log datetime msec
logging host 192.0.2.20
logging trap informational
snmp-server group NMS v3 priv
snmp-server user snmpmon NMS v3 auth sha priv aes 128
Change- und Betriebsprozesse: Compliance und SLA im Alltag umsetzen
Enterprise-Konfiguration ist ohne Prozesse nicht stabil. Standards müssen durch Change-Management, Reviews, Abnahme und Rollback abgesichert werden. Damit werden Changes wiederholbar, risikoarm und auditierbar.
- Change-Plan: Schritte, Verantwortlichkeiten, Kommunikationsplan
- Pre-/Post-Checks mit Protokollierung
- Rollback-Plan mit klaren Triggern
- Konfigversionierung: vor/nach Change, Ticket-ID, Freigaben
Standard-Pre-/Post-Checks (Abnahme-Template)
show ip interface brief
show interfaces counters errors
show ip route summary
show processes cpu sorted
show logging | last 50
show crypto ipsec saDeliverables im Enterprise: Was Sie als Ergebnis erwarten sollten
Enterprise bedeutet „nachweisbar geliefert“. Deliverables sind nicht nur Config-Dateien, sondern vollständige Betriebsartefakte, die Audit, Betrieb und künftige Changes unterstützen.
- Golden Config + Standortvariablen (Template-Ansatz)
- IP-/Interface-Plan, Routing- und Failover-Design (LLD)
- Security- und Compliance-Nachweise (Management-Restriktionen, Logging, AAA)
- Abnahmeprotokolle inkl. Failover- und VPN-Tests
- Runbook/SOP (Monitoring, Standard-Checks, Eskalation)
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.
