Multihoming with BGP on MikroTik RouterOS is the configuration that takes an ISP from dependent on a single upstream to genuinely resilient. Done correctly, a multihomed MikroTik router automatically fails over to the secondary upstream within seconds of detecting a primary failure, prefers routes through the primary under normal conditions, and advertises your prefixes to both upstreams so inbound traffic has redundant paths. Done incorrectly, it either does nothing useful when the primary fails, or routes traffic asymmetrically in ways that create hard-to-diagnose performance problems.
Prerequisites Before Configuration
Before writing a single command, confirm three things: you have an ASN (either your own or a private ASN assigned by your upstream for the peering session), you have IP address space to advertise (your own allocation or a prefix assigned for advertisement), and you have confirmed the ASN and session parameters with both upstream providers, specifically the neighbour IP address they want you to peer with, any prefix filtering they apply, and whether they require BGP communities for traffic engineering.
Private ASNs (64512-65534) are usable for single-hop multihoming where neither upstream will propagate your routes beyond themselves. If your prefixes need to appear in the global routing table, you need a publicly registered ASN from APNIC.
Session Configuration
RouterOS BGP configuration has changed significantly between v6 and v7. These examples target v7 syntax, which is the current production version. For v6 installations, the configuration structure differs but the logical design is identical.
Configure the BGP connection to each upstream in /routing/bgp/connection:
/routing bgp connection
add name=upstream-primary remote.address=<upstream1-peer-ip>/32 \
remote.as=<upstream1-asn> local.role=ebgp \
router-id=<your-router-id> as=<your-asn> \
output.filter-chain=export-to-upstream1 \
input.filter-chain=import-from-upstream1
add name=upstream-secondary remote.address=<upstream2-peer-ip>/32 \
remote.as=<upstream2-asn> local.role=ebgp \
router-id=<your-router-id> as=<your-asn> \
output.filter-chain=export-to-upstream2 \
input.filter-chain=import-from-upstream2Prefix Advertisement Filter
The export filter chain controls what you advertise to each upstream. At minimum, advertise only your own prefixes, never transit routes. This is both correct BGP practice and required under MANRS filtering obligations:
/routing filter rule
add chain=export-to-upstream1 rule="if (dst == <your-prefix>) { accept } else { reject }"
add chain=export-to-upstream2 rule="if (dst == <your-prefix>) { accept } else { reject }"If you want to use AS-path prepending to make one upstream less preferred for inbound traffic (to shift inbound load toward the primary), add prepending to the export filter for the secondary:
/routing filter rule
add chain=export-to-upstream2 rule="if (dst == <your-prefix>) { set bgp-path-prepend 2; accept }"This makes your prefix appear two hops longer through the secondary upstream, causing routers in the internet to prefer the primary path when both are available.
Import Filter and Local Preference
The import filter controls what you accept from each upstream and sets local preference to determine outbound path selection. Higher local preference wins for outbound routing decisions:
/routing filter rule
add chain=import-from-upstream1 rule="set bgp-local-pref 200; accept"
add chain=import-from-upstream2 rule="set bgp-local-pref 100; accept"With this configuration, routes learned from upstream1 have local preference 200 and routes from upstream2 have 100. All outbound traffic prefers paths through upstream1. If upstream1's session goes down, routes are only available through upstream2 (local pref 100) and traffic automatically shifts there.
Apply prefix filtering on import to reject routes that are clearly invalid: default routes unless you specifically want them, routes with your own ASN in the path (routing loop indicator), and RFC 1918 or bogon space:
/routing filter rule
add chain=import-from-upstream1 rule="if (bgp-path includes <your-asn>) { reject }"
add chain=import-from-upstream1 rule="if (dst in [make-set 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16]) { reject }"
add chain=import-from-upstream1 rule="set bgp-local-pref 200; accept"BFD for Fast Failover
BGP hold timers (default 90 seconds, 3x the keepalive interval of 30 seconds) mean a BGP session failure can take up to 90 seconds to be detected through the standard keepalive mechanism. For most ISP applications, 90 seconds of black-holing traffic while waiting for session failure detection is unacceptable.
BFD (Bidirectional Forwarding Detection) reduces this to sub-second detection. Enable BFD on the BGP connection:
/routing bgp connection
set upstream-primary use-bfd=yes
set upstream-secondary use-bfd=yesBFD must be supported and enabled on the upstream router as well. Confirm BFD support with your upstream provider before relying on it for failover timing. PTCL, TWA, and Cybernet all support BFD on their peering interfaces but confirm for your specific circuit.
Verifying the Configuration
After sessions come up, verify the routing table shows routes from both upstreams and that the local preference is correctly applied:
/routing route print detail where bgpRoutes from upstream1 should show local-pref=200 and routes from upstream2 local-pref=100. The best route for any given prefix should be the one through upstream1 under normal conditions.
Test failover by administratively shutting the upstream1 session and verifying that the routing table updates to use upstream2 paths within BFD detection time. Restore the session and confirm traffic shifts back to upstream1.
For operators assessing whether their current peering and transit configuration is cost-optimised and routing-security compliant alongside the basic multihoming setup, PeerIQ covers route path analysis and RPKI posture assessment. For architecture review and design of the full multihomed topology, Network Design & Optimization covers BGP design from the ground up.