A single ACL consists of one or more ACL rules. Each rule is a filter configured to take a specific action when packets matching specific criteria. Up to 256 rules can be configured per ACL.

Each rule specifies the action to take when a packet matches the specifies criteria. This section discusses the rule actions and criteria supported by the system.

A single ACL can consist of multiple rules. Each packet is compared against each of the ACL rules, in the order in which they were entered, until a match is found. Once a match is identified, all subsequent rules are ignored.

[ before | after ] { existing_rule }

To create an ACL, enter the following command sequence from the Exec mode of the system CLI:

configure
   context acl_ctxt_name [ -noconfirm ]
      { ip | ipv6 } access-list acl_list_name
      end

To create rules to deny/permit the subscriber traffic and apply the rules after or before action, enter the following command sequence from the Exec mode of the system CLI:

configure
   context acl_ctxt_name [ -noconfirm ]
      { ip | ipv6 } access-list acl_list_name
         deny { ip_address | any | host | icmp | ip | log | tcp | udp }
         permit { ip_address | any | host | icmp | ip | log | tcp | udp }
         after { deny | permit | readdress | redirect }
         before { deny | permit | readdress | redirect }
         end

Notes:

Caution

The system does not apply a "deny any" rule, unless it is specified in the ACL. This behavior can be changed by adding a "deny any" rule at the end of the ACL.

As discussed previously the system uses an "undefined" ACL mechanism for filtering the packet(s) in the event that an ACL that has been applied is not present. This scenario is likely the result of a mis-configuration such as the ACL name being mis-typed during the configuration process.

For these scenarios, the system provides an "undefined" ACL that acts as a default filter for all packets into the context. The default action is to "permit all".

To modify the default behavior for unidentified ACLs, use the following configuration:

configure
   context acl_ctxt_name [-noconfirm]
      access-list undefined { deny-all | permit-all }
      end

To verify the ACL configuration, enter the Exec mode show { ip | ipv6 } access-list command.

The following is a sample output of this command. In this example, an ACL named acl_1 was configured.

ip access list acl_1
   deny host 10.2.3.4
   deny ip any host 10.2.3.4
   permit any 10.2.4.4
1 ip access-lists are configured.

To apply the ACL to an interface, use the following configuration:

configure
   context acl_ctxt_name [ -noconfirm ]
      interface interface_name
         { ip | ipv6 } access-group acl_list_name { in | out } [ preference ]
         end

To apply the ACLs to a context, use the following configuration:

configure
   context acl_ctxt_name [ -noconfirm ]
      { ip | ipv6 } access-group acl_list_name [ in | out ] [ preference ]
      end

Notes:

• The context name is the name of the ACL context containing the interface to which the ACL is to be applied.

• The context-level ACL is applied to outgoing packets. This applies to incoming packets also if the flow match criteria fails and forwarded again.

  The in and out keywords are deprecated and are only present for backward compatibility.

  Context ACL will be applied in the following cases:

  • Outgoing packets to an external source.

  • Incoming packets that fail flow match and are forwarded again. In this case, the context ACL applies first and only if it passes are packets forwarded.

    During forwarding, if an ACL rule is added with a destination address as a loopback address, the context ACL is also applied. This is because StarOS handles packets destined to the kernel by going through a forwarding lookup for them. To apply ACL rules to incoming packets, the interface ACL must be used instead of the context ACL.

• The ACL to be applied must be configured in the context specified by this command.

• Up to 16 ACLs can be applied to a group provided that the number of rules configured within the ACL(s) does not exceed the 256-rule limit for the interface.

IP ACLs are applied to subscribers via attributes in their profile. The subscriber profile could be configured locally on the system or remotely on a RADIUS server.

To apply an ACL to a RADIUS-based subscriber, use the Filter-Id attribute.

For more details on this attribute, if you are using StarOS 12.3 or an earlier release, refer to the AAA and GTPP Interface Administration and Reference. If you are using StarOS 14.0 or a later release, refer to the AAA Interface Administration and Reference.

This section provides information and instructions for applying an ACL to an individual subscriber whose profile is configured locally on the system.

To configure the system to provide access control list facility to subscribers:

To apply the ACL to an individual subscriber, use the following configuration:

configure
   context acl_ctxt_name [ -noconfirm ]
      subscriber name subs_name
         { ip | ipv6 } access-group acl_list_name [ in | out ]
         end

This section provides information and instructions for applying an ACL to the subscriber named default.

To configure the system to provide access control list facility to subscribers:

This section provides information and instructions for applying an ACL to the subscriber to be used as the "default" profile by various system services.

To configure the system to provide access control list facility to subscribers:

As mentioned in the previous section, IP ACLs are applied to subscribers via attributes in their profile. The subscriber profile could be configured locally on the system or remotely on a RADIUS server.