Product Description
The Cisco® Femto
Network Gateway (FNG) enables mobile operators with CDMA2000 networks
to provide 3G services to subscribers with wireless handsets via
Femtocell Access Points (FAPs). The FNG makes it possible for operators
to provide secure access to the operator’s 3G network from
a non-secure network, extend wireless service coverage indoors,
especially where access would otherwise be limited or unavailable,
reduce the load on the macro wireless network, and make use of existing
backhaul infrastructure to reduce the cost of carrying wireless
calls.
The FNG functions as
a security gateway that allows the FAPs in the access network to
connect to circuit, packet, and IMS core networks. The FNG implements
an IPSec interface to provide a secure, encrypted IPSec tunnel to
each FAP in the access network as it connects to the operator’s
core network. In addition, the FNG provides a highly scalable femtocell
solution by allowing a large number of FAPs to interoperate with
legacy core network elements that are typically not designed to
interface with such a large number of elements.
The FNG splits voice
and data traffic flows into and out of the core network. It forwards
all voice traffic to the operator’s IMS core network and
all data traffic to the PDSN/HA toward the packet data
network. This network configuration fully isolates the traditional
MSC from IP attacks, because all backhauled traffic is secure and
offloaded to a convergence server in the IMS core network.
Platform Requirements
The FNG service
runs on a Cisco® ASR 5x00 chassis running StarOS. The chassis
can be configured with a variety of components to meet specific
network deployment requirements. For additional information, refer
to the installation guide for the chassis and/or contact
your Cisco account representative.
Licenses
The FNG is a licensed
Cisco product. Separate session and feature licenses may be required. Contact
your Cisco account representative for detailed information on specific
licensing requirements. For information on installing and verifying
licenses, refer to the “Managing License Keys” section
of the “Software Management Operations” chapter
in the System Administration Guide.
Network Deployment(s)
and Interfaces
This section
describes the FNG as it functions in a CDMA2000 network.
The figure below shows
how the FNG functions both as a security gateway and a femtocell
gateway between the FAPs in the access network and the operator’s
IMS core network for voice services and the PDSN/HA and
the packet data network for data services.
Figure 1. FNG Network Architecture
Network Elements
This section
provides a description of the network elements in an FNG network.
Femtocell Access
Point
The Femtocell
Access Point (FAP) is a SIP-based CDMA2000 wireless access point
that provides coverage in a small area, usually a private residence
or small office, and connects the subscriber UEs to an operator’s
core network via a broadband connection (e.g., DSL or cable). A
FAP allows operators to extend wireless service coverage indoors,
especially where access would otherwise be limited or unavailable.
Femtocell Management
System
The Femtocell
Management System (FMS) is a network element that resides in the
operator’s network and facilitates the provisioning, activation,
and operational management of the FAPs in the network based on industry
standards such as TR-069. The FMS helps to ensure the scalability
of the FAP network to potentially millions of devices.
Femto Network Gateway
The Femto Network
Gateway (FNG) is a network element that resides in the operator’s
network and functions as both a security gateway and a femtocell
gateway. The security gateway functions provide secure access for
the FAPs to access services within the operator’s core
network. The femtocell gateway functions provide aggregation and
proxy capabilities for the FAPs. The FNG forwards all voice traffic
to the operator’s IMS core network and all data traffic
to the PDSN/HA.
Femtocell AAA Server
The Femtocell
AAA Server provides a FAP authorization function. It sends authorization policy
information to the FNG.
IMS Core Network
Elements
An operator’s
IMS core network may include the following elements to enable voice
services:
-
P-CSCF: The P-CSCF
(Proxy Call/Session Control Function) is the entry point
into the IMS domain and serves as the outbound proxy server for
SIP messaging for the subscriber UEs. The UEs attach to the P-CSCF
prior to performing IMS registrations and initiating SIP sessions.
All SIP signaling traffic to and from the FAPs and the IMS core
is handled by the P-CSCF. The P-CSCF provides message manipulation,
breakout of emergency call services, QoS (Quality of Service) authorization,
and signaling compression. Once the P-CSCF completes all of the
functions for which it is responsible, it forwards the call to the
I-CSCF.
-
I-CSCF: The I-CSCF
(Interrogating Call/Session Control Function) functions
as a location server in the IMS core network. Its major functions
are to select the appropriate registrar server for the subscriber
UEs by consulting the HSS (Home Subscriber Server) and forwarding
the request to the IMS registrar (the S-CSCF). The HSS returns a
set of required S-CSCF capabilities for initial registration requests
by the UE. Based on these capabilities, the I-CSCF selects the appropriate
S-CSCF.
-
S-CSCF: The S-CSCF
(Serving Call/Session Control Function) provides session control
and registration services for the subscriber UEs and FAPs in the
network. It is responsible for all aspects of session control, handling
all subscriber requests, which it relays to the appropriate application
server. The S-CSCF routes mobile-terminating traffic to the P-CSCF
and routes mobile-originating traffic to the convergence server
based on iFC (initial Filter Criteria) downloaded from the HSS.
-
HSS: The HSS (Home
Subscriber Server), is the master user database that supports the
IMS network entities that handle calls. It contains subscription-related
information (subscriber profiles), performs authentication and authorization
of the user, and provides information about the subscriber's location
and IP information.
-
Femtocell Convergence
Server: The Femtocell Convergence Server (FCS) is an IMS application
server that provides legacy Telephony Application Services (TAS)
to 1x femtocell subscribers via SIP, including voice services and
voice feature delivery. The femtocell convergence server also manages
idle and active mode mobility for 1x subscribers as they move into
and out of range of FAP coverage. It functions as an MFIF (MAP-Femtocell
Interworking Function) and interfaces with the HLR for 1x subscriber
authentication. It appears as an IMS application server to the S-CSCF
and as a serving MSC to the HLR.
-
Media Gateway: The
Media Gateway terminates bearer channels from the circuit-switched
network and media streams from the packet-switched network. It can
support media conversion, bearer control, and payload processing
(e.g., using codecs, echo cancellers, and conference bridges).
PDSN/HA
The PDSN/HA
enables femtocell subscribers to receive packet data services in
the mobile operator's core network. In most cases, these services
are the same as those available via the mobile operator's macro
network.
Basic Operation
When a FAP powers
up, it uses DNS resolution to resolve its pre-configured FQDN of
the FNG and obtain the FNG’s IP address. It then initiates
IPSec tunnel establishment over the broadband access network. The
IPSec tunnel terminates at the FNG.
The FAP receives an
IPv4 address known as the Tunnel Inner Address (TIA) from the FNG
during the first IPSec tunnel establishment. The FNG assigns the TIA
from its own IPv4 address pool. Once an IPSec tunnel is established,
the FAP uses the TIA in all its SIP messages and to obtain configuration
data from its FMS. The FNG is agnostic in regard to the protocol
used between the FAP and its FMS, and simply forwards packets between
the FAP and the FMS over the secure connection.
The 1x FAP performs
P-CSCF discovery via a DHCP server per RFC 3319, or it may receive
the IP address of the P-CSCF from the FMS. Once the FAP gets the
P-CSCF address, it initiates SIP registration with the IMS core
network. When a UE attaches to the FAP, it performs 1x registration
with the IMS core network.
Network Interfaces
The following
table provides descriptions of the network interfaces supported
by the FNG in a CDMA2000 network.
Table 1. Network Interfaces
in a CDMA2000 Network
Interface |
Description |
FAP Interface
|
The secure interface
to the FAPs in the network is an IPSec tunnel. The FNG uses IKEv2
for establishing the IPSec tunnel.
Note that the FNG does
not have a direct interface to the UEs in the network. The FNG receives
all voice and data traffic from the UEs via secure IPSec tunnels
between the FNG and the FAPs and sends the traffic to the operator’s
IMS core or PDSN/HA.
|
RADIUS Interface
|
The interface to the
RADIUS server is used for FAP device authentication. The FAP can
use one of the following authentication methods:
- EAP-AKA (Extensible Authentication
Protocol - Authentication and Key Agreement) authentication
- PSK (Pre-Shared Key)
authentication
- X.509 certificate-based
peer (client) authentication
|
Interface with the IMS
Core
|
The FNG sends all SIP
signaling and bearer traffic from the FAPs to the IMS core to access
voice services.
|
Interface with the PDSN/HA
|
The
FNG sends all signaling and bearer traffic from the FAPs to the
PDSN/HA to access packet data services. |
Features and Functionality
This section
describes the features and functions supported by the FNG.
The following features
are supported and described in this section:
FNG Service
The FNG service
and its associated processes enable the system to function as a
femtocell gateway. The FNG service enables the FAPs in the network
to connect to the core network elements via a secure IPSec interface.
During configuration, you create the FNG service in an FNG context,
which is a routing domain on the ASR 5x00. FNG context and service
configuration includes the following main steps:
-
Configure the IPv4 address
for the service: This is the IP address of the FNG to which
the FAPs in the network attempt to connect, sending IKEv2 messages
to this IP address to establish IPSec tunnels.
-
Configure the name of
the crypto template for IKEv2/IPSec: A crypto template
is used to configure an IKEv2/IPSec policy. It includes
most of the IKEv2 and IPSec parameters for keep-alive, lifetime,
NAT-T, and cryptographic and authentication algorithms. There must
be one crypto template per FNG service.
-
The name of the EAP
profile: This profile defines the EAP authentication method
and associated parameters. If the PSK (Pre-Shared Key) authentication
method is used, this configuration is not needed.
-
IKEv2 and IPSec transform
sets: Transform sets define the negotiable algorithms for IKE
SAs and Child SAs to enable calls to connect to the FNG.
-
The setup timeout value: This
parameter specifies the session setup timeout timer value. The FNG
terminates a connection attempt if the FAP does not establish a
successful connection within the specified timeout period.
-
Max-sessions: This
parameter sets the maximum number of subscriber sessions allowed
by this FNG service.
-
FNG supports a domain
template for storing domain-related configuration: The domain
name is taken from the received Network Address Identifier (NAI)
and searched in the domain template database.
-
Duplicate session detection
parameters: The FNG supports the FAP ID in the form of an NAI
for duplicate session detection. This setting enables duplicate
session detection for the FNG service.
When the FNG service
is configured in the system with the IP address, crypto template,
and so on, the FNG is ready to accept IKEv2 control packets for
establishing IKEv2 sessions.
IKEv2 and IP Security
(IPSec) Encryption
The FNG supports
IKEv2 and IPSec encryption using IPv4 addressing. IKEv2 and IPSec
encryption enables network domain security for all IP packet-switched
networks in order to provide confidentiality, integrity, authentication,
and anti-replay protection.
At the beginning of
IKEv2 session setup, the FNG and the FAP exchange capabilities for
authentication. IKEv2 and IPSec transform sets configured in the
crypto template define the negotiable algorithms for IKE SA and
Child SA setup to connect calls to the FNG by creating a single
IPSec tunnel, called the Tunnel Inner Address (TIA), which is intended for
user traffic coming from the FAP. There can be multiple UEs connecting
to a single FAP at the same time, and the traffic from all of the
connected UEs passes through the same IPSec tunnel. The FAP to which
a UE is connected can request one of the following authentication
methods:
- EAP-AKA (Extensible
Authentication Protocol - Authentication and Key Agreement) authentication
- PSK (Pre-Shared Key)
authentication
- X.509 certificate-based
peer (client) authentication
The FNG partially supports
the EAP MD5 (Extensible Authentication Protocol Message-Digest 5)
authentication method.
X.509 Certificate-based
Peer Authentication
In addition to
the EAP-AKA (Extensible Authentication Protocol - Authentication
and Key Agreement) and PSK (Pre-Shared Key) peer authentication
methods, the FNG supports X.509 certificate-based peer authentication.
The FNG checks the
network policy on whether a FAP is authorized to provide service.
If the network policy states that all FAPs that pass device authentication
are authorized to provide service, no further authorization check
may be required. If the network policy requires that each FAP be
individually authorized for service (in the case where the FEID is
associated with a valid subscription), the FNG sends a RADIUS Access-Request
message to the AAA server. If the AAA server sends a RADIUS Access-Accept
message, the FNG proceeds with device authentication. Otherwise,
the FNG terminates the IPSec tunnel setup by sending an IKEv2 Notification
message indicating authentication failure.
For a detailed presentation
of X.509 certificate-based peer authentication, see the section How the FNG Works later
in this chapter.
A12 Aggregation
The Access Network
AAA (AN-AAA) servers in 1x networks are not designed to handle a large
numbers of FAPs attempting A12 authentication to access the network.
The A12 aggregation feature reduces the number of source addresses
in the A12 Access-Request messages sent to the AN-AAA servers by
the FNG, which simplifies the configuration of the AN-AAA server's
database.
A12 authentication is
a CHAP-based authentication method used by CDMA2000 AN-AAA servers
to provide High Rate Packet Data (HRPD) access authentication between
the AN function in the FAPs and the AN-AAA servers in the network.
When the FNG receives
an A12 Access-Request message from a FAP, it validates the source address
of the FAP, then substitutes the source address (and, optionally,
the NAS IP address/port number) in the Access-Request message
with its own source address before sending the message to the AN-AAA
server. When the FNG receives the Access-Accept message from the
AN-AAA server, the FNG sends it back to the FAP. In this way, the
number of AAA sessions required by the AN-AAA server is reduced.
RADIUS Support
RADIUS support
on the FNG provides a mechanism for performing authentication, authorization,
and accounting (AAA) for subscribers. The benefits of using AAA
are:
- Higher flexibility for
subscriber access control
- Better accounting, charging,
and reporting options
- Industry standard RADIUS
authentication
The Remote Authentication
Dial-In User Service (RADIUS) protocol can be used to provide AAA
functionality for subscribers. The AAA functionality on the FNG
provides a wide range of configuration options via AAA server groups,
which allow a number of RADIUS parameters to be configured in support
of the FNG service.
Currently, two types
of authentication load-balancing methods are supported: first-server and
round-robin. The first-server method sends requests to the highest
priority active server. A request will be sent to a different server
only if the highest priority server is not reachable. With the round-robin
method, requests are sent to all active servers in a round-robin
fashion.
The FNG can detect
the status of the AAA servers. Status checking is enabled by configuration
in the AAA Server Group Configuration Mode of the system’s
CLI. Once an AAA server is detected to be down, it is kept in the
down state up to a configurable duration of time called the dead-time
period. After the dead-time period expires, the AAA server is eligible
to be retried. If a subsequent request is directed to that server
and the server properly responds to the request, the system makes
the server active again.
IMPORTANT:
In 12.3 and earlier releases,
refer to the AAA and
GTPP Interface Administration and Reference for more information
on RADIUS AAA configuration.
AAA Server Group
Selection
This feature
provides a maximum of 64 AAA groups on the ASR 5x00. This could
be spread across multiple contexts or all groups can be configured
within a single context. A maximum of 320 RADIUS servers is allowed
on the chassis, unless the aaa-large-configuration command
is issued, and this number becomes a maximum of 800 AAA groups and
1600 RADIUS servers allowed to be configured per chassis.
IMPORTANT:
In 12.3 and earlier
releases, refer to the AAA
and GTPP Interface Administration and Reference for more information
on AAA server groups.
FAP ID-based Duplicate
Session Detection
When this feature
is enabled and a FAP sets up a new session, the FNG automatically
checks for any remnants of abandoned calls, and if found, clears
them. Clearing the old session and establishing the new session
in parallel optimizes FNG processing functions.
With every new session
setup, the FNG verifies whether there are any old sessions that
are bound to the Femtocell Access Point Identifiers (FAP IDs). For
example, when a FAP reboots, it may initiate a new session with
the FNG. After authentication, if the FNG detects an old session
with the same FAP ID, the FNG clears the old IPSec tunnel and establishes a
new IPSec tunnel with the FAP. This feature is designed with the
assumption that not more than one call with duplicate FAP IDs is
in the setup stage at any one time.
You enable FAP ID-based
duplicate session detection in the FNG Service Configuration Mode
of the system’s CLI. This feature should be enabled in
the boot-time configuration before any calls are established.
Tunnel Cleanup
on FAP Reboot
The FNG supports
initial contact handling in IKE_AUTH messages as per RFC
4306 and cleans up the original tunnel if a FAP initiates a new
tunnel after a reboot. The CLI command for duplicate session detection
is not needed to enable this detection. Initial contact notification
asserts that this IKE_SA is the only IKE_SA currently
active between the authenticated identities. It may be sent when
an IKE_SA is established after a crash, and the recipient
may use this information to delete any other IKE_SAs it
has for the same authenticated identity without waiting for a timeout.
Child SA Rekey Support
Rekeying of an
IKEv2 Child Security Association (SA) occurs for an already established Child
SA whose lifetime (either time-based or data-based) is about to
exceed a maximum limit. The FNG initiates rekeying to replace the
existing Child SA. During rekeying, two Child SAs exist momentarily (500ms
or less) to ensure that transient packets from the original Child
SA are processed by the FNG and not dropped.
FNG-initiated Child
SA rekeying is disabled by default, and rekey requests are ignored.
You can enable this feature in the Crypto Configuration Payload
Mode of the system’s CLI.
Multiple Child SAs
The FNG supports
the instantiation, termination, and rekeying of multiple simultaneous Child
SAs derived from an IKE SA, as defined in RFC 4306.
As specified in the
IKEv2 policy, which controls the behavior of encrypted tunnels,
the first Child SA is instantiated during the IKE_AUTH
exchange between the FAP and the FNG, and any additional Child SAs
are instantiated during subsequent CREATE_CHILD_SA
exchanges that may occur between the FAP and the FNG.
An IKEv2 policy may
be terminated via operator intervention or be terminated when a service
is terminated. In these scenarios, all objects derived from the
IKEv2 policy, including the IKE SA and all Child SAs, are terminated.
The FNG maintains two
maximum Child SA values per IKEv2 policy. The first is a system-enforced
maximum value, which is four Child SAs per IKEv2 policy. The second
is a configurable maximum value, which can be a value between one
and four, and which is specified via the system’s CLI in
the Crypto Template Configuration Mode.
If the system maximum
value or the configured maximum value is reached and the FNG receives
a CREATE_CHILD_SA Request for an additional Child
SA, the FNG returns a CREATE_CHILD_SA Response
that contains a Notify payload of the type NO_ADDITIONAL_SAS.
Note that the maximum value does not apply to interim Child SAs
that may exist during transitional phases such as during Child SA
rekeying. For example, if a maximum of two simultaneous Child SAs
are specified, the FNG allows a burst of four during Child SA rekeying.
DoS Protection Cookie
Challenge
There are several
known types of Denial of Service (DoS) attacks associated with IKEv2. Through
a configurable option in the Crypto Template Configuration Mode
in the system’s CLI, the FNG can implement the IKEv2 cookie
challenge payload method per RFC 4306. This method is intended to
protect against the FNG creating too many half-opened sessions or
other similar mechanisms.
This feature is disabled
by default. When enabled, and when the number of half-opened IPSec
sessions exceeds the configured limit of any integer between 0 and 100,000
(or the trigger point with other detection mechanisms), the FNG
invokes the cookie challenge payload mechanism to insure that only
legitimate subscribers are initiating IKEv2 tunnel requests, as
follows:
- The FAP connects to the
FNG and sends an IKE_SA_INIT Request message.
- The FNG sends a Notify
(cookie) payload to the FAP to request retransmission of the IKE_SA_INIT
Request message with the received Notify (cookie) payload in the message.
- Upon receipt of the retransmitted
message, the FNG verifies the cookie payload and ensures that it
is the same cookie payload as the one it had sent.
- If the cookie challenge
is met, setup continues as normal with the FNG sending an IKE_SA_INIT
Response message.
IKEv2 Keep-Alive
Messages (Dead Peer Detection)
The FNG supports
IKEv2 keep-alive messages, also known as Dead Peer Detection (DPD), originating
from both the FAPs and the FNG. You configure DPD per FNG service.
You can also disable DPD, and the FNG will not initiate DPD exchanges
with the FAPs. However, the FNG always responds to DPD availability
checks initiated by a FAP regardless of the FNG configuration.
DSCP Marking
If different
classes of traffic are sent on the same SA and if the FAPs in the
network and the FNG are employing the optional anti-replay feature
in the Encapsulating Security Payload (ESP), this could result in
inappropriate discarding of lower priority packets due to the windowing
mechanism used by this feature. Therefore, it is recommended that
multiple Child SAs are used to provide the appropriate QoS services.
This handling can be applied to different types of traffic (voice
and data) coming from the same UE behind a FAP, or from multiple
UEs belonging to the same QoS class. The FNG will determine the
traffic type and provide a QoS treatment based on configured rules.
Custom DNS Handling
The custom DNS
feature provides a mechanism whereby the FNG sends the DNS address specified
in the FNG configuration file to the FAP only if the FAP requests
it. The FNG considers an address of 0.0.0.0 invalid and does not
include it.
Session Recovery
Support
The session
recovery feature provides seamless failover and nearly instantaneous
reconstruction of subscriber session information in the event of
a hardware or software fault within the same chassis, preventing
a fully-connected user session from being dropped.
IMPORTANT:
Use of the session recovery
feature requires that a valid license key be installed. Contact
your local Sales or Support representative for information on how
to obtain a license.
Session recovery is
performed by mirroring key software processes (the IPSec manager, session
manager, and AAA manager, for example) on the FNG. These mirrored
processes remain in an idle state (in standby mode), where they
perform no processing until they may be needed in the case of a
software failure (a session manager task aborts, for example). The
system spawns new instances of standby mode sessions and AAA managers
for each active control processor being used.
Additionally, other
key system-level software tasks such as VPN manager are performed
on a physically separate PSC/PSC2 to ensure that a double
software fault (the session manager and the VPN manager fail at
same time on same card, for example) cannot occur. The PSC/PSC2
used to host the VPN manager process is in active mode and is reserved
by the operating system for this sole use when session recovery
is enabled.
IMPORTANT:
For more information
about session recovery support, refer to the System Administration
Guide.
Congestion Control
The congestion
control feature allows you to set policies and thresholds and specify
how the system reacts when faced with a heavy load condition.
The congestion control
feature monitors the system for conditions that could potentially
degrade performance when the system is under heavy load. Typically,
these conditions are temporary (for example, high CPU or memory
utilization) and are resolved quickly. However, continuous or large
numbers of these conditions within a specific time interval may
have an impact on the system’s ability to service subscriber
sessions. Congestion control helps identify such conditions and
invokes policies for addressing the situation.
Congestion control operation
is based on configuring the following:
-
Congestion Condition
Thresholds: Thresholds dictate the conditions for which congestion
control is enabled and establishes limits for defining the state
of the system (congested or clear). These thresholds function in
a way similar to operation thresholds that are configured for the
system as described in the Thresholding
Configuration Guide. The primary difference is that when congestion
thresholds are reached, a service congestion policy and an SNMP
trap, starCongestion, are generated. A threshold tolerance dictates
the percentage under the configured threshold that must be reached
in order for the condition to be cleared. An SNMP trap, starCongestionClear,
is then triggered.
-
Port Utilization Thresholds: If
you set a port utilization threshold, when the average utilization
of all ports in the system reaches the specified threshold, congestion
control is enabled.
-
Port-specific Thresholds: If
you set port-specific thresholds, when any individual port-specific
threshold is reached, congestion control is enabled system-wide.
-
Service Congestion
Policies: Congestion policies are configurable for each service.
These policies dictate how services respond when the system detects
that a congestion condition threshold has been crossed.
IMPORTANT:
For more information
on congestion control, refer to the System Administration Guide.
Bulk Statistics
Bulk statistics
allow operators to choose to view not only statistics that are of
importance to them, but to also configure the format in which they
are presented. This simplifies the post-processing of statistical
data since it can be formatted to be parsed by external, back-end
processors.
When used in conjunction
with the Web Element Manager, the data can be parsed, archived,
and graphed.
The system can be configured
to collect bulk statistics and send them to a collection server called
a receiver. Bulk statistics are statistics that are collected in
a group. The individual statistics are grouped by schema. The following
is a partial list of supported schemas:
- System: Provides
system-level statistics.
- Card: Provides card-level
statistics.
- Port: Provides port-level
statistics.
- FNG: Provides FNG
service statistics.
The system supports
the configuration of up to four sets (primary/secondary)
of receivers. Each set can be configured to collect specific sets
of statistics from the various schemas. Statistics can be pulled
manually from the system or sent at configured intervals. The bulk
statistics are stored on the receiver(s) in files.
The format of the bulk
statistic data files can be configured by the user. Users can specify
the format of the file name, file headers, and/or footers
to include information such as the date, system host name, system
uptime, the IP address of the system generating the statistics (available for
headers and footers only), and/or the time that the file
was generated.
When the Web Element
Manager is used as the receiver, it is capable of further processing the
statistics data through XML parsing, archiving, and graphing.
The Bulk Statistics
Server component of the Web Element Manager parses collected statistics
and stores the information in the PostgreSQL database. If XML file
generation and transfer is required, this element generates the
XML output and can send it to a northbound NMS or an alternate bulk
statistics server for further processing.
Additionally, if archiving
of the collected statistics is desired, the Bulk Statistics Server writes
the files to an alternative directory on the server. A specific
directory can be configured by the administrative user or the default
directory can be used. Regardless, the directory can be on a local
file system or on an NFS-mounted file system on the Web Element
Manager server.
IMPORTANT:
For more information
on bulk statistic configuration, refer to the “Configuring
and Maintaining Bulk Statistics” chapter of the System Administration Guide.
Threshold Crossing
Alerts
Thresholding on
the system is used to monitor the system for conditions that could
potentially cause errors or outages. Typically, these conditions
are temporary (i.e., high CPU utilization or packet collisions on
a network) and are quickly resolved. However, continuous or large
numbers of these error conditions within a specific time interval
may be indicative of larger, more severe issues. The purpose of
thresholding is to help identify potentially severe conditions so
that immediate action can be taken to avoid and/or minimize
system downtime.
The system supports threshold
crossing alerts for certain key resources such as CPU, memory, IP
pool addresses, and so on. With this capability, the operator can
configure a threshold on these resources whereby, should the resource
depletion cross the configured threshold, an SNMP trap would be
sent.
The following thresholding
models are supported by the system:
-
Alert: A value is
monitored and an alert condition occurs when the value reaches or
exceeds the configured high threshold within the specified polling
interval. The alert is generated, then generated and/or
sent again at the end of the polling interval.
-
Alarm: Both high
and low thresholds are defined for a value. An alarm condition occurs
when the value reaches or exceeds the configured high threshold
within the specified polling interval. The alert is generated, then
generated and/or sent again at the end of the polling interval.
Thresholding reports
conditions using one of the following mechanisms:
- SNMP Traps: SNMP
traps have been created that indicate the condition (high threshold
crossing and/or clear) of each of the monitored values.
Generation of specific traps can be enabled or disabled on the chassis,
ensuring that only important faults get displayed. SNMP traps are
supported in both Alert and Alarm modes.
- Logs: The system
provides a thresholding facility for which active and event logs
can be generated. As with other system facilities, logs are generated
messages pertaining to the condition of a monitored value are generated
with a severity level of WARNING. Logs are supported in both Alert
and Alarm modes.
- Alarm System: High
threshold alarms generated within the specified polling interval
are considered outstanding until a condition no longer exists or
a condition clear alarm is generated. Outstanding alarms are reported
to the system’s alarm subsystem and are viewable through
the Alarm Management menu in the Web Element Manager.
IMPORTANT:
For more information
on threshold crossing alert configuration, refer to the Thresholding Configuration Guide.