pjhtech Tools
MikroTik · RouterOS v7

MikroTik BGP Commands: Sessions, Prefixes and Routes

Quick answer #

Start with /routing/bgp/session/print detail for the live BGP relationship. Then inspect the configured connection and the exact destination prefix in /routing/route. An established session confirms the BGP conversation, not that the required route was accepted, selected or installed for forwarding.

Scope: RouterOS v7 on RouterBOARD, CCR, CRS running RouterOS, or CHR where the relevant feature exists. Not SwOS. Output fields depend on release and hardware. RouterOS v7 BGP only, on architectures with BGP support; not the RouterOS v6 /routing bgp peer model. Newer v7 releases changed instance and advertisement facilities; this page deliberately uses the core session, connection, template and route views.

Commands #

203.0.113.0/24 is an example prefix. Replace it with the exact prefix being investigated, including its mask length.

Commands
RouterOS v7 · RouterOS v7 terminal; absolute menu paths

Read-only
/system/resource/print
Read-only
/routing/bgp/session/print detail
Read-only
/routing/bgp/connection/print detail
Read-only
/routing/bgp/template/print detail
Read-only
/routing/filter/rule/print detail
Read-only

Replace these example values: 203.0.113.0/24.

/routing/route/print detail where dst-address=203.0.113.0/24
Read-only
/log/print where topics~"bgp"
Output may contain sensitive operational data.

Read the result #

The session view exposes the negotiated relationship, including local and remote information and establishment status. Compare the actual peer address and AS with the intended connection. Session uptime and notification information can help separate a stable conversation with a policy problem from a repeatedly resetting transport or negotiation problem.

Configuration and operational state answer different questions. Templates can supply settings to connections, so a short connection line may not show the entire intended policy. Read the inherited settings before deciding that a parameter is missing. Save the relevant filter chain with the incident notes rather than only the session screenshot.

For the destination route, inspect its source, table, filtering status where shown, next hop and selection state. A route can exist as routing information without becoming the forwarding choice. Also remember that input controls can reject information before it becomes an inspectable stored route. An empty prefix query is not enough to prove that the neighbour never sent an update.

Investigate one prefix #

Ask for one exact prefix that should work and one that does. Compare them against the same session and table. Determine whether the failing prefix is absent, filtered, present but inactive, or active with an unexpected next hop. Each result suggests a different next step and avoids a general BGP reset as the first response.

If you need to establish what the remote side received from you, collect evidence there too. A locally available route and an established session do not together prove a specific advertisement crossed the wire and passed the remote policy.

Pitfalls #

Do not paste RouterOS v6 peer or advertisement commands into a v7 troubleshooting sequence. Do not enable sent-attribute retention across full tables merely to populate a screenshot; it has operational and memory implications. Advertisement inspection differs between v7 releases and deserves a separately scoped procedure.

The commands here do not clear or resend sessions. Preserve notification evidence before any separately authorised reset, and record the exact RouterOS version with the capture.

Sources

Documentation reviewed: 8 October 2026