[Contents] [Prev] [Next] [Index] [Report an Error]

# Configuring Traffic Mirroring

To support traffic mirroring in an SRC network, configure an aggregate service that can be activated to set up input filter policies on a JUNOS routing platform. The aggregate service defines the set of addresses to be mirrored, such as the subscriber’s address or the list of addresses used by an enterprise. This aggregate service is activated for the subscriber whose traffic should be mirrored, and it also activates fragment services on the JUNOS routing platforms that perform the mirroring. One fragment is activated on each JUNOS routing platform that will process the subscriber’s traffic for mirroring.

You must have preconfigured forwarding options on JUNOS routing platforms for port mirroring and next-hop-group. For complete information about how these features work on the router, see the JUNOS Policy Framework Configuration Guide.

To use the traffic-mirroring application, configure the following items:

- Service scopes
- Services for mirroring traffic on routers in subscriber paths
- Subscription to service
- Subscriber sessions for forwarding interfaces

The following sections describe the tasks to incorporate traffic mirroring in your environment and provide references to entries in the sample data that demonstrate an implementation.

## Configuring Scopes

You configure scopes to define the services to be activated for a specific SRC-managed network and the set of routers that handle subscriber traffic for a location, usually a point of presence (POP).

Figure 2 shows the scopes and routers configured in the sample data. The TM POP scope is the scope assigned to all routers, and contains the aggregate and fragment services. Attaching this scope to the retailer (SP-TM) is the easiest way to define the services for all routers, The TM POP1 scope defines the list of JUNOS routing platforms that provide the mirroring service for the subscriber access router. The TM POP2 scope is the scope assigned to JUNOSe routers, and contains the aggregate and fragment services.

Figure 2: Scopes to Support Mirroring Traffic

To configure scopes for defining mirroring services:

1. In SDX Admin, create a general POP scope that defines the mirroring services (aggregate and fragment) to be activated for the network. For more information about defining the aggregate and fragment services, see Configuring Services for Mirroring.
2. Assign this scope to the retailer so that the mirroring services are available to all subscribers, including router subscribers. For an example, see retailermame=SP-TM, o=Users, o=umc in the sample data.

   For a sample scope, see l=TM, o=Scopes, o=umc in the sample data.

To configure scopes for defining mirroring routers:

1. In SDX Admin, create a network-specific scope that lists the names of the mirroring routers in this POP.

   This scope must contain a parameter specifying the virtual router names of the JUNOS routing platforms in the POP. By using this list, the SRC software activates the services in the JUNOS scope for each router listed.

2. Assign this scope to the virtual routers on the subscriber access router. For an example, see virtualRouterName=default, orderedCimKeys=TMJunosA, o=Network, o=umc. This scope is assigned to the routers to define which core routers transmit subscriber traffic.

   For a sample scope, see l=TM-Pop1, o=Scopes, o=umc in the sample data.

## Configuring Services for Mirroring

Before you configure services to mirror subscriber traffic, make sure that the JUNOS routing platform is configured for mirroring, that SRC service policies specify which traffic to mirror, and that the router configuration specifies how to implement mirroring on that system. For information about port mirroring on a JUNOS routing platform, see the JUNOS Policy Framework Configuration Guide.

Figure 3 illustrates the services in the sample data that mirror subscriber traffic from JUNOS routing platforms and shows the routers on which the services are activated.

Figure 3: Services to Mirror Traffic

The traffic-mirroring application passes the value of the subrIps parameter to the aggregate service; the aggregate service then substitutes the value of the subrIps parameter for the fragSubrIps parameter in the fragment services. For example, in Figure 4, the enterprise IP addresses (112.2.1.13 and 112.2.1.14) that were entered are passed to the aggregate service. The aggregate service passes the value for the IP address to the fragment service for the local router (JunosA). Similarly, in Figure 5, the Mirror Traffic of Subscriber’s Current IP check box in the Traffic Mirroring Administration portal was selected, and the aggregate service passes the subscriber’s current IP address in the subscriber session (111.1.2.6) to the fragment services for the JUNOS routing platforms in the same POP (JunosC and JunosD).

Figure 4: Sample fragSubrIps Parameter Values for Mirroring Enterprise Traffic

Figure 5: Sample fragSubrIps Parameter Value for Mirroring Subscriber Traffic

### Configuring Services

To configure services to mirror subscriber traffic:

1. Configure a policy to mirror traffic for a subscriber whose IP addresses are specified by the fragSubrIps parameter.

   For a mirroring policy, you specify policy rules for traffic sent to and received from the subscriber (the value of the fragSubrIps parameter) that have the traffic-mirror action.

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

2. Create a service for the scope that defines mirroring services, which is a router fragment service; set the type to normal, and specify the policy group configured in Step 1. This service is activated once for each router in a specified POP.

   For a sample service, see servicename=MirrorFragment, l=TM, o=Scopes, o=umc in the sample data.

3. Create an aggregate service for the scope that defines mirroring services; set the type to aggregate; and define the fragment service in the Aggregate tab of the SSP Service pane by using the field descriptions in Aggregate Service Fields for Mirroring Traffic to enter the information in the fields of the Service Fragment dialog box.

   For a sample aggregate service, see serviceName=MirrorAggregate, o=TM, o=Scopes, o=umc in the sample data.

#### Aggregate Service Fields for Mirroring Traffic

Use the fields in this section to configure aggregate services in the Service Fragment dialog box.

Expression

- Subscriber reference expression to specify each mirroring router in the subscriber’s traffic paths and the interface name used to activate the service.
- Value—vr="<- substitution.vrNames ->", interfaceName="FORWARDING-INTERFACE"
  - 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.

Service

- Service to be included in the aggregate service as a fragment service.
- Value—Service configured in Step 2 of Configuring Services.

Mandatory

- Specifies whether the fragment service is mandatory.
- Value
  - false
    - If there is a redundancy group, the application will show the mirroring task as pending until one of the mirroring routers becomes manageable by the SAE.
    - If there is no redundancy group, the application will show the mirroring tasks as pending only when it cannot contact the SAE managing the subscriber.
  - true—The application will show the mirroring task as pending until the SAE can activate the fragment service on all the mirroring routers.

Redundancy Group

- Group identifier for a redundant service.
- Value—Text
- Guidelines—Applicable only when Mandatory is false. If there is a redundancy group, then the mirroring task is considered active if the mirroring fragment is activated on at least one of the mirroring routers.

Subscription

- Specifies whether a remote subscriber session is required to subscribe to the fragment service.
- Value—False.

Substitutions

- List of IP addresses for subscribers.
- Value—fragSubrIps=subrIps
- Guidelines—Note that the fragSubrIps parameter is for the fragment service and can be changed to match the parameter used for the policy in Step 1 of Configuring Services. The subrIps parameter is for the aggregate service and cannot be changed. This substitution is used to resolve the value of the IP address in the context of a subscriber session and to pass the correct value to the fragment service.

### Subscribing to the Aggregate Service

You subscribe to the aggregate service from a subscriber. To create a subscription to the aggregate service:

1. In SDX Admin, under Users select a retailer, and then create a subscriber folder for subscribers.
2. In the folder for subscribers, create each subscriber for which you want to mirror traffic.
3. Create a subscription to the aggregate service in the folder for subscribers.

   For a sample subscription, see serviceName=MirrorAggregate, ou=subscribers, retailermame=SP-TM, o=Users, o=umc in the sample data.

## Configuring Subscriber Sessions

To apply policies to the forwarding interfaces, you configure additional entries in the subscriber classification and interface classification scripts. For general information about classifying subscribers and interfaces, see Overview of Classification Scripts .

### Subscriber Classification Scripts

In addition to the typical entries in the subscriber classification script, traffic mirroring requires the assignment of a subscriber profile for the forwarding interface on the JUNOS routing platform. For example:

`

[ou=routers,retailername=SP-TM,o=Users,o=UMC??sub?(routerName=<-virtualRouterName->)]
# host subscriber for JUNOS routers
interfaceName=="FORWARDING_INTERFACE"

`

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

### Interface Classification Scripts

An entry is needed in the interface classification script to specify the default policy for forwarding interfaces. This default policy must forward all traffic; otherwise all traffic that is not mirrored is dropped. For example:

`

[policyGroupName=forwardIntfDefault,ou=tm,o=Policies,o=UMC]
# manage router interface for mirroring
interfaceName=="FORWARDING_INTERFACE"

`

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

[Contents] [Prev] [Next] [Index] [Report an Error]