Providing Threat Mitigation Services with IDP > Directing Subscriber Traffic to IDP for Monitoring

Directing Subscriber Traffic to IDP for Monitoring

You can direct all traffic to IDP by placing an IDP sensor in the network paths through which all incoming and outgoing subscriber traffic passes. In this case, you do not need to configure the SDX software to direct subscriber traffic to an IDP sensor. Skip to Defining Actions to Be Taken for Subscriber Traffic.

How you direct traffic to IDP depends on your network configuration. Table 1 lists ways in which you route subscriber traffic to an IDP sensor.

 Table 1:   Network Configuration and Forwarding Method

 For This Network Configuration

 Use This Method to Forward Subscriber Traffic

 JUNOSe routers as subscriber access routers
 No JUNOS routing platforms as core routers

 Policy-based routing from the JUNOSe router


 JUNOSe routers as subscriber access routers
 and
 JUNOS routing platforms as core routers 

 Mirroring from the JUNOS routing platform



 

 NOTE: Use mirroring from JUNOS routing platform(s) if you are sure that most, or all, of the subscriber traffic traverses those routers. When you mirror traffic to IDP, IDP monitors only the subscriber traffic that traverses a JUNOS routing platform.



 

For policy-based routing from JUNOSe routers, a service is activated on subscriber interfaces for each subscriber IP address, and on each core interface. For mirroring on JUNOS routing platforms, a service is activated only one time for a router or for a set of routers. If your configuration includes a JUNOS routing platform, we recommend that you use mirroring to direct subscriber traffic to IDP.

Surveillance Director

The Surveillance Director manages how to direct subscriber traffic to an IDP sensor. It queries the directory for IP pools associated with specified virtual routers and generates classless interdomain routing (CIDR) subnets that include only the set of IP addresses that are assigned to subscribers. You can configure the number of IP addresses to be included in a CIDR subnet. The Surveillance Director uses CIDR subnets because routers can efficiently handle these subnets to match policy rules.

For each CIDR subnet, the Surveillance Director activates a specified aggregate service, and then the aggregate service activates its fragment services to route traffic to an IDP sensor. The configuration for the fragment services determines whether it policy-routes or mirrors traffic.

Table 2 describes the types of fragment services to configure in an aggregate service, and shows where the fragment services are activated. For general information about aggregate services and fragment services, see SDX Objects Guide, Chapter 1, Managing Services.

 Table 2:  Types of Fragment Services in an Aggregate Service

 Fragment Services

 Policy

 Where Fragment Service Is Activated

 Policy-Based Routing
 

 


 Subscriber-interface fragment

 Routes traffic sent by a subscriber to an IDP sensor

 JUNOSe routers


 Core-interface fragment

 Routes traffic destined for a subscriber to an IDP sensor

 JUNOSe routers


 Mirroring
 

 


 Router (forwarding)-interface fragment

 Mirrors traffic to an IDP sensor

 JUNOS routing platforms that transmit subscriber traffic



 

Traffic for one group of CIDR subnets at a time is sent to an IDP sensor for monitoring. You can configure the length of the interval during which to monitor traffic from CIDR subnet; all traffic for subscribers with IP addresses within the CIDR subnet is monitored during a specified monitoring interval.

The Surveillance Director provides subscriber IDs in the form of a distinguished name (DN) to locate the subscriber session in which to activate a service. The DN is used to locate the SAE that manages the subscriber session in which the aggregate service is activated.

Router and Interface Subscriber Sessions

In addition to the typical subscriber sessions used to activate services, the services to support IDP integration require special subscriber sessions to host:

• An aggregate service
• Core interface fragment services if traffic is policy-routed to an IDP sensor
• Router fragment services if traffic is mirrored to an IDP sensor

Subscriber Session to Host an Aggregate Service

On a JUNOSe router, a router subscriber session hosts an aggregate service. In these cases, a subscriber profile must have a name in the form <vrName>@<routerName>. The <vrName> and <routerName> must correspond to virtual router names and routers names of objects under o=Networks, o=umc in the directory.

Subscriber Session to Host a Core Interface Fragment Service

On a JUNOSe router, a subscriber session is needed to activate a core interface fragment service that policy-routes traffic to the IDP sensor. All core routing interfaces use a single shared subscriber object in the directory.

Subscriber Session to Host a Router Interface Fragment Service

On a JUNOS routing platform, a router subscriber session is used to activate the fragment service that mirrors traffic to the IDP sensor. We recommend that the router subscriber profile have a name in the form <vrName>@<routerName>. The router subscriber session must be associated with the forwarding interface that the SDX creates.

Configuration Tasks to Direct Subscriber Traffic to IDP

The tasks to direct subscriber traffic through IDP are:

• Configuring Scopes
• Defining Services for Policy-Based Routing on JUNOSe Routers

or

Defining Services for Mirroring on JUNOS Routing Platforms

• Configuring Subscriber Sessions
• Configuring Initial Properties for the Surveillance Director
• Customizing Configuration for the Surveillance Director

Configuring Scopes

You configure scopes to define the services to be activated for a specific SDX-managed network. For general information about configuring scopes and assigning scopes to virtual routers, see SDX Objects Guide, Chapter 1, Managing Services. 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 3 shows the scope and JUNOSe router configured in the sample data. This scope also contains the aggregate and fragment services.

Figure 3: Scopes to Support Policy-Routing Traffic to an IDP Sensor

In a network that contains both JUNOSe routers and JUNOS routing platforms, you can assign a single scope to all routers, and a second scope to only JUNOS routing platforms. Figure 4 shows the scopes and routers configured in the sample data. The Junos POP scope contains the aggregate and fragment services. The Junos POP1 scope defines the list of JUNOS routing platforms that provide the mirroring service for the subscriber access router.

Figure 4: Scopes to Support Mirroring Traffic to an IDP Sensor

Configuring Scopes When Policy-Routing Traffic

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.

Configuring Scopes When Mirroring Traffic

To mirror traffic from a JUNOS routing platform to an IDP sensor:

1. Create a general JUNOS POP scope.
2. Assign the scope to the virtual routers on the JUNOSe subscriber access router and the JUNOS routing platforms. Make sure that these routers appear under o=Networks, o=umc in the directory. You create the aggregate service in this scope.

For a sample scope for JUNOS routing platforms, see l=IDP-JunosPop, o=Scopes, o=umc in the sample data.

3. Create a network-specific JUNOS scope that is associated with the general JUNOS scope for each specific POP.

To show the relationship between the two types of JUNOS scopes, we recommend that you incorporate the name of the general JUNOS scope into the name of the network-specific scope. For example, if the name of the general JUNOS scope is JunosPop, then the names of network-specific scopes are JunosPop1, JunosPop2, and so on.

A network-specific scope must contain a parameter that lists the names of the JUNOS routers in the JUNOS POP. By using this list, the SDX software activates the services in the JUNOS scope for each router listed. By using a data integrator, you can simplify the task of keeping information from an external data source synchronized. See SDX Integration Guide, Chapter 9, Data Integration.

For an example of a network-specific scope, see l=IDP-JunosPop1, o=Scopes, o=umc in the sample data.

Defining Services for Policy-Based Routing on JUNOSe Routers

To set up policy-based routing to direct subscriber traffic from a JUNOSe router to IDP, you 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.
• A service that applies a policy to route traffic from the core interfaces that are in the subscriber's JUNOSe virtual router. The Surveillance Director activates this service for each of a set of core interfaces.
• An aggregate service to include the service for the subscriber interfaces and the service for the core interfaces as fragment services.

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.

Figure 5 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 5: Services to Policy Route Traffic to an IDP Sensor

The Surveillance Director provides values for the subrSubnet parameter and the subrIps parameter to the aggregate service. 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 6 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 6: Sample Values for SubrSubnet and SubrIps Parameters in Services for Policy-Routing Traffic

For detailed information about configuring policies, see SDX Objects Guide, Chapter 8, Configuring and Managing Policies; and for detailed information about configuring services, see SDX Objects Guide, Chapter 1, Managing Services.

Configuring a Subscriber Interface Service

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 value-added 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

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 value-added 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

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 Configuring Subscriber Sessions.

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

Defining Services for Mirroring on JUNOS Routing Platforms

Before you configure services to mirror subscriber traffic to an IDP sensor, make sure that the configuration on the JUNOS routing platform:

• Specifies which ports to use for mirroring
• Has a forwarding interface configured

SDX service policies specify which traffic to mirror; the router configuration specifies how to implement mirroring on that system. For information about port mirroring on a JUNOS routing platform, see the JUNOS documentation at

http://www.juniper.net/techpubs/software/junos/junos71/index.html

To use mirroring, you configure a value-added service to reference a policy that mirrors traffic for a set of subscribers selected by Surveillance Director to an IDP sensor, and you configure an aggregate service to activate the fragment service. The Surveillance Director provides the subrSubnet parameter, which represents a CIDR subnet. Router fragment services are activated with this parameter.

Figure 7 illustrates the services in the sample data that mirror subscriber traffic from JUNOS routing platforms to an IDP sensor and shows the routers on which the services are activated. In this example, the DN for subscriber profiles is routerName= default@JunoseB, <DN of Router Profiles>.

Figure 7: Services to Mirror Traffic to an IDP Sensor

The Surveillance Director passes the value for the subrSubnet parameter to the aggregate service; the aggregate service then passes the value of the parameter to the router fragment services. For example, in Figure 8 the Surveillance Director passes value 111.2.1.6/31 for the CIDR subnet, to the aggregate service. The aggregate service passes the value for the CIDR subnet to the router fragment services.

Figure 8: Sample Values for SubrSubnet Parameter in Services for Mirroring

For detailed information about configuring policies, see SDX Objects Guide, Chapter 8, Configuring and Managing Policies; and for detailed information about configuring services, see SDX Objects Guide, Chapter 1, Managing Services. For more information about traffic mirroring, see Chapter 4, Mirroring Subscriber Traffic in the SDX Network.

To configure services to mirror subscriber traffic to an IDP sensor:

1. Configure a policy to mirror traffic for a set of subscribers to the IDP sensor. The subrSubnet parameter (for a specified CIDR subnet) includes the source IP addresses designated for traffic sent by these subscribers.

For a mirroring policy, you specify policy rules for traffic sent to and received from the subscriber subnet (the value of the subrSubnet parameter) that have the action Port Mirror.

For a sample policy that implements mirroring, see policyGroupName=mirrorToIdp, ou=idp, o=Policies, o=umc in the sample data.

2. Create a value-added service, which is a router fragment service in this configuration; set the type to normal; and specify the policy group configured in Step 1. This service is activated once for each JUNOS routing platform in a specified POP.

For a sample service, see servicename=RouterFragment, l=IDP-JunosPop, o=Scopes, o=umc in the sample data.

3. Create an aggregate service; add the value-added service configured in Step 2 to the aggregate service; and in the Service Fragment dialog box specify:

• Expression—A subscriber reference expression to specify the vrNames substitution and the interface name used to activate the service. For example:

vr = "<-  substitution.vrNames ->", interfaceName = 
"FORWARDING_INTERFACE"

where FORWARDING_INTERFACE is used to activate the fragment service for the forwarding table. The vrNames substitution must be defined in each separate POP-specific scope.

For the configuration shown in Figure 7, the substitution would be:

vrNames=["default@JunosC", "default@JunosD"]

as defined in the JUNOS POP1 scope.

• Mandatory—Set the value to false if you want the traffic to be redirected to the IDP sensor even if some of the core routers 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 routers is up for the subscriber addresses 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—subrSubnet specifies the list of addresses provided by the Surveillance Director.

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

Subscribing to an Aggregate Service from a JUNOSe Router

You subscribe to an aggregate service that policy-routes traffic or one that mirrors traffic to an IDP sensor from a JUNOSe router.

To create a subscription to an aggregate service:

1. In SDX Admin, under Users select a retailer, and then create a subscriber folder for router subscribers.
2. In the folder for router subscribers, create a router subscriber for each router.

For sample router subscriptions, see ou=routers, retailername=SP-IDP, o=Users, o=umc in the sample data.

3. Create a subscription to an aggregate service in the folder that includes the router subscribers.

For the sample service CheckForAttacks, to which router subscribers subscribe, see serviceName=CheckForAttacks, ou=routers, retailername=SP-IDP, o=Users, o=umc in the sample data.

4. For policy-based routing to an IDP sensor from a JUNOSe router:

1. Under the retailer, create a subscriber folder for the core interfaces.
2. In the interfaces folder, create one subscriber that is shared by all JUNOSe interfaces that transmit traffic to the network core.

See routerName=idp, ou=interfaces, retailerName=SP-IDP, o-Users, o=umc in the sample data.

Figure 9 shows the SDX Admin navigation pane with the router and interface subscribers included in the sample data.

Figure 9: Router and Interface Subscriptions for JUNOSe Routers

Configuring Subscriber Sessions

You configure additional entries in the subscriber classification script and the interface script to support services for IDP integration. For general information about classifying subscribers and interfaces, see SDX Components Guide, Vol. 1, Chapter 4, Classifying Interfaces and Subscribers.

Classifying Subscribers

IDP integration requires entries in the subscriber classification script for subscriber sessions to host the following services:

• Aggregate service on JUNOSe routers
• Core interface fragment service for policy-based routing traffic on a JUNOSe router
• Router fragment service for mirroring traffic on a JUNOS routing platform

To view the sample subscriber classifications referenced in this section, see l=IDP, l=SAE, ou=staticConfiguration, ou=Configuration, o=Management, o=umc in the sample data.

Router Subscriber Session to Host an Aggregate Service

For JUNOSe routers the subscriber classification script must assign a subscriber profile to the router interface. For example:

[ou=routers,retailername=SP-IDP,o=Users,o=UMC??sub?(routerName=<-virtualRouterN
ame->)]

# host subscriber for JUNOSe routers

interfaceName=="Router"

Interface Subscriber Session to Policy-Route Traffic to IDP

For JUNOSe routers the subscriber classification script must also assign a shared subscriber profile and a login name to a subscriber session when a core interface service is activated. The following example assigns a login name and IP address for the subscriber session to an interface that has core specified as the ifAlias (as configured on the JUNOSe router).

[routerName=idp,ou=interfaces,retailername=SP-IDP,o=Users,o=UMC

?loginName=idp@idp]

# core facing interfaces on JUNOSe routers in JUNOSe POPs

ifAlias=="core"

The login name specified in this classification must be the same as the value set in the subscriber reference expression for the core interface fragment service in the aggregate service. The interface alias must be the same as the one specified in the interface classification script.

Router Subscriber Session to Mirror Traffic to IDP

For JUNOS routing platforms, the subscriber classification script must assign subscriber profiles for the forwarding interface. For example:

[ou=routers,retailername=SP-IDP,o=Users,o=UMC??sub?(routerName=

<-virtualRouterName->)]

# host subscriber for JUNOS routers

interfaceName=="FORWARDING_INTERFACE"

Classifying Interfaces

IDP integration requires entries in the interface classification script to specify default policies.

To view the sample interface classifications referenced in this section, see the interface classification for the IDP<routername> routers listed under o=Network, o=umc in the sample data.

Interface Classification for Core Interfaces on a JUNOSe Router

You identify which interfaces to assign a core routing fragment service by specifying an alias for the group of interfaces. For example:

# ifAlias=="core" Add a line similar to this one if policy-based routing is being used.

# This alias needs to be the same as the one defined in the subscriber classification 
script.

# Could add some further rules to manage DHCP subscribers.

You do not define a classification for the router interface. The SAE automatically creates a router interface and a subscriber session for it when the COPS-PR or COPS XDR router drivers are in use.

Interface Classification for the Forwarding Interface on a JUNOS Routing Platform

For JUNOS routing platforms, the default policy for forwarding interfaces must forward all traffic; otherwise, only traffic mirrored to IDP is forwarded. For example:

policyGroupName=forwardIntfDefault,ou=idp,o=Policies,o=UMC

# manage only forwarding interface on JUNOS routers

interfaceName=="FORWARDING_INTERFACE"

Configuring Initial Properties for the Surveillance Director

To monitor subsets of subscriber traffic by using the Surveillance Director, you configure properties for the Surveillance Director. For general information about the Surveillance Director, see Surveillance Director.

To configure bootstrap properties for the Surveillance Director:

1. On the SAE host, log in as root or as an authorized nonroot admin user.
2. Start the local configuration tool from the installation directory for the IDP integration component:

/opt/UMC/idp/etc/config -l

The first time that you issue this command, it creates the default.properties file and displays the local configuration tool window for the properties.

3. Use the field descriptions in Configuring General Properties and Configuring Java Properties to configure bootstrap properties for the Surveillance Director, and then click OK.

Configuring General Properties

Use the Main tab to configure general information for the Surveillance Director.

Configuration Directory URL

• URL of the directory server that stores the configuration information for the Surveillance Director.
• Value—URL in the format ldap://<host>
• Default—ldap://127.0.0.1:389

Backup Configuration Directory URLs

• URLs of backup directory servers that stores the configuration information for the Surveillance Director.
• Value—URL in the format ldap://<URL>, with more than one URL separated by commas
• Default—No value

Surveillance Director Configuration Location

• Configuration namespace for the Surveillance Director instance definitions.
• Value—Path, relative to the root of the static configuration properties, that defines the object for the namespace in the format /<namespace_name>
• Default—/surveillanceDriver/sds

DES Configuration Location

• Configuration namespace for the Surveillance Director's connection to the network directory (the directory that contains o=Networks, o=umc).
• Value—Path, relative to the root of the static configuration properties, that defines the object for the namespace in the format /<namespace_name>
• Default—/surveillanceDriver/des

Logging Configuration Location

• Configuration namespace for logging for the Surveillance Director.
• Value—Path, relative to the root of the static configuration properties, that defines the object for the namespace in the format /<namespace_name>
• Default—/SurveillanceDirector/Logging

Directory base DN

• DN of the root directory for the SAE.
• Value—<DN>
• Guideline—You must set this attribute if you use a directory-naming scheme that differs from the default.
• Default—o=umc

Configuration Directory Authentication DN

• DN of the entry in the directory that authenticates the directory bind for the Surveillance Director.
• Value—<DN>
• Default—cn=conf, o=operators, <base>

Configuration Directory Password

• Authentication password for the directory.
• Value—Text string
• Default—conf

Connect Timeout

• Interval to connect to the directory.
• Value—Number of seconds in the range 0-2147483647
• Default—10

Configuring Java Properties

Use the Other tab to configure properties for the Java Runtime Environment (JRE).

Java Runtime Environment

• Path to the JRE.
• Value—Directory path in the format /<pathname>
• Default—../jre/bin/java

Java Heap Size

• Maximum amount of memory available to the JRE.
• Value—Number of megabytes in the format <integer>m
• Guidelines—Change this value if the system has problems caused by insufficient memory. Set the value lower than the available physical memory to avoid low performance caused by disk swapping.
• Default—100m

Customizing Configuration for the Surveillance Director

You customize the configuration for the Surveillance Director from SDX Configuration Editor. The configuration files in the sample data contain default values for some Surveillance Director properties. Use these files as a starting place for your configuration. After you import the configuration from the directory into SDX Configuration Editor, the following files appear in the SurveillanceDirector folder.

You can edit the files in this location or make copies of the files and then edit them.

For information about how to use SDX Configuration Editor and how to import data from the directory into SDX Configuration Editor, see SDX Software Basics Guide, Chapter 14, Using SDX Configuration Editor.

Tasks to configure properties for the Surveillance Director are:

• Configuring Directory Properties for the Surveillance Director
• Configuring Logging for the Surveillance Director
• Configuring an Instance of the Surveillance Director

Configuring Directory Properties for the Surveillance Director

You configure properties specific to the Surveillance Director to access network data in the directory through the directory eventing system (DES). For more information about the DES, see SDX Components Guide, Vol. 1, Chapter 11, Configuring the Directory Eventing System.

To configure the directory properties for the Surveillance Director:

1. In SDX Configuration Editor, under SurveillanceDirector edit the des.xml file.

The LDAP pane for directory eventing appears. The following pane shows the properties available with the Editing Level for SDX Configuration Editor set to Normal.

2. Using the following field description, complete the entry under Network.

To complete the entries under DES Client Configuration, see SDX Components Guide, Vol. 1, Chapter 11, Configuring the Directory Eventing System.

3. After you complete the configuration changes, stop and then restart the Surveillance Director for the configuration changes to take effect. Use the following commands to stop and then start the Surveillance Director:

/opt/UMC/idp/etc/sd stop

/opt/UMC/idp/etc/sd start

Network Root

• DN of the network object. The network object contains objects for each router that the SDX software manages.
• Value—<DN>
• Default—No value
• Example—o=Network, o=umc (value in the sample date)

Configuring Logging for the Surveillance Director

To configure logging for the Surveillance Director:

1. In SDX Configuration Editor, under SurveillanceDirector edit the logging.xml file.

The Logging pane appears.

2. Configure logging properties for the Surveillance Director in the same way that you configure logging for other components. See SDX Components Guide, Vol. 1, Chapter 10, Configuring Logging for SDX Components.

Configuring an Instance of the Surveillance Director

You configure properties for an instance of the Surveillance Director for a set of virtual routers to be monitored. One virtual router can be monitored by only one instance of the Surveillance Director at a time.

To configure an instance of the Surveillance Director:

1. In SDX Configuration Editor, under SurveillanceDirector edit the sds.xml file.

The Surveillance Director pane appears.

2. Using the following field descriptions, configure the Surveillance Director properties.
   

   NOTE: The sample data provides values appropriate for setup and debugging for each of these properties.

   
   

Virtual Router Filter

• Virtual routers to be monitored by this instance of the Surveillance Director.
• Value—A regular expression that matches the virtual routers to be managed.
• Guidelines—For information about regular expressions, see

http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html 

Typically, an instance of the Surveillance Director can manage more than one virtual router; however, only one instance of the Surveillance Director manages a virtual router at one time. If more than one instance of the Surveillance Director matches the same virtual router, the first instance of the Surveillance Director that is configured and that matches the virtual router manages it.

If you change the configuration of an instance of the Surveillance Director to stop managing a virtual router, and another instance of the Surveillance Director is already configured to manage that virtual router, then the other instance of the Surveillance Director assumes management of that virtual router.

• Default—No value
• Examples

• .*@BRAS.*—Matches all virtual routers on routers whose names start with BRAS
• .*virneo.*@.*—Matches all virtual routers that contain virneo in the virtual router name, for a router with any name

• Property name—vrFilter

IDP Service Name

• Name of the service to activate in order to direct a subset of subscriber traffic to an IDP sensor.
• Value—<Service name>
• Default—No value
• Property name—idpServiceName

Maximum Number of IP Addresses

• Maximum number of subscriber IP addresses for which the associated traffic should be sent to an IDP sensor or sensor cluster at one time.
• Value—Integer greater than 1
• Guidelines—You must configure a value for this property. This value must be a power of 2. Ensure that the amount of traffic generated by the number of IP addresses identified by this property conforms to the capacity for the IDP system.

For JUNOSe routers, consider system load on the SAE and on the router when you use policy-based routing from JUNOSe routers to an IDP sensor. A fragment service is activated for each IP address.

• Default—8
• Property name—maxIps

Maximum Number of Subnets

• Maximum number of CIDR subnets for which subscriber traffic can be sent to an IDP sensor at one time.
• Value—Integer greater than 1
• Guidelines—Using a large number of CIDR subnets can affect system performance because an aggregate service for IDP is activated once for each CIDR subnet during a specified surveillance time.
• Default—4
• Property name—maxSubnets

Maximum Number of IP Addresses per Subnet

• Maximum number of IP addresses supported in a CIDR subnet.
• Value—Integer greater than 1
• Guidelines—This value must be a power of 2.

If your configuration has a JUNOS routing platform that is being managed from a JUNOS POP, set this value to the value specified for Maximum Number of IP Addresses.

• Default—8
• Property name—maxIpsPerSubnet

Minimum Number of IP Addresses per Subnet

• Minimum number of IP addresses supported in a CIDR subnet.
• Value—Integer greater than 1
• Guidelines—This value must be a power of 2 to efficiently monitor subnets, and must be set to a value less than the value for the Maximum Number of IP Addresses per Subnet.

If the minimum size of a subnet is small and the IP pools do not have large contiguous address ranges, then a surveillance interval can be underused by the number of subscribers. Also with a small minimum size specified, the IP pool can be divided into numerous CIDR subnets to exclude discontinuities in the addresses. In this scenario if the value is a number greater than 1, some addresses may be infrequently or never monitored.

• Default—1
• Property name—minIpsPerSubnet

Surveillance Time

• Length of time to monitor each set of subscribers. This value is also the session timeout for the service specified by the IDP Service Name property.
• Value—Number of seconds greater than 1
• Default—15
• Property name—surveillanceTime

interval Between IDP Service Sessions

• Length of time between when IDP service sessions time out and when the next IDP service sessions are activated.
• Value—Number of seconds greater than 1
• Guidelines— Typically, services for a specified set of IP addresses time out at approximately the same time; however, the length of time to deactivate the services depends on other factors, such as the number of addresses and subnets for which a service is being deactivated, the software and hardware versions of the routers, and the size of systems running the SAE. Use this property to specify how long the Surveillance Director waits for all services to become inactive before it activates services for the next set of addresses to be monitored.

If the value for this property is too long, IDP is underutilized; if it is too short, the IDP can become overloaded.

• Default—5
• Property name—intraSurveillanceTime

DN of Router Profiles

• DN in the directory of the subscriber folder which contains the subscriber entries that correspond to router entries under the network root. For the Surveillance Director to activate a service configured for IDP integration for <vrName>@<routerName>, it constructs a DN type of subscriber ID in the form routerName=<vrName>@<routerName>, <DN of router profiles>. The Surveillance Director then uses that DN to locate the subscriber session in which to activate the service.
• Value—<DN>
• Default—No value
• Example—ou=routers, retailername=SP-IDP, o=Users, o=umc
• Property name—routerProfilesDn

Suppress IP Addresses

• Specifies whether the Surveillance Director provides a value for the subrIps parameter (a list of all the individual addresses to be monitored during a surveillance interval) when it activates an IDP service. For use when traffic is sent directly from JUNOSe routers to an IDP sensor.
• Value—True or false
• Guidelines—Specify false for JUNOSe POPs. Specify true for JUNOS POPs.
• Default—False
• Property name—suppressIps