This appendix provides engineering guidelines for configuring the system
to meet network deployment requirements.
The Engineering Rules listed in this appendix reflect the maximum
capacity of StarOS. The actual limits of VPC running in a VM are governed by
the amount of vCPU and vMemory capacity allocated to the instance.
StarOS CLI Session
CLI session support is based on the amount of available memory. The
Resource Manager reserves enough resources to support a minimum
of six CLI sessions at all times. One of the six sessions
is further reserved for use exclusively by a CLI session on the
Additional CLI sessions
beyond the prereserved limit are permitted if sufficient
VPC resources are available. If the Resource Manager is
unable to reserve resources for a CLI session beyond those that
are prereserved, users with administratorprivileges
are prompted to create the new CLI session, even without
VPC Interface and
The rules discussed
in this section pertain to the vNIC Ethernet ports designated via
the hypervisor for subscriber traffic.
vNIC Ethernet Ports
Give all hypervisorassigned
logical interfaces a unique name to differentiate the interface
from others in the same context.
A single virtual port
can support multiple hypervisorassigned logical interfaces
when you configure VLAN tags for that port. You can use
VLAN tagging to bind a single port to multiple logical interfaces
that reside in different contexts.
Each vNIC port for
subscriber traffic may contain up to a maximum of 1,024
VLAN tags (maximum of 4,000 VLANs per VPC chassis.
- All hypervisorassigned
logical interfaces must have a valid IP address and subnet.
You configure a single
StarOS logical (named interface per context. That
named interface can have up to 512 ethernet+ppp+tunnel
Different StarOS contexts
can can share the same logical (named interface.
You can apply a maximum
of 256 access control list (ACL rules to a StarOS
In StarOS all ports
are identified by their <slot>/<port>.
Packet Data Network (PDN Interface
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
The default is to
use a single interface within the egress context to facilitate the
You can configure
multiple interfaces in the egress context by using static routes
or dynamic routing protocols.
You may also configure
nexthop default gateways.
A maximum of 63
contexts may be configured per VPC.
Up to 16
interfaces can be configured within a single context.
tunnels (2,048 GRE tunnels per chassis)
IP Addresses and
IP Address Pools
Up to 2,000
IPv4 address pools can be configured within a single context, regardless of the
number of packet processing cards with a total system limit of 5,000 IPv4
address pools for all contexts.
Up to 256
IPv6 pools can be configured within a single context.
also a limit of 4,000,000 pool 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.
supports up to 32,000,000 static IP pool addresses. You can configure a maximum
total of 96,000,000 static IP pool addresses per chassis. Each static IP pool
can contain up to 500,000 addresses.
Each context supports up to 16,000,000
dynamic IP pool addresses. You can configure a maximum total of
32,000,000 dynamic IP pool addresses per chassis. Each dynamic IP
pool can contain up to 500,000 addresses.
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 holdtimer 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.
number of simultaneous subscriber sessions is controlled by the installed
capacity license for the services supported.
number of static address resolution protocol (ARP) entries per context is 128.
number of domains per context is 2,048.
Up to 1,200
static routes per context (48,000 per chassis).
routes per context (6,000 per chassis)
explicit host routes per context (6,000 per chassis)
maps per context
The maximum number of unique VPNv4/VPNv6 learned prefixes per context is
1,024 with 32 Equal Cost Multiple Paths [ECMPs], as 32000 Next-Hop Label
Forwarding Entries (NHLFE) per context are supported.
The maximum number of unique VPNv4/VPNv6 learned prefixes per chassis is
4,096 with 32 ECMP paths, as 128000 NHLFE per chassis are supported.
The maximum number of unique learned prefixes per chassis (either
IPv4/IPv6/VPNv4/VPNv6) is 4,096 with 32 ECMP paths per prefix, as only 4k
ECMP groups are supported.
prefixes can be configured per context (64,000 per chassis)
peers can be configured per context (512 per chassis)
peers per context
monitors per context in support of Interchassis Session Recovery (ICSR)
neighbors per chassis
routes per context (64,000 per chassis)
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.
configure up to 800 AAA server groups per context with following limitations:
per AAA server group (accounting, authentication, charging server, or any
servers per context in AAA Server group mode (accounting, authentication,
charging server, or any combination thereof)
address/NAS identifier (one primary and one secondary per server group per
Up to 12
charging gateway functions (CGFs for GTPP accounting can be configured per
Up to 256
bidirectional forwarding detection (BFD) sessions per context
Refer to the
Rules apppendix in your product administration guide for additional
information on productspecific operating limits.
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.
VPC creates a default
subscriber for each context when the context is made. Configure attributes
for each default subscriber. If a AAAbased subscriber
is missing attributes in the authentication reply message, the
default subscriber attributes in the context where the subscriber was
authenticated are used.
Default is not used
when local authentication (for local subscribers is performed.
subscriber templates on a per AAA realm (domain aliases
configured within a context basis.
subscriber templates on a per PDSN, FA, or HA
- 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
engineering rules apply to services configured within the system:
Configure a maximum
of 256 services (regardless of type per system.
Large numbers of services
greatly increase the complexity of management and may affect overall
system performance. Therefore, you should not
configure a large number of services unless your application absolutely
requires it. Please contact your Cisco 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:
number of rules per ACL is 128.
number of ACL rules applied per port is 128.
number of ACL rules applied per context is 1,024.
number of ACL rules per IPSec policy is 1.
number of IPSec ACL rules per context is 1,024.
number of IPSec ACL rules per crypto map is 8.
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 X 8 ACLs = 1,024 ACL
rules per context.
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 = 1,024 (the ACL
rules limit per context