Cisco SCE8000 GBE Software Configuration Guide, Release 4.1.x

VAS Service Goals

The VAS traffic forwarding functionality enables the Service Control solution to meet several important service goals:

• Service providers can provide a range of value-added services to their subscribers, thus increasing customer satisfaction.
• The SCE platform can forward part of the traffic to third-party devices that can provide additional, complementary services.

The SCE platform, due to its strong classification capabilities, forwards only the part of the traffic that should get the additional service based on:

– Subscriber awareness

– Policy that was configured

• The Service Control solution can include value-added servers that cannot be deployed inline for various reasons (for example, they cannot support throughput or are not carrier grade for inline insertion).
• Easy interoperability and flexibility for setting different services.

Because the VAS feature emulates a regular IP network for the third-party devices, no special support is required on the part of the third-party entity.

Requirements for VAS Servers

Because VAS devices are installed behind the Cisco SCE platform, they should follow the network behavior of the Cisco SCE platform. Therefore, VAS devices must meet the following three requirements:

• VAS devices must be equipped with separate interfaces for the subscriber side and the network side.
• Traffic towards the subscribers should be sent from the subscriber interface; traffic should be sent from the network interface to the Internet.
• VAS devices must be transparent in Layer 2. The VAS servers must act like Layer 2 switches in that they are not allowed to change traffic headers or to generate new traffic..

Layer 2 Transparency

To handle non-management traffic of VAS services, follow these guidelines:

• The VAS services should work in promiscuous-mode in Layer 2 and accept packets with any destination MAC address.
• When forwarding traffic back to the network after processing, the VAS devices must preserve the original Layer 2 headers containing the MAC addresses and the VLAN tag. The VAS devices must not change the MAC addresses (destination or source) or the VLAN tags. The following restrictions apply to the injected traffic:

– The VAS device is not permitted to initiate new flows.

– New traffic can be injected only in the context of an existing flow.

– When injecting traffic, the Layer 2 information (MAC addresses, VLAN tags, and the TCP/IP parameters) must be taken from the flow into which the traffic is being injected.

• A VAS device must not generate its own network transactions or relay such transactions. Network transactions such as ARP requests or pings are not permitted.

VAS Management Traffic

VAS devices that are managed inband (through the traffic interface) must meet the following requirements:

• Management traffic should either be carried over a dedicated VLAN or without any VLAN header.
• The switches that are connected to the VAS devices should be directly connected to the POP router.
• The switches that are connected to the VAS devices should be configured so that management traffic is sent directly to the router and not through the SCE platform.

VAS Traffic Forwarding and Cisco SCA BB

When VAS traffic forwarding is enabled, in addition to all its basic functions, the SCA BB application classifies each flow as either a VAS flow or as a standard flow (non-VAS flow). This classification is made on the first packet of the flow (for example, TCP SYN packet). The classification must be performed on the very first packet because the classification is used to select the routing of the packet to a VAS server or to the subscriber or network.

The VAS traffic forwarding rules table is configured using the SCA BB console. These rules map certain traffic to the VAS server groups. When a flow is classified as a VAS flow, the VAS server group for this flow is selected. If the group includes more than one VAS server, traffic is forwarded so that the subscriber load is shared between the servers on the same group.

The mapping of traffic portions per package to VAS server groups is also done using the SCA BB console.

VLAN Tags for VAS Traffic Forwarding

The traffic is routed between the SCE platform and the VAS servers by VLANs. There is a unique VLAN tag for each SCE platform and VAS server combination.

Before the traffic is forwarded to the VAS servers, the SCE platform adds the VLAN tags to the original traffic. When the traffic returns to the SCE platform, the SCE platform removes the VLAN tag it previously added, and then forwards the traffic on its original link.

The VLAN tag for each VAS server is user-configured. To preserve consistency of the traffic flow, the VAS feature requires a unique VLAN tag be configured for each SCE platform and VAS server combination.

The VLAN tag has 12 bits, divided as follows:

• The lower six bits identify the VAS server.
• The higher six bits identify the SCE platform.

For example, 0x171 = 1011 10001 = SCE 11, VAS 17

Observe the following for the six bits that identify the SCE platform:

• These six bits must be the same for all VAS servers attached to a specific SCE platform.
• These six bits must be different for VAS servers attached to different SCE platforms.

The SCE platform enforces that the user-configured VLAN tags retain this format, that is, the lower bits match the VAS server number for which the VLAN tag is configured and the higher bits match the higher bits previously configured for other VAS servers on this SCE platform. However, the SCE platform cannot determine the configuration of other SCE platforms, and therefore, it is important that the configured SCE ID (higher bits) be unique for each SCE platform.

The use of VLAN tags is an integral part of the VAS feature, and therefore, requires that the VAS device be able to work in 802.1q trunk while preserving the VLAN information.

Service Flow

The SCE platform classifies a flow to a VAS server group based on the subscriber package and the TCP/UDP ports of the flow. It then selects one server within this group to handle the flow.

The SCE platform performs load sharing between multiple VAS servers belonging to the same server group; the balance is based on the subscriber load. In other words, the SCE platform ensures that the subscribers are evenly distributed between the VAS servers in the same group.The mapping of subscriber to a VAS server (per group) is maintained even when servers are added or removed from the group either due to configuration changes or changes in the operational status of the servers in the group. The mapping changes only if the same server changes its status.

The following sections explain in more detail when and how the mapping is changed:

• Non-VAS Data Flow
• VAS Data Flow

Data Flow

In a deployment using VAS traffic forwarding, there are two types of data flows:

• Non-VAS flow
• VAS flow

Figure 14-2 depicts the two types of data flows running through a single SCE platform and a single VAS server.

• Ports are illustrated as two unidirectional half ports, RX (on the left side) and TX (on the right side):

– The SCE platform has four ports.

– The VAS server has two ports.

• For the sake of illustration, the SCE platform traffic flow direction is from left to right while the VAS traffic flow is from right to left. The arrow below the name of the element indicates the traffic flow direction.
• The Ethernet switches are omitted.
• Each line represents a flow:

– Thick line is a non-VAS flow.

– Thin line is a VAS flow.

– Black line indicates part of a flow that does not have VLAN tag

– Red line indicates part of a flow that has a VLAN tag

Figure 14-2 illustrates the data flow from the subscriber to the network. Data flow from the network to the subscriber works in the same way, but is received on the network port (N) and transmitted on the subscriber port (S).

Figure 14-2 Data Flow in a VAS System

Non-VAS Data Flow

The data flow steps for a non-VAS flow are:

1. A subscriber packet is received at the SCE platform Port 1 (S).

2. The SCE platform classifies the flow as non-VAS flow.

3. The packet is sent to the network on Port 2 (N).

VAS Data Flow

A VAS data flow is slightly more complex than the basic data flow. It is received and transmitted in the same manner as the basic non-VAS SCE platform flow, but before it is transmitted to its original destination, it flows through the VAS server.

The data flow steps for a VAS flow are:

1. A subscriber packet is received at the SCE platform Port 1 (S).

2. The SCE platform classifies the flow as a VAS flow.

3. The SCE platform adds a VLAN tag to the packet.

4. The VLAN tag is used by the Ethernet switch to route the packet to the proper VAS server.

The packet now has a VLAN tag, which is indicated by the red line.

5. The packet is sent to the VAS subscriber port from SCE platform Port 4 (N).

6. The VAS server processes the packets and either drops the packet or sends it back to the SCE platform from the VAS network port to the SCE platform subscribers Port 3 (S).

The VAS server passes the VLAN tag transparently. This is important to enable the Ethernet switch (not shown) to route the packet back to the proper SCE platform.

7. The SCE platform receives the packet on Port 3 (S), drops the VLAN tag, and passes the packet towards the network through Port 2 (N).

Note In order to be able to use VAS, at least four interfaces should be active on the Cisco SCE device.

Load Balancing

VAS servers can be grouped logically according to their service type. Consider, for example, a system that requires both FTP caching and virus filtering. A single VAS server for each service might not have enough capacity. For example, assume that the system requires five VAS servers, three to provide FTP caching, and two to provide virus filtering. Defining two VAS server groups, for example, FTP caching and virus filtering, permits load sharing across the servers for each server group.

The subscriber package determines the VAS server group to which the flow should be attached. The selection of a specific VAS server from the VAS servers within the group is based on the current load on each VAS server. The system tries to create an equal subscriber load for all the VAS servers belonging to the same group.

In some cases, a single VAS server may be used by more than one SCE platform. Remember that the SCE platform performs load balancing only on the traffic that it sends to the VAS server; it receives no information regarding the load the VAS server may be bearing from a different SCE platform. It is vital to properly allocate available VAS servers to the SCE platforms to ensure a balanced load on each VAS server.

Load Balancing and Subscribers

The system balances the usage of the VAS servers within a VAS server group, trying to create an equal subscriber load for all the VAS servers in one VAS server group. The load balancing is subscriber based, that is, the subscribers are evenly distributed between the servers.

VAS load sharing is subscriber based rather than bandwidth based to ensure that all the traffic of the subscriber gets to the same server so that the server can make subscriber-based decisions.

The SCE platform uses the same VAS server for all the traffic of a subscriber (per server group) even if there is a change in the number of active servers in the group. Traffic from a subscriber is assigned to a new server only if the current server becomes inactive. This applies only on new flows. Flows that were already mapped to a server before it became active remain attached to it.

The mapping of subscriber to VAS servers is not saved across subscriber logouts or SCE platform reload.

Load Balancing and Subscriber Mode

Load balancing is subscriber based, therefore this feature does not work properly in subscriberless mode, because the entire traffic load would be carried by only one VAS server per group.

Tip Use anonymous mode rather than subscriberless mode with VAS traffic forwarding.

In pull mode, the first flow of the subscriber behaves as configured in the anonymous template. If no anonymous template is configured, such first flows are processed as defined by the default template. Therefore, the default template should provide a proper package, so these flows get VAS service.

VAS Server Failure

The system monitors the health of a VAS server by periodically checking the connectivity between the SCE platform and the VAS server. When the SCE platform fails to establish or maintain a connection to the server within a configurable window of time, the server is considered to be in Down state.

When the server is in Down state:

• New logged-in subscribers are distributed between the other active servers in the group.
• Subscribers that are mapped to this server are mapped to a new server if they initiate a new flow.
• The server group may move to a Failure state if the failure caused the number of active servers in the group to go below the minimum number configured.

If the connectivity to the server resumes, the state of the server is changed to Up. The server returns to the list of active servers and continues to serve subscribers that were mapped to it before the failure and have not yet been mapped to a new server during the failure time, as well as new subscribers.

VAS Server Group Failure

For each VAS server group, you can configure:

• The minimum number of active servers necessary.
• The action to take in case the actual number of active servers goes below the configured minimum.

If the minimum number of active servers equals the total number of configured servers, it means there is no redundancy and failure of one server causes the failure of the whole server group.

When the SCE platform detects that the number of active servers within a group is below the configured minimum, it changes the state of the group to Failure. The configured action-on-failure is then applied to all new flows mapped for that VAS server group (existing flows are not affected.)

There are two possible actions when the VAS server group has failed:

• Block —All new flows assigned to the failed VAS server group are blocked by the SCE platform.
• Pass —All new flows assigned to the failed VAS server group are considered as regular non-VAS flows, and are processed without VAS service (that is, they receive SCA BB service but not VAS service).

When the number of active servers is above the minimum and the state of the group is changed to Active again, the configured action-on-failure is no longer applied to the new flows. However, to maintain the coherency of the network, flows that were blocked or passed are not affected by the change in the state of the server group.

Ethernet Switch Failure

The Ethernet switches are a single point of failure in a VAS topology. A complete failure of an Ethernet switch causes all the VAS services to be declared as failed and the configured action (on-failure) is taken for all new VAS flows.

Disabling a VAS Server

A VAS server can be disabled for maintenance via the CLI.

No errors are reported on a disabled VAS server. However, if disabling the server reduces the number of active servers to below the minimum number configured for the group, it brings down the VAS server group because a disabled VAS server is equal to a VAS server in Down state.

Health check is not performed on disabled VAS servers.

VAS Server States

When determining whether a VAS server is active, the system considers the following two parameters:

• User-configured Admin mode—Enabled or disabled
• VAS server state as reported by the health check

Single Cisco SCE Platform, Multiple VAS Servers

In this topology, a single SCE platform forwards VAS traffic to one or more VAS servers through two Ethernet switches (Figure 14-3).

The two Ethernet switches are necessary to avoid a situation in which a single MAC address has two ports or a single VLAN tag has two destinations. Each Ethernet switch should be configured to trunk mode with MAC learning disabled.

Figure 14-3 Single Cisco SCE Platform, Multiple VAS Servers

Data Flow

In a data flow:

1. A subscriber packet is received at Port #1 (Subscriber).

2. The SCE platform opens a flow and classifies the flow as either a non-VAS (blue) flow or as a VAS flow (red).

3. If the flow is non-VAS (blue), the SCE platform passes the packet to the network. The VAS server is not involved in this case.

4. If the flow is a VAS flow (red), the SCE platform selects the VAS server to which the packet should be sent, adds the server VLAN tag to the packet, and transmits the packet on Port #4 (Network).

5. The packet is routed by the Ethernet switch to the VAS server according to its VLAN tag (the port towards the VAS server should be the only port with this VLAN tag allowed).

6. The VAS server processes the packet and either drops or forwards it without changing the VLAN tag.

7. The packet is forwarded by the Ethernet switch to the SCE platform according to its VLAN tag (the port towards the SCE platform should be the only port with this VLAN tag allowed).

8. The SCE platform receives the packet on port #3 (Subscriber), strips the VLAN tag, and forwards the packet to the network via Port #2 (Network).

Multiple Cisco SCE Platforms, Multiple VAS Servers

In this topology, multiple SCE platforms are connected to multiple VAS servers. At least one VAS server receives traffic from more than one SCE platform; if the VAS servers are each in an exclusive relationship to a particular SCE platform, it would simply be several single SCE platform to multiple VAS server topologies grouped together.

In Figure 14-4, the top SCE platform forwards traffic to VAS Server 1 and Server 2, while the bottom SCE platform forwards to VAS Server 2 and Server 3. A unique VLAN tag must designate each SCE-platform-to-VAS-server path. This topology is illustrated with two SCE platforms, but a maximum of 512 SCE platforms is supported (limited by the VLAN tag size).

The two Ethernet switches route the traffic to the VAS servers. The routing is VLAN based. The Ethernet switch should be configured to trunk mode with learning disabled.

The data flow is the same as that for the single SCE platform to multiple VAS servers topology (see “Data Flow” section).

Note The multiple Cisco SCE platforms to multiple VAS servers topology does not support SCE platform redundancy on the cascade ports.

Figure 14-4 Multiple SCE Platforms, Multiple VAS Servers

Incompatible Cisco SCE Platform Features

There are certain SCE platform features that are incompatible with VAS traffic forwarding. Before enabling VAS traffic forwarding, it is the responsibility of the user to make sure that no incompatible features or modes are configured.

There are certain SCE platform features that are incompatible with VAS traffic forwarding. Before you enable VAS traffic forwarding, you must ensure that no incompatible features or modes are configured.

The features and modes listed below cannot coexist with VAS mode:

• Line-card connection modes—receive-only, receive-only-cascade, inline-cascade
• Link mode other than forwarding
• All link encapsulation protocols, including VLAN, MPLS, and L2TP
• Traffic mirroring (see “Intelligent Traffic Mirroring” section)

Note If VAS forwarding is enabled, Cisco SCE devices do not forward VLAN-tagged subscriber traffic received from subscriber side and network side traffic ports to the VAS interface for processing.

VAS Traffic Forwarding and DDoS Processing

VAS traffic forwarding has minor effects on the distributed denial of service (DDoS) mechanisms.

• Specific IP DDoS Attack Detection
• Specific IP Attack Filter

Specific IP DDoS Attack Detection

The specific IP DDoS mechanism uses software counters. The second pass VAS packets do not reach the Service Control Operating System (SCOS), so they are not counted twice.

Network-side packets are handled by the attack-detector in the first pass, when they open a flow, so they are also not counted twice.

Specific IP Attack Filter

The behavior depends on the action configured.

• Report only—VAS is not affected.
• Block—Flow is blocked, no VAS service is provided.
• Bypass—Traffic is bypassed and NO SCA BB or VAS services are provided.

VAS Traffic Forwarding and Bandwidth Management

The complexity of the VAS traffic forwarding results in the modification of some SCE platform bandwidth management capabilities:

• VAS flows are not subject to global bandwidth control.
• The number of global controllers available to regular flows is decreased from 64 to 48.

Global Controllers and VAS Flows

When VAS traffic forwarding is enabled, the global controllers function slightly differently:

• Only 48 global controllers are available.
• Global controllers 49 to 63 are used to count VAS traffic.
• Reserved global controllers cannot be configured.
• VAS flows do not get the global controller from the traffic controller to which they belong. Rather, the global controller is set according to VAS rules.

Configuring VAS Traffic Forwarding from the Cisco SCA BB Console

Configuration of the VAS Traffic Forwarding solution is distributed between the SCA BB console and the SCE platform CLI:

• SCE platform CLI configuration:

– Physical VAS server parameters—VLAN tag, Admin status and health check parameters

– VAS server groups parameters—the VAS servers that belong to the group and the action to take if the group enters a failure state

• SCA BB console configuration—the traffic forwarding rules, meaning which portion of the subscriber traffic should be forwarded to the VAS servers.

This configuration is defined per package so different subscribers can receive different VAS service, based on the package they bought.

Global Options

There are two global VAS traffic forwarding options:

• Enable or disable VAS traffic forwarding
• Configure the link number on which to transmit VAS traffic (necessary only if the VAS servers are connected on Link 0, rather than Link 1, which is the default VAS traffic link))

Enabling VAS Traffic Forwarding

By default, VAS traffic forwarding is disabled. If VAS traffic forwarding is required, you must enable it both from your SCE device and the SCABB console.

For instructions on how to disable VAS traffic forwarding, see “Disabling VAS Traffic Forwarding” section.

There are certain other SCE platform features that are incompatible with VAS traffic forwarding. Before enabling VAS traffic forwarding, make sure that no incompatible features or modes are configured.

The features and modes listed below cannot coexist with VAS mode:

• Line-card connection modes—receive-only, receive-only-cascade, inline-cascade
• Link mode other than forwarding
• All link encapsulation protocols, including VLAN, MPLS, L2TP
• Enhanced open flow mode

Options

The following options are available:

• Enable/disable— Enable or disable VAS traffic forwarding

– Default—Disable

From the SCE(config if)# prompt, type:

Disabling VAS Traffic Forwarding

Disabling the VAS Traffic Forwarding feature in runtime must be done with special care. There are two points to consider:

• You cannot disable VAS mode in the SCE platform while the applied SCA BB policy instructs the SCE platform to forward traffic to the VAS servers.

Therefore, you must dismiss all VAS Traffic forwarding rules in the applied SCA BB policy before disabling the VAS traffic forwarding in the SCE platform.

• After the SCA BB has been reconfigured, there may still be some open flows that have already been forwarded to the VAS servers. If the VAS feature is stopped while there are still such flows open, their packets coming back from the VAS servers may be routed to their original destination with the VLAN tag of the VAS server on it.

Therefore, it is also highly recommended to shutdown the line card before you disable the VAS traffic forwarding in the SCE platform to avoid inconsistency with flows that were already forwarded to the VAS servers.

Step 1 From the SCA BB console, remove all the VAS table associations to packages and apply the changed policy.

Step 2 From the SCE(config if)# prompt, type shutdown and press Enter.

Shuts down the line card.

Step 3 From the SCE(config if)# prompt, type no VAS-traffic-forwarding and press Enter.

Disables VAS traffic forwarding.

Step 4 From the SCE(config if)# prompt, type no shutdown and press Enter.

Re-enables the line card.

Configuring the VAS Traffic Link

By default, the VAS traffic is transmitted on Link 1. If the VAS servers are connected on Link 0, you must configure the VAS traffic link to Link 0.

Note The VAS traffic link should be in Forwarding mode.

Options

The following option is available:

• VAS traffic-link {link-0|link-1}— The link number on which to transmit VAS traffic

– Default—Link 1

How to Select the Link for VAS Traffic

From the SCE(config if)# prompt, type:

How to Revert to the Default Link for VAS Traffic

From the SCE(config if)# prompt, type:

Configuring a VAS Server

You must define the VAS servers. Each VAS server has the following parameters:

• Admin-mode—Enabled or disabled.
• Health check mode—Enabled or disabled
• Health check ports
• VLAN tag

Use the commands in this section to perform these operations for individual VAS servers:

• Enable a specified VAS server
• Disable a specified VAS server
• Define the VLAN tag for a specified VAS server
• Enable or disable the health check for a VAS server
• Define the source and destination ports to use for the health check.
• Delete all properties for a specified VAS server. The server returns to the default state, which is enabled. However, it is not operational since it does not have VLAN.

Note A VAS server is not operational until the VLAN tag is defined, even if the server itself is enabled.

Options

The following option is available:

• number —The number of the VAS server.

How to Enable a VAS Server

Note The server is not operational until a VLAN tag has also been defined

From the SCE(config if)# prompt, type:

How to Disable a VAS Server

From the SCE(config if)# prompt, type:

How to Restore All VAS Server Properties to Default

From the SCE(config if)# prompt, type:

Assigning a VLAN ID to a VAS Server

This section contains the following topics:

• How to Configure the VLAN Tag Number for a Specified VAS Server
• How to Remove the VLAN Tag Number from a Specified VAS Server

Options

The following options are available:

• number —The number of the VAS server.
• vlan-id —The VLAN tag to use for the specified VAS server

The VLAN tag can be redefined as necessary.

– Default—No VLAN.

Note the following important points:

• The VAS server is not operational until the VLAN tag is defined.
• Disabling the server does not remove the VLAN tag number configured to the server.
• The no form of the command (same as the default form of the command), removes the previously configured VLAN tag (no VLAN is the default configuration).

How to Configure the VLAN Tag Number for a Specified VAS Server

From the SCE(config if)# prompt, type:

How to Remove the VLAN Tag Number from a Specified VAS Server

From the SCE(config if)# prompt, type:

Configuring the Health Check

This section explains how to to enable and disable the Health Check, and how to define the ports it should use.

By default, the VAS server health check is enabled, however you may disable it.

The health check will be activated only if all the following conditions are true. If the health check is enabled, the server state will be Down if one or more conditions are not met:

• VAS traffic forwarding mode is enabled.
• Pseudo IPs are configured for the SCE platform traffic ports on the VAS traffic link.
• VAS server is enabled.
• Server has a VLAN tag.
• Health check for the server is enabled.

If the health check of the server is disabled, its operational status depends on the following (requirements for Up state are in parentheses):

• admin status (enable)
• VLAN tag configuration (VLAN tag defined)
• group mapping (assigned to group)

This section contains the following topics:

• How to Enable VAS Server Health Check
• How to Disable VAS Server Health Check
• How to Define the UDP Ports to be Used for Health Check
• How to Remove the UDP Ports Configuration
• Configuring Pseudo IP Addresses for the Health Check Packets

Options

The following options are available:

• number— The ID number of the VAS server for which to enable or disable the health check
• Enable/disable— Enable or disable VAS server health check

– Default—Enable

• UDP ports— Specify the UDP ports to be used for the health check:

– source portnumber— health check source port number

– destination portnumber— health check destination port number

– Default—<63140,63141>used for server #0 through <63154,63155>used for server #7.

How to Enable VAS Server Health Check

From the SCE(config if)# prompt, type:

How to Disable VAS Server Health Check

From the SCE(config if)# prompt, type:

How to Define the UDP Ports to be Used for Health Check

From the SCE(config if)# prompt, type:

How to Remove the UDP Ports Configuration

From the SCE(config if)# prompt, type:

Configuring Pseudo IP Addresses for the Health Check Packets

You should configure source and destination pseudo IP address for the health check packets. The pseudo-ip command allows you to specify a unique IP address to be used by the health check packets.

The pseudo IP address is configured on the interfaces that connect the SCE platform with the VAS servers.

The SCE platform uses the pseudo IP as follows:

• Pseudo IP configured for the subscriber side interface:

– Source IP address for health check packets going in the Upstream direction

– Destination IP address for health check packets going in the Downstream direction

• Pseudo IP configured for the network side interface:

– Source IP address for health check packets going in the Downstream direction

– Destination IP address for health check packets going in the Upstream direction

Note This command is a ROOT level command in the Gigabit Interface Configuration mode.

Options

The following options are available:

• ip-address —IP address to be used (any IP address as long as it is not possible to be found in the network traffic, such as a private IP)

– Default—no IP address

• mask (optional)—Defines the range of IP addresses that can be used by the SCE platform. Note that the SCE platform is not required to reside in this subnet.

– Default—255.255.255.255 (The subnet mask can be set to 255.255.255.255, as the health check mechanism requires only one IP address per interface.)

How to Define the Pseudo IP Address

Use this command to define the pseudo IP address to be used for the health check.

From the SCE(config if)#>prompt, type:

How to Delete the Pseudo IP Address

From the SCE(config if)#>prompt, type:

Configuring a VAS Server Group

You may define up to eight VAS server groups. Each VAS server group has the following parameters:

• Server Group ID
• A list of VAS servers attached to this group.
• Failure detection—minimum number of active servers required for this group so it will be considered to be Active. If the number of active servers goes below this minimum, the group will be in Failure state.
• Failure action—action performed on all new data flows that should be mapped to this Server Group while it is in Failure state.

Options:

– block

– pass

You can perform these operations for a VAS server group:

• Add a VAS server to or remove a VAS server from a specified group.
• Configure the minimum number of active servers for a specified group.
• Configure failure behavior for a specified group.

Adding and Removing Servers

Options

The following options are available:

• group-number— The ID number of the VAS server group
• id-number— The ID number of the VAS server

How to Add a VAS Server to a Specified VAS Server Group

From the SCE(config if)# prompt, type:

How to Remove a VAS Server from a Specified VAS Server Group

From the SCE(config if)# prompt, type:

How to Remove All VAS Servers from a Specified VAS Server Group

Use this command to remove all VAS servers from a specified VAS server group and set all group parameters to the default value.

From the SCE(config if)# prompt, type:

Configuring VAS Server Group Failure Parameters

You can configure these failure parameters for a specified VAS server group:

• Minimum number of active servers—If the number of active servers in the server group goes below this number, the group will be in Failure state
• Failure action—The action to be applied to all new flows mapped to this server group while it is Failure state:

– Block—all new flows assigned to the failed VAS server group will be blocked by the SCE platform.

– Pass—all new flows assigned to the failed VAS server group will be considered as regular non-VAS flows, and will be processed without VAS service.

Options

The following options are available:

• group-number —The ID number of the VAS server group
• minimum-active-servers min-number —The minimum number of active servers required for the specified server group

– Default—1

• failure action —Which of the following actions will be applied to all new flows for the specified server group:

– block

– pass (default)

How to Configure the Minimum Number of Active Servers for a Specified VAS Server Group

From the SCE(config if)# prompt, type:

How to Reset the Minimum Number of Active Servers for a Specified VAS Server Group to the Default

From the SCE(config if)# prompt, type:

How to Configure the Failure Action for a Specified VAS Server Group

From the SCE(config if)# prompt, type:

How to Configure the Failure Action for a Specified VAS Server Group to the Default

From the SCE(config if)# prompt, type:

VAS Configuration Example

How to Display Global VAS Status and Configuration

From the SCE> prompt, type:

Example

How to Display Operational and Configuration Information for a Specific VAS Server Group

From the SCE> prompt, type:

Example

How to Display Operational and Configuration Information for All VAS Server Groups

From the SCE> prompt, type:

How to Display Operational and Configuration Information for a Specific VAS Server

From the SCE> prompt, type:

Example

How to Display Operational and Configuration Information for All VAS Servers

From the SCE> prompt, type:

How to Display the VAS Servers Used by a Specified Subscriber

From the SCE> prompt, type:

How to Display Health Check Counters for a Specified VAS Server

From the SCE> prompt, type:

Example

How to Display Health Check Counters for All VAS Servers

From the SCE> prompt, type:

How to Clear the Health Check Counters for a Specified VAS Server

From the SCE> prompt, type:

How to Clear the Health Check Counters for All VAS Servers

From the SCE> prompt, type:

Using Traffic Mirroring for Behavioral Targeting

Today Internet advertising is being executed by content providers (or publishers) in collaboration with ad networks, which actually handle the syndication of ads from advertisers to web sites. The Cisco Service Control behavioral targeting solution provides the means for service providers to participate in the business of the online advertising. This solution allows the SPs to leverage their information about the subscribers and enables highly targeted advertising.

Based on Deep Packet Inspection (DPI) and subscriber integration, the Cisco SCE 8000 platform filters out only what is relevant for the subscriber profiling. This greatly conserves the resources of the advertising servers, by eliminating the irrelevant web traffic before it even reaches them. This filtered traffic is processed as usual by the SCA BB application along with the rest of the traffic, but in addition a copy of it is passed to an external device which can do offline analysis on the subscriber behavior. The data can then be used for the targeted advertising.

Behavioral Targeting is accomplished using several SCE platform capabilities. This section describes the intelligent traffic mirroring capability, which is one of the features that enable the solution.

Figure 14-5 High Level Overview of a Mirroring-Based Behavioral Targeting Solution

For more information regarding targeted advertising, see the following documents:

• Cisco Service Control Online Advertising Solution Guide: Behavioral Profile Creation Using RDRs
• Cisco Service Control Online Advertising Solution Guide: Behavioral Profile Creation Using Traffic Mirroring

How Traffic Mirroring Works

Traffic mirroring uses the same capabilities as VAS traffic forwarding, but the traffic does not return to the SCE platform.

The following sections explain how traffic mirroring works:

• Traffic Mirroring and Cisco SCA BB
• Mirroring Termination
• Mirroring Exceptions
• Cisco SCE Connectivity
• Traffic Mirroring and Bandwidth Management

Traffic Mirroring and Cisco SCA BB

When traffic mirroring is configured for a certain type of traffic, in addition to all its basic functions, the SCA BB application decides whether each flow is to be mirrored or not, based on L7 classification.

Traffic mirroring rules are configured through the SCA BB console. These rules map the traffic to be mirrored and analyzed to the VAS server groups. When a flow is marked for traffic mirroring, the VAS server group for this flow is selected. If the group includes more than one VAS server, traffic will be forwarded in such a way that the subscriber load is shared between the servers on the same group.

The mapping of traffic portions to VAS server groups is done through the standard SCA BB GUI, this definition is given per package.

Mirroring Termination

Mirroring of a flow can continue until the flow is terminated, or be limited to a certain volume passed over the flow. This enables a huge data reduction on the server side, as well as performance saving in the SCE platform.

An RST packet is sent to the server when the mirroring is stopped due to a stop condition. This is done in order to signal the server that the mirroring has stopped.

The RST packet is sent in the direction of intiator to initatee with the additional VLAN tag.

Mirroring Exceptions

Since the decision to mirror is based on service classification, which can be done on the first payload or after first few packets, the entire TCP handshake is not mirrored.

To save in performance on both sides, zero payload packets are also not mirrored. (note that this type of packets have no real value for offline analysis).

If the VLAN traffic is mirrored, Cisco SCE devices replace the VLAN information from the incoming traffic with the VAS-configured VLAN information before mirroring the traffic on the VAS port.

Mirroring the TCP-Segmented HTTP GET Packets

Traffic mirroring can be enabled for all the TCP-segmented HTTP GET packets if the HTTP port is 80, 8080, or 8081 even if the number of segmented packets are more than two.

By default, mirroring of all the segmented packets is disabled.

Configuring Cisco SCE to Mirror the TCP-Segmented HTTP GET packets

You can configure Cisco SCE to mirror the TCP-segmented HTTP GET packets using the GT_SEG_GET_MIRROR tunable.

To configure Cisco SCE to mirror the TCP segmented HTTP GET packets, from the SCE(config if)# prompt, enter:

Cisco SCE Connectivity

Traffic mirroring is implemented by sending the mirrored packets over a designated VLAN through a predefined link of the SCE platform. The link that has been defined for traffic mirroring can be either used exclusively for this purpose, or it can be one of the traffic ports, in which case the Tx capacity of the link will be shared between the original egress traffic and the mirrored traffic.

The direction of the flow is preserved when mirrored, so traffic that is received on the subscriber interface on either link is sent over a VLAN on the network interface over this predefined link. And traffic that is received on the network interface on either link is sent over a VLAN on the subscriber interface over this predefined link. The mirrored traffic does not return to the SCE platform.

Note Enabling traffic mirroring is expected to impact the SCE performance due to the excessive processing associated with it; the actual figure depending on the amount of the mirrored traffic. It is recommended that you monitor SCE platform performance when enabling this capability.

Figure 14-6 shows an SCE platform using a dedicated link for mirroring (Link 1).

Figure 14-6 Traffic Mirroring on a Dedicated Link

Figure 14-7 shows an SCE platform using traffic ports for mirroring.

Figure 14-7 Traffic Mirroring over Traffic Ports

Traffic Mirroring and Bandwidth Management

In general, the bandwidth management rules to be applied to flows designated for mirroring are not affected by the mirroring decision. However note the following points:

• Bandwidth enforcement applies on the two copies of the flow as if there was only one copy; that is, if the flow should be limited to 50K, then its original copy which is sent to the original destination is limited to 50K, and the copy that is sent to the VAS server is also limited to 50K. This has no effect on the total volume that should be mirrored.
• The mirrored volume is not counted and accounted in the BWM system, and therefore in cases where the mirrored traffic is congesting the link, the system will not be aware of the link congestion and will not know to shrink the BWC.

Configuring Traffic Mirroring

Following is a high-level description of the steps in configuring traffic mirroring:

1. Configure the SCE platform— define the servers and the server groups

2. Configure which traffic goes to which server group using the SCA BB console.

Note Additional traffic mirroring configuration and monitoring options are available from the SCA BB Console. See the “Managing VAS Settings” section in the Cisco Service Control Application for Broadband User Guide.

Note Traffic mirroring is not compatible with regular VAS traffic forwarding.

Traffic mirroring configuration is distributed between the SCA BB console and the SCE platform CLI:

• SCE platform CLI configuration:

There are three broad aspects to traffic mirroring configuration in the SCE platform:

– Configuring the VAS traffic link.

– Configuring the VLAN tag per VAS server.

– Associating servers with server groups.

The health check is not relevant to traffic mirroring, so there is no need to configure anything related to the VAS health check.

• SCA BB console configuration—Configure the traffic mirroring rules, specifying which portion of the subscriber traffic should be mirrored to the VAS servers.

This configuration is defined per package so different subscribers can receive different mirroring service, based on the package they bought.

Monitoring Traffic Mirroring

Use the same commands to monitor traffic mirroring as for regular VAS functionality. (See “Monitoring VAS Traffic Forwarding” section)

Traffic Mirroring: Sample Configuration

Following is a sample illustrating the steps in configuring the SCE 8000 platform for traffic mirroring.