RIPv2 on the Cisco ASA (and Why You'd Still See It)

RIP is legacy. Nobody designs a new network around it, and if you proposed running RIPv2 as your core routing protocol in 2020s production you would be asked to leave the room. And yet you will still meet it, usually at an interop boundary where some older device or a third-party appliance speaks nothing else. So it is worth knowing how RIPv2 behaves on a Cisco ASA, if only so you recognise it when it turns up. This is a short, honest entry in our Cisco ASA cluster, built from two real captures that together tell the whole RIP story: it authenticates loudly, and it almost never wins a route.

Every capture here came from an ASAv 9.24(1) in Cisco Modeling Labs, peering with an IOS-XE router, driven over SSH.

The configuration

RIPv2 on the ASA is about as small as routing configuration gets:

router rip
 network 10.0.0.0
 version 2
 no auto-summary

A few things to note. The network 10.0.0.0 statement is classful, RIP takes the major network, not a subnet mask. The version 2 line forces RIPv2, which you want because version 1 is classful and has no authentication at all. And no auto-summary stops RIP collapsing your subnets to their classful boundary, the same reasoning as EIGRP. This is the minimum viable RIPv2, and on the ASA it really is this short.

Reality one: RIP authenticates, and it is loud about failure

RIPv2 supports authentication, and our lab had it turned on with an MD5 key. But the key on the ASA and the key on CORE1 did not line up. Unlike the silent EIGRP AS mismatch elsewhere in this cluster, the ASA does not keep quiet about a RIP authentication failure. It logs it at severity 1:

%ASA-1-107001: RIP auth failed from 10.20.10.2: version=2, type=ffff, mode=3, sequence=10 on interface inside

Read that message, because it is dense with useful detail. RIP auth failed from 10.20.10.2 names the neighbour that sent the update the ASA rejected (that is CORE1). version=2 confirms we are talking RIPv2, not v1. mode=3 is the important field: mode 3 means MD5 authentication. So the ASA is telling you the neighbour presented an MD5-authenticated RIPv2 update, and the authentication did not pass, so the update was dropped. Every RIP update from that neighbour is being discarded and logged until the keys agree.

The severity is the part worth internalising. The %ASA-1- prefix means severity 1, which on the ASA scale is "alert", one step below the most critical level there is. The firewall does not log routine routing chatter at severity 1. It is effectively shouting. A dropped RIP update is not, in the grand scheme, an emergency, but the ASA treats an authentication failure as a security-relevant event, and rightly so: a failing auth check is exactly what you would see if someone were trying to inject bogus routes. So the loud severity is a feature, not noise. If you see %ASA-1-107001 in a buffer, someone's keys are wrong, and you should find out whether it is a benign misconfiguration or something worth investigating. Contrast this with the EIGRP AS-number mismatch, which produces nothing at all, and you get a feel for how differently these protocols behave when something is off.

Reality two: even with auth fixed, the route will not install

Here is the honest heart of the article. Suppose you fix the MD5 key, the authentication passes, and RIP is now happily exchanging valid v2 updates with CORE1. You would expect the RIP-learned route to appear in the table. It does not. And the reason is not a bug, it is administrative distance doing exactly what it is supposed to.

The prefix RIP is advertising, 10.20.20.0/24, is already in the firewall's route table, learned by two other protocols at the same time. Look at the relevant lines from show route on this box:

D        10.20.20.0 255.255.255.0 [90/128512] via 10.20.10.2, 00:08:55, inside
O        10.20.20.1 255.255.255.255 [110/11] via 10.20.10.2, 00:12:31, inside

EIGRP (administrative distance 90) and OSPF (administrative distance 110) are both offering this network. RIP's administrative distance is 120. When multiple protocols advertise the same prefix, the router installs the one with the lowest administrative distance and ignores the rest. 90 beats 110 beats 120, so EIGRP installs the route as D, OSPF sits in reserve, and RIP does not get a look in. The RIP route is perfectly valid; it is simply outranked, and outranked routes never make it into the table.

That, in one route table, is the entire "why you would still see RIPv2, and why it almost never wins" story. RIP survives in the field for legacy interop: a device on the far end speaks it, so you configure it to talk back. But in any network that also runs OSPF or EIGRP, or really anything with a lower administrative distance, RIP's routes lose the tie-break every time. You would not choose RIP; you tolerate it at a boundary. And the moment a better-ranked protocol advertises the same destination, RIP quietly steps aside. For the full administrative-distance walkthrough across all the protocols on this box, see the dynamic routing overview.

The authentication model is the one thing RIPv2 got right

It is easy to be dismissive of RIP, but the authentication story is genuinely worth respecting, and it is the same model you should insist on wherever a routing protocol supports it. RIPv2 with MD5 means the ASA will only accept an update from a neighbour that can prove it holds the shared key. Without that, RIP is trivially spoofable: anyone on the segment could inject routes and the firewall would believe them. The mode=3 in the failure log is the ASA confirming the neighbour tried to use MD5 at all, which is what you want to see even when the keys are wrong, because it means the far end is not falling back to no authentication.

So when you do stand up a RIP interop link, turn authentication on and treat the severity-1 log as your friend. A wrong key produces a loud, specific message that names the offending neighbour and the interface. That is far easier to chase than a protocol that silently accepts anything or silently rejects everything. The failure being noisy is the whole reason a RIP key mismatch is a five-minute fix rather than an afternoon.

So why bother learning it?

Because "rare" is not "never", and the times you meet RIP are exactly the times you are already having a bad day: an acquisition brought in a network you did not design, an old industrial controller only speaks RIPv2, a partner's edge device was configured a decade ago and nobody wants to touch it. In those moments, knowing that the ASA authenticates RIP loudly (so a severity-1 log points you straight at a key mismatch) and that a RIP route will silently lose to any better-ranked protocol (so you should check what else is advertising the prefix before you conclude RIP is broken) is what turns a confusing ticket into a five-minute fix. That is the whole value of this article: not to teach you to deploy RIP, but to help you recognise and reason about it the day it lands on your firewall.

Key Takeaways

• RIPv2 on the ASA is a four-line configuration: router rip, a classful network, version 2, and no auto-summary.
• A RIP authentication failure is logged loudly at severity 1 (%ASA-1-107001). The mode=3 field means MD5. A severity-1 message is the ASA treating a failed auth check as security-relevant, not routine.
• This is the opposite of the silent EIGRP AS-number mismatch: RIP shouts, EIGRP says nothing.
• Even with authentication fixed, the RIP route for 10.20.20.0/24 will not install, because EIGRP (distance 90) and OSPF (distance 110) already advertise it and both outrank RIP's distance of 120.
• You will still see RIPv2 in the field, but almost always for legacy interop, and it almost never wins a route where a better-ranked protocol is also present.
• For the full administrative-distance picture see the dynamic routing overview, and for the rest of the firewall build the Cisco ASA cluster.