Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Enabling Source Class and Destination Class Usage

For interfaces that carry IPv4, IPv6, MPLS, or peer AS billing traffic, you can maintain packet counts based on the entry and exit points for traffic passing through your network. Entry and exit points are identified by source and destination prefixes grouped into disjoint sets defined as source classes and destination classes. You can define classes based on a variety of parameters, such as routing neighbors, autonomous systems, and route filters.

Source class usage (SCU) counts packets sent to customers by performing lookup on the IP source 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. You must enable SCU accounting on both the inbound and outbound physical interfaces, and the route for the source of the packet must be in located in the forwarding table.

Note: SCU and DCU accounting do not work with directly connected interface routes. Source class usage does not count packets coming from sources with direct routes in the forwarding table because of software architecture limitations.

Destination class usage (DCU) counts packets from customers by performing 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.

Note: SCU and DCU accounting are supported on the J Series router only for IPv4 and IPv6 traffic.

Note: We recommend that you stop the network traffic on an interface before you modify the DCU or SCU configuration for that interface. Modifying the DCU or SCU configuration without stopping the traffic might corrupt the DCU or SCU statistics. Before you restart the traffic after modifying the configuration, enter the clear interfaces statistics command.

Figure 1 illustrates an Internet service provider (ISP) network. In this topology, you can use DCU to count packets customers send to specific prefixes. For example, you can have three counters, one per customer, that count the packets destined for prefix 210.210/16 and 220.220/16.

You can use SCU to count packets the provider sends from specific prefixes. For example, you can count the packets sent from prefix 210.210/16 and 215.215/16 and transmitted on a specific output interface.

Figure 1: Prefix Accounting with Source and Destination Classes

You can configure up to 126 source classes and 126 destination classes. For each interface on which you enable destination class usage and source class usage, the Junos OS maintains an interface-specific counter for each corresponding class up to the 126 class limit.

Note: For transit packets exiting the router through the tunnel, forwarding path features, such as RPF, forwarding table filtering, source class usage, and destination class usage are not supported on the interfaces you configure as the output interface for tunnel traffic. For firewall filtering, you must allow the output tunnel packets through the firewall filter applied to input traffic on the interface that is the next-hop interface towards the tunnel destination.

Performing DCU accounting when an output service is enabled produces inconsistent behavior in the following configuration: Both SCU input and DCU are configured on the packet input interface. SCU output is configured on the packet output interface. Interface services is enabled on the output interface. Note: For an incoming packet with source and destination prefixes matching the SCU and DCU classes respectively configured in the router, both SCU and DCU counters will be incremented. This behavior is not harmful or negative. However, it is inconsistent with non-serviced packets, in that only the SCU count will be incremented (because the SCU class ID will override the DCU class ID in this case).

To enable packet counting on an interface, include the accounting statement:

• input—Configure at least one expected ingress point.
• output—Configure at least one expected egress point.
• input output—On a single interface, configure at least one expected ingress point and one expected egress point.

• [edit interfaces interface-name unit logical-unit-number family (inet | inet6 | mpls)]
• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6 | mpls)]

For SCU to work, you must configure at least one input interface and at least one output interface.

• For traffic over interfaces on Junos Trio chipset-based Packet Forwarding Engine, a single incoming packet is counted for both SCU and DCU accounting if both SCU and DCU are configured. To ensure the outgoing packet is counted, include the source-class-usage output statements in the configuration of the outgoing interface.
• For traffic over other interfaces, an incoming packet is counted only once, and SCU takes priority over DCU. This means that when a packet arrives on an interface on which you include the source-class-usage input and destination-class-usage statements in the configuration, and when the source and destination both match accounting prefixes, the Junos OS associates the packet with the source class only.

For traffic over interfaces on Junos Trio chipset-based Packet Forwarding Engine, SCU and DCU accounting is performed after output filters are evaluated. If a packet matches a firewall filter match condition, the packet is included in SCU or DCU accounting except in the case where the action of the matched term is discard.

• On T Series, M120, and M320 routers, SCU and DCU accounting is performed before the packet enters the fabric.
• On M7i, M10i, M120, and M320 routers, on MX Series routers with non-Trio chipset-based Packet Forwarding Engine, and on T Series routers, SCU and DCU accounting is performed before output filters are evaluated. Consequently, if a packet matches a firewall filter match condition, the packet is included in SCU or DCU accounting; the packet is counted for any term action (including the discard action).
• On M120, M320, and T Series routers, the destination-class and source-class statements are supported at the [edit firewall family family-name filter filter-name term term-name from] hierarchy level only for the filter applied to the forwarding table. On M7i, M10i, and MX Series routers, these statements are supported.

Once you enable accounting on an interface, the Junos OS maintains packet counters for that interface, with separate counters for inet, inet6, and mpls protocol families. You must then configure the source class and destination class attributes in policy action statements, which must be included in forwarding-table export policies.

In Junos OS Release 9.3 and later, you can configure SCU accounting for Layer 3 VPNs configured with the vrf-table-label statement. Include the source-class-usage statement at the [edit routing-instances routing-instance-name vrf-table-label] hierarchy level. The source-class-usage statement at this hierarchy level is supported only for the virtual routing and forwarding (VRF) instance type. DCU is not supported when the vrf-table-label statement is configured. For more information, see the Junos OS VPNs Configuration Guide.

For a complete discussion about source and destination class accounting profiles, see the Network Management Configuration Guide. For more information about MPLS, see the Junos OS MPLS Applications Configuration Guide.

Examples: Enabling Source Class and Destination Class Usage