CliDeck
PlatformLog in
Workspace

FortiGate Routing Table Checks: Find the Route Without Claiming Packet Success

Serial Console
#fortigate#operational-evidence#runbooks#remote-operations#Serial Console
← Back to Blog

Short answer

Use get router info routing-table all in the correct FortiGate VDOM to inspect the current routing table. Identify the destination's matching prefix, next hop, interface, and VRF, then record what the table establishes. A route entry is evidence of routing state; it does not prove that a particular application packet passes firewall policy or reaches its destination.

Define the question and scope

This runbook follows FortiOS 7.6.3 routing concepts and applies to an authorized IPv4 routing inspection. Record the exact model, installed build, VDOM, VRF, destination, and observation time. Check local help when working on another release. IPv6 uses a separate command family and is outside these examples.

Agree on one question, such as whether the expected IPv4 prefix is present in the intended routing context. This keeps a routing-table check separate from an end-to-end connectivity diagnosis and prevents a broad collection from becoming an unplanned configuration task.

Select the correct context first

When VDOMs are enabled, routing commands belong in the relevant VDOM rather than global context. Select the VDOM that owns the traffic using the site's approved administrative workflow. Do not assume that a familiar VDOM name or the current login context is correct.

Confirm the authorized observation context before collecting:

get router info routing-table all

Save the complete result privately. Note the VRF heading and any multiple routing-table sections. A route visible in one VRF is not proof that another VRF can use it. If access is denied or the context is uncertain, stop and resolve that uncertainty before changing anything.

Read the entry before proposing a fix

Start with the intended destination and look for matching networks. Among matching prefixes, a more specific network is relevant before a less specific one; a default route is the broadest match. Do not assume that the presence of a default route makes a more specific route irrelevant.

Record these fields where displayed:

FieldWhat to preserve
Prefix and maskThe destination range represented by the entry
Route codeConnected, static, or the displayed dynamic protocol
Distance and metricThe values associated with this route
Next hop and interfaceThe listed forwarding path or directly connected interface
VRFThe routing-table context containing the entry

For equal-cost paths, preserve every listed next hop. The table alone does not establish which path a specific flow will use. Do not infer a failed neighbor, failed link, or routing-process fault from a missing entry without additional evidence.

Keep policy routing and packet success separate

FortiGate policy routing can select traffic differently from an ordinary destination-based routing lookup. Policy-based routes, Internet Service routes, and SD-WAN rules need their own context-aware review. The relevant source, incoming interface, protocol, ports, and current session can matter to the actual path.

Likewise, an expected route does not establish firewall-policy acceptance, address translation behavior, return-path reachability, or application success. Describe the result precisely: the route was present in the captured table at the recorded time, with the listed next hop and interface.

If the question requires traffic observation, arrange a separate bounded test with the service owner. Use the FortiGate packet-sniffer runbook and preserve its visibility limits rather than treating an empty capture as definitive proof of loss.

Verification note: close with a bounded conclusion

The routing inspection is complete when the intended VDOM and VRF are identified, the table capture is saved, the expected prefix is located or explicitly absent, and uncertainty about policy routing or actual packet success remains visible in the handoff.

No routing change, daemon restart, session clearing, or policy modification is required by this checklist. Those actions need a separate change plan. These acceptance criteria do not claim that a FortiGate model was physically tested.

Use CliDeck Workspace to retain the command, model/build, context, time, route fields, and next investigation step. Sanitize addresses and installation identifiers before sharing an excerpt publicly.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on SSH, serial, browser terminal, and infrastructure operations workflows.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Most common default

Most network console ports use 9600 8N1, but many modern switches, appliances, and server-management interfaces use 115200. Some devices use other speeds such as 38400, 19200, 57600, or 2400.

Notable exceptions

Examples:

  • FortiSwitch often uses 115200.
  • HPE Aruba AOS-CX often uses 115200.
  • Dell OS10 often uses 115200.
  • MikroTik RouterOS commonly uses 115200.
  • TP-Link JetStream examples may use 38400.
  • F5 BIG-IP may use 19200.
  • Some UPS serial protocols may use 2400.

How to use this table

Use the table as a starting point, then verify the setting against the device label, approved device procedure, site runbook, or known-good console output. If the terminal shows unreadable characters, test the likely baud rates before assuming the cable or port is broken.

Verify against the device-specific procedure

Do not treat a reference table as a substitute for the approved device-specific procedure, site policy, or a verified device-specific runbook when the operation is risky.

How CliDeck helps

CliDeck helps teams keep console settings, notes, runbooks, and terminal sessions organized. Console Server Go can show the current UART speed on its built-in screen. Net Controller can help teams process multiple devices with standardized workflows where configured.

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides