Dell SmartFabric OS10 ACL Configuration and Verification

Dell PowerSwitch platforms running SmartFabric OS10 encourage a fabric-first design, but every fabric still needs filtering: management-plane protection, tenant separation, control-plane limits. ACLs on OS10 are straightforward to write and easy to misplace - the rules are evaluated top-down with an implicit deny, the direction keyword changes which side of the traffic sees them, and some S-series platforms do not apply egress rules to untagged access ports at all. This is the configuration and verification walkthrough.

Create the ACL

OS10# configure terminal
OS10(config)# ip access-list mgmt-protect
OS10(config-ip-acl)# seq 10 permit tcp 10.10.0.0/24 any eq ssh
OS10(config-ip-acl)# seq 20 permit udp 10.10.0.0/24 any eq snmp
OS10(config-ip-acl)# seq 30 permit icmp 10.10.0.0/24 any
OS10(config-ip-acl)# seq 100 deny ip any any count
OS10(config-ip-acl)# exit

Sequence numbers make the evaluation order explicit and leave room for later insertions - adding seq 15 is a one-line change instead of a rewrite. The final explicit deny documents the implicit deny that OS10 applies to any traffic not matched by an earlier rule, and the count keyword is what makes the ACL diagnosable later.

Apply it to an interface, VLAN or port-channel

OS10(config)# interface ethernet 1/1/1
OS10(config-if-ethernet-1/1/1)# ip access-group mgmt-protect in
OS10(config-if-ethernet-1/1/1)# exit

OS10(config)# interface vlan 100
OS10(config-if-vlan-100)# ip access-group mgmt-protect in

OS10(config)# interface port-channel 10
OS10(config-if-port-channel-10)# ip access-group mgmt-protect in

Applying the same ACL to a port-channel rather than to each member link is the correct pattern for LAGs: the filter then follows the logical interface through member changes. ACLs applied to a VLAN filter traffic entering that VLAN, which is efficient when a large number of access ports share the same policy.

The egress caveat

Applying an ACL with the out keyword makes it an egress filter, and OS10 documentation is explicit that egress ACL rules are not applied on untagged access ports - and that on some S5200F-ON platforms the same ACL applied with out becomes egress-only. Before designing around outbound filtering, confirm the behaviour on your exact model and software release. If the requirement is "block what leaves the rack", filtering at the uplink or routed interface is usually more predictable than filtering at the server access port.

Verify

OS10# show access-lists
OS10# show access-lists summary
OS10# show access-lists mgmt-protect
OS10# show running-configuration access-list
OS10# show interface ethernet 1/1/1 | grep -i access-group

show access-lists lists configured lists and their applied interfaces; show access-lists summary is the quick view of where each list is bound and in which direction. Counter values per sequence number are the strongest evidence that a filter is doing something - a rule with a zero counter either never matches or is applied in the wrong direction, and those two cases need different fixes.

Order of operations that avoids an outage

1. Write the ACL and apply it to one non-critical interface first.
2. Verify counters and confirm the expected traffic still passes.
3. Save the configuration (write memory or the equivalent), because an unsaved ACL is one reload away from a surprise.
4. Apply to the remaining interfaces, and re-check with show access-lists summary that every binding is where you intended.
5. For management-plane protection, always keep an out-of-band path (console or the management VRF) available while you work - an ACL that blocks your own session is not recoverable in-band.

Practical notes

• Keep ACLs named for their purpose (mgmt-protect, tenant-a-in) rather than numbered by ticket - the next engineer has to read the running configuration, not the change record.
• Use object groups or a consistent address scheme: duplicating literal addresses in twenty rules guarantees that one update is missed.
• On hardware-based platforms, entry count is a TCAM resource, not just a configuration line. Wide ACLs with many ports and ranges consume more entries than expected; monitor usage before adding a large policy set.
• Document which interface each ACL is bound to. An ACL that exists but is not applied is the most common "why is this not blocked" answer.

Related: Cisco Nexus 9000 TCAM carving and ACL regions, OS10 port-channel LACP and static configuration, and OS10 VLT troubleshooting commands.

原文链接：https://www.dell.com/support/manuals/en-us/dell-emc-smartfabric-os10/smartfabric-os-user-guide-10-5-0/assign-and-apply-acl-filters