Supervised Learning for Networking
Objective
In this lesson you will configure device-level telemetry to support supervised learning workflows for network problems: specifically, setting up NetFlow and SNMP to collect labeled data for classification (predicting link or device failures) and regression (predicting capacity/throughput trends). This matters in production because reliable ML requires consistent, accurate telemetry; without it your models will be trained on noisy or incomplete data and will misclassify failures or under/over-estimate capacity. Real-world scenario: an enterprise wants to predict when a WAN link will saturate (regression) and to classify whether an unusual traffic spike is a DDoS or normal application burst (classification); both require exported flows and interface counters.
Quick Recap
This lesson continues from the topology established earlier (Lesson 1). No new physical devices are added for this lesson — we will configure telemetry on Router R1 and show the matching configuration on R2 where appropriate. The NetFlow collector is a host on the same access network.
ASCII topology (exact IPs on every interface)
+---------+ +------------+
| Host | | R2 |
|(Collector)| <-- 192.168.1.100 -->|Gi0/0 192.168.1.2/24|
| 192.168.1.100/24 | | |
+---------+ +------------+
|
| Access VLAN (192.168.1.0/24)
|
+-------+
| S1 |
|Switch |
+-------+
| |
| |
192.168.1.1/24 192.168.1.2/24
R1 Gi0/0 R2 Gi0/0
+------+ +------+
| R1 | | R2 |
+------+ +------+
Device table
| Device | Interface | IP Address |
|---|---|---|
| R1 | GigabitEthernet0/0 | 192.168.1.1/24 |
| R2 | GigabitEthernet0/0 | 192.168.1.2/24 |
| S1 | Access ports to R1, R2, Collector | 192.168.1.0/24 (switching VLAN) |
| Collector | eth0 | 192.168.1.100/24 |
Tip: For telemetry you must ensure the collector is reachable from the exporter. If the exporter cannot reach the collector, export packets will be dropped and you will see zero records.
Key Concepts
- Supervised learning requires labeled historical data: when you export NetFlow and SNMP counters, those raw signals become features; labels come from ticketing systems, maintenance logs, or synthesized events. In production, integrate telemetry timestamps with incident labels.
- NetFlow (Flexible NetFlow) collects per-flow records and exports them over UDP/TCP to a collector. The exporter assembles records from the flow cache and sends them periodically (export packets). If the collector is unreachable, those exports are lost — there is no built-in guaranteed delivery over UDP.
- SNMP provides scalar counters (ifInOctets, ifOutOctets, ifInErrors) useful for long-term trend regression. SNMP counters are polled on intervals to derive rates. Polling frequency affects time-series resolution and model accuracy.
- Sampling & cache timeout matter: shorter cache timeouts create more frequent exports and higher collectors load but better temporal resolution for ML labels; sampling reduces collector load at a cost of representativeness.
- Think of NetFlow as a “camera” that captures each conversation between endpoints; SNMP is like a “speedometer” recording vehicle throughput. Both together give ML models both detailed per-flow behavior (for classification) and aggregated rates (for regression).
Step-by-step configuration
Step 1: Configure interface IPs on R1 and R2
What we are doing: Assign IP addresses so devices (R1, R2, Collector) are reachable and the collector can receive NetFlow exports. Connectivity is a prerequisite for telemetry.
R1# configure terminal
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# exit
R2# configure terminal
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip address 192.168.1.2 255.255.255.0
R2(config-if)# no shutdown
R2(config-if)# exit
R2(config)# exit
What just happened: Each router interface was given an IP in the access VLAN. This enables the routers to reach the collector host (192.168.1.100) locally. Interfaces must be up for NetFlow and SNMP to operate on those interfaces.
Real-world note: In production networks, management/telemetry often runs in a dedicated management VRF or network to isolate monitoring traffic from production flows and avoid overloading production links.
Verify:
R1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 192.168.1.1 YES manual up up
GigabitEthernet0/1 unassigned YES unset administratively down down
Loopback0 unassigned YES unset administratively down down
R2# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 192.168.1.2 YES manual up up
GigabitEthernet0/1 unassigned YES unset administratively down down
Loopback0 unassigned YES unset administratively down down
Step 2: Configure Flexible NetFlow exporter on R1
What we are doing: Create a NetFlow exporter that sends flow records to the collector at 192.168.1.100 over UDP port 2055. This is the channel by which flow data will be delivered to the ML pipeline.
R1# configure terminal
R1(config)# flow exporter NHPREP-EXPORTER
R1(config-flow-exporter)# description Export to NHPREP collector
R1(config-flow-exporter)# destination 192.168.1.100
R1(config-flow-exporter)# transport udp 2055
R1(config-flow-exporter)# exit
R1(config)# exit
What just happened: The flow exporter named NHPREP-EXPORTER is defined with the collector destination and transport protocol. The exporter groups the destination and transport settings that flow monitors will use to send records. Export packets will be sent to 192.168.1.100:2055 using UDP; because UDP is used, exports are not retransmitted if lost.
Real-world note: Use UDP for compatibility with many collectors, but if your collector supports TCP (or TLS-secured transport), prefer reliable transport for critical telemetry.
Verify:
R1# show running-config | section flow exporter
flow exporter NHPREP-EXPORTER
description Export to NHPREP collector
destination 192.168.1.100
transport udp 2055
R1# show flow exporter
Flow exporter: NHPREP-EXPORTER
Destination: 192.168.1.100
Transport: udp 2055
Templates timeout: 300 secs
Flow monitor: N/A
Exporter statistics:
Packets exported: 0
Bytes exported: 0
Templates sent: 0
0 exports failed
Step 3: Create a flow monitor and attach a record, then apply to interface
What we are doing: Define a flow monitor that records IPv4 flows, points it to the exporter, and apply the monitor to the interface so that flows traversing the interface are captured and exported. This is the functional telemetry path.
R1# configure terminal
R1(config)# flow record NHPREP-RECORD
R1(config-flow-record)# match ipv4 source address
R1(config-flow-record)# match ipv4 destination address
R1(config-flow-record)# match transport source-port
R1(config-flow-record)# match transport destination-port
R1(config-flow-record)# collect counter bytes
R1(config-flow-record)# collect counter packets
R1(config-flow-record)# exit
R1(config)# flow monitor NHPREP-MONITOR
R1(config-flow-monitor)# description Monitor for ML dataset
R1(config-flow-monitor)# record NHPREP-RECORD
R1(config-flow-monitor)# exporter NHPREP-EXPORTER
R1(config-flow-monitor)# cache timeout inactive 60
R1(config-flow-monitor)# exit
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip flow monitor NHPREP-MONITOR input
R1(config-if)# ip flow monitor NHPREP-MONITOR output
R1(config-if)# exit
R1(config)# exit
What just happened: A custom flow record (NHPREP-RECORD) was defined to capture source/destination IPs, transport ports, and byte/packet counters — fields useful for ML features. The flow monitor (NHPREP-MONITOR) ties the record to the exporter and sets an inactive cache timeout (how long a flow is kept without activity). Applying the monitor to the interface enables real-time capture of flows entering and leaving that interface.
Real-world note: Select fields in the flow record deliberately — too many fields create large records and put load on exporters and collectors; too few fields may starve your ML features.
Verify:
R1# show flow monitor NHPREP-MONITOR
Flow Monitor: NHPREP-MONITOR
Description: Monitor for ML dataset
Record: NHPREP-RECORD
Exporter: NHPREP-EXPORTER
Cache: IPv4
Cache entries: 0
Cache timeout active: 0 seconds
Cache timeout inactive: 60 seconds
Record flags: None
R1# show flow record NHPREP-RECORD
Flow Record: NHPREP-RECORD
Match: ipv4 source address
Match: ipv4 destination address
Match: transport source-port
Match: transport destination-port
Collect: counter bytes
Collect: counter packets
Step 4: Configure SNMPv2c for interface counters (simple polling)
What we are doing: Enable SNMP community read-only access so a collector or NMS can poll interface counters at a desired sampling interval. SNMP counters are used to compute rates over time and are typical features for regression models predicting capacity.
R1# configure terminal
R1(config)# snmp-server community NHPREP RO
R1(config)# snmp-server location "NHPREP DataCenter"
R1(config)# snmp-server contact "ops@lab.nhprep.com"
R1(config)# exit
What just happened: A read-only SNMP community named NHPREP was configured, allowing SNMPv2c polling. The location and contact strings provide metadata. SNMP allows the collector to poll MIBs such as IF-MIB::ifInOctets and ifOutOctets to compute bitrates over time.
Real-world note: SNMPv2c is simple but insecure; in production use SNMPv3 with authentication and encryption. For lab and model development, SNMPv2c is often used for simplicity.
Verify:
R1# show running-config | include snmp-server
snmp-server community NHPREP RO
snmp-server location NHPREP DataCenter
snmp-server contact ops@lab.nhprep.com
Step 5: Generate test traffic and check flow cache/export behavior
What we are doing: Trigger traffic flows and confirm the flow cache populates and that exporter statistics reflect exports. (In a lab you can generate traffic from the collector or another host via ping, iperf, or synthetic flows.)
R1# show flow monitor NHPREP-MONITOR cache
Cache entries: 1
Flow ID: 0x1a2b3c4d
src-ip: 192.168.1.100
dst-ip: 192.168.1.1
src-port: 50000
dst-port: 80
packets: 10
bytes: 6400
start-time: 00:00:10
last-time: 00:00:12
R1# show flow exporter
Flow exporter: NHPREP-EXPORTER
Destination: 192.168.1.100
Transport: udp 2055
Templates timeout: 300 secs
Exporter statistics:
Packets exported: 1
Bytes exported: 512
Templates sent: 1
0 exports failed
What just happened: The flow monitor cache shows an active flow between the collector and router (e.g., test HTTP or ping flow). The exporter stats indicate at least one export packet was sent to the collector. These records are now available to your collector for labeling and feature extraction for supervised ML tasks.
Real-world note: If you see cache entries but Packets exported remains 0, check reachability to the collector, ACLs blocking UDP 2055, or incorrect exporter destination IP.
Verify (collector side): Confirm the collector receives flow records (this is collector-specific; for example, using a NetFlow collector UI or tcpdump on the collector):
# (Collector) tcpdump -n -i eth0 udp port 2055
13:45:02.123456 IP 192.168.1.1.2055 > 192.168.1.100.12345: UDP, length 512
13:45:02.124567 IP 192.168.1.1.2055 > 192.168.1.100.12345: UDP, length 256
(Collector verification commands are shown conceptually — ensure your collector captures UDP 2055 and shows parsed flows.)
Verification Checklist
- Check 1: Interfaces up — verify with
show ip interface briefand ensure Gi0/0 on R1 is up/up. - Check 2: NetFlow exporter configured and pointing to collector — verify with
show flow exporterand expect Destination 192.168.1.100 and Transport udp 2055. - Check 3: Flow monitor attached to interface and cache has entries after generating traffic — verify with
show flow monitor NHPREP-MONITOR cache. - Check 4: SNMP community present — verify with
show running-config | include snmp-serverand expectsnmp-server community NHPREP RO.
Common Mistakes
| Symptom | Cause | Fix |
|---|---|---|
| No flow records arrive at collector | Exporter destination wrong or collector unreachable | Verify IP reachability (ping), check exporter destination with show flow exporter, correct IP if wrong |
| Flow cache has entries but Packets exported = 0 | UDP to collector blocked by ACL or wrong port | Confirm ACLs and port 2055 allowed, check show access-lists and collector listens on 2055 |
| SNMP polling returns no counters | Community string mismatch or SNMP agent disabled | Check `show running-config |
| Flow monitor attached but cache entries remain 0 after traffic | Monitor applied to wrong interface or record does not match flow | Confirm ip flow monitor is on the correct interface and check flow record match fields |
Key Takeaways
- NetFlow and SNMP are complementary: NetFlow gives per-flow detail (good for classification), SNMP gives time-series counters (good for regression).
- Exporter reachability and transport (UDP 2055 in this lab) are critical — no reachability = no telemetry. Always verify with
show flow exporter. - Choose appropriate flow record fields and cache timeouts for ML needs: more detail and shorter timeouts increase fidelity but also collector load.
- In production, isolate telemetry traffic and prefer secure transports (SNMPv3, reliable export mechanisms) to protect your monitoring pipeline.
Final Tip: When building supervised datasets, always align timestamps from telemetry with labeled events (maintenance windows, alerts) — mismatched timestamps are a leading cause of mislabeled training data and poor model performance.
This lesson prepared the telemetry foundation that the ML team will use to build classification and regression datasets. In the next lesson we will cover feature extraction and labeling best practices for failure prediction and capacity forecasting.