RIP

RIP (Routing Information Protocol) is a distance-vector interior gateway protocol designed for small to medium-sized networks. RouterOS implements RIPv1 and RIPv2, providing simple yet effective routing for networks where the complexity of link-state protocols like OSPF is unnecessary. RIP uses hop count as its metric, with a maximum path length of 15 hops, making it suitable for networks with limited diameter. The protocol periodically broadcasts entire routing tables to neighboring routers, enabling automatic network discovery and convergence without complex configuration.

RIPv2 enhances the original RIPv1 specification by adding subnet mask information, enabling classless routing that supports variable-length subnet masking (VLSM). RIPv2 also includes authentication mechanisms to secure routing updates and supports route tagging for identifying the origin of routes. Despite its simplicity compared to modern link-state protocols, RIP remains valuable for small enterprise networks, laboratory environments, and scenarios where protocol simplicity takes precedence over advanced features. RouterOS RIP implementation provides both versions with straightforward configuration and reliable operation.

RIP Fundamentals

Understanding distance-vector routing principles is essential for effective RIP deployment and troubleshooting. RIP’s simplicity stems from its straightforward approach: routers share their entire routing tables with neighbors at regular intervals, and each router builds its routing table based on information received from adjacent routers. This approach requires less computational overhead than link-state protocols but introduces different characteristics in terms of convergence behavior and routing loop susceptibility.

Distance-Vector Concepts

Distance-vector protocols operate on the Bellman-Ford algorithm, where each router maintains a distance (metric) and vector (next-hop) for each destination. RIP uses hop count as its metric, where each router along a path adds one to the metric value. A metric of 16 represents infinity in RIP, meaning destinations beyond 15 hops are considered unreachable. This hop count limitation fundamentally restricts RIP to networks with a diameter of 15 routers or fewer, making it unsuitable for large enterprise or service provider networks.

The distance-vector approach means routers have limited topological awareness, knowing only the distance to each destination and the next-hop router to reach it. This localized view contrasts sharply with link-state protocols where each router maintains a complete map of the network topology. The trade-off results in simpler router configuration and lower computational requirements but requires additional mechanisms to prevent routing loops and ensure convergence stability.

RIPv1 vs RIPv2 Comparison

RIPv1 operates as a classful protocol, transmitting only network addresses without subnet mask information. This limitation prevents RIPv1 from supporting VLSM or CIDR, as routers must infer subnet masks based on address class boundaries. RIPv1 also lacks authentication capabilities, making it vulnerable to route poisoning from unauthorized sources. The protocol broadcasts routing updates using IP broadcast address 255.255.255.255, ensuring all devices on a network segment receive updates but limiting scalability in environments with many RIP routers.

RIPv2 addresses these limitations through classless routing support, carrying subnet mask information in each routing update entry. This enables subnetting within classful address boundaries and supports variable-length subnet masks across the network. RIPv2 also includes authentication fields in routing updates, supporting simple password authentication to prevent unauthorized route injection. Additionally, RIPv2 can use multicast address 224.0.0.9 for routing updates, reducing unnecessary traffic on network segments without RIP routers and supporting faster convergence in larger RIP deployments.

Feature	RIPv1	RIPv2
Classful/Classless	Classful	Classless
Subnet Mask Support	No	Yes
Authentication	None	Simple password / MD5
Update Method	Broadcast (255.255.255.255)	Multicast (224.0.0.9)
Route Tagging	No	Yes
VLSM Support	No	Yes

RIP Packet Format

RIP packets transport routing information between adjacent routers using UDP port 520 for both RIPv1 and RIPv2. Each packet contains up to 25 routing entries, with each entry specifying a destination network, its associated metric, and in RIPv2, the subnet mask and route tag. The packet format supports both request and response message types, where routers send requests to query neighboring routing tables and respond with their complete routing tables or specific route information.

Response packets contain the sending router’s current routing table entries, with metrics representing the hop count to each destination. When routers receive response packets, they add one to each received metric and compare the result against their existing routing table entry for that destination. If the new metric is lower or the existing route becomes unavailable, the router updates its routing table and propagates the change to neighboring routers in subsequent updates.

RIP Configuration

RouterOS 7 uses an instance-based RIP configuration model. Each RIP instance is tied to a VRF and has interface templates that define which interfaces participate and how.

RIP Instance

Sub-menu: /routing rip instance

The RIP instance defines the router’s participation in a RIP routing domain. In RouterOS 7, most per-protocol settings (timers, redistribution) are controlled through routing policy rather than instance properties.

RIP instances are created in a disabled state (shown as X in print output). The instance must be explicitly enabled before RIP operates.

# Create a RIP instance
/routing rip instance add name=rip-instance

# Create instance bound to a specific VRF
/routing rip instance add name=rip-lan vrf=main

# Enable the instance (remove the disabled flag)
/routing rip instance set [find name=rip-instance] disabled=no

# View configured instances
/routing rip instance print detail

Property	Type	Description
name	string	Instance name for identification
vrf	VRF name	VRF this instance belongs to
disabled	yes \| no	Disable this instance (X flag)

RIP Interface Template

Sub-menu: /routing rip interface-template

Interface templates define which interfaces participate in RIP and control per-interface behavior. Each template requires both an instance and interfaces parameter.

Interface templates are created in a disabled state (shown as X in print output). RIP does not process routes on the interface until the template is explicitly enabled.

# Enable RIP on a specific interface
/routing rip interface-template add instance=rip-instance interfaces=ether1

# Enable RIP on multiple interfaces
/routing rip interface-template add instance=rip-instance interfaces=ether2
/routing rip interface-template add instance=rip-instance interfaces=ether3

# Enable RIP on a bridge interface
/routing rip interface-template add instance=rip-instance interfaces=bridge-local

# Enable the interface templates (required - created disabled by default)
/routing rip interface-template enable [find instance=rip-instance]

# Configure split horizon
/routing rip interface-template set [find instance=rip-instance] split-horizon=yes

# View interface templates
/routing rip interface-template print detail

Property	Type	Description
instance	string	RIP instance this template belongs to (required)
interfaces	interface name	Interface to enable RIP on (required)
split-horizon	yes \| no	Enable split horizon to prevent routing loops
disabled	yes \| no	Disable this template

RIP Timers

RIP employs several timers to manage routing table updates, timeout routes, and perform garbage collection. Understanding these timers is essential for tuning RIP behavior in different network environments.

Timer Types

The update timer controls the interval between periodic routing table broadcasts. The default of 30 seconds ensures reasonable convergence while avoiding excessive network traffic. Networks with slower links or requiring less frequent updates can increase this interval, though doing so increases convergence time following topology changes.

The timeout timer determines how long a route remains valid without receiving confirmation from the next-hop router. Routes not refreshed within the timeout period are marked as unreachable but remain in the routing table for an additional garbage collection period. The default timeout of 180 seconds (3 update intervals) provides a balance between rapid failure detection and tolerance of occasional missed updates.

The garbage collection timer controls how long unreachable routes remain in the routing table with an infinite metric before removal. During this period, routes with metric 16 propagate to neighbors, ensuring rapid convergence by advertising unreachable destinations. The default 120-second garbage collection period allows time for unreachable route information to propagate throughout the RIP domain.

Timer	Default	Description
update-timer	30s	Interval between periodic routing table updates
timeout-timer	180s	Time before a route is marked as unreachable
garbage-timer	120s	Time before an unreachable route is removed

RIP Route Filtering

Route Filter Rules

Sub-menu: /routing filter rule

Import and export filters control which routes enter or leave the RIP routing table. In RouterOS 7, filters are configured under /routing filter rule with named chains, and match logic is written inside the rule= expression.

# Accept routes from 10.0.0.0/8
/routing filter rule add chain=rip-in rule="if (dst in 10.0.0.0/8) {accept}"

# Reject routes from 172.16.0.0/12
/routing filter rule add chain=rip-in rule="if (dst in 172.16.0.0/12) {reject}"

# Accept 192.168.0.0/16
/routing filter rule add chain=rip-in \
    rule="if (dst in 192.168.0.0/16) {accept}"

# View all filter rules
/routing filter rule print

# View rules for a specific chain
/routing filter rule print where chain=rip-in

RouterOS 7 filters can match rip-metric, but they do not support set rip-metric as a filter action.

Export Filters

# Advertise only 192.168.1.0/24
/routing filter rule add chain=rip-out rule="if (dst in 192.168.1.0/24) {accept}"

# Block default route advertisement
/routing filter rule add chain=rip-out rule="if (dst in 0.0.0.0/0) {reject}"

# View export filter rules
/routing filter rule print where chain=rip-out

RIP Authentication

RIPv2 supports authentication to prevent unauthorized route injection. Authentication is configured per interface-template. RIP authentication requires matching configuration on all routers exchanging updates.

Simple Authentication

Simple authentication uses a plaintext password included in RIPv2 routing updates. While providing basic verification, this method transmits passwords in cleartext. Use MD5 authentication for production deployments.

# Configure simple authentication (RIPv2 only)
/routing rip interface-template set [find interfaces=ether1] \
    authentication=simple authentication-key=YourSecret

MD5 Authentication

MD5 authentication provides cryptographic verification of RIPv2 packets using shared secret keys. Matching keys must be configured on all routers exchanging RIP updates.

# Configure MD5 authentication
/routing rip interface-template set [find interfaces=ether1] \
    authentication=md5 authentication-key=SecureKey123 authentication-key-id=1

Split Horizon and Poison Reverse

Split Horizon

Split horizon prevents routing loops by ensuring routes learned from an interface are not advertised back out the same interface. Split horizon is a configurable property on the interface template.

# Enable split horizon (prevents routing loops)
/routing rip interface-template set [find interfaces=ether1] split-horizon=yes

# Disable split horizon (use only when required for hub-and-spoke topology)
/routing rip interface-template set [find interfaces=ether2] split-horizon=no

# View current split horizon configuration
/routing rip interface-template print detail

RIP Monitoring and Troubleshooting

Viewing RIP Status

# View RIP instance configuration
/routing rip instance print detail

# View RIP interface templates
/routing rip interface-template print detail

# View active RIP interfaces
/routing rip interface print

# View RIP neighbors
/routing rip neighbor print

Monitoring the Routing Table

# View RIP routes in the routing table
/ip route print where rip

# View RIP routes with details
/ip route print detail where rip

Debugging RIP

# Enable RIP packet debugging
/system logging add topics=rip action=memory

# View RIP-related logs
/log print where topic~"rip"

# Disable RIP packet debugging
/system logging remove [find topics=rip]

Troubleshooting Commands

# Verify RIP instance configuration
/routing rip instance print detail

# Check interface templates
/routing rip interface-template print detail

# Check which interfaces are actively running RIP
/routing rip interface print

# Verify neighbor adjacency
/routing rip neighbor print

# Check RIP routes in the routing table
/ip route print where rip

# Verify logging is enabled for RIP
/system logging print where topics~"rip"

RIP Route Redistribution

Route redistribution in RouterOS 7 is controlled through routing policy. Connected routes, static routes, and routes from other protocols can be redistributed into RIP.

# Example: redistribute connected routes into RIP instance
/routing rip instance set [find name=rip-instance] disabled=no

# View the routing table to verify redistributed routes appear
/ip route print where rip

RIP Best Practices

Network design for RIP deployments should prioritize simplicity given the protocol’s fundamental limitations. The 15-hop maximum diameter restricts RIP to networks that can be traversed within 15 router hops, limiting applicability to small enterprise networks, branch offices, and laboratory environments. Larger networks requiring RIP should implement hierarchical design with RIP boundaries at the 15-hop limit.

Authentication on all RIPv2 links prevents unauthorized router participation and route manipulation. Deploy MD5 authentication with strong passwords on all production RIP links. Document authentication configurations securely and implement key rollover procedures before password expiration.

Route filtering enables controlled redistribution between RIP domains and other routing protocols. Implement export filters to advertise only necessary routes, reducing routing table size in downstream devices. Import filters prevent route poisoning from misconfigured or malicious routers. Regular filter review ensures routes remain appropriate as network topology evolves.

Split horizon should remain enabled on all interfaces except those specifically requiring disabled operation, such as hub-and-spoke configurations. Consider network topology when configuring split horizon.

Monitoring RIP health through regular inspection of neighbor states, route counts, and update timing ensures early problem detection. Configure logging for authentication failures and route changes. Establish baseline measurements for comparison during troubleshooting incidents.

RIP Limitations

RIP’s design simplicity introduces several limitations that constrain its applicability in modern networks. The hop count metric provides no awareness of actual link bandwidth, latency, or reliability, potentially resulting in suboptimal routing decisions. A path with many slow links may have the same metric as a path with fewer fast links, despite significantly different performance characteristics.

The distance-vector update mechanism requires complete routing table transmission every update interval, consuming bandwidth and processing resources on networks with large routing tables. This approach contrasts with link-state protocols that transmit only changed topology information, providing more efficient scaling in large networks.

Routing loop susceptibility during convergence represents a fundamental limitation of distance-vector protocols. Although mechanisms like split horizon and triggered updates reduce loop formation probability, complete elimination requires the sophisticated shortest-path-first calculations used by link-state protocols. Networks requiring guaranteed loop-free convergence during topology changes should deploy OSPF or other link-state protocols.

Maximum network diameter of 15 hops severely limits RIP applicability in large enterprise or service provider networks. While sufficient for small deployments, networks exceeding this diameter require multiple RIP domains with redistribution boundaries or migration to alternative protocols.

OSPF - Open Shortest Path First for larger, more sophisticated routing domains
BGP - Border Gateway Protocol for inter-domain and large-scale routing
Routing Overview - General IP routing concepts and configuration
Route Filters - Policy-based route manipulation
Routing Manager - Centralized routing configuration

RIP

RIP