Home

FortiSwitch SNMP Configuration: The Hidden Architecture of Network Visibility

.

Master FortiSwitch SNMP configuration: CLI commands, firewall policies, and troubleshooting for FortiGate-managed switches.

The Visibility Gap: Why SNMP Monitoring Fails on Managed FortiSwitches

Network operators frequently encounter a perplexing scenario: SNMP polling returns comprehensive data from a FortiGate firewall, yet the FortiSwitch units managed beneath it remain silent. This is not a malfunction—it is a deliberate architectural choice rooted in Fortinet's security-first design philosophy. Understanding the layered configuration requirements reveals why standard SNMP setup procedures fall short and what precise steps restore full monitoring capability.

The Security Fabric's Default Posture

FortiSwitch units managed through FortiLink operate under a distinct security paradigm. Every interface, including the FortiLink trunk connecting switch to controller, inherits a default security policy that restricts management protocols. SNMP traffic, operating over UDP port 161 for queries and 162 for traps, encounters this policy barrier unless explicitly permitted. The consequence: monitoring platforms receive no response from downstream switches despite correct global SNMP declarations on the FortiGate.

This behavior stems from Fortinet's foundational principle: treat every network element as a potential attack surface. Management access is never implicit; it requires intentional, granular authorization. For SNMP visibility across the FortiLink boundary, three configuration layers must align—firewall policy, switch-controller security policy, and SNMP community definitions.

Configuring the Foundation: Firewall Policies for SNMP Transit

Establishing Bi-Directional Access Rules

Stateful firewalls track TCP connections automatically, but SNMP's UDP transport lacks inherent session state. Consequently, administrators must define explicit bidirectional firewall policies to permit SNMP query requests from monitoring servers and trap responses from FortiSwitch units.

A functional policy set includes two rules:

  • Inbound rule: Permits SNMP queries from the monitoring server subnet to the FortiLink subnet
  • Outbound rule: Allows SNMP trap responses from FortiLink-connected devices back to the monitoring server

Both rules must reference the SNMP service object and apply to the appropriate source and destination address objects representing the monitoring infrastructure and FortiLink management subnet. Logging should be enabled initially to validate traffic flow during testing phases.

Subnet Design Considerations

Fortinet utilizes the 169.254.0.0/16 link-local address space for automatic FortiLink addressing. However, Microsoft Windows systems may self-assign addresses in this range upon DHCP failure, creating potential routing conflicts. Best practice dictates carving a dedicated, routable IPv4 subnet exclusively for FortiLink and managed device communication. This isolation simplifies policy definition and prevents unintended exposure of management traffic to general user networks.

Enabling SNMP at the Switch Controller Layer

Global Configuration via FortiGate CLI

SNMP settings applied globally through the FortiGate's switch-controller hierarchy propagate to all managed FortiSwitch units. This approach ensures consistency but requires careful syntax. The configuration sequence involves five distinct components:

  1. Security policy modification: Enable SNMP in the internal-allowaccess or mgmt-allowaccess parameters depending on deployment topology
  2. System information definition: Set descriptive metadata including contact details and physical location
  3. Community string configuration: Define read-only community names, permitted host addresses, and enabled SNMP versions
  4. Trap threshold specification: Establish CPU, memory, and log utilization percentages that trigger event notifications
  5. SNMPv3 user provisioning: Configure authentication and privacy protocols for encrypted management sessions

Local Overrides for Individual Switches

When a specific FortiSwitch requires distinct SNMP parameters, administrators can bypass global settings by configuring the switch directly via its local CLI. This method uses the system snmp configuration tree rather than the FortiGate's switch-controller hierarchy. Local configuration takes precedence over global definitions, enabling tailored monitoring policies for edge deployments or specialized hardware.

Version-Specific Behaviors and Evolution

FortiOS 7.0.x Through 8.0.x: Incremental Enhancements

SNMP implementation on FortiSwitch has evolved across FortiOS releases. Version 7.0 introduced read-only SNMPv3 support with SHA-256 authentication and AES-256 encryption. Subsequent updates expanded trap event coverage:

  • 7.0.2: Added MAC learning limit exceeded notifications
  • 7.2.0: Enabled layer-2 MAC address change traps (additions, deletions, movements)
  • 7.2.1: Introduced hardware health monitoring traps for fan status, power supply changes, and sensor alarms

Administrators upgrading between versions should verify that existing SNMP configurations remain compatible with new event types and that monitoring platforms can parse updated MIB definitions. The FortiSwitch MIB files, downloadable from the FortiGate GUI under System > Config > SNMP, must be recompiled into monitoring tools after firmware upgrades to ensure accurate OID interpretation.

The MIB Dependency

Successful SNMP monitoring requires more than network reachability and credential validation. Monitoring platforms depend on Management Information Base (MIB) files to translate numeric object identifiers into human-readable metrics. Fortinet provides vendor-specific MIBs that describe FortiSwitch system objects, interface statistics, and proprietary trap formats. Failure to load these definitions results in generic or incomplete data presentation, even when SNMP communication succeeds at the protocol level.

Troubleshooting Common Failure Modes

Silent Switches: Diagnosing Unresponsive SNMP Agents

When FortiSwitch units fail to respond to SNMP queries, systematic verification isolates the root cause:

  1. Policy validation: Confirm firewall rules permit UDP/161 and UDP/162 traffic between monitoring server and FortiLink subnet
  2. Access control check: Verify mgmt-allowaccess or internal-allowaccess includes the snmp keyword in the relevant security policy
  3. Community string alignment: Ensure the monitoring platform uses the exact community name and version (v1, v2c, or v3) configured on the FortiGate or switch
  4. Host restriction review: SNMP communities can limit query sources to specific IP addresses; confirm the monitoring server's address is explicitly permitted
  5. MIB compilation audit: Validate that the monitoring tool has loaded the current FortiSwitch MIB files matching the deployed firmware version

Packet captures on the FortiLink interface provide definitive evidence of SNMP traffic flow. Absent query packets indicate routing or policy blocks; unanswered queries suggest agent misconfiguration or host restrictions.

Trap Delivery Failures

SNMP traps operate asynchronously, making delivery issues harder to diagnose than query failures. Key verification steps include:

  • Confirming trap destination addresses match the monitoring server's IP
  • Ensuring the FortiSwitch has network reachability to the trap receiver via the FortiLink subnet
  • Validating that trap thresholds are set below current resource utilization levels to trigger test events
  • Checking that the monitoring platform listens on UDP/162 and has firewall rules permitting inbound trap traffic

Frequently Asked Questions

Can SNMPv3 be used with FortiSwitch units managed by FortiGate?
Yes. FortiSwitch supports SNMPv3 with authentication (MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) and privacy (DES, AES-128, AES-192, AES-256) protocols. Configuration occurs within the switch-controller snmp-user hierarchy on the FortiGate or the system snmp user tree for local switch settings.

Why do SNMP queries succeed on the FortiGate but fail on managed FortiSwitch units?
Global SNMP settings on the FortiGate do not automatically propagate to managed switches. Each FortiSwitch requires explicit SNMP enablement via the switch-controller security policy and community configuration. Additionally, firewall policies must permit SNMP traffic across the FortiLink interface, which carries a default restrictive posture.

How many SNMP trap destinations can be configured per FortiSwitch?
A maximum of eight host addresses may be specified for SNMP trap delivery within a single community configuration. Administrators requiring broader distribution should implement trap forwarding on the monitoring server or deploy multiple community definitions with distinct host lists.

Are FortiSwitch SNMP counters read-only or read-write?
FortiSwitch SNMP implementation is strictly read-only. Monitoring platforms can query system information, interface statistics, and event logs but cannot modify configuration parameters via SNMP set operations. All configuration changes must occur through the FortiGate GUI, CLI, or FortiSwitch Manager.

What MIB files are required for comprehensive FortiSwitch monitoring?
Operators should compile both the core Fortinet MIB and the FortiSwitch-specific MIB into their monitoring platform. These files define OIDs for system metrics, interface counters, environmental sensors, and proprietary trap types. Updated MIBs accompany each FortiOS release and should be reloaded after firmware upgrades to ensure accurate metric interpretation.