Summarizing everything a FortiGate considers when multiple candidate paths exist to the same substation subnet, in which order does it actually apply longest-prefix match, administrative distance, and priority to decide the active route?
Select an answer to reveal the explanation.
Short Explanation
It's a strict pecking order, not a group vote: first the most specific address wins, then among equally specific routes the more trusted source wins, and only if those tie does the priority number get a say at all.
Full Explanation
FortiGate route selection follows a fixed hierarchy rather than any kind of averaged score: first, longest-prefix match narrows the field to whichever candidate route has the most specific subnet mask actually covering the destination address; second, among any remaining routes that share that same prefix length, administrative distance is compared and the lowest value is preferred; and only when distance is also tied does priority step in as the final tiebreaker, with the lower priority value winning. Reversing this order, as the fourth option does by putting distance ahead of prefix length, would incorrectly let a less specific but lower-distance route beat a more specific one, which is not how FortiOS behaves. Putting priority first, as the first option does, misrepresents priority as a primary selector when it is in fact the last and narrowest tiebreaker of the three. Treating the three as a blended composite score invents a mechanism FortiOS does not use; each criterion is applied sequentially, with earlier criteria eliminating candidates before the next criterion is even considered. A solid way to confirm this hierarchy on a live device is to build routes that differ on exactly one criterion at a time — prefix length only, then distance only, then priority only — and verify the routing table's selected route in each case matches this three-step ordering.