„Ready-to-Use“-Konfigurationstemplates für Branch-Router sind der schnellste Weg zu stabilen, sicheren und vergleichbaren Standorten. Das Ziel ist eine Golden Config, die überall gleich bleibt (Hardening, Logging, Monitoring, Policies), plus wenige Standortvariablen (SiteID, WAN-Daten, VPN-Peer). So reduzieren Sie Drift, vereinfachen Rollouts und beschleunigen Troubleshooting, weil jeder Standort dieselbe Struktur hat. Die folgenden Templates sind praxisorientierte Bausteine, die Sie als Copy/Paste-Grundlage verwenden und per Variablenmodell automatisieren können.
Template-Logik: Golden Config + Variablen (damit es skalierbar bleibt)
Ein „Ready-to-Use“-Template ist nicht eine riesige Config, sondern ein Baukasten. Alles, was überall gleich ist, gehört in die Baseline. Alles, was standortspezifisch ist, wird als Platzhalter geführt.
- Platzhalter (Beispiele): <SITEID>, <HOSTNAME>, <WAN_IP>, <WAN_MASK>, <WAN_GW>
- Standard-VLANs: 10=MGMT, 20=USERS, 50=GUEST, optional 40=IOT
- IP-Schema (Beispiel): 10.<SITEID>.<VLAN>.0
- Definition of Done: Pre-/Post-Checks + Abnahmeprotokoll + Handover
Template 1: Baseline (Hardening, SSH, NTP, Syslog)
Diese Baseline ist Pflicht und sollte in jeder Filiale identisch sein. Sie reduziert Angriffsfläche, schützt Adminzugriffe und stellt Auditfähigkeit sicher.
! ===== BASELINE / HARDENING =====
hostname <HOSTNAME>
no ip domain-lookup
no ip http server
no ip http secure-server
ip domain-name example.local
username netadmin privilege 15 secret <SECRET>
crypto key generate rsa modulus 2048
ip ssh version 2
ip access-list standard MGMT_ONLY
permit 10.<SITEID>.10.0 0.0.0.255
deny any
line vty 0 4
transport input ssh
access-class MGMT_ONLY in
login local
exec-timeout 10 0
service timestamps log datetime msec
ntp server 192.0.2.10 prefer
ntp server 192.0.2.11
logging host 192.0.2.20
logging trap informational
! ===== END BASELINE =====Template 2: WAN (Dedicated Internet / Standard ISP Hand-off)
Dieser Block wird pro Standort mit Providerdaten befüllt. Nutzen Sie immer eine klare Interface-Description mit Circuit-ID, damit Betrieb und Provider-Tickets schneller sind.
! ===== WAN =====
interface GigabitEthernet0/0
description WAN-ISP-PRIMARY-CID<CIRCUITID>-SITE<SITEID>
ip address <WAN_IP> <WAN_MASK>
ip nat outside
no cdp enable
no shutdown
ip route 0.0.0.0 0.0.0.0 <WAN_GW>
! ===== END WAN =====Template 3: LAN (Router-on-a-Stick VLAN-Gateways)
Für typische Branches ist Router-on-a-Stick praxistauglich. Der Trunk zum Switch bleibt gleich, die IPs folgen der SiteID-Logik. NAT inside ist für die internen VLANs gesetzt.
! ===== LAN / VLAN GATEWAYS =====
interface GigabitEthernet0/1
description LAN-TRUNK-to-SW1-SITE<SITEID>
no shutdown
interface GigabitEthernet0/1.10
description VLAN10-MGMT-SITE<SITEID>
encapsulation dot1Q 10
ip address 10.<SITEID>.10.1 255.255.255.0
ip nat inside
interface GigabitEthernet0/1.20
description VLAN20-USERS-SITE<SITEID>
encapsulation dot1Q 20
ip address 10.<SITEID>.20.1 255.255.255.0
ip nat inside
interface GigabitEthernet0/1.50
description VLAN50-GUEST-SITE<SITEID>
encapsulation dot1Q 50
ip address 10.<SITEID>.50.1 255.255.255.0
ip nat inside
! ===== END LAN =====Template 4: NAT (PAT/Overload) mit Whitelisting
NAT ist bewusst auf definierte Netze begrenzt. Das verhindert, dass versehentlich nicht vorgesehene VLANs Internetzugang erhalten. Ergänzen Sie No-NAT, wenn VPN im Scope ist.
! ===== NAT =====
ip access-list standard NAT_INSIDE
permit 10.<SITEID>.20.0 0.0.0.255
permit 10.<SITEID>.50.0 0.0.0.255
ip nat inside source list NAT_INSIDE interface GigabitEthernet0/0 overload
! ===== END NAT =====Template 5: Pflicht-Policy – Guest intern blockieren
Diese ACL ist der wichtigste Sicherheitsbaustein in Branches. Sie wird inbound am Guest-VLAN angewendet und blockiert interne RFC1918-Netze.
! ===== GUEST POLICY =====
ip access-list extended ACL-GUEST-IN
deny ip 10.<SITEID>.50.0 0.0.0.255 10.0.0.0 0.255.255.255
deny ip 10.<SITEID>.50.0 0.0.0.255 172.16.0.0 0.15.255.255
deny ip 10.<SITEID>.50.0 0.0.0.255 192.168.0.0 0.0.255.255
permit ip 10.<SITEID>.50.0 0.0.0.255 any
interface GigabitEthernet0/1.50
ip access-group ACL-GUEST-IN in
! ===== END GUEST POLICY =====Template 6: Optional – IoT-Policy (Whitelist) für Printer/POS
Wenn IoT/POS vorhanden ist, sollte es restriktiv sein. Das Template erlaubt DNS/NTP zu definierten Servern und blockiert interne Netze breit. Passen Sie Ziele/Ports an Ihre Policy-Matrix an.
! ===== OPTIONAL IOT VLAN =====
interface GigabitEthernet0/1.40
description VLAN40-IOT-SITE<SITEID>
encapsulation dot1Q 40
ip address 10.<SITEID>.40.1 255.255.255.192
ip nat inside
ip access-list extended ACL-IOT-IN
permit udp 10.<SITEID>.40.0 0.0.0.63 10.<SITEID>.10.10 0.0.0.0 eq 53
permit udp 10.<SITEID>.40.0 0.0.0.63 10.<SITEID>.10.10 0.0.0.0 eq 123
deny ip 10.<SITEID>.40.0 0.0.0.63 10.0.0.0 0.255.255.255
deny ip 10.<SITEID>.40.0 0.0.0.63 172.16.0.0 0.15.255.255
deny ip 10.<SITEID>.40.0 0.0.0.63 192.168.0.0 0.0.255.255
permit ip 10.<SITEID>.40.0 0.0.0.63 any
interface GigabitEthernet0/1.40
ip access-group ACL-IOT-IN in
! ===== END OPTIONAL IOT =====Template 7: Optional – Path-Monitoring (IP SLA) für „Link up, Internet down“
IP SLA ist ein pragmatischer Standardbaustein, insbesondere wenn Standorte ohne 24/7 Vor-Ort-Team betrieben werden. Er liefert Messwerte für Monitoring und kann für Failover-Logik genutzt werden.
! ===== OPTIONAL IP SLA =====
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
! ===== END OPTIONAL IP SLA =====Template 8: Abnahme- und Runbook-Checks (Pflichtanhang)
Ein „Ready-to-Use“-Template ist erst vollständig, wenn ein standardisiertes Checkset existiert. Diese Kommandos gehören in Pre-/Post-Checks und in das Handover.
! ===== POST-CHECKS / RUNBOOK =====
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip nat statistics
show ip nat translations
show ntp status
show logging | last 50
show ip sla statistics
ping 8.8.8.8 repeat 10
traceroute 1.1.1.1
! ===== END CHECKS =====Rollout-Hinweise: So bleiben Templates wirklich „ready“
Templates sind nur dann „ready-to-use“, wenn sie versioniert, getestet und drift-kontrolliert sind. Halten Sie daher eine feste SOP ein, statt pro Standort „kleine Änderungen“ einzubauen.
- Pilotstandort: Template einmal vollständig abnehmen, dann Template-Freeze
- Wellenrollout: Standorte in Batches ausrollen, nach jeder Welle prüfen
- Drift-Control: Soll/Ist-Abgleich der Running-Config gegen Template
- Dokumentation: Variablenblatt + Config pre/post + Abnahmeprotokoll pro Standort
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.
