Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Grouping Source and Destination Prefixes into a Forwarding Class

This example shows how to group source and destination prefixes into a forwarding class.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

This example uses three routing devices: a customer edge (CE) device, a provider edge (PE) device, and a provider core (P) device.

Figure 1 shows the sample network.

Figure 1: SCU and DCU Sample NetworkSCU and DCU Sample Network

Source class usage (SCU) counts packets sent to the customer edge by performing lookup on the IP source address and the IP destination address. SCU makes it possible to track traffic originating from specific prefixes on the provider core and destined for specific prefixes on the customer edge.

DCU counts packets from customers by performing a lookup of the IP destination address. DCU makes it possible to track traffic originating from the customer edge and destined for specific prefixes on the provider core router.

On Device PE’s fe-1/2/1 interface, facing the provider core (represented by Device P), SCU input is configured with the source-class-usage input statement to track traffic originating at Device P and destined to Device CE. On this same interface, the destination-class-usage input statement is configured to track traffic originating at Device CE destined to the provider core.

Unlike destination class usage (DCU), which only requires implementation on a single interface, accounting for SCU must be enabled on two interfaces: the inbound and outbound interfaces traversed by the source class. You must define explicitly the two interfaces on which SCU monitored traffic is expected to arrive and depart. This is because SCU performs two lookups in the routing table: a source address (SA) and a destination address (DA) lookup. In contrast, DCU only has a single destination address lookup.

On Device PE’s fe-1/2/0 interface, facing Device CE, SCU output is configured with the source-class-usage output statement.

To account for traffic destined to the customer, the policy called scu_class uses route filters to place traffic into the gold1, gold2, and gold3 classes.

To account for traffic destined to the provider, the policy called dcu_class uses route filters to place traffic into the silver1, silver2, and silver3 classes.

The policies are then applied to the forwarding table.

The example uses static routes to provide connectivity and loopback interface addresses for testing the operation.

CLI Quick Configuration shows the configuration for all of the devices in Figure 1.

The section #configuration715__scu-dcu-sample-st describes the steps on Device PE.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device CE

Device PE

Device P

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Use the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To group source and destination prefixes in a forwarding class:

  1. Create the router interfaces.

  2. Configure BGP.

  3. Configure the DCU policy.

  4. Configure the SCU policy.

  5. Apply the policies to the forwarding table.

    Note:

    You can refer to the same routing policy one or more times in the same or different export statement.

  6. (Optional) Configure a routing policy that advertises direct routes.

  7. Configure the autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by issuing the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Making Sure That the DCU Policy Is Working

Purpose

Verify that traffic sent from the provider core into the customer network is causing the DCU policy counters to increment.

Action

  1. From Device P, ping an address in the customer network.

  2. On Device PE, check the interface statistics on the interface facing the provider core.

Meaning

Packet and bit rates are displayed with packet and byte counters.

Alternatively, you can use the show interfaces destination-class all command to display the same information.

Making Sure That the SCU Policy Is Working

Purpose

Verify that traffic sent from the customer network into the provider core is causing the SCU policy counters to increment.

Action

  1. From Device CE, ping an address in the customer network.

  2. On Device PE, check the interface statistics on the interface facing the customer network.

Meaning

Packet and bit rates are displayed with packet and byte counters.

Alternatively, you can use the show interfaces source-class all command to display the same information.