Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
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:
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 188.8.131.52, which is what we will be doing later in this exercise, but using ECS.
[desintation]CSE_2(config-acl)#deny ip any 184.108.40.206 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
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
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>
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.
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
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:
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.
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:
tcp either-port = 80
This ruledef could be matched with a protocol analyzer in the rulebase as follows:
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-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:
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