The performance
of a service provider’s network is usually defined as how well
it can support services, and is measured with metrics such as delay
and utilization. We suggest that you monitor the following performance
metrics using applications such as InfoVista Service Performance Management
or Concord Network Health (see Table 32).
Table 32: Performance
Metrics
Metric:
Average delay
Description
Average round-trip time (in milliseconds) between two
measurement points.
MIB name
DISMAN-PING-MIB (RFC 2925)
Variable name
pingResultsAverageRtt
Variable OID
pingResultsEntry.6
Frequency (mins)
15 (or depending upon ping test frequency)
Allowable range
To be baselined
Managed objects
Each measured path in the network
Metric:
Interface utilization
Description
Utilization percentage of a logical connection.
MIB name
IF-MIB
Variable name
(ifInOctets & ifOutOctets) * 8
/ ifSpeed
Variable OID
ifTable entries
Frequency (mins)
60
Allowable range
To be baselined
Managed objects
All operational interfaces in the network
Metric:
Disk utilization
Description
Utilization of disk space within the Juniper Networks
router
MIB name
HOST-RESOURCES-MIB (RFC 2790)
Variable name
hrStorageSize – hrStorageUsed
Variable OID
hrStorageEntry.5 – hrStorageEntry.6
Frequency (mins)
1440
Allowable range
To be baselined
Managed objects
All Routing Engine hard disks
Metric:
Memory utilization
Description
Utilization of memory on the Routing Engine and FPC.
You can use class-of-service (CoS) mechanisms to
regulate how certain classes of packets are handled within your network
during times of peak congestion. Typically you must perform the following
steps when implementing a class-of-service mechanism:
Identify the type of packets that will be applied to this
class. For example, include all customer traffic from a specific ingress
edge interface within one class, or include all packets of a particular
protocol such as voice over IP (VoIP).
Identify the required deterministic behavior for each
class. For example, if VoIP is important, give VoIP traffic the highest
priority during times of network congestion. Conversely, you can downgrade
the importance of Web traffic during congestion, as it may not impact
customers too much.
With this information, you can configure mechanisms
at the network ingress to monitor, mark, and police traffic classes.
Marked traffic can then be handled in a more deterministic way at
egress interfaces, typically by applying different queuing mechanisms
for each class during times of network congestion. You can collect
information from the network to provide customers with reports showing
how the network is behaving during times of congestion. (See Figure 7.)
Figure 7: Network Behavior During Congestion
To generate these reports, routers must provide
the following information:
Submitted traffic—Amount of traffic received per
class.
Delivered traffic—Amount of traffic transmitted
per class.
Dropped traffic—Amount of traffic dropped because
of CoS limits.
The following section outlines how this information
is provided by Juniper Networks routers.
Inbound Firewall Filter Counters per Class
Firewall filter counters are a very flexible mechanism
you can use to match and count inbound traffic per class, per interface.
For example:
firewall {
filter f1 {
term t1 {
from {
dscp af11;
}
then {
# Assured forwarding class 1 drop profile 1 count inbound-af11;
accept;
}
}
}
}
For example, Table 33 shows
additional filters used to match the other classes.
Table 33: Inbound
Traffic Per Class
DSCP Value
Firewall Match Condition
Description
10
af11
Assured forwarding class 1 drop profile 1
12
af12
Assured forwarding class 1 drop profile 2
18
af21
Best effort class 2 drop profile 1
20
af22
Best effort class 2 drop profile 2
26
af31
Best effort class 3 drop profile 1
Any packet with a CoS DiffServ code point (DSCP)
conforming to RFC 2474 can be counted in this way. The Juniper Networks
enterprise-specific Firewall Filter MIB presents the counter information
in the variables shown in Table 34.
Table 34: Inbound
Counters
Indicator Name
Inbound Counters
MIB
jnxFirewalls
Table
jnxFirewallCounterTable
Index
jnxFWFilter.jnxFWCounter
Variables
jnxFWCounterPacketCount
jnxFWCounterByteCount
Description
Number of bytes being counted pertaining to the specified firewall
filter counter
SNMP version
SNMPv2
This information can be collected by any SNMP management
application that supports SNMPv2. Products from vendors such as Concord
Communications, Inc., and InfoVista, Inc., provide support for the
Juniper Networks Firewall MIB with their native Juniper Networks device
drivers.
Monitoring Output Bytes per Queue
You can use the Juniper Networks enterprise ATM
CoS MIB to monitor outbound traffic, per virtual circuit forwarding
class, per interface. (See Table 35.)
Table 35: Outbound
Counters for ATM Interfaces
Indicator Name
Outbound Counters
MIB
JUNIPER-ATM-COS-MIB
Variable
jnxCosAtmVcQstatsOutBytes
Index
ifIndex.atmVclVpi.atmVclVci.jnxCosFcId
Description
Number of bytes belonging to the specified forwarding class
that were transmitted on the specified virtual circuit.
SNMP version
SNMPv2
Non-ATM interface counters are provided by the
Juniper Networks enterprise-specific CoS MIB, which provides information
shown in Table 36
Table 36: Outbound
Counters for Non-ATM Interfaces
Indicator Name
Outbound Counters
MIB
JUNIPER-COS-MIB
Table
jnxCosIfqStatsTable
Index
jnxCosIfqIfIndex.jnxCosIfqFc
Variables
jnxCosIfqTxedBytes
jnxCosIfqTxedPkts
Description
Number of transmitted bytes or packets per interface per forwarding
class
SNMP version
SNMPv2
Dropped Traffic
You can calculate the amount of dropped traffic
by subtracting the outbound traffic from the incoming traffic:
Dropped = Inbound Counter – Outbound Counter
You can also select counters from the CoS MIB,
as shown in Table 37.
Table 37: Dropped
Traffic Counters
Indicator Name
Dropped Traffic
MIB
JUNIPER-COS-MIB
Table
jnxCosIfqStatsTable
Index
jnxCosIfqIfIndex.jnxCosIfqFc
Variables
jnxCosIfqTailDropPkts
jnxCosIfqTotalRedDropPkts
Description
The number of tail-dropped or RED-dropped packets per interface
per forwarding class
