Skip to content
MikroTik RouterOS Docs

BGP Basic Peering on MikroTik RouterOS: A Complete Guide

BGP Basic Peering on MikroTik RouterOS: A Complete Guide

Section titled “BGP Basic Peering on MikroTik RouterOS: A Complete Guide”

RouterOS Version: 7.x+ Difficulty: Advanced Estimated Time: 60 minutes

For the impatient: here’s the 30-second version.

# Minimal eBGP peering setup
/routing bgp instance add name=main as=65001
/routing bgp connection add name=to-peer remote.address=10.0.0.2 instance=main local.role=ebgp

Border Gateway Protocol (BGP) is the routing protocol that powers the Internet. Unlike interior gateway protocols (IGP) like OSPF or RIP that focus on finding the shortest path, BGP is a path-vector protocol designed for policy-based routing between autonomous systems (AS). Understanding BGP peering is essential for connecting to ISPs, implementing redundant internet connections, or building large-scale networks.

This guide explains BGP fundamentals, the critical differences between iBGP and eBGP, and how to establish basic peering relationships on MikroTik RouterOS v7.

  • MikroTik router running RouterOS 7.x+ (BGP not supported on SMIPS devices)
  • Basic understanding of IP routing and autonomous systems
  • Administrative access to the router
  • Valid AS number (public or private range 64512-65534 for testing)
  • IP connectivity to BGP peer

BGP operates fundamentally differently from IGP protocols:

IGP (OSPF, RIP): “What’s the shortest path to destination X?” BGP: “What’s the best policy-compliant path to destination X, and who should I trust?”

BGP doesn’t just move packets—it implements routing policy at Internet scale.

An Autonomous System is a collection of IP networks under single administrative control that presents a common routing policy to the Internet.

BGP Autonomous Systems Topology

AS Number Ranges:

  • Public: 1-64511 (assigned by RIRs for Internet routing)
  • Private: 64512-65534 (for internal use, like RFC 1918 addresses)
  • 4-byte: 65536+ (newer extended format)

The type of BGP session fundamentally changes how the protocol behaves:

  • Between different AS numbers
  • Direct neighbors only (unless multihop configured)
  • Administrative distance: 20
  • Next-hop changes to local router
  • AS-PATH is modified (local AS prepended)
  • Within the same AS
  • Can be multihop (typically via loopback addresses)
  • Administrative distance: 200 (lower priority than IGP)
  • Next-hop preserved (requires IGP reachability)
  • AS-PATH unchanged
  • Requires full mesh or route reflectors

BGP uses a finite state machine with these key states:

BGP State Machine

Session establishment process:

  1. TCP connection established (port 179)
  2. OPEN messages exchanged (AS number, router ID, capabilities)
  3. KEEPALIVE messages confirm session is active
  4. UPDATE messages exchange routing information

BGP Message Format

Message Types:

  • OPEN (1): Session negotiation
  • UPDATE (2): Route advertisements/withdrawals
  • NOTIFICATION (3): Error conditions
  • KEEPALIVE (4): Session maintenance

RouterOS v7 introduced a new BGP architecture that separates configuration into logical components:

RouterOS v7 BGP Architecture

Key Changes from v6:

  • Explicit instances instead of auto-detection by router-id
  • Connection-based configuration (not peer-based)
  • Template inheritance for common settings
  • Improved session monitoring

Let’s establish eBGP peering between two routers representing different ISPs:

eBGP Peering Topology

This represents a typical ISP peering scenario where:

  • Each router has its own AS number
  • They’re directly connected (single hop)
  • Each advertises their customer networks
  • BGP provides path redundancy and policy control

This section provides a minimal testable eBGP configuration between two routers.

Create a BGP instance with your AS number:

/routing bgp instance add name=main as=65001

Establish eBGP peering with the remote router:

/routing bgp connection add name=to-peer remote.address=10.0.0.2 instance=main local.role=ebgp

Add networks to advertise to the BGP peer:

/ip route add dst-address=192.168.1.0/24 blackhole
/routing bgp template set default output.network=bgp-networks
/routing filter rule add chain=bgp-networks rule="if (dst in 192.168.1.0/24) {accept}"

Check that the BGP session is established:

/routing bgp session print

Confirm your BGP configuration is working correctly:

/routing bgp instance print

Expected Output:

Flags: D - DISABLED, I - INVALID
# NAME AS ROUTER-ID ROUTING-TABLE
0 main 65001 10.0.0.1 main
/routing bgp session print

Expected Output:

Flags: E - ESTABLISHED
0 E name="to-peer"
remote.address=10.0.0.2 .as=65002 .id=10.0.0.2
local.address=10.0.0.1 .as=65001 .id=10.0.0.1
uptime=5m30s
/ip route print where bgp

Expected Output:

Flags: D - DYNAMIC, A - ACTIVE, B - BGP
# DST-ADDRESS GATEWAY DISTANCE
0 ADB 192.168.2.0/24 10.0.0.2 20

When BGP receives multiple paths to the same destination, it uses a deterministic algorithm to select the best path:

1. Highest WEIGHT (Cisco-specific, local to router)
2. Highest LOCAL_PREF (within AS only)
3. Shortest AS_PATH length
4. Lowest ORIGIN type (IGP < EGP < INCOMPLETE)
5. Lowest MED (Multi-Exit Discriminator)
6. eBGP over iBGP
7. Lowest IGP metric to BGP next-hop
8. Lowest BGP router ID
9. Shortest cluster list (route reflectors)
10. Lowest neighbor address

MikroTik-specific notes:

  • WEIGHT is implemented as a local attribute
  • LOCAL_PREF default is 100
  • AS_PATH length comparison can be disabled with ignore-as-path-len=yes

The sequence of AS numbers a route has traversed:

AS 65001 → AS 65002 → AS 65003
AS_PATH: [65003, 65002, 65001]

Loop prevention: If a router sees its own AS in the path, it rejects the route.

The IP address of the next router toward the destination:

  • eBGP: Changes to the advertising router’s IP
  • iBGP: Preserved from original eBGP advertisement
  • Multihop: Can be set to loopback addresses

Tells routers within an AS which exit point to prefer:

Higher LOCAL_PREF = More Preferred Path

Only meaningful within an AS (not sent to eBGP peers).

BGP’s power lies in policy control. You can filter routes based on:

  • Prefix lists: Specific networks
  • AS-PATH filters: Routes from specific AS numbers
  • Community attributes: Tags for policy application

Example filter to accept only specific prefixes:

/routing filter rule add chain=bgp-in rule="if (dst in 192.168.0.0/16) {accept} else {reject}"

Communities are 32-bit tags attached to routes for policy signaling:

Format: AS:Value (e.g., 65001:100)

Well-known communities:

  • NO_EXPORT (65535:65281): Don’t advertise to eBGP peers
  • NO_ADVERTISE (65535:65282): Don’t advertise to any peer
  • LOCAL_AS (65535:65283): Don’t advertise outside confederation

For eBGP sessions across multiple hops (common in ISP environments):

/routing bgp connection add name=multihop-peer remote.address=203.0.113.1 instance=main local.role=ebgp multihop=yes remote.ttl=5

Use cases:

  • Peering via loopback addresses
  • Load balancers between BGP speakers
  • Route servers at Internet exchanges

Symptoms: Session stuck in “Connect” or “Active” state

Common causes:

  1. TCP connectivity issues

    • Firewall blocking port 179
    • Routing problems
    • Wrong IP addresses
  2. BGP configuration mismatch

    • Wrong AS numbers
    • Authentication failures
    • Capability negotiation failures

Debugging steps:

# Check TCP connectivity
/tool traceroute 10.0.0.2
# Monitor BGP session attempts
/log print where topics~"bgp"
# Check connection configuration
/routing bgp connection print detail

Symptoms: BGP session shows “Established” but routing table empty

Common causes:

  1. No networks being advertised by peer
  2. Input filters rejecting all routes
  3. Next-hop unreachable (iBGP issue)

Debugging steps:

# Check what peer is advertising
/routing bgp session print detail
# Verify input filters
/routing filter rule print where chain~"bgp"
# Check next-hop reachability
/ip route print where dst-address=<next-hop-ip>

Symptoms: Routes visible in /ip route print but marked as inactive

Common causes:

  1. Better route exists (lower administrative distance)
  2. Next-hop unreachable
  3. Route filtering marking routes as unreachable

Solution:

# Check route details
/ip route print detail where dst-address=<prefix>
# Verify next-hop reachability
/ip route print where dst-address=<next-hop>

Symptoms: Session repeatedly going up/down

Common causes:

  1. Network instability (physical layer issues)
  2. Hold-time too aggressive
  3. Resource exhaustion (memory, CPU)

Solutions:

# Increase hold-time
/routing bgp template set default hold-time=180s
# Monitor system resources
/system resource print
# Check interface statistics
/interface monitor ether2
# Monitor BGP sessions in real-time
/routing bgp session monitor [find]
# View detailed session information
/routing bgp session print detail
# Check BGP routing table
/ip route print where bgp
# Monitor BGP logs
/log print where topics~"bgp"
# View BGP statistics
/routing stats print

Always use MD5 authentication for BGP sessions:

/routing bgp connection set [find name=to-peer] tcp-md5-key="your-secret-key"

Implement strict prefix filtering to prevent:

  • Route hijacking
  • Accidental advertisements
  • DDoS amplification
# Only accept customer prefixes
/routing filter rule add chain=customer-in rule="if (dst in 192.168.0.0/16) {accept} else {reject}"

Prevent AS-PATH manipulation:

# Reject routes with suspicious AS-PATH length
/routing filter rule add chain=bgp-in rule="if (bgp-as-path-length > 10) {reject}"

Protect against resource exhaustion:

# Limit received prefixes
/routing bgp template set default input.limit-process-routes-ipv4=10000

Dual-Homed Internet

Configuration approach:

  • eBGP to both ISPs
  • Local preference to prefer one path
  • AS-PATH prepending for traffic engineering

BGP Route Reflector

Benefits:

  • Eliminates full-mesh requirement
  • Reduces configuration complexity
  • Scales to hundreds of routers

Internet Exchange Point

Characteristics:

  • Multiple AS numbers on shared LAN
  • Route server provides route distribution
  • Reduced transit costs