Netzwerk & Monitoring

Enterprise Netzwerk-Architektur

Moderne Rechenzentren und Campus-Netzwerke erfordern skalierbare, redundante Architekturen, die sowohl East-West- als auch North-South-Traffic effizient verarbeiten. Die Spine-Leaf-Topologie hat das klassische Three-Tier-Modell (Core/Distribution/Access) weitgehend abgelöst und bietet vorhersagbare Latenz, einfache Skalierung und optimale Bandbreitenauslastung.

• Spine-Leaf-Architektur — Design-Prinzipien: Jeder Leaf-Switch ist mit jedem Spine-Switch verbunden (Full-Mesh zwischen den Schichten). Skalierung: neue Leafs hinzufügen erhöht Ports, neue Spines erhöhen Bandbreite. ECMP (Equal-Cost Multi-Path) verteilt den Traffic über alle verfügbaren Uplinks. Typisches Design: 4 Spine-Switches (je 100 GbE) und 20+ Leaf-Switches (48x 25 GbE + 8x 100 GbE Uplink). BGP im Underlay mit EVPN/VXLAN im Overlay für Layer-2-Erweiterung über Layer-3-Grenzen hinweg.
• VLAN-Design & 802.1Q Trunking: VLANs segmentieren Broadcast-Domänen und implementieren Sicherheitszonen. Best Practice: Management (VLAN 10), Server (VLAN 20), Clients (VLAN 30), VoIP (VLAN 40), IoT (VLAN 50), Guest (VLAN 99). Trunk-Konfiguration: switchport mode trunk, switchport trunk allowed vlan 10,20,30,40,50,99, switchport trunk native vlan 999 (Unused VLAN als Native). Spanning Tree: RSTP (802.1w) oder MSTP (802.1s) mit explizitem Root-Bridge-Design — spanning-tree vlan 1-4094 priority 4096 auf dem primären Core-Switch.
• 802.1X Network Access Control: Portbasierte Authentifizierung verhindert den Zugang unbefugter Geräte. Architektur: Supplicant (Endgerät) → Authenticator (Switch) → Authentication Server (RADIUS/FreeRADIUS/NPS). Switch-Konfiguration: dot1x system-auth-control, interface GigabitEthernet0/1: dot1x port-control auto, authentication order dot1x mab, authentication host-mode multi-auth. MAB (MAC Authentication Bypass) als Fallback für Geräte ohne 802.1X-Support (Drucker, IoT). Dynamic VLAN Assignment via RADIUS-Attribut Tunnel-Private-Group-ID.
• Netzwerk-Automatisierung mit Ansible & Netbox: Manuelle Switch-Konfiguration skaliert nicht. Ansible Network Modules ermöglichen deklaratives Konfigurationsmanagement: ansible-playbook -i netbox_inventory.yml deploy-vlans.yml --diff --check (Dry-Run). Netbox als Single Source of Truth für IP-Adressen (IPAM), Geräte-Inventar und Kabelmanagement. NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) für Konfigurationsvergleich: napalm-cli --user admin --vendor ios call get_config. Git-basiertes Config-Backup: Änderungen automatisiert committen und Compliance-Drift erkennen.

Network Monitoring im Enterprise-Umfeld

Proaktives Monitoring ist die Grundlage für Verfügbarkeit und Performance. Die Wahl des Monitoring-Systems hängt von Netzwerkgröße, Budget und Integrationsanforderungen ab. Open-Source-Lösungen wie Zabbix und LibreNMS bieten Enterprise-Funktionalität ohne Lizenzkosten, während PRTG und Nagios XI mit out-of-the-box Usability punkten.

• Zabbix — Skalierbare Open-Source-Plattform: Zabbix überwacht Netzwerk, Server, Cloud und Applikationen mit einer einheitlichen Plattform. Architektur: Zabbix Server + PostgreSQL Backend + Zabbix Proxies für verteiltes Monitoring. Installation: apt install zabbix-server-pgsql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent2. Auto-Discovery: Configuration > Discovery > IP Range 10.0.0.0/24, SNMP v3 Checks. Template-System: 800+ vorgefertigte Templates für Cisco, HP, Dell, Linux, Windows. LLD (Low-Level Discovery) erkennt automatisch neue Interfaces, Filesystems und Services.
• PRTG Network Monitor — Windows-zentriertes Monitoring: PRTG bietet eine intuitive Web-Oberfläche mit über 250 vordefinierten Sensor-Typen. Lizenzierung: per Sensor (Freeware bis 100 Sensoren). Stärken: WMI-Integration für tiefes Windows-Monitoring, NetFlow/sFlow-Analyse, Bandwidth Monitoring, VMware/Hyper-V-Sensoren. Remote Probes ermöglichen Monitoring über WAN-Grenzen hinweg. REST-API: https://prtg-server/api/table.json?content=sensors&filter_status=5&username=api&passhash=xxx für Alerting-Integration.
• LibreNMS — Auto-Discovering Network Management: LibreNMS ist ein Fork von Observium und bietet vollautomatisches SNMP-Discovery, Alerting und Performance-Graphing. Stärke: Oxidized-Integration für automatisiertes Config-Backup aller Netzwerkgeräte. Deployment: ./lnms device:add 10.0.0.1 --v3 --auth-name monitoring --auth-pass secret123 --priv-pass priv456 --auth-proto SHA --priv-proto AES. Weathermap-Plugin visualisiert Bandbreitenauslastung auf Netzwerk-Diagrammen in Echtzeit. API-Anbindung an Netbox für bidirektionale Inventarsynchronisation.
• Alerting-Strategie & Eskalation: Effektives Alerting vermeidet Alert Fatigue durch mehrstufige Eskalation und intelligente Gruppierung. Zabbix-Trigger-Hierarchie: Warning (Interface Utilization >70 %) → High (Utilization >90 %) → Disaster (Interface Down). Maintenance-Windows unterdrücken Alerts während geplanter Wartung. Benachrichtigungskanäle: E-Mail für Low Priority, Microsoft Teams Webhook für Medium, PagerDuty/SMS für Critical. Eskalationszeiten: 5 Min (L1-Admin) → 15 Min (L2-Team) → 30 Min (Teamleiter). Zabbix Action: Operations > Send to Teams > Recovery: Resolved.

SNMP v3 & moderne Telemetrie

SNMP (Simple Network Management Protocol) bleibt das Fundament des Netzwerk-Monitorings, wobei v3 mit Authentifizierung und Verschlüsselung die Sicherheitsmängel von v1/v2c behebt. Parallel dazu gewinnen Streaming-Telemetrie-Protokolle (gNMI, gRPC) an Bedeutung, die Push-basierte Echtzeit-Daten liefern statt Poll-basierter SNMP-Abfragen.

• SNMP v3 — Sichere Konfiguration: SNMPv3 bietet drei Sicherheitsstufen: noAuthNoPriv (nur Username), authNoPriv (HMAC-SHA-256 Authentifizierung), authPriv (+ AES-256 Verschlüsselung). Produktionskonfiguration (Cisco IOS): snmp-server group MONITORING v3 priv, snmp-server user zabbix MONITORING v3 auth sha256 AuthPass123! priv aes 256 PrivPass456!. Wichtig: Community Strings (v2c) aus allen Geräten entfernen — no snmp-server community public. Access-Listen beschränken SNMP-Zugriff auf Monitoring-Server: snmp-server group MONITORING v3 priv access SNMP-ACL.
• NetFlow v9 / IPFIX — Traffic-Analyse: NetFlow exportiert Flow-Records (Src/Dst IP, Ports, Protocol, Bytes, Packets) für Bandbreiten-Analyse und Security-Forensik. Router-Konfiguration: ip flow-export version 9, ip flow-export destination 10.0.10.50 2055, interface GigabitEthernet0/0: ip flow ingress, ip flow egress. Collector: ntopng oder Elastiflow. IPFIX (IP Flow Information Export) erweitert NetFlow um flexible Templates und Enterprise-spezifische Information Elements. Typische Analyse: Top-Talker, Application-Mix, Anomalie-Erkennung (plötzlicher Traffic-Anstieg = DDoS oder Datenexfiltration).
• Streaming Telemetrie — gNMI & gRPC: Model-Driven Telemetry ersetzt Polling durch Subscriptions: das Netzwerkgerät pushed Änderungen in Echtzeit zum Collector. gNMI (gRPC Network Management Interface) nutzt YANG-Datenmodelle und Protocol Buffers. Konfiguration (Arista EOS): management api gnmi transport grpc default port 6030. Subscription via gnmic: gnmic -a 10.0.0.1:6030 subscribe --path "/interfaces/interface/state/counters" --stream-mode sample --sample-interval 10s. Vorteile: Millisekunden-Granularität, geringere CPU-Last auf dem Gerät, native Integration in InfluxDB/Prometheus.
• MIB-Management & OID-Referenz: SNMP-Daten werden über Object Identifiers (OIDs) adressiert, die in MIB-Dateien (Management Information Base) definiert sind. Wichtige Standard-OIDs: .1.3.6.1.2.1.1.1.0 (sysDescr), .1.3.6.1.2.1.2.2.1.10 (ifInOctets), .1.3.6.1.2.1.2.2.1.16 (ifOutOctets), .1.3.6.1.2.1.31.1.1.1.6 (ifHCInOctets — 64-Bit Counter für 10G+). Hersteller-MIBs importieren: snmptranslate -M +/usr/share/snmp/mibs/vendor -m ALL -Tp. Zabbix: MIB-Import über Administration > General > MIB Upload für automatisierte Template-Generierung.

QoS & Traffic Shaping

Quality of Service (QoS) stellt sicher, dass geschäftskritische Anwendungen (VoIP, Video, ERP) auch unter Last zuverlässige Bandbreite, geringe Latenz und minimalen Jitter erhalten. Die Implementierung folgt dem DiffServ-Modell mit DSCP-Markierung am Netzwerkrand und Per-Hop-Behavior (PHB) auf allen Transit-Switches.

• DiffServ & DSCP-Klassifikation: Differentiated Services nutzt das 6-Bit DSCP-Feld im IP-Header für Traffic-Klassifizierung. Standard-Markierungen: EF (Expedited Forwarding, DSCP 46) für VoIP, AF41 (DSCP 34) für Video-Conferencing, AF21 (DSCP 18) für Business-Critical Data, CS1 (DSCP 8) für Bulk/Backup, BE (DSCP 0) für Best Effort. Markierung am Access-Switch: class-map match-all VOICE: match ip dscp ef, policy-map QOS-POLICY: class VOICE: priority 1000. Trust Boundary: DSCP-Markierungen nur von vertrauenswürdigen Geräten akzeptieren, sonst re-markieren.
• Queuing-Mechanismen — LLQ, CBWFQ, WFQ: Low Latency Queuing (LLQ) kombiniert Priority Queuing für Echtzeit-Traffic mit Class-Based Weighted Fair Queuing (CBWFQ) für den Rest. Konfigurationsbeispiel: policy-map WAN-QOS: class VOICE: priority percent 15, class VIDEO: bandwidth percent 25, class BUSINESS: bandwidth percent 30, class SCAVENGER: bandwidth percent 5, class class-default: fair-queue. Wichtig: Priority Queue auf maximal 33 % der Link-Bandbreite begrenzen, um Starvation anderer Klassen zu vermeiden. Outbound-Policy auf WAN-Interfaces anwenden: service-policy output WAN-QOS.
• Traffic Shaping & Policing: Shaping buffers überschüssigen Traffic und sendet ihn verzögert (geeignet für Outbound auf WAN-Links), Policing verwirft oder re-markiert überschüssigen Traffic sofort (geeignet für Inbound). Shaper-Konfiguration für 100 Mbit/s WAN: policy-map SHAPE-100M: class class-default: shape average 100000000 service-policy WAN-QOS (hierarchisches QoS). OPNsense Traffic Shaping: Firewall > Shaper > Pipes: Bandwidth 100 Mbit/s, Queues: Weight-basierte Verteilung. CoDel/FQ-CoDel als Active Queue Management gegen Bufferbloat.
• VoIP-spezifisches QoS-Design: VoIP erfordert maximale One-Way-Delay von 150 ms, Jitter unter 30 ms und Packet Loss unter 1 %. Bandbreitenberechnung: G.711 = 87,2 kbit/s pro Call (mit L2-Overhead), G.729 = 31,2 kbit/s. Für 50 gleichzeitige G.711-Calls: 4,36 Mbit/s reservieren. Dediziertes Voice-VLAN (802.1p CoS 5 = DSCP EF) mit LLDP-MED für automatische VLAN-Zuweisung an IP-Telefone. Switch-Port: switchport voice vlan 40, mls qos trust dscp. Monitoring: show mls qos interface statistics — Dropped Packets in der Priority Queue deuten auf Unter-Dimensionierung hin.

Wi-Fi 6E/7 Enterprise Design

Enterprise-WLAN-Design erfordert eine systematische Planung von Abdeckung, Kapazität und Roaming-Verhalten. Wi-Fi 6E (802.11ax im 6-GHz-Band) und Wi-Fi 7 (802.11be) bieten erheblich mehr Spektrum und höhere Datenraten, erfordern aber angepasste Kanalplanung und Sicherheitskonfiguration.

• Site Survey & AP-Platzierung: Professionelle WLAN-Planung beginnt mit einem predictive Site Survey (Ekahau, iBwave) und wird durch einen Post-Installation Validation Survey verifiziert. Faustregeln: ein AP pro 20–30 Benutzer (High Density), Zellenabdeckung mit -67 dBm Signalstärke am Zellenrand, Channel Overlap <20 %. 6-GHz-Planung: kürzere Reichweite als 5 GHz (höhere Freiraumdämpfung), dafür 59 zusätzliche 20-MHz-Kanäle ohne Legacy-Geräte. AP-Montage: 2,5–3,5 m Höhe, Antennen nach unten gerichtet, Abstand zu Metalldecken mindestens 15 cm.
• Controller-basierte vs. Cloud-Managed Architektur: On-Premises-Controller (Cisco 9800, Aruba Mobility Controller) bieten maximale Kontrolle und Datenlokalität. Cloud-Managed (Meraki, Aruba Central, UniFi) vereinfachen Multi-Site-Deployments. Hybrid: lokale Forwarding-Plane mit Cloud-Management. Cisco 9800 FlexConnect: ap profile FLEX-PROFILE: flex-connect vlan-name CORP vlan-id 30 — Traffic wird lokal geswitcht, Management über den Controller. Roaming: 802.11r (Fast BSS Transition) + 802.11k (Radio Resource Management) + 802.11v (BSS Transition Management) aktivieren für <50 ms Handover.
• Kanalplanung & RF-Optimierung: 2,4 GHz: nur Kanäle 1, 6, 11 verwenden (nicht überlappend). 5 GHz: DFS-Kanäle nutzen (52–144), um das verfügbare Spektrum zu maximieren — Radar-Detection muss aktiviert bleiben. 6 GHz: 160-MHz-Kanalbreite empfohlen (Kanäle 1, 33, 65, 97, 129, 161, 193), PSC-Kanäle (Preferred Scanning Channels) für schnelles Client-Discovery. Transmit Power: minimale Leistung für Zellenabdeckung verwenden — übermäßige Sendeleistung erhöht Co-Channel-Interferenz. RRM (Radio Resource Management) automatisiert Kanal- und Leistungsanpassung.
• WPA3-Enterprise & RADIUS-Integration: WPA3-Enterprise (192-bit Mode) nutzt CNSA Suite B Kryptographie (GCMP-256, HMAC-SHA-384) und erfordert 802.1X/EAP-TLS mit Zertifikatsauthentifizierung. FreeRADIUS-Konfiguration: eap { default_eap_type = tls, tls { private_key_file = /etc/raddb/certs/server.key, certificate_file = /etc/raddb/certs/server.pem, ca_file = /etc/raddb/certs/ca.pem } }. OWE (Opportunistic Wireless Encryption) für Gastnetzwerke — automatische Verschlüsselung ohne Passphrase. SAE (Simultaneous Authentication of Equals) ersetzt PSK und verhindert Offline-Dictionary-Attacks.

Wireshark Deep-Dive & Troubleshooting

Wireshark ist das mächtigste Werkzeug für Netzwerk-Analyse und Fehlerdiagnose. Die effektive Nutzung erfordert Verständnis von Capture-Methoden, Display-Filtern und Protokoll-Dissektoren. Kombiniert mit tcpdump für Remote-Captures und tshark für automatisierte Analyse bildet es das Rückgrat des Netzwerk-Troubleshootings.

• Capture-Strategien & Mirror Ports: Für Switch-basierte Netzwerke: SPAN/Mirror Port konfigurieren: monitor session 1 source interface Gi0/1 both, monitor session 1 destination interface Gi0/24. Alternativ: Network TAP (Test Access Point) für passive, non-intrusive Captures in Produktionsumgebungen. Remote-Capture mit tcpdump: ssh admin@server "tcpdump -i eth0 -s 0 -w -" | wireshark -k -i -. Capture Filter (BPF) für gezielte Aufzeichnung: host 10.0.0.1 and port 443 reduziert Datenvolumen erheblich. Ring-Buffer für Langzeit-Captures: tshark -i eth0 -b duration:3600 -b files:24 -w /captures/trace.pcapng.
• Display Filter — Essenzielle Syntax: Wireshark Display Filter sind leistungsfähiger als Capture Filter. Wichtige Filter: tcp.analysis.retransmission (Retransmissions), tcp.analysis.zero_window (Bufferüberlauf), dns.time > 0.5 (langsame DNS-Auflösung), http.response.code >= 400 (HTTP-Fehler), tls.handshake.type == 1 (Client Hello — TLS-Verbindungsaufbau). Kombinierte Filter: ip.addr == 10.0.0.1 && tcp.port == 5432 && tcp.analysis.flags (PostgreSQL-Verbindungsprobleme). Farbregeln anpassen: View > Coloring Rules > tcp.analysis.retransmission = Red Background.
• TCP-Analyse & Performance-Diagnose: TCP-Probleme systematisch identifizieren: 1) Statistics > TCP Stream Graphs > Round Trip Time — RTT-Spikes deuten auf Netzwerkengpässe hin. 2) Statistics > TCP Stream Graphs > Throughput — Vergleich mit theoretischem Maximum (BDP = Bandwidth × RTT). 3) Window-Scaling-Probleme: tcp.window_size_value < 8192 bei High-Bandwidth-Links. 4) Expert Info (Analyze > Expert Information) kategorisiert automatisch Warnings, Errors und Notes. Typisches Szenario: TCP Window Full → Zero Window → Window Update — Empfänger kann Daten nicht schnell genug verarbeiten.
• tshark & Automatisierte Analyse: tshark ermöglicht skriptbasierte Paketanalyse. Top-10-Verbindungen nach Volumen: tshark -r capture.pcapng -q -z conv,tcp | sort -k 10 -rn | head -10. DNS-Query-Statistik: tshark -r capture.pcapng -Y "dns.flags.response == 0" -T fields -e dns.qry.name | sort | uniq -c | sort -rn. HTTP-Response-Code-Verteilung: tshark -r capture.pcapng -Y "http.response" -T fields -e http.response.code | sort | uniq -c. Integration in Monitoring: periodische Captures analysieren und Metriken an Zabbix/Prometheus exportieren.

IPv6 Transition & Dual-Stack

Die IPv4-Adresserschöpfung macht IPv6-Transition zur strategischen Notwendigkeit. Dual-Stack bleibt der empfohlene Ansatz für Enterprise-Netzwerke, da er parallelen Betrieb beider Protokolle ermöglicht. Transitional Technologies wie NAT64/DNS64 überbrücken die Koexistenzphase, während pure IPv6-Segmente für neue Deployments genutzt werden.

• Dual-Stack-Implementierung: Dual-Stack aktiviert IPv4 und IPv6 parallel auf allen Interfaces. Router-Konfiguration: interface GigabitEthernet0/0: ip address 10.0.1.1 255.255.255.0, ipv6 address 2001:db8:1::1/64, ipv6 enable. DNS: AAAA-Records parallel zu A-Records pflegen. Happy Eyeballs (RFC 8305) in Clients präferiert IPv6, fällt aber innerhalb 250 ms auf IPv4 zurück, wenn IPv6 nicht erreichbar ist. Firewall: separate Rulesets für IPv4 und IPv6 — oft vergessene IPv6-Regeln ermöglichen Bypass. Monitoring: beide Protokollstacks überwachen, ICMPv6 (insbesondere Neighbor Discovery) nicht blockieren.
• SLAAC vs. DHCPv6: Stateless Address Autoconfiguration (SLAAC, RFC 4862) generiert Adressen aus Router-Prefix + EUI-64 oder Privacy Extensions (RFC 8981). DHCPv6 bietet Stateful Address Assignment und Option für DNS-Server (Option 23), Domain-Search-List und PXE-Boot. Empfehlung: SLAAC + DHCPv6 Stateless (RA M-Flag=0, O-Flag=1) — Adressen via SLAAC, zusätzliche Optionen (DNS, NTP) via DHCPv6. Router-Advertisement: ipv6 nd other-config-flag. Privacy Extensions auf Clients aktivieren für Tracking-Schutz: sysctl net.ipv6.conf.all.use_tempaddr=2.
• NAT64/DNS64 — IPv6-Only-Netzwerke: NAT64 übersetzt IPv6-Pakete in IPv4 für den Zugriff auf IPv4-only-Dienste. DNS64 synthetisiert AAAA-Records für Domains ohne native IPv6-Adresse. Deployment mit Jool (Linux NAT64): modprobe jool pool4 add --tcp 203.0.113.1 1024-65535. DNS64 mit BIND: dns64 64:ff9b::/96 { clients { any; }; };. Well-Known Prefix 64:ff9b::/96 gemäß RFC 6052. Monitoring: NAT64-State-Table überwachen, Session-Limits für einzelne IPv6-Adressen konfigurieren (DoS-Schutz). Langfristziel: native IPv6-Konnektivität für alle Dienste, NAT64 als Fallback.
• IPv6-Sicherheit & NDP-Schutz: IPv6 bringt neue Angriffsvektoren: NDP Spoofing (äquivalent zu ARP Spoofing), Rogue Router Advertisements, Extension Header Abuse. Schutzmaßnahmen: RA Guard auf Access-Switches: ipv6 nd raguard policy HOST-POLICY: device-role host. DHCPv6 Guard analog zu DHCP Snooping. SEcure Neighbor Discovery (SEND, RFC 3971) mit kryptographisch generierten Adressen (CGA). First-Hop Security auf Cisco: ipv6 snooping policy FHS: security-level guard, ipv6 nd inspection policy NDP-INSPECT. IPv6 ACLs: deny ipv6 any any routing-type 0 (Routing Header Type 0 blockieren — bekannter Amplification-Vektor).