OSPF Prefix List for Intra Area routes

[Michael Douville]

Hi everyone,

I have been playing around with various prefix list setups. Here I am using OSPF and I have attached the lab picture. I have attached the lab picture below.

 

For a intra-area prefix list I understand that just a distribute list is needed. I have defined the task as follows:

Task: Filter routes coming out of R4 so that you can not see routes 14.0.0.0 to 14.0.3.0 on router R3. Use a 2 prefix entries using 1 deny and 1 permit.

On R3

I set up my prefix list as follows:

ip prefix-list BLOCK14 seq 10 deny 14.0.0.0/22 le 32
ip prefix-list BLOCK14 seq 20 permit 0.0.0.0/0 le 32

My distribute list as:

distribute-list prefix BLOCK14 in

Now if I show my ospf routes on R3 I get:

R3#sh ip route ospf

14.0.0.0/32 is subnetted, 13 subnets
O 14.0.4.1 [110/2] via 192.168.34.2, 00:01:27, GigabitEthernet0/2
O 14.0.5.1 [110/2] via 192.168.34.2, 00:01:27, GigabitEthernet0/2
O 14.0.6.1 [110/2] via 192.168.34.2, 00:01:27, GigabitEthernet0/2
O 14.0.7.1 [110/2] via 192.168.34.2, 00:01:27, GigabitEthernet0/2
O 14.0.8.1 [110/2] via 192.168.34.2, 00:01:27, GigabitEthernet0/2
O 14.0.9.1 [110/2] via 192.168.34.2, 00:01:27, GigabitEthernet0/2

output shortened..........................

I get the output I expect. But if I go downstream to R2 I do not see the same filtering being done:

R2#sh ip route ospf

14.0.0.0/32 is subnetted, 17 subnets
O 14.0.0.1 [110/3] via 192.168.23.2, 00:32:13, GigabitEthernet0/1
O 14.0.1.1 [110/3] via 192.168.23.2, 00:32:13, GigabitEthernet0/1
O 14.0.2.1 [110/3] via 192.168.23.2, 00:32:13, GigabitEthernet0/1
O 14.0.3.1 [110/3] via 192.168.23.2, 00:32:13, GigabitEthernet0/1
O 14.0.4.1 [110/3] via 192.168.23.2, 00:32:13, GigabitEthernet0/1
O 14.0.5.1 [110/3] via 192.168.23.2, 00:32:13, GigabitEthernet0/1

The routes came back!

Interesting huh? Is there an explanation for this? Any help is appreciated.

Thanks!

Mike

[Jon Marshall · Accepted solution]

It is because every router in the same OSPF area has the same LSAs in it's OSPF database and within an area the routes are derived from the LSAs. 

So when you filter routes within an area the way you have all you are doing is stopping the routes from being installed in the IP routing table on the router you are doing the filtering, R4 in this case. 

But R2 still has all the LSAs and it is from these it builds it own routing table. 

If you wanted R2 to also filter those routes you would need the same configuration on that router as well. 

Jon

[Michael Douville]

Thanks Jon much appreciated!  I guess if I understand correctly then, the lSA's shared in area 0 are always going to be the same and all routers will have the same information.  Makes sense as I could look at the DB's and see every router knew the information about all the other routers.  We then have to filter those routes on a per router basis. 

[Tubster123]

Hi Micheal,

The task doesn't say you can't redistribute the loopbacks into OSPF.  Doing this and then filter with a distribute-list at the point of redistribution should achieve the desired results?

Thanks

[Georg Pauwen]

Hello,

on a side note, technically the easiest way to accomplish the same goal would be to use the 'ip ospf prefix-suppression' command on R4 under the loopback interfaces you don't want to advertise, e.g.:

interface Loopback1

ip address 14.0.1.1 255.255.255.0

ip ospf prefix-suppression

!

interface Loopback2

ip address 14.0.2.1 255.255.255.0

ip ospf prefix-suppression

That way, the loopbacks never get anywhere...

[Michael Douville]

Thanks Georg,

That is also true and a command I wasn't aware of.  In this case however I was experimenting with using prefix-list across various protocols to try and get a better understanding.  Sorry I didn't say that up front.  Well now on to BGP, lol.

Thanks!