> Access Control Lists
> This chapter describes system support for access control lists and explains how they are configured. The product administration guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model before using the procedures in this chapter.
> Important: You do not require a license to configure ACLs; however, the number of ACLs configured might impact performance significantly.
> Important: Not all commands and keywords/variables may be available. This is dependent on the platform type.
> This chapter contains the following sections:

> • | Understanding ACLs

> • | Configuring ACLs on the System

> • | Applying IP ACLs

> Overview
> IP access lists, or access control lists (ACLs) as they are commonly referred to, are used to control the flow of packets into and out of the system. They are configured on a per-context basis and consist of “rules” (ACL rules) or filters that control the action taken on packets that match the filter criteria. Once configured, an ACL can be applied to any of the following:

> • | An individual interface

> • | All traffic facilitated by a context (known as a policy ACL)

> • | An individual subscriber

> • | All subscriber sessions facilitated by a specific context

> Understanding ACLs
> This section discusses the two main aspects to ACLs on the system:

> • | Rule(s)

> • | Rule Order

> Important: Refer to the ACL Configuration Mode Commands chapter of the Command Line Interface Reference for the full command syntax.
> Rule(s)
> A single ACL consists of one or more ACL rules. As discussed earlier, the rule is a filter configured to take a specific action on packets matching specific criteria. Up to 128 rules can be configured per ACL.
> Important: Configured ACLs consisting of no rules imply a “deny any” rule. The deny action and any criteria are discussed later in this section. This is the default behavior for an empty 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.
> Actions
> ACLs specify that one of the following actions can be taken on a packet that matches the specified criteria:

> • | Permit: The packet is accepted and processed.

> • | Deny: The packet is rejected.

> • | Redirect: The packet is forwarded to the specified next-hop address through a specific system interface or to the specified context for processing.

> Important: Redirect rules are ignored for ACLs applied to specific subscribers or all subscribers facilitated by a specific context, or APN for UMTS subscribers.
> Criteria
> Each ACL consists of one or more rules specifying the criteria that packets will be compared against.
> The following criteria are supported:

> • | Any: Filters all packets

> • | Host: Filters packets based on the source host IP address

> • | ICMP: Filters Internet Control Message Protocol (ICMP) packets

> • | IP: Filters Internet Protocol (IP) packets

> • | Source IP Address: Filter packets based on one or more source IP addresses

> • | TCP: Filters Transport Control Protocol (TCP) packets

> • | UDP: Filters User Datagram Protocol (UDP) packets

> Each of the above criteria are described in detail in the sections that follow.
> Important: The following sections contain basic ACL rule syntax information. Refer to the ACL Configuration Mode Commands chapter of the Command Line Interface Reference for the full command syntax.

> • | Any: The rule applies to all packets.

> • | Host: The rule applies to a specific host as determined by its IP address.

> • | ICMP: The rule applies to specific Internet Control Message Protocol (ICMP) packets, Types, or Codes.

> Important: ICMP type and code definitions can be found at www.iana.org as indicated by RFC 3232.

> • | IP: The rule applies to specific Internet Protocol (IP) packets or fragments.

> • | IP Packet Size Identification Algorithm: The rule applies to specific Internet Protocol (IP) packets identification for fragmentation during forwarding.

> This configuration is related to the “IP Identification field” assignment algorithm used by the system, when subscriber packets are being encapsulated (such as Mobile IP and other tunneling encapsulation). Within the system, subscriber packet encapsulation is done in a distributed way and a 16 bit IP identification space is divided and distributed to each entity which does the encapsulation, so that unique IP identification value can be assigned for IP headers during encapsulation.
> Since this distributed IP Identification space is small, a non-zero unique identification will be assigned only for those packets, which may potentially be fragmented during forwarding (since the IP identification field is only used for reassembly of the fragmented packet). The total size of the IP packet is used to determine the possibility of that packet getting fragmented.

> • | Source IP Address: The rule applies to specific packets originating from a specific source address or a group of source addresses.

> • | TCP: The rule applies to any Transport Control Protocol (TCP) traffic and could be filtered on any combination of source/destination IP addresses, a specific port number, or a group of port numbers.

> Important: TCP port numbers definitions can be found at www.iana.org.

> • | UDP: The rule applies to any User Datagram Protocol (UDP) traffic and could be filtered on any combination of source/destination IP addresses, a specific port number, or a group of port numbers.

> Important: UDP port numbers definitions can be found at www.iana.org.
> Rule Order
> 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.
> Additional rules can be added to an existing ACL and properly ordered using either of the following options:

> • | Before

> • | After

> Using these placement options requires the specification of an existing rule in the ACL and the configuration of the new rule as demonstrated by the following flow:
> [ before | after ] { <existing_rule> }
> Configuring ACLs on the System
> This section provides information and instructions for configuring ACLs.
> Important: This section provides the minimum instruction set for configuring access control list on the system. For more information on commands that configure additional parameters and options, refer ACL Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to provide access control list facility to subscribers:

> Step 1 | Create the access control list by applying the example configuration in the Creating ACLs section.

> Step 2 | Specify the rules and criteria for action in ACL list by applying the example configuration in the Configuring Action and Criteria for Subscriber Traffic section.

> Step 3 | Optional. 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”. Modify default configuration for “unidentified” ACLs for by applying the example configuration in the Configuring an Undefined ACL section.

> Step 4 | Verify your ACL configuration by following the steps in the Verifying the ACL Configuration section.

> Step 5 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Creating ACLs
> To create an ACL, use the following configuration:
> configure
> context <acl_ctxt_name> [ -noconfirm ]
> ip access-list <acl_list_name>
> end
> Notes:

> • | The maximum number of ACLs that can be configured per context is limited by the amount of available memory in the VPN Manager software task. Typically, the maximum is less than 200.

> Configuring Action and Criteria for Subscriber Traffic
> To create rules to deny/permit the subscriber traffic and apply the rules after or before action, use the following configuration:
> configure
> context <acl_ctxt_name> -noconfirm
> ip 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:

> • | Use the information provided in the Actions and Criteria sections of this chapter to configure the rules that comprise the ACL. For more information, refer ACL Configuration Mode Commands in Command Line Interface Reference.

> • | The maximum number of rules that can be configured per ACL varies depending on how the ACL is to be used. For more information, refer Engineering Rules in System Administration Guide.

> Caution: Unless configured to do otherwise, the system implicitly adds a “deny any” rule to the end of the ACL resulting in the packet being dropped if it does not match any other configured rule. This behavior can be changed by adding a “permit any” rule as the last rule in the ACL.
> Configuring an “Undefined” ACL
> As discussed previously in this chapter 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
> Notes:

> • | Context name is the name of the context containing the “undefined” ACL to be modified. For more information, refer Context Configuration Mode Commands in Command Line Interface Reference.

> Verifying the ACL Configuration
> To verify the ACL configuration:

> Step 1 | In the Exec Mode, enter the following command:

> show ip access-list
> 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 1.2.3.4
> deny ip any host 1.2.3.4
> permit any 1.2.4.4
> 1 ip access-lists are configured.
> Applying IP ACLs
> Once an ACL is configured, it must be applied to take effect.
> As discussed earlier, an ACL can be applied to any of the following:

> • | Applying an ACL to an Individual Interface

> • | Applying an ACL to All Traffic Within a Context (known as a policy ACL)

> • | Applying an ACL to an Individual Subscriber

> • | Applying a Single ACL to Multiple Subscribers

> • | Applying a Single ACL to Multiple Subscribers via APNs (for 3GPP subscribers only)

> Important: ACLs must be configured in the same context in which the subscribers and/or interfaces to which they are to be applied. Similarly, ACLs to be applied to a context must be configured in that context.
> If ACLs are applied at multiple levels within a single context (i.e. an ACL is applied to an interface within the context and another ACL is applied to the entire context), they will be processed as shown in the following figure and table.
> ACL Processing Order
> ACL Processing Order Descriptions

> Packet coming from the mobile node to the packet data network (left to right)
> Order | Description
> 1 | An inbound ACL configured for the receiving interface in the Source Context is applied to the tunneled data (i.e. the outer IP header). The packet is then forwarded to the Destination Context.
> 2 | An inbound ACL configured for the subscriber (either the specific subscriber or for any subscriber facilitated by the context) is applied.
> 3 | A context ACL (policy ACL) configured in the Destination Context is applied prior to forwarding.
> 4 | An outbound ACL configured on the interface in the Destination Context through which the packet is being forwarded is applied.
> Packet coming from the packet data network to the mobile node (right to left)
> Order | Description
> 1 | An inbound ACL configured for the receiving interface configured in the Destination Context is applied.
> 2 | An outbound ACL configured for the subscriber (either the specific subscriber or for any subscriber facilitated by the context) is applied. The packet is then forwarded to the Source Context.
> 3 | A context ACL (policy ACL) configured in the Source Context is applied prior to forwarding.
> 4 | An outbound ACL configured on the interface in the Source Context through which the packet is being forwarded is applied to the tunneled data (i.e. the outer IP header).

> ‌
> In the event that an IP ACL is applied that has not been configured (i.e. the name of the applied ACL was configured incorrectly), the system uses an “undefined” ACL mechanism for filtering the packet(s).
> This section provides information and instructions for applying ACLs and for configuring an “undefined” ACL.
> Applying an ACL to an Individual Interface
> This section provides information and instructions for applying one or more ACLs to an individual interface configured on the system.
> Important: It is recommended that all ACLs be configured and verified according to the instructions in the Configuring ACLs on the System section of this chapter prior to beginning this procedure.
> Important: This section provides the minimum instruction set for applying the ACL list to an interface on the system. For more information on commands that configure additional parameters and options, refer Ethernet Interface Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to provide ACL facility to subscribers:

> Step 1 | Apply the configured access control list by applying the example configuration in the Applying ACL to Interface section.

> Step 2 | Verify that ACL is applied properly on interface by following the steps in the Verifying the ACL Configuration on Interface section.

> Step 3 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Applying ACL to Interface
> To apply the ACL to an interface, use the following configuration:
> configure
> context <acl_ctxt_name> -noconfirm
> interface <interface_name>
> ip 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 ACL to be applied must be configured in the context specified by this command.

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

> Verifying the ACL Configuration on Interface
> This section describes how to verify the ACL configuration.

> Step 1 | In the Exec Mode, enter the following command:

> show configuration context context_name
> context_name is the name of the context containing the interface to which the ACL(s) was/were applied.
> The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
> configure
> context context_name
> ip access-list acl_name
> deny host ip_address
> deny ip any host ip_address
> exit
> ip access-group access_group_name
> service-redundancy-protocol
> exit
> interface interface_name
> ip address ip_address/mask
> exit
> subscriber default
> exit
> aaa group default
> exit
> gtpp group default
> end
> Applying an ACL to All Traffic Within a Context
> This section provides information and instructions for applying one or more ACLs to a context configured within a specific context on the system. The applied ACLs, known as policy ACLs, contain rules that apply to all traffic facilitated by the context.
> Important: It is recommended that all ACLs be configured and verified according to the instructions in the Configuring ACLs on the System section of this chapter prior to beginning this procedure.
> Important: This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer Context Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to provide access control list facility to subscribers:

> Step 1 | Apply the configured ACL as described in the Applying ACL to Context section.

> Step 2 | Verify that ACL is applied properly on interface as described in the Verifying the ACL Configuration in a Context section.

> Step 3 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Applying ACL to Context
> To apply the ACLs to a context, use the following configuration:
> configure
> context <acl_ctxt_name> [ -noconfirm ]
> ip 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 are applied only to outgoing packets. The in and out keywords are deprecated and are only present for backward compatibility.

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

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

> Verifying the ACL Configuration in a Context
> To verify the ACL configuration:

> Step 1 | Verify that your ACL lists were applied properly by entering the following command in Exec Mode:

> show configuration context context_name
> context_name is the name of the context to which the ACL(s) was/were applied.
> The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
> configure
> context context_name
> ip access-list acl_name
> deny host ip_address
> deny ip any host ip_address
> exit
> ip access-group access_group_name
> service-redundancy-protocol
> exit
> interface interface_name
> ip address ip_address/mask
> exit
> subscriber default
> exit
> aaa group default
> exit
> gtpp group default
> end
> Applying an ACL to an Individual Subscriber
> 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. Refer to the AAA Interface Administration and Reference for more detail on this attribute.
> This section provides information and instructions for applying an ACL to an individual subscriber whose profile is configured locally on the system.
> Important: It is recommended that all ACLs be configured and verified according to the instructions in the Configuring ACLs on the System section of this chapter prior to beginning this procedure. Additionally, it is assumed that the subscribers have been previously configured.
> Important: This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to provide access control list facility to subscribers:

> Step 1 | Apply the configured access control list by applying the example configuration in the Applying ACL to an Individual Subscriber section.

> Step 2 | Verify that ACL is applied properly on interface by following the steps in the Verifying the ACL Configuration to an Individual Subscriber section.

> Step 3 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Applying ACL to an Individual Subscriber
> To apply the ACL to an individual subscriber, use the following configuration:
> configure
> context <acl_ctxt_name> -noconfirm
> subscriber name <subs_name>
> ip access-group <acl_list_name> [ in | out ]
> end
> Notes:

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

> • | If neither the in nor the out keyword is specified, the ACL will be applied to all packets in and out.

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

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

> Verifying the ACL Configuration to an Individual Subscriber
> These instructions are used to verify the ACL configuration.

> Step 1 | Verify that your ACL lists were applied properly by entering the following command in Exec Mode:

> show configuration context context_name
> context_name is the name of the context containing the subscriber subs1 to which the ACL(s) was/were applied.
> The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
> configure
> context context_name
> ip access-list acl_name
> deny host ip_address
> deny ip any host ip_address
> exit
> ip access-group access_group_name
> service-redundancy-protocol
> exit
> interface interface
> ip address ip_address/mask
> exit
> subscriber default
> exit
> subscriber name subscriber_name
> ip access-group access_group_name in
> ip access-group access_group_name out
> exit
> aaa group default
> exit
> gtpp group default
> exit
> content-filtering server-group cfsg_name
> response-timeout response_timeout
> connection retry-timeout retry_timeout
> end
> Applying a Single ACL to Multiple 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.
> The system provides for the configuration of subscriber functions that serve as default values when specific attributes are not contained in the individual subscriber’s profile. The following table describes these functions.
> Functions Used to Provide “Default” Subscriber Attributes

> Function | Description
> Subscriber Named default | Within each context, the system creates a subscriber called default. The profile for the subscriber named default provides a configuration template of attribute values for subscribers authenticated in that context. Any subscriber attributes that are not included in a RADIUS-based subscriber profile is configured according to the values for those attributes as defined for the subscriber named default. NOTE: The profile for the subscriber named default is not used to provide missing information for subscribers configured locally.
> default subscriber Command | This command in the PDSN, FA, and HA service Configuration modes specifies a profile from a subscriber named something other than default to use a configuration template of attribute values for subscribers authenticated in that context. This command allows multiple services to draw “default” subscriber information from multiple profiles.

> ‌
> When configured properly, the functions described in the table above could be used to apply an ACL to:

> • | All subscribers facilitated within a specific context by applying the ACL to the profile of the subscriber named default.

> • | All subscribers facilitated by specific services by applying the ACL to a subscriber profile and then using the default subscriber command to configure the service to use that subscriber as the “default” profile.

> Applying an ACL to the Subscriber Named default
> This section provides information and instructions for applying an ACL to the subscriber named default.
> Important: It is recommended that all ACLs be configured and verified according to the instructions in the Configuring ACLs on the System section of this chapter prior to beginning this procedure.
> Important: This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to provide access control list facility to subscribers:

> Step 1 | Apply the configured access control list by applying the example configuration in the Applying an ACL to the Subscriber Named default section.

> Step 2 | Verify that ACL is applied properly on interface by following the steps in the Verifying the ACL Configuration to the Subscriber Named default section.

> Step 3 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Applying an ACL to the Subscriber Named default
> To example to apply the ACL to the default subscriber, use the following configuration:
> configure
> context <acl_ctxt_name> [ -noconfirm ]
> subscriber name <subs_name>
> ip access-group <acl_list_name> [ in | out ]
> end
> Notes:

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

> • | If neither the in nor the out keyword is specified, the ACL will be applied to all packets in and out.

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

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

> Verifying the ACL Configuration to the Subscriber Named default
> These instructions are used to verify the ACL configuration.

> Step 1 | Verify that your ACL lists were applied properly by entering the following command in Exec Mode:

> show configuration context context_name
> context_name is the name of the context containing the subscriber default to which the ACL(s) was/were applied.
> The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
> configure
> context context_name
> ip access-list acl_name
> deny host ip_address
> deny ip any host ip_address
> exit
> ip access-group access_group_name
> service-redundancy-protocol
> exit
> interface interface
> ip address ip_address/mask
> exit
> subscriber name default
> ip access-group access_group_name in
> ip access-group access_group_name out
> exit
> aaa group default
> exit
> gtpp group default
> exit
> content-filtering server-group cfsg_name
> response-timeout response_timeout
> connection retry-timeout retry_timeout
> end
> Applying an ACL to Service-specified Default 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.
> Important: It is recommended that all ACLs be configured and verified according to the instructions in the Configuring ACLs on the System section of this chapter prior to beginning this procedure. Additionally, it is assumed that the services and subscribers have been previously configured.
> Important: This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to provide access control list facility to subscribers:

> Step 1 | Apply the configured access control list by applying the example configuration in the Applying an ACL to Service-specified Default Subscriber section.

> Step 2 | Verify that ACL is applied properly on interface by following the steps in the Verifying the ACL Configuration to Service-specified Default Subscriber section.

> Step 3 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Applying an ACL to Service-specified Default Subscriber
> To apply the ACL to a service-specified Default subscriber, use the following configuration:
> configure
> context <acl_ctxt_name> -noconfirm
> { pdsn-service | fa-service | ha-service } <service_name>
> default subscriber <svc_default_subs_name>
> exit
> subscriber name <svc_default_subs_name>
> ip access-group <acl_list_name> [ in | out ]
> end
> Notes:

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

> • | If neither the in nor the out keyword is specified, the ACL will be applied to all packets in and out.

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

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

> Verifying the ACL Configuration to Service-specified Default Subscriber
> To verify the ACL configuration.

> Step 1 | Verify that your ACL lists were applied properly by entering the following command in Exec Mode:

> show configuration context context_name
> context_name is the name of the context containing the service pdsn1 having default subscriber to which the ACL(s) was/were applied.
> The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
> configure
> context context_name
> ip access-list acl_name
> deny host ip_address
> deny ip any host ip_address
> exit
> ip access-group access_group_name
> interface interface
> ip address ip_address/mask
> exit
> subscriber default
> exit
> subscriber name subscriber_name
> ip access-group access_group_name in
> ip access-group access_group_name out
> exit
> pdsn-service service_name
> default subscriber subscriber_name
> end
> Applying a Single ACL to Multiple Subscribers via APNs
> 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.
> To reduce configuration time, ACLs can alternatively be applied to APN templates for GGSN subscriber. When configured, any subscriber packets facilitated by the APN template would then have the associated ACL applied.
> This section provides information and instructions for applying an ACL to an APN template.
> Important: It is recommended that all ACLs be configured and verified according to the instructions in the Configuring ACLs on the System section of this chapter prior to beginning this procedure.
> Important: This section provides the minimum instruction set for applying the ACL list to all traffic within a context. For more information on commands that configure additional parameters and options, refer Subscriber Configuration Mode Commands chapter in Command Line Interface Reference.
> To configure the system to provide access control list facility to subscribers:

> Step 1 | Apply the configured access control list by applying the example configuration in the Applying an ACL to Multiple Subscriber via APNs section.

> Step 2 | Verify that ACL is applied properly on interface by following the steps in the Verifying the ACL Configuration to APNs section.

> Step 3 | Save your configuration as described in the Verifying and Saving Your Configuration chapter.

> Applying an ACL to Multiple Subscriber via APNs
> To apply the ACL to multiple subscribers via APN, use the following configuration:
> configure
> context <dest_context_name> -noconfirm
> apn <apn_name>
> ip access-group <acl_list_name> [ in | out ]
> end
> Notes:

> • | The ACL to be applied must be in the destination context of the APN (which can be different from the context where the APN is configured).

> • | If either the in or out keyword is not specified, the command is added to the config file twice, once with in and once with out, and the ACL will be applied to all packets inbound and outbound.

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

> Verifying the ACL Configuration to APNs
> To verify the ACL configuration:

> Step 1 | Verify that your ACL lists were applied properly by entering the following command in Exec Mode:

> show configuration context context_name
> context_name is the name of the context containing the APN apn1 having default subscriber to which the ACL(s) was/were applied.
> The output of this command displays the configuration of the entire context. Examine the output for the commands pertaining to interface configuration. The commands display the ACL(s) applied using this procedure.
> configure
> context context_name
> ip access-list acl_name
> deny host ip_address
> deny ip any host ip_address
> exit
> ip access-group access_group_name
> interface interface
> ip address ip_adrress/mask
> exit
> subscriber default
> exit
> apn apn_name
> ip access-group access_group_name in
> ip access-group access_group_name out
> end

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883