3 Gx Interface Support Introduction

3 Gx Interface Support Introduction
CH A P T E R
3
Gx Interface Support
Published: December 23, 2013
Introduction
The Gx interface may be used for two purposes:
1.
Setting the subscriber tunables (for example, package ID) and setting the subscriber RADIUS VSA
attributes, which are used by the Gy interface.
The subscriber parameters may be updated either by SCE or by PCRF triggering. SCE-initiated
updates are mostly generated by login events, which result in sending CCR Initial/Update messages
to the PCRF. PCRF can initiate an update by sending a RAR message to the SCE.
2.
New subscriber integration method, where PCRF is responsible for coupling IP to the subscriber
name in the SCE.
Gx subscriber integration is used by setting Gx as anonymous-group manager (similar to SM pull
mode).
Number of Subscriber IP Addresses Supported
The SCE supports a single IP address per subscriber when the Gx interface is used.
Gx Subscriber Properties and AVPs
The PCRF provides the Cisco SCE with the properties related to both Cisco SCA BB, and RADIUS
VSA.
The properties that are related to the Cisco SCA BB and are provided by the PCRF to the Cisco SCE are:
•
Package-id
•
Real-time monitor
•
Up virtual link
•
Down virtual link
These properties are provided in the VSAs described in Table 3-1.
Cisco Service Control Mobile Solution Guide
OL-30600-01
3-1
Chapter 3
Gx Interface Support
Gx Subscriber Properties and AVPs
Vendor-Specific AVPs
Table 3-1 describes the vendor-specific Diameter AVPs defined for the Gx reference point. The
Vendor-ID header of all the AVPs defined in this section is set to Cisco.
Table 3-1
Vendor-Specific AVPs
AVP Name
AVP Value
Code Type
AVP Flag Rules
Must
Must May Not
Note
Should
Not
May Acc.
Encr. Type
Cisco-SCA BB-Package-Install
1000 Uint32 V
P
M
Y
All
Cisco-SCA BB-Real-time-monitor-Install
1001 Uint32 V
P
M
Y
All
Cisco-SCA BB-Vlink-Upstream-Install
1002 Uint32 V
P
M
Y
All
Cisco-SCA BB-Vlink-Downstream-Install 1003 Uint32 V
P
M
Y
All
The AVP header bit denoted as “M,” indicates whether support of the AVP is required. The AVP header
bit denoted as “V,” indicates whether the optional Vendor-ID field is present in the AVP header. For
further details, see RFC 3588.
Cisco-SCA BB-Package-Install
•
AVP code—1000
•
Value type—Uint32
•
Used to activate the SCE package as instructed by the PCRF. Defines the policy that will be assigned
to the subscriber.
•
Can be used either to install or to update the package ID to a subscriber.
Cisco-SCA BB-Real-time-monitor-Install AVP
•
AVP code—1001
•
Value type—Uint32
•
Defines the SCE real-time monitor rule sent by the PCRF to the SCE. Activates and deactivates
real-time monitoring for the subscriber.
– Activate by sending a 1.
– Deactivate by sending a 0.
– Other values fail and are treated as error.
Cisco-SCA BB-Vlink-Upstream-Install AVP
•
AVP—1002
•
Value type—Uint32
•
Defines the virtual link upstream rule sent by the PCRF to the SCE. Defines the upstream virtual
link that the subscriber is assigned to. The virtual link is used to manage a group of subscribers that
share a resource.
•
Can be used either to install or update the virtual link upstream to a subscriber.
Cisco Service Control Mobile Solution Guide
3-2
OL-30600-01
Chapter 3
Gx Interface Support
Gx Subscriber Properties and AVPs
Cisco-SCA BB-Vlink-Downstream-Install AVP
•
AVP—1003
•
Value type—Uint32
•
Defines the virtual link downstream rule sent by the PCRF to the SCE. Defines the downstream
virtual link that the subscriber is assigned to.The virtual link is used to manage a group of
subscribers sharing a resource.
•
Can be used either to install or update virtual link downstream to a subscriber.
Gx Reused AVPs
Table 3-2 lists the Diameter AVPs reused by the Gx reference point from the existing Diameter
applications. Other AVPs from the existing Diameter applications, except for the AVPs from the
Diameter base protocol, do not need to be supported. The AVPs from the Diameter base protocol are not
included in Table 3-2, but they are reused by the Gx reference point.
Where 3GPP RADIUS VSAs are reused, they are translated to Diameter AVPs, with the exception that
the “M” flag is set and the “P” flag may be set.
Table 3-2
Note
Gx Reused Diameter AVPs
Attribute Name
Description
Acc. Type
CC-Request-Number
Number of the request for mapping requests and answers.
All
CC-Request-Type
Type of the request (initial, update, termination).
All
Framed-IP-Address
IP version 4 (IPv4) address allocated to the subscriber.
All
Subscription-ID
Subscriber ID as defined in the PCRF, USER_E164.
All
See Appendix B, “Supported VSAs” for a complete list of supported VSAs.
Cisco Service Control Mobile Solution Guide
OL-30600-01
3-3
Chapter 3
Gx Interface Support
Gx Session
Gx Session
The Gx session is the basic Gx entity and it is uniquely describes a subscriber and single IP mapping.
The session is identified by a unique string (called session-id) and it is created both on the server and the
SCE. Each Gx message must include the session-id AVP, which identifies the session that the message
refers to.
Session Creation
The Gx session creation is initiated by the Cisco SCE. Session creation includes the exchange of Credit
Control Request (CCR) and Credit Control Answer (CCA) messages. The Cisco SCE sends a CCR Initial
message to the PCRF and the PCRF answers with a CCA message.
In the CCR Initial, the SCE sends the subscriber IP and subscriber name (if no Gx integration is used).
The PCRF replies with a CCA Initial message, which includes a subset of the subscriber parameters.
After the SCE receives a successful CCA Initial message (including a result AVP with success), the
session is successfully opened. If the PCRF CCA Initial message includes error codes, the session is not
created, and the Cisco SCE will attempt to reopen it later. However, the subscriber will be assigned to
the anonymous group until the Cisco SCE receives a successful CCA initial message. For more details
on the error handling of the CCA initial message, see the “Error Handling” section on page A-8.
Session Lifetime
During the lifetime of a Gx session, the following messages can be sent:
•
CCR Update: Similar to CCR Initial, except that the session is already opened. The SCE asks the
PCRF for updates on the parameters.
•
RAR: Message sent from the PCRF to the SCE to update subscriber parameters. In this case, an
external event causes the PCRF to update the subscriber parameters and send the updates to the SCE.
Session End
A session may be ended in either of two ways:
•
The SCE may terminate the session by sending a CCR Terminate message. The CCR Terminate
message is triggered by logout of the subscriber, either explicit (for example, SM logout) or implicit
(by aging).
•
PCRF may terminate the session by sending an Abort Session Request (ASR) message. The ASR
message is intended to be used in Gx subscriber integration mode where an external event (for
example, user disconnecting the mobile modem Internet connection) triggers the PCRF to close the
session. The ASR terminates the session in both modes (Gx subscriber integration and other external
integration methods). However, in Gx integration, the ASR also triggers a logout of the subscriber
from the SCE.
Gx Session Life Cycle
The Gx session life cycle varies based on the whether or not the subscriber integration is external (set as
none) or internal. The following sections describe the Gx session life cycles.
Cisco Service Control Mobile Solution Guide
3-4
OL-30600-01
Chapter 3
Gx Interface Support
Gx Session
Gx Subscriber Integration (None)
In an external subscriber integration method such as SM, the Gx session is created when the subscriber
logs in. The subscriber is logged in to the SCE by the external API (for example, SM). When the login
process is complete, the SCE tries to open a Gx session for the subscriber and the IP tuple. After the
session is created, (the PCRF responded with a successful CCA Initial), the subscriber parameters are
extracted from the CCA message and updated. As described earlier, the PCRF may send a RAR message
to the SCE during the life time of the session. CCR Updates may be sent to the PCRF as a result of the
external API, such as SM sync.
The Gx session is terminated when the external API in use logs the subscriber out. The session can be
terminated by sending an ASR message from the PCRF, although this does not trigger subscriber logout.
Figure 3-1 shows a typical flow of session messages. The flow starts when a subscriber is logged into
the SCE, triggering a CCR and CCA message exchange. The session ends with user explicit logout,
which terminates the session.
Figure 3-1
Gx Subscriber Integration (None) Flow
PCRF
SCE
End User
User Logon
CCR (Initial, Sub-Id, IP)
CCA (Policy, Radius VSA,...)
PCRF Update
RAR (Sub-Id, Policy,...)
RAA
User Logout
CCR (Terminated, Sub-Id)
276734
CCA
Cisco Service Control Mobile Solution Guide
OL-30600-01
3-5
Chapter 3
Gx Interface Support
Gx Session
Gx Subscriber Integration
The Gx session life cycle is slightly different when Gx is the subscriber integration method. The Cisco
SCE starts the Gx session upon identifying an anonymous IP that belongs to the Gx anonymous-group
(similar to SM pull, where a pull notification is created). However, the Cisco SCE does not know the
subscriber name, and therefore it is not sent as part of the CCR Initial message. The PCRF responds with
a CCA Initial message that includes the subscriber name. The Cisco SCE logs in the subscriber, and
sends the IP mapping to the Cisco SCE, together with the subscriber parameters. The Gx session may
terminate in two ways, by aging, which generates subscriber logout, or by CCR Terminate, with the
PCRF ending the session by sending an ASR. In the second scenario, the ASR also logs out the
subscriber from the Cisco SCE because the Gx is the subscriber owner. See Figure 3-2.
Figure 3-2
End User
Gx Anonymous-Group Flow
Traffic of an unknown IP
traverses the SCE.
SCE
PCRF
CCR (Initial, IP)
CCA (Sub Id, Policy, Radius VSA)
PCRF Update
RAR (Sud-Id, Policy, Other)
RAA
User Logout – PCRF is updated via management IF
ASA
277076
ASR
Whether the session is terminated by aging or by CCR Terminate, the PCRF may send a RAR in order
to update the subscriber parameters.
Note
Using Gx, the SCE supports single IP mapping per subscriber.
Cisco Service Control Mobile Solution Guide
3-6
OL-30600-01
Chapter 3
Gx Interface Support
Configuring Gx Support
Configuring Gx Support
This section contains the information and instructions to configure and monitor the Gx support
configuration.
Gx Interface CLI Commands
Table 3-3 lists the CLI commands used to configure and monitor the Gx interface.
Table 3-3
Gx Interface CLI Commands
CLI Command
Command Description
[no] diameter Gx
Start and stop Gx.
show diameter Gx
Show Gx state and connected peers.
show diameter Gx counters
Show Gx messages statistics.
clear diameter Gx counters
Reset Gx statistics.
diameter Gx tx-timer <timeout-in-seconds>
Set the time-out on messages. If the PCRF does
not respond to a Gx message in the configured
tx-timer seconds, the message is considered timed
out. The message is dumped if it arrives after
tx-timer expires.
diameter Gx PCRF-connection-failure-grace-time Set the Gx failover grace period. Failover
<time>
functions as follows:
•
If a connection fails and is reestablished
within the failover grace period, no failover
action is taken.
•
If a connection fails and is not reestablished
within the failover grace period, failover
action is taken.
•
If a server fails, all its sessions remain open
for the failover grace period. After the failover
grace period expires, all the server sessions
are closed and reopened on a secondary
server.
•
If a server fails on a system using
session-sharing, no failover action is taken.
diameter Gx fatal-grace-time <time>
Set the Gx detection timeout. If no connection to
any server is detected for the configured length of
time, all the diameter sessions are closed and a
new connection is established.
[no]subscriber Gx-pull-request-disable
Stops the SCE from sending the subscriber pull
request to the PCRF server.
Cisco Service Control Mobile Solution Guide
OL-30600-01
3-7
Chapter 3
Gx Interface Support
Configuring the Maximum Gx Login Rate
Example for displaying the Gx configuration:
SCE8000> show diameter gx
Gx Application Status
Gx Realm
Gx tx-timer
Gx PCRF-connection-failure-grace-time
Gx fatal-grace-time
Connected
:
:
:
:
:
Up
scos.com
5
150
300
Example for enabling, disabling, and viewing the Gx pull request status:
SCE8000#> show interface LineCard 0 subscriber Gx-pull-request-disable
Gx-pull-request is enabled
SCE8000#> config
SCE8000(config)#> interface LineCard 0
SCE8000(config if)#> subscriber Gx-pull-request-disable
SCE8000(config if)#> show interface LineCard 0 subscriber Gx-pull-request-disable
Gx-pull-request is disabled
SCE8000(config if)#> no subscriber Gx-pull-request-disable
SCE8000(config if)#> show interface LineCard 0 subscriber Gx-pull-request-disable
Gx-pull-request is enabled
SCE8000(config if)#>
Configuring the Maximum Gx Login Rate
Starting from Cisco SCE Release 4.0.0, you can configure the maximum Gx login rate using the diameter
Gx login-rate command. This featue is applicable only when subscribers are introduced through Gx.
How to Configure the Maximum Gx Login Rate
From the SCE(config)#> prompt, type:
Table 3-4
Configuring the Maximum Gx Login Rate
Command
Purpose
diameter Gx login-rate
Configures the maximum Gx login rate.
default diameter Gx login-rate
Reverts the configuration to the default maximum
Gx login-rate of 360.
The maximum diameter login-rate when Gy is
enabled is 200.
If Gx and Gy is enabled, the default maximum
diameter login-rate is 200.
show diameter Gx login-rate
Displays the diameter Gx login-rate.
Configuring the Default Subscription ID Type in Gx
You can configure any of the following subscription ID types as the default subscription ID type by using
the party default-type command:
•
END_USER_E164
Cisco Service Control Mobile Solution Guide
3-8
OL-30600-01
Chapter 3
Gx Interface Support
Setting the Proxy Bit Flag for Gx and Gy Separately
•
END_USER_IMSI
•
END_USER_NAI
•
END_USER_SIP-URI
•
END_USER_PRIVATE
If the default subscription ID type is configured, the Cisco SCE sends the configured subscription ID
type to the Policy and Charging Rules Function (PCRF) in the Credit Control Request (CCR) messages.
The factory default subscription ID type is END_USER_E164.
How to Configure the Default Subscription ID type
From the SCE(config)#> prompt, type:
Table 3-5
Configuring the Default Subscription ID type
Command
Purpose
party default-type {e164 | imsi | nai | sip-uri}
Configures the default subscription type.
Setting the Proxy Bit Flag for Gx and Gy Separately
You can enable peer proxy agent (set the proxy bit flag as true) for Gx and Gy separately using the
diameter Gx peer-proxyagent and diameter Gy peer-proxyagent commands respectively.
When the proxy bit flag is set to true, the corresponding proxy bit is enabled on the CCR messages
generated by the Cisco SCE and the Credit Control Answer (CCA) messages generated by the PCRF.
Further, the proxy bit is enabled on Abort Session Request (ASR) messages, Abort Session Answer
(ASA) messages, Reauthorize Request (RAR) messages, and Reauthorization Answer (RAA) messages.
How to Enable Peer Proxy Agent for Gx and Gy
From the SCE(config)#> prompt, type:
Table 3-6
Enabling Peer Proxy Agent for Gx and Gy
Command
Purpose
diameter Gx peer-proxyagent
Enables the peer proxy agent for Gx.
diameter Gy peer-proxyagent
Enables the peer proxy agent for Gy.
High Availability for the Gx Interface
Two parameters define the High Availability (HA) behavior:
•
Session shared—Defines whether the session needs to reopen upon failover. When a shared session
is defined, it is assumed that each session is common to all the servers (for example, through a
common database).
•
Stickiness—Defines whether the session needs to move back to the original server when it restarts.
Cisco Service Control Mobile Solution Guide
OL-30600-01
3-9
Chapter 3
Gx Interface Support
High Availability for the Gx Interface
A server is in failure mode if the underlying diameter connection fails and cannot recover for the
configurable grace time. Fatal mode is when all the servers are in failure mode and no connections to
PCRF exist.
Session not Shared with Stickiness
When the primary server fails, all the sessions managed by that server are migrated to the next server in
a controlled manner (limited by the maximum rate allowed).
If the Gx session manages the subscriber, the subscriber is logged out. On the next traffic generating
event, the subscriber logs in on a different server. If any other method manages the subscriber, only the
Gx session is closed and the session reopens on the secondary server.
Eventually, all the subscribers relog and migrate to the secondary server. After the primary server is up,
new sessions are forwarded to it. The migrated sessions on the secondary server continue on the
secondary server until logout or failure.
In this scheme, a server failure causes a long convergence time.
In fatal mode, all the Gx-managed subscribers are logged out and all the other subscribers remain with
their last configuration. When the connection resumes, the SCE reopens all the non-Gx-managed
sessions and the Gx-managed sessions are triggered by traffic.
Example:
Servers A, B, and C with priority 100, 99, and 98, respectively.
1.
After ten Gx sessions, all the servers are up and all the sessions are opened on server A. Servers B
and C do not handle any sessions.
2.
Servers A and B fail. The ten sessions are closed and are reopened on server C.
3.
Server B is up. Server C continues to handle all its sessions, new sessions open on server B.
4.
After nine more new Gx sessions, server A comes back up. Server A handles no sessions, server B
handles nine sessions, and server C handles ten sessions.
Session Shared with Stickiness
In this scheme, the servers share the session. When the primary server is down, all the existing sessions
are handled by the secondary server. No relogin is required.
When the primary server is up again, all the new sessions are handled by it, while old sessions that were
moved to the secondary server remain on the secondary server until logout.
Fatal mode works in the same way as in a session not shared with stickiness.
Example:
Servers A, B, and C with priority 100, 99, and 98, respectively.
1.
After 10 Gx sessions, all the servers are up and all the sessions are opened on server A. Servers B
and C do not handle any sessions.
2.
Servers A and B fail. The 10 sessions are handled by server C without being closed (no action is
taken). When a message needs to be sent, it is sent to server C, and remains with server C until the
session is closed.
Cisco Service Control Mobile Solution Guide
3-10
OL-30600-01
Chapter 3
Gx Interface Support
Mapping of VLAN ID to Virtual Gi ID
3.
Server B is up. Again no action is taken, all the messages related to the new sessions are sent to
server B. Any messages related to the sessions handled by server C (Step 2) remain with server C.
4.
After nine more new Gx sessions, server A comes back up. If a message was generated in Step 2 or
3 for a session, it remains with server B or server C, respectively. All the other messages are sent to
server A.
Session Shared Without Stickiness
Same as the session shared with stickiness with the exception that when the primary server recovers, all
the sessions are re-forwarded to it.
Fatal mode works in the same way as in a session shared with stickiness.
Example:
Servers A, B, and C with priority 100, 99, and 98, respectively.
1.
After 10 Gx sessions, all servers are up, and all the sessions are opened on server A. Servers B and
C do not handle any sessions.
2.
Servers A and B fail. The 10 sessions are handled by server C without being closed (no action is
taken). When a message needs to be sent, it is sent to server C.
3.
Server B is up. No action is taken, all the messages are sent to server B.
4.
After nine more new Gx sessions, server A comes back up. No action is taken, all the messages are
forwarded to server A.
Load Balancing with Default High Availability
Load balancing is always done by round robin per available servers. Round robin is done per session and
not per message, that is, all the messages for a specific session are sent to the same server.
When a server fails, it is removed from the round robin.
If a server is removed from the load balancing setup, sessions that are already initiated with that server
will be closed. These sessions reopen on a new server and remain open with that server.
Mapping of VLAN ID to Virtual Gi ID
The mapping of VLAN ID to virtual Gi ID feature enables Cisco SCE to map the VLAN ID retrieved
from the subscriber traffic to a virtual Gi ID, thereby, allowing the Policy Charging and Rules Function
(PCRF) server to fetch the policy corresponding to the virtual GI ID and IP address, and send it to Cisco
SCE. The physical VLAN ID received from the subscriber side traffic is in the range of 1-4094. This
range (1-4094) is mapped to a static virtual ID that is of the range 1-255, and is used by the PCRF server
to fetch the policy.
The mapped virtual ID is sent to the PCRF server as part of the CCR-I request. The corresponding policy
is sent back to the Cisco SCE as part of the CCA answer.
Cisco Service Control Mobile Solution Guide
OL-30600-01
3-11
Chapter 3
Gx Interface Support
Mapping of VLAN ID to Virtual Gi ID
Mapping of VLAN ID to Virtual ID
User Logon
Mobile
Users
User Logout
CCR-I (VGI-ID)
361763
Figure 3-3
CCA (Policy)
SCE
PCRF
Gi AVP
Table 3-7 defines the Gi AVP that carries the mapped Virtual Gi ID as part of a CCR-I request:
Table 3-7
Gi Interface AVP
AVP Name
AVP Code
Value Type
Used In
TMO-Virtual-Gi-ID
120
Uint32
CCR-I
Subscriber-ID
CCA
RAR
RAA
O (optional) —
—
—
443
—
—
—
—
—
Subscription-ID-Type 450
—
—
—
—
—
Subscription-ID-Data
—
—
—
—
—
444
The optional flag (O) is set for TMO-Virtual-Gi-ID and is used in CCR-I. The value type (unsigned
integer 32) carries the value of the mapped virtual-ID.
Configuring VLAN ID Mapping to Virtual Gi ID
This section contains the information and instructions to configure and monitor the feature.
Following are the steps for configuring the mapping of VLAN ID to a virtual Gi interface ID:
Step 1
1.
Configure the VLAN ID mapping to a virtual Gi ID.
2.
Configure the Gx server.
3.
Enable the virtual Gi mode in the interface configuration mode.
4.
Enable VLAN symmetric classification.
Command
Purpose
enable
Enables privileged EXEC mode. Enter your
password when prompted.
Example:
SCE> enable
Step 2
configure
Enables the global configuration mode.
Example:
SCE#> configure
Cisco Service Control Mobile Solution Guide
3-12
OL-30600-01
Chapter 3
Gx Interface Support
Mapping of VLAN ID to Virtual Gi ID
Step 3
Command
Purpose
diameter gx virtual-gi vlan-id vlan-id mapping value1
Configures the VLAN-ID to virtual-Gi-ID mapping
in the global configuration mode.
Example:
SCE(config)#> diameter Gx virtual-gi vlan-id 2
mapping 3
Step 4
diameter peer name peer-host ip-address [port <port#>]
Example:
•
vlan-id—Specifies the vlan-id to be mapped.
•
value1—Specifies the virtual Gi ID.
Configures the Gx server (PCRF server) in the
global configuration mode.
•
name—Name to be assigned to the entry in the
peer table.
•
ip-address—IP address of the host.
SCE(config)#> diameter peer GX peer-host
10.78.241.155 port 3868
A peer is defined by an URI. This means that the
same IP can not be used on different ports to
distinguish between two servers except when a
DNS is used.
•
Step 5
interface linecard 0
port#—Port number used.
Enables the interface configuration mode.
Example:
SCE(config)#> interface linecard 0
Step 6
subscriber virtual-gi-mode
Enables the virtual Gi mode.
Example:
SCE(config-if)#> subscriber virtual-gi-mode
Step 7
VLAN symmetric classify
Example:
SCE(config-if)#> VLAN symmetric classify
Step 8
show interface linecard 0 subscriber virtual-gi-mode
Enables VLAN symmetric classification in the
interface configuration mode. This command
enables VLAN-ID to be retieved from the subscriber
traffic.
Enter this command in the global configuration
mode.
Example:
SCE(config)#> show interface linecard 0 subscriber
virtual-gi-mode
Step 9
show diameter gx virtual-gi all
Displays the status of the virtual Gi mode.
Displays the virtual Gi mapping table having all the
existing VLAN ID to virtual Gi ID mapping.
Example:
SCE(config)#> show diameter gx virtual-gi all
Step 10
show running-config | include diameter
Displays diameter related configurations made in
the system.
Monitoring Mapping of VLAN ID to Virtual ID
To monitor mapping of VLAN ID to Virtual ID, use one or more of the following commands.
These commands are in viewer mode.
Cisco Service Control Mobile Solution Guide
OL-30600-01
3-13
Chapter 3
Gx Interface Support
Mapping of VLAN ID to Virtual Gi ID
Command
Purpose
show diameter gx virtual-gi all
Displays all the VLAN ID to virtual Gi ID mappings.
show diameter gx virtual-gi vlan-id
vlan-id
Displays a particular VLAN ID and virtual ID mapping.
show interface linecard 0 VLAN
Displays the VLAN configuration mode.
show interface linecard 0 subscriber
virtual-gi-mode
Displays the status of the virtual Gi mode.
Cisco Service Control Mobile Solution Guide
3-14
OL-30600-01
Chapter 3
Gx Interface Support
Mapping Multiple VLAN IDs to a Virtual Gi ID
Mapping Multiple VLAN IDs to a Virtual Gi ID
Multiple VLAN IDs can be mapped to a Virtual Gi ID. This is useful in scenarios where Cisco SCEs are
used on Subscriber side and Network side for redundant connectivity between Cisco SCE loadbalancer
and Cisco SCE.
If a VLAN to VGi mapping is configured, Cisco SCE handles the traffic as a VGi traffic. If mapping is
not configured, the traffic is considered as generic traffic.
By default, this feature is disabled on Cisco SCE devices.
Configuring Multiple VLAN IDs to a Virtual Gi ID Mapping
Following are the steps for configuring the mapping of VLAN ID to a virtual Gi interface ID:
Step 1
1.
Configure the VLAN ID mapping to a virtual Gi ID.
2.
Configure the Gx server.
3.
Enable the virtual Gi mode in the interface configuration mode.
4.
Enable VLAN symmetric classification.
Command
Purpose
enable
Enables privileged EXEC mode. Enter your
password when prompted.
Example:
SCE> enable
Step 2
configure
Enables the global configuration mode.
Example:
SCE#> configure
Step 3
diameter gx virtual-gi multiple-mapping enable
Enables the multiple VLAN-ID to a virtual-Gi-ID
mapping in the global configuration mode.
Example:
SCE(config)#> diameter Gx virtual-gi multiple-mapping
enable
Step 4
diameter gx virtual-gi vlan-id vlan-id mapping value1
Example:
SCE(config)#> diameter Gx virtual-gi vlan-id 111
mapping 4
Step 5
diameter gx virtual-gi vlan-id vlan-id mapping value1
Example:
SCE(config)#> diameter Gx virtual-gi vlan-id 211
mapping 4
Configures the VLAN-ID to virtual-Gi-ID mapping
in the global configuration mode.
•
vlan-id—Specifies the vlan-id to be mapped.
•
value1—Specifies the virtual Gi ID.
Configures the VLAN-ID to virtual-Gi-ID mapping
in the global configuration mode.
•
vlan-id—Specifies the vlan-id to be mapped.
•
value1—Specifies the virtual Gi ID. Note that
this value is same as the one configured in the
earlier step.
Cisco Service Control Mobile Solution Guide
OL-30600-01
3-15
Chapter 3
Gx Interface Support
Mapping Multiple VLAN IDs to a Virtual Gi ID
Step 6
Command
Purpose
diameter peer name peer-host ip-address [port <port#>]
Configures the Gx server (PCRF server) in the
global configuration mode.
Example:
•
name—Name to be assigned to the entry in the
peer table.
•
ip-address—IP address of the host.
SCE(config)#> diameter peer GX peer-host
10.78.241.155 port 3868
A peer is defined by an URI. This means that the
same IP can not be used on different ports to
distinguish between two servers except when a
DNS is used.
•
Step 7
interface linecard 0
port#—Port number used.
Enables the interface configuration mode.
Example:
SCE(config)#> interface linecard 0
Step 8
subscriber virtual-gi-mode
Enables the virtual Gi mode.
Example:
SCE(config-if)#> subscriber virtual-gi-mode
Step 9
VLAN symmetric classify
Example:
SCE(config-if)#> VLAN symmetric classify
Step 10
show interface linecard 0 subscriber virtual-gi-mode
Enables VLAN symmetric classification in the
interface configuration mode. This command
enables VLAN-ID to be retieved from the subscriber
traffic.
Enter this command in the global configuration
mode.
Example:
SCE(config)#> show interface linecard 0 subscriber
virtual-gi-mode
Step 11
show diameter gx virtual-gi all
Displays the status of the virtual Gi mode.
Displays the virtual Gi mapping table having all the
existing VLAN ID to virtual Gi ID mapping.
Example:
SCE(config)#> show diameter gx virtual-gi all
Step 12
show running-config | include subscriber
Displays the status of virtual Gi.
Example:
SCE(config)#> show running-config | include
subscriber
Step 13
show running-config | include diameter
Displays diameter related configurations made in
the system.
Monitoring Multiple VLAN ID to a Virtual Gi ID Mapping
To monitor mapping of multiple VLAN IDs to a Virtual Gi ID, use one or more of the following
commands.
These commands are in viewer mode.
Cisco Service Control Mobile Solution Guide
3-16
OL-30600-01
Chapter 3
Gx Interface Support
Mapping Multiple VLAN IDs to a Virtual Gi ID
Command
Purpose
show diameter gx virtual-gi
multi-mapping
Displays whether the Multiple VLAN ID to Virtual Gi ID mapping is enabled.
show diameter gx virtual-gi all
Displays all the VLAN ID to virtual Gi ID mappings.
show diameter gx virtual-gi vlan-id
vlan-id
Displays a particular VLAN ID and virtual ID mapping.
show interface linecard 0 VLAN
Displays the VLAN configuration mode.
show interface linecard 0 subscriber
virtual-gi-mode
Displays the status of the virtual Gi mode.
Cisco Service Control Mobile Solution Guide
OL-30600-01
3-17
Chapter 3
Gx Interface Support
Mapping Multiple VLAN IDs to a Virtual Gi ID
Cisco Service Control Mobile Solution Guide
3-18
OL-30600-01
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising