IPsec mit IKEv2 ist auf Cisco Routern der moderne Standard für Site-to-Site VPNs: robustes Negotiation-Framework, bessere Security-Defaults und saubere Erweiterbarkeit (z. B. EAP/AAA, Mobility, Rekey). In der Praxis entscheidet jedoch weniger „IKEv2 ja/nein“, sondern das Design: Wie baust du Profile, Authentifizierung und Policy sauber, und welche Implementationsform nutzt du – klassische Crypto Maps oder Route-based…
Routing-Protokoll-Security steht und fällt mit einem Detail, das im Betrieb oft unterschätzt wird: Key-Rollover. OSPF/IS-IS Authentifizierung und BGP MD5/TCP-AO (je nach Plattform) schützen zwar vor Spoofing und Session-Hijacking, aber nur solange Schlüssel aktuell sind. Der Härtungsgewinn verpufft, wenn Keys jahrelang unverändert bleiben – und ein schlecht geplanter Wechsel kann komplette IGP- oder BGP-Outages verursachen. Der…
Route-based VPNs über Virtual Tunnel Interfaces (VTIs) gelten im Enterprise-Betrieb als „skalierbarer“ als klassische Crypto Maps, weil Routing (statt ACL-Selector) bestimmt, welcher Traffic durch den Tunnel geht. Kombinierst du VTIs mit BGP, bekommst du ein sehr robustes Betriebsmodell: dynamische Prefix-Verteilung, saubere Failover-Entscheidungen und weniger Copy/Paste-ACLs pro Peer. Der entscheidende Punkt ist jedoch: VTI+BGP ist nicht…
Logs sind im Netzwerkbetrieb das wichtigste Beweismittel – aber nur, wenn sie vertrauenswürdig sind. Unverschlüsseltes Syslog über UDP ist leicht abhörbar, manipulierbar und kann bei Störungen „still“ ausfallen. Für einen praxisfesten Security-Ansatz brauchst du deshalb drei Säulen: Transport-Sicherheit (Syslog über TLS), verlässliche Zeitbasis (NTP/PTP mit Monitoring) und Maßnahmen für Log-Integrität (Identität, Tamper-Evidence, zentrale Retention). In…
DMVPN (Dynamic Multipoint VPN) ist ein Cisco-Architekturpattern, um viele Standorte über einen Hub-and-Spoke-Tunnelverband zu verbinden, ohne für jeden Spoke einen eigenen statischen Tunnel bauen zu müssen. Kernkomponenten sind GRE over IPsec, mGRE (multipoint GRE) am Hub, NHRP als „Mapping-Datenbank“ (Tunnel-IP ↔ Public-IP) und – je nach Phase – Direktverbindungen (Spoke-to-Spoke) über Shortcut Routing. In der…
Compliance für Netzwerkgeräte scheitert selten an fehlenden Sicherheitsfunktionen, sondern an fehlender Wiederholbarkeit: Konfigurationen driften, Ausnahmen werden nicht dokumentiert, und Audits basieren auf „Screenshots“ statt nachvollziehbaren Checks. Automatisierte Compliance-Checks lösen genau dieses Problem: Du definierst eine Baseline (z. B. CIS-orientiert), prüfst sie regelmäßig gegen die reale Running-Config und erzeugst auditfähige Nachweise (wer/was/waswo/ wann). Der praxisfeste Ansatz…
FlexVPN ist ein modernes Cisco-Designframework für IPsec/IKEv2, das Site-to-Site, Hub-and-Spoke und Remote-Access-Konzepte unter einem einheitlichen Policy- und Profile-Modell zusammenführt. Für Large-Scale Remote Sites ist FlexVPN besonders attraktiv, weil es skalierbare „Single-Template“-Konfigurationen ermöglicht: Spokes werden über IKEv2 Identitäten gematcht, bekommen dynamisch Tunnel-Interfaces (Virtual-Access) und können sauber über Routing (VTI/Route-based) integriert werden. Im Vergleich zu klassischen Crypto…
Ein Security-Incident auf Routern ist anders als ein Server-Incident: Der Router ist gleichzeitig Produktionskomponente, Kontrollpunkt und oft Teil der Angriffskette. Incident Response muss daher zwei Ziele balancieren: Beweise sichern (Forensik) und den Geschäftsbetrieb stabilisieren (Containment/Recovery). Ein gutes Runbook verhindert hektische Aktionen wie „reload“ oder „debug all“, die Beweise zerstören oder die Lage verschlimmern. Stattdessen arbeitest…
QoS in MPLS L3VPN scheitert in der Praxis selten an fehlenden Queues, sondern an inkonsistentem Marking: Ein CE setzt DSCP, der PE mappt falsch auf EXP/TC, der Core behandelt die Bits anders, und am Egress kommt „Best Effort“ an. Sauberes EXP/TC Mapping ist deshalb ein Designproblem: Du definierst wenige, klare Service-Klassen, legst fest, wo klassifiziert…
MPLS Blackholes sind besonders unangenehm, weil sie oft selektiv auftreten: Routing wirkt „gesund“, BGP/OSPF Nachbarn sind up, aber bestimmte Prefixes sind nicht erreichbar oder nur in eine Richtung. Der Grund liegt fast immer in einer Inkonsistenz zwischen Control Plane (RIB/BGP/LDP/SR) und Data Plane (CEF/FIB/LFIB). Ein klassischer Fall: Die IP-Route existiert, aber die Label-Imposition (Push) fehlt…
Got questions? Ideas? Fill out the form below & our specialist will contact you.