Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Basics of setting up Enhanced Charging Service v2 (ECS)

Though it has a lot of pieces that need to fit together to work, ECS is not difficult once you understand the concepts and the various components that need to be configured. Topics covered are access control lists, subscriber profiles, ruledefs, charging-services, rulebases, and UDRs. We'll show how to drop packets as an example.

 

Though it has a lot of pieces that need to fit together to work, ECS is not difficult once you understand the concepts and the various components that need to be configured. Here we’ll cover everything you need to know to drop ping packets during a call. Topics covered are access control lists, subscriber profiles, ruledefs, charging-services, rulebases, and UDRs. The combination of this tutorial along with the PDSN Administration and ECS v2 manuals should provide a solid jump start in learning ECS.

Note: This document uses angle brackets < > to specify names that you assign instead of being hard-coded.

Configuring Subscriber Profiles and Access Control List

ECS relies on subscriber profiles to be able to redirect and process traffic for the appropriate users. Note that subscriber profiles can be retrieved from a Radius server during Radius Authentication, where the user profile data is not stored on ST16, or they can be stored on ST16 using a local subscriber profile. The exercise here is not focusing on how to interact with Radius, so we’ll just focus on the concept of creating a local subscriber profile to keep it simple. Note that this profile will need to be specified/defined in the context where authentication is done, as well as in the destination context where the mobile node (MN) IP address gets assigned.

For the subscriber profile in question, an IP Access List (ACL) needs to be assigned to it, for both the inbound (packets received from the MN) and outbound (packets sent to the MN) directions. While configuring the user profile, execute:

[source]CSE_2(config-subscriber)# ip access-group <ACL name>

Note that the above command will apply to BOTH directions. If you only want to apply to one direction, then add “in” or “out” at the end of the command, for example:

[source]CSE_2(config-subscriber)# ip access-group <ACL name> in

Also note that the command name is “access-group”, though it is really an Access List.

The other item to be added to the user profile is the name of the rulebase from the Active Charging Service that should be accessed by subscribers of this profile:

active-charging rulebase <Rulebase name>

This RuleBase will be defined later in the Active Charging Service to be created.

Next, the access list, along with any other relevant access lists, must be added to the configuration for the destination context:

[destination]CSE_2(config-ctx)#ip access-list <ACL name>

[destination]CSE_2(config-acl)#

In an access list, you can specify an ordered set of rules that control what to do with packets passing through. The list is processed top to bottom – there is no “priority” field to specify the ordering. Filters can be specified to deny, permit or re-address or re-direct certain packets. The easy solution for this exercise would be to add a deny rule. For example, the following rule will drop packets from any source and with a destination 18.0.1.254, which is what we will be doing later in this exercise, but using ECS.

[desintation]CSE_2(config-acl)#deny ip any 18.0.1.254 255.255.255.255

The reason one might use ECS though is that ECS has the ability to track what you are doing with certain packet types, for example how many times you dropped the packet type, etc., whereas applying the filters at the ACL level will not result in being able to track this information.

CSS Delivery Sequence

As a side-note, the system actually has the ability to send traffic to more than one place, such that the traffic is processed in one place, then returned, and sent to a second place for more processing, and then to a third, and so on. To do this you would specify the ordered set of redirects to the various places or services, all defined in a CSS Delivery Sequence. Note that these services could be on the ST16 itself, or they could be external servers made by other vendors.

           

For now though, let’s keep it simple. In this case, we will specify redirecting to just ONE service, not a list of them, and in this case it will be an enhanced charging service that we will create in a moment. The command is:

redirect css service <ECS name> any

You could actually enter multiple redirects, but a packet will end up being sent to just one of them (specifically the first match found in order, assuming one is found) – it will not be sent to multiple services if there would be multiple matches. To do that, you would need to configure the CSS Delivery Sequence feature mentioned above.

Let’s review the few configuration additions made thus far:

In the destination context:

   ip access-list <ACL name>

redirect css service <ECS name> any  

   #exit

In BOTH the source and destination contexts:

   subscriber name <Subscriber name>

     ip access-group <ACL name>

     active-charging rulebase <Rulebase name>

     ip context-name destination                             => not mentioned above but important

   #exit

You can read about all of the configuration made above in the ECS v2 manual, Chapter 2, Configuring ECS for PDSN Services, Section: Redirecting Subscriber Traffic to ECS.

Creating Enhance Charging Service

Now we are ready to create the enhanced charging service. From the global config mode:

[destination]CSE_2(config)# active-charging service <ECS name>

[destination]CSE_2(config-acs)#

We now need to create a ruledef which is used to filter on certain packets, a charging-action to specify what action to take on packets handed to it as a result of being filtered by the ruledef, and a rulebase to tie together ruledefs and charging-actions. In this very simple case, we will only create one of each, where the rulebase ties together the one ruledef and one charging-action we create. But, a real system would probably have multiple ruledef and charging-action pairs in the RuleBase. Traffic that enters the charging service will be compared to each rule until a match is found.

To create the ruledef:

[destination]CSE_2(config-acs)# ruledef <RuleDef name>

[destination]CSE_2(config-acs-ruledef)#

For this ruledef we want to filter on all IP packets that have a specific destination IP address:

     ip dst-address = 18.0.1.254/32

To create the charging-action:

[destination]CSE_2(config-acs)# charging-action <Charging Action name>

[destination]CSE_2(config-charging-action)#

Charging actions are typically used for billing policies, and are where User Data Records (UDRs) and Event Data Records (EDRs) are assigned. UDRs are more for tracking general usage for a user, while EDRs are for tracking specific events, such as download completions. By default, all charging actions will write to the UDR data file, the format of which we will define in a moment, while for EDRs, they must be explicitly specified by the “billing-action” command in the particular charging-action config. For this particular example’s charging action, we want to drop the packet, which will be an ICMP (Ping) packet:

    

     flow action discard

     content-id 100

The content-id value is a label for tracking the specific charging-action and is used elsewhere.

Finally, tying the charging-action with the ruledef in a Rulebase is done as follows:

[destination]CSE_2(config-acs)# rulebase <Rulebase name>

[destination]CSE_2(config-rule-base)# action priority 1000 ruledef <RuleDef name> charging-action <Charging Action name>

The priority field (lower valued priority is actually a higher priority and invokes first) allows for convenient adding of pairs of ruledefs and charging-actions in any order. The prioritization field controls the order that the pairs are consulted when the Rulebase is being accessed, so the process of re-ordering the pairs that have been previously added is efficient. More specific rules usually have a higher priority and less specific rules should be assigned a lower priority.

The above usage of the ruledef is known as a charging ruledef and starts with the action keyword.

Routing Ruledefs

The other usage/type of a ruledef in a rulebase is as a routing ruledef, which starts with the route keyword, and which will need to be matched with an analyzer category, such as “http”, in the Rulebase. This is required in situations where deep packet inspection is required to examine the packet contents at layers deeper than layer three (i.e. need to know more than the port number, IP address, etc., for example, the URL address.) The results of these deep packet inspections for specific protocols such as http are relied upon by certain charging ruledefs that themselves require this information in order to be able to do their own proper packet identification for those same protocols.

Here is an example of a routing ruledef:

ruledef HTTP_port_80

tcp either-port = 80

rule-application routing

This ruledef could be matched with a protocol analyzer in the rulebase as follows:

route priority 50 ruledef HTTP_port_80 analyzer http

and the results of this http deep packet inspection may be needed by a specific charging-ruledef that is http-dependent, for example:

action priority 500 ruledef <Charging Ruledef > charging-action <Charging Action>

Before leaving the rulebase, we need to point to the UDR format to be used by any of the charging-actions when data is written (default behavior).

billing-records udr udr-format <UDR format name>

Back in the config space of the active-charging service, we now need to define this format:

[destination]CSE_2(config-acs)#udr-format <UDR format name>

[destination]CSE_2(config-acs-udr)#

Here you can specify over 30 attributes that you want to appear in the data record with the attribute command, for example:

[destination]CSE_2(config-acs-udr)#attribute sn-content-id priority 10

Configuring UDR file creation

Finally, go into context configuration mode for any context besides the local context, and configure the UDR file creation properties for the data that will be generated. Note that most of the parameters are optional.

[source]CSE_2(config-ctx)# udr-module active-charging-service

[source]CSE_2(config-udr)# file name <UDR file name> trailing-text test exclude-checksum-record time-stamp rotated-format sequence-number padded-six-length

Note that the files are written in memory on the PAC and not to the flash. Once written, UDRs and EDRs are pulled out of the ST16 to an L-ESS (Local External Storage Server) server. This server acts as a storage mechanism until these files can be pulled into mediation and through to billing. If you want to be able to access these files remotely, you will need to setup an administrator account with sftp capability in the local context, as well as configuring ssh and sftp in the context that you just configured for UDR file creation (details in manual).

Reviewing the configured settings

There are many show commands you can run in order to view all of the settings you have just made for active-charging service. Here are some of them that you should run to confirm your work.

show active-charging [service | ruledef | charging-action | rulebase | udr-format] all

show active-charging file-space-usage

Testing the configuration

Make a call that does 10 pings, while monitoring for the next call with verbosity = 2.

Make sure that the name of the subscriber matches the subscriber profile you created in the source and destination contexts.

You should see the 10 pings but no responses because they have been dropped by ECS.

Here are some commands you can run to see what ECS has done since the beginning:

show active-charging [ruledef | charging-action | rulebase] statistics

Note that the rulebase statistics include information on the UDRs that are generated.

You can clear these statistics as well on a component basis:

clear active-charging [ruledef | charging-action | rulebase] statistics

You can view the list of active subscribers that are using ECS and a summary of their activity:

show active-charging sessions all

show active-charging sessions summary all

Finally, you can view all the detailed ECS information for all active subscribers that are using ECS with the following command.

show active-charging sessions full all

Besides all the significant call setup information, it includes the active-charging service name, the rulebase name, and all the packet data statistics for all the ruledefs in the rulebase, plus a whole lot more! Of course you can limit viewing certain subscribers by modifying the above commands as well.

Imported from Starent Networks Knowledgebase Article # 10060

Version history
Revision #:
1 of 1
Last update:
‎01-24-2012 04:10 PM
Updated by:
 
Everyone's tags (1)
Comments
New Member

I have read in the configuration guide that ECS allows you to configure free sites. For example, configuring Cisco.com not to be a free websites. However the configuration is not clear and I am not sure if it can be done or not.

Can you please explain more regarding this ECS feature?