12-17-2012 01:01 AM - edited 03-04-2019 06:25 PM
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
12-17-2012 01:10 AM
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
12-17-2012 01:32 AM
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
12-17-2012 01:37 AM
Sorry for the doubling of text. Whenever, I copy and paste, the browser paste's everything twice...
12-17-2012 01:43 AM
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
12-17-2012 02:15 AM
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?
12-17-2012 02:18 AM
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
12-17-2012 02:25 AM
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
???
12-17-2012 02:31 AM
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
12-17-2012 02:38 AM
12-17-2012 02:39 AM
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
12-17-2012 02:47 AM
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
12-17-2012 02:50 AM
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
Hope to help
Giuseppe
12-17-2012 03:02 AM
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
12-17-2012 03:03 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide