Hi @russelljames202,
I completely agree on the fundamental matching logic, and It is my understanding that the role of an ACL or prefix list, regardless of its use with a route-map, is used as a matching criteria. What happens from there in terms of result/action is ultimately up to the feature/application leveraging the ACL/prefix-list.
When used with a route-map, the ACL and prefix list still define what qualifies as a match. However, the meaning and outcome of that match are determined by the configurationof the route-map, and—crucially—by the specific feature or application leveraging the route-map. I agree that the use of a route-map in conjunction with an ACL or prefix list is that the latter is controlling what is allowed to be denied/permitted by the route-map.
However, a standard ACL is purely matching on the prefix, not the prefix and the prefix length (or subnet mask). This means that the ACE within the ACL with the line 'deny 10.10.0.0 0.0.255.255' is simplying denying 10.10.x.x/x to be matched in seq 10 of the route-map. This means that any advertised routes from a BGP peer that begin with 10.10 will be a match. This would be the reason that 10.10.0.0/24 is also permitted, because as far as the logic is concerned, as long as the route begins with '10.10', it matches. You could also specify the subnet mask by using an extended ACL. I haven't tried this in a long time so not sure if it still works but probably does. The last testing I did was with monolothic IOS, not IOS-XE. The extended ACL would look something like this 'deny ip 10.10.0.0 0.0.0.0 255.255.0.0 0.0.0.0'. The '0.0.0.0' statements are the wildcards which are effectively saying 'only this exact prefix' and 'only this exact subnet mask', respectively.
It is worth noting that prefix-lists are more efficient in their data structure, so it consumes less resources and is faster to process when compared to an ACL.
So, I believe the answers that INE gave are correct based on the above.
I'll also just mention (for fun) that extended ACLs have different implications based on the application leveraging the ACL, which I mentioned briefly above. For example, filtering in EIGRP and OSPF with extended ACLs are used to match on the advertising or neighboring router that sent the prefix. So with an extended ACL we could say that we want to receive this prefix but we will only accept it from R2. If R3 sent us the prefix we will drop it. BGP is different in the application of the extended ACL. There is a lot of complexity, and the filtering also affects the routing protocols differently; EIGRP filtering inbound prevents incoming routes from entering the topology database. EIGRP filtering out prevents routes in the RIB from being advertised (due to the distance-vector (not hybrid) nature). OSPF inbound filtering prevents routes from entering the RIB, but it can't stop the acceptance of LSAs as that is the core operation of OSPF. Similarly, outbound filtering in OSPF would break many rules, so it is only allowed in specific circumstances. In BGP, filtering stops traffic entering the BGP table, and outbound filtering stops the best-path within the BGP table from being advertised.
Do let me know if you've any further questions! Hopefully I was making sense with the above!
