|
|
Table Of Contents
Value Added Services (VAS) Traffic Forwarding
Information About VAS Traffic Forwarding
How VAS Traffic Forwarding Works
VAS Traffic Forwarding and SCA BB
VLAN Tags for VAS Traffic Forwarding
VAS Status and VAS Health Check
VAS Traffic Forwarding Topologies
Single SCE Platform, Multiple VAS Servers
Multiple SCE Platforms, Multiple VAS Servers
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
Configuring VAS Traffic Forwarding
Configuring VAS Traffic Forwarding from the SCA BB Console
Enabling VAS Traffic Forwarding
Disabling VAS Traffic Forwarding
How to Configure the VAS Traffic Link
How to Assign a VLAN ID to a VAS Server
How to Configure a VAS Server Group
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
Data Flow in VAS over 10G Topology
Health Check in VAS over 10G Topology
Configuring VAS over 10G: General Guidelines
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
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
•
•
•
•
•
•
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:
•
•
The SCE platform, due to its strong classification capabilities, forwards only the part of the traffic that should get the additional service:
–
–
•
•
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
•
•
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
Important information:
•
•
•
•
The following sections provide a more detailed description of the following aspects of VAS traffic forwarding:
•
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
The VLAN tag has twelve bits, divided as follows:
•
–
–
•
•
•
•
Observe the following for the nine bits that identify the SCE platform:
•
•
Examples of valid VLAN tag ranges for an SCE platform:
•
•
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 that 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 that the mapping of subscriber to a VAS server (per group) is kept 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 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
In a deployment using VAS traffic forwarding, there are two types of data flows:
•
•
The following figure depicts the two types of data flows running through a single SCE platform and a single VAS server.
•
–
–
•
•
•
–
–
–
–
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
Non-VAS Data Flow
The flow steps for a non-VAS flow are:
•
•
•
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:
•
•
•
•
Note that at this point the packet has a VLAN tag, which is indicated by the red line.
•
•
Note that 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.
•
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. 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
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
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:
•
•
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:
•
•
•
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:
•
•
Note that 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:
•
•
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:
•
•
IP addresses should be:
–
–
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:
•
•
•
•
•
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:
•
Alternatively, it should be able to configure the VAS server to pass traffic on specific ports (the health check ports).
•
VAS Server States
When determining whether a VAS server is active, the system considers the following two parameters:
•
•
VAS Traffic Forwarding Topologies
The following sections describe the following VAS traffic forwarding topologies:
•
•
•
Note
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
Data Flow
The data flow is:
•
•
•
•
•
•
•
•
Multiple SCE Platforms, Multiple VAS Servers
In this topology, multiple SCE platforms are connected to multiple VAS servers. Note that 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 that SCE platform redundancy on the cascade ports is not supported in this topology.
Figure 12-5 Multiple SCE Platforms, Multiple VAS Servers
SNMP Support for VAS
The following items in the "PCUBE-SE-MIB" proprietary MIB support VAS traffic forwarding:
•
•
•
Interactions Between VAS Traffic Forwarding and Other SCE Platform Features
•
•
•
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:
•
•
•
VAS Traffic Forwarding and DDoS Processing
VAS traffic forwarding has minor effects on the DDoS mechanisms.
•
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.
•
•
•
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:
•
•
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.
•
•
•
•
Configuring VAS Traffic Forwarding
•
•
•
•
•
•
•
There are three broad aspects to VAS traffic forwarding configuration in the SCE platform:
•
•
•
Note
Following is a high-level description of the steps in configuring VAS traffic forwarding.
1.
2.
3.
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:
•
–
–
•
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:
•
•
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:
•
•
•
•
Options
The following options are available:
•
–
Step 1
VAS-traffic-forwardingand 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:
•
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.
•
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.
SUMMARY STEPS
1.
2.
shutdownand press Enter.3.
VAS-traffic-forwardingand press Enter.4.
no shutdownand press Enter.DETAILED STEPS
Step 1
Step 2
shutdownand press Enter.Shuts down the line card.
Step 3
VAS-traffic-forwardingand press Enter.Disables VAS traffic forwarding.
Step 4
no shutdownand press Enter.Re-enables the line card.
How to Configure 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.
To configure the link for VAS over 10G, see VAS over 10G ).
Note
Options
The following option is available:
•
–
How to Select the Link for VAS Traffic
Step 1
VAS-traffic-forwarding traffic-link {link-0|link-1}and press Enter.How to Revert to the Default Link for VAS Traffic
Step 1
no VAS-traffic-forwarding traffic-linkand press Enter.How to Configure a VAS Server
The user must define the VAS servers. Each VAS server has the following parameters:
•
•
•
•
Use the following commands to perform these operations for individual VAS servers:
•
•
•
•
•
•
Note that 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:
•
How to Enable a VAS Server
Use this command to enable a VAS server.
Note
Step 1
VAS-traffic-forwarding VAS server-idnumber enable and press Enter.How to Disable a VAS Server
Step 1
VAS-traffic-forwarding VAS server-idnumber disable and press Enter.How to Restore all VAS Server Properties to Default
Step 1
no VAS-traffic-forwarding VAS server-idnumber 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
The following options are available:
•
•
The VLAN tag can be redefined as necessary.
–
Note the following important points:
•
•
•
How to Configure the VLAN Tag Number for a Specified VAS Server
Step 1
VAS-traffic-forwarding VAS server-idnumber VLAN vlan-idand press Enter.How to Remove the VLAN Tag Number from a Specified VAS Server
Step 1
no VAS-traffic-forwarding VAS server-idnumber 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 numberVLAN
How to Configure the Health Check
•
•
•
•
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 that 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:
•
•
•
•
•
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):
•
•
•
Options
The following options are available:
•
•
–
•
–
–
–
How to Disable VAS Server Health Check
Step 1
no VAS-traffic-forwarding VAS server-idnumber health-check and press Enter.How to Define the UDP Ports to be Used for Health Check
Step 1
VAS-traffic-forwarding VAS server-idnumber health-check UDP ports source portnumber destination portnumber and press Enter.How to Remove the UDP Ports Configuration
Step 1
no VAS-traffic-forwarding VAS server-idnumber 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 numberhealth-check UDP ports
How to Configure Pseudo IP Addresses for the Health Check Packets
•
•
•
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:
•
–
–
•
–
–
Note
Options
The following options are available:
•
–
•
–
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
pseudo-ipip-address [mask] and press Enter.How to Delete the pseudo IP Address
Step 1
no pseudo-ipip-address [mask] and press Enter.How to Configure a VAS Server Group
•
•
About VAS Server Groups
The user may define up to eight VAS server groups. Each VAS server group has the following parameters:
•
•
•
•
Options:
–
–
Use the following commands to perform these operations for a VAS server group:
•
•
•
How to Add and Remove Servers
Use these commands to add and remove servers to or from a specified VAS server group.
•
•
•
•
Options
The following options are available:
•
•
How to Add a VAS Server to a Specified VAS Server Group
Step 1
VAS-traffic-forwarding VAS server-groupgroup-number server-id id-number and press Enter.How to Remove a VAS Server from a Specified VAS Server Group
Step 1
no VAS-traffic-forwarding VAS server-groupgroup-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
no VAS-traffic-forwarding VAS server-groupgroup-number and press Enter.How to Configure VAS Server Group Failure Parameters
•
•
•
•
•
•
About VAS Server Group Failure Parameters
Use the following commands to configure these failure parameters for the specified VAS server group:
•
•
–
–
Options
The following options are available:
•
•
–
•
–
–
How to Configure the Minimum Number of Active Servers for a Specified VAS Server Group
Step 1
VAS-traffic-forwarding VAS server-groupgroup-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
default VAS-traffic-forwarding VAS server-groupgroup-number failure minimum-active-servers min-number and press Enter.How to Configure the Failure Action for a Specified VAS Server Group
Step 1
VAS-traffic-forwarding VAS server-groupgroup-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
default VAS-traffic-forwarding VAS server-groupgroup-number failure action and press Enter.
How to Monitor VAS Traffic Forwarding
•
•
•
•
•
•
•
•
•
•
•
Use these commands to display the following information for VAS configuration and operational status summary.
•
•
This information may be displayed for a specific server group or all server groups
•
This information may be displayed for a specific server or all servers
•
•
Sample outputs are included.
How to Display Global VAS Status and Configuration
Step 1
show interface linecard 0 VAS-traffic-forwardingand press Enter.Example
SCE>show interface linecard 0 VAS-traffic-forwarding VAS traffic forwarding is enabled VAS traffic link configured: Link-1 actual: Link-1How to Display Operational and Configuration Information for a Specific VAS Server Group
Step 1
show interface linecard 0 VAS-traffic-forwarding VAS server-groupid-numberand 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: PassHow to Display Operational and Configuration Information for All VAS Server Groups
Step 1
show interface linecard 0 VAS-traffic-forwarding VAS server-group alland press Enter.How to Display Operational and Configuration Information for a Specific VAS Server
Step 1
show interface linecard 0 VAS-traffic-forwarding VAS server-idid-numberand 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: 0How to Display Operational and Configuration Information for All VAS Servers
Step 1
show interface linecard 0 VAS-traffic-forwarding VAS server-id alland press Enter.How to Display the VAS Servers Used by a Specified Subscriber
Step 1
show interface linecard 0 subscriber namesubscriber-nameVAS-servers and press Enter.How to Display Health Check Counters for a Specified VAS Server
Step 1
show interface linecard 0 VAS-traffic-forwarding VAS server-idid-numbercounters 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
How to Clear the Health Check Counters for a Specified VAS Server
Step 1
clear interface linecard 0 VAS-traffic-forwarding VAS server-idid-numbercounters health-check and press Enter.How to Clear the Health Check Counters for All VAS Servers
Step 1
clear interface linecard 0 VAS-traffic-forwarding VAS server-id all counters health-checkand press Enter.How to Display Bandwidth per VAS Server and VAS Direction
Note that 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
show interface linecard 0 counters VAS-traffic-bandwidthand 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 0VAS over 10G
•
•
•
•
•
•
•
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
Data Flow in VAS over 10G Topology
•
•
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. Note that the path between the SCE platform and the VAS servers has the same VLAN tag for all SCE platforms in the same EtherChannel.
Figure 12-7 Data Flow in VAS over 10G Topology
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 fromthe 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 that 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:
•
•
•
•
–
–
•
VAS Data Flow: To the VAS Server
Figure 12-8 Data Flow in VAS over 10G Topology: To the VAS Server
The following is the sequence of steps in the VAS data flow from the subscriber side to the VAS server:
1.
2.
3.
4.
5.
6.
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
The following is the sequence of steps in the VAS data flow from the VAS server out to the network:
1.
2.
3.
4.
5.
6.
7.
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:
•
Figure 12-10 VAS over 10G Topology: Failover
•
•
•
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:
•
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.
•
The 10G link that goes through the failed 7600/6500 device is lost completely, however SCA BB and VAS services onthe 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 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:
•
•
•
Note
Note
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:
•
–
–
•
–
–
•
•
How to Configure VAS over 10G
•
•
•
How to Configure the VAS Traffic Link Auto-Select Parameters (VAS over 10G)
•
•
To enable switching the VAS traffic automatically upon a failover situation, the following options must be configured for VAS over 10G:
•
•
•
How to Configure the Link for VAS over 10G
By default, the VAS traffic is transmitted on Link 1. However, for VAS over 10G, theVAS 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:
•
–
Step 1
VAS-traffic-forwarding traffic-link auto-selectand 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:
•
–
Step 1
no VAS-traffic-forwarding traffic-linkand press Enter.How to Configure the Minimum Time between Link Switches
•
•
•
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 that 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:
•
–
How to Configure the Delay between Link Switches
Step 1
VAS-traffic-forwarding traffic-link auto-select link-switch-delayswitch-timeand press Enter.How to Revert to the Default Delay Configuration
Step 1
no VAS-traffic-forwarding traffic-link auto-select link-switch-delayand 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
•
•
•
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:
•
–
How to Set the Active VAS Link
Step 1
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
no VAS-traffic-forwarding traffic-link auto-select initial-selectionand 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
•
•
When configuring the health check for VAS over 10G, you must perform the following steps:
•
•
How to Configure the Health Check IP Address
•
•
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.
•
•
•
Options
The following options are available:
•
•
•
•
•
•
Step 1
VAS-traffic-forwarding health-check ip-address sourcesource-ipdestination dest-ipand press Enter.How to Remove the IP Address Configuration
Step 1
no VAS-traffic-forwarding health-check ip-addressand 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
The following options are available:
•
–
How to Enable Health Check Compatibility for VAS over 10G (MGSCP)
Step 1
VAS-traffic-forwarding health-check topology MGSCPand press Enter.How to Remove the Health Check Compatibility Configuration
Step 1
no VAS-traffic-forwarding health-check topology MGSCPand 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.
SUMMARY STEPS
1.
interface LineCard 0and press Enter.2.
VAS-traffic-forwarding health-check topology MGSCPand press Enter.3.
VAS-traffic-forwarding health-check ip-address source 192.168.100.0:0xffffff00 destination 192.168.101.0and press Enter.4.
VAS-traffic-forwarding traffic-link auto-selectand press Enter.5.
VAS-traffic-forwarding traffic-link auto-select link-switch-delay 240and press Enter.6.
#VAS-traffic-forwarding traffic-link auto-select initial-selection link-0and press Enter.7.
8.
9.
#VAS-traffic-forwardingand press Enter.DETAILED STEPS
Step 1
interface LineCard 0and press Enter.Enter the LineCard Interface configuration mode.
Step 2
VAS-traffic-forwarding health-check topology MGSCPand press Enter.Set VAS health-check to MGSCP mode.
Step 3
VAS-traffic-forwarding health-check ip-address source 192.168.100.0:0xffffff00 destination 192.168.101.0and 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
VAS-traffic-forwarding traffic-link auto-selectand 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
VAS-traffic-forwarding traffic-link auto-select link-switch-delay 240and 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
#VAS-traffic-forwarding traffic-link auto-select initial-selection link-0and press Enter.Sets link-0 to be used as the initial VAS traffic link in auto-select mode.
Step 7
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 603Step 8
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 3Step 9
#VAS-traffic-forwardingand press Enter.Sets the SCE platform to forward VAS traffic (enables VAS traffic forwarding).
Posted: Wed May 30 08:43:45 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
