RIP Configuration

RIP Configuration

This guide covers practical RouterOS 7 RIP configuration: building a RIP domain using interface-template, securing updates with RIPv2 authentication, and redistributing external routes into RIP using routing filters.

RouterOS 7 replaces the legacy /routing rip interface and /routing rip network menus with /routing rip interface-template. All configuration examples on this page use RouterOS 7 syntax.

Basic RIP Instance

Instance Setup

Every RIP deployment starts with an instance. The instance holds global parameters including timers and the routing table binding.

/routing rip instance
add name=rip1 routing-table=main

To verify the instance is active and review its properties:

/routing rip instance print detail

Interface-Template

Interface-templates replace per-interface RIP configuration. A template matches by interface name or by network prefix and applies RIP participation to all matching interfaces.

/routing rip interface-template
# Match a specific interface
add instance=rip1 interfaces=ether1

# Match all interfaces with addresses inside a prefix
add instance=rip1 networks=192.168.10.0/24

# Passive: receive updates but do not send — use for LAN segments
# where this router should receive RIP routes but not advertise to hosts
add instance=rip1 interfaces=ether-lan passive=yes

Passive interfaces are appropriate for LAN-facing ports where no RIP neighbors exist but the connected prefix should still be reachable from the RIP domain via redistribution.

Adding Neighbor Interfaces

For point-to-point WAN links, match by interface name. For segments shared with non-RIP devices, match by network prefix so only the RIP-capable interface participates.

/routing rip interface-template
# WAN link to upstream RIP router
add instance=rip1 interfaces=ether-wan

# Branch LAN — passive, not sending updates to end hosts
add instance=rip1 interfaces=bridge-branch passive=yes

# Matches any interface whose address falls in this range
add instance=rip1 networks=10.10.0.0/16

---

RIPv2 Authentication

RIPv2 supports MD5 and simple (plaintext) authentication. MD5 is strongly preferred for any production deployment. Authentication is configured per interface-template.

/routing rip interface-template
# MD5 authentication — cryptographic integrity check on each update packet
add instance=rip1 interfaces=ether1 auth=md5 auth-key=SecureSharedKey

# Simple (plaintext) — not recommended; use only in isolated lab environments
add instance=rip1 interfaces=ether2 auth=simple auth-key=plaintext-secret

Both sides of an adjacency must use the same authentication type and key. Mismatched keys cause updates to be silently discarded. Verify with:

/routing rip neighbor print detail

---

Route Redistribution

Redistribution in RouterOS 7

RouterOS 7 separates what to redistribute from how to filter it. The RIP instance redistribute parameter selects which route classes enter the redistribution pipeline; a routing filter chain (attached via out-filter-chain) controls which individual routes are accepted.

redistribute value	Source
connected	Directly connected interfaces
static	Static routes
ospf	Routes learned from OSPF
bgp	Routes learned from BGP

Multiple sources are specified as a comma-separated list.

Redistribute Connected and Static Routes

/routing rip instance
set rip1 redistribute=connected,static

Without an output filter, all routes from the selected classes are redistributed with the default metric. For small networks with predictable route tables, this is often sufficient.

Controlling Redistribution with Routing Filters

Attach a filter chain to the instance to select which routes are advertised and to set metrics on individual routes.

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

Filter rules are evaluated top-to-bottom. Routes that match no rule are implicitly rejected.

/routing filter rule

# Redistribute only the management loopback into RIP with metric 1
add chain=rip-out rule="if (protocol connected && dst in 10.10.10.0/24) { \
    set rip-metric 1; accept }"

# Redistribute infrastructure statics within the 172.16.0.0/12 block
add chain=rip-out rule="if (protocol static && dst in 172.16.0.0/12) { \
    set rip-metric 2; accept }"

# Reject everything else (explicit — documents intent)
add chain=rip-out rule="reject"

Redistributing OSPF Routes into RIP

Redistributing OSPF into RIP is common in networks that use OSPF internally and RIP on legacy spoke sites. Apply a strict prefix filter to avoid leaking transit or summary routes.

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

/routing filter rule
# Accept connected routes at low metric
add chain=rip-out rule="if (protocol connected) { set rip-metric 1; accept }"

# Accept only OSPF routes within the site's aggregate block
add chain=rip-out rule="if (protocol ospf && dst in 10.0.0.0/8 && dst-len <= 24) { \
    set rip-metric 3; accept }"

add chain=rip-out rule="reject"

Keep metrics in mind: RIP’s maximum is 15 hops. Routes redistributed from OSPF should be given a conservative metric (3–5) to leave headroom for the RIP domain itself.

Redistributing BGP Routes into RIP

Only redistribute BGP prefixes that edge sites genuinely need. Advertising full BGP tables into RIP risks exceeding the 15-hop metric limit and saturating small routers with large routing tables.

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

/routing filter rule
add chain=rip-out rule="if (protocol connected) { set rip-metric 1; accept }"

# Only redistribute customer aggregates — not transit /30s or default
add chain=rip-out rule="if (protocol bgp && dst in 192.0.2.0/22 && dst-len >= 24) { \
    set rip-metric 4; accept }"

add chain=rip-out rule="reject"

---

Full Example: Hub Router with Redistribution

This example shows a hub router acting as the RIP domain boundary, redistributing connected management prefixes and selected static routes into RIP while protecting against route leaks.

          [Internet / upstream OSPF domain]
                      │
                 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 — redistribute connected + static with filter
/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, full RIP participation
add instance=rip1 interfaces=ether2 auth=md5 auth-key=SpokePSK
add instance=rip1 interfaces=ether3 auth=md5 auth-key=SpokePSK
# Management LAN — passive, no updates sent to hosts
add instance=rip1 interfaces=ether-mgmt passive=yes

# 3. Redistribution filter
/routing filter rule
# Hub's management prefix — redistribute at low metric
add chain=rip-out rule="if (protocol connected && dst in 10.99.0.0/24) { \
    set rip-metric 1; accept }"

# Hub aggregate — allow spoke subnets to reach each other via hub
add chain=rip-out rule="if (protocol static && dst in 10.0.0.0/8 && dst-len <= 24) { \
    set rip-metric 2; accept }"

# Reject everything else — no default route or transit routes into RIP
add chain=rip-out rule="reject"

---

Troubleshooting

No RIP Neighbors Forming

# Verify instance is active and template is matching
/routing rip instance print detail
/routing rip interface-template print detail

# Check neighbor table — should show neighbors after ~30 s
/routing rip neighbor print detail

# Authentication mismatch silently drops updates — confirm keys match on both sides
/routing rip interface-template print detail where auth!=none

If the neighbor table is empty after 30 seconds and no authentication is configured, verify that UDP 520 is not blocked by a firewall rule. RIP uses UDP port 520 for both sending and receiving updates.

/ip firewall filter print where protocol=udp and dst-port=520

Redistributed Routes Not Appearing on Remote Routers

# Confirm redistribute and filter chain are set
/routing rip instance print detail where name=rip1

# Check which routes the filter is passing
/routing filter rule print where chain=rip-out

# Verify routes are in the RIP route table on this router
/routing rip route print

# Check routes appear in the main routing table on the remote router
/ip route print where rip~"."

A misconfigured filter chain silently drops all redistributed routes. To confirm the filter is the issue, temporarily remove it and check whether routes begin propagating.

# Remove filter temporarily
/routing rip instance set rip1 out-filter-chain=""

# Confirm routes now appear on remote router
/ip route print where rip~"."

# Re-attach filter and narrow down the rule causing the reject
/routing rip instance set rip1 out-filter-chain=rip-out

Metric Exceeded (Routes Show Metric 16)

Metric 16 is RIP infinity — the route is unreachable. This happens when:

• The redistributed metric plus the RIP hop count exceeds 15
• A routing loop is causing metric accumulation

# Check metric values being redistributed
/routing rip route print detail

# Verify split horizon is enabled on all interfaces (default: yes)
/routing rip interface-template print detail

Reduce the redistribution metric if redistributed routes are being assigned metrics close to 15. Routes redistributed at metric 4 can only traverse 11 more hops before becoming unreachable.

---

Related Documentation

• RIP — RIP fundamentals, RIPv1 vs RIPv2 comparison, timers, and authentication reference
• Route Filters — Routing filter rule syntax and available matchers and actions
• OSPF Configuration — OSPF configuration for larger networks where RIP’s 15-hop limit is a constraint
• BGP — BGP configuration for redistributing into RIP