This post is part of a series of blogs about RIP functionning from the basic to the more complex operation. Let’s recall that RIP stands for Routing Information Protocol and is an IGP (Interior Gateway Protocol) in the same category as OSPF, EIGRP, etc.; most implementations of RIP are not centralized (distributed) meaning that no synchronisation exists between routers in the same routing domain. But let’s retain that RIP could’ve been implemented in a centralized manner such as the other link-state protocols…
In this post we’ll check the operation of one of RIP features: the ECMP or Equal Cost Maximum Paths.
lab setup
Our network setup is based on Cisco technology emulated routers under GNS3. The test network is a two routers networks that are connected by multiple physical links (almost 3). This setup is sufficient to show the logic behind the support of ECMP in RIP.
In this lab R2 (to the right) advertises 2.2.2.2/32 subnetwork to R1 via RIP.
R1 processes three equal paths through interfaces fa0/0, fa1/0 and fa1/1 to join R2 loopback0 interface subnet.
First, R1 uses R2 updates to populates its RIP database (we show the content using the show ip rip database command)
Because RIP is configured to accept four equal cost paths by default, it accepts the three of them (the advertised routes by R2)
R1 default routing table (or global routing table) is populated next showing some important information about the traffic sharing count, the outgoing interface, the next hop, etc.
RIP timers modification and first test: reduce ECMP to 2
The protocol (RIP) in router R1 is configured to defaults: 30 seconds for update interval, 180 seconds to invalidate a path starting from the last update, the holddown of a route (down) is 180 seconds, and the flush time is 240 seconds…
To see those timers also into play (to see how the ECMP operation may correlate to them), we change their default values to 30, 90, 180 and 240 seconds respectively (we only changed the invalid time to a value different from the holddown).
At T0 and under router configuration mode, we change the maximum accepted equal cost paths from 4 to only 2 and observe the effect on tables : rip database, default routing table and cef (forwarding table that is an augmented global routing table with lower layer forwarding information)
We notice that in RIP database, the third path has disapeared after 90 seconds of the invalid timer
how routing table react to ECMP reduction
We redo our test and check how default routing table react by using debug ip routing to log all routing table related events
In this Cisco router, as soon as the feature is configured the route (including the paths) are deleted waiting for the next updates to rebuild the entry again. This is very important to include in consideration when adding the feature in production: the fact that all the routing information is flushed could cause routing issues, or loops the time the routing is populated again…
redo the same test and check the wire
Let’s redo the same test and check what happens on the wire (using Wireshark or equivalent software or material that captures trafic on the wire) at the control plane
On the path (fa1/0) that was deleted from the routing table (because of the maximum paths limit) R1 sends an update that includes the 2.2.2.2/32 subnetwork
split horizon not in action at R1
If the route (via path fa1/0) was in the routing table the split horizon rule would’ve prevented it from being advertised back to the advertiser (R2).
Because the split horizon check is done against the routing table (and not the updates contained in the routing protocol update packets), the 2.2.2.2/32 is sent back to R2.
In R2, the route is not being installed because of the connected subnet having the lowest admin distance.
This is another limitation that could impact our routing domain information coherence and cause permanent or temporay loops.
as conclusion
Configuring ECMP would give control on the number of equal paths to a route to be included in default or global routing table. In RIP this number should be greater than the available paths to prevent a situation where some routing information is looped back to originating routers (in our case R2)… such as in our test lab setup!
We’ve also the split-horizon security is not working is bypassed for the simple reason that we’ve prevented a valid path in RIP local RIB from being installed in the default routing information (the table used for effective routing). The updated get adverstised back because split-horizon rule is not checked against the default routing table…
We conclude also the ECMP in the case of RIP is a local feature meaning that we applied to R1, R2 has no idea about it and could install the same link in its table if its ECMP accepts more than 3 paths to a route from R1… it is logically a problematic situation where R2 sees only two paths to router R1 and R1 sees more than 3 in its routing table!
