Redirecting Subscriber Traffic Using ISG Layer 4 Redirect
|
||||||||||||||||||||||||||||||||||||
Contents
Redirecting Subscriber Traffic Using ISG Layer 4 RedirectLast Updated: November 30, 2011
Intelligent Services Gateway (ISG) is a Cisco IOS software feature set that provides a structured framework in which edge devices can deliver flexible and scalable services to subscribers. This module describes how to configure ISG to redirect subscriber traffic by using the ISG Layer 4 Redirect feature. The ISG Layer 4 Redirect feature enables service providers to better control the user experience by allowing subscriber TCP or UDP packets to be redirected to specified servers for appropriate handling. ISG Layer 4 redirection can be used to facilitate subscriber authentication, initial and periodic advertising captivation, redirection of application traffic, and Domain Name System (DNS) redirection. Finding Feature InformationYour software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Restrictions for Redirecting ISG Subscriber TrafficThe ISG Layer 4 Redirect feature applies only to TCP or UDP traffic. A Layer 4 Redirect feature and a traffic-class (TC) service containing a Layer 4 Redirect feature cannot be applied on the same session. A Layer 4 Redirect feature can be applied either on a session or on a TC on the session. Layer 4 Redirect translations are not stateful switchover (SSO) capable. Translations must be re-created after a switchover. Information About Redirecting ISG Subscriber TrafficOverview of ISG Layer 4 RedirectThe ISG Layer 4 Redirect feature redirects specified packets to servers that handle the packets in a specified manner. For example, packets sent upstream by unauthorized users can be forwarded to a server that redirects the users to a login page. Similarly, if users try to access a service to which they have not logged in, the packets can be redirected to a server that provides a service login screen. The Layer 4 Redirect feature supports three types of redirection, which can be applied to subscriber sessions or to flows:
A redirect server can be any server that is programmed to respond to the redirected packets. If ISG is used with a web portal, unauthenticated subscribers can be sent automatically to a login page when they start a browser session. Web portal applications can also redirect to service login pages, advertising pages, and message pages. Redirected packets are sent to an individual redirect server or redirect server group that consists of one or more servers. ISG selects one server from the group on a rotating basis to receive the redirected packets. When traffic is redirected, ISG modifies the destination IP address and TCP port of upstream packets to reflect the destination server. For downstream packets, ISG changes the source IP address and port to the original packet's destination. When traffic is selected by a policy map that includes a redirection command, packets are fed back into the policy map classification scheme for a second service selection. The modified IP headers can be subject to different classification criteria. For example, if two class maps exist, each with different redirection commands, packets could be redirected, selected by the first class map, and redirected a second time. To avoid this situation, configure traffic class maps so that two consecutive redirections cannot be applied to the same packet. Layer 4 Redirect ApplicationsThe Layer 4 Redirect feature supports the following applications:
How to Configure ISG Layer 4 RedirectThere are three ways to apply Layer 4 redirection to sessions. One way is to configure redirection directly on a physical main interface or logical subinterface. A second way is to configure a service profile or service policy map with the Layer 4 redirect attribute in it, and apply that service to the session. A third way is to configure the Layer 4 redirect attribute in the user profile. The following tasks describe how to configure Layer 4 redirection. The first task is optional. One or more of the next three tasks is required. The last task is optional. For examples of Layer 4 redirection configuration for specific applications (such as unauthenticated user redirect), see the "Configuration Examples for ISG Layer 4 Redirect" section.
Defining a Redirect Server GroupPerform this task to define a group of one or more servers to which traffic will be redirected. Traffic will be forwarded to servers on a rotating basis. DETAILED STEPS
Configuring Layer 4 Redirection in a Service Policy MapBefore You Begin
SUMMARY STEPS
The ISG Layer 4 Redirect feature is configured under a traffic class within a service policy map. This task assumes that you have defined the traffic class map. See the "Configuring ISG Subscriber Services" module for more information.
DETAILED STEPS Configuring Layer 4 Redirection in a Service or User Profile on the AAA ServerThe Layer 4 Redirect feature can be configured as a Cisco vendor-specific attribute (VSA) in a user or service profile on an authentication, authorization, and accounting (AAA) server. This attribute can appear more than once in a profile to define different types of redirections for a session and can be used in both user and service profiles simultaneously. DETAILED STEPS
What to Do NextIf you configure ISG Layer 4 redirection in a service profile, you may want to configure a method of activating the service profile; for example, control policies can be used to activate services. For more information about methods of service activation, see the "Configuring ISG Subscriber Services" module. Verifying ISG Traffic RedirectionPerform this task to verify the configuration and operation of ISG Layer 4 traffic redirection. The show commands can be used in any order. DETAILED STEPS ExamplesThe following is sample output from the show redirect translations command showing the number of active redirect translations:
Router# show redirect translations
Maximum allowed number of L4 Redirect translations per session: 5
Destination IP/port Server IP/port Prot In Flags Out Flags Timestamp
10.0.1.2 23 10.0.2.2 23 TCP Oct 21 2009 11:48:01
10.0.1.2 23 10.0.2.2 23 TCP Oct 21 2009 11:48:01
10.0.1.2 23 10.0.2.2 23 TCP Oct 21 2009 11:48:01
Total Number of Translations: 3
Highest number of L4 Redirect: 3 by session with source IP 10.0.0.2
The following sample output from the show subscriber session command shows that Layer 4 redirect is being applied from the service profile:
Router# show subscriber session uid 135
Subscriber session handle: 7C000114, state: connected, service: Local Term
Unique Session ID: 135
Identifier: blind-rdt
SIP subscriber access type(s): IP-Interface
Root SIP Handle: CF000020, PID: 73
Current SIP options: Req Fwding/Req Fwded
Session Up-time: 40 minutes, 30 seconds, Last Changed: 40 minutes, 30 seconds
AAA unique ID: 135
Switch handle: F000086
Interface: ATM2/0.53
Policy information:
Authentication status: unauthen
Config downloaded for session policy:
From Access-Type: IP-Interface, Client: SM, Event: Service Selection Request, Service
Profile name: blind-rdt, 2 references
username "blind-rdt"
l4redirect "redirect to group sesm-grp"
Rules, actions and conditions executed:
subscriber rule-map blind-rdt
condition always event session-start
action 1 service-policy type service name blind-rdt
Session inbound features:
Feature: Layer 4 Redirect
Rule Cfg Definition
#1 SVC Redirect to group sesm-grp !! applied redirect
Configuration sources associated with this session:
Service: blind-rdt, Active Time = 40 minutes, 32 seconds
Interface: ATM2/0.53, Active Time = 40 minutes, 32 seconds
The following is sample output from the show subscriber sessioncommand for a session in which the Layer 4 redirection is applied on the interface:
Router# show subscriber session uid 133
Subscriber session handle: D7000110, state: connected, service: Local Term
Unique Session ID: 133
Identifier:
SIP subscriber access type(s): IP-Interface
Root SIP Handle: 1E, PID: 73
Current SIP options: Req Fwding/Req Fwded
Session Up-time: 42 minutes, 54 seconds, Last Changed: 42 minutes, 54 seconds
AAA unique ID: 133
Switch handle: 17000084
Interface: FastEthernet0/0/0.505
Policy information:
Authentication status: unauthen
Session inbound features:
Feature: Layer 4 Redirect
Rule Cfg Definition
#1 INT Redirect to group sesm-grp
Configuration sources associated with this session:
Interface: FastEthernet0/0/0.505, Active Time = 42 minutes, 54 seconds
Configuration Examples for ISG Layer 4 Redirect
Example: Redirecting Unauthenticated Subscriber TrafficIn the following example, Layer 4 redirection is configured in the service policy map "BLIND-RDT." This policy is applied to all sessions at session start and redirects subscriber TCP traffic to the server group called "PORTAL." At account login the subscriber is authenticated and the redirection is not applied. Service-policy type control DEFAULT-IP-POLICY policy-map type control DEFAULT-IP-POLICY class type control always event session-start 1 service-policy type service name BLIND-RDT ! class type control always event account-logon 1 authenticate aaa list AUTH-LIST 2 service-policy type service unapply name BLIND-RDT policy-map type service BLIND-RDT class type traffic CLASS-ALL redirect to group PORTAL ! redirect server-group PORTAL server ip 2001:ABCD:14::6, Port 8000 Example: Redirecting Unauthorized Subscriber TrafficThe following example shows the configuration of redirection for unauthorized subscribers. If the subscriber is not logged into the service called "svc," traffic that matches "svc" is redirected to the server group "PORTAL." Once the subscriber logs on to the service, the traffic is no longer redirected. When the subscriber logs off the service, redirection is applied again. service-policy type control THE_RULE ! class-map type traffic match-any CLASS-ALL ! class-map type traffic match-any CLASS-100_110 match access-group input 100 match access-group output 110 ! policy-map type service blind-rdt class type traffic CLASS-ALL redirect to group PORTAL ! policy-map type service svc-rdt class type traffic CLASS-ALL redirect to group PORTAL ! policy-map type service svc class type traffic CLASS-100_110 class type traffic default in-out drop policy-map type control THE_RULE class type control alwyas event account-logon 1 authenticate 2 service-policy type service name svc-rdt class type control cond-svc-logon event service-start 1 service-policy type service unapply name svc-rdt 2 service-policy type service identifier service-name class type control cond-svc-logon event service-stop 1 service-policy type service unapply name svc 2 service-policy type service name svc-rdt ! class-map type control match-all cond-svc-logon match identifier service-name svc ! redirect server-group PORTAL server ip 10.2.36.253 port 80 Example: Initial ISG RedirectionThe following example shows ISG configured to redirect the Layer 4 traffic of all subscribers to a server group called "ADVT" for the initial 60 seconds of the session. After the initial 60 seconds, ISG will stop redirecting the traffic for the rest of the lifetime of the session. service-policy type control initial-rdt policy-map type control intial-rdt class type control always event session-start 1 service-policy type service name initial-rdt-profile ! policy-map type service initial-rdt-profile class type traffic CLASS-ALL redirect to group ADVT duration 60 Example: Periodic ISG RedirectionThe following example shows how to redirect all subscriber traffic for a period of 60 seconds every 3600 seconds: service-policy control periodic-rdt session-start ! policy-map type control periodic-rdt class type control always event session-start 1 service-policy service periodic-rdt-profile ! policy-map type service periodic-rdt-profile redirect to group ADVT duration 60 frequency 3600 Example: Redirecting DNS TrafficThe following example shows how to redirect all subscriber DNS packets to the server group "DNS-server:" service-policy type control DNS-rdt policy-map type control DNS-rdt class type control event session-start 1 service-policy type service name DNS-rdt-profile ! policy-map type service DNS-rdt-profile class type traffic CLASS-ALL redirect to group DNS-server Redirection for PPP Sessions ExampleThe following example shows how to configure Layer 4 redirection for PPP sessions: class-map type traffic match-any CLASS-L4R ! policy-map type service svc-rdt class type traffic CLASS-L4R redirect to group PORTAL ! policy-map type control THE_RULE class type control alwyas event session-start 1 authenticate 2 service-policy type service name svc-rdt ! redirect server-group PORTAL server ip 10.2.36.253 port 80 ! Additional ReferencesRelated DocumentsTechnical Assistance
Feature Information for Redirecting ISG Subscriber TrafficThe following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. © 2011 Cisco Systems, Inc. All rights reserved.
|
||||||||||||||||||||||||||||||||||||