I was thinking today about the first Cisco exam I ever took. Its been over 7 years since I first sat for my CCNA Route Switch exam. The CCNA has changes a lot since then. One of these changes was the removal of the RIP protocol across the CCNA,CCNP, and CCIE certifications. RIP has been around forever and gone through multiple iterations with v2 and NG. While it may not be on the exams today, it’s a fundamental protocol that believe it or not is still out there. On that note I wanted to make a post that clears up a common misconception with the RIP protocol. That is the use case for the “passive interface” command. I have seen this command used as a security mechanism for RIP in multiple use cases and documents to stop routing updates. While it does stop routing updates, it only stops updates from being sent to its neighbor over multicast, however it can still receive these updates. I believe this confusion comes from the use of the “passive interface” command with OSPF and EIGRP. For these protocols the command actually filters out hello packets stopping the routers from ever becoming neighbors. Not so with RIP. Lets show this in a lab.

For this lab POC I used a simple topology shown in Figure 1

Figure 1

In this setup R1 is setup for Rip and is advertising its f0/0 interface and its lo1 interface. R2 is configured the same. The only difference is on R1 the “passive interface” command is set for f0/0. We can see this setup in Figures 2 & 3.

Figure 2

Figure 3

Following the misconception, this should prevent lo1 on R2 from showing up in the routing table. However this is not the case as we can see in Figure 4. As we can see the route for lo1 shows up in the table from RIP even though the passive interface is used.

Figure 4

Conclusion: While not commonly used these days RIP is still out there. Due tot he use of passive interface on more common protocols like OSPF or EIGRP, the use case on RIP can be dangerously miss used. If used like this in a production system a Network Admin could get a false sense of security that their route table is protected. In reality any user with a L2 connection to the device can inject routes into the table.