FortiNAC doesn't see new VLANs on FortiLink

[AEK]

Hi FNAC admins

• FortiNAC 7.2.9
• FortiOS 7.4.9 with managed switches

Integration is fine and all works great so far except when I add a new VLANs in my FortiLink it is not detected by FortiNAC, while all pre-existing VLANs are all detected.

Performed Read VLANs, Resync Interfaces, Validate Credentials, L2/L3 poll, but new VLANs still not detected.

I mean don't see the new VLANs when try Model Config, and don't see then when I try Test Device Mapping.

Even when I assign the new VLAN manually to to a port on my FGT, the FNAC doesn't want to reflect this change (it keeps only known VLANs).

Opened a ticket but no fix so far.

Any idea about this issue?

[ebilcari]

There is a reported issue affecting integrations with later version of FGT #1203457 due to changes in token naming. The workaround is to use token based API access, the fix will be included in 7.6.5.

[AEK]

Thanks for your feedback Emirjon.

I see this issue is reported in FortiOS 7.6.4. Is it the same case for my 7.2.9?

Also we are already using token based API since the beginning and I confirm the API access it working fine.

[ebilcari]

FortiOS 7.6.4 refers to the FGT firmware. I'm not sure if the same change was also applied in the latest release of FortiOS 7.4.9. In any case, if token-based API access is configured for this integration, this integration should not be affected by it.

How many VDOMs does this FGT have and does it have a large number of VLANs configured?

[AEK]

It has only 2 VDOMs, while only root VDOM is used here. The API user has access rights to both VDOMs.

There are about 40 VLANs max.

[ebilcari · Accepted solution]

Based on the documentation, the VLAN information should be extracted with REST API.
I didn't found any reported issue related to this behavior. I tried to emulate it in a lab (FOS 7.2.11) and the API call used for it should be: 

https://10.0.10.1:443/api/v2/cmdb/system/interface?filter=type==vlan&access_token=*****&format=name|vdom|vlanid|interface&vdom=* 
the output should list all the VLANs like:

{
"name":"ISOL-F",
"q_origin_key":"ISOL-F",
"vdom":"root",
"interface":"port5",
"vlanid":2501
}

You can check from FNAC logs by enabling this debugs:

$ device -ip <IP> -setAttr -name DEBUG -value "TelnetServer ForwardingInterface"

or from an external API system and check the response of the FGT when asked to provide the VLAN information.

With debugs enabled you can also try to run:
# exe enter
$ updatevlans -ip 10.0.10.1

[AEK]

The API call should help a lot. Thanks!

Regarding TelnetServer Debug, I already tried it and I found some trace of the new VLAN name in some output that looks like API response.

So I'll try the suggested API call and see what it gives. I also check in FGT API logs if the API call you mentioned is made by FNAC.

Thanks again, Emirjon!

[ByteHaven]

Hello AEK,

I'm no expert and I don't know if this helps in your scenario, but I came across this article and thought about your issue...

https://community.fortinet.com/t5/FortiNAC/Technical-Tip-Best-practice-for-manually-changing-VLANs-o...

BR,

[AEK]

Hi BH

Thanks for sharing.

It doesn't provide the solution but indeed this tech tip helps to understand more.

Also the link at the bottom of the tech tip explains when VLAN info is updated during L2 poll. It gives some ideas for troubleshooting my issue.

[AEK]

I tried the API call and I found that the new VLAN is included in the response with the other VLANs, and its output is well formatted just like other VLANs.

That means FGT is responding to the API call with the right response.

In FGT API call logs I also see trace of previous API "/api/v2/cmdb/system/interface" from FortiNAC, with status code 200. That also mean FortiNAC is performing the API call and getting a correct response.

I also tried snmpwalk from FNAC to FGT and I could see the new VLAN interface.

Tried to run updatevlans command and I can see the new VLAN in the output. Also after running this command I could see the new VLAN on FNAC GUI. So it seems the manual run of updatevlans has fixed the issue. Knowing that Read VLANs, Re-sync Interfaces, L2/L3 poll, Validate Credentials, all have been run several times without getting the new VLANs.

This is at least a very good workaround, and thanks for that.

In case you have any extra idea to get it updated from the GUI it will be welcome.