fortinet models list update procedure - building a completer model list

[inphobia]

fortinet removes device models from their mibs at regular intervals since they provide targetted mibs with each major fortios version.

for the products mapping this means this does mean that if fortios 7.6.2 gets released a few weeks later 7.2.8 with it's specific mibs , that if we just overwrite we'll be loosing all models from 7.6.2 that aren't known in 7.4.8, and when you go to 7.6.3 it's a bunch of add/remove again.

as it is, we have a manual procedure to make this somewhat structured, it's glaring weakness is that once you forget it the removed models could be gone forever.

each mib version from fortinet will have a unique filename but ofcourse the same module id.

what we want is to have a place where the model inventory can be safe over time. this can be done by storing a version of each unique mib, but in a place where netdisco doesn't go looking by default. or store the in a format we don't read by default.

fortinet is a more labor intensive one, but fixups to model inventory is quite common over all mibs. both are not really something that's been done in the past in an ordered way in the mibs tree i think.

updating mibs will always require manual review - so i think that simple but generic that committers can easily check and/or fix might suffice. i'd just throw each version we find or get offered in a directory per vendor and basicly sort -u it for models.

so, looking for ideas, insights or just a plain "nope, not gonna fly". initial question if we move forward would: where will we store this (under extras somewhere i guess, and what.

it's a naive approach, perhaps i can get genxlate to ask "are you sure" for each indivual model removed:-)

[rc9000]

Heh I was also baffled by this MIB yet another time.

I do think keeping the various variants of the MIB files would be a pain, but basically we have all the info in git. For fun I made a little script that can show the history of fgModel entries, and will also show if we enter a state of oscillation like in fgModel.646:

 $ ./EXTRAS/contrib/fortinet-fgmodel-history.pl --only-changes                                                                                                                                                        [B: master]
fgModel.46:
  - 2017-01-05T17:45:30+01:00 (93641b2): fgtVM64AWSONDEMAND
  - 2021-05-15T03:34:55+02:00 (17d7adf): fgtVM64FGCAWS
fgModel.61:
  - 2019-03-05T22:48:46+01:00 (35a7a3a): fgtVM64NPU
  - 2022-08-17T02:41:44+01:00 (05e4ccf): fgtVM64FGCKVM
fgModel.624:
  - 2015-06-11T18:36:01-04:00 (3b0fdee): fwf60D
  - 2018-04-29T16:17:26-04:00 (1848686): fgt60D
  - 2023-09-14T10:12:27+02:00 (1bd43bc): fgt60D
fgModel.625:
  - 2014-10-11T09:48:49-04:00 (0f17a41): fgt60D
  - 2018-04-29T16:17:26-04:00 (1848686): fgt60DPOE
  - 2023-09-14T10:12:27+02:00 (1bd43bc): fgt60DPOE
... 
fgModel.646:
  - 2019-03-05T22:48:46+01:00 (35a7a3a): fg60EI
  - 2021-05-15T03:34:55+02:00 (17d7adf): fwf60F
  - 2023-09-14T10:12:27+02:00 (1bd43bc): fg60EI
  - 2025-09-03T20:55:08+02:00 (636fa6d): fwf60F
  ...

It's in https://github.com/netdisco/netdisco-mibs/blob/rc9000-fgmodelhist/EXTRAS/contrib/fortinet-fgmodel-history.pl and if you peeps think that would be useful we can put it into the main branch and mention it in fortinet/README.

But I think it would be a lot better to try to explain to FortiEngineering that this is a fundamentally bad idea, it's not a big deal with the models but they also often change the datatype or meaning of other OIDs, so that the SNMP manager would need multiple versions of the MIB loaded, depending on e.g. what release is sending a trap. This is fundamentally impossible in most cases and a huge pain.