This chapter provides configuration guidelines for the Cisco Mobile Exchange (CMX).
For a complete description of the CMX commands in this chapter, refer to the Cisco IOS Mobile Wireless Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
The reference topology for the CMX configuration is shown in Figure 5-1 and Figure 5-2.
Figure 5-1 CMX Reference Topology (1 of 2)
The CMX topology is organized into several VLANs. The VLANs shown in Figure 5-1 include:
GGSN-to-MSFC1/2 VLANs 2 and 14—Connects the GGSN to 7609-1 and 7609-2 via redundant connection, using Open Shortest Path First (OSPF) protocol to exchange routing information and detect interface failure
MSFC1/2-to-CSG1/2 VLAN 17—Connects MSFC1/2 to CSG1/2, and interconnects MSFC1 and MSFC2 to run High Speed Router Protocol (HSRP)
CSG1-to-CSG2 VLAN 256—Used by the fault tolerance mechanism of the CSGs
CSG1/2-to-MSFC1/2 VLAN 16—Connects the CSG1/2 server to the MSFC1/2 (toward the RLB1/2 Vserver), and interconnects RLB1 and RLB2 for HSRP
MSFC1/2-to-SSGs VLAN 113—Connects the MSFC1/2 running RLB1/2 to all the SSGs, and used for HSRP between MSFC1 and MSFC2
The VLAN trunking protocol (VTP) is a Layer 2 messaging protocol that maintains the VLAN configuration by managing the addition, deletion, and renaming of VLANs within a VTP domain. A VTP domain (also known as a VLAN management domain) is made up of one or more network devices that share the same VTP domain name and are interconnected with trunks. The VTP minimizes misconfigurations and configuration inconsistencies such as duplicate VLAN names, incorrect VLAN-type specifications, and security violations.
Before you create VLANs, you must decide whether to use VTP in your network. With VTP, you can make configuration changes centrally on one or more network devices and have those changes automatically communicated to all the other network devices in the network.
VTP Configuration Guidelines and Restrictions
Follow these guidelines and restrictions when implementing VTP in your network:
All network devices in a VTP domain must run the same VTP version.
You must configure a password on each network device in the management domain when in secure mode.
Caution If you configure VTP in secure mode, the management domain does not function properly unless you assign a management domain password to each network device in the domain.
A VTP version 2-capable network device can operate in the same VTP domain as a network device running VTP version 1 only if VTP version 2 is disabled on the VTP version 2-capable network device (VTP version 2 is disabled by default).
Do not enable VTP version 2 on a network device unless all of the network devices in the same VTP domain are version 2-capable. When you enable VTP version 2 on a network device, all of the version 2-capable network devices in the domain enable VTP version 2.
In a token ring environment, you must enable VTP version 2 for token ring VLAN switching to function properly.
Enabling or disabling VTP pruning on a VTP server enables or disables VTP pruning for the entire management domain.
Configuring VLANs as pruning eligible or pruning ineligible on a Catalyst switch affects pruning eligibility for those VLANs on that switch only (not on all network devices in the VTP domain).
Configuring a VTP Password
To configure the VTP password parameters, use the following commands:
Command
Purpose
Router# vtp passwordpassword_string
Sets a password, which can be from 8 to 64 characters long, for the VTP domain
Router# no vtp password
Clears the password
Configuring the VTP Mode
To configure the VTP mode, use the following commands:
Command
Purpose
Router(config)# vtp mode {client | server |
transparent}
Configures the VTP mode
Note Use no vtp mode to revert to the default VTP mode (server).
Router(config)# vtp domaindomain_name
(Optional for server mode) Defines the VTP domain name, which can be up to 32 characters long. VTP server mode requires a domain name. If the switch has a trunk connection to a VTP domain, the switch learns the domain name from the VTP server in the domain.
Note You cannot clear the domain name.
Router(config)# end
Exits VLAN configuration mode
Router# show vtp status
Verifies the configuration
Note When VTP is disabled, you can enter VLAN configuration commands in configuration mode instead of
the VLAN database mode, and the VLAN configuration is stored in the startup configuration file.
This example shows how to configure the switch as a VTP server:
Router# configuration terminal
Router(config)# vtp mode transparent
Setting device to VTP TRANSPARENT mode.
Router(config)# vtp domain CMX
Setting VTP domain name to CMX
Router(config)# end
Router#
This example shows how to verify the configuration:
VLANs allow you to group LAN ports to limit unicast, multicast, and broadcast traffic flooding.
Note Before you create VLANs, you must decide whether to use VLAN Trunking Protocol (VTP) to maintain
global VLAN configuration information for your network. For complete information on VTP, see
"Configuring VLAN Trunking Protocol"
section.
Creating or Modifying an Ethernet VLAN
User-configured VLANs have unique IDs from 1 to 1001. Enter a VLAN command with an unused ID to create a VLAN. Enter a VLAN command for an existing VLAN to modify the VLAN. If you do not specify the VLAN type with the media keyword, the VLAN is an Ethernet VLAN.
To create a VLAN, use the following commands:
Command
Purpose
Router# configure terminal
Enters global configuration mode to allow you to configure the system from the terminal.
Router(config)# vlanvlan_ID
Adds an Ethernet VLAN.
Note Use the no vlan command to delete a VLAN. You cannot delete the default VLANs for the different media types: Ethernet VLAN 1 and FDDI or Token Ring VLANs 1002 to 1005. When you delete a VLAN, any LAN ports configured as access ports assigned to that VLAN become inactive. They remain associated with the VLAN (and inactive) until you assign them to a new VLAN.
Router(config-vlan)# end
Updates the VLAN database and returns to privileged EXEC mode.
Router# show vlan [id | name] vlan
Verifies the VLAN configuration.
This example shows how to create an Ethernet VLAN in global configuration mode and verify the configuration:
A VLAN created in a management domain is not used until you assign one or more LAN ports to it.
Note Make sure you assign LAN ports to a VLAN of the appropriate type. For CMX Release 1, you can assign
Fast Ethernet and Gigabit Ethernet ports.
To assign one or more LAN ports to a VLAN, use the following commands:
Command
Purpose
Router(config)# interfacetype slot/port
Selects the LAN port to configure1
Router(config-if)# shutdown
(Optional) Shuts down the interface to prevent traffic flow until configuration is complete
Router(config-if)# switchport
Configures the LAN port for Layer 2 switching.
Note You must enter the switchport command once without any keywords to configure the LAN port as a Layer 2 port before you can enter additional switchport commands with keywords. Use the no switchport command to clear Layer 2 LAN port configuration.
Router(config-if)# no shutdown
Activates the interface (required only if you previously shut down the interface)
Router(config-if)# end
Exits configuration mode
Router# show running-config interface [typeslot/port]
Displays the running configuration of the interface1
Router# show interfaces [typeslot/port] switchport
Displays the switch port configuration of the interface1
Router# show interfaces [typeslot/port] trunk
Displays the trunk configuration of the interface1
1type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet After you enter the switchport command, the default mode is switchport mode dynamic desirable. If the neighboring port supports trunking and is configured to allow trunking, the link becomes a Layer 2 trunk when you enter the switchport command. By default, LAN trunk ports negotiate encapsulation.
The code below represents an example of configuring a LAN port for Layer 2 switching:
To configure the default VLAN, use the following commands:
Command
Purpose
Router(config-if)# switchport access vlanvlan_num
(Optional) Configures the default VLAN, which is used if the interface stops trunking
Router(config-if)# no switchport access vlan
Reverts to the default value (VLAN 1)
The code below represents an example of configuring the default VLAN:
!
interface FastEthernet4/13
description SSG4 0/0 Host Side
no ip address
duplex full
speed 100
switchport
switchport access vlan 113
!
Configuring Port Channels
This feature allows multiple Fast Ethernet point-to-point links to be bundled into one logical link. You can configure the port-channel interface as you would do to any Fast Ethernet interface. After you create a port-channel interface, you assign Fast Ethernet interfaces (up to four) to it.
To configure port channel interfaces, use the following command:
The RADIUS Load Balancer (RLB) load-balances the traffic among the SSGs using the IOS RADIUS SLB feature. The IOS SLB feature is an IOS-based solution that provides IP server load balancing. Using the IOS SLB feature, you can define a virtual server that represents a group of real servers in a cluster of network servers known as a server farm. In this environment, the clients connect to the IP address of the virtual server. When a client initiates a connection to the virtual server, the IOS SLB function chooses a real server for the connection based on a configured load-balancing algorithm.
Observe the following guidelines when configuring the redundant RLBs in the CMX framework:
Use the correct Cisco IOS version for the RLB router (see Table 3-2)
To configure an IOS SLB server farm, you will specify a server farm name and assign real servers to the server farm. Use the following commands beginning in global configuration mode:
Command
Purpose
Router(config)# ip slb serverfarm serverfarm-name
Adds a server farm definition to the IOS SLB configuration and initiates server farm configuration mode.
Router(config-slb-sfarm)# nat {client pool | server}
Configures NAT client or server address translation mode on the server farm.
Configures the IOS SLB behavior when a real server fails.
The radius reassign option enables IOS SLB to automatically reassign to a new real server the RADIUS sticky objects that are destined for a failed real server.
Router(config-slb-sfarm)#probe probe
Associates a probe with the real server.
Router(config-slb-sfarm)# realip-addr [port]
Identifies a real server by IP address and optional port number as a member of a server farm and enters real server configuration mode.
Router(config-slb-real)# weightsetting
Specifies the real server's workload capacity relative to other servers in the server farm.
Router(config-slb-real)# reassign threshold
Specifies the threshold of consecutive unacknowledged synchronizations that, if exceeded, result in an attempted connection to a different real server.
Specifies the number of consecutive connection failures and, optionally, the number of unique client connection failures that constitute failure of the real server.
Router(config-slb-real)#maxclients number-conns
(Optional) Specifies the maximum number of entries in the IOS SLB RADIUS framed-IP sticky database that can be assigned to an individual real server.
Router(config-slb-real)# inservice
Enables the real server for use by IOS SLB.
The code below represents an example of configuring a server farm and a real server on the RLB:
!
ip slb serverfarm GPRS-SSGs
nat server
failaction radius reassign
probe PROBE1
!
real 10.113.0.16
weight 1
reassign 2
faildetect numconns 8 numclients 1
maxclients 10000
inservice
!
Configuring a Virtual Server
To configure the virtual servers on the RLB, use the following commands beginning in global configuration mode:
Command
Purpose
Router(config)# ip slb vserver virtual_server
Identifies a virtual server and initiates virtual server configuration mode.
Associates a real server farm with a virtual server and optionally configures a backup server farm and specifies that sticky connections are to be used in the backup server farm.
Specifies that connections from the same client use the same real server as long as the interval between client connections does not exceed the specified duration.
Prevents RLB from deleting information about sticky connections.
Note The GGSN can send accouting on and off messages when powered on or shut down. On receiving these messages, the RLB would delete information about sticky connections. This command purges these GGSN messages to preserve RLB sticky connections.
Configures a stateful backup of IOS SLB decision tables to a backup switch.
Router(config-slb-vserver)# inservice
Enables the virtual server for use by IOS SLB.
The code below represents an example of configuring a virtual server on the RLB:
!
ip slb vserver GPRS-RLB-ACCT
virtual 10.7.7.15 udp 1646 service radius
serverfarm GPRS-SSGs
sticky radius framed-ip group 1
idle radius framed-ip 3600
purge radius framed-ip acct on-off
access Vlan16 route framed-ip
replicate casa 10.113.0.22 10.113.0.23 33333
inservice standby rlb-csg
!
Configuring Probes
Configure probes to verify connectivity and to detect SSG failures. By default, no probes are configured in IOS SLB. To configure a probe, enter the following commands in order, beginning in global configuration mode:
Configures the IOS SLB probe name and changes to probe configuration submode.
Router(config-slb-probe)# address [ip-addr]
(Optional) Configures an IP address to which to send the probe.
Router(config-slb-probe)# intervalseconds
(Optional) Configures the probe transmit timers.
Router(config-slb-probe)# faildetectpings
Specifies the number of consecutive unacknowledged pings that constitute failure of the real server or firewall.
The code below represents an example of configuring a probe on the RLB:
!
ip slb probe PROBE1 ping
address 10.119.0.11
interval 15
faildetect 4
!
Enabling IOS SLB to Inspect Packets for RADIUS Framed-IP Sticky Routing
You can enable IOS SLB to inspect packets with source IP addresses that match a configured IP address and subnet mask. If the source IP address of an inspected packet matches an entry in the IOS SLB RADIUS framed-IP sticky database, IOS SLB uses that entry to route the packet; otherwise, IOS routes the packet.
To enable IOS SLB to inspect packets for routing using the RADIUS framed-IP sticky database, enter the following command in global configuration mode:
Command
Purpose
Router(config)# ip slb routeip-addr netmaskframed-ip
Enables IOS SLB to route packets using the RADIUS framed-IP sticky database.
The code below represents an example of configuring framed-IP sticky routing on the RLB:
!
ip slb route 192.168.0.0 255.0.0.0 framed-ip
!
SSG Configuration Guidelines
Prior to configuring the SSG, the SSG image must be installed on the router and the FastEthernet port IP addresses must be configured using the ip address ip-address network-mask command. To enable the SSG, use the ssgenable command in the global configuration mode.
The following tasks are presented in this section:
To configure security for SSG, use the following commands beginning in global configuration mode:
Command
Purpose
Router(config)# aaa new-model
Enables AAA
Router(config)# aaa authorization config-commands
Reestablishes the default created when the aaa authorization commandscommand was issued.
Router(config)# aaa authorization network default
group radius
Specifies that RADIUS is the default authorization used for all network-related requests.
Router(config)# ssg service-password password
Sets the password used to authenticate the SSG with the local AAA server service profiles. This value must match the value configured for the AAA server service profiles.
Router(config)# ssg radius-helper key key
Sets the RADIUS shared secret key between SSG and SESM.
The SESM, AAA server, CW4MW, BMA, and prepaid server reside in the default network. To assign the default network, use the following command in global configuration mode:
Sets the IP address or subnet that users are able to access without authentication. A mask provided with the IP address specifies the range of IP addresses that users can access without authentication.
The code below represents an example of configuring the default network on the SSG:
!
ssg default-network 10.13.0.0 255.255.255.0
!
Configuring the Access Network
Mobile wireless subscribers belong to the access network. To specify a downlink interface to the access network, use the following commands beginning in global configuration mode:
Specifies the downlink interface to the subscribers in the access network.
The code below represents an example of configuring the access network on the SSG:
!
ssg bind direction downlink BVI2
!
Configuring the Services Network
Network services, such as the pass-through service, are part of the services network. Configure one network for each service. The services networks are connected via the services VLAN. All interfaces connected to the services must be configured on the uplink interfaces. To configure the uplink interface (services network), use the following commands beginning in global configuration mode:
Specifies the uplink interface to the services network.
Note To verify the SSG interfaces configuration, use the show ssg direction command.
The code below represents an example of configuring the services network on the SSG:
!
ssg bind direction uplink BVI1
!
Enabling SSG User Profile Caching
Enabling SSG user profile caching allows the SSG to cache the user profiles of non-PPP users. User profiles of PPP and RADIUS proxy users are cached by the SSG by default. In situations in which the user profile is not available from other sources, SSG user profile caching makes the user profile available for RADIUS status queries and provides support for single sign-on functionality and failover from one SESM to another.
Note SSG user profile caching is required only when the SESM is used in RADIUS mode.
To enable SSG user-profile caching, use the following command in global configuration mode:
Command
Purpose
Router(config)# ssg profile-cache
Enables the caching of user profiles for non-PPP users.
Configuring the SSG to Support L2TP Service
The SSG can be configured to support L2TP service. With this configuration, when a subscriber selects a service through the SESM, the router serves as an L2TP access concentrator (LAC) and sends the PPP session through the service-specific L2TP tunnel. If the tunnel does not already exist, the LAC creates the proper tunnel to the LNS.
To configure the SSG to support L2TP, perform the following tasks:
Configure the SSG as a LAC
Configure RADIUS profiles for SSG support of L2TP
Configure the LNS (LNS is not part of CMX framework)
Configuring the SSG as a LAC
To configure the SSG as a LAC, use the following command in global configuration mode:
Command
Purpose
Router(config)# vpdn enable
Enables L2TP functionality.
Configuring RADIUS Profiles for SSG Support of L2TP
The following vendor-specific attributes (VSAs) are used by the SSG to support L2TP:
Cisco-AVpair VPDN
Account-Info VPDN
Service-Info VPDN
Cisco-AVpair VPDN Attributes
Table 5-1 lists the Cisco-AVpair attributes used in the service profile to configure VPDN.
Table 5-1 Cisco-AVpair VPDN Attributes
Attribute
Description
VPDN IP Address
Specifies the IP address of the home gateway (LNS) to receive the L2TP connections.
VPDN Tunnel ID
Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group.
L2TP Tunnel Password
Specifies the secret (password) used for L2TP tunnel authentication.
Account-Info VPDN Attributes
Table 5-2 lists the Account-Info attributes used in the user profile to subscribe the user to a VPDN.
Table 5-2 Account-Info VPDN Attributes
Attribute
Description
Auto Service
(Reply attribute) Subscribes the user to a service and automatically logs the user in to the service when the user accesses the SESM. Multiple instances of this attribute can occur within a single user profile. Use one attribute for each service to which the user is subscribed.
Service Name
Specifies the name of the tunnel that must match the tunnel ID specified in the LNS VPDN group.
Service-Info VPDN Attributes
Table 5-3 lists the Service-Info attributes used in the service profile to define the L2TP service parameter.
Specifies the PP maximum transmission unit (MTU) size for the SSG as a LAC. By default, the PPP MTU size is 1500 bytes.
Service Route
Specifies the networks available to the user for this service.
Configuring SSG Auto-logon Using Proxy RADIUS
To configure the SSG auto-logon using proxy RADIUS, use the following commands beginning in global configuration mode:
Command
Purpose
Router(config)# ip cef
Enables CEF.
Note SSG works with CEF switching technology to provide maximum Layer 3 switching performance. Because CEF is topology-driven rather than traffic-driven, its performance is unaffected by network size or dynamics.
Router(config)# ssg enable
Enables SSG functionality.
Router(config)# ssg radius-proxy
Enables SSG RADIUS proxy and enters SSG RADIUS proxy mode.
(Optional) Proxies accounting start/stop/update packets generated by any RADIUS clients to the AAA server.
The code below represents an example of configuring auto-logon using proxy RADIUS on the SSG:
!
ip cef
ssg enable
!
ssg radius-proxy
server-port auth 1645 acct 1646
client-address 5.5.5.33
key gociscogo
!
client-address 10.5.5.19
key gociscogo
!
forward accounting-start-stop
!
Enabling SSG TCP Redirect for Services
To configure the TCP redirect feature on the SSG, use the following commands beginning in global configuration mode:
Command
Purpose
Router(config)# ip cef
Enables CEF.
Note SSG works with CEF switching technology to provide maximum Layer 3 switching performance. Because CEF is topology-driven rather than traffic-driven, its performance is unaffected by network size or dynamics.
Creates a list of destination IP networks that can be redirected by the named captive portal group.
(Optional) destination network-list—Checks incoming packets from authenticated hosts to networks that they are not authorized to access to determine if they need redirection.
(Optional) network-listname—Name of the list of destination IP networks.
group-name—Name of the captive portal group.
Note If you do not specify a destination IP network by configuring the optional destination network-list keywords, the captive portal group specified in the group-name attribute is used as the default group for unauthorized service redirection when the IP address of the unauthorized packet does not fall into any network list associated with the captive portal group.
Router(config-ssg-redirect)# redirect smtp group
group-name [all | user]
Selects a captive portal group for redirection of SMTP traffic.
group-name—Name of the captive portal group.
(Optional) all—All SMTP packets are forwarded.
(Optional) user—SMTP packets from users that have SMTP forwarding permission are forwarded.
Note If you do not configure the optional all or user keywords, the default is all.
The code below represents an example of enabling TCP redirect on the SSG:
!
ssg tcp-redirect
server-group RedirectServer
server 10.13.0.13 8090
!
redirect unauthenticated-user to RedirectServer
!
Configuring the RADIUS Attributes for SSG TCP Redirect
Configure the RADIUS attributes in the user profiles on the AAA server. The user profile is downloaded from the AAA server as part of user authentication.
Table 5-4 lists vendor-specific attributes needed in the user profile to perform SSG TCP redirection.
Table 5-4 RADIUS Attributes for TCP Redirect
Feature Attribute ID
VendorID
SubAttrID
SubAttrName
SubAttrDataType
Account-Info Feature Code
26
9
250
Account-Info
String
R
Additional features allowed include the following:
"S"—User has SMTP forwarding capability.
"Igroup;duration[;service]"—User has initial captivation capability. This attribute also indicates the duration of the captivation in seconds. If you specify the optional service field, initial captivation starts only when the user activates the named service.
"Agroup;duration;frequency[;service]"—User has advertisement captivation capability. Specifies the captive portal group to use and the duration and approximate frequency of the captivation in seconds. If you add the optional service field, advertisement captivation starts only when the user activates the named service active.
Configuring SSG Prepaid Billing
To configure SSG to provide the prepaid billing server with session ID and time-stamp information, use the following commands in global configuration mode:
Sends RADIUS attribute 44 (accounting session ID) in access request packets before performing user authentication (including requests for preauthentication).
Configures an attribute in a local RADIUS service profile.
Note Only attributes that can appear in RADIUS Access-Accept packets can be configured using the attribute command.
Configuring an Open Garden
A Web portal presents subscribers with a menu of services that they can access using a Web browser. An open garden is a part of the Web portal that is free of charge to subscribers who have not been authenticated. Examples of free services in the open garden include checking the status of the user connection and obtaining the current balance for prepaid services.
To configure an open garden, use the following commands beginning in global configuration mode:
Command
Purpose
Router(config)# local-profile profilename
Creates a local service profile and enters profile configuration mode.
(DNS server address attribute) Specifies the DNS server for the service.
Note Enter this command twice to specify two DNS servers for DNS fault tolerance. SSG sends DNS requests to the first DNS server in its list. If the first server does not respond to the requests, SSG sends the requests to the second DNS server.
(Domain name attribute) Specifies the domain name that gets DNS resolution from the DNS server specified in Step 3. You can add multiple domain names to an open garden service.
Note This step is required only if the open garden is routed through a next-hop gateway. Routes to the open garden network must be added to the routing table.
The code below represents an example of configuring an open garden network on the SSG:
!
ssg bind service opengarden1 10.111.0.15
ssg bind service ssg-gprs-passthru-service1 10.111.0.15
ssg bind service ssg-cisco-passthrough-service1 10.111.0.15
ssg bind service ssg-gprs-walled-service1 10.111.0.15
ssg open-garden opengarden1
!
local-profile opengarden1
attribute 26 9 251 "R10.115.0.0;255.0.0.0"
!
SESM Configuration Guidelines
Prior to installing and configuring SESM, Solaris must be installed and configured with an IP address. To install and configure SESM, the following steps must be completed:
Step 1 Install the SESM.
Step 2 Configure the SESM with the SSG addresses (see note).
Note A typical SESM deployment consists of multiple SSGs. An SESM web application must know
which SSG is handling each subscriber request. Each request arriving at an SESM web
application contains a source IP address (also known as a client IP address). The SESM uses this
client IP address to determine which SSG should handle each request. You must configure the
associations between a subscriber request and its SSG.
Step 3 Configure captive portal, single sign-on, and port mapping.
The Firewall Load Balancer (FWLB) implements load balancing among the Service Selection Gateways (SSGs) similar to the load balancing in the RADIUS Load Balancer (RLB). See "RLB Configuration Guidelines" section. The FWLB uses the IOS server load balancing (SLB) feature to balance traffic flows to the SSGs. The SLB feature is used in the FWLB to ensure that traffic flows to the same SSG in the downlink direction that was used in the uplink direction.
To configure the FWLB for the CMX, use the following commands:
Command
Purpose
Router(config)# ip slb probenameping
Places the user in ping probe configuration submode; the name string identifies the probe instance; maximum 15 characters long
Router(config-slb-probe)# addressip-address
In ping probe submode, ip-address is the destination intended to respond to the ping
Note If this probe is associated with a server farm, and the address is not specified, the address is inherited from the server farm real servers. If this probe is associated with a firewall farm, the address must be specified.
Router(config-slb-probe)# intervalseconds
(Optional) Configures the probe transmit timers
Router(config)# ip slb firewallfarmname
Places the user in firewall configuration submode
Router(config-slb-sfarm)#probename
(Optional) Associates a probe with the real server
Router(config-slb-sfarm)# realip-address
Identifies a real server by IP address as a member of a server farm and enters real firewall configuration submode
Router(config-slb-real)# faildetectnumber
Configures the number of consecutive unanswered pings before failing the real server
(Optional) Specifies the maximum number of active connections allowed on the real server at one time
Router(config-slb-real)# inservice
Enables the real server for use by IOS SLB
stickyduration
(Optional) Specifies that connections from the same client use the same real server as long as the interval between client connections does not exceed the specified duration
idleduration
(Optional) Specifies the minimum amount of time IOS SLB maintains connection context in the absence of packet activity
The code below represents an example of configuring the default VLAN:
!
ip slb probe PING-PROBE1 ping
address 10.111.0.16
interval 600
!
!
ip slb firewallfarm FIRE
inservice standby fwlb-ssg
!
real 10.111.0.16
probe PING-PROBE1
inservice
!
!
real 10.111.0.26
probe PING-PROBE4
inservice
protocol tcp
sticky 60 destination
protocol datagram
sticky 60 destination
replicate casa 10.111.0.17 10.111.0.18 22222
CSG Configuration Guidelines
The CMX framework uses the Content Services Gateway (CSG) in two locations to provide two distinct functions. In the uplink direction, it assumes a position before the RADIUS Load Balancer (RLB) and the Service Selection Gateways (SSGs). This CSG provides reference data as a backup to the IP billing in the SSG (in case the SSG fails). A second CSG is positioned after the SSGs and the Firewall Load Balancer (FWLB) in the uplink direction. This CSG is positioned to provide content-based billing. Each of these CSGs has a redundant standby. In the reference topology shown in Figure 5-1, CSG pair 1 and 2 provide the billing backup for the SSGs. The CSG pair 3 and 4 provide the content billing function (shown in Figure 5-2).
The configuration guidelines for the Content Services Gateway (CSG) include the following categories:
User groups
Accounting policies
Client/server connectivity
CSG location and interface association
Client-side VLAN
Server-side VLAN
Server farms
Policies
Filters
Billing traffic (virtual servers)
Fault tolerant group
For complete configuration details, use the guidelines provided in the Content Services Gateway Installation and Configuration Guide. This guide is available at the following URL:
To configure the CSG to record and generate accounting records, you must specify the user group(s) for which you want to generate accounting records. You also specify the user database that the CSG queries for user IDs.
To configure user groups on the CSG, and to specify the user database and RADIUS endpoint, use the following commands:
Command
Purpose
Router# ip csg user-group group-name
Creates a group of end users that you want to generate accounting records for.
Router(config-csg-group)# database ip address port number
Specifies the location of the user database, including its IP address and port number.
Router(config-csg-group)# radius key secret
Specifies and configures the CSG to be the RADIUS endpoint for accounting records and provides the key.
Router(config-csg-group)# radius acct-port port
Specifies the port number for the RADIUS accounting endpoint.
This example shows how to configure a CSG user group, database, and RADIUS endpoint:
ip csg user-group U1
database 10.10.10.10 6666
radius key secret
radius acct-port 7777
Configuring and Activating Accounting Policies
To configure the CSG to record and generate accounting records, you need to define content-based client accounting as a service. This includes specifying the user group(s) you want to generate accounting records for, as well as the Billing Mediation Agent (BMA) to send accounting records to.
To configure the accounting policies on the CSG, use the following commands:
Command
Purpose
Router# ip csg accounting name
Defines content-based client accounting as a policy.
Router(config-csg-acct)# user-group name
Associates a user group with a specific accounting service.
Router(config-csg-acct)# agent ip_address port number priority
Specifies the primary or backup billing mediation agent to send accounting records to (including IP address, port numbe, and priority).
Router(config-csg-acct)# inservice
Activates the accounting service on a CSG.
Router(config)# module ContentSwitcingModule number
Specifies the CSG location on the router/switch.
Router(config-module-csm)# csgaccountingname
Activates the accounting policy on the CSG.
This example shows how to define the CSG accounting policy:
!
ip csg accounting GGSN-BMA
user-group MN-ID
agent 172.18.41.70 3333 1
agent 172.18.41.70 4444 2
inservice
!
module ContentSwitchingModule 3
csg accounting GGSN-BMA
Configuring Client-side VLAN
To configure client-side VLANs, use the following commands:
Caution You cannot use VLAN 1 as a client-side or server-side VLAN for the CSG.
Command
Purpose
Router(config-module-csm)# vlan vlanidclient
Configures the client-side VLANs and enters the client VLAN mode1.
Router(config-slb-vlan-client)# ip ip-address netmask
Configures an IP address to the CSG. This address is used by probes and ARP requests on this particular VLAN2.
Configures a static route to reach the real servers if they are more than one Layer 3 hop away from the CSG.
1Enter the exit command to leave a mode or submode. Enter the end command to return to the menu's top level.
2The no form of this command restores the defaults.
This example shows how to configure the CSG for server-side VLANs:
!
vlan 16 server
ip address 10.16.16.29 255.255.255.0
route 0.0.0.0 0.0.0.0 gateway 10.16.16.15
!
Configuring Server Farms
A server farm or server pool is a collection of servers that contain the same content. You specify the server farm name when you configure the server farm and when you bind the server farm to a virtual server.
To use the CSG billing feature, you must specify a server farm and associate it with any policies that you create. The server farm associated with a policy receives all the requests that match that policy.
To configure server farms on the CSG, use the following commands:
Creates and names a server farm and enters the server farm configuration mode12.
Router(config-slb-sfarm)# predictorforward
Configures the load-balancing prediction algorithm2.
Note Be sure to specify forward.
Router(config-slb-real)# inservice
Enables the server farm.
1Enter the exit command to leave a mode or submode. Enter the end command to return to the menu's top level.
2The no form of this command restores the defaults.
This example shows how to configure a server farm for the CSG. This serverfarm, named RLB, uses the predictor forward algorithm, and has no NAT or client servers.
!
serverfarm RLB
no nat server
no nat client
predictor forward
!
Note Configure the CSG server farm without a real server. Configure no NAT server, no NAT client, and set
the predictor forward.
Configuring Policies and Filters
Policies are access rules that traffic must match for a server farm. Policies allow the CSG to apply filters to certain types of traffic subject to the accounting service.
Note You must associate a server farm with a policy. A policy that does not have an associated server farm
cannot forward traffic. The server farm associated with a policy receives all the requests that match
that policy.
When the CSG is able to match policies, it selects the policy that appears first in the policy list. Policies are located in the policy list in the sequence in which they were bound to the virtual server. You can reorder the policies in the list by removing policies and reentering them in the correct order.
To configure accounting records policies and filters, use the following commands:
Command
Purpose
Router(config-module-csm)# policy policy-name
Creates the policy and enters the policy submode to configure the policy attributes1.
Router(config-slb-policy)# url-map name
Specifies a URL map for the policy.
Router(config-slb-policy)# serverfarm name
Specifies a server farm for the policy.
Router(config-slb-policy)# csg filter service name type <http | other>string ASCII string
Specifies which type of accounting records should be generated, as well as the string to include in the accounting records.
1Enter the exit command to leave a mode or submode. Enter the end command to return to the menu's top level.
The following example illustrates how to configure policies and filters on the CSG:
Virtual servers (Vservers) represent groups of real servers and are associated with real server farms through policies. The CSG uses Vservers to specify destinations for billing records.
Configuring virtual servers requires that you set the attributes of the virtual server specifying the default server farm (default policy) and that you associate other server farms through a list of policies. The default server farm (default policy) is used if a request does not match any CSG filter policy or if there are no policies associated with the virtual server.
Before you can associate a server farm with the virtual server, you must configure the server farm. Policies are processed in the order in which they are entered in the virtual server configuration.
Note Although all IP protocols have a protocol number, the CSG allows you to specify TCP or UDP by
name instead of requiring you to enter their numbers.
To configure virtual servers, use the following commands:
Sets the IP address for the virtual server optional port number or name and the connection coupling and type2. The protocol value is tcp, udp, any (no port-number is required), or a number value (no port-number is required).
Associates the default server farm with the virtual server23. Only one server farm is allowed. If the server farm is not specified, all the requests not matching any other policies will be discarded.
Configures CSRP replication for connection redundancy on the CSGs.
Router(config-slb-vserver)# persistent rebalance
Enables HTTP 1.1 persistence for connections in the virtual server. When a client connection fails during a transaction, the connection is rebalanced(using the load-balancing policy)to a new server in the server farm.
Router(config-slb-vserver)# slb-policy policy name
(Optional) Associates a filter policy with a virtual server2.
This example shows how to configure virtual servers on the CSG:
!
vserver LNSINT
virtual 10.103.0.0 255.0.0.0 any
serverfarm RLB
replicate csrp connection
persistent rebalance
slb-policy IP
inservice
!
Configuring Fault Tolerant Group
This section describes a fault-tolerant configuration. In this configuration, two separate Catalyst 7600 devices each contain a CSG.
The client-side and server-side VLANs provide the fault-tolerant (redundant) connection paths between the CSG and routers on the client side and the servers on the server side. In a redundant configuration, two CSGs perform active and standby roles. Each CSG contains the same IP address, virtual server, and server farm. From the client-side and server-side networks, each CSG is configured identically. The network sees the fault-tolerant configuration as a single CSG.
Note When you configure multiple fault-tolerant CSG pairs, do not configure multiple CSG pairs to use
the same FT VLAN. Use a different FT VLAN for each fault-tolerant CSG pair.
To configure a CSG for fault tolerance, use the following commands:
Command
Purpose
Router(config-module-csm)# ft groupft-group-numbervlan vlanid
Assigns a VLAN to a fault tolerant group.
Router(config-module-csm)# priority level
Assigns a priority level to the CSG in a fault-tolerant pair of CSGs. The CSG with the highest priority level is the primary CSG.
Router(config-module-csm)# heartbeat-time time
Specifies number of seconds between heartbeat transmissions.
Router(config-module-csm)# failover value
Specifies number of seconds (default of 3) the CSG waits before assuming the mate CSG is not operational.
Router(config-module-csm)# show module csm csm-number ft
Displays statistics and counters for the CSG fault-tolerant pair.
This example shows how to configure fault tolerance on the CSG:
!
ft group 1 vlan 256
priority 20
!
ft group 2 vlan 257
priority 20
!
Refer to the Content Services Gateway Installation and Configuration Guide for a detailed description of fault tolerant configurations. This guide is available at the following URL:
