Configuring Services to Policy-Route Traffic to IDP

The tasks to configure services to policy-route traffic to IDP are:

1. (Optional) Configuring Scopes When You Use Policy-Based Routing
2.  Defining Services for Policy-Based Routing on JUNOSe Routers

Configuring Scopes When You Use Policy-Based Routing

You configure scopes to define the services to be activated for a specific SRC-managed network. Which scopes you configure depends on how you direct traffic to an IDP sensor.

In a network that contains only JUNOSe routers, you can assign a single scope to one or more JUNOSe routers. Figure 9 shows the scope and JUNOSe router configured in the sample data. This scope also contains the aggregate and fragment services.

Figure 9: Scopes to Support Policy-Based Routing of Traffic to an IDP Sensor

To policy-route traffic from a JUNOSe router to an IDP sensor:

1. Create one JUNOSe point of presence (POP) scope.
2. Assign this scope to all the JUNOSe subscriber access routers that use policy routing. Make sure that these routers appear under o=Networks, o=umc in the directory. You create the aggregate services in this scope.

For a sample JUNOSe POP scope, see l=IDP-JunosePop, o=Scopes, o=umc in the sample data.

Defining Services for Policy-Based Routing on JUNOSe Routers

Figure 10 illustrates the services in the sample data that policy-route incoming and outgoing subscriber traffic to an IDP sensor. In this example this DN for subscriber profiles is routerName=default@JunoseA, <DN of Router Profiles>.

Figure 10: Services to Policy-Route Traffic to an IDP Sensor

The Surveillance Director provides the following information to the services:

• subrSubnet—CIDR subnet. Core interface fragments are activated with this parameter.
• subrIps—List of addresses. A subscriber interface service fragment is created for each address supplied by the parameter.

The aggregate service passes the value of the subrSubnet parameter to each CoreIntFragment service, and uses the value of the subrIps parameter when the SubrIntFragment services are created. A SubrIntFragment service is created for each IP address (which is specified as the subscriber ID). A CoreIntFragment service is created for the subscriber ID or IDs specified in the configuration for the aggregate service (idp@idp in the sample data).

For example, in Figure 11 the Surveillance Director passes the value 111.2.1.6/31 for the CIDR subnet, and the list of addresses 111.2.1.6 and 111.2.1.7 to the aggregate service. The aggregate service passes the value for the CIDR subnet to the CoreIntFragment service, and activates a SubrIntFragment service for each address in the list—in this case for IP addresses 111.2.1.6 and 111.2.1.7.

Figure 11: Sample Values for SubrSubnet and SubrIps Parameters in Services for Policy-Based Routing of Traffic

To set up policy-based routing to direct subscriber traffic from a JUNOSe router to IDP:

• Configure the following services:
  • A service that applies a policy to route traffic from the subscriber interfaces. The Surveillance Director activates this service once for each subscriber whose IP address is in the CIDR subnet that includes the addresses being monitored.

Configuring a Subscriber Interface Service

Before you configure a subscriber interface service, read the overview of services to be used for policy-based routing. See Defining Services for Policy-Based Routing on JUNOSe Routers .

To configure the subscriber interface service:

1. Configure a policy to direct subscriber traffic entering a subscriber interface to an IDP sensor.

   We recommend that you use a next-hop policy rule to route traffic sent by subscribers to the IP address of the IDP sensor. Depending on your network configuration you can also route traffic to a system interface that then routes traffic to the IDP sensor, or you can specify a substitution to indicate the IP address of the IDP sensor.

   For a sample policy group see policyGroupName=policyRouteSubscriberToIdp, ou=idp, o=Policies, o=umc in the sample data.

2. In SDX Admin in the JUNOSe scope, create a service, set the type to normal, and specify the policy group configured in Step 1.

   For a sample subscriber interface service, see serviceName=SubrIntfFragment, o=IDP-JunosePop, o=Scopes, o=umc in the sample data.

Configuring a Core Interface Service

Before you configure a core interface service, read the overview of services to be used for policy-based routing. See Defining Services for Policy-Based Routing on JUNOSe Routers .

To configure the core interface service:

1. Configure policies to direct the traffic destined for subscribers to an IDP sensor.

   We recommend that you use a next-hop policy to route traffic sent to subscribers to the IP address of the IDP sensor. The policy must be applied to each ingress interface that might transmit traffic destined for a subscriber.

   A core interface policy requires that the subscriber CIDR subnet be available from a substitution. You can use the subrSubnet substitution in policies that are applied to all core interfaces.

   For a sample core interface policy, see policyGroupName=policyRouteSubnetToIdp, ou=idp, o=Policies, o=umc in the sample data.

2. In SDX Admin in the JUNOSe scope, create a service, set the type to normal, and specify the policy group configured in Step 1.

   For a sample core interface service, see serviceName=CoreIntfFragment, o=IDP-JunosePop, o=Scopes, o=umc in the sample data.

Configuring an Aggregate Service

Before you configure an aggregate service, read the overview of services to be used for policy-based routing. See Defining Services for Policy-Based Routing on JUNOSe Routers .

You configure an aggregate service to include the subscriber interface service and the core interface service as fragment services.

To configure an aggregate service:

1. In SDX Admin in the JUNOSe scope, create an aggregate service.
2. Add the subscriber interface service as a fragment service, and in the Fragment Service dialog box specify:
   • Expression—A subscriber reference expression written in Python to supply a list of IP addresses, such as:

     address = “ <- substitution.subrIps ->”

     where subrIps is a parameter that provides a list of subscriber IP addresses.

     This expression causes one subscriber interface fragment service to be activated for each subscriber whose address appears in the list.

   • Service—Name of a subscriber interface service.
   • Mandatory—False.

     When set to false, the service is activated even if some of the subscribers for some of the addresses are offline. If set to true, the aggregate service is not activated when some of the addresses are not in use.

   • Redundancy Group—Name of a group of services that provide redundancy.

     We recommend that you configure a redundant service. By configuring a redundancy group, the Surveillance Director can move through the groups of addresses more rapidly. When you configure a group, at least one of the fragments must become active for the aggregate service to become active. If none of the subscribers for the addresses is online when the aggregate service is being activated, activation of the aggregate service fails, and the Surveillance Director skips to the next group of addresses.

   • Subscription—False.
   • Substitution—idpAddress. Specifies the IP address of an IDP sensor The sample data defines the value for the idpAddress substitution in the service. You can use this strategy if an IDP sensor or cluster of sensors has a single IP address. If you use more than one IDP sensor that have different IP addresses, define the value of the idpAddress substitution in a scope, one scope for each IDP sensor, and assign the scope for an IDP sensor to the routers that use that sensor.
3. Add the core interface service as a fragment service, and in the Fragment Service dialog box specify:
   • Expression—A subscriber reference expression written in Python to supply the virtual router name and the login name used to identify subscriber sessions in which to activate the core fragment service. For example:

     vr = “ <- virtualRouterName ->” , login_name = “ idp@idp”

     The expression specifies a set of core interfaces on the same virtual router as the aggregate service.

     The loginName that you use in this expression must be the same as the login name configured in the subscriber classification script for the core interfaces. For information about configuring the login name, see Classifying Subscribers for IDP Integration .

   • Service—Name of a core interface service.
   • Mandatory—False.

     When set to false, the service is activated even if some of core interfaces are down. If set to true, the aggregate service is not activated when some of the core interfaces are down.

   • Redundancy Group—Name of a group of services that provide redundancy.

     We recommend that you configure a redundant service. By configuring a redundancy group, the Surveillance Director can move through the groups of addresses more rapidly. When you configure a group, at least one of the fragments must become active for the aggregate service to become active. If none of the core interfaces is up when the aggregate service is being activated, activation of the aggregate service fails, and the Surveillance Director skips to the next group of addresses.

   • Subscription—False.
   • Substitutions:
     • idpAddress—Specifies the IP address of the IDP sensor

       The sample data defines the value of the idpAddress substitution in the service. You can use this strategy if an IDP sensor or cluster of sensors has a single IP address. If you use more than one IDP sensor that have different IP addresses, define the value of the idpAddress substitution in a scope, one scope for each IDP sensor, and assign the scope for an IDP sensor to the routers that use that sensor.

     • subrSubnet—Specifies the addresses provided by the Surveillance Director

     The subrSubnet parameter specifies a CIDR-specified subnet. The core interface fragment service uses the subrSubnet parameter in policies that are applied to each core interface.

For a sample aggregate service, see serviceName=CheckForAttacks, o=IDP-JunosePop, o=Scopes, o=umc in the sample data.

Copyright © 2009, Juniper Networks, Inc. All rights reserved. Trademark Notice.