Intelligent Broadband Remote Access Server (iBRAS) service awareness (SA) is also known as the iBRAS Application Awareness (APA) solution. Carriers can use the iBRAS SA solution to identify different service traffic types at the user level, and provide value-added services such as traffic acceleration and security protection at both the service and application levels for broadband access users. Additionally, the iBRAS SA solution can analyze the service quality of access users and control their service traffic, helping carriers achieve refined operations.

Network for the iBRAS SA solution

As shown in Figure 1, the H3C iBRAS SA solution is applied in the carrier's metropolitan area network (MAN), and its basic architecture mainly contains the following parts:

· iBRAS SA frontend—Implemented by the hardware APA card in the BRAS. When a forwarding plane interface module receives uplink service packets from users, the interface module directs the packets to the APA card. The APA card analyzes the users' service traffic, and identifies and tags the app category for each type of service traffic per user. Then, the APA card performs other value-added services (such as mirroring, acceleration, control, or blocking) for identified traffic based on application categories.

· iBRAS SA backend—A versatile business platform typically implemented by an H3C controller. The iBRAS SA backend performs poor quality analysis for user services, visually presents user service reports, and manages the application identification signature libraries for third-party plugins.

To implement the iBRAS SA solution, you need to configure SA user policies. An SA user policy is similar to a QoS policy. It contains the rules that match application types and the traffic forwarding behaviors. When the application category information of user traffic matches a rule of an SA user policy, the system executes the associated forwarding behavior defined by the SA user policy.

The iBRAS SA backend creates and defines SA user policies and deploys them to the iBRAS SA frontend (the APA cards). An APA card matches the application categories according to the SA user policies and then executes the associated traffic behaviors.

Figure 1 Basic network and architecture diagram of the iBRAS SA solution

iBRAS SA frontend

As shown in Figure 2, user traffic is directed to the APA card for processing. As the iBRAS SA frontend, the APA card in the BRAS primarily implements the following logical functions:

· Application identification—Uses integrated plugins on the APA card to identify user service traffic based on IP address, port number, application layer signatures of packets, and other information. Different types of service traffic require different identification mechanisms.

¡ App traffic—Traffic from common apps is identified based on various factors such as IP address, port number, and application layer signatures in packets. During application identification, the APA card typically classifies them. For example, iQIYI and TikTok are classified as video applications, and QQ and WeChat are classified as instant messaging (IM) applications. You can identify and distinguish video or IM applications by their category ID (major ID). Also, you can identify the traffic from a single app by using the application ID (minor ID). Therefore, the traffic of a certain app can have both a major ID and a minor ID, collectively referred to as the app ID.

¡ URL traffic—Traffic accessing certain webpages is identified based on the Uniform Resource Locator (URL) in the application layer information of packets. The APA card can identify traffic with a specific URL and process it separately. Alternatively, the APA card can categorize certain URLs and assign a URL category ID, and process traffic with URLs in the URL category collectively.

· Application acceleration—After the APA card identifies the user service traffic, it matches the traffic with the specified app IDs based on the SA user policies. Then, it redirects traffic of the specified applications based on the matching SA user policy to a dedicated acceleration channel for forwarding. In this way, the traffic bypasses the NAT processing process of the Carrier Grade NAT (CGN) module or the routing table lookup process, and application acceleration is implemented. For example, after you deploy the iBRAS SA solution, you can redirect prioritized game application traffic to a specific SRv6 TE policy tunnel for traversal across the public network. This provides users with value-added services such as game acceleration.

· Traffic control—Uses the plug-in's application identification capability to match traffic with the specified app IDs based on SA user policies on the APA card. Then, the APA card manages this type of traffic by implementing bandwidth limiting, connection limiting, or DSCP marking, as defined by SA user policies.

· Security protection—Security protection is a type of traffic management, with slight differences in implementation. The APA card matches traffic to the specified URLs based on SA user policies. Then, the APA card can block or redirect traffic accessing the specified illegal URLs, which can be precisely or fuzzily defined.

· Traffic mirroring—The APA card matches traffic with the specified app IDs based on SA user policies. Then, the APA card mirrors and copies application traffic with the specified app IDs to the specified monitor port or monitoring group based on the matching SA user policy. By connecting a monitoring device to the monitor port, you can analyze traffic details without affecting the service. Traffic mirroring is mainly used for network monitoring, troubleshooting, and network attack prevention.

Figure 2 Logical functions of the traffic identification and distribution system of the iBRAS SA frontend

iBRAS SA backend

As shown in Figure 3, the iBRAS SA backend, also known as the SA backend system, connects to the Operating Support System (OSS) and Business Support System (BSS) through the northbound API, and provides support for OSS and BSS. The OSS system provides functions such as fault management, device management, and configuration management through the iBRAS SA backend for the network. The BSS system provides services like service provisioning and marketing to users based on data analysis results from the iBRAS SA backend. The iBRAS SA backend connects to the iBRAS SA frontend through the southbound API to manage application identification signature libraries, deploy user traffic forwarding policies, and analyze traffic. The iBRAS SA backend, as a software suite, can be deployed in the resource pool of Multi-access Edge Computing (MEC) servers to provide low-latency edge computing services for user services, enhancing user experience.

The main logical functions implemented by the iBRAS SA backend include:

· Application identification signature library management—The iBRAS SA backend communicates with third-party signature library upgrade centers through the northbound application programming interface (API), and automatically updates and upgrades the signature libraries to adapt to protocol and application software changes. The iBRAS SA backend synchronizes application identification signature libraries with the iBRAS SA frontend through the southbound API. In addition, the iBRAS SA backend allows you to customize application identification signature libraries, making SA more flexible.

· SA user policy management and deployment—The iBRAS SA backend can obtain access user attributes and user-subscribed package policies from the AAA system through the northbound API. SA user policies define value-added services for different types of application traffic. For example, User A subscribes to a package that accelerates traffic for a specific game, or the administrator mirrors and analyzes the inbound traffic of an application for User A. The user policies will be deployed to the APA card through the southbound API of the iBRAS SA backend. The APA card will then execute actions on user traffic based on the received SA user policies.

· Traffic analysis and statistics—The iBRAS SA backend obtains user service traffic statistics and logs from the iBRAS SA frontend through the southbound API. Then, the iBRAS SA backend analyzes and calculates the Quality of Experience (QoE) information of user services, such as latency, packet loss rate, and speed when users browse webpages or watch videos, and generates statistical reports. The statistical reports can be sent to other service systems through the northbound API.

· Visual data presentation—The iBRAS SA backend provides web-based presentation of user statistics and analysis data.

Figure 3 Logical functions of the iBRAS SA backend

iBRAS SA workflow

The iBRAS SA workflow is as follows:

1. In normal conditions, after a user completes authentication, service traffic generated by the user is directed to an APA card for processing and analysis. At this point, the user information is recorded and the user comes online on the APA card.

2. After the user comes online, the BRAS APA card maintains and generates the SA user table. In the SA user table, an online user is uniquely identified by its IP address and the name of the VPN instance to which the user belongs.

3. Users on the APA card include two types: those with bound SA user policies and those without.

¡ For an online user bound to SA user policies, the APA card analyzes and identifies different traffic. Based on the identified app ID or URL category ID, the APA card matches user traffic with the bound SA user policies.

¡ For online users without bound SA user policies, the APA card does not execute the SA user policies. Instead, the APA card forwards the traffic as per the normal process.

4. When the user traffic matches a bound SA user policy, the traffic is reported to the CPU on the APA card for processing, and the CPU generates a service flow table to guide packet forwarding.

The CPU compares the traffic's ID (app ID or URL category ID) with the app IDs or URL category IDs specified in the SA user policies bound to the user.

¡ For the same service flow, if the ID of multiple consecutive packets matches the app IDs or URL category IDs in an SA user policy, the flow is considered matching the SA user policy, and the CPU generates a forwarding flow table based on the SA user policy.

¡ For the same service flow, if the ID of multiple consecutive packets does not match the IDs or URL category IDs in an SA user policy, the traffic is considered not matching the SA user policy, and the CPU generates a normal forwarding flow table without SA user policies.

5. Regardless of whether the user traffic matches an SA user policy, subsequent packets are directly fast forwarded based on the forwarding flow table without being sent to the CPU for comparison and processing.

iBRAS SA tasks at a glance

This document describes only configuration tasks on devices with APA cards installed and does not describe the iBRAS SA backend configuration tasks.

To configure iBRAS SA, perform the following tasks:

1. Creating an SA node

2. Configuring the processing mode for an APA card

3. (Optional.) Configuring the minimum number of CPUs required by the iBRAS SA feature

4. (Optional.) Configuring traffic to bypass the APA card

5. Configuring SA user policies

6. Configuring user online/offline events and binding users to SA user policies

7. Redirecting traffic of the specified application

8. Configuring the monitor ports or monitoring groups for traffic mirroring

9. Configuring QoE analysis

10. Configuring signature libraries

11. (Optional.) Setting the upper limit on the packet count for determining whether packets match an SA user policy

Creating an SA node

About this task

An SA node uniquely identifies a BRAS with an APA card installed. After you create SA nodes on BRASs, the SA backend can identify different iBRAS SA frontends.

Restrictions and guidelines

In SA node view, you can configure SA user policies and SA QoE analysis-related functions.

You can create only one SA node on one device.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

Configuring the processing mode for an APA card

About this task

Users that complete authentication and connect to the BRAS have various types of application traffic. This feature directs user service traffic received on the device to an APA card. The APA card analyzes the quality of different types of traffic for each user and identifies the services. Then, the APA card performs traffic acceleration, traffic redirecting, traffic mirroring, or traffic control on the identified service traffic based on the SA user policies.

The APA card supports the following processing mode:

· Inline mode—Directly routes user traffic to the APA card. The APA card identifies, analyzes, and processes the traffic before forwarding it. In this mode, the BRAS SA feature performs QoE quality analysis on service traffic. It also performs traffic acceleration, traffic redirecting, traffic mirroring, or traffic control on identified service traffic based on SA user policies, which might introduce processing delays.

Restrictions and guidelines

Use the sa port mode command to configure how an APA card processes traffic. The sa port mode command applies only to user traffic received on the specified interface.

For APA card-based functions such as traffic redirecting and traffic mirroring to take effect, you must first execute the sa port mode command to direct traffic to an APA card in inline mode.

CAUTION:

When many access users exist, executing this command will refresh the user entries, which affects the device CPU performance. Do not execute this command repeatedly in a short period.

APA cards include the following cards: IM-APA-I cards.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Direct the traffic from the specified interface to the APA card and set the processing mode for the APA card.

sa port mode inline interface interface-type interface-number

By default, traffic of an interface is not directed to the APA card for processing.

Configuring the minimum number of CPUs required by the iBRAS SA feature

About this task

The APA card has limited CPU engines and processing capacity. To support large-scale users and service traffic, the iBRAS SA feature requires multiple CPU engines to work together. In this case, configure the minimum number of CPUs required by the iBRAS SA feature. If the device has fewer CPUs than the minimum number required, traffic bypasses the APA card without being processed. This prevents failures caused by service overload.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Configure the minimum number of CPUs required by the iBRAS SA feature.

sa engine min-engine number

By default, the system does not set the minimum number of CPUs required by iBRAS SA, and the APA card with any number of CPUs can support iBRAS SA.

Configuring traffic to bypass the APA card

Restrictions and guidelines

If you execute the sa port mode command to direct traffic to the APA card for processing, you must preferentially restore the services quickly when the APA card fails due to hardware issues or software errors without automatic recovery. To do that, use the sa engine bypass command to configure traffic to bypass the APA card and skip its processing.

After you execute the sa engine bypass command, the executed sa port mode command will not take effect.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Configure traffic to bypass the APA card.

sa engine bypass

By default, traffic is not configured to bypass the APA card. Whether traffic passes through the APA card depends on the configuration of the sa port mode command.

Configuring SA user policies

About this task

You can define SA user policies in the iBRAS SA backend and deploy them to the APA card. The APA card then executes traffic behaviors according to the SA user policies. The SA backend supports the following SA user policies:

· App ID-based traffic acceleration—Redirects the traffic of applications with the specified app IDs directly to the SRv6 TE policy tunnel for fast forwarding or forwards the traffic through looking up the routing table of the specified VPN instance. App ID-based traffic acceleration is also known as app ID-based traffic redirecting.

· App ID-based traffic mirroring—Mirrors the traffic from applications with the specified app IDs to the monitor port or monitoring group of a mirroring group.

· App ID-based traffic control—Controls, limits the number of connections for, or drops the traffic from applications with the specified app IDs.

· URL-based traffic control—Redirects or drops traffic from users accessing the specified URLs.

· URL category ID-based traffic control—Groups multiple URLs with the same signatures into one category, assigns a URL category ID to this group, and redirects or drops traffic from users accessing URLs of the specified categories.

· URL allowlist—Adds the specified URLs to the URL allowlist, and allows traffic accessing the allowlisted URLs to pass directly without traffic control.

Restrictions and guidelines: SA user policy configuration

You can only configure and create SA user policies in real-time-mode system view (system-view immediate).

Configuring an SA user policy with app ID-based traffic acceleration

Restrictions and guidelines

For traffic redirecting or acceleration to operate correctly for traffic with the specified app IDs, make sure the following conditions are met:

· Execute the sa global mode command to direct traffic to the APA card for application identification.

· Make sure the SA backend has deployed an SA user policy with app ID-based traffic acceleration to online users.

· Execute the sa-ctl accelerate-policy add command. Make sure the app ID specified by using the sa app-id redirect command belongs to the SA user policy with app ID-based traffic acceleration.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Create an SA user policy with app ID-based traffic acceleration, and add app IDs to the SA user policy.

sa-ctl accelerate-policy add name { app-id app-id }&<1-64>

4. (Optional.) Delete app IDs from the SA user policy with app ID-based traffic acceleration.

sa-ctl accelerate-policy delete name { app-id app-id }&<1-64>

Configuring an SA user policy with app ID-based traffic mirroring

About this task

To analyze traffic with the specified app IDs from the specified users, create an SA user policy with app ID-based traffic mirroring on the SA backend (the controller) and define the app ID-mirroring group ID mappings in the SA user policy. After you deploy the SA user policy to a BRAS installed with an APA card, execute the sa mirroring-group mirror-to command on the BRAS to specify the monitor port or monitoring group for each mirroring group. Then, the application traffic with the specified app ID will be forwarded to the monitor port or monitoring group of the specified mirroring group.

Restrictions and guidelines

For traffic mirroring to operate correctly for traffic with the specified app IDs, make sure the following conditions are met:

· Execute the sa global mode command to direct traffic to the APA card for application identification.

· Execute the sa-ctl mirror-policy add command to create an SA user policy. Make sure the mirroring group ID specified in the sa mirroring-group mirror-to command matches one specified in the SA user policy.

· Make sure the SA backend has deployed an SA user policy with app ID-based traffic mirroring for online users.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Create an SA user policy with app ID-based traffic mirroring, and add app ID-mirroring group ID mappings in the SA user policy.

sa-ctl mirror-policy add name { app-id app-id { inbound group-id | outbound group-id } }&<1-16>

4. (Optional.) Delete the app ID-mirroring group ID mappings from the SA user policy with app ID-based traffic mirroring.

sa-ctl mirror-policy delete name { app-id app-id { inbound | outbound } }&<1-16>

Configuring an SA user policy with app ID-based traffic control

About this task

Execute the sa-ctl control-policy add command to create an SA user policy with app ID-based traffic control. The SA backend then deploys this policy to users who come online. When the app ID in the online user traffic matches an app ID specified in the SA user policy, the device will execute the matching forwarding behavior, such as rate-limiting, limiting the number of connections for, marking a DSCP value, or directly dropping the traffic with the specified app ID.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Create an SA user policy with app ID-based traffic control, and add app IDs to the SA user policy.

sa-ctl control-policy add name { app-id app-id { { in-cir committed-information-rate [ in-cbs committed-burst-size ] | in-connection-limit number | in-remark-dscp dscp-value | out-cir committed-information-rate [ out-cbs committed-burst-size ] | out-connection-limit number | out-remark-dscp dscp-value } * | drop } }&<1-64>

4. (Optional.) Delete app IDs from the SA user policy with app ID-based traffic control.

sa-ctl control-policy delete name { app-id app-id }&<1-64>

Configuring an SA user policy with URL category ID-based traffic control

About this task

The APA card can identify traffic accessing certain webpages based on the URLs in the application layer information of the packets. The APA card can identify traffic with a specific URL and process it separately. Alternatively, the APA card can categorize certain URLs and assign a URL category ID, and process traffic with URLs in the URL category collectively.

Execute the sa-ctl sort-url-policy add command to create an SA user policy with URL category ID-based traffic control, and add the specified URL category IDs to the SA user policy. The SA user policy uniformly drops traffic accessing URLs of specified categories or redirects the traffic to the URL specified in the sa redirect-url command.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Create an SA user policy with URL category ID-based traffic control, and add URL category IDs to the SA user policy.

sa-ctl sort-url-policy add name { sort-url sort-id action { drop | redirect } }&<1-16>

4. (Optional.) Delete URL category IDs from the SA user policy with URL category ID-based traffic control.

sa-ctl sort-url-policy delete name { sort-url sort-id }&<1-16>

5. Redirect traffic to the specified URL.

sa redirect-url url

By default, traffic is not redirected to the specified URL.

Configuring an SA user policy with URL-based traffic control

About this task

Use the sa-ctl url-policy add command to create an SA user policy with URL-based traffic control, and add the specified URLs to the SA user policy. The SA user policy drops traffic accessing the specified URLs or redirects the traffic to the URL specified in the sa redirect-url command.

For URLs, you can perform either exact match or fuzzy match.

· Exact match—For the URL information carried in the application layer information of the packets to match, it must be exactly the same as the URL specified by using the sa-ctl url-policy add command.

· Fuzzy match—For the URL information carried in the application layer information of the packets to match, it only needs to contain the URL specified by using the sa-ctl url-policy add command.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Create an SA user policy with URL-based traffic control, and add URLs to the SA user policy.

sa-ctl url-policy add name { url url action { drop | redirect } [ exact-match ] }&<1-10>

4. (Optional.) Delete URLs from the SA user policy with URL-based traffic control.

sa-ctl url-policy delete name { url url }&<1-10>

5. Redirect traffic to the specified URL.

sa redirect-url url

By default, traffic is not redirected to the specified URL.

Configuring an SA user policy with the URL allowlist

About this task

Add the specified URLs to the URL allowlist, and allow traffic accessing the allowlisted URLs to pass directly without traffic control.

For URLs, you can perform either exact match or fuzzy match.

· Exact match—For the URL information carried in the application layer information of the packets to match, it must be exactly the same as the URL specified by using the sa-ctl whitelist-url-policy add command.

· Fuzzy match—For the URL information carried in the application layer information of the packets to match, it only needs to contain the URL specified by using the sa-ctl whitelist-url-policy add command.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Create an SA user policy with the URL allowlist and add URLs to the allowlist in the SA user policy.

sa-ctl whitelist-url-policy add name { whitelist-url url [ exact-match ] }&<1-10>

4. (Optional.) Delete URLs from the SA user policy with the URL allowlist.

sa-ctl whitelist-url-policy delete name { whitelist-url url }&<1-10>

Configuring user online/offline events and binding users to SA user policies

About this task

Execute sa-ctl user online command on the BRAS to simulate user online events without the need for normal user authentication. By simulating user online events and then executing the sa-ctl user bind command to bind SA user policies, you can debug SA services for online users. To display simulated online users, execute the display sa user command.

Different SA user policies are deployed to different users. Typically, all user traffic is sampled and undergoes QoE analysis, and only specific traffic from certain users undergo traffic acceleration or traffic control.

Restrictions and guidelines

The sa-ctl user online and sa-ctl user bind commands are for debugging to simulate user online events, and they are not recommended for users.

Make sure the slot keyword in the sa-ctl user online command specifies an APA card. If you fail to do that, users cannot come online on an APA card, and you cannot view these users by using the display sa user command.

You can specify the batch keyword in the sa-ctl user online command to bulk simulate user online or offline events. For example, if you use the sa-ctl user online command to set the user's online IP address to 192.168.1.2 and set the value for the count argument to 100 in the batch count option, you bulk specify the user online IP addresses in the range of 192.168.1.2 to 192.168.1.101.

When no SA user policy parameters are specified in the sa-ctl user bind command, the online users are not bound to any SA user policy. These users are insignificant.

When you execute the sa-ctl user bind command multiple times to modify the mask of the same IP address or when the specified user IP addresses overlap or have an inclusion relationship, the most recent command cannot be executed. To resolve this issue, first delete the existing overlapping IP address range, and then configure the new user IP address. For example, if you configure users with IPv4 address 1.1.1.0 and mask length 24 and then configure users with IPv4 address 1.1.1.2 and mask length 32, the first configured users and the latter configured users have an inclusion relationship. The command for the latter configured users cannot be issued.

When you execute the sa-ctl user bind command with the batch keyword to bulk bind SA user policies to online users, follow these restrictions and guidelines:

· When you specify a single user IP address without specifying the mask-length or prefix-length parameter, the system will allow all users to come online with addresses in the range from that specified IPv4 or IPv6 address to that address plus count minus one. For example, if you use the sa-ctl user bind command to set the user IP address to 192.168.1.2 and set the value for the count argument to 100 in the batch count option, you bulk specify the user online IP addresses in the range of 192.168.1.2 to 192.168.1.101.

· When you specify a user IP address range by configuring the mask-length or prefix-length argument, the specified user IPv4 or IPv6 address range will be used as one user and also as the start value and count-1 address ranges with the same mask or prefix length will be added. For example, if you use the sa-ctl user bind command to set the user IP address to 192.168.1.0 with mask length 24 and set the value for the count argument to 10 in the batch count option, you bulk specify the user online IP addresses in the range of 192.168.1.0/24 to 192.168.10.0/24.

Simulating user online and offline events

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Simulate user online events.

In standalone mode:‌

sa-ctl user online { ipv4-address | ipv6-address } [ vpn-instance vpn-instance-name ] [ batch count ] slot slot-number [ cpu cpu-number ]

In IRF mode:

sa-ctl user online { ipv4-address | ipv6-address } [ vpn-instance vpn-instance-name ] [ batch count ] chassis chassis-number slot slot-number [ cpu cpu-number ]

4. Simulate user offline events.

In standalone mode:‌

sa-ctl user offline { ipv4-address | ipv6-address } [ vpn-instance vpn-instance-name ] [ batch count ] slot slot-number

In IRF mode:

sa-ctl user offline { ipv4-address | ipv6-address } [ vpn-instance vpn-instance-name ] [ batch count ] chassis chassis-number slot slot-number

Binding users to SA user policies

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Bind users to SA user policies.

sa-ctl user bind { ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } [ vpn-instance vpn-instance-name ] [ batch count | user-name user-name ] [ accelerate-policy name | control-policy name | mirror-policy name | sort-url-policy name | url-policy name | whitelist-url-policy name ] *

4. (Optional.) Unbind the users from the SA user policies.

sa-ctl user unbind { ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } [ vpn-instance vpn-instance-name ] [ batch count ]

sa-ctl user unbind all

Setting the aging time for SA user entries

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Set the aging time for SA user entries.

sa user aging-time time

By default, the aging time of SA user entries is 300 seconds.

Setting the aging time for service forwarding flow entries

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Set the aging time for service forwarding flow entries.

sa flow-table aging-time time

By default, the aging time of service forwarding flow entries is 240 seconds.

Redirecting traffic of the specified application

About this task

Execute the sa app-id redirect command to redirect the traffic of the application with the specified app ID to the specified SRv6 TE policy for forwarding, or redirect the traffic to the specified VPN instance and forward the traffic by looking up the local routing table of the VPN instance.

Restrictions and guidelines

For traffic redirecting or acceleration to operate correctly for traffic with the specified app IDs, make sure the following conditions are met:

· Execute the sa global mode command to direct traffic to the APA card for application identification.

· Make sure the SA backend has deployed an SA user policy with app ID-based traffic acceleration for online users.

· Execute the sa-ctl accelerate-policy add command. Make sure the app ID specified by using the sa app-id redirect command belongs to the SA user policy with app ID-based traffic acceleration.

If you execute the sa app-id redirect command multiple times for traffic with the same app ID, the most recent configuration takes effect.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Redirect traffic of the specified application.

sa app-id app-id redirect { srv6-policy endpoint color [ sid sid ] | vpn-instance vpn-instance-name }

Configuring the monitor ports or monitoring groups for traffic mirroring

About this task

Restrictions and guidelines

For traffic mirroring to operate correctly for traffic with the specified app IDs, make sure the following conditions are met:

· Execute the sa global mode command to direct traffic to the APA card for application identification.

· Make sure the SA backend has deployed an SA user policy with app ID-based traffic mirroring to online users.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Configure a monitor port or monitoring group for a traffic mirroring group.

sa mirroring-group group-id mirror-to { interface interface-type interface-number | monitoring-group monitoring-group-id }

If you execute this command multiple times with the same group-id argument, the most recent configuration takes effect.

Configuring QoE analysis

Enabling the QoE feature on an APA card

About this task

After the Quality of Experience (QoE) feature is enabled on an APA card, the APA card samples user signaling packets and data packets to create user flow logs, and sends these logs to the SA backend server through TCP. Then, the SA backend analyzes QoE for various user service traffic based on the user flow logs, provide raw data for building a data warehouse, and visually present the QoE analysis results of user service traffic.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Enable the QoE feature on the APA card.

sa qoe enable

By default, the global QoE feature is disabled.

Configuring the interval for reporting user flow logs to the server

About this task

Perform this task to control the interval for reporting user flow logs to the server.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Configure the interval for reporting user flow logs to the server.

sa flow-log interval interval

By default, the interval for reporting user flow logs to the server is 300 seconds.

Configuring encapsulation information for packets reporting user flow logs to a server

About this task

An APA card generates user flow logs by resolving user signaling packets and data packets. User flow logs contain basic information, such as the user IP, the protocol type of the user service packets, and traffic statistics.

After the APA card establishes a TCP connection to the SA backend analysis system (server), the APA card encapsulates user flow logs in TCP packets and sends them to the SA backend server. The SA backend analysis system analyzes QoE for various service traffic of users based on the user flow logs and provides raw data for building a data warehouse. It also visually presents the QoE analysis results of user service traffic.

Restrictions and guidelines

After you designate a load balancing group (load-balance-group) for multiple different server numbers, the same user flow log will be sent to only one server within the load balancing group, achieving load sharing of user flow logs.

For the same backend server, you can also configure multiple different server numbers. You can specify the same load balancing group, source IP address, and destination IP address, but with different destination port numbers, to enable user flow logs to be load-shared through different TCP ports.

Use the sa qoe collector command to configure the destination server address and the encapsulation information for packets reporting the user flow logs to the server. You can execute the sa qoe collector command multiple times to specify different server numbers and destination addresses, allowing the APA card to report user flow logs to different servers. If you execute the sa qoe collector command multiple times, the most recent configuration takes effect.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Configure encapsulation information for packets reporting user flow logs to a server.

sa qoe collector collector-id { source-ipv4 source-ipv4-address destination-ipv4 destination-ipv4-address | source-ipv6 source-ipv6-address destination-ipv6 destination-ipv6-address } destination-port port [ vpn-instance vpn-instance-name ] [ load-balance-group group-name ]

By default, no encapsulation information is configured for packets reporting user flow logs to a server.

Setting the user group capacity and polling interval for CPU analysis

About this task

The SA backend analyzes QoE for various service traffic of users based on the user flow logs reported by the APA card. It also visually presents the QoE analysis results of user service traffic.

Due to the large number of access users and the large scale of data, the device evenly organizes the users into several user groups. The APA card periodically pre-analyzes and processes data for a certain number of users on the local CPU. Use this feature to control the number of users in the user group that the local CPU pre-analyzes and processes during an interval, as well as the CPU pre-analysis interval.

Restrictions and guidelines

Configuring a large user group capacity might lead to too many users in a single group, placing significant pressure on CPU analysis and processing. Conversely, configuring a small user group capacity might result in too few users in a group, making the CPU analysis and processing results less accurate. You must adjust the number of users in the user group analyzed by the CPU during the interval based on the scale of access users. Also, you must set the user group polling and analysis interval appropriately.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Set the user group capacity for CPU analysis during the polling interval.

sa qoe group-capacity number

By default, the user group capacity for CPU analysis during the polling interval is 256000.

4. Configure the user group polling and analysis interval.

sa qoe polling-interval interval

By default, the user group polling and analysis interval is 60.

Configuring signature libraries

About this task

The iBRAS SA system must maintain two separate signature libraries:

· Predefined signature library—Signature mappings pre-loaded on the BRAS APA card and manually updated by loading a signature library file. The signature library file defines the mappings between common user service packet signatures in the live network and the app IDs or URL category IDs. The predefined signature library includes both the predefined application signature library and the predefined URL signature library.

¡ Predefined application signature library—Stores the mappings between the application packet signatures and the app IDs.

¡ Predefined URL signature library—Stores the mappings between URLs in packets and URL category IDs.

· Custom signature library—Mappings configured on the BRAS. The custom signature library includes both the custom application signature library and the custom URL signature library.

¡ Custom application signature library—Configured with the mappings between the signatures (such as the packet quintuples) and the app IDs.

¡ Custom URL signature library—Configured with the mappings between URLs in packets and URL category IDs.

Updating and upgrading the predefined signature library

About this task

For the BRAS SA feature to accurately identify over 99% of applications and URLs, which frequently change, you typically need to regularly update the predefined signature library.

To do that, upload a predefined signature library file to the local directory of the device through FTP, and then execute the sa signature update command to specify the path and name of the signature library file.

Restrictions and guidelines

The full path and name of the local signature library file cannot exceed 255 characters, including /mnt/ and file-path, for example, /mnt/flash:/url_sort_feature_1.2.txt.

Procedure

1. Enter system view.

system-view

2. Update and upgrade the predefined signature library.

sa signature update { application | url } file-path

By default, the predefined signature library is not updated or upgraded automatically.

Configuring the custom application signature library

About this task

The custom application signature library is a collection of mappings between packet signatures and app IDs. Perform this task to add new mappings between packet signatures and app IDs to the custom application signature library.

Packet signatures mainly include the following elements:

· Packet quintuple—Includes the source and destination IP addresses, source and destination ports, and the transport layer protocol type (TCP or UDP) of packets.

· Application layer signature keyword.

· Domain name information.

If you specify multiple packet quintuple parameters in the match rule for a packet signature-app ID mapping, a packet must match all the specified quintuple parameters to be considered compliant with the match rule. Then, the packet is assigned the specified major ID and minor ID.

If you specify all the three elements or two of the three elements in the match rule for a packet signature-app ID mapping, a packet only needs to match one of the specified elements to be considered compliant with the match rule. Then, the packet is assigned the specified major ID and minor ID.

A packet might match both a rule in the custom application signature library and a rule in the predefined signature library. If the packet matches the quintuple match criteria in the custom application signature library, the app ID assigned to the packet by the custom application signature library takes priority.

Restrictions and guidelines

When you execute the sa-ctl custom-app command, the same major ID can be associated with multiple different minor IDs, and the same minor ID can be associated with multiple different rule IDs. To prevent a packet from matching multiple different minor IDs or major IDs, do not associate a single match rule with multiple minor IDs. Similarly, do not associate a single minor ID with multiple major IDs. Additionally, make sure the match criteria specified by different rule IDs are different.

TIP:

When you execute the sa-ctl custom-app command to configure the custom application signature library, if the specified match rules only contain packet quintuple information, the custom application signature library will automatically update and take effect without the sa-ctl custom-app submit command. If the specified match rule contains application layer signature keywords or domain name information, execute the sa-ctl custom-app submit command to submit the configuration, which will then update and activate the custom application signature library.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Configure mappings between packet signatures and app IDs in the custom application signature library.

sa-ctl custom-app major-id major-id minor-id minor-id rule-id rule-id { [ [ source-ip source-ipv4-address | destination-ip destination-ipv4-address ] * | [ source-ipv6 source-ipv6-address | destination-ipv6 destination-ipv6-address ] * ] | source-port source-port | destination-port destination-port | [ tcp | udp ] | http-payload payload-list | domain-name name } *

4. Configure the name of the application with the specified app ID in the custom application signature library.

sa-ctl custom-app { major-id major-id | minor-id minor-id } name name

5. Submit the custom application signature library configuration.

sa-ctl custom-app submit

By default, the application signature library configuration does not take effect immediately.

Configuring the custom URL signature library

About this task

The custom URL signature library is a collection of mappings between URLs and URL category IDs. Use this command to add new mappings between URLs and their URL category IDs to the custom URL signature library.

When the APA card receives a user packet, it can extract the URL information from the application layer information of the packet. By comparing the URL in the packet with the URL-URL category ID mappings in the custom URL signature library, the APA card can assign the matching URL category ID to the packet and process the packet based on that ID.

URL category IDs include the following types:

· Minor category ID (sort ID)—Finely categorizes URLs. One minor category ID can identify multiple URLs.

· Major category ID (sort ID)—Broadly categorizes URLs. One major category ID can identify multiple URLs.

Typically, a URL collection identified by one major category ID can contain multiple URL collections identified by different minor category IDs. A URL collection with the same minor category ID cannot belong to URL collections with different major category IDs.

Restrictions and guidelines

For URLs, you can perform either exact match or fuzzy match.

· Exact match—For the URL information carried in the application layer information of the packets to match, it must be exactly the same as the URL specified by using the sa-ctl sort-url command.

· Fuzzy match—For the URL information carried in the application layer information of the packets to match, it only needs to contain the URL specified by using the sa-ctl sort-url command.

When you execute the sa-ctl sort-url command, the same major category ID can be associated with multiple different minor category IDs, and the same minor category ID can be associated with multiple different match rule IDs. However, the same rule ID cannot be associated with multiple minor category IDs, and the same minor category ID cannot be associated with multiple major category IDs.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Configure the mappings between URLs and URL category IDs in the custom URL signature library.

sa-ctl sort-url major-sort-id major-sort-id minor-sort-id minor-sort-id rule-id rule-id url [ exact-match ]

4. Set the name for a URL category ID in the custom URL signature library.

sa-ctl sort-url { major-sort-id major-sort-id | minor-sort-id minor-sort-id } name name

5. Submit the custom URL signature library configuration.

sa-ctl sort-url submit

By default, the custom URL signature library configuration does not take effect immediately.

Setting the upper limit on the packet count for determining whether packets match an SA user policy

About this task

Use this feature mainly for testing and debugging. As a best practice, do not adjust the upper limit.

After the user service traffic is identified and analyzed by an APA card, the user service traffic is sent to the CPU of the APA card for processing. The CPU generates a flow table to guide traffic forwarding. The process and types for generating forwarding flow tables are as follows:

1. The CPU compares the traffic's ID (app ID or URL category ID) with the app IDs or URL category IDs specified in the SA user policies associated with the user.

¡ If the ID of multiple packets matches the app IDs or URL category IDs in an associated SA user policy, the traffic is considered to match the SA user policy. The CPU then generates a special forwarding flow table based on the SA user policy.

¡ If the ID of multiple consecutive packets does not match the app IDs or URL category IDs in an SA user policy, the traffic is considered not matching the SA user policy, and the CPU generates a common forwarding flow table.

2. Regardless of whether the SA user policy is matched, subsequent packets are directly fast forwarded based on the forwarding flow table without being sent to the CPU for comparison and processing.

Use the sa match-packet max-number command to set the upper limit on the packet count for determining whether packets match an SA user policy. If the number of packets that does not match the SA user policy exceeds the upper limit, then the traffic is considered not matching the SA user policy.

Procedure

1. Enter system view.

system-view

2. Create an SA node and enter its view.

sa node node-id

3. Set the upper limit on the packet count for determining whether packets match an SA user policy.

sa match-packet max-number number

By default, the upper limit on the packet count for determining whether packets match an SA user policy is 8.

Display and maintenance commands for iBRAS service awareness

Execute the display commands in any view and reset commands in user view.

Task	Command
Display the global configuration information of SA nodes on the device.	display sa node
Display the port processing mode on the APA module.	display sa port mode
Display SA user policy information.	In standalone mode:‌ display sa user-policy { accelerate \| control \| mirror \| sort-url \| url \| whitelist-url } [ name name ] [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display sa user-policy { accelerate \| control \| mirror \| sort-url \| url \| whitelist-url } [ name name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Display user flow log information reported to the server.	In standalone mode:‌ display sa qoe collector [ collector-id \| load-balance-group group-name ] [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display sa qoe collector [ collector-id \| load-balance-group group-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Display information about online users on APA cards.	In standalone mode:‌ display sa user [ { ipv4 ipv4-address [ mask-length ] \| ipv6 ipv6-address [ prefix-length ] } [ vpn-instance vpn-instance-name ] \| user-name user-name ] [ slot slot-number [ cpu cpu-number ] ] display sa user [ { ipv4 \| ipv6 } \| { all-vpn-instance \| public-instance \| vpn-instance vpn-instance-name } ] * [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display sa user [ { ipv4 ipv4-address [ mask-length ] \| ipv6 ipv6-address [ prefix-length ] } [ vpn-instance vpn-instance-name ] \| user-name user-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] display sa user [ { ipv4 \| ipv6 } \| { all-vpn-instance \| public-instance \| vpn-instance vpn-instance-name } ] * [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Display the online user count statistics for an APA card.	In standalone mode:‌ display sa user count [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display sa user count [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Display information about users with bound SA user policies.	In standalone mode:‌ display sa user policy [ { ipv4 ipv4-address [ mask-length ] \| ipv6 ipv6-address [ prefix-length ] } [ vpn-instance vpn-instance-name ] \| user-name user-name ] [ slot slot-number [ cpu cpu-number ] ] display sa user policy [ { ipv4 \| ipv6 } \| { all-vpn-instance \| public-instance \| vpn-instance vpn-instance-name } ] * [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display sa user policy [ { ipv4 ipv4-address [ mask-length ] \| ipv6 ipv6-address [ prefix-length ] } [ vpn-instance vpn-instance-name ] \| user-name user-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] display sa user policy [ { ipv4 \| ipv6 } \| { all-vpn-instance \| public-instance \| vpn-instance vpn-instance-name } ] * [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Display the redirecting policy for traffic of the specified application.	display sa redirect app-id [ app-id ]
Display the monitor ports or monitoring groups for mirroring groups.	display sa mirroring-group [ group-id ]
Display the version of the current predefined signature library.	In standalone mode:‌ display sa signature { application \| url } version [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display sa signature { application \| url } version [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Display information about the custom application signature library.	display sa custom-app [ [ major-id \| minor-id ] [ verbose ] ]
Display information about the custom URL signature library.	display sa sort-url [ major-sort-id major-sort-id \| minor-sort-id minor-sort-id ]

iBRAS SA configuration examples

Example: Configuring iBRAS SA (without the iBRAS SA backend)

Network configuration

As shown in Figure 4, an APA card is installed and deployed on the BRAS, but the iBRAS SA backend has not been deployed. You can simulate the basic functions of iBRAS SA based on this configuration example. On the BRAS, you can configure various SA user policies for online users to process different types of service traffic of these users.

· Ensure game traffic quality—Configure the custom application signature library to identify traffic of the specific game. Configure an SA user policy with app ID-based traffic acceleration to redirect the traffic to an SRv6 TE policy tunnel, which forwards the game traffic to the POP node through a dedicated fast channel.

· Analyze user service quality in real time—Configure the custom application signature library to identify test traffic of users. Configure an SA user policy with app ID-based traffic mirroring to forward the test traffic with the specified app ID to the specified monitor port. The BRAS directly connects to the probe device in the edge data center through Ten-GigabitEthernet 3/1/2, allowing the probe device to analyze the service quality of the mirrored test traffic in real time.

· Limit access to malicious URLs—Configure an SA user policy with URL-based traffic control to redirect traffic accessing malicious URLs to the specified URL.

Figure 4 Network diagram

‌

Table 1 Interface label and interface name mappings

Interface label	Interface name
Interface1	Ten-GigabitEthernet3/1/1
Interface2	Ten-GigabitEthernet3/1/2

Procedure

1. Configure access authentication and an SRv6 TE policy tunnel on the BRAS. Make sure access users can come online normally and the SRv6 TE policy tunnel from the BRAS to the POP node operates correctly. (Details not shown.)

2. Configure the basic functions of iBRAS SA.

# Direct the received traffic to an APA card for processing, and set the processing mode to inline for the APA card.

<BRAS> system-view

[BRAS] sa port mode inline interface ten-gigabitethernet 3/1/1

# Create SA node 10.

[BRAS] sa node 10

[BRAS-sa-node-10] quit

3. Configure the app ID-based traffic acceleration feature of iBRAS SA:

# Configure the custom application signature library in SA node view to identify user game traffic, and assign major ID 201 and minor ID 2010 to the game traffic. Configure the application name as GameABC for the game traffic with minor ID 2010. After configuring the match rules, submit the custom application signature library configuration.

[BRAS] sa node 10

[BRAS-sa-node-10] sa-ctl custom-app major-id 201 minor-id 2010 rule-id 10 destination-ip 2.3.4.5 destination-port 3074 udp

[BRAS-sa-node-10] sa-ctl custom-app major-id 201 minor-id 2010 rule-id 20 destination-ip 2.3.4.5 destination-port 3074 tcp

[BRAS-sa-node-10] sa-ctl custom-app major-id 201 minor-id 2010 rule-id 30 http-payload

'GameABC' domain-name GameABC.com

[BRAS-sa-node-10] sa-ctl custom-app minor-id 2010 name GameABC

[BRAS-sa-node-10] sa-ctl custom-app submit

# Create an SA user policy named ForGameABC for app ID-based traffic acceleration, and add minor ID 2010 in the SA user policy.

[BRAS-sa-node-10] sa-ctl accelerate-policy add ForGameABC app-id 2010

[BRAS-sa-node-10] quit

# Redirect game traffic with minor ID 2010 to the specified SRv6 TE policy tunnel. For this tunnel, the ingress node is the BRAS, and the destination address is loopback interface address 100::100 on the POP node. The Color attribute value of the SRv6 TE policy is 100, and the End.DT46 SID of the VPN on the POP node is 2000::2.

[BRAS] sa app-id 2010 redirect srv6-policy 100::100 100 sid 2000::2

4. Configure the app ID-based traffic mirroring feature of iBRAS SA:

# Configure the custom application signature library in SA node view to identify the test traffic of users, and assign major ID 202 and minor ID 2020 to the test traffic. Configure the application name as Test for the test traffic with minor ID 2020. After configuring the match rules, submit the custom application signature library configuration.

[BRAS] sa node 10

[BRAS-sa-node-10] sa-ctl custom-app major-id 202 minor-id 2020 rule-id 10 source-ip 1.1.1.1 destination-ip 2.2.2.2 source-port 65530 destination-port 65530 udp

[BRAS-sa-node-10] sa-ctl custom-app minor-id 2020 name Test

[BRAS-sa-node-10] sa-ctl custom-app submit

# Create an SA user policy named ForMonitor for app ID-based traffic mirroring and associate app ID 2020 with mirroring group 10 in the SA user policy.

[BRAS-sa-node-10] sa-ctl mirror-policy add ForMonitor app-id 2020 inbound 10

[BRAS-sa-node-10] quit

# Copy traffic with the app ID associated with mirroring group 10 to monitor port Ten-GigabitEthernet 3/1/2, which forwards the traffic to the directly connected probe device.

[BRAS] sa mirror-group 10 mirror-to interface ten-gigabitethernet 3/1/2

5. Configure the app ID-based traffic control feature of iBRAS SA:

# Create an SA user policy named RedirectURL for URL-based traffic control and add URL example.com to the SA user policy. Redirect traffic accessing this URL to the specified URL of the carrier.

[BRAS] sa node 10

[BRAS-sa-node-10] sa-ctl url-policy add RedirectURL url example.com action redirect exact-match

# Redirect traffic to URL example1.com.

[BRAS-sa-node-10] sa redirect-url https://www.example1.com

6. Because no iBRAS SA backend exists in this example, simulate user online events and deploy SA user policies to users directly on the BRAS.

# Bulk bring 100 users online, and specify their IP addresses. Deploy SA user policy ForGameABC for app ID-based traffic acceleration, SA user policy ForMonitor for app ID-based traffic mirroring, and SA user policy RedirectURL for URL-based traffic control to the online users.

[BRAS-sa-node-10] sa-ctl user online 192.168.1.2 batch 100 accelerate-policy ForGameABC mirror-policy ForMonitor url-policy RedirectURL

Verifying the configuration

# On the BRAS, view the configured SA user policies. Verify that the displayed SA user policies include SA user policy ForGameABC for app ID-based traffic acceleration, SA user policy ForMonitor for app ID-based traffic mirroring, and SA user policy RedirectURL for URL-based traffic control.

<BRAS> display sa user-policy accelerate

Accelerate policy : ForGameABC Create time : 2024-04-15 20:17:22

Referenced times : 100 Rule number : 1

APP ID : 2010 Major : F

<BRAS> display sa user-policy mirror

Mirror policy : ForMonitor Create time : 2024-04-15 20:17:22

Referenced times : 100 Rule number : 1

APP ID : 2020 Major : F

Inbound mirror : 10 Outbound mirror : -

<BRAS> display sa user-policy url

URL policy : RedirectURL Create time : 2024-04-15 20:17:22

Referenced times : 100 Rule number : 1

URL : example.com

Action : Redirect Exactmatch : Y

# View the SA user policies deployed to all online users on the BRAS.

<BRAS> display sa user

Total user number : 100

PCDN user number : 0

User address : 192.168.1.2

VPN instance : -

User name : -

Accelerate policy : ForGameABC

APP ID : 2010

Mirror policy : ForMonitorr

APP ID : 2020

Inbound mirror : 10 Outbound mirror : -

URL policy : Url

URL : example.com

Action : Redirect Exactmatch : Y

…

17-BRAS Services Configuration Guide

Network for the iBRAS SA solution

iBRAS SA tasks at a glance

Creating an SA node

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

Restrictions and guidelines

Procedure

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

Configuring user online/offline events and binding users to SA user policies

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

Display and maintenance commands for iBRAS service awareness

Network configuration

Procedure

Verifying the configuration

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us