RIP

RIP

Routing Information Protocol (RIP) is a distance-vector interior gateway protocol that routes packets using hop count as its sole metric. RouterOS implements both RIPv1 (RFC 1058) and RIPv2 (RFC 2453). RIPv2 is the default and recommended version for all new deployments.

Overview

RIP selects paths by counting the number of routers (hops) between source and destination. The maximum hop count is 15; a metric of 16 signifies an unreachable destination. Routers broadcast or multicast their full routing table to neighbors every 30 seconds.

Key characteristics:

• Simple to configure; no area hierarchy or topology database
• Maximum network diameter of 15 hops limits applicability to small networks
• Slow convergence: worst-case convergence takes several minutes on large tables
• Loop prevention via split horizon and poison reverse (not guaranteed loop-free under all conditions)
• RIPv2 adds classless routing, multicast updates, and authentication over RIPv1

RIPv1 vs RIPv2

Feature	RIPv1	RIPv2
Routing model	Classful	Classless (VLSM/CIDR)
Subnet mask in updates	No	Yes
Update destination	Broadcast (255.255.255.255)	Multicast (224.0.0.9)
Authentication	None	Simple password or MD5
Route tagging	No	Yes
VLSM support	No	Yes

RIPv1 cannot carry subnet mask information, so it cannot distinguish between subnets within the same classful network. Avoid RIPv1 in any network using VLSM or CIDR. RouterOS defaults to sending RIPv2 and accepting both versions on each interface.

Prerequisites

• RouterOS v7 (all configuration examples use the v7 model)
• Package: routing (included in all RouterOS builds)
• IP addresses configured on all RIP-enabled interfaces

Configuration

RouterOS v7 RIP uses a two-layer configuration hierarchy:

1. Instance — process-wide settings: redistribution sources, filter chains, routing table binding
2. Interface template — binds interfaces to the instance with per-link settings: authentication, send/receive version, split horizon, passive mode

Basic Setup

Minimal two-router RIP configuration:

# Router A
/routing rip instance
add name=rip1 routing-table=main

/routing rip interface-template
add instance=rip1 interfaces=ether1

# Router B
/routing rip instance
add name=rip1 routing-table=main

/routing rip interface-template
add instance=rip1 interfaces=ether1

Verify neighbors have formed:

/routing rip neighbor print detail

A healthy neighbor entry shows the neighbor’s address, last-update timestamp, and the number of routes received.

Instance Parameters

Property	Description	Default
name	Instance identifier	—
routing-table	Routing table to use	main
redistribute	Comma-separated list of route classes to redistribute: connected, static, ospf, bgp	""
out-filter-chain	Routing filter chain applied to redistributed routes before advertising	—
in-filter-chain	Routing filter chain applied to received routes before installing	—

Interface Template Parameters

Property	Description	Default
instance	Instance this template belongs to	—
interfaces	Interface name(s) to match	—
send	Version to send: v1, v2, both, disabled	v2
receive	Versions to accept: v1, v2, both, disabled	both
authentication	Authentication type: none, simple, md5	none
authentication-key	Authentication key/password	—
split-horizon	Enable split horizon	yes
poison-reverse	Advertise unreachable routes back with metric 16	no
passive	Suppress outgoing updates; still receive and process	no

Passive Interfaces

Mark LAN-facing or management interfaces as passive to suppress outgoing RIP updates while still including the connected prefix in redistribution:

/routing rip interface-template
add instance=rip1 interfaces=ether-lan passive=yes

Authentication

RIPv2 supports two authentication modes. MD5 is strongly preferred for production deployments.

Simple (Plaintext) Authentication

Simple authentication embeds a plaintext password in each RIP packet. It provides minimal protection against accidental misconfiguration but is trivially defeated by packet capture.

/routing rip interface-template
add instance=rip1 interfaces=ether1 authentication=simple authentication-key=MyPassword

Both sides of a link must use the same authentication type and key. A mismatch causes all updates to be silently dropped.

MD5 Authentication

MD5 authentication uses a keyed hash of the RIP packet content. This prevents route injection from unauthorized routers and protects against replay attacks.

/routing rip interface-template
add instance=rip1 interfaces=ether1 authentication=md5 authentication-key=StrongSharedKey

Verify authentication is working — neighbors should still appear and routes should be exchanged:

/routing rip neighbor print detail
/routing route print where protocol=rip

If neighbors disappear after enabling authentication, check that both sides use identical authentication type and authentication-key.

Timers

RIP still follows the standard protocol timers, but RouterOS 7.15.3 does not expose update-timer, timeout-timer, or garbage-timer as configurable /routing rip instance properties.

Timer	Purpose	Default
update-timer	How often the full routing table is sent to neighbors	30 s
timeout-timer	How long after the last update a route is considered unreachable	180 s
garbage-timer	How long an unreachable route remains in the table before deletion	120 s

These timers are fixed by the implementation rather than tuned per instance in the CLI.

Split Horizon and Poison Reverse

Split Horizon

Split horizon prevents a router from advertising a route back on the interface through which it was learned. This eliminates the most common two-node routing loop scenario. Split horizon is enabled by default and should remain enabled on all point-to-point and broadcast links.

Disable only on NBMA (non-broadcast multi-access) hub interfaces where the hub must re-advertise spoke routes back onto the same interface:

/routing rip interface-template
add instance=rip1 interfaces=ether-hub split-horizon=no

Poison Reverse

Poison reverse is a stronger form of split horizon: instead of omitting the route, the router advertises it back with metric 16 (unreachable). This accelerates loop detection when a route fails.

/routing rip interface-template
add instance=rip1 interfaces=ether1 split-horizon=yes poison-reverse=yes

Poison reverse increases update packet size. For networks with stable topology and no convergence issues, the default (split horizon only) is sufficient.

Route Redistribution

Redistribution is configured in two steps on the instance: select which route classes enter the pipeline, then optionally attach a filter chain to control which individual routes are advertised.

Redistributing Connected and Static Routes

/routing rip instance
set rip1 redistribute=connected,static

Without a filter, all connected and static routes are redistributed with the default metric (1). This is appropriate for simple networks where all connected prefixes should be visible to RIP neighbors.

Controlling Redistribution with Filters

Attach an out-filter-chain to select which routes are advertised. Redistributed routes keep RIP’s default metric because RouterOS 7 does not support set rip-metric as a filter action.

/routing rip instance
set rip1 redistribute=connected,static out-filter-chain=rip-out

/routing filter rule
# Advertise management LAN
add chain=rip-out rule="if (protocol connected && dst in 10.99.0.0/24) { \
    accept }"

# Advertise site aggregates from static routes
add chain=rip-out rule="if (protocol static && dst in 10.0.0.0/8 && dst-len <= 24) { \
    accept }"

# Reject everything else
add chain=rip-out rule="reject"

The default action at the end of a filter chain is reject. Always add an explicit reject rule as the last entry to make this visible in the configuration.

Redistributing OSPF Routes into RIP

Redistributing OSPF into RIP is common when an OSPF core connects to legacy RIP spokes. Apply a strict prefix filter to avoid leaking transit or summary routes from the OSPF domain.

/routing rip instance
set rip1 redistribute=connected,ospf out-filter-chain=rip-out

/routing filter rule
# Connected routes
add chain=rip-out rule="if (protocol connected) { accept }"

# OSPF routes within the site aggregate only
add chain=rip-out rule="if (protocol ospf && dst in 10.1.0.0/16 && dst-len <= 24) { \
    accept }"

add chain=rip-out rule="reject"

Keep redistribution filters conservative. RIP still has a 15-hop maximum, so only advertise the routes the downstream domain actually needs.

Redistributing BGP Routes into RIP

/routing rip instance
set rip1 redistribute=bgp out-filter-chain=rip-out

/routing filter rule
# Accept only specific BGP prefixes
add chain=rip-out rule="if (protocol bgp && dst in 203.0.113.0/24) { \
    accept }"

add chain=rip-out rule="reject"

Never redistribute a full BGP table into RIP without strict filtering — a single leaked default or full-table entry can black-hole traffic when it hits metric 16.

Inbound Route Filtering

Use in-filter-chain to control which routes received from RIP neighbors are installed in the routing table:

/routing rip instance
set rip1 in-filter-chain=rip-in

/routing filter rule
# Accept routes within the expected address space only
add chain=rip-in rule="if (dst in 10.0.0.0/8) { accept }"

# Reject default route and anything outside expected range
add chain=rip-in rule="reject"

Complete Example: Hub Router with Redistribution

A hub router acting as the RIP domain boundary, redistributing connected management prefixes and selected static routes to two spoke sites:

          [Upstream / OSPF core]
                    │
               ether1 (10.0.0.1/30)
         ┌─────────────────────────┐
         │  hub-router             │
         │  RIP domain gateway     │
         └────┬──────────┬─────────┘
           ether2      ether3
         RIP spoke 1  RIP spoke 2
         10.1.0.0/24  10.2.0.0/24

# 1. RIP instance
/routing rip instance
add name=rip1 routing-table=main \
    redistribute=connected,static \
    out-filter-chain=rip-out

# 2. Interface templates
/routing rip interface-template
# Spoke links — MD5 authentication
add instance=rip1 interfaces=ether2 authentication=md5 authentication-key=SpokePSK
add instance=rip1 interfaces=ether3 authentication=md5 authentication-key=SpokePSK
# Management LAN — passive; no updates to hosts
add instance=rip1 interfaces=ether-mgmt passive=yes

# 3. Redistribution filter
/routing filter rule
# Hub management prefix
add chain=rip-out rule="if (protocol connected && dst in 10.99.0.0/24) { \
    accept }"

# Site aggregates
add chain=rip-out rule="if (protocol static && dst in 10.0.0.0/8 && dst-len <= 24) { \
    accept }"

# Drop everything else
add chain=rip-out rule="reject"

Monitoring and Troubleshooting

View Neighbors

/routing rip neighbor print detail

Each neighbor entry shows the neighbor address, the interface through which it was learned, and the time since the last update was received.

View RIP Routes

/routing route print where protocol=rip

Shows all routes received via RIP before filtering. Compare with the active routing table to verify installed routes:

/routing route print where protocol=rip

View Interface State

/routing rip interface-template print detail

Enable Debug Logging

/system logging
add topics=rip,debug action=memory

Review log output:

/log print where topics~"rip"

Disable after troubleshooting — RIP debug logging is verbose:

/system logging remove [find topics~"rip"]

Common Problems

No neighbors forming

• Confirm both routers have an interface-template matching the shared interface
• Check for firewall rules blocking UDP port 520
• Verify authentication type and key match exactly on both sides
• Confirm send is not set to disabled on either side

Routes not received from neighbor

• Check in-filter-chain is not rejecting the routes
• Verify the neighbor is not on a passive interface
• Check split horizon is not suppressing the route (common on hub NBMA interfaces)

Redistributed routes not appearing on remote routers

• Confirm redistribute= includes the source protocol on the redistributing router
• Check out-filter-chain is not rejecting the route
• Verify the metric is ≤ 15; metric 16 = unreachable

Routes show metric 16 (route count exceeded)

• The route has passed through more than 15 hops
• Rethink network topology — flatten the path or migrate to OSPF
• Check for routing loops causing the hop count to increment

RIP vs OSPF: Choosing the Right Protocol

Criteria	Choose RIP	Choose OSPF
Network size	≤ 10 routers, ≤ 15 hops	Any size
Topology complexity	Simple linear or star	Mesh, hierarchical, multi-site
Convergence requirements	Minutes acceptable	Seconds required
Staff expertise	Minimal routing knowledge	Familiar with link-state concepts
Legacy interoperability	Required	Not required
Variable-length subnets	RIPv2 (required)	Fully supported

Use RIP when:

• The network is small (fewer than 10 routers) and will not grow significantly
• Simplicity and minimal configuration are priorities over convergence speed
• Legacy CPE or appliances only support RIP

Use OSPF when:

• The network has more than 15 hops or multiple redundant paths
• Fast convergence (sub-minute) is required
• You need route summarisation at area boundaries
• The network is expected to grow

For networks on the boundary (5–15 routers), OSPF is the better long-term choice — the additional configuration complexity pays off quickly as the network grows.

Related Topics

• OSPF — link-state IGP for larger or more complex networks
• Route Filters — routing filter rule syntax for redistribution and inbound policy
• Route Selection — how RouterOS selects the best path from multiple protocols
• BFD — sub-second failure detection that can be paired with dynamic routing protocols