Enable Source Class and Destination Class Usage
For interfaces that carry IPv4 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 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. You must enable SCU accounting on both the inbound and outbound physical interfaces.
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.
Figure 4 illustrates an 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.
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 software maintains an interface-specific counter for each corresponding class up to the 126 class limit.
 |
|
To enable packet counting on an interface, include the accounting statement:
accounting {
destination-class-usage;
source-class-usage {
(input | output | [input output]);
}
}
You can configure these statements at the following hierarchy levels:
-
[edit interfacesinterface-nameunitlogical-unit-numberfamily inet] - [
edit logical-routerslogical-router-nameinterfacesinterface-nameunitlogical-unit-numberfamily inet]
For SCU to work, you must configure at least one input interface and at least one output interface. 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 software associates the packet with the source class only. To ensure the outgoing packet is counted, include the source-class-usage output statements in the configuration of the outgoing interface.
Once you enable accounting on an interface, the JUNOS software maintains packet counters for that interface. You must then configure the source class and destination class attributes in policy action statements, which must be included in forwarding-table export policies. For a complete discussion about source and destination class accounting profiles, see the JUNOS Internet Software Configuration Guide: Network Management.
Examples: Enable Source Class and Destination Class Usage
Configure DCU and SCU output on one interface:
[edit]
interfaces {
so-6/1/0 {
unit 0 {
family inet {
accounting {
destination-class-usage;
source-class-usage {
output;
}
}
}
}
}
}
Configure SCU input on another interface
[edit]
interfaces {
ge-0/1/0 {
unit 0 {
family inet {
accounting {
source-class-usage {
input;
}
}
}
}
}
}
Optionally, you can include the input and output statements on a single interface
[edit]
interfaces {
ge-0/1/2 {
unit 0 {
family inet {
accounting {
source-class-usage {
input;
output;
}
}
}
}
}
}
Enable Packet Counting for Layer 3 VPNs
You can use SCU and DCU to count packets on Layer 3 VPNs. To enable packet counting for Layer 3 VPN implementations at the egress point of the MPLS tunnel, you must configure a virtual loopback tunnel interface (vt) on the PE router, map the VRF instance type to the virtual loopback tunnel interface, and send the traffic received from the VPN out the source class output interface, as shown in the following example:
[edit interfaces]
vt-0/3/0 {
unit 0 {
family inet {
accounting {
source-class-usage {
input;
}
}
}
}
}
[edit]
routing-instances {
VPN-A {
instance-type vrf;
interface at-2/1/1.0;
interface vt-0/3/0.0;
route-distinguisher 10.255.14.225:100;
vrf-import import-policy-A;
vrf-export export-policy-A;
protocols {
bgp {
group to-r4 {
local-address 10.27.253.1;
peer-as 400;
neighbor 10.27.253.2;
}
}
}
}
}
 |
For SCU and DCU to work, you must not include the |
[edit interfaces]
at-1/1/0 {
unit 0 {
family inet {
accounting {
source-class-usage {
output;
}
}
}
}
}
For more information about VPNs, see the JUNOS Internet Software Configuration Guide: VPNs. For more information about virtual loopback tunnel interfaces, see Configure Tunnel Interfaces.