Retail-Netze mit vielen Filialen benötigen vor allem eines: Standardisierung. Kassen (POS), Payment-Terminals, Gäste-WLAN, IoT (Kameras, Digital Signage) und Backoffice müssen stabil laufen, sicher getrennt sein und sich mit minimalem Aufwand ausrollen lassen. Der Schlüssel ist ein wiederverwendbares Cisco-Router-Template („Golden Config“) plus klare Standortvariablen und eine Rollout-SOP mit Pre-/Post-Checks, Abnahme und Rollback. Dieser Leitfaden zeigt, wie Sie Template und Rollout so aufbauen, dass 10, 100 oder 1.000 Filialen beherrschbar bleiben.
Retail-Anforderungen: Warum Filialnetze besondere Standards brauchen
Retail ist betriebskritisch und zeitkritisch: Ausfälle bedeuten Umsatzverlust. Gleichzeitig sind Filialen oft heterogen (Provider, Leitungsqualität, lokale Verkabelung). Eine robuste Konfiguration muss daher standardisiert, fehlertolerant und betriebsfähig (Monitoring) sein.
- POS/Payment: hohe Verfügbarkeit, geringe Latenz, stabile Pfade
- Segmentierung: POS strikt getrennt von Guest/IoT und Backoffice
- WAN: häufig Single oder Dual-ISP, Path-Failover erforderlich
- Remote-Betrieb: zentraler Rollout, Remote-Troubleshooting, OOB/Remote-Hands
- Compliance: Logging, Zugriffskontrolle, nachvollziehbare Changes
Template-Strategie: Golden Config + Standortvariablen
In Retail-Umgebungen sollte die Konfiguration in zwei Teile zerlegt werden: Eine unveränderliche Baseline (Golden Config) und ein kleines Variablenpaket pro Filiale (IPs, VLANs, Peers, Providerdaten). Damit vermeiden Sie Drift und reduzieren Rollout-Fehler.
Golden Config (immer gleich)
- Hardening: SSH-only, Management-Restriktionen, sichere Defaults
- NTP, Syslog, SNMPv3 (Monitoring-Basis)
- Namenskonventionen: Hostname, Interface-Descriptions, Objekt-/ACL-Namen
- Standard-Checks: Pre-/Post-Check-Kommandos, Abnahmekriterien
Standortvariablen (pro Filiale unterschiedlich)
- Hostname/Store-ID
- WAN-Parameter: IP/PPPoE, Gateway, VLAN-Tagging, MTU
- LAN-Subnets und VLANs: Gateways, DHCP-Relays
- VPN: Peer-IP/FQDN, erlaubte Netze, PSK/Zertifikate
- Dual-ISP: Tracking-Ziele, Prioritäten, Backup-Route
Standard-Segmentierung im Retail: POS, Backoffice, IoT, Guest
Die wichtigste Sicherheits- und Betriebsregel lautet: POS/Payment niemals im gleichen Segment wie Gäste oder IoT. Eine übersichtliche Rollenstruktur mit festen VLAN-IDs erleichtert Policies, Monitoring und Rollouts.
- VLAN10-MGMT: Management (nur IT)
- VLAN20-POS: Kassen/Payment (streng restriktiv)
- VLAN30-BACKOFFICE: Office-PCs, lokale Systeme
- VLAN40-IOT: Kameras, Signage, Sensoren (limitiert)
- VLAN50-GUEST: Gäste (nur Internet)
Subnetting für Filialrollen: /26 als Standardbaustein
Für kleine Filialsegmente ist /26 häufig ausreichend: 64 Adressen, 62 nutzbar. Das reduziert Broadcast-Last und hält den IP-Plan modular.
Beispiel: VLAN-Gateways (Router-on-a-Stick, Auszug)
interface GigabitEthernet0/1
description LAN-TRUNK-to-SW1
no shutdown
interface GigabitEthernet0/1.10
description VLAN10-MGMT
encapsulation dot1Q 10
ip address 10.10.10.1 255.255.255.192
interface GigabitEthernet0/1.20
description VLAN20-POS
encapsulation dot1Q 20
ip address 10.10.20.1 255.255.255.192
interface GigabitEthernet0/1.50
description VLAN50-GUEST
encapsulation dot1Q 50
ip address 10.10.50.1 255.255.255.0
Policies: POS schützen, Guest isolieren, IoT begrenzen
Retail-Policies sollten minimalistisch und strikt sein: POS darf nur zu definierten Payment-Zielen, Guest darf nicht ins interne Netz, IoT darf nur zu benötigten Management-/Cloud-Zielen. Alles muss dokumentiert und testbar sein.
Beispiel: Guest nur Internet (kein Zugriff auf interne Netze)
ip access-list extended ACL-GUEST-IN
deny ip 10.10.50.0 0.0.0.255 10.10.0.0 0.0.255.255
permit ip 10.10.50.0 0.0.0.255 any
interface GigabitEthernet0/1.50
ip access-group ACL-GUEST-IN in
Beispiel: POS nur zu definierten Zielen (konzeptionelles Muster)
ip access-list extended ACL-POS-IN
permit tcp 10.10.20.0 0.0.0.63 198.51.100.100 0.0.0.0 eq 443
permit udp 10.10.20.0 0.0.0.63 198.51.100.101 0.0.0.0 eq 123
deny ip 10.10.20.0 0.0.0.63 10.10.0.0 0.0.255.255
permit ip 10.10.20.0 0.0.0.63 any
interface GigabitEthernet0/1.20
ip access-group ACL-POS-IN in
WAN und Dual-ISP: Failover, das wirklich funktioniert
In Filialen ist „Link up“ nicht gleich „Internet ok“. Daher wird Path-Monitoring mit IP SLA genutzt, um Upstream-Ausfälle zu erkennen und kontrolliert auf Backup umzuschalten. Das ist essenziell für POS/Payment.
Beispiel: IP SLA + Tracking (Primary/Backup Default-Route)
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
Erwartete Ergebnisse im Betrieb
- Bei Path-Ausfall ISP1 übernimmt ISP2 automatisch
- POS-Transaktionen laufen nach kurzer Umschaltung wieder
- Flapping wird durch saubere Schwellenwerte/Tests minimiert
NAT und VPN: Filial-Standard für Internet und Zentrale
Retail-Filialen nutzen meist NAT Overload für Internet und ein Site-to-Site VPN zur Zentrale/Cloud. Wichtig: No-NAT für VPN-Traffic, sonst entstehen sporadische Probleme („Tunnel up, kein Traffic“).
Beispiel: NAT Overload (mehrere VLANs)
interface GigabitEthernet0/0
description WAN-ISP
ip address 198.51.100.2 255.255.255.252
ip nat outside
no shutdown
interface GigabitEthernet0/1
ip nat inside
ip access-list standard NAT_INSIDE
permit 10.10.10.0 0.0.0.63
permit 10.10.20.0 0.0.0.63
permit 10.10.30.0 0.0.0.63
permit 10.10.40.0 0.0.0.63
permit 10.10.50.0 0.0.0.255
ip nat inside source list NAT_INSIDE interface GigabitEthernet0/0 overload
VPN-Checks (Runbook-Baustein)
show crypto ikev2 sa
show crypto ipsec sa
show crypto session detailMonitoring für viele Filialen: Syslog, SNMPv3 und sinnvolles Alerting
Bei vielen Filialen entscheidet Monitoring über Betriebskosten. Ein Standard-Setup mit Syslog und SNMPv3 ermöglicht zentrale Sichtbarkeit. Alerts müssen priorisiert sein: WAN down, Path down, Flaps, hohe CRC/Drops, CPU-Spikes, VPN down.
- Syslog zentral: Interface-, VPN- und Routing-Events
- SNMPv3: CPU/Memory, Interface-Status, Fehlerzähler, Auslastung
- Alerting: korrelieren (z. B. WAN down + VPN down = ein Incident)
Beispiel: Syslog + SNMPv3 Baseline
service timestamps log datetime msec
ntp server 192.0.2.10 prefer
logging buffered 64000 informational
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
snmp-server location "STORE-001"
Rollout-Prozess: Von Pilotfiliale zu Massenausbringung
Ein erfolgreicher Retail-Rollout nutzt einen Pilot (1–3 Filialen), stabilisiert Template und SOP, und skaliert dann in Wellen. Jede Welle folgt dem gleichen Ablauf: Pre-Checks, Umsetzung, Post-Checks, Abnahme, Dokumentation.
- Pilot: Template validieren, Provider-Sonderfälle identifizieren
- Wellen-Rollout: 10–50 Filialen pro Welle, abhängig von Teamkapazität
- Standardisierte Abnahme: POS, VPN, Failover, Monitoring
- Rollback-Plan: definierte Trigger, schnelle Rückkehr auf vorherigen Zustand
Pre-Checks (vor dem Change in der Filiale)
show clock
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show logging | last 50Post-Checks (nach dem Change)
show ip interface brief
show ip nat statistics
show ip nat translations
show crypto ikev2 sa
show crypto ipsec sa
ping 8.8.8.8 repeat 10
traceroute 1.1.1.1Abnahme-Kriterien (Retail-spezifisch)
- POS/Payment: definierte Payment-Tests erfolgreich
- Guest: Internet ok, internes Netz nicht erreichbar
- VPN: SAs stabil, Paketzähler steigen bei Filialtraffic
- Failover: ISP1 Path-Down Test, Umschaltung erfolgreich
- Monitoring: Syslog/SNMPv3 sichtbar, Standort korrekt getaggt
Minimaler Template-Auszug: Golden Config für Retail-Filialen
Dieses Muster bündelt typische Baseline-Elemente für viele Filialen: Hardening, NTP/Syslog, Monitoring und klare Management-Restriktionen. Es ist als Startpunkt gedacht und muss an Ihre Netze/Policies angepasst werden.
hostname R1-STORE-001
no ip domain-lookup
service password-encryption
no ip http server
no ip http secure-server
ip domain-name example.corp
username netadmin privilege 15 secret
crypto key generate rsa modulus 2048
ip ssh version 2
ip access-list standard MGMT_ONLY
permit 10.10.10.0 0.0.0.63
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
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
snmp-server location "STORE-001"
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.
