Routing Settings

Routing Settings

Global routing settings in RouterOS control fundamental routing behavior that affects all routing protocols and static routes. These settings determine how routes are selected, installed in the forwarding information base (FIB), and distributed across routing protocols. Understanding and properly configuring routing settings is essential for building reliable and predictable routed networks, especially in complex environments running multiple routing protocols simultaneously.

The routing settings hierarchy provides centralized control over routing behavior that would otherwise require protocol-specific configuration. Settings such as route decision criteria, equal-cost multi-path (ECMP) behavior, and routing table distribution affect all routing protocols uniformly. This consistency simplifies network design and reduces the likelihood of unexpected routing behavior caused by conflicting protocol-specific settings.

RouterOS maintains a complete separation between the routing information base (RIB), where all learned routes are stored, and the forwarding information base (FIB), which contains the actual routes used for packet forwarding. The routing settings control how routes flow from the RIB to the FIB, which routes are eligible for installation, and how multiple routes to the same destination are resolved.

Summary

The /routing/settings menu contains global parameters that influence routing protocol operation and route selection across the entire RouterOS installation. These settings are applied before any protocol-specific logic, establishing baseline behavior that all routing components respect. Network administrators use these settings to enforce organizational routing policies, optimize routing performance, and ensure consistent route handling across diverse network topologies.

Key routing settings include the selection of default routes for unreachable destinations, ECMP configuration for load balancing across multiple paths, route mark evaluation for policy-based routing, and distribution scope controls that determine which routing tables receive routes from which sources. Proper configuration of these settings requires understanding both the immediate effect on routing behavior and the potential interaction with protocol-specific configurations.

RouterOS supports multiple routing tables for advanced policy routing scenarios. Routes learned through different mechanisms can be distributed to different tables, and routes from different tables can compete for installation in the main forwarding table based on administrative distance and other criteria. The routing settings provide the foundation for this multi-table routing architecture by defining default behaviors and distribution rules.

Introduction

Routing settings represent the lowest level of routing configuration in RouterOS, sitting below individual protocol configurations and affecting all routing decisions. While each routing protocol has its own settings for timers, hello intervals, and authentication, the global routing settings control universal aspects of route processing that apply regardless of how the route was learned. This includes fundamental decisions about which routes to accept, how to handle multiple routes to the same destination, and how to distribute routes between routing tables.

The global nature of these settings means that changes can have widespread effects on network behavior. A modification to ECMP configuration, for example, immediately affects how traffic is distributed across all equal-cost paths regardless of the routing protocol that discovered those paths. Similarly, changes to route selection criteria affect the preference order for routes learned through any mechanism. This makes careful planning essential before modifying routing settings, particularly in production networks where unexpected behavior could cause service disruption.

RouterOS implements routing settings using a hierarchical model where global settings establish default behavior and can be overridden by protocol-specific or instance-specific configurations when needed. This model provides both consistency through sensible defaults and flexibility through targeted overrides. Understanding where each setting can be overridden helps network administrators apply changes at the appropriate level rather than modifying global settings unnecessarily.

Route Selection Process

RouterOS evaluates routes through a multi-stage selection process that considers route type, administrative distance, metric, and other attributes to determine the best route for each destination. The routing settings influence several stages of this process, particularly the initial filtering and the final selection when multiple routes have equal attributes.

The route selection process begins when a routing protocol receives a route update or when a static route is configured. At this stage, global routing settings may apply route marks, perform distribution scope checks, or filter routes based on configured criteria. Routes that pass these initial checks enter the routing information base where they compete with routes from other sources.

When multiple routes to the same destination exist in the RIB, RouterOS selects the best route based on a well-defined preference order. Routes with lower administrative distance are preferred, with directly connected routes having the lowest preference value (0), followed by static routes (1), and then dynamically learned routes with their protocol-specific distances. When routes have equal administrative distance, the route with the lowest metric is preferred, with further tie-breaking based on route age and other factors.

The ECMP configuration determines how RouterOS handles situations where multiple routes have equal preference values. With ECMP enabled, multiple routes can be installed in the forwarding table, allowing load balancing across multiple paths. The specific load balancing algorithm depends on the ECMP mode configured, with options including per-destination hashing, per-packet distribution, and L4-based load balancing that considers transport layer information.

Routing Table Architecture

RouterOS implements a flexible multi-table routing architecture that supports complex policy routing requirements. While simple networks typically use only the main routing table, advanced deployments can leverage additional tables for traffic engineering, multi-tenancy, or separating routing domains. The routing settings define default behaviors for all tables while allowing specific tables to have custom configurations.

The main routing table, identified as main or by number 254, contains the routes used for regular packet forwarding. All traffic that does not match more specific rules in other tables or policy routing rules uses this table for next-hop resolution. Routes from all sources are eligible for installation in the main table unless specifically filtered or redirected to an alternate table.

Additional routing tables can be configured and referenced by name or number. Custom tables use numbers in the range 1-252, with table 255 reserved for cache entries and table 254 reserved for the main table. Routes can be explicitly placed in specific tables using route marks, distribution rules, or protocol-specific configuration. This flexibility enables sophisticated routing architectures where different types of traffic or different network segments use entirely separate routing tables.

The relationship between routing tables is controlled by distribution settings that determine which routes are visible to which tables. By default, routes learned through any mechanism are installed only in the main table. However, distribution rules can cause routes to be copied to additional tables, enabling scenarios where all routes learned through one interface are visible to all routers in a particular VRF instance or where specific protocol routes are isolated to prevent undesired redistribution.

Global Routing Parameters

The following sections describe the individual parameters available in the /routing/settings menu and their effects on routing behavior. Each parameter controls a specific aspect of routing, and proper network operation typically requires understanding the interactions between these settings rather than configuring each in isolation.

Default Route Behavior

The default route settings control how RouterOS handles traffic destined for networks that have no matching route in the routing table. In networks where a default route exists, all undetermined traffic is forwarded toward the default next-hop. Networks without a default route will generate ICMP destination unreachable responses for traffic that cannot be routed.

The route-distribute setting controls whether routes learned through connected interfaces are automatically distributed to other routing protocols. When enabled, RouterOS advertises directly connected networks through any active routing protocols, providing automatic network discovery without manual static route configuration. This setting is enabled by default and is generally desirable in most deployments, though it may be disabled in scenarios where manual control over advertised networks is required.

The route-filter setting applies a routing filter to all routes before they are processed by the routing protocol implementation. This filter can accept, reject, or modify routes based on prefix, next-hop, or other route attributes. Route filters provide a centralized location for applying policy to all routing activity, ensuring consistent route handling regardless of the routing protocol involved.

ECMP Configuration

Equal-Cost Multi-Path (ECMP) configuration determines how RouterOS handles multiple routes to the same destination with equal preference. ECMP enables load sharing across multiple paths, improving bandwidth utilization and providing redundancy without requiring complex traffic engineering mechanisms. The ECMP settings control both whether multiple routes are installed and how traffic is distributed across those routes.

The ecmp-mode parameter accepts several values that determine the load balancing algorithm. The auto mode selects an appropriate algorithm based on the router’s capabilities and the types of traffic observed. The persistent mode uses consistent hashing to ensure that packets for the same connection always use the same path, preserving TCP session integrity and ensuring proper operation of applications that require session affinity.

When ecmp-mode is set to legacy, RouterOS performs round-robin distribution of packets across ECMP paths without considering connection boundaries. This mode provides the most even distribution of traffic but may cause issues with applications that require session persistence or that are sensitive to asymmetric routing. Legacy mode is generally suitable only for UDP traffic or in networks where all paths provide equivalent latency and loss characteristics.

The l3-encoding setting controls whether layer 3 information beyond the destination address is considered in load balancing decisions. When enabled, the source IP address is incorporated into the hashing calculation, helping to ensure that return traffic follows the same path as outbound traffic in asymmetric routing scenarios. This setting is particularly important in networks with asymmetric paths where return traffic must reach the original sender through the same path used for the outbound connection.

Route Mark Evaluation

Route marks provide a mechanism for tagging routes with arbitrary identifiers that can be used for policy routing, filtering, or classification purposes. The route mark evaluation settings control how RouterOS processes route marks and where they are applied in the routing decision process.

Route marks can be applied in several ways. The /routing/filter menu allows marking routes based on various criteria including prefix, next-hop, and protocol of origin. Additionally, routes can be marked statically using the route-mark parameter when configuring static routes or through protocol-specific redistribution rules. Marked routes carry their mark through routing protocol advertisements, allowing consistent policy application across the network.

The route-mark parameter in /routing/settings controls the default behavior for routes that do not have an explicit mark applied. Setting this parameter applies the specified mark to all routes by default, which can then be overridden on a per-route basis where needed. This feature is particularly useful for applying consistent marks to routes from certain sources or for implementing default policies that are then customized for specific cases.

Administrative Distance Configuration

Administrative distance values determine the preference order when multiple routing sources provide routes to the same destination. RouterOS maintains default administrative distances for each route type, but the global routing settings allow customization of these defaults to accommodate specific network requirements or to implement policies that favor certain routing sources.

Lower administrative distance values indicate higher preference, so a route with distance 10 is preferred over a route with distance 20 for the same destination. The default values in RouterOS follow standard conventions: directly connected interfaces use distance 0, static routes use distance 1, EBGP uses distance 20, OSPF uses distance 110, and RIP uses distance 120. These defaults can be modified globally, and protocol-specific distance settings can override the global defaults for individual protocols.

The static-distance setting controls the default administrative distance assigned to static routes. This affects all static routes that do not have an explicit distance configured. Increasing the static distance makes static routes less preferred relative to dynamically learned routes, which may be desirable in networks where dynamic routing provides better path diversity and faster convergence.

The connected-distance setting controls the administrative distance for directly connected networks. Connected routes are typically the most preferred since they represent directly attached networks with minimal chance of misconfiguration. Modifying this value is rarely recommended and can cause unexpected routing behavior if routes become less preferred than they should be.

Distribution Scope Settings

Distribution scope settings control how routes are distributed between routing tables and between routing protocols. These settings enable complex routing architectures including route leaking between tables, VRF-lite implementations, and policy-based route propagation. Understanding distribution scopes is essential for building networks that require traffic separation or selective route sharing.

The distribution scope is specified when configuring routes or redistribution rules and determines which routing tables will receive the route. Routes with scope universe are visible to all routing protocols and tables, making them candidates for global routing decisions. Routes with scope same-as inherit the scope of the route from which they were learned, which is useful for preserving routing domain boundaries during redistribution.

Scope values range from universe (visible everywhere) through table (visible only in the specified table) to nowhere (not installed in any table). The nowhere scope is used for routes that should be tracked but never used for forwarding, such as routes that serve as match criteria for traffic policy rules but are not themselves destinations.

The distribution mechanism uses a publish-subscribe model where routing protocols and route sources publish routes with a specified scope, and routing tables subscribe to routes from various scopes. A route with universe scope is automatically visible to all subscribers, while routes with table scope are visible only to the specified table. Routes with scope same-as use the subscription settings of the route’s origin, effectively inheriting distribution characteristics.

Properties

General Settings

Property	Description
route-distribute	Enable/disable automatic distribution of connected routes to other routing protocols (yes/no, default: yes)
route-filter	Routing filter applied to all routes before processing (default: no filter)
route-mark	Default route mark applied to all routes without explicit mark (default: no mark)
router-id	Router ID for routing protocols that require it (default: auto-select from IP addresses)

ECMP Settings

Property	Description
ecmp-mode	Equal-Cost Multi-Path mode: auto, persistent, legacy, or none (default: auto)
l3-encoding	Include source IP in load balancing hash (yes/no, default: no)
ecmp-interval	Interval for ECMP recomputation (default: varies by RouterOS version)

Administrative Distance Settings

Property	Description
static-distance	Default administrative distance for static routes (0-255, default: 1)
connected-distance	Default administrative distance for directly connected routes (0-255, default: 0)
ospf-distance	Default administrative distance for OSPF routes (0-255, default: 110)
rip-distance	Default administrative distance for RIP routes (0-255, default: 120)
bgp-distance	Default administrative distance for BGP routes (0-255, default: 20)

Distribution Scope Settings

Property	Description
redistribute-connected	Redistribute directly connected networks (yes/no, default: yes)
redistribute-static	Redistribute static routes (yes/no, default: yes)
redistribute-ospf	Redistribute OSPF routes (yes/no, default: yes)
redistribute-bgp	Redistribute BGP routes (yes/no, default: yes)
redistribute-rip	Redistribute RIP routes (yes/no, default: yes)

Configuration Examples

The following examples demonstrate common routing settings configurations for various network scenarios. These configurations should be adapted to specific network requirements and tested in a non-production environment before deployment.

Basic ECMP Load Balancing

# Configure ECMP for persistent load balancing
/routing/settings/set ecmp-mode=persistent

# Enable L3 encoding for asymmetric path consistency
/routing/settings/set l3-encoding=yes

# Verify ECMP configuration
/routing/settings/print

This configuration enables persistent ECMP with source address consideration, ensuring that TCP connections and other stateful traffic flows consistently use the same path while still distributing different connections across available equal-cost paths.

Route Mark for Policy Routing

# Apply default route mark to all routes
/routing/settings/set route-mark=custom-mark

# Configure static route with specific mark
/ip/route/add dst-address=0.0.0.0/0 gateway=10.0.0.1 routing-mark=custom-mark

# Verify route marks in routing table
/ip/route/print detail where routing-mark=custom-mark

This configuration applies a consistent route mark to all routes, enabling policy routing rules to match traffic based on the routing table or mark regardless of how the route was learned.

Connected Route Redistribution Control

# Disable automatic connected route redistribution
/routing/settings/set route-distribute=no

# Manually redistribute specific connected networks
/routing/ospf/network/add network=10.0.0.0/24 area=backbone

# Verify redistribution settings
/routing/settings/print

Disabling automatic redistribution provides explicit control over which connected networks are advertised through each routing protocol, preventing unintended network exposure and ensuring consistent advertisement policies.

Custom Administrative Distances

# Increase static route distance to prefer OSPF
/routing/settings/set static-distance=110

# Configure BGP template with lower distance for specific peers (RouterOS v7)
/routing/bgp/template set default distance=15

# Verify effective distances in routing table
/ip/route/print detail

This configuration makes static routes less preferred than OSPF routes, ensuring that dynamically learned routes take precedence while still allowing static routes as a fallback.

Examples

Enterprise Network with Dual ISP Routing

This example configures ECMP load balancing between two ISP connections with proper route marking for traffic policy:

# Enable persistent ECMP for consistent traffic flow
/routing/settings/set ecmp-mode=persistent l3-encoding=yes

# Add static routes to both ISPs with equal distance
/ip/route/add dst-address=0.0.0.0/0 gateway=203.0.113.1 distance=1 comment="ISP1-primary"
/ip/route/add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=1 comment="ISP2-backup"

# Verify ECMP routes are installed
/ip/route print where dst-address=0.0.0.0/0

Expected output shows both routes active with equal distance, allowing load balancing across both ISPs.

VRF-Based Multi-Tenant Routing

Configure isolated routing tables for different tenants using route marks and distribution scopes:

# Configure default route mark for tenant A routes
/routing/settings/set route-mark=tenant-a

# Add tenant A specific routes
/ip/route/add dst-address=10.10.0.0/16 gateway=172.16.1.1 routing-mark=tenant-a
/ip/route/add dst-address=10.20.0.0/16 gateway=172.16.1.2 routing-mark=tenant-a

# Configure tenant B routes (default table)
/ip/route/add dst-address=10.30.0.0/16 gateway=172.17.1.1

# Verify routing tables
/ip/route/print where routing-mark=tenant-a
/ip/route/print where routing-mark=0

OSPF Preference Over Static Routes

Ensure OSPF-learned routes are always preferred over static routes by adjusting administrative distances:

# Set static route distance higher than OSPF (default 110)
/routing/settings/set static-distance=115

# Verify distances in routing table
/ip/route print detail where dst-address~"10\\."

# OSPF routes (distance 110) will be preferred over static routes (distance 115)

Troubleshooting

When routing settings cause unexpected behavior, systematic troubleshooting helps identify the specific setting or interaction causing the issue. The routing monitor and logging facilities provide visibility into routing decisions and can help diagnose problems.

The /routing/monitor command displays the current state of all routes including their distance, metric, and scope. Comparing routes from different sources helps identify preference issues where routes from one source are not being selected despite having better characteristics. The detailed output includes the administrative distance for each route, enabling verification that the correct distance is being applied.

Enabling routing debug logs with /system/logging/add topics=route,debug provides detailed information about route processing, including filter application, distribution decisions, and selection criteria. The debug output can reveal why routes are being filtered or why certain routes are not being selected despite meeting basic criteria.

Common issues with routing settings include unintended ECMP behavior causing asymmetric traffic flows, route marks interfering with normal routing, and administrative distance changes making routes less preferred than expected. Checking the current settings with /routing/settings/print and comparing with expected values is the first step in diagnosing these issues.

Verifying Current Settings

# Display all routing settings
/routing/settings/print

# Check specific setting values
/routing/settings/get ecmp-mode
/routing/settings/get route-distribute
/routing/settings/get static-distance

# Compare with routing table entries
/ip/route/print detail where dst-address=0.0.0.0/0

The output of these commands shows the active configuration and the resulting routes, enabling verification that settings are being applied correctly and producing the expected routing behavior.

Integration Points

Routing settings interact with several other RouterOS features and protocols. Understanding these integration points helps ensure consistent configuration and avoids unintended interactions that could affect network operation.

Firewall mangle rules can mark packets with connection marks, routing marks, or simple marks that influence subsequent routing decisions. The interaction between routing settings and firewall marks determines how packets are classified and which routing table is consulted for forwarding. Policy routing rules typically evaluate routing marks before consulting the main routing table, enabling complex traffic classification schemes that route traffic based on application or user identity rather than merely destination address.

The VRF-lite implementation uses routing tables and distribution scopes to isolate routing domains without requiring separate router instances. Routes configured within a VRF context automatically use the VRF’s routing table, and redistribution between VRFs must be explicitly configured using distribution rules. This isolation provides network segmentation at the routing layer while maintaining the simplicity of a single router platform.

Routing protocol integration with routing settings ensures consistent behavior across all protocol types. Protocol-specific settings override global defaults where configured, but the global settings provide baseline behavior that ensures consistent route handling even when specific protocols lack detailed configuration. Understanding this hierarchy helps maintain predictable routing behavior as the network evolves and protocols are added or modified.