Traditional ONEPolicy architecture uses a hierarchical approach to rule precedence where rule type dictates precedence. In addition, rule look-ups occur per role, per action type. This means, for example, that triggering a forward/drop rule without an explicit Class of Service (CoS) action results in applying the forward/drop action, and then continuing searching until a rule with CoS action matches. This hierarchical approach is implemented in hardware by maintaining one list for forward/drop actions, and one list for CoS actions. This implementation often results in underused resources, because not every rule has both forward/drop and CoS actions.
With ACL Style Policy, a mode of operation with a single ordered list per role is maintained. Rule look-ups occur in the provided ACL order per role. A match applies all actions specified, and the search stops. This approach can potentially double the advertised scale of classification rules as compared to the traditional model. It also provides a more standard approach to policy classification rules.
Default policy rule-model is hierarchical, unless you are upgrading from ExtremeXOS 30.5 with a saved configuration that is set to access list.
For information about configuring ACL Style Policy, see Configuring ACL Style Policy.
SNMP for configuration of ACL Style Policy classification rules is not supported.
Policy access-list hardware installation errors may occur depending on the configured IFP slice mode, the type of IFP processor, and the combination of match criteria used. The ipv4-ipv6-double-shared slice mode attempts to program all policy access-lists into a single double-wide slice type. This allows installation of match fields such as IPv4/IPv6 destination prefixes, layer 4 destination ports (including ranges), and Ethernet type. However, if additional match criteria—such as IPv4 source address, layer 4 source ports, TTL, or TOS—are required, the ipv4-ipv6-double-separate mode should be used to ensure successful hardware programming.
Similar limitations apply to the ipv4-single-ipv6-double slice mode. In this configuration, IPv4 access-lists are programmed in single-wide slices, while IPv6 access-lists use double-wide slices—only on platforms that support double-wide. On platforms that do not support double-wide slices, IPv6 access-lists will also be programmed in single-wide slices, which restricts the available match criteria.
Platforms that do not support double-wide slices:
The following table compares the overall classification rule scale between "traditional" and ACL Style policy:
| Switch Model(s) | Traditional | ACL Style* |
|---|---|---|
|
X435 | Default: 184 Less System ACL: 184 | Default: 440 Less System ACL: N/A |
|
X450-G2 X460-G2 | Default: 952 Less System ACL: 1,464 | Default: 3,000 Less System ACL: N/A |
|
X440-G2 | Default: 440 Less System ACL: 440 | Default: 952 Less System ACL: N/A |
|
X465 | Default: 1,976 Less System ACL: 1,976 | Default: 4,024 Less System ACL: N/A |
|
X695 | Default: 1,976 Less System ACL: 1,976 | Default: 3,512 Less System ACL: N/A |
** - Applies to role-based DACLs as well as static ACLs created via the Policy CLI, which are also associated with a profile. User-based DACLs may achieve lower ACL Style numbers.
ACL Style Policy implements a new RESTful API for configuration of classification rules.
Note
RESTful API is not supported for Dynamically-created ACLs via RADIUS and COA.