RIP Configuration

RIP Configuration

This guide covers practical RouterOS 7 RIP configuration: building a RIP domain using interface-template 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. Each template is attached to a specific interface and controls how that interface participates in RIP.

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

# Match another RIP-facing interface
add instance=rip1 interfaces=ether2

# Add another specific interface to the same RIP instance
add instance=rip1 interfaces=ether-lan

Use explicit interfaces= matches for RIP interface-templates. Add one template for each interface that should participate in the RIP instance.

Adding Neighbor Interfaces

For point-to-point WAN links and shared segments alike, add the exact interface that should participate in RIP.

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

# Another directly matched interface
add instance=rip1 interfaces=bridge-branch

# Additional routed link participating in RIP
add instance=rip1 interfaces=vlan10

---

Authentication Support

RouterOS 7.15.3 does not expose RIP interface-template authentication parameters such as auth, auth-key, authentication, or authentication-key. This guide omits RIP authentication examples because those commands are not available in the verified version.

---

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
add chain=rip-out rule="if (protocol connected && dst in 10.10.10.0/24) { \
    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) { \
    accept }"

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

Redistributed routes keep RIP’s default metric. RouterOS 7 can match rip-metric in filters, but it does not support set rip-metric as a filter action.

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
add chain=rip-out rule="if (protocol connected) { 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) { \
    accept }"

add chain=rip-out rule="reject"

Keep route selection strict: RIP’s maximum is 15 hops, so only redistribute the prefixes that edge routers actually need.

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) { 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) { \
    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 participating in RIP
add instance=rip1 interfaces=ether2
add instance=rip1 interfaces=ether3
# Management-facing interface participating in RIP
add instance=rip1 interfaces=ether-mgmt

# 3. Redistribution filter
/routing filter rule
# Hub's management prefix
add chain=rip-out rule="if (protocol connected && dst in 10.99.0.0/24) { \
    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) { \
    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

# Confirm the expected interfaces are attached to the RIP instance
/routing rip interface-template print detail

If the neighbor table is empty after 30 seconds, 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 route print where protocol=rip

# 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 route print where protocol=rip 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, and timers
• 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