RIP distribute-lists

I'm working through the BSCI Lab Portfolio and I've come to the Challenge for Redistribution between OSPF and RIP (lab 5-1), The challenge wants me to filter out a couple routes from coming into the RIP process using an extended access list.

The thing I'm confused about is that it says to look at Step 5, which has to do with using prefix lists, which says you can't use an extended access list with distribute lists (which is also what the router tells me when I try it anyway). It seems to contradict itself. So, unless the answer to the challenge is that it's not possible I'm at a loss.

Many thanks to anyone that can shed some light on the situation.

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

jezg76

I remember doing that damn lab back when I was going through that lab manual and I even posted the same question here and I still, to this day, am not sure WTF they wanted you to do.

I know you can filter with extended access-lists in BGP, but I couldn't figure out what they wanted you to do using extended ACLs in RIP.

I guess I hope one day I'll be smart enough to figure it out lol

kalebksp

I went found your post (guess I should have searched first). Some people provided answers, with the exception of last poster no one provided an answer within the confines of the question. I don't know what version of the IOS the last poster was running, but mine won't let me apply an extended ACL to a distribute list.

Oh well, I've moved on. There are better ways to accomplished the goal anyway.

Thanks.

EdTheLad

kalebksp wrote: »

I don't know what version of the IOS the last poster was running, but mine won't let me apply an extended ACL to a distribute list.

Maybe you were trying to apply an "ip access-list" ? did you try the reguar "access-list 101" type?

Anyway i've had a look at this to see if the extended would work with a distribution-list in rip.

So below R1 has multiple addresses created.

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 4 subnets
R 172.16.23.0 [120/1] via 172.16.12.2, 00:00:03, Serial1/0
C 172.16.12.0 is directly connected, Serial1/0
C 172.16.1.0 is directly connected, Loopback0
R 172.16.2.0 [120/1] via 172.16.12.2, 00:00:03, Serial1/0
C 192.168.51.0/24 is directly connected, Loopback51
C 192.168.50.0/24 is directly connected, Loopback50
C 192.168.49.0/24 is directly connected, Loopback49
C 192.168.70.0/24 is directly connected, Loopback70
C 192.168.48.0/24 is directly connected, Loopback48
S 192.168.48.0/22 is directly connected, Null0

I enabled rip debugging to see them being advertised.

R1#debug ip rip
RIP protocol debugging is on
R1#
*Mar 1 02:33:44.515: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (172.16.12.1)
*Mar 1 02:33:44.519: RIP: build update entries
*Mar 1 02:33:44.519: 172.16.1.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 02:33:44.523: 192.168.48.0/22 via 0.0.0.0, metric 1, tag 0
*Mar 1 02:33:44.527: 192.168.48.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 02:33:44.531: 192.168.49.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 02:33:44.531: 192.168.50.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 02:33:44.535: 192.168.51.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 02:33:44.539: 192.168.70.0/24 via 0.0.0.0, metric 1, tag 0

Now i want to filter everything but the /22 route, usually i would use a prefix-list but i'm only interested in the extended access-list way.

R1(config)#access-list 101 permit ip 192.168.48.0 0.0.0.0 255.255.252.0 0.0.0.0
R1(config)#do sho access-li
Extended IP access list 101
10 permit ip host 192.168.48.0 host 255.255.252.0

Now i apply this to RIP.

R1(config)#router rip
R1(config-router)#distribute-list 101 out

R1#
*Mar 1 02:36:53.643: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (172.16.12.1)
*Mar 1 02:36:53.647: RIP: build update entries - suppressing null update
R1#
R1#
*Mar 1 02:37:08.351: RIP: received v2 update from 172.16.12.2 on Serial1/0
*Mar 1 02:37:08.351: 172.16.2.0/24 via 0.0.0.0 in 1 hops
*Mar 1 02:37:08.355: 172.16.23.0/24 via 0.0.0.0 in 1 hops
R1#

As you can see its not working,everything is being blocked.If i change the access-list to permit any any, it forwards everything.Maybe its an issue on my IOS? maybe it's not supported, maybe i'm missing something fundermental here, if so advise.

kalebksp

It seem that I was incorrect about not being able to apply extended access lists to rip's distribute list.

Here's an example of an access list I got to work:

access-list 101 deny ip any 192.168.2.0 0.0.0.255
access-list 101 permit ip any any

This would them block any route with a network address 192.168.2.0-192.168.2.255.

The source portion of the ACL seems to match against the neighbor routers address when applied to an inbound distribute list, I don't know if it matches anything when applied outbound.

EdTheLad

You dont seem to understand how the extended access-list works with filtering.

The source portion matches the network number, the destination portion matches the mask.

access-list 101 deny ip 192.168.2.0 0.0.0.255 255.255.255.252 0.0.0.0

this will block networks 192.168.2.0 -> 192.168.2.255 , which have a /30 mask.

kalebksp

Ummm, well, then would you be able to tell me why when I did it my way it worked, and you said when you did it your way it didn't? Perhaps that is how it works with other routing protocols, but based on what I observed on my routers it's not the case with RIP.

I did try it with the network portion in the source and the mask in the destination before I tried the way I previously posted and it didn't work.

EdTheLad

Ok from internetworking expert.

The confusion for this extended access-list implementation is that when it is called as a distribute-list in IGP the syntax changes. In the previous examples the normal “source” field in the ACL represents the network address, where the “destination” field represents the subnet mask. In IGP distribute-list application the “source” field in the ACL matches the update source of the route, and the “destination” field represents the network address. This implementation allows us to control which networks we are receiving, but more importantly who we are receiving them from.

So it behaves differently from BGP, great i learned something new today, this might come in handy.

vinnyjones

I'm working on this same stupid lab and agree with kalebksp, it doesn't look possible. In the case of IGP distribute lists, the source portion matches up with the update source (router)and the destination the network itsself

According to:
CCIE Routing and Switching Official Exam Certification Guide - By Wendell Odom - Page 424

"One difference between BGP distribute lists and IGP distribute lists is that a BGP distribute list can use an extended ACL to match against both the prefix and prefix length. When used with IGP filtering tools, ACLs called from distribute lists cannot match against prefix length."

It is very clear in the challenge though, it says to use an extended access list to accomplish the task..

helpppp. i'm an obsessive and if i don't find a solution to this problem i'm going to go nuts...