> Engineering Rules
> This section provides engineering rules or guidelines to consider prior to configuring the system for your network deployment.
> CLI Rules
> Multiple CLI session support is based on the amount of available memory. The Resource Manager reserves enough resources so that at a minimum, support for six CLI sessions is assured at all times. One of the six sessions is further reserved for use exclusively by a CLI session on an SPIO serial interface.
> Additional CLI sessions beyond the pre-reserved limit are permitted if sufficient SMC resources are available. If the Resource Manager is unable to reserve resources for a CLI session beyond those that are pre-reserved, users with administrator-privileges are prompted to create the new CLI session, even without reserved resources.
> Interface and Port Rules
> The rules discussed in this section pertain to the following Ethernet line cards and the type of interfaces they facilitate, regardless of the application:

> • | Fast Ethernet 10/100 (FELC)

> • | Gigabit Ethernet 1000 (GELC)

> • | Quad Gigabit Ethernet (QGLC)

> Line Card Rules
> The following engineering rules apply to the Fast Ethernet 10/100, Gigabit Ethernet 1000, and Quad Gigabit line cards:

> • | Give all logical interfaces a unique name to identify the interface from others in the same context. Logical interfaces in different contexts may have the same name.

> • | A single physical port can support multiple logical interfaces when you configure VLAN tags for that physical port. You can use VLAN tagging to bind a single physical port to multiple logical interfaces that reside in different contexts.

> • | Assign all logical interfaces a valid IP address and subnet.

> • | Give each logical interface within a context a unique IP address(es). Logical interfaces in different contexts can have the same IP address(es).

> • | If multi-homing is supported on the network, you can assign all logical interfaces a single primary IP address and up to 16 secondary IP addresses.

> • | You can configure a logical interface in only one context, but you can configure multiple interfaces (up to 512 Ethernet or 1,024 ATM) in a single context.

> • | You can apply a maximum of 128 ACL rules to a single logical interface.

> • | All ports are identified by their <slot#>/<port#>.

> • | Each physical port on a Gigabit Ethernet 1000 or Quad Gigabit line card may contain up to a maximum of 1024 VLAN tags.

> • | Each physical port on an Fast Ethernet 10/100 Line card may contain up to a maximum of 256 VLAN tags.

> • | The total number of VLANs untagged and/or tagged on each Fast Ethernet 10/100 Line Card must not exceed 1025 (8 untagged + 1017 tagged).

> • | A logical interface is limited to using a single VLAN or ATM PVC on a single physical port, identified by its <cardslot#/port#>.

> • | When using redundant (standby) line cards:

> • | You must configure the active line card only. In the event of a failover, all relevant information (such as the IP address) is transferred to the standby line card.

> • | Assure that the line cards installed in the upper and lower chassis slots behind a single PSC or PSC2 must be of the same type: Fast Ethernet 10/100, Gigabit Ethernet 1000, or Quad Gigabit line cards.

> Important: If you have enabled the Port Redundancy feature, it is possible for ports on both line cards to be active while one provides line card redundancy for the other. With the port redundancy feature, each physical port has a primary MAC address. Each corresponding standby port has a different (alternate) MAC address.
> Packet Data Network (PDN) Interface Rules
> The following engineering rules apply to the interface to the packet data network (PDN):

> • | Configure the logical interfaces used to facilitate the PDN interface within the egress context.

> • | The default is to use a single interface within the egress context to facilitate the PDN interface.

> • | You can configure multiple interfaces in the egress context by using static routes or dynamic routing protocols.

> • | You may also configure next-hop default gateways.

> Packet Processing Card Rules
> The following engineering rules apply to the PSC, and PSC2 processing application cards:

> • | When you configure a processing line card to enter the active mode, it results in the following:

> • | The total number of PSCs or PSC2s that will become operationally active is increased by one.

> • | In the event of a failure, the line card(s) directly behind the PSC or PSC2 will become available directly, or to another PSC/PSC2 via the RCC.

> • | If you want processing-only application cards, all line card slots directly behind them can be empty. Otherwise, disable those line card slots with the shutdown command as described in the Command Line Interface Reference.

> • | If you want standby (redundant) PSCs or PSC2s, do not populate all line card slots directly behind them since they will not be used. If the slots are populated, disable the line card slots with the shutdown command as described in the Command Line Interface Reference.

> • | A line cards is not used unless the processing application card directly in front of it is made active.

> Context Rules

> • | A maximum of 64 contexts may be configured per chassis.

> • | Up to 2000 IP address pools can be configured within a single context (regardless of the number of PSCs or PSC2s) with a total system limit of 5000 IP address pools for all contexts. However, there is also a limit of 4,000,000 addresses and 32,000,000 static addresses that can be configured per context. Therefore, the number of pools depends on how many addresses are being used and how they are subnetted.

> • | Each context supports up to 32,000,000 static IP pool addresses. You can configure a maximum total of M64 x 32M static IP pool addresses per chassis. Each static IP pool can contain up to 500,000 addresses.

> • | Each context supports up to 4,000,000 dynamic IP pool addresses. You can configure a maximum total of 4 x 4M dynamic IP pool addresses per chassis. Each dynamic IP pool can contain up to 500,000 addresses.

> Important: Each address in the pool requires approximately 60 bytes of memory. The amount of memory required, however, depends on a number of factors such as the pool type, and hold-timer usage. Therefore, in order to conserve available memory, you may need to limit the number of pools depending on the number of addresses to be configured and the number of installed application cards.

> • | A maximum of 1,000,000 IP addresses per chassis can be in use at any given time. The maximum number of simultaneous subscriber sessions is controlled by the installed capacity license for the service(s) supported.

> • | The maximum number of static routes that can be configured per context is 1200.

> • | The maximum number of static ARP entries per context is 128.

> • | The maximum number of domains per context is 2,048.

> • | ASN GW services configured within the same context cannot communicate with each other.

> • | A maximum of 512 BGP/AAA monitors can be configured per context for Interchassis Session Recovery support.

> • | You can configure up to 128 AAA servers per context for a default AAA server group. The servers can be configured as accounting, authentication, charging servers, or any combination thereof.

> • | You can configure up to 800 AAA server groups per context with following limitations:

> • | Configure up to 128 servers per AAA server group. The servers can be configured as accounting, authentication, or charging servers, or any combination thereof.

> • | Configure up to 1600 servers per context in AAA Server group mode. The servers can be configured as accounting, authentication, or charging servers, or any combination thereof.

> • | Up to 800 NAS-IP address/NAS identifier (1 primary and 1 secondary per server group) can be configured per context.

> • | Up to 12 charging gateway functions (CGFs) for GTPP accounting can be configured per context.

> Subscriber Rules
> The following engineering rules apply to subscribers configured within the system:

> • | Configure a maximum of 2,048 local subscribers per context.

> • | You may configure attributes for each local subscriber.

> • | The system creates a default subscriber default for each context when the context is made. Configure attributes for each default subscriber. If a AAA-based subscriber is missing attributes in the authentication reply message, the default subscriber attributes in the context where the subscriber was authenticated are used.

> Important: Default is not used when local authentication (for local subscribers) is performed.

> • | Configure default subscriber templates on a per AAA realm (domain aliases configured within a context) basis.

> • | Configure default subscriber templates on a per PDSN, FA,ASN GW, or HA service.

> • | For AAA authenticated subscribers, the selection of local subscriber template to use for setting attributes is in the following order:

> • | If the username (NAI) matches any local domain name and the domain name has a local subscriber name configured, that local subscriber template is used.

> • | If the first case fails, and if the serving service has a default username configured, that subscriber template is used.

> • | If the first two cases fail, the default subscriber template in the AAA context is used.

> Service Rules
> The following engineering rules apply to services configured within the system:

> • | Configure a maximum of 256 services (regardless of type) per system.

> Caution: Large numbers of services greatly increase the complexity of management and may affect overall system performance. Therefore, it is recommended that you do not configure a large number of services unless your application absolutely requires it. Please contact your local service representative for more information.

> • | The total number of entries per table and per chassis is limited to 256.

> • | Although you can use service names that are identical to those configured in different contexts on the same system, this is not a good practice. Services with the same name can lead to confusion and difficulty in troubleshooting problems, and make it difficult to understand the output of show commands.

> Access Control List (ACL) Engineering Rules
> The following rules apply to Access Control Lists:

> • | The maximum number of rules per ACL is 128.

> • | The maximum number of ACL rules applied per port is 128.

> • | The maximum number of ACL rules applied per context is 1024.

> • | The maximum number of ACL rules per IPSEC policy is 1.

> • | The maximum number of IPSEC ACL rules per context is 1024.

> • | The maximum number of ACLs you can configure per context is limited by the number of rules allowed within each ACL. If each ACL contained the maximum number of rules (128), the maximum number of ACLs per context is 8 (128 rules per ACL multiplied by 8 ACLs = 1024 (the ACL rules limit per context)).

> • | The maximum number of ACLs applied to an IP access group is 1 whether it is configured for a port or context. Since the maximum number of IP access groups you can apply to an interface or context is 16, the following calculations apply:

> • | For each interface/port: 8 rules per ACL multiplied by 16 IP access groups = 128 (the ACL rules limit per port)

> • | For each context: 64 rules per ACL multiplied by 16 IP access groups = 1024 (the ACL rules limit per context)

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