14.3 SNMPv1/v2c/v3 Security & Flexible NetFlow (FNF) Architecture

14.3 SNMPv1/v2c/v3 Security & Flexible NetFlow (FNF) Architecture

Core Blueprint Focus: Cisco 350-401 ENCOR v1.2 topic 4.2 requires candidates to configure and verify Flexible NetFlow (FNF), and topic 4.1 names SNMP as a diagnosis tool. Mastery requires evaluating MIBs and OIDs, comparing SNMP versions and operations (Get, Set, Trap vs Inform), configuring SNMPv3 User-Based Security Model (USM) levels (noAuthNoPriv, authNoPriv, authPriv) with View-Based Access Control (VACM), and architecting Flexible NetFlow flow records, flow exporters, flow monitors, and flow samplers.

Modern network assurance architectures require two complementary visibility paradigms: state polling/event signaling (provided by SNMP) and flow-based traffic telemetry (provided by Flexible NetFlow). While SNMP provides discrete device health statistics (CPU utilization, interface counters, power status), NetFlow provides deep statistical accounting of conversation flows traversing the data plane.

1. SNMP Architecture: Managers, Agents, MIBs & OIDs

The Simple Network Management Protocol (SNMP) operates on a client-server paradigm consisting of three architectural components:

1. SNMP Manager (Network Management Station - NMS): Centralized management platform (e.g., Cisco DNA/Catalyst Center, SolarWinds, PRTG) that polls agents and receives asynchronous alerts.
2. SNMP Agent: Software daemon embedded in managed network devices (routers, switches, firewalls) that maintains operational counters and executes commands.
3. Management Information Base (MIB): A structured, hierarchical database residing on the agent that defines all manageable device parameters using Structure of Management Information (SMI) syntax.

+-----------------------------------------------------------------------------------+
|                             SNMP MIB TREE HIERARCHY                               |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|                                    iso (1)                                        |
|                                       |                                           |
|                                    org (3)                                        |
|                                       |                                           |
|                                    dod (6)                                        |
|                                       |                                           |
|                                 internet (1)                                      |
|                                       |                                           |
|             +-------------------------+-------------------------+                 |
|             |                         |                         |                 |
|       directory (1)              mgmt (2)                 private (4)             |
|                                       |                         |                 |
|                                    mib-2 (1)              enterprises (1)         |
|                                       |                         |                 |
|                      +----------------+----------------+     cisco (9)            |
|                      |                |                |        |                 |
|                  system (1)     interfaces (2)       ip (4)  ciscoMgmt (9)        |
|                      |                |                                           |
|                 sysDescr (1)      ifTable (2)                                     |
|                                       |                                           |
|                                   ifEntry (1)                                     |
|                                       |                                           |
|                               +-------+-------+                                   |
|                               |               |                                   |
|                          ifInOctets (10)  ifOutOctets (16)                        |
+-----------------------------------------------------------------------------------+

Object Identifiers (OIDs)

Every variable in a MIB is uniquely addressed by a dot-delimited Object Identifier (OID) representing its sequence of branches from the root node:

• sysDescr: 1.3.6.1.2.1.1.1 (Device hardware, OS version, software description)
• sysUpTime: 1.3.6.1.2.1.1.3 (Time since network management entity was re-initialized)
• ifInOctets: 1.3.6.1.2.1.2.2.1.10.<ifIndex> (32-bit counter of inbound bytes on interface)
• ifHCInOctets: 1.3.6.1.2.1.31.1.1.1.6.<ifIndex> (64-bit high-capacity counter for $\ge 1\text{ Gbps}$ interfaces)

SNMP Protocol Operations & Transport Ports

+-----------------------------------------------------------------------------------+
|                         SNMP PROTOCOL OPERATIONS & PORTS                          |
+-----------------------------------------------------------------------------------+
| Operation        Direction        Port          Description                       |
| --------------   ---------------  ------------  --------------------------------- |
| GetRequest       NMS -> Agent     UDP Port 161  Queries value of specific OID(s). |
| GetNextRequest   NMS -> Agent     UDP Port 161  Walks MIB tree sequentially.      |
| GetBulkRequest   NMS -> Agent     UDP Port 161  Retrieves large MIB tables (v2/v3)|
| SetRequest       NMS -> Agent     UDP Port 161  Modifies writable MIB parameters. |
| GetResponse      Agent -> NMS     UDP Port 161  Returns requested data / error.   |
| SNMP Trap        Agent -> NMS     UDP Port 162  Unsolicited alert (Unreliable).   |
| InformRequest    Agent -> NMS     UDP Port 162  Unsolicited alert (Acknowledged). |
+-----------------------------------------------------------------------------------+

[!IMPORTANT] Trap vs Inform: An SNMP Trap is an unacknowledged UDP notification sent from the agent to the NMS on UDP port 162. If dropped by network congestion, the agent never knows. An SNMP Inform requires the NMS to return an acknowledgment response. If the agent does not receive an acknowledgment, it retransmits the Inform, guaranteeing delivery.

2. SNMP Version Evolution: SNMPv1, v2c & v3 Security Models

+-----------------------------------------------------------------------------------+
|                         SNMP VERSION SECURITY MATRIX                              |
+-----------------------------------------------------------------------------------+
| Feature                 SNMPv1              SNMPv2c             SNMPv3            |
| ---------------------   -----------------   -----------------   ----------------- |
| RFC Specification       RFC 1157            RFC 1901-1908       RFC 3411-3418     |
| Authentication Method   Cleartext Community Cleartext Community Cryptographic HMAC|
|                         String (Password)   String (Password)   MD5 / SHA Hashing |
| Packet Encryption       None (Cleartext)    None (Cleartext)    DES / AES-128/256 |
| 64-Bit Counter Support  No (32-Bit Only)    Yes (ifHC counters) Yes               |
| Bulk Table Retrieval    No (GetNext walk)   Yes (GetBulk)       Yes (GetBulk)     |
| Acknowledged Alerts     No (Traps Only)     Yes (Informs)       Yes (Informs)     |
| Access Control Model    Community String    Community String    VACM (OID Views)  |
+-----------------------------------------------------------------------------------+

Security Vulnerabilities of SNMPv1 and SNMPv2c

Both SNMPv1 and SNMPv2c authenticate transactions using Community Strings (Read-Only [RO] or Read-Write [RW]). Community strings are transmitted across the network in unencrypted plaintext. Any attacker capturing traffic with a network analyzer (Wireshark) can extract the string and execute unauthorized SetRequest operations to alter device configurations or GetRequest queries to map network topology.

3. SNMPv3 User-Based Security Model (USM) & View-Based Access Control (VACM)

SNMPv3 resolves historical vulnerabilities by decoupling identity from passwords through two independent models: USM for authentication/encryption and VACM for granular access control.

User-Based Security Model (USM) Levels

+-----------------------------------------------------------------------------------+
|                         SNMPv3 USM SECURITY TIERS                                 |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  1. noAuthNoPriv (No Authentication, No Privacy):                                 |
|     - Username match only.                                                        |
|     - No hashing, no encryption (Cleartext payload).                              |
|                                                                                   |
|  2. authNoPriv (Authentication, No Privacy):                                      |
|     - Cryptographic authentication via HMAC-MD5, HMAC-SHA-1, or SHA-256.          |
|     - Guarantees message integrity and source identity. No encryption.            |
|                                                                                   |
|  3. authPriv (Authentication and Privacy) [RECOMMENDED]:                          |
|     - Authentication via HMAC-SHA-1 / SHA-256 / SHA-512.                          |
|     - Symmetric encryption via AES (128-bit, 192-bit, or 256-bit) or 56-bit DES.  |
|     - Guarantees complete confidentiality, integrity, and non-repudiation.        |
+-----------------------------------------------------------------------------------+

View-Based Access Control Model (VACM)

VACM controls which MIB subtrees a user or group is authorized to view or modify. An administrator defines a named View containing included or excluded OID branches, and binds that view to a group using read, write, or notify permissions.

4. Flexible NetFlow (FNF) Architecture & Building Blocks

Traditional NetFlow (NetFlow v5) utilized a fixed 7-tuple key to define a flow. Flexible NetFlow (FNF), based on NetFlow Version 9 and the IETF IPFIX (IP Flow Information Export, RFC 7011) standard, allows network engineers to define custom flow records, multiple independent monitors, and flexible export formats.

Definition of a Network Flow

A flow is defined as a unidirectional stream of packets sharing identical Key Fields (match parameters). When a packet arrives, the router inspects its key fields against the active NetFlow cache:

• If a matching entry exists, the router updates the flow's non-key metrics (collect parameters).
• If no matching entry exists, a new flow record is instantiated in the cache.

The Four Modular Building Blocks of FNF

+-----------------------------------------------------------------------------------+
|                         FNF BUILDING BLOCKS BREAKDOWN                             |
+-----------------------------------------------------------------------------------+
| Building Block    CLI Command                     Operational Purpose             |
| ----------------  -----------------------------   ------------------------------- |
| 1. Flow Record    flow record <name>              Defines WHAT to analyze         |
|                                                   (match keys + collect fields)   |
| 2. Flow Exporter  flow exporter <name>            Defines WHERE to send flows     |
|                                                   (Collector IP, Port, Protocol)  |
| 3. Flow Monitor   flow monitor <name>             Binds Record + Exporter + Cache |
|                                                   (Active/Inactive Cache Timers)  |
| 4. Flow Sampler   flow sampler <name>             Defines HOW OFTEN to sample     |
|                                                   (M-out-of-N packet sampling)    |
+-----------------------------------------------------------------------------------+

1. Flow Record: match vs collect Fields

• match Fields (Key Attributes): Criteria used to differentiate one flow from another. Any packet with different match fields creates a separate cache entry:
  • match ipv4 source address / match ipv4 destination address
  • match transport source-port / match transport destination-port
  • match ipv4 protocol
  • match interface input / match interface output
  • match ipv4 tos
• collect Fields (Non-Key Metrics): Telemetry gathered about an existing flow that does not alter flow identity:
  • collect counter bytes long / collect counter packets long
  • collect timestamp sys-uptime first / collect timestamp sys-uptime last
  • collect transport tcp flags
  • collect routing next-hop ipv4 address

2. Flow Exporter: Transport & Export Protocols

• Destination Port: Typically UDP Port 2055 (Standard NetFlow) or UDP Port 4739 (IPFIX RFC 7011).
• Export Formats: export-protocol netflow-v9 (Cisco template-based) or export-protocol ipfix (IETF open standard).
• Template Refresh: Because NetFlow v9 and IPFIX use dynamic templates, exporters periodically resend templates (template data timeout <seconds>, default 1800s) so collectors can decode records correctly.

3. Flow Monitor: Cache Timers

The flow monitor manages the in-memory flow cache:

• Active Cache Timeout (cache timeout active <seconds>): Enforces periodic export for long-lived, continuous flows (such as continuous video streams or large backup transfers). Default is 1800 seconds (30 minutes). Prevents counter overflow and ensures real-time reporting.
• Inactive Cache Timeout (cache timeout inactive <seconds>): Flushes flows that have completed or experienced no traffic for the specified duration. Default is 15 seconds.

4. Flow Sampler: Scaling High-Speed Interfaces

On 40 Gbps, 100 Gbps, and 400 Gbps backbone interfaces, inspecting every single packet in software can overwhelm router CPUs. A Flow Sampler implements statistical sampling (e.g., mode random 1 out-of 1000), analyzing one packet out of every 1,000 to maintain high-fidelity traffic profiling with minimal processing load.

5. Cisco IOS-XE Configuration & Verification CLI

1. SNMPv3 with USM (authPriv) and VACM Configuration

! Step 1: Define MIB View (Permit internet subtree, exclude sensitive Cisco auth)
snmp-server view VIEW_ENCOR internet included
snmp-server view VIEW_ENCOR 1.3.6.1.4.1.9.9.43 excluded

! Step 2: Define SNMPv3 Group bound to View with authPriv enforcement
snmp-server group GRP_NETADMIN v3 priv read VIEW_ENCOR write VIEW_ENCOR access 10

! Step 3: Define SNMPv3 User with SHA authentication and AES-128 encryption
snmp-server user USR_ADMIN GRP_NETADMIN v3 auth sha AuthPass#2026 priv aes 128 PrivPass#2026

! Step 4: Configure SNMPv3 Traps and Informs to NMS Host
snmp-server enable traps
snmp-server host 192.168.100.50 informs version 3 priv USR_ADMIN

2. Flexible NetFlow (FNF) End-to-End Configuration

! Step 1: Define Flow Record with Match (Key) and Collect (Metric) fields
flow record REC_CAMPUS_TRAFFIC
 description Match IPv4 5-Tuple with Timestamps and Byte Counters
 match ipv4 protocol
 match ipv4 source address
 match ipv4 destination address
 match transport source-port
 match transport destination-port
 match interface input
 collect transport tcp flags
 collect counter bytes long
 collect counter packets long
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last

! Step 2: Define Flow Exporter targeting SIEM Collector over IPFIX
flow exporter EXP_STEALTHWATCH
 destination 192.168.100.60
 source Loopback0
 transport udp 2055
 export-protocol ipfix
 template data timeout 60

! Step 3: Define Flow Monitor and Tune Cache Timers
flow monitor MON_CORE_EDGE
 record REC_CAMPUS_TRAFFIC
 exporter EXP_STEALTHWATCH
 cache timeout active 60
 cache timeout inactive 15

! Step 4: Apply Flow Monitor to Interfaces
interface GigabitEthernet0/0/1
 ip flow monitor MON_CORE_EDGE input
 ip flow monitor MON_CORE_EDGE output

3. Verification Commands

Router-1# show snmp user
User name: USR_ADMIN
Engine ID: 800000090300500604200001
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: GRP_NETADMIN

Router-1# show flow monitor MON_CORE_EDGE cache
  Cache type:                               Normal (Platform cache)
  Cache size:                                 4096
  Current entries:                               3
  High Watermark:                                8

  Flows added:                                 142
  Flows aged:                                  139
    - Active timeout      (    60 secs)         12
    - Inactive timeout    (    15 secs)        127

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  IP PROT  bytes long  pkts long
===============  ===============  =============  =============  =======  ==========  =========
10.1.1.50        203.0.113.100            49152            443        6       14520         12
10.1.1.51        198.51.100.20            53210             53       17         140          2
10.1.1.52        10.2.2.10                61200             22        6        8920         18