Cisco Service Control Engine Software Configuration Guide, Rel 3.1.6
Value Added Services (VAS) Traffic Forwarding
Downloads: This chapterpdf (PDF - 842.0KB) The complete bookPDF (PDF - 7.0MB) | Feedback

Value Added Services (VAS) Traffic Forwarding

Table Of Contents

Value Added Services (VAS) Traffic Forwarding

Information About VAS Traffic Forwarding

VAS Service Goals

How VAS Traffic Forwarding Works

Requirements for VAS Servers

VAS Traffic Forwarding and SCA BB

VLAN Tags for VAS Traffic Forwarding

Service Flow

Data Flow

Non-VAS Data Flow

VAS Data Flow

Load Balancing

Load Balancing and Subscribers

Load Balancing and Subscriber Mode

VAS Redundancy

VAS Server Failure

VAS Server Group Failure

Ethernet Switch Failure

Disabling a VAS Server

VAS Status and VAS Health Check

VAS Server States

VAS Traffic Forwarding Topologies

Single SCE Platform, Multiple VAS Servers

Data Flow

Multiple SCE Platforms, Multiple VAS Servers

SNMP Support for VAS

Interactions Between VAS Traffic Forwarding and Other SCE Platform Features

Incompatible SCE Platform Features

VAS Traffic Forwarding and DDoS Processing

Specific IP DDoS Attack Detection

Specific IP Attack filter

VAS Traffic Forwarding and Bandwidth Management

Global Controllers and VAS flows

Configuring VAS Traffic Forwarding

Configuring VAS Traffic Forwarding from the SCA BB Console

Global Options

Enabling VAS Traffic Forwarding

Options

Disabling VAS Traffic Forwarding

How to Configure the VAS Traffic Link

Options

How to Select the Link for VAS Traffic

How to Revert to the Default Link for VAS Traffic

How to Configure a VAS Server

Options

How to Enable a VAS Server

How to Disable a VAS Server

How to Restore all VAS Server Properties to Default

How to Assign a VLAN ID to a VAS Server

Options

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

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

How to Configure the Health Check

How to Configure Pseudo IP Addresses for the Health Check Packets

How to Configure a VAS Server Group

About VAS Server Groups

How to Add and Remove Servers

How to Configure VAS Server Group Failure Parameters

How to Monitor VAS Traffic Forwarding

How to Display Global VAS Status and Configuration

Example

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

Example

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

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

Example

How to Display Operational and Configuration Information for All VAS Servers

How to Display the VAS Servers Used by a Specified Subscriber

How to Display Health Check Counters for a Specified VAS Server

Example

How to Display Health Check Counters for All VAS Servers

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

How to Clear the Health Check Counters for All VAS Servers

How to Display Bandwidth per VAS Server and VAS Direction

Example

VAS over 10G

About VAS over 10G

Data Flow in VAS over 10G Topology

VAS Data Flow: To the VAS Server

VAS Data Flow: From the VAS Server

Failover Support

Health Check in VAS over 10G Topology

Configuring VAS over 10G: General Guidelines

Configuring the 7600/6500 for VAS over 10G

How to Configure VAS over 10G

How to Configure the VAS Traffic Link Auto-Select Parameters (VAS over 10G)

How to Configure the Minimum Time between Link Switches

How to Set the Active VAS Link

How to Configure Health Check for VAS over 10G

How to Configure the Health Check IP Address

How to Remove the IP Address Configuration

How to Enable the Health Check for VAS over 10G Topology

Options

How to Enable Health Check Compatibility for VAS over 10G (MGSCP)

How to Remove the Health Check Compatibility Configuration

VAS Over 10G Sample Configuration


Value Added Services (VAS) Traffic Forwarding


This module provides an overview of VAS traffic forwarding, explaining what is it and how it works. It also explains the various procedures for configuring and monitoring the VAS traffic forwarding.

Information About VAS Traffic Forwarding

How VAS Traffic Forwarding Works

VAS Redundancy

VAS Status and VAS Health Check

VAS Traffic Forwarding Topologies

SNMP Support for VAS

Interactions Between VAS Traffic Forwarding and Other SCE Platform Features

Configuring VAS Traffic Forwarding

How to Monitor VAS Traffic Forwarding

VAS over 10G

Information About VAS Traffic Forwarding

This module provides an overview of VAS traffic forwarding, and explains how to configure and monitor VAS traffic forwarding. It also explains how to configure VAS over 10G installations.

With every new SCA BB release, the classification and control of new services is supported. The VAS integration capability enables classification and control of services not currently supported by SCA BB. The concept behind this capability enables the solution to use an external "expert system" for classification and control of the service traffic. Using this capability, the service provider can choose to forward selected flows to an external, third-party solution for per-subscriber value-added functionality. Possible use cases for this functionality would be intrusion detection and content-filtering. These value added services are provided on top of the services and functions of the SCA BB solution.

The VAS feature enables the user to divert a specified part of the traffic streams to an individual VAS server or appliance, or a cluster of them. The diversion is based on the subscriber package, flow type and the availability of the VAS servers. This capability also delivers a load balancing function for even distribution of the load on the various VAS servers.

The solution provides support for multiple VAS service types using different VAS Server Groups. Several servers of the same type can be deployed to increase the total capacity and resiliency.

The SCE platform performs subscriber load sharing between the active servers of the same Server Group. It is able to identify the active servers among the defined servers through a dedicated Health Check mechanism.

There is also a VAS over 10G solution, which is a special case of the Cisco Multi-Gigabit Service Control Platform (MGSCP) solution, supporting only one external 10G link and using a Cisco 6500/7600 Series router as a dispatcher to distribute the external 10G link and as the switch towards the VAS servers

VAS Service Goals

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

Allows service providers to provide a range of Value Added Services to their subscribers, thus increasing customer satisfaction.

Allows the SCE platform to 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

Based on the policy that was configured

Allows the Service Control solution to include Value Added Servers that cannot be deployed inline for various reasons (for example, cannot support throughput or are not carrier grade for inline insertion).

Provides easy interoperability and flexibility for setting different services.

Since the VAS feature emulates a regular IP network for the third party devices, no special support is required on their part.

How VAS Traffic Forwarding Works

Requirements for VAS Servers

VAS Traffic Forwarding and SCA BB

VLAN Tags for VAS Traffic Forwarding

Service Flow

Data Flow

Load Balancing

Subscribers are provisioned to the VAS services as part of the normal provisioning process of new subscribers to 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).

Flows that were classified to a VAS service get the usual SCA BB service, as well as being forwarded to the VAS servers for additional service.

Logically, "VAS engine" is upstream of "SCA engine", meaning upstream traffic is first processed by the SCA BB application, downstream is first processed by the VAS server.

Routing the traffic to the VAS servers is done by using VLAN tags.

Figure 12-1 Typical VAS Traffic Forwarding Installation

157202.jpg

Important information:

A single SCE platform can support up to eight VAS servers.

A maximum of 512 SCE platforms can be connected.

The same VAS server may be used by more than one SCE platform.

The VAS traffic forwarding feature is supported on the SCE 2000 4xGBE platform only.


Note When working in VAS mode, the SCE performance envelope might be up to 50% lower than in normal operation mode. The exact performance envelope is specific to the traffic mix in the customer network and should be sized in advance.


The following sections provide a more detailed description of how VAS traffic forwarding works.

Requirements for VAS Servers

Since the VAS devices are installed behind the SCE platform, they should follow the network behavior of the SCE platform.

The two main guidelines that VAS device should follow are:

They should be equipped with two separate interfaces - subscriber side and network side.

Traffic toward the subscribers should be sent from the subscriber interface and for the Internet from the network interface.

Transparency in layer-2 - This means that the VAS servers act like layer-2 switches from the networking perspective. They are not allowed to change anything in the traffic headers or to generate new traffic on behalf of themselves

Layer-2 Transparency

The following guidelines for handling VAS services non-management traffic:

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 (injecting), the VAS devices must preserve the original layer-2 headers containing the MAC addresses and the VLAN tag. The VAS devices may not change the MAC addresses (destination or source) or the VLAN tags.

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

The VAS device is not permitted to initiate new flows.

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

VAS devices may not generate any network transactions on behalf of themselves or replay 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 management traffic will be sent directly to the router and not through the SCE platform.

VAS Traffic Forwarding and 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 since the classification is used to select the routing of the packet to a VAS server or to the subscriber/network.

VAS traffic forwarding rules are configured through 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 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 GUI, this definition is given per package

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/VAS server combination.

Before being forwarded to the VAS servers, the SCE platform adds the VLAN tag 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 to be used for each VAS server is configured by the user. To preserve consistency of the traffic flow, the VAS solution requires the user to configure a unique VLAN tag for each SCE platform/VAS server combination.

The VLAN tag format is shown in the figure below.

Figure 12-2 VLAN Tag Format

157203.jpg

The VLAN tag has twelve bits, divided as follows:

The VLAN tag has twelve bits, divided as follows:

The lower three bits identify the VAS server.

The higher nine bits identify the SCE platform.

For example:

0x20 = 100 000 = SCE #4, VAS #0

0x21 = 100 001 = SCE #4, VAS #1

0x58 = 1011 000 = SCE #11, VAS #0

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

These nine bits must be the same for all VAS servers attached to a specific SCE platform.

These nine bits must be different for VAS servers attached to different SCE platforms.

Examples of valid VLAN tag ranges for an SCE platform:

0x20, 0x21 - 0x27, but not 0x33

0x58,0x59 - 0x5F, but not 0x26

The SCE platform enforces that the VLAN tags configured by the user keep this format, meaning that the lower three bits match the VAS server number for which the VLAN tag is configured and that the higher nine bits match the higher nine bits previously configured for other VAS servers on this SCE platform. However, the SCE platform is not aware of the configuration of other SCE platforms, and therefore it is the responsibility of the user to configure a unique nine bits (SCE id) for each SCE platform.


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


Service Flow

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

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 subscriber load. In other words, the SCE platform ensures that the subscribers are evenly distributed between the VAS servers in the same group.


Note The mapping of subscriber to a VAS server (per group) is kept even when servers are added or removed from the groupeither due to configuration changes or changes in the operational status of the servers in the group. The mapping will change only if the same server changes its status.


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

Data Flow

Non-VAS Data Flow

VAS Data Flow

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

Non-VAS flow

VAS flow

The following figure depicts the two types of data flows running through a single SCE platform and a single VAS server.

Ports are illustrated as two uni-directional half ports, RX (on the left side) and the 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 left to right while the VAS traffic flow is 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

This figure illustrates the data flow from the subscriber to the network. Data flow from the network to the subscriber works in exactly the same way, but is received on the network port (N) and transmitted on the subscriber port (S).

Figure 12-3 Data Flow in a VAS System

157201.jpg

Non-VAS Data Flow

The flow steps for a non-VAS flow are:

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

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

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

VAS Data Flow

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 flow steps are:

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

The SCE platform classifies the flow as VAS flow.

The SCE platform adds a VLAN tag to the packet.

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


Note At this point the packet has a VLAN tag, which is indicated by the red line.


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

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).


Note 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.


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).

Load Balancing

Load Balancing and Subscribers

Load Balancing and Subscriber Mode

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. Let us say that the system requires five VAS servers, three to provide FTP caching, and two to provide virus filtering. Defining two VAS Server Groups, FTP caching and virus filtering, permits load sharing across the servers for each Server Group.

The VAS Server Group to which the flow should be attached is determined by the package of the subscriber. The selection of a specific VAS server from the VAS servers within this 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 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 is not aware how much of a load the VAS server may be bearing from a different SCE platform. It is the responsibility of the user to allocate available VAS servers to the SCE platforms in a way that ensures proper total 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, meaning that 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 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 will only apply on new flows. Flows that were already mapped to a server before it became active will remain attached to it.

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

Load Balancing and Subscriber Mode

Since the load balancing is subscribers based, this solution will not work properly in subscriberless mode, as the entire traffic load would be carried only by one VAS server per group.


Note 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 will be processed as defined by the default template. Therefore, the default template should provide a proper package, so these flows will get VAS service.

VAS Redundancy

VAS Server Failure

VAS Server Group Failure

Ethernet Switch Failure

Disabling a VAS Server

The services provided by the VAS servers should be highly available. The failure of a single VAS server should not degrade the total system performance and availability. This requirement must be considered when determining the number of VAS servers necessary for each VAS service.

There are two mechanisms by which the system guarantees the performance and availability of the VAS services:

Load sharing — The SCE platform distributes the subscribers between all the active VAS servers within a server group.

Monitoring — The SCE platform monitors connectivity with the VAS servers and handles server failure according to the applied configuration.

In addition to failure of an individual VAS server, a complete VAS Server Group is considered to be failed if a defined minimum number of servers are not active.

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 state of the server is considered to be Down.

The implications of such state are:

New logged-in subscribers will be distributed between the other active servers in the group.

Subscribers that are mapped to this server will be mapped to a new server if they initiate a new flow.

The Server Group may move to a Failure state if this failure caused the number of active servers in the group go below the minimum 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 will continue 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, the user can configure the following:

The minimum number of active servers necessary.

The action to take in case the actual number of active servers goes below this number.


Note If the minimum number equals the total number of configured servers, it means there is no redundancy and failure of one server will cause 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 will then be applied to all new flows mapped for that VAS Server Group (existing flows will not be affected.)

There are two possible actions when the VAS Server Group has failed:

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 (that is, they will get 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 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 the 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) will be 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 will bring down the VAS Server Group since a disabled VAS server is equal to a VAS server in a Down state.

Health check is not performed on disabled VAS servers.

VAS Status and VAS Health Check

To manage the VAS redundancy, the SCE platform needs to know the state of each VAS server. The SCE platform performs periodic health checks for all the configured VAS servers. These checks are the basis for VAS redundancy control; they enable the SCE platform to identify and react to VAS server failure, and to check the connectivity of the SCE platform-VAS server before enabling the server to handle traffic.

The health check is performed over the VAS link, the link that connects the SCE platform with the VAS servers. It validates the traffic flow between the SCE platform and the VAS server in both directions through special health check packets generated by the SCE platform.

The health check mechanism does not require special interaction with the VAS device, since the VAS server does not need to answer the health check packets, only to pass them as they are back to the SCE platform. As long as the packets are received by the SCE platform, the VAS server is considered to be alive. Failing to receive the packets back from the VAS server within a pre-defined time window is considered by the SCE platform as a failure of the VAS server and the server status is changed to Down.

Important information about the health check packets:

They are carried over UDP flows

Their source and destination IP addresses are configurable by the user

IP addresses should be:

Unique to the SCE platform

Addresses that will not be used by the network traffic (such as private IPs)

The SCE platform uses default UDP ports between 63140 and 63155, unless the user has configured different ports for the health check.

The SCE platform adds its own layer 7 data on top of the UDP transport layer. This data is used by the SCE platform to validate the correctness of the packet upon retrieval.

The health check is performed under the following conditions:

VAS mode is enabled

VAS server is enabled

Health Check for the VAS server is enabled

Server has VLAN tag

Pseudo IPs are configured for the GBE interfaces

If the check is enabled, but any one of the conditions is not met, the server state will be Down (the same as if the server did not pass the health check).

To check the connectivity with the VAS server before enabling it to handle traffic, the server should not be assigned to any group.

The health check procedure does not require a special interface with the VAS server, the health check traffic goes through the same network channels as any other VAS traffic. However, there are two assumptions the VAS servers should fulfill:

The VAS server does not drop traffic unless it is specifically configured to do so. Therefore, if the VAS server-SCE platform connectivity is operative, the health check packets should reach the SCE platform safely.

Alternatively, it should be able to configure the VAS server to pass traffic on specific ports (the health check ports).

In case of a failure, the VAS server should drop, not bypass, the traffic (cut the link), so that the SCE platform will be able to identify the failure.

VAS Server States

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

Admin mode as configured by the user — Enabled or disabled

VAS server state as reported by the health check

VAS Traffic Forwarding Topologies

The following sections describe the following VAS traffic forwarding topologies:

Single SCE Platform, Multiple VAS Servers

Multiple SCE Platforms, Multiple VAS Servers

VAS over 10G, which is a special case of Cisco Multi-Gigabit Service Control Platform (MGSCP) solution, supporting only one external 10G link and using a Cisco 6500/7600 Series router as a dispatcher to distribute the external 10G link and as the switch towards the VAS servers.


Note A topology in which a VAS server is directly connected to the SCE platform is not supported. If a topology of a single SCE platform connected to a single VAS server is desired, a switch should still be used between the SCE platform and the VAS server.


Single SCE Platform, Multiple VAS Servers

In this topology, a single SCE platform is forwarding VAS traffic to one or more VAS servers through two Ethernet switches.

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 12-4 Single SCE Platform, Multiple VAS Servers

157199.jpg

Data Flow

The data flow is:

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

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

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.

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).

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).

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

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).

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 SCE Platforms, Multiple VAS Servers

In this topology, multiple SCE platforms are connected to multiple VAS servers.


Note 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/multiple VAS server topologies grouped together.


In the following figure, the top SCE platform forwards traffic to VAS servers 1 and 2, while the bottom SCE platform forwards to VAS servers 2 and 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 previous topology.


Note SCE platform redundancy on the cascade ports is not supported in this topology.


Figure 12-5 Multiple SCE Platforms, Multiple VAS Servers

157198.jpg

SNMP Support for VAS

The following items in the "PCUBE-SE-MIB" proprietary MIB support VAS traffic forwarding:

SCE-MIB object: vasTrafficForwardingGrp SCE-MIB

Object type: vasServersTable - provides information on each VAS server operational status.

SNMP Trap: vasServerOperationalStatusChangeTrap - signifies that the agent entity has detected a change in the operational status of a VAS server.

Interactions Between VAS Traffic Forwarding and Other SCE Platform Features

Incompatible SCE Platform Features

VAS Traffic Forwarding and DDoS Processing

VAS Traffic Forwarding and Bandwidth Management

Incompatible 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.

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

VAS Traffic Forwarding and DDoS Processing

VAS traffic forwarding has minor effects on the 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 software, 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 also are 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 to give.

Bypass - Traffic will be bypassed and NO SCA BB or VAS services are given.

VAS Traffic Forwarding and Bandwidth Management

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

VAS flows are not subject to global bandwidth control.

The number of global controllers available to regular flows has been decreased from 64 to 48.

Certain changes are required in the configuration of the global controllers to support these two restrictions.

Global Controllers and VAS flows

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

Only 48 global controllers are available to the user.

Global controllers 49-63 are used to count VAS traffic.

The reserved global controllers cannot be configured.

On VAS flows, the flow does not get its global controller from the traffic controller to which it belongs. Rather, its global controller is set according to VAS rules.

Configuring VAS Traffic Forwarding

Configuring VAS Traffic Forwarding from the SCA BB Console

Global Options

Enabling VAS Traffic Forwarding

Disabling VAS Traffic Forwarding

How to Configure the VAS Traffic Link

How to Configure a VAS Server

How to Assign a VLAN ID to a VAS Server

How to Configure a VAS Server Group

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

Configuring global VAS traffic forwarding options, such as enabling or disabling VAS traffic forwarding, or specifying the VAS traffic link.

Configuring a VAS server, such as enabling or disabling a specific VAS server, or enabling or disabling the VAS health check for a specified VAS server.

Configuring a VAS server group, such as adding or removing a specific VAS server, configuring the minimum number of active servers per group, or configuring VAS server group failure behavior.


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


Following is a high-level description of the steps in configuring VAS traffic forwarding.

1. Configure the SCE platform— define the servers and the server groups, configure Pseudo IP for the GBE interfaces, and enable VAS mode.

2. Verify the state of the individual VAS servers as well as that of the VAS Server Groups to make sure all are Up (see How to Monitor VAS Traffic Forwarding).

3. Configure which traffic goes to which Server Group through the SCA BB console (see Configuring VAS Traffic Forwarding from the SCA BB Console).

Configuring VAS Traffic Forwarding from the 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, the user must enable it.

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

There are certain other 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.

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


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


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.


How to Configure the VAS Traffic Link

Options

How to Select the Link for VAS Traffic

How to Revert to the Default Link for VAS Traffic

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.

To configure the link for VAS over 10G, see VAS over 10G).


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


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding traffic-link {link-0|link-1} and press Enter.


How to Revert to the Default Link for VAS Traffic


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


How to Configure a VAS Server

Options

How to Enable a VAS Server

How to Disable a VAS Server

How to Restore all VAS Server Properties to Default

The user 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 following commands 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

Use this command to enable a VAS server.


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



Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding VAS server-id number enable and press Enter.


How to Disable a VAS Server


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding VAS server-id number disable and press Enter.


How to Restore all VAS Server Properties to Default


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


How to Assign a VLAN ID to a VAS Server

Use this command to assign the VLAN ID to a specified VAS server.

Options

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

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

How to Configure the Health Check

How to Configure Pseudo IP Addresses for the Health Check Packets

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


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding VAS server-id number VLAN vlan-id and press Enter.


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


Step 1 From the SCE(config if)# prompt, type no VAS-traffic-forwarding VAS server-id number VLAN and press Enter.

You can also use the default form of the command to remove the VLAN tag configuration.

default VAS-traffic-forwarding VAS server-id number VLAN


How to Configure the Health Check

About the Health Check

Options

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

About the Health Check

Use these commands to enable and disable the Health Check, and to define the ports it should use.

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


Note 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 GBE ports on the VAS traffic link

VAS server is enabled

Server has a VLAN tag

Health check for the server is enabled


To configure VAS server health check for VAS over 10G, see also How to Configure Health Check for VAS over 10G.

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)

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 Disable VAS Server Health Check


Step 1 From the SCE(config if)# prompt, type no VAS-traffic-forwarding VAS server-id number health-check and press Enter.


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


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding VAS server-id number health-check UDP ports source portnumber destination portnumber and press Enter.


How to Remove the UDP Ports Configuration


Step 1 From the SCE(config if)# prompt, type no VAS-traffic-forwarding VAS server-id number health-check UDP ports and press Enter.

You can also use the default form of the command to remove the UDP port configuration.

VAS-traffic-forwarding VAS server-id number health-check UDP ports


How to Configure Pseudo IP Addresses for the Health Check Packets

About Pseudo IP Addresses

Options

How to Define the pseudo IP Address

How to Delete the pseudo IP Address

About Pseudo IP Addresses

Use this command to configure source and destination pseudo IP address for the health check packets. This command allows you to specify a unique IP address to be used by the health check packets.

This is a ROOT level command and is available under the GBE configuration interface mode. The interfaces that should be configured are those interfaces which connect the SCE platform with the VAS servers (by default interfaces GBE 0/3 and GBE 0/4).

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 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.


Step 1 From the SCE(config if)#> prompt, type pseudo-ip ip-address [mask] and press Enter.


How to Delete the pseudo IP Address


Step 1 From the SCE(config if)#> prompt, type no pseudo-ip ip-address [mask] and press Enter.


How to Configure a VAS Server Group

About VAS Server Groups

How to Add and Remove Servers

How to Configure VAS Server Group Failure Parameters

About VAS Server Groups

The user 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

Use the following commands to perform these operations for a VAS server group:

Add or remove a VAS server to or from a specified group.

Configure the minimum number of active servers for a specified group.

Configure failure behavior for a specified group.

How to Add and Remove Servers

Use these commands to add and remove servers to or from a specified VAS server group.

Options

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

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

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

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


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding VAS server-group group-number server-id id-number and press Enter.


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


Step 1 From the SCE(config if)# prompt, type no VAS-traffic-forwarding VAS server-group group-number server-id id-number and press Enter.


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 their default value.


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


How to Configure VAS Server Group Failure Parameters

About VAS Server Group Failure Parameters

Options

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

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

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

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

About VAS Server Group Failure Parameters

Use the following commands to configure these failure parameters for the 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


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding VAS server-group group-number failure minimum-active-servers min-number and press Enter.


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


Step 1 From the SCE(config if)# prompt, type default VAS-traffic-forwarding VAS server-group group-number failure minimum-active-servers min-number and press Enter.


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


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding VAS server-group group-number failure action {block | pass} and press Enter.


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

Use this command to revert the failure action configuration for the specified VAS server group to the default value (pass).


Step 1 From the SCE(config if)# prompt, type default VAS-traffic-forwarding VAS server-group group-number failure action and press Enter.


How to Monitor VAS Traffic Forwarding

How to Display Global VAS Status and Configuration

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

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

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

How to Display Operational and Configuration Information for All VAS Servers

How to Display the VAS Servers Used by a Specified Subscriber

How to Display Health Check Counters for a Specified VAS Server

How to Display Health Check Counters for All VAS Servers

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

How to Clear the Health Check Counters for All VAS Servers

How to Display Bandwidth per VAS Server and VAS Direction

Use these commands to display the following information for VAS configuration and operational status summary.

Global VAS status summary — VAS mode, the traffic link used

VAS Server Groups information summary — operational status, number of configured servers, number of current active servers.

This information may be displayed for a specific server group or all server groups

VAS servers information summary — operational status, Health Check operational status, number of subscribers attached to this server.

This information may be displayed for a specific server or all servers

Bandwidth per VAS server and VAS direction (to VAS / from VAS)

VAS health check counters

Sample outputs are included.

How to Display Global VAS Status and Configuration


Step 1 From the SCE> prompt, type show interface linecard 0 VAS-traffic-forwarding and press Enter.


Example

SCE>show interface linecard 0 VAS-traffic-forwarding 
VAS traffic forwarding is enabled 
VAS traffic link configured: Link-1  actual: Link-1

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


Step 1 From the SCE> prompt, type show interface linecard 0 VAS-traffic-forwarding VAS server-group id-number and press Enter.


Example

SCE>show interface linecard 0 VAS-traffic-forwarding VAS server-group 0 
VAS server group 0: 
State: Failure  configured servers: 0   active servers: 0 
minimum active servers required for Active state: 1   failure action: Pass

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


Step 1 From the SCE> prompt, type show interface linecard 0 VAS-traffic-forwarding VAS server-group all and press Enter.


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


Step 1 From the SCE> prompt, type show interface linecard 0 VAS-traffic-forwarding VAS server-id id-number and press Enter.


Example

SCE>show interface linecard 0 VAS-traffic-forwarding VAS server-id 0 
VAS server 0: 
Configured mode: enable   actual mode: enable   VLAN:  520  server group:    3 
State: UP 
Health Check configured mode: enable  status: running 
Health Check source port: 63140  destination port: 63141 
Number of subscribers:       0

How to Display Operational and Configuration Information for All VAS Servers


Step 1 From the SCE> prompt, type show interface linecard 0 VAS-traffic-forwarding VAS server-id all and press Enter.


How to Display the VAS Servers Used by a Specified Subscriber


Step 1 From the SCE> prompt, type show interface linecard 0 subscriber name subscriber-name VAS-servers and press Enter.


How to Display Health Check Counters for a Specified VAS Server


Step 1 From the SCE> prompt, type show interface linecard 0 VAS-traffic-forwarding VAS server-id id-number counters health-check and press Enter.


Example

SCE>show interface linecard 0 VAS-traffic-forwarding VAS server-id 0 
Health Checks statistics for VAS server '0'    Upstream      Downstream 
------------------------------------------------------------------------ 
Flow Index '0' 
----------------- 
Total packets sent                         :       31028  :       31027 : 
Total packets received                     :       31028  :       31027 : 
Good packets received                      :       31028  :       31027 : 
Error packets received                     :           0  :           0 : 
Not handled packets                        :           0  :           0 : 
Average roundtrip (in millisecond)         :           0  :           0 : 
Error packets details                      :              :             : 
---------------------                      :              :             : 
Reordered packets                          :           0  :           0 : 
Bad Length packets                         :           0  :           0 : 
IP Checksum error packets                  :           0  :           0 : 
L4 Checksum error packets                  :           0  :           0 : 
L7 Checksum error packets                  :           0  :           0 : 
Bad VLAN tag packets                       :           0  :           0 : 
Bad Device ID packets                      :           0  :           0 : 
Bad Server ID packets                      :           0  :           0 :

How to Display Health Check Counters for All VAS Servers


Step 1 From the SCE> prompt, type show interface linecard 0 VAS-traffic-forwarding VAS server-id all counters health-check and press Enter.


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


Step 1 From the SCE> prompt, type clear interface linecard 0 VAS-traffic-forwarding VAS server-id id-number counters health-check and press Enter.


How to Clear the Health Check Counters for All VAS Servers


Step 1 From the SCE> prompt, type clear interface linecard 0 VAS-traffic-forwarding VAS server-id all counters health-check and press Enter.


How to Display Bandwidth per VAS Server and VAS Direction


Note The bandwidth presented in this command is measured at the Transmit queues, therefore the first table in the example presents the bandwidth of traffic transmitted towards the VAS servers and the second table presents the bandwidth of traffic transmitted out of the SCE platform after being handled by the VAS servers.


The counting is based on L2 bytes.


Step 1 From the SCE> prompt, type show interface linecard 0 counters VAS-traffic-bandwidth and press Enter.


Example

SCE>show interface linecard 0 counters VAS-traffic-bandwidth 
Traffic sent to VAS processing TxBW [Kbps] (bytes are counted from Layer 2): 
 
Port 1    Port 2    Port 3    Port 4 
--------  --------  --------  -------- 
VAS server id 0:         0         0         0         0 
VAS server id 1:         0         0         0         0 
VAS server id 2:         0         0         0         0 
VAS server id 3:         0         0         0         0 
VAS server id 4:         0         0         0         0 
VAS server id 5:         0         0         0         0 
VAS server id 6:         0         0         0         0 
VAS server id 7:         0         0         0         0 
Traffic after VAS processing TxBW [Kbps] (bytes are counted from Layer 2): 
 
Port 1    Port 2    Port 3    Port 4 
--------  --------  --------  -------- 
VAS server id 0:         0         0         0         0 
VAS server id 1:         0         0         0         0 
VAS server id 2:         0         0         0         0 
VAS server id 3:         0         0         0         0 
VAS server id 4:         0         0         0         0 
VAS server id 5:         0         0         0         0 
VAS server id 6:         0         0         0         0 
VAS server id 7:         0         0         0         0

VAS over 10G

About VAS over 10G

Data Flow in VAS over 10G Topology

Failover Support

Health Check in VAS over 10G Topology

Configuring VAS over 10G: General Guidelines

How to Configure VAS over 10G

How to Configure Health Check for VAS over 10G

How to Enable the Health Check for VAS over 10G Topology

VAS Over 10G Sample Configuration

About VAS over 10G

A specific configuration of VAS traffic forwarding is VAS over 10G using a Cisco 6500/7600 Series router as a dispatcher. The VAS over 10G topology is a specific application of the Cisco Multi-Gigabit Service Control Platform (MGSCP) solution in which only one external 10G link is supported. The 7600 distributes the external 10G link and also functions as the switch for the VAS servers.

VAS functionality is supported over a dual 10G topology only. This topology provides a solution with no single point of failure.

In this topology, there are two external 10G links, each one connected to a separate 7600 platform and VAS server array. Only one set of VAS servers is used at a time, serving the VAS traffic of both 10G links. The other set of VAS servers is reserved for failover in case of either a switch failure or VAS server failure.

The following figure illustrates the VAS over 10G topology.

Figure 12-6 Typical VAS over 10G Topology

157213.jpg

Data Flow in VAS over 10G Topology

VAS Data Flow: To the VAS Server

VAS Data Flow: From the VAS Server

Data flow in the VAS solution over 10G topology depends on the appropriate use of VLAN tags to route the packets through the system, from the 7600/6500 to the SCE platform, to the appropriate VAS server, back to the SCE platform and then back to the network through the 7600/6500.

The following figure illustrates the flow of VAS data in the VAS solution over 10G topology.

Figure 12-7 Data Flow in VAS over 10G Topology


Note The path between the SCE platform and the VAS servers has the same VLAN tag for all SCE platforms in the same EtherChannel.


VAS flows enter the SCE platform without a VLAN tag, and are then transmitted from the SCE platform with the VLAN tag of the VAS server. They must return from the VAS server to the SCE platform with this tag, which is then stripped off.

In the solution using the 7600/6500, VLAN tags are also used to identify the external link.


Note This is not the same VLAN tag used for the VAS servers. This VLAN tag must be defined as native in the trunk ports towards the SCE platforms, so that the external traffic arrives at the SCE platform without a VLAN tag.


In this description of the VAS data flow, note the following important points:

This section describes the data flow of packets originating at the subscriber side of the 10G link and sent towards the network. The network to subscriber flow exactly mirrors this flow.

The description does not elaborate on the internal path inside the 7600/6500 device. It is intended to present the path between the SCE platform, the 7600/6500, and the VAS servers, and describe how the VLAN tag changes along that path.

Although the figures show only one SCE platform, in actuality the VAS over 10G topology would usually consist of multiple SCE platforms on multiple ECs. In such a topology, the ports towards the VAS servers must be trunk ports, which allow the presence of multiple VLAN tags, since there will be a unique VLAN tag for each EC. (As noted previously, all SCE platforms on one EC must use the same VLAN tag per VAS server).

The data flow is presented in two parts:

To the VAS servers

From the VAS servers

The figures assume that the VAS link is link 1.

VAS Data Flow: To the VAS Server

Figure 12-8 Data Flow in VAS over 10G Topology: To the VAS Server

157247.jpg

The following is the sequence of steps in the VAS data flow from the subscriber side to the VAS server:

1. A subscriber packet is received at the 7600/6500 external 10G link.

2. The packet is marked with VLAN 100 at the access port and is sent towards the EtherChannel (EC) configured with VLAN 100.

3. The EC selects port 1 of the SCE platform based on the subscriber side IP, and the VLAN tag is stripped off (100 is the native VLAN tag in the 7600/6500 trunk port).

4. The SCE platform classifies the flow as VAS flow and tags it with the VAS server VLAN tag 505.

5. The packet is sent to the VAS server from SCE platform port 2 (N) towards the 7600/6500 with VLAN tag 505.

6. The packet is received on the 7600/6500 trunk port and is sent to the access port configured with VLAN 505, which is the port connected to the VAS server subscriber side.

The packet has no VLAN tag when it arrives at the VAS server.

VAS Data Flow: From the VAS Server

Figure 12-9 Data Flow in VAS over 10G Topology: From the VAS Server

157246.jpg

The following is the sequence of steps in the VAS data flow from the VAS server out to the network:

1. The VAS server processes the packet and sends it to the SCE platform from the VAS network port.


Note As the VAS server received the packet with no VLAN tag, it also transmits it with no VLAN tag.


2. The packet is received on the 7600/6500 access port, is assigned VLAN tag 525, and is sent towards the EC configured with VLAN 525.

3. At the trunk port, the VLAN tag 525 is translated to VLAN tag 505.

4. The packet is sent towards port 1 of the SCE platform based on the subscriber side IP.

5. SCE platform gets the packet on port 1 (S) and forwards it towards the network through port 2 (N) The SCE platform forwards the packet with NO VLAN tag.

6. The packet is received on the 7600/6500 trunk port, gets the native VLAN 101 and sent towards the access port configured with VLAN 101.

7. The packet is sent towards the network with no VLAN tag.

Failover Support

The SCE monitors the health of the connection to each VAS server on the active VAS link; failure of either the 7600/6500 or the VAS server will cause the server health check to fail. The failure of one or more server groups causes the VAS traffic to be forwarded to the redundant 7600/6500/VAS servers system.

How failover works:

The VAS link (the link on which to send the VAS traffic) is dynamically selected. In failover, the SCE platform switches to its backup subscriber and network ports, so that the VAS traffic is The VAS link does not revert automatically. It will be switched again only if required due to a VAS server group failure on this link.

Refer to Figure 12-7. SCE ports 1 and 2 for each SCE platfrom are the primary interfaces, while ports 3 and 4, connecting to the redundant router and VAS servers, are the backup interfaces.

The system always checks only one set of the VAS servers; those on the active VAS link.

There is a user-configurable parameter that controls the link-switch rate if there has not been a successful health check on the current VAS link. The default value of this parameter is less than the failure detection time. It is recommended to configure a larger value.

Once there is a successful health check on the VAS link, the link switches immediately upon failure (see How to Configure the Minimum Time between Link Switches).

In the VAS over 10G topology, a failure may occur at any of the following three points:

Failure of an SCE platform

SCE platform failure is detected and handled by the 7600/6500 device. In such case, the EtherChannel will balance the traffic load between the other active SCE platforms. SCA BB and VAS service through the other SCE platforms continues uninterrupted with no change in the VAS link.

Failure of a 7600/6500

The 10G link that goes through the failed 7600/6500 device is lost completely, however SCA BB and VAS services on the 10G link that goes through the second 7600/6500 device continue uninterrupted. In case of failure of the 7600/6500 that is connected to the active set of VAS servers, all the VAS traffic of the other 10G link is forwarded to the standby set of VAS servers

Failure of a VAS server group

Failure of a VAS server group on the active VAS traffic link is detected by the VAS health check. Failure of any VAS server group triggers the switch of the entire link to the standby VAS servers. A server group failure is declared when the number of active VAS servers drops below the parameter "minimum active VAS servers in a group" (see How to Configure VAS Server Group Failure Parameters).

Both links preserve SCA BB and VAS services. However, during the transition period, the replacing VAS servers will see VAS flows in the middle and the VAS service may be temporarily damaged.

Health Check in VAS over 10G Topology

In the VAS over 10G topology, special attention must be paid to the selected IP addresses of the health check flows. A flow initiated by an SCE platform may not always be hashed correctly by the EtherChannel. Therefore, a health check packet can be sent out from one SCE platform, go through the 7600/6500 towards the VAS server, then be sent back from the VAS server through the 7600/6500 but hashed by the EtherChannel to a SCE platform different than the originator SCE platform.

To prevent this from happening, the SCE platform opens eight flows per VAS server. This ensures that at least one of the flows will be mapped to the correct SCE platform; the other SCE platforms disregard health check packets not initiated by them.

Configuring VAS over 10G: General Guidelines

When configuring VAS over 10G, the following changes must be made to the configuration process:

Configuration of the VAS traffic link is different (see Configuring the VAS Traffic Link (VAS over 10G))

You must configure a range of IP addresses as the source IP addresses for the health check (see How to Configure the Health Check IP Address).

The health check must be specifically enabled to be compatible with the 10G topology (see How to Enable Health Check Compatibility for VAS over 10G (MGSCP)).


Note The VLAN tags and configuration of the two sets of VAS servers must be identical.



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


Configuring the 7600/6500 for VAS over 10G

This section explains some important points to keep in mind when configuring the 7600/6500 as part of the VAS over 10G solution. For complete information on how to configure the 7600/6500, please refer to the appropriate Cisco documentation.

Please refer to the following guidelines when configuring the 7600/6500 as part of the VAS over 10G solution:

The 7600/6500 device traffic distribution is based on the EtherChannel dispatching function. Specifically it is required that:

External traffic coming from the subscriber side of the 7600/6500 device must be hashed by the EtherChannel according to the source IP

External traffic coming from the network side must be hashed according to the destination IP.

This requirement insures that the same SCE platform handles all the traffic of a subscriber. Since the hashing metric is configurable per line card, the external 10G link subscriber and network ports must be on different line cards. The VAS servers should be connected to the 7600/6500 following this convention as well:

Connect the VAS server subscriber leg to the same line card as the network 10G port, or to a line card that is configured with per destination IP dispatching function.

Connect the VAS server network leg to the same line card as the subscriber 10G port, or to a line card that is configured with per source IP dispatching function.

In order for the native VLAN configuration to be effective, disable the "vlan dot1q tag native" configuration on the 7600/6500.

Introduce the VLAN tags of the VAS servers and the external subscriber and Network ports by running the "vlan XXX" configuration command on the 7600/6500 device.

How to Configure VAS over 10G

How to Configure the VAS Traffic Link Auto-Select Parameters (VAS over 10G)

How to Configure the Minimum Time between Link Switches

How to Set the Active VAS Link

How to Configure the VAS Traffic Link Auto-Select Parameters (VAS over 10G)

How to Configure the Link for VAS over 10G

How to Revert to the Default Link Configuration

To enable switching the VAS traffic automatically upon a failover situation, the following options must be configured for VAS over 10G:

Set the VAS traffic link to auto-select, so that the system can switch between the links in case of 7600/6500/VAS servers failure..

Specify the minimum time allowed between two consecutive link switches before any health check has succeeded.

Specify the link on which to transmit VAS traffic initially after changing the configuration to ` auto-select ' (in runtime or after reload) or the current VAS traffic link if ` auto-select ' is already configured

How to Configure the Link for VAS over 10G

By default, the VAS traffic is transmitted on Link 1. However, for VAS over 10G, the VAS link should be set to auto-select, so that the system can switch to the backup link when necessary.

Options

The following option is available:

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

For VAS over 10G, specify auto-select.


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding traffic-link auto-select and press Enter.


How to Revert to the Default Link Configuration

By default, the VAS traffic is transmitted on Link 1.

Options

The following option is available:

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

For VAS over 10G, specify auto-select.


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


How to Configure the Minimum Time between Link Switches

Options

How to Configure the Delay between Link Switches

How to Revert to the Default Delay Configuration

You can configure the minimum time allowed between two consecutive link switches. This parameter applies only after a link switch and before any health check has succeeded.


Note The system assumes the servers are UP while the health check initializes (initialization occurs as a result of every change in the configuration related to the health check or after a link switch, and it lasts until the first health check success or failure). This means that even if the servers are actually DOWN or not even connected, it is assumed that they are UP and user traffic is forwarded to them. Once the health check fails, the servers are declared to be Down, and user traffic is no longer forwarded to them.


In VAS over 10G topology, the default delay between two consecutive link switches (30 seconds) is less than the time it takes for the health check to fail. This means that once a VAS server group fails, the SCE platform switches immediately to the second link.

In cases where there is at least one failed VAS server group on both links, the SCE platform will flip continuously between the links, and as described above, most of this time the state of the servers will be UP.

To avoid the constant flip between the links in such a case, it is recommended to configure a link-switch-delay time greater than 3 minutes.

It is also recommended to monitor the SNMP traps conveying messages on changes in server status.

Options

The following option is available:

switch-time — The time in seconds to hold between two consecutive link switches on initial health check state.

Default = 30 seconds

How to Configure the Delay between Link Switches


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding traffic-link auto-select link-switch-delay switch-time and press Enter.


How to Revert to the Default Delay Configuration


Step 1 From the SCE(config if)# prompt, type no VAS-traffic-forwarding traffic-link auto-select link-switch-delay and press Enter.

You can also use the default form of the command:

default VAS-traffic-forwarding traffic-link auto-select link-switch-delay


How to Set the Active VAS Link

Options

How to Set the Active VAS Link

How to Revert to the Default Active VAS Link Configuration

Use this command to set the active VAS link, the link on which to transmit VAS traffic after a system reload and when working in auto-select mode.

When executed, this command triggers an immediate link switch if the currently active VAS traffic link used is different from the one specified in the command.

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 Set the Active VAS Link


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding traffic-link auto-select initial-selection {link-0 | link-1} and press Enter.


How to Revert to the Default Active VAS Link Configuration


Step 1 From the SCE(config if)# prompt, type no VAS-traffic-forwarding traffic-link auto-select initial-selection and press Enter.

You can also use the default form of the command:

default VAS-traffic-forwarding traffic-link auto-select initial-selection


How to Configure Health Check for VAS over 10G

How to Configure the Health Check IP Address

How to Remove the IP Address Configuration

When configuring the health check for VAS over 10G, you must perform the following steps:

Configure the health check source and destination IP addresses

Enable health check compatibility for VAS over 10G

How to Configure the Health Check IP Address

About the Health Check IP Address

Options

About the Health Check IP Address

Use this command to configure the IP addresses to be used for the VAS health check flows. Any traffic to the configured IP address will be handled as belonging to health check flows; it will not be processed as usual traffic and will be dropped by the SCE platform.

There are three important rules to follow when configuring the IP addresses of the VAS health check. Improper configuration will cause the health check to fail and may cause health check traffic to be forwarded outside of the 7600/6500.

It is required to configure a range of IP addresses (at least eight IP addresses) for the source IP. This will insure that at least one out of the eight flows will be hashed correctly to the SCE platform. If no range is configured and the VAS over 10G mode (MGSCP) is selected, the health check will fail to run.

The configured IP addresses must be unique to the SCE platforms and should not exist in the network. Any traffic to the configured IP addresses other than VAS health check traffic will be regarded as fault traffic and be dropped by the SCE platform.

All the SCE platforms under the same EtherChannel must have the same IP address configuration. Using the same IP addresses allows the SCE platform to correctly identify health check flows coming from other SCE platforms (as a result of the EtherChannel hashing) and drop these flows before they are transmitted out of the SCE platform

Options

The following options are available:

ip-address — Specify the IP addresses to be used for the health check:

source-ip — health check source IP address The source-ip must include a range indication (A.B.C.D/E or A.B.C.D:0xMASK, where A,B,C,D are numbers between [0,255] and E is in the range [0,32]. MASK is the IP mask in 8 hexadecimal characters.)

dest-ip — health check destination IP address

The configured IP addresses should not be in use in the network.

The same IP address should be used by all the SCE platforms under the same EtherChannel.

Use the no form to remove the configured IP addresses.


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding health-check ip-address source source-ip destination dest-ip and press Enter.


How to Remove the IP Address Configuration


Step 1 From the SCE(config if)# prompt, type no VAS-traffic-forwarding health-check ip-address and press Enter.

You can also use the default form of the command:

default VAS-traffic-forwarding health-check ip-address


How to Enable the Health Check for VAS over 10G Topology

Use this command to configure the health check to adjust to VAS over 10G (MGSCP) conditions (see Health Check in VAS over 10G Topology).

Options

How to Enable Health Check Compatibility for VAS over 10G (MGSCP)

How to Remove the Health Check Compatibility Configuration

Options

The following options are available:

The keyword MGSCP is specified to enable health check compatibility because VAS over 10G is a special case of a MGSCP (Multi-Gigabit Service Control Platform) system.

By default, VAS over 10G compatibility is disabled.

How to Enable Health Check Compatibility for VAS over 10G (MGSCP)


Step 1 From the SCE(config if)# prompt, type VAS-traffic-forwarding health-check topology MGSCP and press Enter.


How to Remove the Health Check Compatibility Configuration


Step 1 From the SCE(config if)# prompt, type no VAS-traffic-forwarding health-check topology MGSCP and press Enter.

You can also use the default form of the command:

default VAS-traffic-forwarding health-check topology MGSCP


VAS Over 10G Sample Configuration

Following is a sample illustrating the steps in configuring the VAS over 10G solution.


Step 1 From the SCE(config)# prompt, type interface linecard 0 and press Enter.

Enter the LineCard Interface configuration mode.

Step 2 From the SCE(config if)# prompt, type VAS-traffic-forwarding health-check topology MGSCP and press Enter.

Set VAS health-check to MGSCP mode.

Step 3 From the SCE(config if)# prompt, type VAS-traffic-forwarding health-check ip-address source 192.168.100.0:0xffffff00 destination 192.168.101.0 and press Enter.

Sets VAS health-check source IP address to the range 192.168.100.0/24 and destination to 192.168.101.0

Step 4 From the SCE(config if)# prompt, type VAS-traffic-forwarding traffic-link auto-select and press Enter.

Sets VAS traffic link to auto-select so in case of a failure in any of the VAS servers group, the VAS traffic link will be automatically switched.

Step 5 From the SCE(config if)# prompt, type VAS-traffic-forwarding traffic-link auto-select link-switch-delay 240 and press Enter.

Configures the link switch delay to 4 minutes. The delay will be applied only if there was no successful health check on the current link.

Step 6 From the SCE(config if)# prompt, type VAS-traffic-forwarding traffic-link auto-select initial-selection link-0 and press Enter.

Sets link-0 to be used as the initial VAS traffic link in auto-select mode.

Step 7 Assign VAS servers 0-3 to VLAN 600-603 respectively.

SCE(config if)#VAS-traffic-forwarding VAS server-id 0 VLAN 600 
SCE(config if)#VAS-traffic-forwarding VAS server-id 1 VLAN 601 
SCE(config if)#VAS-traffic-forwarding VAS server-id 2 VLAN 602 
SCE(config if)#VAS-traffic-forwarding VAS server-id 3 VLAN 603 

Step 8 Map VAS servers 0-1 and 2-3 to server groups 0 and 1 respectively, allowing server redundancy within each group:

SCE(config if)#VAS-traffic-forwarding VAS server-group 0 server-id 0 
SCE(config if)#VAS-traffic-forwarding VAS server-group 0 server-id 1 
SCE(config if)#VAS-traffic-forwarding VAS server-group 1 server-id 2 
SCE(config if)#VAS-traffic-forwarding VAS server-group 1 server-id 3 

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

Sets the SCE platform to forward VAS traffic (enables VAS traffic forwarding).