Back
Lesson 6 of 6

Security Visibility with AI

Objective

In this lesson you will configure and verify security visibility features that enable an AI-driven security analytics platform to detect threats across the network. We will enable device telemetry and traffic export (syslog + NetFlow) so the analytics platform has the telemetry and flow data required for context-aware threat detection. In production networks this kind of visibility is used to correlate device logs and flow records for anomaly detection, rapid incident investigation, and feeding ML/AI models with rich telemetry.

Real-world scenario: A campus edge router forwards user traffic to the Internet. Security teams need full visibility into flows and device events so an analytics platform can detect unusual lateral movement or data exfiltration. By exporting syslog and NetFlow to the analytics platform, you provide the required raw data for real-time ML/AI detection and historical forensic analysis.

Quick Recap

This is Lesson 6 of 6 in Lab 38: AIOps for Network Security. Refer to the topology used in Lesson 1 for core connectivity and addressing. This lesson adds one new device — the Security Analytics Platform (SAP) — and configures the edge router to export telemetry.

New device added in this lesson:

  • Security Analytics Platform (SAP) — IP: 10.0.0.100/24 (consumes syslog on UDP/514 and NetFlow v9 on UDP/9995)

All other devices and addressing remain unchanged from Lesson 1.

ASCII topology (exact IPs and interfaces for this lesson):

R1 is the edge router that connects the LAN to the Internet and exports telemetry to the analytics platform.

                Internet
                   |
           +---------------+
           |   R2 (Core)   |
           |               |
           +------|--------+
                  |
          192.168.0.2/30
                  |
          192.168.0.1/30
           +---------------+
           |   R1 (Edge)   |
           | hostname: R1   |
           | Gi0/0: 10.0.0.1/24 (LAN)  |
           | Gi0/1: 192.168.0.1/30 (to R2) |
           +---------------+
                  |
                  | 10.0.0.100/24
           +---------------+
           |  SAP (Analytics) |
           |  IP: 10.0.0.100  |
           +---------------+

Notes:

  • Exact interface names on R1 used in this lesson: GigabitEthernet0/0 (LAN), GigabitEthernet0/1 (to core).
  • Analytics platform FQDN examples should use the lab domain: sap.lab.nhprep.com

Device Table

DeviceHostnameRelevant IPs
Edge RouterR1Gi0/0: 10.0.0.1/24, Gi0/1: 192.168.0.1/30
Core RouterR2GiX: 192.168.0.2/30
Security Analytics PlatformSAPeth0: 10.0.0.100/24

Key Concepts (theory + packet behavior)

  • Syslog export for event telemetry

    • Theory: Syslog delivers device-generated event messages (interface up/down, security events, authentication failures). The router encapsulates syslog messages in UDP (default) and sends them to a centralized collector.
    • Packet flow: When an event occurs, the router sends a UDP/514 packet to the collector IP with the RFC3164/5424 formatted message. The collector timestamps and indexes events for ML analysis.

  • NetFlow v9 export for flow telemetry

    • Theory: NetFlow records summarize traffic flows (source/destination IP, ports, bytes, packets, timestamps) and are exported to a collector in UDP datagrams (NetFlow v9 is template-based). AI models use flows to identify anomalies like unusual ports, asymmetric routing, or application-level changes.
    • Packet flow: The router aggregates active flows into an export buffer and periodically sends NetFlow packets (templates + flow records) to the collector UDP port.

  • Why both syslog and flow matter

    • Flow gives "what conversations are happening" (who talked to whom, how much), while syslog gives "what events occurred" (authentication, errors, ACL denies). Together they provide context for threat detection and reduce false positives in ML models.

  • Data age and use case

    • Real-time detection requires flow and event ingestion within seconds to minutes. Historical forensic analysis relies on archives of flow and log data. Ensure your export/transmit intervals match detection SLAs.

Tip: Think of syslog as the device’s diary entries and NetFlow as a ledger of conversations. AI uses both to answer “what happened” and “who talked to whom”.

Step-by-step configuration

Step 1: Configure device identity and management domain

What we are doing: Set an explicit hostname and domain for the router so logs and certificates (if used later) include meaningful metadata. This helps the analytics platform attribute events to the correct device.

R1> enable
R1# configure terminal
R1(config)# hostname R1
R1(config)# ip domain-name lab.nhprep.com
R1(config)# exit
R1#

What just happened:

  • hostname R1 sets the device name used in prompts and included in syslog messages.
  • ip domain-name lab.nhprep.com sets the DNS domain appended to hostnames for FQDNs and can be used in certificate generation. In telemetry, consistent hostnames help the analytics platform map events to inventory.

Real-world note: In production, consistent hostnames and domains allow automatic asset discovery and reduce mapping errors in the analytics system.

Verify:

R1# show running-config | include hostname|ip domain-name
hostname R1
ip domain-name lab.nhprep.com

Expected output shows the configured hostname and domain exactly as above.

Step 2: Configure syslog export to the Security Analytics Platform

What we are doing: Enable syslog and point the router to send device event messages to the analytics server at 10.0.0.100. We also select the severity level to send — informational and above — to ensure events relevant to security are collected without excessive noise.

R1# configure terminal
R1(config)# logging host 10.0.0.100 transport udp port 514
R1(config)# logging trap informational
R1(config)# logging source-interface GigabitEthernet0/0
R1(config)# exit
R1#

What just happened:

  • logging host 10.0.0.100 transport udp port 514 configures the remote syslog collector address and the UDP destination port. Syslog messages will be sent to UDP/514 to that IP.
  • logging trap informational sets the minimum severity level to send (informational = level 6). Events of severity 6 and lower (0–6) will be forwarded.
  • logging source-interface GigabitEthernet0/0 ensures the source IP of syslog packets is the interface IP on the LAN (10.0.0.1), avoiding asymmetric source addresses that can confuse the collector.

Real-world note: Use logging source-interface to maintain consistent source IPs for accurate asset identification and to ensure firewall ACLs permit collector traffic.

Verify:

R1# show running-config | section logging
logging host 10.0.0.100 transport udp port 514
logging trap informational
logging source-interface GigabitEthernet0/0

Expected output shows the logging configuration lines above.

Additionally:

R1# show logging
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)
    Console logging: level debugging, 159 messages logged
    Monitor logging: level debugging, 0 messages logged
    Buffer logging: level informational, 0 messages logged
    Exception Logging: size (4096 bytes)
    Count and timestamp logging messages: disabled
Logging to 10.0.0.100  (udp port 514, 0 connections established)
    Logging source-interfaces: GigabitEthernet0/0
    Trap logging: level informational, 5 message lines logged

Expected show output demonstrates that logging to 10.0.0.100 is configured and that the source-interface is set.

Step 3: Enable NetFlow v9 export to the analytics platform

What we are doing: Configure NetFlow (version 9) export toward 10.0.0.100 UDP port 9995, and enable flow accounting on the ingress interface so flow records are generated. NetFlow provides the analytics platform with conversation metadata needed for ML detection.

R1# configure terminal
R1(config)# ip flow-export destination 10.0.0.100 9995
R1(config)# ip flow-export version 9
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip flow ingress
R1(config-if)# exit
R1(config)# exit
R1#

What just happened:

  • ip flow-export destination 10.0.0.100 9995 sets the NetFlow collector IP and UDP port. The router will export NetFlow datagrams to that destination.
  • ip flow-export version 9 selects the template-based NetFlow v9 format (commonly used by analytics platforms because it is extensible).
  • ip flow ingress on GigabitEthernet0/0 enables flow record generation for packets entering that interface. Each unique combination of source/destination IP/port/etc. will be tracked as a flow and later exported.

Real-world note: Choose the correct interface(s) for flow accounting — enabling flow on all interfaces may overload CPU on busy routers. In many designs you instrument edge and aggregation points where flows are aggregated.

Verify:

R1# show ip flow export
Flow exporter: to 10.0.0.100  9995
  Active exports: 0
  Export format: NetFlow Version 9
  Flow export template timeout: 60 secs
  Flow export timeout: 60 secs
  Source IP address for export: GigabitEthernet0/0 (10.0.0.1)
  Destination host is 10.0.0.100

Expected output shows exporter destination, format, timeouts, and the source IP used for exports.

Also verify interface flow configuration:

R1# show running-config interface GigabitEthernet0/0 | include ip flow
 ip flow ingress

Expected output indicates ip flow ingress is enabled on Gi0/0.

Step 4: Generate a synthetic event and test end-to-end ingestion

What we are doing: Create a test syslog event (e.g., shut/no shut an interface) and generate a small flow (ping) to create NetFlow records. This tests that logs and flows are exported and that the SAP can receive them.

R1# configure terminal
R1(config)# interface GigabitEthernet0/0
R1(config-if)# shutdown
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# exit
R1# ping 10.0.0.100 source 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100, timeout is 2 seconds:
.!!!!
R1#

What just happened:

  • Shutting and bringing the interface back up creates syslog events (link down/link up) that should be forwarded to the analytics platform.
  • The ping to 10.0.0.100 generates actual packets that are seen as flows; NetFlow will generate flow records and export them to the collector.

Real-world note: In production, you would not use active interface flaps to test — use controlled simulated events or test traffic during maintenance windows.

Verify syslog transmission:

R1# show logging
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)
    Logging to 10.0.0.100  (udp port 514, 0 connections established)
    Logging source-interfaces: GigabitEthernet0/0
    Recent events:
    Mar  1 12:30:01 R1 %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to administratively down
    Mar  1 12:30:03 R1 %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up

Expected output contains the recent link down/up events — these messages are the same events that would have been exported.

Verify NetFlow export / cache:

R1# show ip cache flow
IP header version 4 (count 1): 1
 Protocol  SrcIf  SrcIPaddress    DstIPaddress    Pr SrcP DstP Pkts   Bytes Firstt          Lastt
 ------  ------  --------------  --------------  -- ----- ----- ----- ------- ---------- ----------
 1       Gi0/0   10.0.0.1        10.0.0.100      1  0     0     1      84     00:00:02       00:00:02

R1# show ip flow export
Flow exporter: to 10.0.0.100  9995
  Active exports: 1
  Export format: NetFlow Version 9
  Flow export template timeout: 60 secs
  Flow export timeout: 60 secs
  Source IP address for export: GigabitEthernet0/0 (10.0.0.1)
  Destination host is 10.0.0.100

Expected show ip cache flow shows at least the ping flow from 10.0.0.1 to 10.0.0.100. show ip flow export shows an active export count.

Verification Checklist

  • Check 1: Syslog messages are configured and the source IP is correct. Verify with show running-config | section logging and show logging.
  • Check 2: NetFlow v9 exporter is configured with destination 10.0.0.100 and the correct source IP. Verify with show ip flow export and show running-config | include ip flow-export.
  • Check 3: Flow cache contains recent records after test traffic and at least one active export. Verify with show ip cache flow and show ip flow export.

Common Mistakes

SymptomCauseFix
Analytics server receives no syslog messagesNo logging host configured or wrong destination IP/portConfigure logging host <IP> transport udp port 514 and verify network reachability to collector IP
Analytic platform shows flows from unexpected IPRouter used wrong source IP for NetFlow/syslog (e.g., loopback)Set logging source-interface and ensure Source IP address for export is the intended interface
NetFlow exports show Active exports: 0Templates not sent or exporter misconfigured (wrong version/port)Configure ip flow-export version 9 and correct ip flow-export destination <IP> <port>; verify UDP reachability
High CPU after enabling NetFlow on all interfacesFlow accounting enabled on very busy interfacesEnable ip flow only on aggregation/edge interfaces or use sampling where supported
No flows shown in show ip cache flow after test trafficFlow capture not enabled on the interface (no ip flow ingress)Enable ip flow ingress or ip flow egress on relevant interface and retest traffic

Key Takeaways

  • Use both syslog and NetFlow exports to provide event and flow telemetry; AI-driven analytics needs both to correlate context and reduce false positives.
  • Configure logging source-interface and verify source IPs so collectors can reliably map data to devices.
  • Use NetFlow v9 (template-based) when feeding modern analytics platforms; ensure correct destination IP and UDP port and enable flow capture only where needed to reduce resource usage.
  • Test end-to-end by generating controlled events and test traffic, and verify with show logging, show ip flow export, and show ip cache flow.

Important: In production, plan capacity and retention with your analytics team — telemetry volume grows quickly. Use sampling, selective instrumentation, and appropriate log levels to balance visibility and resource constraints.

If you completed all verification checks, you have successfully enabled security visibility for AI-assisted detection in the lab environment. In the next step (out of scope for this lesson) you would configure the analytics platform to parse the incoming NetFlow and syslog messages and enable ML models or detection rules to start producing alerts.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security