It’s easy to assume that an Access-List may be blocking traffic to a Destination IP in a TSHOOT Topology / Trouble ticket, so it is important to know exactly how to read them, and to assess if it applies to your trouble ticket!
IPv4 Standard / Extended / Time-Based ACL review / troubleshooting
I will be as brief as possible as most of this is likely review.
ACL’s are applied to an interface with the command “access-group (acl #/name) (in/out)” with “In” meaning Ingress (inbound) traffic is being filtered based on the ACL criteria, and “Out” meaning Egress or Outbound traffic is being filtered on the interface.
Traffic must either hit an exact match on an ACL line, will be implicitly denied of not explicitly permitted (or explicitly denied), and the line “permit ip any any” is an ‘allow all’ rule that will basically negate the implicit deny all at the bottom of an ACL.
- “sh access-list (#/name)” – This is to view either all or a specific ACL
- “sh int (int)” or “sh run int (int)” – To view if an interface has “access-group …” applied and which direction (ingress or egress) it is being applied
- An interface can have two ACL’s applied to it, but must be different ACL’s, and be filtering traffic in different directions, the same ACL cannot be applied both in / out and two different ACL’s cannot be applied to the same direction for traffic
The last point is a biggy, as when explaining a fix for a network problem, saying the applying an ACL (even if it is the correct ACL) to an interface is NOT the correct answer, because applying it to the interface will be denied unless the original one is removed!
How to immediately figure out the Network # from a Wildcard Mask
ACL’s on a Cisco Router / Switch use wildcard masks, its imperative to know how to read these, as an exampe of a random Extended ACL line:
10 permit tcp 10.1.1.0 0.0.0.63 host 192.0.0.2 eq https
As stated in a previous post, the immediate way to read a wildcard mask is the subnet / network mask will be the #’s added to the “Wildcard” mask to make all octets = 255.
That would be 255.255.255.192, so network 10.1.1.0/26 is being allowed to the host address 192.0.0.2 on port 443 via this ACL line, to take it one step further 2 bits in the last octect are network bits (128 – 64), meaning the range will be increments of 63 IP Addresses.
Any confusion with this I recommend reading this post for a full explanation!
It is critical to be able to properly decipher Wildcard masks, so make sure this skillset is solid before exam day!!!
Time-Based ACL’s
- “sh access-list” – Verify if “time-range” is set on end of ACL line, will also show (active) or (inactive) after time-range, will only filter traffic if (active)
- “sh time-range (name)” – Verify the time frame the ACL will be (active) during
- “sh clock” – Verify time is correct and determine when time-range will be active
There isn’t a whole lot extra there, but its a consideration, if a problem report is happening during a certain time of day and you see a time-range on an ACL related to their particular traffic, this could very well be the issue.
Using “telnet” from Host PC to troubleshoot ACL’s is critical for exam day!
From the PC you can simulate certain types of traffic with “telnet” but issuing the command “telnet 192.168.110.100 25” to send telnet traffic over port 25 which would test SMTP / Email.
Using Telnet paired with checking the hit counter on configured ACL’s could reveal where the issue resides, as it can be observed which ACL is incrementing (or not incrementing) that should be or should not be!
IPv6 Access-List review and troubleshooting
IPv6 ACL’s work the same as IPv4 ACL’s with the exceptions of their configuration syntax when applying to interfaces, and that there is an implicit allow of ND traffic before the implicit deny all at the end of the ACL.
This means the following two lines are implicitly at the bottom of the ACL:
“permit icmp any any nd-na”
“permit icmp any any nd-ns”
This is to allow for IPv6 Neighbor Discovery to work properly, unless for some reason explicitly denied in a line of the ACL, which is something to watch for on exam day.
- “ipv6 traffic-filter (name) (in/out)” to apply an IPv6 ACL to an interface
- “sh ipv6 int (int)” or “sh run int” to verify the ACL applied to an IPvt6 interface
- “no sequence #” to remove an ACL line rather than just “no #” for an IPv4 ACL
Prefix-Lists (used for Route Filtering) review and troubleshooting
Prefix-Lists are used specifically for Route Filtering rather than traffic filtering, as they can be configured to be more flexible in terms of ranges of routes that will be allowed to be advertised using Dynamic Routing Protocols, whereas ACL’s can often also be used but are exact match or not – So essentially one line of a Prefix-List can replace several lines of an ACL when applied to route filtering mechanisms.
Again these are not applied to interfaces to filter traffic, these filter routes / subnets that are propagated via Dynamic Routing Protocols!
Prefix-Lists work the same as ACL’s that it searches Top Down for a match, once a match is found that search is over and the route is permitted or filtered, and anything not matched is implicitly denied at the end if not explicitly permitted (unless a catch-all Prefix-List line is configured at the end of the list).
They also behave the exact same with IPv4 and IPv6, it will match the length of the prefix listed exactly, unless “ge” or “le” is configured to give it a range of prefix lengths it can match on when applied to a route filter list.
ge = Greater or Equal to, defines the minimum value the Prefix length must match
le = Less or Equal to, defines the maximum value the Prefix length must match
These can be used by themselves, together, or not at all in a Prefix-List line!
Prefix-Lists go in order of sequence, as shown here:
ip prefix-list CCNP seq 10 deny 192.168.10.0/27
ip prefix-list CCNP seq 15 permit 172.16.31.0/25
These two lines will be treated the same way an ACL line would be, like a Network / Wildcard mask, and will only Deny and Permit a single network. It works if a single network is needed to be added to a Prefix-List, but contiguous networks should be listed like an ACL, instead the “ge” and “le” values should be leveraged to make life easier.
Direct from IOS from a past post regarding BGP route-filtering:
R1(config)#ip prefix-list BlockNets seq 24 deny 55.5.5.5/32 ?
ge Minimum prefix length to be matched
le Maximum prefix length to be matched
<cr>
This might come in handy for example if you have a summary route being advertised from an EIGRP Stub Area, and you only want the /24 networks to NOT be filtered, it could be summed up with the following prefix-list line:
ip prefix-list CCNP seq 20 permit 10.10.0.0/16 ge 24 le 24
This states that from the Summary Route 10.10.0.0/16, only permit subnets with a prefix of /24, so this will allow subnets 10.10.1.0, 10.10.2.0, 10.10.3.0, etc without needing ACL Line after ACL Line explicitly allowing each individual exact match.
This is the magic of Prefix-Lists!
Another example permitting all “Host Addresses” from the same subnet:
ip prefix-list CCNP seq 25 permit 10.10.0.0/16 le 32
This is another great case use especially for Dynamic Routing Protocols, as you may only want to propagate “Host Addresses” or Route-ID’s (RIDs) to allow formation of a neighbor Adjacencies only (/32 addresses) without propagating subnetworks.
Any / All prefix-list addresses for ipv4 and ipv6
ip prefix-list CCNP seq 40 0.0.0.0/0 le 32
ipv6 prefix-list CCIE seq 10 ::/0 le 128
This is basically the “permit ip any any” equivalent for Prefix-Lists if you want to “allow all” other than items explicitly denied in the list.
IPv6 Addresses work the exact same as IPv4 Prefix-Lists, a Prefix length must be defined and you can add ‘ge’ and ‘le’ to match certain parameters of Prefix length exactly.
Troubleshooting Prefix-Lists commands
I won’t get deep into the troubleshooting, but to identify the lists being used within protocols for route filtering:
- “sh ip route” – To view routes
- “sh ip prefix-list” – To view configured Prefix-Lists
- “sh ip protocols” – To see which Prefix-Lists are in use for route filtering
When working with Dynamic Routing Protocols, I personally would immediately look at “sh ip proto” to see if any prefix-list is in use for Route-Filtering then immediately review that Prefix-List, as you can bet your bottom dollar Cisco will place false positives like ACLs that appear to be blocking tracking that you may choose for an answer while the real issue is some very obscure / difficult to find Prefix-List mistake.
Definitely suggest labbing Prefix-Lists, writing some out on paper, and once a random prefix-list is drawn up quick figure out what all subnets could possibly be permitted or denied for just quick practice identifying and working with Prefix-Lists.
That is it for this one!
Prefix lists are really the difficult concept to understand within all this for me, but would be a go to command for exam day, as they can be so confusing if I were a Cisco exam question creator I would put a prefix-list in the network somewhere to break it 🙂
Until next time!
The DEVNET GRIND! 