cc/td/doc/product/wireless/moblwrls/cmx
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Description of Cisco Mobile Exchange
CMX Network Elements
Supported Features
Physical and Logical Interfaces
Data Traffic Flows
Supported Services
Detailed RADIUS Interactions
Billing Solutions
High Availability Solutions

Description of Cisco Mobile Exchange


This chapter provides a detailed description of the Cisco Mobile Exchange (CMX) framework and contains the following sections:

CMX Network Elements

Cisco's CMX solution for mobile wireless networks combines multiple network elements into a single solution framework. As shown in Figure 3-1, the core of the CMX solution framework is the Cisco 7600 series switch/router. Descriptions of the CMX network elements shown in Figure 3-1 are listed in Table 3-1.


Figure 3-1   CMX Functional Components Overview


Table 3-1   CMX Network Elements

CMX Element Description

Switch/Router (7600)

  • Provides Layer 2 connectivity within CMX
  • Provides external interfaces from/to CMX
  • Performs Layer 2 switching
  • Performs Layer 3 routing

Service Selection Gateway (SSG)

  • Acts as a RADIUS proxy and captures the authentication parameters to offer single sign-on and automatically authenticate the user through SSG
  • Performs TCP redirect to a captive portal
  • Allows multiple service selection
  • Performs domain naming service (DNS) redirection
  • Performs network address translation (NAT)
  • Allows connecting to multiple networks using one Protocol Data Packet (PDP) context and one access point name (APN)
  • Performs charging by generating RADIUS accounting records for postpaid and prepaid billing
  • Allows point-to-point (PPP) regeneration and Layer 2 Tunneling Protocol (L2TP) tunneling

Service Gateway Load Balancer (SGLB)

  • RADIUS Load Balancer (RLB):
    • Load-balances RADIUS messages among multiple SSGs on subscriber side and among multiple AAA servers on network side
    • Load-balances user traffic among multiple SSGs
  • Firewall Load Balancer (FWLB):
    • Directs user traffic from services network to the SSGs

Content Services Gateway (CSG)

  • Collects IP statistics
  • Generates content-based call detail records (CDRs) to a charging gateway (CG) or billing mediation agent (BMA)

Authentication, Authorization, and Accounting (AAA) server (Cisco Access Registrar or equivalent third-party AAA server)

  • Authenticates and authorizes users
  • Contains user service profiles for downloading to SSGs
  • Can allocate IP address for MS
  • Collects accounting records from SSGs and GGSNs
  • Provides front end to Prepaid Server

Prepaid server

  • Provides interface to SSGs using RADIUS
  • Stores user prepaid balances

Billing Mediation Agent (BMA)

  • Collects content-based CDRs from the CSG

Subscriber Edge Services Manager (SESM)

  • Provides session authentication (via AAA server)
  • Provides service subscription
  • Provides service selection (by controlling the SSG)
  • Supports captive portal Web application (provided by IBM) for sessions and services

Remote Console Access (not shown in Figure 3-1)

  • Provides remote access to the CMX elements

CiscoWorks for Mobile Wireless (CW4MW)

  • Provides device-level management

Table 3-2 lists the CMX hardware and software components required for CMX.

Table 3-2   CMX Hardware/Software Configuration

Network Element Platform Software

SSG

7401-BB

IOS 12.2(8)B

RLB

7609 (MSFC)

IOS 12.1(12c)E1

FWLB

7609 (MSFC)

IOS 12.1(12c)E1

AAA server

Sun

Cisco Access Registrar or equivalent

Prepaid server

Sun

Partner (MIND CTI)

BMA

PC

Partner (MIND CTI)

SESM

Sun

SESM 3.1(3)

CW4MW

PC

CW4MW 3.0

Remote Control Access

2611

IOS 12.2T

CSG

7609

CSG 2.2(3)C2(1)/IOS 12.1(12c)E1


Note   Cisco partner can provide AAA server, prepaid server, or BMA components.

Supported Features

This section describes the supported features for Cisco Mobile Exchange components.

Service Selection Gateway Features

The CMX features supported for SSG are listed in Table 3-3.

Table 3-3   SSG Supported Features

Feature Description

SSG functions

Support for service selection and service control for GPRS users

SSG proxy service

SSG acts as a RADIUS proxy for the GGSN to authenticate user and retrieve user profile

SSG pass-through service

SSG support for pass-through service

SSG TCP redirect

SSG redirects unauthenticated users to a captive portal (SESM or other)

SSG tunnel service

SSG support for L2TP service

SSG open garden

SSG access to open garden service (no authentication required)

AAA interface

Interface to AAA server

User/password authentication

AAA support for authentication based on user name and password

Mobile station ISDN (MSISDN) authentication

AAA support for MSISDN-based authentication

Network address translation (NAT) function

Support for NAT

Three-key authentication

Support for authentication based on user name, password, and MSISDN.

Subscriber Edge Services Module Features

The CMX supports interworking between the SESM and the Web portal provider. The Web portal uses the application programming interface (API) provided by the SESM to interact with the SSGs and the AAA server.

The SESM and AAA server use the RADIUS protocol and vendor-specific attributes (VSAs) to interwork. Each of these VSAs requires the SESM to know the target SSG IP address.

High Availability Features

The CMX supports the high availability features listed in Table 3-4.

Table 3-4   High Availability Features

Feature Description

Load balancing for SSGs

SSG load balancing provided on the access path (uplink) and subscriber traffic path (downlink). On SSG failure, incoming user sessions are redirected to available SSGs.

Redundant physical interfaces

CMX network elements support redundant physical interfaces.

Redundant load balancing functions

Load balancing functions are redundant and support a failover mechanism if load balancing fails

No single point of failure

CMX provides no single point of failure

Collection of IP statistics for backup of billing information

CSG supports backup of billing information if SSG fails

Redundant connectivity to AAA

CMX supports redundant connectivity to AAA server

Redundant connectivity to BMA

CMX supports redundant connectivity to BMA

Redundant connectivity to GGSN

CMX supports redundant connectivity to BMA

Billing Features

The CMX supports the billing features listed in Table 3-5.

Table 3-5   Billing Features

Feature Description

Postpaid billing

SSG generates charging records to BMA

Prepaid billing

SSG interworks with third-party prepaid billing server

Content billing

CSG provides call detail records (CDRs) based on HTTP and URLs

Hot billing

SSG and CSG generate charging records in real time to third-party billing server

Network Time Protocol (NTP) support

NTP maintains timing between all CMX entities to ensure accurate time stamps on billing records

Physical and Logical Interfaces

The CMX network elements are connected using Ethernet segments. Each element of the solution uses one or two physical fast Ethernet (FE) interfaces as shown in Figure 3-2. The interfaces run network time protocol (NTP) to maintain timing between the network elements.


Figure 3-2   CMX Physical Interfaces


To increase efficiency and redundancy, the CMX also uses logical Ethernet interfaces. Logical Ethernet interfaces are created by configuring virtual local area networks (VLAN)s. With VLAN configuration, each physical Ethernet interface is separated into 802.1q VLAN interfaces using the 802.1q encapsulation provided by the Cisco IOS.

The CMX interconnections are organized into multiple VLANs that cover three major areas:

The CMX VLAN organization is illustrated in Figure 3-3.


Figure 3-3   CMX VLAN Organization


Data Traffic Flows

A basic understanding of how data traffic flows through the CMX network elements and interconnecting VLANs is beneficial to personnel who are responsible for configuring and maintaining the CMX network elements. The following sequence of events is also illustrated in Figure 3-4 (the numbers in Figure 3-4 correspond to steps below).


Note   The following sequence of events describes only data traffic flows. Traffic flows for RADIUS messages are described in "Detailed RADIUS Interactions" section.

1. The GGSN sends user IP packets to a Multilayer Switch Feature Card (MSFC) in the RLB platform using the open shortest path first (OSPF) algorithm.

2. The MSFC uses policy routing to send the user packet to CSG1.

3. CSG1 directs all traffic on VLAN 17 to the RLB and creates accounting records for the user traffic.

4. RADIUS server load balancing (SLB) software directs the user traffic to the correct SSG.

5. The SSG performs service control and selection by sending the user packets to the selected service. The SSG can also generate RADIUS accounting records and send RADIUS authorization to the prepaid server (via the AAA server) for prepaid sessions.

6. The next hop for all service-bound packets from the SSG is the FWLB. The FWLB registers the downlink path with the correct SSG for downlink IP traffic flow.

7. The next hop is CSG2, which generates billing records for content-based billing. Encrypted AAA or tunneled traffic passes through this CSG unaltered.

8. CSG2 routes the user traffic to a next-hop router or border gateway toward the services network.

9. The downstream user traffic is received on CSG2.

10. The CSG2 generates billing records for content-based billing and sends the user packets to the FWLB.

11. The FWLB forwards the user packet to the same SSG that was used for the uplink traffic flow.

12. The SSG routes the user traffic toward the MSFC in the RLB (downstream traffic is transparent to the RLB).

13. The RLB uses policy routing to send the user traffic to CSG1.

14. CSG1 creates accounting records for the user traffic and generates content-based CDRs to send to the BMA. The user traffic is sent to the MSFC.

15. The MSFC uses the OSPF algorithm to route the user packet to the correct GGSN.

16. The GGSN receives the user packet and encapsulates it in a tunnel (using GTP) toward the mobile station.


Figure 3-4   Example of Data Traffic Flow in CMX


Supported Services

The CMX solution for mobile wireless networks supports the following services (Figure 3-5):


Figure 3-5   CMX Supported Services


Pass-through Service

Pass-through service is typically used to provide standard Internet access to mobile wireless subscribers. This type of service allows subscribers to pass through the service provider's network to access the external PDN. Pass-through service can be configured to authenticate subscribers automatically based on a profile or to provide transparent (unauthenticated) service.

The events that occur to activate authenticated pass-through service are described in the steps below (steps also shown in Figure 3-6).

1. The GGSN sends an access request to the RADIUS Load Balancer (RLB) with the username, MSISDN, and IMSI of the subscriber.

2. The RLB receives the access request, selects an SSG, and forwards the request to the SSG.

3. The SSG receives the request and forwards it to the AAA server.

4. The AAA server authenticates the user and allocates an IP address for the user session. The AAA server sends the IP address and a user profile to the SSG.

5. The SSG forwards this information to the RLB, creates a host object for the user session, and queries the AAA server for the service profile to enable pass-through service.

6. The RLB retrieves the user IP address and sends it to the GGSN.

7. The GGSN sends the IP address to the mobile handset. It also sends a message to the RLB to start accounting records and forwards the message to the SSG.

8. The SSG generates a message to the AAA server to start accounting records.

9. The pass-through is enabled and the user session is active.

10. The SSG periodically sends interim update messages to the AAA server for accounting purposes.

11. The GGSN generates a message to stop RADIUS accounting records when the subscriber terminates access. The RLB clears the user IP address. The SSG sends out messages to each service the subscriber accessed and terminates the host object for the user session.


Figure 3-6   Pass-through Service Events


Transparent pass-through service allows unauthenticated subscriber traffic to be routed through the SSG in either direction. Filters can be specified to control transparent passthrough traffic. Some of the applications for this feature include:

Proxy Service

When a subscriber requests access to a proxy service, the SSG proxies the Access-Request packet to the remote AAA server. On receiving an Access-Accept packet from the remote RADIUS server, the SSG logs the subscriber in. To the remote AAA server, the SSG appears as a client.

If the RADIUS server assigns an IP address to the subscriber during remote authentication, the SSG performs network address translation (NAT) between the assigned IP address and the real IP address of the subscriber. If the remote RADIUS server does not assign an IP address, NAT is not performed.

When a user selects a proxy service, there is another prompt for username and password. After authentication, the service is accessible until the user logs out from the service, logs out from the SESM, or times out.

The events that occur to enable proxy service are described in the steps below (steps also shown in Figure 3-7).

1. The GGSN sends an access request to the RADIUS Load Balancer (RLB).

2. The RLB receives the access request, selects an SSG, and forwards the request to the SSG.

3. The SSG receives the request and performs a full, transparent proxy of the request to the AAA server (to ensure propagation of all RADIUS attributes).

4. The AAA server authenticates the user and allocates an IP address for the user session. The AAA server sends the IP address and a user profile to the SSG.

5. The SSG forwards this information to the RLB and creates a host object for the user session.

6. The RLB retrieves the user IP address and sends it to the GGSN.

7. The GGSN sends the IP address to the mobile handset. It also sends a message to the RLB to start accounting records and forwards the message to the SSG.

8. The SSG proxies the message to the AAA server to start accounting records.

9. The proxy service is enabled and the user session is active.

10. The SSG periodically proxies interim update messages to the AAA server for accounting purposes.

11. The GGSN generates a message to stop RADIUS accounting records when the subscriber terminates access. The RLB clears the user IP address. The SSG sends out messages to each service the subscriber accessed and terminates the host object for the user session.


Figure 3-7   Proxy Service Events


Tunnel Service

Layer 2 Tunneling Protocol (L2TP) enables mobile wireless subscribers to access a tunnel to an L2TP network server (LNS) for virtual private networking (VPN) applications. The typical application for tunnel service is employee access to corporate networks from remote locations. Tunnel services are targeted to enterprises and generate high revenues for service providers.

In this configuration, it is assumed that the CMX is connected to a GGSN through any IP connection.

The events that occur to enable tunnel service are described in the steps below (steps also shown in Figure 3-8).

1. The user is already connected, and a host object is created in the SSG. The user starts a user session on the provider's Web portal.

2. The Web portal (via the SESM) queries the SSG to verify that a host object exists; if no host object exists, the user is redirected (via the TCP redirect feature) to a login page.

3. The user selects the tunnel service on the Web portal; the Web portal sends an access request to the SSG to enable the creation of the tunnel service.

4. The SSG proxies the access request to the AAA server and queries the AAA server for a service profile.

5. The SSG sets up the tunnel service. The SSG can receive an IP address from the remote network server and create a network address translation (NAT) entry between the user's address domain and the address received from the network server.

6. Data traffic flows on the tunnel (see note) established between the user and the remote network server.


Note    An L2TP tunnel exists between the SSG and the remote network server.


Figure 3-8   Tunnel Service Events


The Service Selection Gateway (SSG) supports the tunnel service with the following configurable features:


Note

Auto-logon Feature

The SSG auto-logon feature allows the SSG to automatically create a host object for a user session and retrieve the user profile from the RADIUS messages sent by the GGSN. With the auto-logon feature, the SSG acts as a RADIUS proxy. The following steps describe the sequence of events that occur when the auto-logon feature is configured on the SSG.


Note   Load balancing interactions are excluded from the following sequence to clarify auto-logon interactions between the GGSN, SSG, AAA server, and SESM.

1. When the GGSN receives a request for access from the mobile wireless subscriber, it sends a RADIUS access request to the SSG.

2. The SSG, configured with the auto-logon feature, forwards the request to the AAA server.

3. The AAA server authenticates the user, allocates an IP address, and sends vendor-specific attributes (VSAs) related to the user services.

4. The SSG strips off the SSG VSAs, creates a host object for the user session, and sends this information to the GGSN.

5. The PDP context is created (i.e., the user has an IP connection and can access the SESM with a Web browser). The GGSN sends a message to start accounting records for the session. The message is proxied by the SSG to the AAA server.

6. The SESM receives the HTTP request and queries the SSG.

7. The SSG responds with the username, IP address, service list, and SESM attributes.

8. The SESM uses the RADIUS interface to access a database and retrieve the user service attributes.

9. The service attributes are sent using the RADIUS interface.

10. The user home page is sent in the HTTP response to the subscriber.

Figure 3-9 illustrates these auto-logon interactions:


Figure 3-9   GGSN/SSG/AAA/SESM Interactions for Auto-logon


TCP Redirect Feature

The SSG TCP redirect feature transmits certain packets, which would otherwise be dropped, to captive portals that can handle the packets. Examples of packet redirection include the following:

The following steps describe the sequence of events that occur when the TCP redirect feature is configured on the SSG.


Note   Load balancing interactions are excluded from the following sequence to clarify TCP redirect interactions between the SSG, AAA server, and SESM.

1. An IP-enabled PC accesses the SESM using a Web client. User ID and password fields are presented in HTML format.

2. The SESM translates the user ID and password received via HTML into a RADIUS authentication packet and sends it to the SSG.

3. The SSG forwards the RADIUS request to the AAA server.

4. The AAA server responds to the SSG.

5. The SSG forwards the response to the SESM and creates a host object to establish the user session.

6. The SESM requests service profiles from the AAA server.

7. The AAA server responds to the SESM request with the service profiles.

8. The SESM provides a new HTML page to the user with service selection links.

Figure 3-10 illustrates these TCP redirect interactions:


Figure 3-10   SSG/SESM/AAA Interactions for TCP Redirect Feature


The TCP redirect feature also ensures availability of user sessions in the event that a single SSG fails. The following events occur when an SSG fails:

1. The RADIUS Load Balancer (RLB) detects the failure of the SSG and load balances the user traffic to an alternate SSG.

2. The alternate SSG receives the user data but does not have a host object for the user. The SSG redirects the user traffic to the Web portal.

3. The user establishes an HTTP session with the Web portal using a browser. The user logs in, and the new SSG receives an access request from the Web portal. The user host object is created and pass-through service is established.

4. The user traffic passes through the new SSG.

Detailed RADIUS Interactions

RADIUS messages originate from one of the following network elements:

GGSN-initiated RADIUS Messages

The following sequence of events describes the flow of RADIUS messages that originate from the GGSN during a request for access:

1. The GGSN forwards an Access Request message to the RLB (see Figure 3-11).

2. The RLB selects an SSG from the SSG farm.

3. The selected SSG proxies the request to the AAA-RLB.

4. The AAA-RLB selects the AAA1 server.

5. The AAA1 server is in a failure mode and does not respond to the request.

6. The GGSN retransmits the request.

7. The RLB detects the retransmission and resends the request to the same SSG that was originally selected.

8. The SSG proxies the request to the AAA-RLB.

9. The AAA-RLB selects the AAA2 server and marks the AAA1 server as failed.

10. The AAA2 server returns the Access Accept message to the SSG and then back to the GGSN.

The GGSN-initiated RADIUS message flow is shown in Figure 3-11.


Figure 3-11   GGSN-initiated RADIUS Flows


The RLB uses the RADIUS request identifier to detect retransmissions and mark the AAA server as failed.

The sequence is slightly altered for an Accounting Request message. In this case, the RLB does not detect retransmissions from the GGSN. The RLB marks the SSG as failed. To avoid having the SSG marked as failed because of Accounting Request retranmissions, you can configure a probe on the RLB to periodically verify that one SSG is still operational.

SSG-initiated RADIUS Messages

The following sequence of events describes the flow of RADIUS messages that originate from the SSG during a request for access:

1. The SSG forwards an Access Request message to the AAA-RLB (see Figure 3-12).

2. The AAA-RLB selects the AAA1 server.

3. The AAA1 server is in a failure mode and does not respond to the request.

4. The SSG retransmits the request.

5. The AAA-RLB selects the AAA2 server and marks the AAA1 server as failed.

6. The AAA2 server returns the Access Accept message to the SSG.

SSG-initiated RADIUS message flows are shown in Figure 3-12.


Figure 3-12   SSG-initiated RADIUS Message Flows


The same limitations for GGSN-initiated accounting requests apply to SSG-initiated accounting requests. You can configure a probe on the RLB to periodically verify that one AAA server is still operational.

Billing Solutions

The CMX framework enables a billing solution for mobile wireless operators that is flexible and facilates transition to next-generation networks. In legacy networks, operators charge users based on the duration of the call. In next-generation networks, the user is always on; therefore, charging based on time is not appropriate.

The CMX framework allows per-service billing based on volume (number of packets), type of content, and the applications accessed. The CMX generates the billing and accounting information, which is then used by the billing agent to bill the subscriber.

Cisco enables solutions for prepaid and postpaid billing using two components. The Service Selection Gateway (SSG) provides service volume and time accounting information. The CSG provides information based on content (Layer 4 and Layer 7).

Prepaid Billing

The two CMX components that play key roles in providing prepaid billing are the SSG and the CSG.

SSG Role

The SSG prepaid features allow the SSG to check a subscriber's available credit to determine whether to connect the subscriber to a service and how long the connection can last. The subscriber's credit is administered by the prepaid billing server as a series of quotas representing either a duration of use (in seconds) or an allowable data volume (in bytes). A quota is an allotment of available credit for a service.

To obtain the first quota for a connection, the SSG submits an authorization request to the AAA server. The AAA server contacts the prepaid billing server, which forwards the quota values to the SSG. The SSG monitors the connection to track the quota usage. When the quota runs out, the SSG performs reauthorization. During reauthorization, the billing server can provide the SSG with an additional quota if credit is available. If no further quota is provided, the SSG logs the user off the service. The user can be redirected to a Web server to refill accounts.

A prepaid idle timeout feature allows remaining quota to be returned to the billing server if the connection remains inactive (idle) for a specified period of time. Also, if a disconnect occurs before quota depletion, the SSG returns the unused amount to the billing server.

Figure 3-13 shows the prepaid billing solution provided by the SSG (see note).


Note   The configuration shown in Figure 3-13 integrates the MIND CTI Real-Time Server, which provides the AAA, rating, and billing capabilites for the overall solution.


Figure 3-13   SSG-based Prepaid Billing Solution


As shown in Figure 3-13, the SSG sends an access/authorization request to the billing mediation agent (BMA) to retrieve quotas and accounting records.

CSG Role

The CSG occupies two positions in the CMX configuration. The first CSG in the CMX configuration, represented in Figure 3-13 as CSG1, generates call detail records (CDRs) of statistics and sends them to the BMA. These CDRs are used to restore the user's balance in the event of an SSG failure. This CSG provides an important backup function for the SSG prepaid billing features.

The second CSG in the CMX configuration is configured to provide content-based billing. Web pages are identified by their URLs and charged on a fixed-fare basis, also known as per-page billing. The subscriber incurs billing in real time as the Web page is requested.

The service provider can also configure this CSG to perform per-event billing from within a Web page to charge subscribers for downloading files. These events, also known as stats, must be structured in a keyed directory tree to distinguish them from events for which no billing occurs. Also, subscribers are billed only for files that are completely transferred (i.e., failed downloads are not billed). Files to be downloaded must reside on a dedicated server (i.e., the IP destination address of the downloading server must be different than the IP destination address of the Web server).

Per-page billing (URL-based) and per-event billing (stats) are provided by CSG2 shown in Figure 3-14. The BMA connects to a database and a billing server to verify user balances and perform rating and billing functions (see note).


Note   The configuration shown in Figure 3-14 integrates the MIND CTI Real-Time Server, which provides the AAA, rating, and billing capabilites for the overall solution.


Figure 3-14   CSG-based Content Billing


Postpaid Billing

Postpaid billing based on time and volume usage is implemented by the SSG. The accounting start message sent to the AAA server initiates accounting records for the session. When the user disconnects from a service, the SSG sends an accounting stop message to the AAA server. During the user session, the SSG periodically sends interim-update messages to update the time and volume used. The RADIUS accounting records record the service volume and session duration for billing purposes.

The CSG allows service providers to bill subscribers based on service content instead of time and volume used. The CSG records user traffic based on the URL entered by the end user. Web pages that are billed can be structured as previously described (see CSG Role).

The CSG sends the content-based call detail records to a billing mediation agent (BMA) over a GTP' interface. The BMA uses the subscriber's IP address to retrieve the MSISDN, which is required to properly identify and charge the subscriber for the content accessed.

High Availability Solutions

The CMX configuration handles any single point of failure by using redundant load-balancing platforms, redundant physical interfaces, and the Hot Standby Router Protocol (HSRP). Each routing element is connected to a standby element through a virtual LAN (VLAN) interface. The links between the RLB and multiple SSGs are maintained on a single VLAN using bridged virtual interfaces (BVIs) on the SSGs. This configuration uses the spanning tree protocol for quick recovery if an interface fails. This solution is based on the following:

Figure 3-15 illustrates the high-reliability solution for the CMX. The RLB1 and FWLB1 are configured to be active, and their peers, RLB2 and FWLB2, are in standby mode. If an active network element fails, the standby element becomes active. Also, both RLB1 and FWLB1 are configured to preempt their peers. For example, if RLB1 fails and RLB2 becomes active, RLB1 resumes activity when its failure condition clears.

The CSGs in the CMX framework are not configured for preemption. For example, if a failure occurs in CSG1, user traffic from the GGSN sequentially traverses RLB1, CSG2, back to RLB1, then to the SSGs. Even if the failure in CSG1 clears, user traffic continues to traverse the path through CSG2.


Figure 3-15   Failure Case Scenarios


The numbers shown in Figure 3-15 correspond to the failure scenarios listed below:

1. Failure of an SSG—When an SSG fails, user sessions supported by the SSG are lost. Incoming RADIUS requests for new user sessions are redirected to available SSGs. The RLB detects the SSG failure (using probes) and sends the user traffic to another SSG. The new SSG redirects users to the Web portal to authenticate them and restore user sessions. When the failed SSG restarts, it sends messages to the AAA server to stop accounting.


Note    The redundant CSGs in the RLB are used for backing up SSG-based prepaid billing records (if an SSG fails). The redundant CSGs in the FWLB provide content billing.

2. Failure of one RLB—HSRP runs between the two RLBs to maintain RADIUS load-balancing. When one RLB fails, the other RLB takes over the RADIUS load-balancing function.

3. Failure of the RLB-to-FWLB link—Messages are redirected via the links between the two RLBs to the peer FWLB. Spanning Tree Protocol is used to determine the alternate path.

4. Failure of an FWLB—HSRP runs between the FWLBs to maintain load-balancing of sticky objects between them. When one FWLB fails, the other FWLB takes over the load-balancing function.

5. Failure of the link between FWLBs—User traffic is redirected via the link between the RLBs.

6. Failure of a CSG—A fault-tolerance mechanism runs between the CSGs to maintain RLB sticky objects. When one CSG fails, the other CSG takes over.

7. Failure of an SSG link—The SSG supports redundant links to each RLB and FWLB. If one link fails, the other link is used.

8. Failure of the link to the services network—The FWLBs support redundant links to the services network. If one link fails, the other link is used.

9. Failure of the default network link—The RLBs support redundant links to the default network. If one link fails, the other link is used.

The configuration redundancies provided by bridged virtual interfaces (BVIs) in the SSG are illustrated in Figure 3-16. The SSG avoids any single point of failure by its connection to the two CMX VLANs. The failure of a physical interface or port adapter does not impact service.

As shown in Figure 3-16, the FE 0/0 and FE 1/0 ports are used to connect to the access VLAN, which interconnects the RLB for incoming RADIUS and user packets. The FE 0/1 and FE 1/1 ports are used to connect to the services VLAN, which interconnects the FWLB toward the services network. On each VLAN, the SSG is addressed with a single IP address; bridging is used between the interfaces and the IP addresses are configured on the BVIs.

The Spanning Tree Protocol (STP) is used to find a Layer 2 path between all the components when a physical interface fails. The RLB 1, which has the highest HSRP priority (active), is configured as the primary bridge root on the access and services VLANs. The RLB 2, which has the lowest HSRP priority (standby), is configured as the secondary bridge root on the access and services VLAN.


Figure 3-16   Example of Bridged Virtual Interfaces in SSG



hometocprevnextglossaryfeedbacksearchhelp
Posted: Tue Dec 31 04:25:59 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.