A full-mesh BGP topology is simple: every router peers with every other router. For a small network of five to eight routers, this can work well. The problem is that the number of BGP sessions grows rapidly as routers are added.

• 10 routers require 45 BGP sessions.
• 20 routers require 190 BGP sessions.
• 25 routers require 300 BGP sessions.

At scale, this creates real operational problems:

• CPU load rises during convergence events, especially with complex BGP filters and policies.
• Every router maintains state with every peer, increasing memory and TCP overhead.
• Route changes arrive from multiple directions and are more difficult to troubleshoot.
• Adding one router requires configuring BGP relationships with every existing router.
• Routine maintenance windows become riskier as the control plane grows.

At that point, the network is not truly scaling—it is accumulating operational risk.

Route Reflectors use a hierarchical design. Client routers peer with designated route reflectors instead of peering directly with every other client. The reflectors distribute eligible routes to their clients, greatly reducing the number of sessions required.

Confederations divide a large autonomous system into smaller internal sub-autonomous systems. They can provide additional policy separation and regional control, but they add another layer of design and troubleshooting complexity.

Full-Mesh Topologies maintain direct peering between every router. They remain useful for small, stable networks where simplicity matters more than scaling, but they become expensive to operate as the router count grows.

For most growing ISP deployments, Link Technologies, Inc. prefers a redundant route-reflector design because it solves the scaling problem without introducing unnecessary operational complexity.

In this model, one or more routers are designated as route reflectors. Other routers become route-reflector clients. Clients establish BGP sessions to the reflectors, not to every other client router. When a client advertises a route, the reflector applies the relevant policy and reflects that route to other eligible clients.

The architecture provides several immediate benefits:

• Client routers generally need only one or two BGP sessions to the route reflectors.
• Reflectors maintain sessions with clients and selected external peers.
• Route distribution remains predictable and easier to monitor.
• Adding a new router requires configuration on the new router and the reflector—not every router in the network.
• Policy, filtering, communities, and traffic-engineering decisions can be managed consistently.

For an ISP with 25 routers, a dual route-reflector design can reduce the internal client session count from 300 full-mesh sessions to roughly 50 client-to-reflector and reflector-related sessions, depending on the exact topology.

Full mesh still has a place in small networks. If you have fewer than 10 routers, do not expect rapid growth, and want the most direct possible visibility between peers, full mesh can be a reasonable choice.

It is most appropriate when:

• The router count is small and expected to remain small.
• The network is geographically compact.
• Routing policy is straightforward.
• The engineering team accepts the configuration overhead.

Once an ISP grows beyond that point, the advantages quickly fade. Higher peer counts consume additional resources, make change management harder, and increase the chance that a routine routing change becomes a network-wide event.

Confederations solve a different problem than route reflection. They allow a larger network to be divided into smaller internal sub-autonomous systems while appearing as a single autonomous system to external providers.

Confederations can make sense for:

• Multi-region networks with separate operational teams.
• Networks that require policy isolation between regions.
• Large organizations that need additional control over inter-region routing.
• Networks with distinct geographic or business-unit boundaries.

The tradeoff is complexity. For most regional ISPs, WISPs, municipalities, and enterprise networks, dual route reflectors handle the scaling requirement with far less operational overhead.

MikroTik RouterOS provides a clean, cost-effective route-reflector implementation for ISP-scale networks. The design begins by selecting at least two reliable routers to act as route reflectors and placing them in separate failure domains whenever possible.

A typical implementation includes:

• Stable loopback addresses used for BGP router IDs and internal BGP peering.
• An underlay IGP, such as OSPF, that reliably carries loopback reachability.
• Two route reflectors for resilient route distribution.
• BGP client sessions to both reflectors.
• Strict import and export filters for routes, communities, and traffic engineering.
• Monitoring for BGP state, route counts, CPU, memory, and routing changes.

RouterOS supports route-reflector cluster identification and the BGP controls needed for filtering, route selection, and policy. Cluster ID, router ID, route-reflector client roles, and route filters should all be deliberately designed and documented.

The performance difference between full mesh, route reflection, and confederation designs can be significant in production networks. The exact result depends on router model, RouterOS version, route count, filtering policy, peer count, traffic engineering, and the overall underlay design.

In real deployments, full mesh commonly places more session-processing responsibility on every router. Route reflectors centralize selected control-plane work on dedicated devices while reducing internal peer counts on the clients. This normally provides more headroom for growth and simplifies maintenance.

Monitor the following on route reflectors:

• CPU and memory use during large route changes and maintenance events
• BGP session uptime, disconnect reasons, and route counts
• Filtered prefixes and unexpected route-policy changes
• Underlay reachability to client loopbacks
• Convergence time during controlled failure tests

Every route-reflector deployment begins with the existing topology. Link Technologies, Inc. maps router locations, loopback reachability, peer relationships, traffic flows, routing tables, and policy requirements before recommending a migration path.

Our engineering approach includes:

• Reviewing the current BGP and IGP design
• Identifying full-mesh scaling limits and unnecessary peerings
• Designing redundant route-reflector placement
• Creating safe route filters and traffic-engineering policy
• Developing a phased migration plan with rollback options
• Staging and pre-configuring MikroTik hardware when needed
• Testing route propagation, convergence, and reflector failure
• Documenting the final architecture for future support

We can provide pre-configured MikroTik routers ready for deployment and ongoing engineering support as your network evolves. The goal is a routing architecture that remains understandable, stable, scalable, and supportable for years to come.