{{ result.summary.heading }}{{ result.summary.primary }}{{ result.summary.line }}

Top Match End {{ aclStageSequenceLabel }} {{ row.label }}
Cisco ACL generation inputs
Use one flow per row. CIDR, host IP, any, wildcard masks, and permitted object-group forms are supported.
{{ params.source.length.toLocaleString() }} chars
{{ sourceStatus }}
{{ fileError }}
Choose the command family used by the target device before copying configuration.
Standard ACL output is limited to IOS / IOS XE in this generator.
Numbered mode is available only for IOS / IOS XE.
Examples: EDGE-IN for named mode or 101 for an extended numbered ACL.
Pick the operational context used to review and deploy the ACL.
Use expanded rows when the receiving template cannot resolve object groups.
Numbered IOS and ASA output omit sequence prefixes regardless of this setting.
{{ params.sequence_start }}
Leave room above existing entries when inserting into a live named ACL.
{{ params.sequence_step }}
A step of 10 leaves space for later insertions.
Turn this option on when remark lines is required.
{{ params.emit_remarks ? 'Include remarks' : 'Omit remarks' }}
Target compatibility is checked before a default logging token is emitted.
Leave off unless the deployment standard requires a visible logged terminal deny.
{{ params.explicit_deny ? 'Append deny' : 'Use implicit deny' }}
{{ configExportAnnouncement }}
{{ result.configText }}
{{ tableExportAnnouncement }}
SeqActionProtocolSourceSource portDestinationDestination port/typeLoggingRemarkCopy
{{ row.sequence }}{{ row.action }}{{ row.protocol }}{{ row.source }}{{ row.sourcePort }}{{ row.destination }}{{ row.destinationPort }}{{ row.logging }}{{ row.remark }}
{{ tableExportAnnouncement }}
CheckStatusActionEvidenceReview noteCopy
{{ row.check }}{{ row.status }}{{ row.action }}{{ row.evidence }}{{ row.note }}
{{ tableExportAnnouncement }}
SettingValueGenerated effectReview noteCopy
{{ row.setting }}{{ row.value }}{{ row.effect }}{{ row.note }}
{{ chartExportAnnouncement }}

An IPv4 access control list is an ordered policy, not a bag of independent firewall rules. Each access control entry (ACE) tests packet fields and stops evaluation when it matches. A correct permit placed below a broader matching deny is unreachable; a broad permit near the top can make later restrictions ineffective.

Standard and extended ACLs express different amounts of intent. A standard ACL matches only the source address. An extended ACL can also match protocol, destination, TCP or UDP ports, ICMP type, options, and logging. Choosing the narrower syntax for a destination-sensitive policy discards information even when every source row looks reasonable.

Wildcard mask
A zero bit must match the corresponding address bit; a one bit may vary. This is the inverse of a contiguous subnet mask in IOS-style ACL syntax.
First match
The earliest matching ACE decides permit or deny, so row order changes policy behavior.
Implicit deny
Traffic not permitted by an earlier ACE is denied at the end even when no final deny line is visible.
Object group
A named address or service set that must already exist on the target device and be supported by its syntax.

Platform syntax also changes the command projection. IOS and IOS XE use wildcard masks for network terms, NX-OS output uses IPv4 prefixes, and ASA output uses subnet masks in flat access-list commands. Sequence prefixes, standard ACLs, numbered ACLs, service object groups, and log-input are not interchangeable across those targets.

Risk is wider than syntax. An any-any permit, broad management-service exposure, an unlogged deny, or a missing remark may parse successfully and still be a poor change. Logging every denial can be harmful too because busy ACLs can create avoidable CPU and syslog load.

Generated commands cannot establish interface direction, attachment point, existing object-group definitions, software-train behavior, time-range availability, or the safety of the surrounding rules. Review the complete device policy and keep a recovery path before applying an ACL to live traffic.

How to Use This Tool:

Define the target syntax and policy shape before entering flows; those choices decide what can be emitted safely.

  1. Choose Platform target, ACL type, and Identifier mode. Use an extended ACL for protocol, destination, or service matching.
  2. Enter the ACL identifier. Named identifiers accept letters, numbers, underscore, period, colon, and hyphen; numbered output is limited to IOS and checked against the selected ACL type.
  3. Paste or load Flow rows. Keep one policy row per line, with an optional CSV header. Use any, a host, an IPv4 CIDR, wildcard syntax, or an allowed network object group for addresses.
  4. Choose the Review profile and Object-group handling. Strict profiles flag broad scope sooner, while object-group choices decide whether unresolved network or service names are accepted.
  5. Set the Sequence strategy, remarks, and logging. Leave Explicit terminal deny off unless the change standard requires a visible logged final deny.
  6. Do not paste commands while Fix before using the ACL is shown. When generation succeeds, compare the ACL config with the ACE ledger, safety review, and target assumptions before testing it in the intended device context.

Interpreting Results:

ACE count is the number of packet-matching lines after multi-port expansion; remark lines and headers are separate. A source row containing several source and destination ports can therefore create more than one ACE while retaining a single original policy row.

Cisco ACL review statuses and required action
Status Meaning Response
Blocked A row, identifier, address, service, expansion, or platform combination is invalid. Correct the named input; no generated config is safe to use.
Risk A strict review found a consequential condition such as broad scope, unlogged denies, or management exposure. Narrow or reorder the policy, then repeat the review.
Review The syntax can be generated, but the condition needs a human decision. Verify the evidence against the change request and target device.
Ready or Info The local rule passed or records a neutral platform fact. Continue with device-side syntax and attachment testing.

Technical Details:

CIDR input is normalized to its network address before platform syntax is emitted. A /32 becomes a host term and /0 becomes any. Explicit wildcard input may be noncontiguous for IOS or ASA, but NX-OS prefix output requires the implied mask to be contiguous.

Formula Core:

For a contiguous IPv4 prefix of length p, the IOS wildcard is the bitwise inverse of the subnet mask. The equivalent integer has one bit for every host position.

W = ¬ Mp = 232p 1

Review breadth adds the number of variable source and destination address bits. It is a local screening measure, not a count of packets or proof that an ACE is unsafe.

B = wsource + wdestination

A host contributes 0 variable bits, a CIDR contributes 32 − p, any contributes 32, and explicit wildcard syntax contributes the number of one bits. An object-group address is assigned 12 bits for this review heuristic because its members are not expanded locally.

Rule Core:

Ordered Cisco ACL generation rules
Stage Deterministic rule
Parse The first non-comment row may be a recognized header. Without a header, fields use action, protocol, source, destination, destination port, remark, log, source port, and option order.
Normalize Action aliases become permit or deny; all and any protocols become ip; addresses and service operands are validated for the chosen platform.
Expand Comma-separated source and destination ports form a Cartesian product. One source row may create at most 40 ACEs, and the complete ACL may contain at most 300 ACEs.
Emit Input order is preserved. An enabled remark is placed immediately before its ACEs, and sequence values advance across both remarks and ACEs.
Terminate An optional explicit deny is appended with logging. If omitted, the platform's implicit deny still controls unmatched traffic.
Cisco ACL platform syntax projections
Target Address form Supported projection
IOS / IOS XE Network plus wildcard mask Named or numbered; standard or extended; named sequences; log-input; service object groups
NX-OS IPv4 CIDR prefix Named extended output with sequences; no numbered, standard, service-object-group, or log-input projection
ASA Network plus subnet mask Flat named extended access-list lines without sequences; service object groups allowed; log-input reduced to log
Cisco ACL review breadth thresholds
Review profile Broad when B is at least Additional emphasis
Balanced change review32 bitsRemarks expected
Strict edge ingress24 bitsStrict status and explicit deny recommended
Internal segmentation28 bitsStrict status and explicit deny recommended
Management plane access24 bitsBroad-source management permits receive a dedicated risk check
Migration staging36 bitsRemarks and explicit deny are not required by the profile

Any-any ACEs are tracked separately from the breadth threshold. IOS numbered standard ACLs accept 1 to 99 or 1300 to 1999; numbered extended ACLs accept 100 to 199 or 2000 to 2699. Numeric protocols span 0 to 255, numeric ports span 1 to 65535, sequence starts span 1 to 2,147,483,647, and sequence steps span 1 to 1,000,000. Remarks longer than 100 characters are shortened with a warning.

The safety review also checks a broad terminal rule before later rows, permit coverage, deny logging, remark coverage, multi-port expansion, object-group references, explicit terminal behavior, and permits from any source to common management services. These are review heuristics and do not replace device configuration validation.

Security Review Limits:

Flow text is processed in the browser, but a valid draft can still interrupt traffic or expose a service. Test the commands against the exact platform and software release, inspect the existing ACL and attachment direction, confirm referenced objects and time ranges, estimate logging volume, and arrange console or out-of-band recovery before deployment.

References: