FortiSwitch Dynamic Port Policies – Is It Best to Use Them for Preliminary Device Classification, or Should We Start with a Statically Configured Network?

Hello everyone,

We’re currently preparing to deploy a larger FortiSwitch environment and are discussing the best way to get started with Dynamic Port Policies.

The environment consists of two FortiSwitch 2048F switches as the core and about 20 access switches. The access switches will connect primarily standard clients, printers, Swyx DECT base stations, Raspberry Pi systems, a total of about 40 FortiAPs, and other IoT Devices. However, the APs are distributed very unevenly across the access switches—some have no APs, while others have five, for example.

Currently, network segmentation is still very straightforward. The majority of the servers, clients, printers, etc., are still all located within the same network 172.16.0.0/16. Although there is already an organizational address allocation within this network—for example, servers are primarily in 172.16.0.x and clients starting at 172.16.100.x—technically, it is still the same network.

A few true VLANs already exist, for example, for Wi-Fi networks, the DMZ, the PV system, and individual special areas.

In the long term, segmentation is to be significantly expanded. FortiClient/ZTNA is planned for managed clients and, if necessary, servers. However, devices without FortiClient—such as printers, DECT base stations, FortiAPs, or other appliances—must, of course, continue to be identified and handled in other ways.

Our initial thought was to configure the access ports entirely statically. However, this raised the question of whether we could already use Dynamic Port Policies as a preliminary device classification.

The idea would be, for example, to define broad classes such as

• Client
• Printer
• DECT
• FortiAP
• Raspberry Pi
• Default/Unknown

In the first phase, Client, Printer, DECT, Raspberry Pi, and even unknown devices would all still be assigned the same current production VLAN. This means that day-to-day network operations would remain virtually unchanged.

From our perspective, the advantage would be that we could already see how reliably Fortinet recognizes the various device types. We could monitor this for some time and check which devices are classified correctly, which ones are not recognized, and where rules might be too general or prone to errors.

Later, for example, we could change only the VLAN policy for the printer class and move these devices to a separate printer VLAN, followed by DECT, clients, and so on.

We would also initially set the default/onboarding VLAN to the current production main VLAN during this learning phase. If a device isn’t recognized, nothing would go down initially. Only once we have sufficient confidence in the classification could the default VLAN be replaced later with a true onboarding or quarantine VLAN.

With the FortiAPs, we’re still unsure what real benefit a dynamic port policy actually provides. For example, if five APs are permanently assigned to a 48-port switch, those five ports must be prepared anyway. In that case, we might as well configure them statically as AP ports. In our view, a dynamic policy would only offer significant added value if APs were to be flexibly connected to different, pre-prepared ports.

Another point of discussion was iSCSI. One colleague views iSCSI as a particularly important device class. However, I would tend to view this as a completely separate matter: To me, iSCSI is a statically planned core/server/storage connection with fixed ports, VLANs, redundancy paths, MPIO, etc., and is not really a suitable candidate for a Dynamic Port Policy at the access layer.

Therefore, I would be particularly interested in hearing from those who have been operating FortiSwitch environments for some time:

Does it make sense to use Dynamic Port Policies even during such a transition phase, even though several device classes will initially still be assigned to the same VLAN?

Would you temporarily use the existing production VLAN as a default/onboarding VLAN to initially focus solely on monitoring detection quality?

Which device classes work reliably in practice via Fortinet Device Detection or LLDP? In particular, experiences with printers, DECT/VoIP devices, and Raspberry Pi or similar appliances would be interesting.

Would you tend to configure permanently installed FortiAPs statically, or would you still map them via Dynamic Port Policies?

And would you also clearly separate iSCSI from this topic and treat it exclusively as a static infrastructure configuration?

Our goal is explicitly not to build a perfect NAC/ZTNA architecture right away. We’d like to start by deploying an access switch configuration that’s as robust as possible, while minimizing the number of settings we’d have to change again later during segmentation.

I’d be interested to hear how you’d approach such a migration in practice.

Thx in advance

CD