Advanced ACLs on IOS XE: Time-Based, Object-Group, and IPv6 ACLs

The access list you learned for the CCNA (permit this host, deny that subnet) still works, but it does not scale and it does not express intent. When you have forty admin hosts, a policy that only applies during business hours, and an IPv6 network to protect alongside the IPv4 one, a flat list of permit and deny lines becomes an unmaintainable wall. Advanced ACL features exist to make policy readable, reusable, and time-aware.

This article covers time-based ACLs, object groups, and IPv6 ACLs on Cisco IOS XE, with real output including a schedule that is genuinely inactive because of when the lab ran. It extends the Infrastructure Security cluster guide.

Time-Based ACLs

Some rules should only apply at certain times: allow contractor access during business hours only, block recreational traffic during work hours, permit a maintenance path only during the change window. A time-based ACL attaches a time-range to an ACE, and the ACE is only active when the time-range is.

R1(config)# time-range BUSINESS-HOURS
R1(config-time-range)#  periodic weekdays 8:00 to 18:00
!
R1(config)# ip access-list extended ADV-ACL
R1(config-ext-nacl)#  permit tcp object-group TRUSTED-ADMINS any eq 22
R1(config-ext-nacl)#  permit object-group WEB-SERVICES any any time-range BUSINESS-HOURS
R1(config-ext-nacl)#  deny ip any any log

The time-range supports periodic (recurring, like "weekdays" or "weekend" or specific days) and absolute (a one-off window with a start and end date, ideal for a temporary contractor or a scheduled event).

Here is the genuinely useful part, captured live. This lab ran on a Saturday, and the time-range is weekdays only. Watch what the router reports:

R1#show time-range
time-range entry: BUSINESS-HOURS (inactive)
   periodic weekdays 8:00 to 18:00
   used in: IP ACL entry

R1#show ip access-lists ADV-ACL
Extended IP access list ADV-ACL
    10 permit tcp object-group TRUSTED-ADMINS any eq 22
    20 permit object-group WEB-SERVICES any any time-range BUSINESS-HOURS (inactive)
    30 deny ip any any log

(inactive) on both the time-range and the ACE that uses it, because it is the weekend. That is not a mockup; it is the router correctly reporting that line 20 is currently dormant and, right now, web traffic falls through to the deny on line 30. Come Monday at 08:00 the same commands would show (active) and line 20 would start permitting. The time-range is evaluated against the router's clock in real time, which is exactly why accurate NTP is a prerequisite for time-based security: a router with the wrong time enforces the wrong policy.

Object Groups

The scaling problem. You have twenty admin hosts that should reach SSH on every device. Without object groups, that is twenty permit lines, repeated in every ACL that references them, and updated by hand in every place whenever an admin joins or leaves. Object groups let you name the set once and reference the name.

R1(config)# object-group network TRUSTED-ADMINS
R1(config-network-group)#  host 192.168.99.100
R1(config-network-group)#  host 10.0.10.101
!
R1(config)# object-group service WEB-SERVICES
R1(config-service-group)#  tcp eq 80
R1(config-service-group)#  tcp eq 443

Two kinds of group do most of the work:

Now the ACL reads like policy, not plumbing: permit tcp object-group TRUSTED-ADMINS any eq 22 means "the admins may SSH anywhere." Add a new admin by editing the group once, and every ACL that references it updates automatically. The router expands the groups internally, so the enforcement is identical; what changes is maintainability.

R1#show object-group
Network object group TRUSTED-ADMINS
 host 192.168.99.100
 host 10.0.10.101

Service object group WEB-SERVICES
 tcp eq www
 tcp eq 443

Object groups can also nest (a group of groups), which is how large enterprises model "all datacentre subnets" or "all management stations" as a single named object built from smaller ones.

IPv6 ACLs and the ND Trap

IPv6 ACLs work like extended IPv4 ACLs with three differences that catch people out. First, there are no standard vs extended flavours; all IPv6 ACLs are named and behave like extended ones. Second, the syntax is ipv6 access-list and it is applied with ipv6 traffic-filter, not ip access-group. Third, and this is the one that causes outages:

R1(config)# ipv6 access-list ADV-V6
R1(config-ipv6-acl)#  permit tcp any host 2001:DB8:10::1 eq 22
R1(config-ipv6-acl)#  permit icmp any any nd-ns
R1(config-ipv6-acl)#  permit icmp any any nd-na
R1(config-ipv6-acl)#  deny ipv6 any any log

Those two nd-ns and nd-na lines are not optional. IPv6 relies on Neighbor Discovery (Neighbor Solicitation and Neighbor Advertisement) the way IPv4 relies on ARP, but unlike ARP, ND rides inside ICMPv6, which means an IPv6 ACL can block it. If your ACL ends in deny ipv6 any any without first permitting ND, the router can no longer resolve its neighbors and IPv6 connectivity on that segment collapses, including your own management session.

Every IPv6 ACL that ends in a deny must explicitly permit ND first. This is the single most common way people lock themselves out with IPv6 ACLs, and it has no IPv4 equivalent because ARP is not IP traffic and ACLs never touched it.

Logging and the Performance Note

The log keyword on the final deny (as in both ACLs above) records what is being blocked, which is invaluable for both security monitoring and for discovering the rule you forgot to add. But logging punts matched packets for logging, which costs CPU, so:

• Log the deny lines, not the permits. You want to see what is blocked, not a firehose of normal traffic.
• Use log (rate-limited) rather than log-input on high-traffic ACLs unless you specifically need the ingress interface and source MAC.
• On a busy edge, even logged denies can be a lot. Consider CoPP protection for the logging path, or sample rather than log everything.

Order Still Matters

None of these features change the fundamental rule: ACLs are processed top-down, first match wins, and there is an implicit deny at the end. Object groups and time-ranges make each line richer, but the evaluation order is unchanged. Put your most specific and most-hit rules near the top, your broad denies at the bottom, and remember that a time-range that is inactive causes its ACE to be skipped entirely, so traffic falls through to the next line, exactly as the Saturday capture above demonstrated.

FAQ

Do object groups change how the ACL enforces?

No. The router expands the group into individual entries internally. Enforcement is identical; the benefit is purely maintainability and readability.

My time-based ACL is not working. Why?

Check the router's clock and time zone (show clock). A time-range is evaluated against the router's local time, so wrong time or wrong zone means the wrong window. Sync NTP.

Why did my IPv6 ACL break connectivity?

You almost certainly denied Neighbor Discovery. Add permit icmp any any nd-ns and permit icmp any any nd-na before any broad deny.

Can I use object groups in IPv6 ACLs?

IPv6 object-group support exists on modern IOS XE but is less complete than IPv4. Verify on your platform; some releases support network object-groups in IPv6 ACLs, others are more limited.

Absolute or periodic time-range?

Periodic for recurring schedules (business hours, weekends). Absolute for one-off windows with real dates (a two-week contractor, a specific maintenance night).

Key Takeaways

• Time-based ACLs attach a time-range to an ACE so it only applies on schedule. The lab captured a weekdays range showing (inactive) on a Saturday, with the dependent ACE dormant.
• Time-based security depends on an accurate clock. Sync NTP or you enforce the wrong policy at the wrong time.
• Object groups name sets of hosts (network) or ports (service) once and reference the name, so a policy change is one edit instead of many. Enforcement is unchanged; maintainability transforms.
• IPv6 ACLs must explicitly permit icmp any any nd-ns and nd-na before any broad deny, or Neighbor Discovery breaks and IPv6 connectivity collapses. This has no IPv4 equivalent.
• Log the deny lines, not the permits, and mind the CPU cost of logging on busy links.
• Order is unchanged: top-down, first match, implicit deny at the end. An inactive time-range simply skips its ACE.

Next: hardening the management plane, or the Infrastructure Security cluster guide.