An ACL change starts with a traffic requirement, not a command list. The same intended policy can require different syntax, placement and verification on Cisco, Juniper, HP and Brocade platforms.
This article draws on the multi-vendor change and automation work described in my portfolio. Its focus is the engineering method: how to review policy intent, handle CLI differences and retain evidence. It does not claim that automation eliminates configuration errors or guarantees uninterrupted service.
Translate the traffic requirement into checks
Write down source, destination, protocol, port, direction and the purpose of the flow. Include a connection that must remain allowed and a connection that should be denied. Identify management traffic that must survive the change.
Record where the policy is applied. An apparently correct rule on the wrong interface or direction may not control the intended path. Check return traffic and dependencies rather than using one successful ping as the acceptance test.
Account for vendor-specific ACL syntax and behavior
A Cisco ACL and a Junos firewall filter are not interchangeable objects. Rule order, default handling, address family, interface binding and commit behavior need platform-specific review. Juniper’s filter evaluation documentation explains why term order matters.
Keep each supported platform mapping small enough to inspect. Classify inventory by the actual software and device type rather than relying only on a naming convention. An unsupported platform should be reported and skipped instead of receiving a guessed command sequence.
Investigate slow or ambiguous CLI responses
My project encountered differences in terminal timing and prompts. A command that has not returned the expected prompt should not be assumed either successful or unsuccessful. Collect sanitized output, check session state and verify device configuration before deciding to retry.
Separate a transport failure from a command rejection and a delayed commit. The Netmiko user-management article covers the general session workflow; the Netmiko API documentation provides the version-specific method reference.
Project evidence: what is documented and what is public
My multi-vendor automation case study names juniper-update_acl.py and hp_aclconfig.py as part of the wider workflow. Those files are not in the public repository snapshot reviewed for this article. The published repository demonstrates user-management automation, not a publicly reproducible ACL deployment. I therefore treat the ACL work as portfolio-documented experience and do not invent a Juniper configuration transcript or successful traffic-test result.
There is inspectable evidence for the underlying CLI problem. The H3C implementation reads the prompt, sends commands with send_command_timing, retrieves configuration and handles save confirmation separately. For ACL automation, the transferable lesson is to separate command delivery, configuration verification and persistence. This account-management code does not prove an ACL allowed or blocked a flow.
Worked ACL acceptance example
Suppose an approved monitoring host must reach a device’s SSH service while another test host must remain blocked. The addresses below are documentation examples, not client infrastructure or results from my project. Translate the policy into the actual platform’s syntax only after reviewing existing rules and management dependencies.
| Test | Example flow | Required evidence |
|---|---|---|
| Intended permit | 192.0.2.10 to 198.51.100.20, TCP 22 |
Successful authorized SSH connection and relevant rule/counter evidence |
| Intended deny | 192.0.2.30 to the same destination, TCP 22 |
Connection blocked, with evidence distinguishing policy denial from an unrelated outage |
| Preserve operations | Existing approved monitoring and management flows | Existing checks still pass after the change |
| Confirm placement | The actual ingress/egress interface and direction | Applied policy matches the reviewed traffic path |
| Confirm persistence | Active and saved/committed configuration | Platform-specific readback; no assumption that command delivery saved the change |
A connection timeout alone is an ambiguous deny result: the host, route or SSH service might be unavailable. Run the positive control during the same test window and compare policy counters where available. If the management session drops after an ACL change, first establish the device state through the agreed recovery path; repeatedly resending the change can make recovery harder.
This is the handover artifact I would build around a Python ACL automation task: a reviewed policy, a small target set, before/after state and explicit permitted and denied flow results. It gives a client something testable rather than a claim that a script completed.
Plan a limited rollout and recovery
Agree on an initial device group, the approver and the test window. Capture the relevant pre-change state and define how access can be recovered if the management path is affected. A saved configuration is useful only if the team knows how and when to restore it.
After execution, compare the intended rule with the applied policy. Then perform the allowed and denied service checks. Inspect logs or counters where they support the diagnosis, but do not treat one counter as proof that every dependency is healthy.
Document ACL rollout evidence and operational ownership
A change record should name the target, policy version, execution result, verification evidence and unresolved exceptions. Include skipped devices and partial failures. Avoid publishing client configurations or credentials as proof of expertise.
If a current ACL automation workflow is failing, bring the expected policy, sanitized commands, device versions and observed result to a scope review. The multi-vendor project shows the related implementation context.