EIGRP filtering with Extended ACLs

Being a distance-vector routing protocol, EIGRP supports route filtering at any point of the network using ACLs, prefix lists and route maps. Today we will mainly look into Extended ACL filtering logic.

Although Standard and Extended ACLs are supported, the matching logic is way different. Both types of ACL can only match prefixes and not prefix length (as compared to prefix-lists). However, Extended ACL gives some flexibility when Inbound filtering is required on multiple access interfaces (NBMA or Ethernet) with more than one neighbor behind such interfaces. It is possible to configure Inbound Extended ACL so that its clauses match not only the received prefixes but the advertising neighbor’s IP address (next-hop) too. Imagine, you can deny specific prefixes from one neighbor and permit similar prefixes from a different neighbor reachable over the same interface.  This is how Inbound Extended ACLs behave. Outbound Extended ACLs act same as Standard ACLs, the only difference is semantics. Let’s review the following example.

Routers in the example are configured as follows

R1
interface FastEthernet0/0
 description WAN
 ip address 192.168.0.1 255.255.255.0
interface Loopback1
 ip address 10.1.0.1 255.255.0.0
interface Loopback2
 ip address 10.2.0.1 255.255.255.0
!
router eigrp 100
 network 10.0.0.0
 network 192.168.0.0
 no auto-summary
R2
interface FastEthernet0/0
 description WAN
 ip address 192.168.0.2 255.255.255.0
interface Loopback1
 ip address 10.3.1.1 255.255.255.0
interface Loopback2
 ip address 10.5.1.1 255.255.255.0
!
router eigrp 100
 network 10.0.0.0
 network 192.168.0.0
 no auto-summary
R3
interface FastEthernet0/0
 description WAN
 ip address 192.168.0.3 255.255.255.0
interface Loopback1
 ip address 10.3.2.1 255.255.255.0
interface Loopback2
 ip address 10.5.2.1 255.255.255.0
!
router eigrp 100
 network 10.0.0.0
 network 192.168.0.0
 no auto-summary

EIGRP has established neighbor relationship and synchronized its topology tables across all three routers. Now, imagine a simple task – R1 must accept all inbound advertisements except 10.3.0.0/16. A standard ACL configured inbound under EIGRP configuration of R1 will fulfill the requirement:

router eigrp 100
 distribute-list 10 in FastEthernet0/0
!
access-list 10 remark Accept all but 10.3.0.0/16
access-list 10 deny 10.3.0.0 0.0.255.255
access-list 10 permit any

The logic is “any prefix that starts with 10.3 is denied”. As stated previously, there’s no way to control prefix-length by using any type of ACL. So, this clause will match 10.3.1.0/24 or 10.3.1.8/30. Let’s make our task look more difficult. Now, R1 must accept all inbound advertisements except prefixes from the range of 10.3.0.0/16 coming from R2.

There are few ways you can do that. One, and probably the only you already though about, is to configure a standard ACL which explicitly denies only R2’s subnets. Now, imagine you have tens of subnets from 10.3.0.0/16 range behind R2 (or multiple neighbors) that have to be filtered. You can easily end up with very long and not optimal ACLs. At the very least it will significantly increase your work load, with no doubts. Inbound Extended ACLs help to automate the process.

router eigrp 100
 distribute-list 100 in FastEthernet0/0
!
access-list 100 remark Accept all but 10.3.0.0/16 from R2
access-list 100 deny ip host 192.168.0.2 10.3.0.0 0.0.255.255
access-list 100 permit ip any any

The logic is “any prefix that comes from 192.168.0.2 and starts with 10.3 is denied”. So, basically, source part of the ACL statement refers to the next hop router’s IP address, while destination part of the ACL statement tells what prefixes to filter.

You may think the same logic applies to an Outbound Extended ACL. Unfortunately, this is not true. EIGRP (or Cisco IOS) logic does not distinguish between different neighbors when it comes to a filtering of the outbound advertisements. The following ACL will not work as you intend.

router eigrp 100
 distribute-list 110 out FastEthernet0/0
!
access-list 110 remark Advertise all but 10.2.0.0/24 to R2
access-list 110 deny ip host 192.168.0.2 10.2.0.0 0.0.0.255
access-list 110 permit ip any any log

You will notice that this ACL does not deny anything. I intentionally added ‘log’ keyword at the end of the permit clause to show you the logic.

Log entry for Outbound Extended ACL

%SEC-6-IPACCESSLOGNP: list 110 permitted 0 0.0.0.0 -> 10.1.0.0, 3 packets

Log entry for Inbound Extended ACL

%SEC-6-IPACCESSLOGNP: list 100 denied 0 192.168.0.2 -> 10.3.1.0, 3 packets

As you may see, the logic of the outbound Extended ACLs does not consider next hop router’s IP address.

Is it possible to achieve the same goal using prefix lists? No!

Route-maps? Well, Yes. Route maps is the most advanced tool to do mostly anything with the filtering. It’s just a question of what do you like more – ACLs or Route Maps?

Leave a Reply

%d bloggers like this: