Contents

Overview·· 1

Technical background· 1

Benefits· 1

Technology implementation· 1

Network model 1

Mechanisms· 2

Concepts· 2

DIP-based hierarchical accounting policy assignment 2

Traffic matching mechanism·· 3

Interacting with the server 3

Overview

Technical background

With traditional accounting policies, the device mixes all traffic of a user together to perform accounting. The policies cannot implement destination IP-based (DIP-based) hierarchical accounting to classify traffic destined for different network resources.

DIP-based hierarchical accounting can perform accounting on a per-IP basis, which meets the refined accounting requirements of users.

Benefits

DIP-based hierarchical accounting is more flexible than traditional accounting for portal and 802.1X authenticated users.

·     The hierarchical accounting technology not only can perform accounting on a per-user basis, but also can classify the traffic of a user based on the traffic destination IP addresses. The hierarchical accounting technology facilitates the accounting server to use different accounting policies to charge traffic destined for different network resources.

·     The hierarchical accounting technology supports separating IPv4 and IPv6 traffic for accounting.

Technology implementation

Network model

As shown in Figure 1, the user on the client sends traffic destined for Website A and Website B after it passes 802.1X or portal authentication. With DIP-based hierarchical accounting, the statistics of the traffic destined for Website A and Website B are separately counted based on the traffic destination IP addresses.

Figure 1 Network model

Mechanisms

Concepts

DIP-based hierarchical accounting policy

A DIP-based hierarchical accounting policy defines accounting levels and the traffic matching criteria of the accounting levels.

One DIP-based hierarchical accounting policy can have a maximum of eight accounting levels. ACLs are applied to each accounting level to filter traffic. The ACLs contain different rules to match traffic destined for different IP addresses or subnets. If an inbound or outbound flow matches an ACL rule, the statistics of the flow is counted at the corresponding accounting level.

An accounting level can correspond to multiple destination IP addresses. Each destination IP address corresponds to an accounting flow.

Fast matching entry

A fast matching entry includes an IP address and the accounting level of the IP address.

When the access device receives a service packet destined for an IP address for the first time, it matches the packet to an accounting level based on the destination IP address and the applied accounting policy. Then, the access device creates a fast matching entry for the IP address.

When the access device receives packets destined for the same destination, it searches the fast matching table for the destination IP address to obtain the accounting level of the packets. The search conditions are the destination IP address and the name of the applied accounting policy.

DIP-based hierarchical accounting policy assignment

To implement DIP-based hierarchical accounting for a portal or 802.1X authenticated user, include DIP-based hierarchical accounting policies in a user profile and assign the user profile to the user. A user profile can contain a maximum of four accounting policies.

You can specify a user profile for a portal or 802.1X user in local user view on the access device or in the user account of that user on the RADIUS server. After the user passes portal or 802.1X authentication, the access device or RADIUS server assigns the user profile to the access port of the user.

The access device or RADIUS server only specifies the user profile name. You must configure the contents of the user profile on the access device, including DIP-based hierarchical accounting policies.

Traffic matching mechanism

Inbound traffic

A user accesses the network. When the access device receives service traffic from the user, it first searches for the fast matching entry of the traffic destination IP address to obtain the accounting level. The search conditions are the traffic destination IP address and the name of the accounting policy applied to the user.

·     If an entry is found, the statistics of the inbound service traffic is counted at the accounting level in the entry.

·     If no entry is found, the device matches the traffic to an accounting level according to the destination IP address and the accounting policy applied to the user. Then, the device creates a fast matching entry for the destination IP address and starts to count inbound traffic statistics for the accounting level.

Outbound traffic

A user visits the network. When the access device forwards outbound service traffic for the user, it first searches for the fast matching entry of the traffic destination IP address to obtain the accounting level. The search conditions are the traffic destination IP address and the name of the accounting policy applied to the user.

·     If an entry is found, the statistics of the outbound service traffic is counted at the accounting level in the entry.

·     If no entry is found, the device matches the traffic to an accounting level according to the destination IP address and the accounting policy applied to the user. Then, the device creates a fast matching entry for the destination IP address and starts to count outbound traffic statistics for the accounting level.

Interacting with the server

After a user passes portal or 802.1X authentication, the server assigns a user profile to the AC for the user. The AC delivers the ACL accounting policy configuration to the AP through the CAPWAP tunnel. The AP matches the user traffic to different accounting levels based on the traffic destination IP addresses and the ACL settings in the accounting policy. Additionally, the AP reports the traffic statistics to the AC at regular intervals for accounting of each level.

The AC notifies the server to start accounting for each level of traffic. The traffic of each accounting level is counted separately. The AC sends start-accounting requests, real-time accounting requests, and stop-accounting requests separately for each accounting level. In addition, the AC notifies the server of accounting updates at regular accounting intervals.

The level 0 traffic is the traffic that does not match the accounting policy. In DIP-based hierarchical accounting, the traffic of each accounting level is counted separately as a subuser of the main user (user with level 0 traffic) on the AAA server. The accounting is independent from the accounting of the main user.

After the main user goes offline, the AP notifies the AC to send stop-accounting requests for the main user and its subusers. When receiving stop-accounting requests for the users, the server sends stop-accounting responses to the AC to stop accounting for all accounting levels. After receiving the stop-accounting responses, the AC and AP delete the accounting policy and stop counting traffic statistics for the accounting levels.

Figure 2 Interaction between the AAA server and AC