FCP FortiNAC-F Administrator study materials
FCP FortiNAC-F Administrator study resources

FCP FortiNAC-F Administrator: Network Device Integration and SNMP/CLI Modeling

FCP FortiNAC-F Administrator · Work through your exam, one topic at a time.

All guide sections

Network Device Integration and SNMP/CLI Modeling

Domain 2 tests how FortiNAC-F learns the network topology and controls switch ports. Integration is not just adding an IP address: the appliance needs read access for visibility, write or CLI access for enforcement, and the correct device model so that vendor-specific tables and commands are interpreted properly.

Core rules

  • Add each switch, router, wireless controller, or access point as a Network Device. Select the correct vendor and model; the model determines which SNMP OIDs and CLI commands FortiNAC uses.
  • SNMPv2c uses a community string; SNMPv3 uses a username with auth and priv settings. Test from the appliance, and ensure the SNMP view includes bridge, interface, ARP, and VLAN MIBs, not just system MIBs.
  • FortiNAC polls MAC address tables, ARP tables, interface status, and VLAN membership. Traps and syslog speed up link-state and topology changes but do not replace polling.
  • CLI credentials are used for read-only commands, VLAN changes, or port actions when SNMP write is unsupported or disabled. CLI modeling maps prompts and command sequences; a wrong prompt or privilege level breaks automation.
  • Place devices in the correct logical container or network. A device in the wrong container can appear online yet produce no useful endpoint location data.
  • Validate integration with three checks: device status is reachable, the MAC table is populated, and ports show the expected VLANs.

Worked example

An engineer adds a Cisco access switch using SNMPv3 authPriv and SSH. After creating the device with the Cisco model, the engineer tests SNMP and sees the device as reachable, but the MAC table is empty. The SNMPv3 user was restricted to a view that excludes the bridge MIB; the engineer grants read access to the bridge and interface subtrees, then polls again. The MAC table populates, and an endpoint appears on the expected access VLAN. The reasoning: reachability alone proves only that UDP 161 answers; visibility depends on MIB permissions and correct model parsing.

Traps

  • Using a read-only community for an action that requires write access.
  • Assuming a green device status means MAC and VLAN data are complete.
  • Mismatching the CLI prompt or enable mode in the device model.
  • Forgetting that wireless controllers and APs may model client tables differently from switches.
  • Placing a device in the wrong container and then misreading endpoint location.