Behavior of distribution lists

[Kevin Dorrell]

Suppose that you have a router runnning RIP v2, and that is receiving advertisment for 10.42.41.0/28 as well as 10.42.41.0/24. I want to remove the route for 10.42.41.0/28 but keep the /24 route. Or even vice versa. I find by experimant that I cannot do it with a distribution list.

<b>

access-list 20 deny 10.42.41.0 0.0.0.15

access-list permit any

router rip

 distribute-list 20 in S0/0

</b>

This does not work - it removes both the /28 route and the /24. It seems that the match is only on the base address of the route, and not on the mask. That is, even access-list 20 deny 10.42.41.0 0.0.0.0 will remove both routes.

This was a surprise to me. Can anyone suggest how to go about filtering the /28 route but leaving the /24, or also (maybe more difficult) how to remove the /24 but leave the /28.

Kevin Dorrell

Luxembourg

[Richard Burts]

The idea of filtering by prefix value and also by prefix length is the forte of prefix lists. But I am not clear if prefix list is supported with RIPv2.

Another alternative that may work is to do the distribute list with an extended access list rather than with a standard access list. Using extended access lists to filter routing updates is a very different process than using extended access lists to filter data packets. Rather than the familiar extended access list syntax representing source_address source_mask destination_address destination_mask when filtering routing updates the extended access list syntax represents prefix_value number_of_bits_significant prefix_mask number_of_bits_significant. So for route filtering the entries of:

10.42.41.0 0.0.0.255 255.255.255.0 0.0.0.0 and

10.42.41.0 0.0.0.255 255.255.255.240 0.0.0.0

would represent the two cases that you want to permit or deny.

Give it a try and let us know what happens.

HTH

Rick

[Kevin Dorrell]

Rick,

I'm afraid the extended access-list did not work at all. Or rather, it did, but it did something completely different to what I was expecting. It may be because the IOS I was using is quite old - 11.2(13) in one case and 12.1(5)T9 in another. But I couldn't find it anywhere in the documentation either - do you have a reference?

But the documentation mentioned only standard access lists, but I did get an experimental result by logging the extended: the "source" address and wildcards represent the advertising router, and the "destination" represented the route - which behaved in the same way as for a standard list. So it looks like the extended list allows you to filter by source router, which also makes sense.

I also considered prefix lists, but I don't see any way I can apply them to RIP. With BGP you apply them with the neighbor command. RIP does have a neghbor command, but it doesn't take any arguments after the IP address, at least not in the versions I was using. I think it is only for BGP.

So I think it is just one to mark down to experience.

Thanks again for the suggestion.

Kevin Dorrell

Luxembourg

[Richard Burts]

Kevin

I am not sure whether this is version dependent. Perhaps it is. I do not have a reference. I found a lot about how things work that is not well documented when I was practicing for the lab, and when I was teaching Cisco classes. This is one of those things.

I am surprised at the results that you got when you logged the processing of the extended access list. In my experience it was not sensitive to the source address of the advertising router.

It may be that there is no support for prefix lists in code as old as what you are testing with. But it is supported for RIP in recent code.

I am not sure what is supported in the code versions that you are running but in current versions of code prefix lists are supported in both EIGRP and RIP. They are not applied on the neighbor command but are applied as an optional parameter in distribute-list (distribute-list prefix ....). We are using prefix lists for EIGRP updates in one of my customers network and are quite pleased with what it does. If you have some routers with fairly recent code give it a try.

HTH

Rick

[Kevin Dorrell]

Rick,

OK, I shall have another go at it with more recent code. I shall be away for a couple of weeks now, but I shall try it as soon as I get back.

BTW, I forgot to mention something about my findings about the source router. They apply to extended access lists on incoming distribute lists. For outgoing lists, the source match was always 0.0.0.0.

Thanks again.

Kevin Dorrell

Luxembourg

[Richard Burts]

I would like to offer a clarification. In my first response I talked about advantages of prefix list filtering of updates and commented that I was not sure whether there was support in RIP code for this feature. When I prepared my second response I did check and verified that there is indeed support for prefix list filtering for RIP in relatively recent versions of the code.

HTH

Rick

[ruwhite]

Extended access lists act different ways with different protocols, rather than different versions of code.... It's one of those really odd hacks that every protocol did different, for various reasons. I _think_, though I'm not positive, that the way they work is:

-- BGP: source prefix, destination network mask

-- EIGRP, RIP, and EIGRP: source prefix, destination source of update

I'm not positive this is true in all circumstances. Time for a tech note--though I really just prefer using prefix lists.

:-)

Russ.W

[limtohsoon]

Hi Rick, Kevin -

I've done a lab test using a Cisco 3660, IOS 12.2(15)T15. I configured RIPv2 as follows:

!

router rip

version 2

network 172.16.0.0

no auto-summary

!

It learns these three routes; 172.16.2.0/24, 10.42.41.0/28, and 10.42.41.0/24.

Router#sh ip route

172.16.0.0/24 is subnetted, 2 subnets

C 172.16.1.0 is directly connected, FastEthernet0/0

R 172.16.2.0 [120/1] via 172.16.1.2, 00:00:01, FastEthernet0/0

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

R 10.42.41.0/28 [120/1] via 172.16.1.2, 00:00:01, FastEthernet0/0

R 10.42.41.0/24 [120/2] via 172.16.1.2, 00:00:01, FastEthernet0/0

I configured a distribute-list to permit only 10.42.41.0/28 and 10.42.41.0/24, as follows:

!

router rip

version 2

network 172.16.0.0

distribute-list 100 in FastEthernet0/0

no auto-summary

!

access-list 100 permit ip host 10.42.41.0 host 255.255.255.240 log-input

access-list 100 permit ip host 10.42.41.0 host 255.255.255.0 log-input

!

Kevin was right; there wasn't any matches because the router was matching the IP address of the advertising router against the "source" address of the ACL. As a result, all the 3 routes were denied.

Configuring the ACL as follows (as per Rick's recommendation) produced the same result as above:

!

access-list 100 permit ip 10.42.41.0 0.0.0.255 255.255.255.0 0.0.0.0

access-list 100 permit ip 10.42.41.0 0.0.0.255 255.255.255.240 0.0.0.0

!

I got the same result when using EIGRP; the extended ACL just doesn't work as it should.

However, the following example using prefix-list indeed works:

!

router rip

version 2

network 172.16.0.0

distribute-list prefix myprefixlist in FastEthernet0/0

no auto-summary

!

ip prefix-list myprefixlist seq 5 permit 10.42.41.0/28

ip prefix-list myprefixlist seq 10 permit 10.42.41.0/24

!

Router#sh ip route

172.16.0.0/24 is subnetted, 1 subnets

C 172.16.1.0 is directly connected, FastEthernet0/0

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

R 10.42.41.0/28 [120/1] via 172.16.1.2, 00:00:14, FastEthernet0/0

R 10.42.41.0/24 [120/2] via 172.16.1.2, 00:00:14, FastEthernet0/0

Router#sh ip prefix-list det

Prefix-list with the last deletion/insertion: myprefixlist

ip prefix-list myprefixlist:

count: 2, range entries: 0, sequences: 5 - 10, refcount: 4

seq 5 permit 10.42.41.0/28 (hit count: 2, refcount: 1)

seq 10 permit 10.42.41.0/24 (hit count: 2, refcount: 1)

distribute-list with extended ACL works when it is used in BGP. Please see example below:

!

router bgp 100

no synchronization

neighbor 172.16.1.2 remote-as 200

auto-summary

!

Router#sh ip bgp

Network Next Hop Metric LocPrf Weight Path

*> 10.42.41.0/28 172.16.1.2 0 0 200 i

*> 10.42.41.0/24 172.16.1.2 26112 0 200 i

*> 172.16.2.0/24 172.16.1.2 0 0 200 i

!

router bgp 100

no synchronization

neighbor 172.16.1.2 remote-as 200

neighbor 172.16.1.2 distribute-list 100 in

auto-summary

!

access-list 100 permit ip host 10.42.41.0 host 255.255.255.240 log-input

access-list 100 permit ip host 10.42.41.0 host 255.255.255.0 log-input

!

Router#sh ip bgp

Network Next Hop Metric LocPrf Weight Path

*> 10.42.41.0/28 172.16.1.2 0 0 200 i

*> 10.42.41.0/24 172.16.1.2 26112 0 200 i

Router#sh access-l

Extended IP access list 100

10 permit ip host 10.42.41.0 host 255.255.255.240 log-input (1 match)

20 permit ip host 10.42.41.0 host 255.255.255.0 log-input (1 match)

Please let me know if you got different results than I did.

Thank you.

B.Rgds,

Lim TS

[Richard Burts]

Lim

I am glad that you did the testing. And I am surprised at the results. It is true that most of my experience with extended access lists for route filtering is in the BGP environment, where they do work as I described and which you prooved. I thought I remembered having done them with other protocols. But the results you report and the results reported by Kevin seem to indicate that my memory was not correct.

So it is a good thing that RIP and EIGRP now both do support prefix list filtering. I continue to believe that prefix lists do this kind of filtering much better than extended access lists.

HTH

Rick

[aravindhs]

Hi Kevin/Rick,

Let us assume that the router is receiving RIPv2 routes for

10.42.41.0/28,

10.42.41.16/28,

10.42.41.32/28 &

10.42.41.48/28.

As per what you have said, as a result of the access-list 20, the distribute-list will deny all the /28 subnets (since it blocks the entire /24 range, as per your experiment) ?

If this is the case, VLSM becomes impossible with distribute-list using a standard ACL, right ?

Do you think this could be software version dependant ?

Also, you have mentioned that it looks to be blocking on the basis of 'base address'. Octet boundary becomes the base address ? or the class of the IP ?

Because, to my understanding, a mask of 0.0.0.255 will block all the /28s that fall in the /24 range also. But a 0.0.0.15 should not be blocking the entire /24s.

Any thoughts Rick/Kevin ?

Thanks in advance !

Arav

[Kevin Dorrell]

Hi Arav,

By "base address", I mean the lowest address in the prefix. So extending your example, if I am receiving VLSM advertisments for:

10.42.41.0/28

10.42.41.16/28

10.42.41.32/28

10.42.41.48/28

10.42.41.0/24

then the access list will strip the 10.42.41.0/28 and 10.42.41.0/24 routes, but not the rest. So with a standard access-list, you cannot distinguish between two prefixes with the same base address but different lengths.

I have not yet tried Rick's suggestion of the extended access list, (thanks for that, Rick) but I shall try and do it later on today and report back.

Kevin Dorrell

Luxembourg

[limtohsoon]

Hi Kevin,

Would you mind to also try the following:

access-list <100-199> {permit | deny} ip host 10.42.41.0 host 255.255.255.240

access-list <100-199> {permit | deny} ip host 10.42.41.0 host 255.255.255.0

The first entry will exactly match (prefix & prefix length) the route 10.42.41.0/28, while the second entry will exactly match (prefix & prefix length) the route 10.42.41.0/24.

I've checked on cisco.com; the command "distribute-list prefix in" is supported in RIP for IOS release starting from 12.0. For further details, kindly go to this URL:

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1831/products_command_reference_chapter09186a00800ca697.html#wp1025003

Please let us know the outcome of your coming testing.

Thank you.

B.Rgds,

Lim TS