Filter a RIP route with Distribute List

This one seems worthy of a blog post. Previously, I discovered some esoterically cool stuff about auto-summarization and how in RIPv2, it is possible to create routing "blackholes" when certain routes are auto-summarized across classful boundaries then fed back to the originator of the route. The originator of the route then point back to the routers that auto-summarized the route. The network is a circular so eventually split-horizon stops the route update madness. Bottom line, pings to anything unknown address in the 10.0.0.0/8 network will loop between two routers until the TTL expires. This came about in my final lab ICND2 lab studies. Check out the ICND2 Certification Guide, Appendix F, last question and check the output of the show ip route command. Turns out, EIGRP stops this kind of thing cold with the clever Null0 bit bucket.

But on to the subject of the day.

I discovered how to use a distribute-list to filter a RIPv2 update. The whole exercise was a prelude to how to summarize (there's that word again) external RIP routes into a OSPF network across an Autonomous System Boundary Router (ASBR). The problem became how to start with a clean network where none of the OSPF networks were leaking into the RIP domain and none of the RIP routes were spilling into the OSPF domain. I use those words because I lack the technical-speak for the situation. Suffice it to say, my studies and meanderings have paid off with a nice solution.


Check out the diagram. The ASBR, R4, is running RIPv2 and OSPF. Each serial interface is in the 10.0.0.0/8 network. Since the network command in RIP only accepts classful networks, both S1/0 and S1/1 are included in the RIP process. So a passive-interface Serial 1/1 prevents the RIP advertisement leakage into the OSPF side of the R4.

Looking at the route table on R5, the 10.1.34.0/30 network is advertised since it is a connected interface on R4. That is really not desired because it exposes a part of the OSPF backbone network to the external network. Plus a ping from R5 to R3's S1/0 interface would go unanswered anyway. Investigating the distribute-list command allows for filtering routes based on an access-list. Creating an access-list that denies the subnet address (source address) and attaching itto the outgoing side of R4's Serial 1/0 interface filters the route. In fact, running debug ip rip displays "suppressing null update" for the update going out Serial 1/0. The configuration is listed in the diagram.

Using a passive-interface command on Serial1/0 would also work to suppress the RIP update, but it would defeat redistributing any learned routes to the external RIP domain from R4. That does not seem desirable since the next step in this investigation will be how to get networks in Area 1 (192.168.x.x/16) to talk to networks in the RIP domain (172.16.x.x/16) without using a static route and not exposing any details about Area 0 to RIP. Neat trick... later.