„NetFlow auf Switches“ ist im Campus ein häufiges Ziel, weil Flow-Daten Antworten auf die wichtigsten Betriebsfragen liefern: Wer spricht mit wem? Welche Applikationen erzeugen Last? Woher kommen Spitzen und Paketverluste? In der Praxis ist NetFlow-Unterstützung auf Switches jedoch stark plattformabhängig: Viele reine Layer-2-Access-Switches können kein klassisches NetFlow für Transit-Traffic, während L3-Switches mit IOS XE oft Flexible NetFlow oder hardwarebasierte Telemetrie unterstützen. Deshalb ist der sinnvollste Ansatz: erst klären, welche Flow-Daten du wirklich brauchst, dann entscheiden, ob NetFlow direkt am Switch möglich ist – oder ob Alternativen wie SPAN, sFlow, IPFIX, Streaming Telemetry oder NetFlow am L3-Gateway die bessere Wahl sind.
Was Flow-Daten leisten: Warum NetFlow so wertvoll ist
SNMP zeigt dir „wie viel“ Traffic fließt, aber nicht „wer“ und „womit“. Flow-Daten liefern genau diese Kontextinformation – ideal für Kapazitätsplanung, Security-Analysen und Troubleshooting.
- Top-Talkers (Quellen/Ziele), Top-Ports/Protokolle
- Application-/Service-Muster (z. B. DNS/SMB/RDP/HTTPS)
- Traffic-Peaks zeitlich und ursächlich erklären
- Security-Use-Cases: Scans, exfiltration patterns, ungewöhnliche Flows
Realität im Campus: Warum „NetFlow am Access-Switch“ oft nicht klappt
Auf Access-Switches läuft Transit-Traffic typischerweise im ASIC (Data Plane). Klassisches NetFlow braucht entweder CPU-Processing oder dedizierte Hardware-Unterstützung für Flow-Export. Viele Layer-2-Switches haben diese Export-Funktion nicht oder nur eingeschränkt.
- L2-Access: wenig bis kein NetFlow für Transit-Frames
- L3-Switch (Distribution): deutlich bessere Chancen (SVIs, Routing, FNF)
- Feature-Verfügbarkeit hängt von Modell, IOS/IOS XE und Lizenz ab
Merksatz
Wenn du „wer spricht mit wem“ im Campus willst, ist der beste Platz oft das L3-Gateway (SVIs) – nicht der reine Access-Switch.
NetFlow, IPFIX, sFlow: Begriffe kurz einordnen
Im Campus werden verschiedene Flow-Technologien genutzt. Für das Design ist wichtig: Sampling vs. unsampled, Export-Format und Plattform-Support.
- NetFlow: Cisco-Origin, mehrere Versionen (v5/v9), häufig auf Routern/L3
- IPFIX: Standardisiertes Flow-Exportformat (ähnlich NetFlow v9)
- sFlow: Sampling-basiert (häufig in Switches), plus Counter-Sampling
Praxisentscheidung
Für „Top-Talkers“ reicht Sampling oft aus. Für Security- oder Accounting-Anforderungen kann unsampled (oder sehr geringes Sampling) nötig sein.
Möglichkeit 1: Flexible NetFlow am L3-Switch (Distribution/Core)
Wenn du im Campus SVIs und Inter-VLAN-Routing auf einem L3-Switch hast, ist das ein idealer Flow-Messpunkt: Du siehst Inter-VLAN-Traffic zentral, ohne jeden Access-Switch zu instrumentieren. Das gilt besonders für IOS XE Plattformen mit Flexible NetFlow.
Konzept: Flows auf SVI oder L3-Uplink erfassen
- Ingress/egress auf VLAN-Interfaces (SVIs) oder Routed Ports
- Export an einen Flow-Collector (z. B. ntopng, Scrutinizer, ElastiFlow)
- Sampling optional, je nach Leistungsfähigkeit
Möglichkeit 2: sFlow im Access (wenn verfügbar)
Wenn dein Access-Switch sFlow unterstützt, ist das oft die pragmatische Alternative zu NetFlow: Du bekommst Stichproben über Traffic, kannst Top-Talkers erkennen und Peaks erklären – ohne vollen Flow-Overhead.
- Sampling-basierte Flows, gut für Kapazitäts- und Top-Talker-Analyse
- Geringere CPU/ASIC-Last als unsampled Flow-Export
- Collector-Unterstützung in vielen Tools vorhanden
Möglichkeit 3: SPAN/Port Mirroring als „Flow-Alternative“
Wenn du kurzfristig einen Engpass, Paketverlust oder einen Security-Verdacht analysieren musst, ist SPAN oft schneller als Flow-Setup. Du siehst echte Pakete (nicht nur Metadaten), aber es ist punktuell und kann bei hoher Last unvollständig sein.
SPAN kurz (Port als Source)
configure terminal
monitor session 1 source interface gigabitEthernet 1/0/10 both
monitor session 1 destination interface gigabitEthernet 1/0/24
end
Wann SPAN besser ist als Flow
- Fehleranalyse (Retransmits, MTU, TCP-Handshake, ARP/IGMP)
- Security-Forensik im kleinen Scope
- Wenn Flow-Export nicht unterstützt wird
Möglichkeit 4: SNMP + Syslog + „smarte“ Gegenmaßnahmen (oft ausreichend)
Für viele Campus-Use-Cases brauchst du keine vollständigen Flows. Wenn du Uplink-Traffic (SNMP), Errors/Drops und Events (Syslog) sauber hast, kannst du die meisten Betriebsprobleme bereits sehr gut lösen. Flows sind dann ein „Deep Dive“-Werkzeug.
- SNMP: Traffic, Utilization, Errors/Drops, CPU/Memory
- Syslog: Flaps, STP/Guards, Security Drops, PoE Faults
- Ergänzend: QoS Stats für Congestion-Klassen
Entscheidungslogik: Wo du Flow-Daten im Campus am sinnvollsten erhebst
Wähle den Messpunkt so, dass du mit minimaler Komplexität maximalen Nutzen bekommst. In den meisten Campus-Designs ist das Distribution/Core (SVIs), nicht der einzelne Edge-Port.
- Inter-VLAN Analyse: Flows am L3-Gateway (SVIs) ideal
- Internet/DMZ: Flows an Firewall/Edge-Router (häufig ohnehin vorhanden)
- Einzelner Client/Port: SPAN gezielt
- Access-Top-Talkers: sFlow, wenn Switch es kann
Risiken und Grenzen: Performance, Datenschutz, Betrieb
Flow-Daten sind mächtig, aber bringen Overhead und Governance-Themen. Plane Speicher, Retention und Zugriffsrechte. Außerdem kann unsachgemäßer Export CPU belasten, besonders bei zu vielen Interfaces oder zu geringer Sampling-Rate.
- CPU/ASIC-Overhead durch Flow-Export (plattformabhängig)
- Collector-Last und Speicherbedarf
- Datenschutz/Compliance: „wer spricht mit wem“ ist sensibel
- Change-Risiko: falsche Konfig kann Monitoring/Control beeinflussen
Verifikation: Wie du prüfst, ob dein Switch Flow-Features bietet
Bevor du planst, prüfe die verfügbaren Kommandos. Wenn dein Switch weder Flexible NetFlow noch sFlow bietet, sind SPAN oder Messung am L3-Gateway die realistischen Alternativen.
Kommandos/Feature-Hinweise suchen (plattformspezifisch)
show running-config | include flow|netflow|ipfix|sflow
show platform software
show version
Best Practices: Flow-Transparenz im Campus ohne Overengineering
Ein robustes Campus-Setup nutzt Flow-Daten dort, wo sie am meisten bringen: am L3-Gateway und an den Edge-Übergängen. Am Access setzt du eher auf SNMP/Syslog und gezielten SPAN, statt jeden Switch mit Flow-Export zu belasten.
- Flows bevorzugt am Distribution/Core (SVIs) oder Edge-Router/Firewall
- Sampling (sFlow/IPFIX) für Top-Talker, unsampled nur bei Bedarf
- SPAN für punktuelle Deep-Dive-Analysen
- SNMP + Syslog als Baseline, QoS-Stats bei Congestion
- Governance: Retention, Zugriff, Datenschutz sauber definieren
copy running-config startup-config
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.
