Command syntax

When entering a command, the CLI console requires that you use valid syntax and conform to expected input constraints. It will reject invalid commands.

Fortinet documentation uses the conventions below to describe valid command syntax.

Terminology

Each command line consists of a command word that is usually followed by configuration data or other specific item that the command uses or affects.

To describe the function of each word in the command line, especially if that nature has changed between firmware versions, Fortinet uses terms with the following definitions.

Command syntax terminology

• Command — A word that begins the command line and indicates an action that the FortiGate should perform on a part of the configuration or host on the network, such as config or execute. Together with other words, such as fields or values, that end when you press the Enter key, it forms a command line. Exceptions include multiline command lines, which can be entered using an escape sequence. Valid command lines must be unambiguous if abbreviated. Optional words or other command line permutations are indicated by syntax notation.
• Sub-command — A config sub-command that is available only when nested within the scope of another command. After entering a command, its applicable sub-commands are available to you until you exit the scope of the command, or until you descend an additional level into another sub-command. Indentation is used to indicate levels of nested commands.Not all top-level commands have sub-commands. Available sub-commands vary by their containing scope.
• Object — A part of the configuration that contains tables and /or fields. Valid command lines must be specific enough to indicate an individual object.
• Table — A set of fields that is one of possibly multiple similar sets which each have a name or number, such as an administrator account, policy, or network interface. These named or numbered sets are sometimes referenced by other parts of the configuration that use them.
• Field — The name of a setting, such as ip or hostname. Fields in some tables must be configured with values. Failure to configure a required field will result in an invalid object configuration error message, and the FortiGate will discard the invalid table.
• Value — A number, letter, IP address, or other type of input that is usually your configuration setting held by a field. Some commands, however, require multiple input values which may not be named but are simply entered in sequential order in the same command line. Valid input types are indicated by constraint notation.
• Option — A kind of value that must be one or more words from of a fixed set of options.

Indentation

Indentation indicates levels of nested commands, which indicate what other sub-commands are available from within the scope. The “next” and “end” lines are used to maintain a hierarchy and flow to CLI commands, especially helping to distinguish those commands with extensive sub-commands.

The "next" line is entered at the same indentation-level as the previous “edit”, to mark where you would like to finish that table entry and move on to the next table entry; doing so will not mean that you have “left” that sub-command.

next

Below is an example command, with a sub-command of entries:

After entering settings for <2> and entering next, the <2> table entry has been saved, and you be set back one level of indentation so you can continue to create more entries (if you wish).

This hierarchy is best indicated in the CLI console, as the example below is what displays in the console after entering next:

To go-back up an indentation-level from this point on (i.e. to finish configuring the entries sub-command), you cannot enter next; you must enter end.

end

Below is the same command and sub-command, except end has been entered instead of next after the sub-command:

Entering end will save the <2> table entry, but bring you out of the sub-command entirely; in this example, you would enter this when you don’t wish to continue creating new entries.

Again, your hierarchy is best indicated by the CLI console. Below is what displays in the console after entering end:

Notation

Brackets, braces, and pipes are used to denote valid permutations of the syntax. Constraint notations, such as <address_ipv4>, indicate which data types or string patterns are acceptable value input.

All syntax uses the following conventions:

Convention	Description
Square brackets [ ]	An optional word or series of words. For example: [verbose {1 | 2 | 3}] indicates that you may either omit or type both the word verbose and its accompanying option/s, such as verbose 3. See Optional values and ranges below for more information.
Curly braces { }	A word or series of words that is constrained to a set of options delimited by either vertical bars or spaces. You must enter at least one of the options, unless the set of options is surrounded by square brackets [ ].
Mutually exclusive options - delimited by vertical bars |	Both mutually and non-mutually exclusive commands will use curly braces, as they provide multiple options, however mutually exclusive commands will divide each option with a pipe. This indicates that you are permitted to enter one option or the other: {enable | disable}
Non-mutually exclusive options - delimited by spaces	Non-mutually exclusive commands do not use pipes to divide their options. In those circumstances, multiple options can be entered at once, as long as they are entered with a space separating each option: {http https ping snmp ssh telnet}
Angle brackets < >	A word constrained by data type. The angled brackets contain a descriptive name followed by an underscore ( _ ) and suffix that indicates the valid data type. For example, <retries_int>, indicates that you should enter a number of retries as an integer. Data types include: <xxx_name>: A name referring to another part of the configuration, such as policy_A. <xxx_index>: An index number referring to another part of the configuration, such as 0 for the first static route. <xxx_pattern>: A regular expression or word with wild cards that matches possible variations, such as *@example.com to match all email addresses ending in @example.com. <xxx_fqdn>: A fully qualified domain name (FQDN), such as mail.example.com. <xxx_email>: An email address, such as admin@example.com. <xxx_ipv4>: An IPv4 address, such as 192.168.1.99. <xxx_v4mask>: A dotted decimal IPv4 netmask, such as 255.255.255.0. <xxx_ipv4mask>: A dotted decimal IPv4 address and netmask separated by a space, such as 192.168.1.99 255.255.255.0. <xxx_ipv4/mask>: A dotted decimal IPv4 address and CIDR-notation netmask separated by a slash, such as 192.168.1.1/24 <xxx_ipv4range> : A hyphen ( - )-delimited inclusive range of IPv4 addresses, such as 192.168.1.1-192.168.1.255. <xxx_ipv6>: A colon( : )-delimited hexadecimal IPv6 address, such as 3f2e:6a8b:78a3:0d82:1725:6a2f:0370:6234. <xxx_v6mask>: An IPv6 netmask, such as /96. <xxx_ipv6mask>: A dotted decimal IPv6 address and netmask separated by a space. <xxx_str>: A string of characters that is not another data type, such as P@ssw0rd. Strings containing spaces or special characters must be surrounded in quotes or use escape sequences. <xxx_int>: An integer number that represents a metric, minutes_int for the number of minutes.

Optional values and ranges

Any field that is optional will use square-brackets, such as set comment. This is because it doesn’t matter whether it’s set or not. The overall config command will still successfully be taken.

Another example of where square-brackets would be used is to show that multiple options can be set, even intermixed with ranges. The example below shows a field that can be set to either a specific value or range, or multiple instances:

config firewall service custom

set iprange <range1> [<range2> <range3> ...]

end