Eine Standard Naming Convention für Cisco-Router ist ein unterschätzter Erfolgsfaktor: Sie reduziert Fehlkonfigurationen, beschleunigt Troubleshooting und macht Automatisierung sowie Audits deutlich einfacher. Ohne Namensstandard entstehen schnell kryptische Interface-Descriptions, uneinheitliche ACL-Namen, „Copy/Paste“-Objekte ohne Kontext und Policies, die niemand mehr sicher ändern möchte. Eine production-grade Convention ist kurz, eindeutig, maschinenlesbar und skalierbar für viele Standorte. Dieser Leitfaden liefert praxistaugliche Standards für Hostnames, Interfaces, Routing/VPN-Objekte und Policies – inklusive CLI-Beispiele, die Sie direkt als Template nutzen können.
Designprinzipien: So sieht ein guter Namensstandard aus
Ein Standard muss im Betrieb funktionieren: schnell lesbar, konsistent und ohne Sonderfälle. Vermeiden Sie überlange Namen und stellen Sie sicher, dass die wichtigsten Informationen vorne stehen.
- Eindeutig: Name identifiziert Objekt ohne zusätzliche Recherche
- Kurz: in CLI und Tools gut nutzbar (keine „Romane“)
- Konsistent: gleiche Reihenfolge der Felder überall
- Skalierbar: funktioniert für 5 und für 500 Standorte
- Maschinenlesbar: Trennzeichen und Token klar definiert
Token-Standard: Die Bausteine, aus denen alle Namen bestehen
Definieren Sie wenige, feste Tokens, die überall wiederverwendet werden. Dadurch wird Naming automatisch und Tools können Regeln anwenden.
- SITE: Standortkennung (z. B. BR012, HQ001, DC01)
- ROLE: Geräte-/Objektrolle (R, FW, SW, HUB, SPOKE)
- ENV: Umfeld (PRD, TST) falls erforderlich
- VRF/SEG: Segment (MGMT, CORP, GUEST, OT)
- LINK: WAN1/WAN2/LTE/MPLS/INET
Hostnames: Standort + Rolle + Nummer (ohne Rätselraten)
Hostnames sind die erste Orientierung in Logs und Monitoring. Halten Sie sie stabil und vermeiden Sie IP-Adressen oder Provider-Namen im Hostname.
- Format: ROLE-SITE-NN (oder SITE-ROLE-NN, aber konsistent)
- Beispiele: R-BR012-01, R-HQ001-02, R-DC01-EDGE-01
- Optional: ENV als Suffix (z. B. -TST), wenn nötig
CLI: Hostname + Banner Header (Beispiel)
hostname R-BR012-01
!
! TEMPLATE: naming-standard
! VERSION: v1.0.0
! SITE: BR012
! ROLE: BRANCH-EDGE
!Interfaces: Description-Standard, der im Incident hilft
Interface-Descriptions sind der schnellste Debug-Hebel. Ein guter Standard sagt in einer Zeile: wohin geht der Link, wofür ist er, und wer ist der Gegenpart.
- Format: ROLE|LINK|PEER|CIRCUIT|COMMENT
- ROLE: WAN/LAN/MGMT/TRN (Transit)
- PEER: Provider/Device (kurz), kein Freitext
- CIRCUIT: Circuit-ID oder Ticket-Referenz (wenn vorhanden)
Beispiel-Descriptions
- WAN|INET1|ISP-A|CIR123456|PPPoE
- WAN|INET2|ISP-B|CIR987654|DIA
- TRN|HQ|R-HQ001-01|VLAN999|IPsec-HUB
- LAN|CORP|SW-BR012-01|TRUNK|802.1Q
CLI: Interface-Descriptions (Beispiel)
interface GigabitEthernet0/0
description WAN|INET1|ISP-A|CIR123456|DIA
ip address 203.0.113.2 255.255.255.252
no shutdown
interface GigabitEthernet0/1
description LAN|CORP|SW-BR012-01|TRUNK|802.1Q
no shutdown
VLAN-/Subinterface-Design: Tokens für Übersicht und Automatisierung
Wenn Sie Subinterfaces nutzen, standardisieren Sie VLAN-ID und Segmentname. Das erleichtert IP-Plan, UAT und späteres Rollout-Templating.
- Subinterface: Gi0/1.10 = VLAN 10 (CORP)
- Beschreibung: LAN|CORP|VLAN10|GW
- Gateway-IP: standardisierte Regel (z. B. .1 oder .254)
CLI: Subinterface-Naming (Beispiel)
interface GigabitEthernet0/1.10
description LAN|CORP|VLAN10|GW
encapsulation dot1Q 10
ip address 10.12.10.1 255.255.255.0Objekte in Policies: ACL-Namen, Prefix-Lists und Route-Maps
Policy-Objekte müssen sofort erkennen lassen, in welcher Richtung und für welchen Zweck sie genutzt werden. Verwenden Sie Prefixe, die den Typ und die Richtung codieren.
- ACL: ACL-<SCOPE>-<DIR>-<PURPOSE>
- Prefix-List: PL-<PROTO>-<DIR>-<SCOPE>
- Route-Map: RM-<PROTO>-<DIR>-<PURPOSE>
Beispiele
- ACL-MGMT-IN-SSHONLY
- ACL-GUEST-IN-BLOCK-RFC1918
- PL-BGP-OUT-PUBLIC
- RM-BGP-IN-SETLOCALPREF
CLI: ACL + Prefix-List + Route-Map (Beispiel)
ip access-list standard ACL-MGMT-IN-SSHONLY
permit 10.10.10.0 0.0.0.255
deny any
ip prefix-list PL-BGP-OUT-PUBLIC seq 10 permit 198.51.100.0/24
route-map RM-BGP-OUT-ANNOUNCE permit 10
match ip address prefix-list PL-BGP-OUT-PUBLIC
Tracking/IP SLA: Standardnamen für Dual-ISP und Verfügbarkeit
Bei Dual-ISP ist Naming besonders wichtig, weil NOC und RCA auf Track-Events basieren. Standardisieren Sie SLA-IDs und Track-Namen/Kommentare.
- IP SLA: SLA-<LINK>-<TARGET> (in Doku/Runbook), ID numerisch stabil
- Track: TRK-<LINK>-<SLAID>
- Log-Suche: Track-Events eindeutig zuordenbar
CLI: IP SLA + Track (Beispiel)
ip sla 10
icmp-echo 10.0.0.10 source-interface GigabitEthernet0/0
frequency 10
timeout 1000
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability
VPN-Objekte: Tunnel-Gruppen, Crypto-Maps, Profiles
VPN-Naming muss Standortbezug und Rolle (Hub/Spoke) enthalten, damit Tickets und Monitoring eindeutig sind. Vermeiden Sie generische Namen wie „VPN1“.
- IKEv2 Profile: IKEV2-<SITE>-TO-<PEER>
- IPsec Profile: IPSEC-<SITE>-TO-<PEER>
- Tunnel Interface: TU-<PEER>-<ROLE> (wenn Tunnel-Interfaces genutzt werden)
Beispiele
- IKEV2-BR012-TO-HQ001
- IPSEC-BR012-TO-HQ001
- TU-HQ001-HUB
QoS-Policies: Klassen und Policies standardisieren
QoS ist ohne Naming kaum wartbar. Standardisieren Sie Class-Maps und Policy-Maps nach Zweck und Richtung.
- Class-Map: CM-<PURPOSE> (z. B. CM-VOICE, CM-VIDEO, CM-DEFAULT)
- Policy-Map: PM-<DIR>-<LINK> (z. B. PM-OUT-WAN)
- Interface Attach: dokumentiert und konsistent
CLI: QoS Naming (Beispiel)
class-map match-any CM-VOICE
match dscp ef
policy-map PM-OUT-WAN
class CM-VOICE
priority percent 10
class class-default
fair-queue
Dokumentations- und Runbook-Naming: Evidence wird dadurch nutzbar
Benennen Sie Evidence-Dateien, Backups und Runbooks nach dem gleichen Token-Standard. Das beschleunigt Audits und Incidents massiv.
- Backup: SITE_DEVICE_PRE/POST_CHANGEID_TIMESTAMP
- Evidence: SITE_DEVICE_TESTID_TIMESTAMP
- Runbook: RB-<SCOPE>-<SITECLASS> (z. B. RB-DUALISP-BRANCH)
DoD und Governance: Naming-Standard durchsetzen
Ein Naming-Standard wirkt nur, wenn er überprüft wird. Machen Sie ihn zum Go-Live Gate und integrieren Sie Checks in Reviews und Automatisierung.
- Review Gate: Interface descriptions, ACL/Policy-Namen, Template-Version
- Automation: Naming aus Variablen rendern (keine Freitextfelder)
- Drift-Control: regelmäßiger Soll/Ist-Abgleich
- KT/Ops: Runbooks und NOC-Dashboards nutzen gleiche Tokens
CLI: Quick Naming Audit (Beispiel)
show running-config | include ^hostname
show interfaces description
show running-config | include ip access-list|ip prefix-list|route-map|policy-map|class-mapKonfiguriere 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.
