My friends,
Once again: An extended ACL receives different input values depending on whether it is used in a distribute-list directly, or whether it is used in a route-map that is subsequently used in a distribute-list.
Consider the following topology:
R1 --- R2
R1 has a loopback 10.255.255.1/32, R2 has a loopback 10.255.255.2/32. They are connected through a network 10.0.12.0/24; R1 is 10.0.12.1/24, R2 is 10.0.12.2.
To demonstrate the value an ACL is going receive, I will be using an ACL in the following form:
access-list 100 permit ip any any log
The log keyword is going to log the details of the parameters passed to the ACL so that we can exactly see what data have been passed to the ACL for matching.
So consider the following configuration of both routers:
R1:
access-list 100 permit ip any any log
!
interface Lo0
ip address 10.255.255.1 255.255.255.255
!
interface e2/0
ip address 10.0.12.1 255.255.255.0
no shutdown
!
router eigrp 1
network 10.0.0.0
R2:
interface Lo0
ip address 10.255.255.2 255.255.255.255
!
interface e2/1
ip address 10.0.12.2 255.255.255.0
no shutdown
!
router eigrp 1
network 10.0.0.0
R1 has the ACL created but it is not applied yet; it's just ready.
After the adjacency is up, let's see what gets logged if I apply the ACL 100 in the outbound direction on R1:
R1(config)#router eigrp 1
R1(config-router)#distribute-list 100 out e2/0
R1(config-router)#
*Sep 12 10:06:18.723: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (Ethernet2/0) is resync: intf route configuration changed
*Sep 12 10:06:18.747: %SEC-6-IPACCESSLOGNP: list 100 permitted 0 0.0.0.0 -> 10.255.255.1, 1 packet
So what values do we have here?
- 0 stands for IP protocol; this will always be 0 for ACLs used in routing policies
- 0.0.0.0 is the next hop address; for outbound advertised routes, this will always be 0.0.0.0
- 10.255.255.1 is the network address being advertised to R2
In other words, when the ACL is used in a distribute-list directly in the outbound direction, the "source" part of the ACL entry will always see the value 0.0.0.0, and the "destination" part of the ACL entry will see the actual network IP address of the advertised route. Note that the netmask of this route is not passed to the ACL; in other words, an ACL used directly in a distribute-list cannot be used to match on netmasks of the advertised routes.
Let's now remove the ACL from the outbound direction on R1, and place it into the inbound direction:
R1(config-router)#no distribute-list 100 out e2/0
R1(config-router)#distribute-list 100 in e2/0
R1(config-router)#
*Sep 12 10:12:11.963: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (Ethernet2/0) is resync: intf route configuration changed
*Sep 12 10:12:12.063: %SEC-6-IPACCESSLOGNP: list 100 permitted 0 10.0.12.2 -> 10.255.255.2, 1 packet
What do we have here now?
- 0 is the IP protocol; again, it is always going to be 0
- 10.0.12.2 is the advertising router's address, in this case, R2; thus, it is a potential next hop IP
- 10.255.255.2 is the network advertised by R2
Again, we see the next hop address being passed as the "source IP" to the ACL, and the address of the advertised network being passed as the "destination IP" to the ACL. Again, there is no netmask here; an ACL used directly in a distribute-list cannot be used to match on netmasks of advertised networks.
Let's now change the scenario - stop using the ACL in the distribute-list directly; instead, let's "encapsulate" it into a route-map, and test again in an outbound direction:
R1(config-router)#no distribute-list 100 in e2/0
R1(config-router)#exit
R1(config)#route-map Test permit 10
R1(config-route-map)#match ip address 100
R1(config-route-map)#exit
R1(config)#router eigrp 1
R1(config-router)#distribute-list route-map Test out e2/0
R1(config-router)#
*Sep 12 10:18:36.959: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (Ethernet2/0) is resync: intf route configuration changed
*Sep 12 10:18:36.975: %SEC-6-IPACCESSLOGNP: list 100 permitted 0 10.255.255.1 -> 255.255.255.255, 1 packet
What we now see is something quite different:
- 0 is the IP protocol; it will always be 0 for this kind of ACL use
- 10.255.255.1 is the address of the advertised network
- 255.255.255.255 is the netmask of the advertised network
In other words, when the ACL is used in a route-map, and the route-map is then used in a distribute-list, the parameters passed to the ACL are very different: The address of the network is passed as the "source IP", and the netmask of the network is passed as the "destination IP".
And what about the opposite direction, inbound?
R1(config-router)#no distribute-list route-map Test out e2/0
R1(config-router)#distribute-list route-map Test in e2/0
R1(config-router)#
*Sep 12 10:24:19.879: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (Ethernet2/0) is resync: intf route configuration changed
*Sep 12 10:24:33.383: %SEC-6-IPACCESSLOGNP: list 100 permitted 0 10.255.255.2 -> 255.255.255.255, 1 packet
Again, it is:
- 0 as the IP protocol
- 10.255.255.2 as the address of the learned network
- 255.255.255.255 as the netmask of the learned network
So to sum up:
- If the ACL is used directly in a distribute-list, then:
- Protocol = 0 (matches "ip")
- Source = advertising router's address; will be 0.0.0.0 for outbound routes, and the IP address of the advertising router for inbound routes (potential next-hop IP)
- Destination = address of the advertised network
- If the ACL is used in a route-map which is then used in a distribute-list, then:
- Protocol = 0
- Source = address of the advertised network
- Destination = netmask of the advertised network
This is what makes the behavior different.
Please note that these rules are only valid for IGP protocols; BGP might be different, but to test this for BGP, I am leaving this to you as an exercise ;) The method of testing would similar to what you see above. If you test this in a lab, keep in mind that logging messages from ACLs are rate-limited; to flush the ACL logging cache to the log immediately, you may need to enter the clear access-list counters command.
Best regards,
Peter
