Command docs claim exist doesn't again.

[DerekWSmall]

I would like to increase the default ARP timeout on my Fortigates.  The docs say that for version 7.2.7  The command is:

config system global

  set arp-timeout [value-seconds]

However on my Fortigate there is no "set arp-timeout [value]" command on the CLI.  Why not?  Where is this command?

Please, no one from Fortigate post with ANY questions about what I'm running, where I'm looking, how I'm connected.  If your docs say I can connect to the CLI and just run this command then I should just be able to connect to the CLI and run this command.  If there is more required to be ABLE to run this command THEN PUT THAT IN YOUR DOCUMENTATION!!!!

If anyone knows a way ACTUALLY change the ARP timeout on a Fortigate, please help me out.  This should not be this hard or frustrating.

[Quint021]

Hello @DerekWSmall,

Arp-timeout value is a value that can be set on the Fortiswitch per the documentation. Can you please provide the link stating this command is possible for the Fortigate?

Kind Regards,

[bonelso2]

The TAB key is your friend. I could do your example, with cd pi<TAB> and auto completing the name, Tab again to see a list of other possible auto completions, and keep going deeper and deeper.

[DerekWSmall]

So you can only change the ARP timeout value on a Fortiswitch?  We have lots of Fortinet switches, but as is typical all Layer-3 is being done on the Fortigate, so the ARP table on the switches would only matter for the Fortilink (mgmt) Vlan.  I need to increase the timeout on the Fortigate.  Why is changing the ARP timer on the Fortigate (apparently) not possible, or why would it not use the exact same command?

[ede_pfau]

Hi @DerekWSmall,

you are right, there is no such command in "config system global".

However, you can modify the arp lifetime on a port which is part of a (Fortigate-internal) virtual switch:

config system switch-interface

    set mac-ttl <integer>

And, for the special case when the FGT is in Transparent Mode, you can modify the arp lifetime with

config system settings

    set mac-ttl <integer>

However, both settings apply to special settings.

Could you please post a link of where you read about the arp lifetime in FortiOS v7.2?

[DerekWSmall]

So short story from Frotigate is that when I connect a Fortinet switch to a FortiGate via a FortiLink connection, there is no way to get the ARP entries to stay around longer.

So I've been doing this for over 25 years and have been a CCIE for over 20.  When you want to know what devices are connected to a VLan on a network, the best way to do that is to do a ping sweep of that subnet, then collect the ARP table from the layer-3 device functioning as the default gateway for that subnet.  If a device has a local firewall or filter, you might not be able to ping it, but it will ALWAYS repond to ARPs, so the device will always show up in the ARP table of the device functioning as the default gateway for that subnet.  When I'm trying to track down what all is connected to a subnet that NO ONE has any documentation on, this is discovery process #1. The ARP entries on our Fortigates are only staying cached for about 30-60 seconds regardless of what the default is supposed to be.  I need them to stay around longer so I don't have to keep scanning each VLan. This is the kind of basic layer-2 / layer-3 stuff that I keep finding is lacking in Fortinet products.  You need more consistency between platforms, and you need to address some lacking features.  How can you recognize the need for this setting on your switches if they are doing layer-3, but not on your Fortigates?  If you just take a Fortigate out of the box and plug it into a Fortiswitch and boot them both up, the two will automatically form a Fortilink , and all layer-3 will occur on the Fortigate.  I've done Fortinet designs and builds where we tried to do the layer-3 on the Fortinet switches, and it did not go well.  Anytime we ever needed support the first thing we were ever told was that we should have done layer-3 on the Fortigates.  Please get everyone at Fortinet rowing in the same direction and present a product that has a consistent set of recommended build models. Getting a different story every time you run into problems is the worst kind of frustration.