Infrastructure ACL configuration guidelines filtering controls which traffic can reach routers, switches, and other network devices. An infrastructure access control list, or iACL, blocks unwanted traffic before it reaches device addresses.
But rules must allow required traffic, or outages can follow. BCP 38 also recommends ingress filtering to limit source-address spoofing. Keep rules clear, with specific rules placed before broader ones. Test changes before deployment, then review logs for blocked traffic and unexpected matches.
Remove old rules when they’re no longer needed. Review ACLs often because network traffic changes. Keep reading with Network Threat Detection.
Infrastructure ACL Filtering Quick Wins
- Protect infrastructure addresses separately from transit traffic so device-facing services receive tighter controls.
- Order ACL rules deliberately, permitting essential routing and operational traffic before broader infrastructure denies.
- Test hardware capacity, logging, control-plane behavior, and recovery access before treating an ACL deployment as production-ready.
What Is an Infrastructure ACL and Why Does It Matter?
An infrastructure ACL filters traffic sent to protected network infrastructure while normal transit traffic follows its own policy.
We use it to protect router interfaces, loopbacks, management addresses, and internal links. Our goal isn’t to act like an application firewall. It’s to block unwanted traffic before it reaches network devices and support stronger router and switch security.
We align our edge deployments with IETF BCP 38 (RFC 2827) and NIST SP 800-41 Rev. 1 by enforcing strict Anti-Spoofing Ingress Filtering directly at border interfaces.
Dropping RFC 1918 unroutable space and non-delegated bogon prefixes at the physical ingress interface prevents forged source packets from ever stressing internal state tables. We still use that idea when reviewing anti-spoofing rules.
In our design reviews, we separate infrastructure and transit traffic first. Otherwise, policy logic gets messy fast.
- Protect device-facing addresses.
- Keep transit traffic separate.
- Filter external ingress points.
- Apply BCP 38 principles.
That keeps network security easier to test.
How Should Infrastructure and Transit Address Space Be Separated?
Infrastructure IPs should sit in clear CIDR blocks. We’ve found this makes iACLs easier to review while keeping valid transit traffic out of the deny rules.
We first map loopbacks, management links, point-to-point links, and routing endpoints. NIST SP 800-41 Rev. 1 supports this approach by using IPs, ranges, protocols, and ports to define policy.
| Address category | Purpose | Typical access |
| Management plane | Device administration | SSH, SNMP, AAA, NTP, Syslog |
| Control plane | Routing communication | BGP, OSPF, IS-IS, LDP, ICMP |
| Transit space | Customer traffic | Separate transit policy |
Management traffic gets tight source filtering. Routing peers need clear rules too.
Don’t over-aggregate. A well-documented block can help, but a block that’s too broad may protect addresses that don’t need it.
Our threat reviews ask: what’s protected, who may reach it, and what’s only passing through?
Which Traffic Should an iACL Permit or Deny?
An iACL should allow needed infrastructure traffic from known sources, block unwanted access to protected addresses, and treat transit traffic separately as part of broader network security controls.
We usually build around a default deny rule. But exceptions come first, so needed routing traffic still works. The broad deny follows them.
According to NIST SP 800-41 Rev. 1
“As a best practice, you should start with a foundation of deny by default, blocking all inbound and outbound traffic unless specifically permitted by the firewall policy.” – NIST SP 800-41 Rev. 1
| Traffic | Baseline action | Example control |
| Spoofed sources | Deny | Source filtering |
| Known BGP peers | Permit | TCP/179 |
| OSPF/IS-IS links | Permit | Link-specific |
| Needed ICMP/ICMPv6 | Selective | Message rules |
| Unwanted infrastructure traffic | Deny | Protected prefixes |
| Transit traffic | Separate | Transit policy |
In our reviews, BGP gets limited to known peers. OSPF, IS-IS, and LDP stay on expected links.
ICMP needs care. Blocking it can break troubleshooting, while allowing everything can widen exposure. For IPv6, ICMPv6 Packet Too Big must remain available for Path MTU Discovery.
So ask first: what must work, and who should reach it?
Why Does iACL Rule Ordering Matter?
ACL order matters. Entries are checked from top to bottom, so one broad rule can block a later exception.
We normally build rules in this order:
- DENY spoofed sources
- PERMIT known infrastructure traffic
- PERMIT needed operations
- DENY remaining infrastructure traffic
- PERMIT valid transit traffic
The implicit deny still helps, but an explicit infrastructure deny makes the boundary easier to see and troubleshoot.
In our reviews, we check ACL statement order, rule precedence, wildcard masks, CIDR ranges, and interface direction. Then we check counters after deployment.
In our years managing edge routing, We’ve seen a misplaced /23 wildcard mask take down an entire regional transit path during a routine change window.
A configuration can pass syntax checks seamlessly while still causing a catastrophic outage, which is why dry-run validation against active routing tables is non-negotiable. Our threat models also help spot gaps before deployment.
How Should You Protect BGP and Other Control-Plane Protocols?
BGP and other control-plane traffic should reach only known peers and expected links. Strong routing protocol controls help limit unauthorized access, while the infrastructure ACL acts as the security guard at the front gate, stopping uninvited guests before they reach the door.
Control-Plane Policing (CoPP) is the receptionist inside who limits how many visitors can talk to the manager (the device CPU) at one time so the system doesn’t crash.
| Protocol | Primary control | Validation |
| BGP | TCP/179 filtering | Known peers |
| OSPF | Protocol filtering | Expected interfaces |
| IS-IS | Link filtering | Known adjacencies |
| LDP | MPLS filtering | Known neighbors |
| ICMP/ICMPv6 | Message filtering | Operational needs |
In our edge reviews, BGP gets extra attention. We check peer IPs, interface direction, TTL where used, and CPU rate limits. A routing session loss can hurt more than one blocked management connection.
Filtering should happen early, but valid control traffic still needs to pass through each layer. NIST’s policy-first approach fits our threat models too.
Should You Use Stateless iACLs or Stateful Firewalls?
iACLs fit infrastructure protection and broad packet filtering. Stateful controls fit rules that need session tracking and dynamic return traffic.
A stateless ACL checks source IP, destination IP, protocol, and port. It doesn’t track a connection like a stateful firewall does.
We’ve found simple rules, such as allowing BGP from known peers, are easy to manage with iACLs. Complex application sessions can become messy.
| Requirement | iACL | Stateful control |
| Protect infrastructure | Yes | Yes |
| Block spoofed sources | Yes | Yes |
| Restrict routing peers | Yes | Yes |
| Track sessions | Limited | Yes |
| Application-aware policy | Limited | Yes |
| Dynamic return traffic | Limited | Yes |
Our iACLs stay focused on device-facing access. That keeps rules readable and avoids endless exceptions.
We also use Network Threat Detection for visibility. It can flag unusual traffic without forcing the iACL to make every decision.
Stateless filtering still has a strong place. It’s predictable and fast, which suits perimeter filtering and anti-spoofing.
Give each control one job. That’s easier to test and defend.
How Can You Avoid TCAM Exhaustion When Scaling ACLs?
Credits: Cisco
ACL scale depends on the device, so check hardware resources before adding more rules.
TCAM lets switches and routers classify packets at high speed. But each rule can use different amounts of space. PACL, VACL, and RACL policies may also compete for it.
We’ve learned that counting ACL lines isn’t enough. Complex matches can use far more hardware than basic rules. IPv4 and IPv6 can differ too.
What Should You Check Before Expanding an ACL?
- Current TCAM use
- PACL, VACL, RACL overlap
- Platform ACL limits
- IPv4 and IPv6 needs
- Duplicate rules
- Hardware programming
- Software fallback risk
On platforms like the Cisco Catalyst 9500 or ASR 1000s, hitting TCAM allocation limits won’t crash the device, it silently punts matching packets to the CPU.
I always run show platform hardware fed switch active fwd-asic resource tcam utilization prior to push-deployments to confirm hardware availability before high-volume traffic hits software switching.
Our risk reviews check TCAM after major ACL changes. That helps catch gaps before they affect traffic.
How Should You Handle ICMP, Fragments, and PMTUD?
ICMP filtering needs care. Some messages support diagnostics, error handling, and packet-size discovery.
The IETF RFC 4890 gives guidance for ICMPv6 filtering. We’ve seen broad ICMPv6 blocks cause hard-to-trace failures, especially with Path MTU Discovery.
According to IETF RFC 4890
“When a network supports IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role including being an essential component in establishing and maintaining communications both at the interface level and for sessions to remote nodes. This means that overly aggressive filtering of ICMPv6 by firewalls may have a detrimental effect on the establishment and maintenance of IPv6 communications.” – IETF RFC 4890
| Traffic type | Filtering approach | Primary concern |
| Echo Request | Selective | Diagnostics |
| Echo Reply | Selective | Expected responses |
| Time Exceeded | Permit as needed | Traceroute |
| Destination Unreachable | Selective | Error signaling |
| IPv6 Packet Too Big | Preserve | Path MTU Discovery |
| Unnecessary fragments | Review | Evasion |
When auditing customer links, we never rely on basic 64-byte ping sweeps. We run active tcpdump sessions while forcing 1500-byte ICMP packet tests with the Don’t Fragment (DF) bit set; if ICMP Type 3, Code 4 (Fragmentation Needed) is silently dropped by a lazy iACL entry, your TCP sessions will stall out completely right after the TLS handshake.
Fragment rules also need platform testing. And don’t treat them as a full DoS protection plan. Rate limits, upstream filtering, and monitoring still matter.
Our threat models help check those gaps.
How Can You Control ACL Logging Without Overloading Devices?
ACL logging should capture useful events, not every packet. High-volume logs can add device load and create noise.
We usually rely on ACL counters for busy links. Network operators must limit ACL logging exclusively to actionable security events.
Systems engineers should run platform-level benchmarks before enabling the log or log-input keywords, as unthrottled hardware logging can exhaust CPU cycles within seconds during an active DDoS event.
- Log targeted security events
- Watch CPU after changes
- Check counters for odd traffic
- Rate-limit telemetry when supported
- Test log and log-input
- Send events to security monitoring
A broad infrastructure deny can still have counters without logging every hit. That gives our team evidence without flooding telemetry.
Network Threat Detection adds wider visibility. We use it to spot patterns while the ACL stays focused on clear traffic rules.
Less noise helps. Our risk reviews also flag logging gaps before they become blind spots.
How Can You Deploy iACL Changes Without Losing Management Access?
Production iACL changes need a recovery path, testing, and a controlled workflow. One wrong direction can lock out the team.
An out-of-band (OOB) network gives us access if normal management gets blocked. That matters on core and edge devices.
What Should a Production Change Workflow Include?
- Build the ACL policy.
- Check source and destination IPs.
- Verify masks and CIDRs.
- Check routing peers.
- Confirm interface direction.
- Test OOB or console access.
- Apply during a change window.
- Verify routing adjacencies.
- Check ACL counters.
- Test management access.
- Keep rollback ready.
We prefer version-controlled templates over manual edits. Infrastructure as code can help, but automation won’t fix bad logic.
Our threat models also test intent, not only syntax. The real question is simple: will approved traffic still reach the infrastructure it needs?
How Should You Audit an iACL After Deployment?
An iACL needs regular review against current prefixes, peers, protocols, counters, hardware limits, and recovery access.
Our ACLs are snapshots. Networks change. New BGP peers arrive, IP blocks move, and management paths get redesigned. An old rule can become a gap.
| Audit area | Review question |
| Infrastructure prefixes | Are protected IPs current? |
| Peering | Are trusted peers current? |
| Protocols | Are needed protocols allowed? |
| Counters | What rules are matching? |
| TCAM | Is capacity available? |
| CoPP | Are valid packets dropped? |
| Logging | Is logging adding load? |
| Recovery | Does OOB access work? |
We review after topology, peering, address, or routing changes. Software upgrades matter too.
Unexpected permits can expose overly broad rules. Unexpected denies may point to missing access.
Remove stale entries. Our audits and threat models help keep the policy tied to the network as it exists now.
What Should a Production iACL Baseline Contain?
A production iACL should define the policy first. Then we translate it into vendor syntax after testing the platform.
Cisco IOS-XE, NX-OS, RouterOS, and other systems differ in syntax, hardware, logging, and match options. So a generic model is safer than one “universal” command set.
- Deny spoofed sources
- Permit known infrastructure protocols
- Permit needed ICMP/ICMPv6
- Deny remaining infrastructure traffic
- Handle transit traffic separately
The final deny sets the boundary around protected addresses.
What Should You Validate Before Using the Baseline?
- Vendor and software version
- IPv4 and IPv6 behavior
- Interface direction
- Infrastructure CIDRs
- BGP peer addresses
- ICMP needs
- Fragment behavior
- TCAM capacity
- CoPP or CPPr
- Logging
- OOB recovery
We’ve seen rules behave differently across platforms. Test each one. Our threat models also check how extended ACL rules interact with real device behavior.
What Is the Practical iACL Deployment Checklist?
A production iACL needs clear scope, known exceptions, hardware checks, and a tested recovery path. We use this checklist before deployment:
- Define infrastructure CIDRs.
- Separate infrastructure from transit.
- Identify trusted control-plane peers.
- Filter bad source addresses.
- Apply RFC 1918 filtering where needed.
- Review special-use source addresses.
- Permit required protocols only.
- Preserve needed ICMP/ICMPv6.
- Deny unwanted infrastructure traffic.
- Check interface direction.
- Check TCAM capacity.
- Review CoPP or CPPr.
- Limit ACL logging.
- Test asymmetric paths.
- Test MTU-sensitive traffic.
- Confirm OOB recovery.
- Automate policy checks.
- Audit after network changes.
We treat each item as a gate. Missing one can break routing or leave a gap.
Our reviews have caught valid BGP peers blocked by source filtering. That’s why policy and real traffic must be tested together.
How Can iACLs Fit Into a Modern Network Security Strategy?
iACLs still fit well as infrastructure boundary controls. But we get better results when they work with control-plane protection, stateful security, monitoring, and automation.
We keep each control focused. The iACL protects direct device access. CoPP protects CPU resources. Stateful controls handle session-based traffic, while Network Threat Detection helps spot patterns static rules can’t see.
The IETF supports ingress filtering against forged sources, and NIST guidance favors policy-based traffic controls.
- Keep iACLs focused on infrastructure.
- Use CoPP for CPU protection.
- Use stateful controls for sessions.
- Add threat detection for visibility.
- Automate testing and version control.
- Watch TCAM resources.
- Review address changes.
- Check ACL counters and logs.
Our experience is clear: narrow rules are easier to test. And if one control fails, another can limit the damage.
FAQs
How do you choose between a standard ACL and extended ACL for infrastructure traffic?
A standard ACL filters by source address. An extended ACL filters by source, destination, protocol, and ports, providing more precise traffic access control.
What should an infrastructure ACL do with fragmented packets?
Fragmented packet filtering should account for fragments that lack transport-layer information. Test these ACL filtering rules carefully to avoid blocking legitimate transit traffic.
How can an ACL help prevent IP spoofing on network ingress points?
An anti-spoofing ACL can block packets with invalid source addresses at network ingress points. Source IP filtering supports IP spoofing prevention and infrastructure protection.
When should ACL logging and monitoring be enabled?
Enable ACL logging when troubleshooting or validating ACL deployment. ACL monitoring helps identify unauthorized traffic, unexpected denials, and rules that require adjustment.
How often should infrastructure ACL rules be reviewed after deployment?
Review ACL rules whenever infrastructure IP addresses, services, or access requirements change. Regular ACL optimization helps remove outdated access control entries and unnecessary rules.
Keep Infrastructure ACLs Narrow and Testable
When an infrastructure ACL is too broad, it can expose management paths or allow unwanted traffic toward critical network devices. When it’s too restrictive, legitimate control-plane traffic can break. That’s the reality check.
A reliable ACL starts with a clear scope, allows only required traffic, and blocks unauthorized access to infrastructure addresses. Before deployment, test rule order, ICMP, fragmentation, logging, and recovery paths. For teams looking to strengthen network visibility, Network Threat Detection can help identify risks and potential attack paths before they become operational problems.
References
- https://csrc.nist.rip/glossary/term/network_access_control
- https://datatracker.ietf.org/doc/rfc4890/#1
