Re: [j-nsp] Destination Class

From: Simon Leinen (simon@limmat.switch.ch)
Date: Tue Apr 17 2001 - 11:11:51 EDT


>>>>> "ag" == Aviva Garrett <aviva@juniper.net> writes:
> This is a JUNOS 4.3 feature. We call it desgination-class uage. For
> some information, see

> http://www.juniper.net/techpubs/software/junos43/swconfig43-interfaces/html/interfaces-family-config30.html

thanx for the link! We know this feature from Cisco as "Policy-based
Accounting" and like it a lot. They only have eight destination
"bins" as opposed to the sixteen on Juniper. Cisco counts both
packets and bytes, which is sort of nice. If I read the documentation
right, Juniper only counts packets, right? That would sound like a
reasonable tradeoff and is certainly still very useful.

The policy-based accounting counters on the Cisco are accessible by
SNMP - is that also the case for Juniper's "destination-class usage"?
I have written a short page on how to use MRTG to plot Cisco's counters:

http://www.switch.ch/misc/leinen/snmp/monitoring/cisco-bgp-pa.html

If Juniper also has SNMP access and someone can point me to the MIB,
I'd like to add that.

> I don't know the answer to your second question.

The performance hit should be very low, because there are very few
operations in the forwarding path - look up the destination address
(has to be done anyway in order to know where to forward to), get an
additional index for the destination class, and update a counter
pointed to by this index. I assume this can be done in an ASIC
consuming only a couple gates (because the table is limited to a few
entries).

Mapping of destination prefixes to destination classes is only done
(in software - "policy action") as route announcements are processed.
Thus you can do interesting things here without being overly concerned
about performance.

My personal suggestions for improvement of (Cisco's implementation of)
this feature are:

* Allow a couple more destination groups - 32 or 64 would be nice. I
  know one or two transit networks that would like to generate traffic
  matrices between connected networks in this ballpark.

* Support per-source address accounting too - if you do RPF you have
  to look up the source address in the FIB anyway. This would permit
  to measure certain types of routing asymmetry, which some people
  would like to do. Doing both per-source and per-destination would
  make this less scalable to larger numbers of prefix classes of
  course.

Regards,

-- 
Simon.



This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:42 EDT