Configuring Distribute-lists with OSPF

Carlton Patterson · ‎12-17-2012

Hello community

I'm trying to configure the a distribute list on ospf but I keep on getting the following error message:

% This command only accepts named standard IP access-lists.

The access-list that I'm trying to apply is:

ip access-list extended router2nets

remark DistributteInOSPF_150.2.0.0

permit IP 150.2.0.0 0.0.0.255 any ip access-list extended router2nets
remark DistributteInOSPF_150.2.0.0
permit IP 150.2.0.0 0.0.0.255 any

Can someone please explain why I'm getting that message?

Cheers

Carlton

Peter Paluch · ‎12-17-2012

Hi Carlton,

Extended ACLs have no meaning when used in distribute-list command. If an extended ACL is used for packet filtering, it can check source IP, destination IP, protocol, ports and optionally other attributes of packets. However, if such an ACL is used in a distribute-list that filters IP networks in routing protocol updates, what is a source IP in this case? And what would be the destination IP? What is the protocol?

You see, the ACLs were originally designed for packet filtering and they are merely forced into filtering the contents of routing protocol updates when used in distribute-lists. Many attributes ACLs can try to match on packets have no meaning in distribute-lists. That is why using extended ACLs may not even be supported in a particular routing protocol. This is what the router is currently telling you.

If you rewrite your ACL into a standard ACL then the router should accept it. A standard ACL matches only a single parameter - a source IP when used as a packet filter, and the network IP address when used in a distribute-list. Here, there is no ambiguosity of what goes into the ACL and what is being matched by it.

Even better, though, you should use the prefix lists when configuring distribute-lists. Prefix lists are evaluated in a more efficient manner than ACLs when used in distribute-lists, and they have a strong advantage: they can match also the netmask of the network, not just its IP address (as opposed to ACLs!), and are much more readable.

Please feel welcome to ask further!

Best regards,

Peter

Carlton Patterson · ‎12-17-2012

Peter that's great mate.

So I have the following routes in my table and I want to only distribute (or allow) 150.2.2.0 in the table. Can you show me how I would apply a prefix list

170.7.0.0/24 is subnetted, 1 subnets

O 170.7.7.0 [110/20] via 10.0.1.1, 00:00:04, Ethernet1/0

C 16.0.0.0/8 is directly connected, Ethernet1/1

10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks

C 10.0.0.12/30 is directly connected, FastEthernet0/0

O 10.0.1.1/32 [110/10] via 10.0.1.1, 00:00:04, Ethernet1/0

O IA 10.0.0.0/30 [110/11] via 10.0.1.1, 00:00:04, Ethernet1/0

C 10.0.1.0/29 is directly connected, Ethernet1/0

O 10.0.0.4/30 [110/2] via 10.0.0.13, 00:00:05, FastEthernet0/0

C 192.168.1.0/24 is directly connected, FastEthernet0/1

150.1.0.0/32 is subnetted, 1 subnets

O 150.1.1.3 [110/11] via 10.0.1.1, 00:00:05, Ethernet1/0

150.2.0.0/24 is subnetted, 1 subnets

O E1 150.2.2.0 [110/31] via 10.0.1.1, 00:00:05, Ethernet1/0

150.3.0.0/24 is subnetted, 1 subnets

O E2 150.3.3.0 [110/20] via 10.0.0.13, 00:00:05, FastEthernet0/0

C 15.0.0.0/8 is directly connected, Ethernet1/2

O*E2 0.0.0.0/0 [110/1] via 10.0.0.13, 00:00:05, FastEthernet0/0      170.7.0.0/24 is subnetted, 1 subnets
O       170.7.7.0 [110/20] via 10.0.1.1, 00:00:04, Ethernet1/0
C    16.0.0.0/8 is directly connected, Ethernet1/1
     10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
C       10.0.0.12/30 is directly connected, FastEthernet0/0
O       10.0.1.1/32 [110/10] via 10.0.1.1, 00:00:04, Ethernet1/0
O IA    10.0.0.0/30 [110/11] via 10.0.1.1, 00:00:04, Ethernet1/0
C       10.0.1.0/29 is directly connected, Ethernet1/0
O       10.0.0.4/30 [110/2] via 10.0.0.13, 00:00:05, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
     150.1.0.0/32 is subnetted, 1 subnets
O       150.1.1.3 [110/11] via 10.0.1.1, 00:00:05, Ethernet1/0
     150.2.0.0/24 is subnetted, 1 subnets
O E1    150.2.2.0 [110/31] via 10.0.1.1, 00:00:05, Ethernet1/0
     150.3.0.0/24 is subnetted, 1 subnets
O E2    150.3.3.0 [110/20] via 10.0.0.13, 00:00:05, FastEthernet0/0
C    15.0.0.0/8 is directly connected, Ethernet1/2
O*E2 0.0.0.0/0 [110/1] via 10.0.0.13, 00:00:05, FastEthernet0/0

R4(config-router)??????????

Cheers

Carlton Patterson · ‎12-17-2012

Sorry for the doubling of text. Whenever, I copy and paste, the browser paste's everything twice...

Peter Paluch · ‎12-17-2012

Hi Carlton,

This should do the trick:

configure terminal

ip prefix-list OSPF permit 150.2.2.0/24

router ospf 1

distribute-list prefix OSPF in

end

Please note that in case of OSPF, the distribute-list will affect only your local routing table. Other routers will still see the routes you have filtered out, even the routers that are using you as the next hop. This is a principial property of link-state routing protocols. You have to be careful not to create blackholes or routing loops by this filtering.

Best regards,

Peter

Carlton Patterson · ‎12-17-2012

Hi Peter,

I applied to config, however I can no longer see 150.2.2.0

C 16.0.0.0/8 is directly connected, Ethernet1/1

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

C 10.0.0.12/30 is directly connected, FastEthernet0/0

C 10.0.1.0/29 is directly connected, Ethernet1/0

O 10.0.0.4/30 [110/2] via 10.0.0.13, 00:00:56, FastEthernet0/0

C 192.168.1.0/24 is directly connected, FastEthernet0/1

150.3.0.0/24 is subnetted, 1 subnets

O E2 150.3.3.0 [110/20] via 10.0.0.13, 00:00:46, FastEthernet0/0

router ospf 1

router-id 4.4.4.4

log-adjacency-changes

default-information originate

distribute-list prefix OSPF in Ethernet1/0

!

ip prefix-list OSPF seq 5 permit 150.2.2.0/24

Any ideas?

Peter Paluch · ‎12-17-2012

Hi Carlton,

Would you mind trying removing the Ethernet1/0 from your distribute-list command and using it just in the form I suggested earlier, without the interface name? Thanks!

Best regards,

Peter

Carlton Patterson · ‎12-17-2012

Hi Peter,

With:

router ospf 1

router-id 4.4.4.4

log-adjacency-changes

default-information originate

distribute-list prefix OSPF in

All OSPF routes are gone:

Gateway of last resort is not set

C    16.0.0.0/8 is directly connected, Ethernet1/1
     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.0.0.12/30 is directly connected, FastEthernet0/0
C       10.0.1.0/29 is directly connected, Ethernet1/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
C    15.0.0.0/8 is directly connected, Ethernet1/2

???

Peter Paluch · ‎12-17-2012

Carlton,

Are you running this in Dynamips/GNS3 or on real hardware? I've just tested the suggested config and it works for me... There is something strange going on here. Can you perhaps post the entire configuration of the router you're configuring the distribute-list on?

Best regards,

Peter

Carlton Patterson · ‎12-17-2012

Hi Peter,

Yes I'm running thisn in GNS3.

Attached is the entire config

Jose Jara · ‎12-17-2012

Hi Peter,

you can use extended ACLs for filtering in IGPs, the source IP will be the router that originated the prefix (in OSPF the router-id) and the destination will be the prefix that you want to filter.

By the way, regarding the behavior of distribute-list in OSPF, I agree with you but there are exceptions:

- Distribute-list in:

Applied on an ABR, it will filter the prefixes specified in the ACL from entering the route table, plus the LSAs type 3 to enter the area which is attached. Let's say that ABR is connected to Area-1, and it has type 3 of Area 2, it will filter those to enter Area-1. The distance 255 will do the same.

Applied on an ABR attached to a NSSA, it will filter the prefixes specified plus sending the type 5 LSAs to the Backbone. To be accurate, this has to be done on the ABR which is doing the translation of Type-7 to Type-5. This router will be the ABR with the highest router-ID according to NSSA RFC 1587. The distance 255 will do the same. Here, in an ABR attached to a NSSA, you need to clear the OSPF process.

- Distribute-list out:

Applied on an ASBR it will prevent the generation of the external LSAs.

This is what I have seen running tests to see the behavior of the protocol but, as you said, in real life you have to be careful as you can create black holes.

HTH,

Jose

Peter Paluch · ‎12-17-2012

Hello Jose,

you can use extended ACLs for filtering in IGPs, the source IP will be  the router that originated the prefix (in OSPF the router-id) and the  destination will be the prefix that you want to filter.

I absolutely agree but I did not want to confuse Carlton with too much detail here. My point was that ACLs are by far not the ideal tools to be used in distribute-lists because they are cumbersome - sometimes they get routing source/network as the source/destination pair. In other situations, they get network/netmask as the source/destination pair. It's just not consistent. Compounded with the fact that in many situations, you are not able to perform match on the netmask, the ACLs seem to be just inadequate to be used in distribute-lists at all.

Applied on an ABR, it will filter the prefixes specified in the ACL from entering the route table, plus the LSAs type 3 to enter the area which is attached ...

Applied on an ABR attached to a NSSA, it will filter the prefixes specified plus sending the type 5 LSAs to the Backbone...

Yes, this is logical because LSA-3 and LSA-7-to-5 are generated based on the contents of the routing table, so if the routing table does not contain the appropriate routes, they can not be injected as LSA-3 or LSA-5 into appropriate areas.

Your knowledge of OSPF is very good, Jose! +5 points as deserved.

Best regards,

Peter

Giuseppe Larosa · ‎12-17-2012

Hello Jose,

for inter area filtering of internal routes on ABR I have seen effective the area filter-list command not the distribute-list that should just prevent installation of the route in the IP routing table without altering the LS DB content.

see

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_ospf/command/ospf-a1.html#GUID-A4EF0934-BA01-4FD7-9456-9348DF445E10

Hope to help

Giuseppe

Carlton Patterson · ‎12-17-2012

Hi guys,

I've decided to abandon filtering with distribute-lists for now.

I have applied the following access list to only allow 150.2.2.0 through ethernet 1/0

access-list 101 remark DistributteInOSPF_150.2.0.0

access-list 101 permit ip 150.2.0.0 0.0.0.255 any

access-list 101 remark P2P with R1

access-list 101 permit ip host 10.0.1.1 any

access-list 101 remark P2P with R1

access-list 101 deny ip any any

However, after applying the access-list to the interface I can still route 150.1.0.0 being advertised through the interface eth 1/0

     170.7.0.0/24 is subnetted, 1 subnets
O       170.7.7.0 [110/20] via 10.0.1.1, 00:04:17, Ethernet1/0
C    16.0.0.0/8 is directly connected, Ethernet1/1
     10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
C       10.0.0.12/30 is directly connected, FastEthernet0/0
O       10.0.1.1/32 [110/10] via 10.0.1.1, 00:04:17, Ethernet1/0
O IA    10.0.0.0/30 [110/11] via 10.0.1.1, 00:04:17, Ethernet1/0
C       10.0.1.0/29 is directly connected, Ethernet1/0
O       10.0.0.4/30 [110/2] via 10.0.0.13, 00:04:18, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
     150.1.0.0/32 is subnetted, 1 subnets
O       150.1.1.3 [110/11] via 10.0.1.1, 00:04:18, Ethernet1/0
     150.2.0.0/24 is subnetted, 1 subnets
O E1    150.2.2.0 [110/31] via 10.0.1.1, 00:04:18, Ethernet1/0
     150.3.0.0/24 is subnetted, 1 subnets
O E2    150.3.3.0 [110/20] via 10.0.0.13, 00:04:18, FastEthernet0/0
C    15.0.0.0/8 is directly connected, Ethernet1/2
O*E2 0.0.0.0/0 [110/1] via 10.0.0.13, 00:04:18, FastEthernet0/

Any ideas why?

Chee

Jose Jara · ‎12-17-2012

Thank you Peter, appreciated

Giuseppe: I totally agree with you. In real life I use/would use the area filter-list command and not the distribute-list.

Best Regards,

Jose.