Bill,
We have seen both approaches (one datasource for the LAG, or
separate datasources for each component link). You could even offer
both: it's OK for the same packet-sample to be sent on behalf of a
component link datsource and also on behalf of the LAG datasource.
There are trade-offs in both directions, so it comes down to the
architecture on your device, and which approach yields the cleanest
and most consistent model. For example, at the time when you
examine a sampled forwarding-decision, do you know the ifIndex of
the component link, or do you only know the ifIndex of the LAG? In
that scenario it might be cleaner to model it as a single datasource
for the LAG. And if you make the decision to model the LAG as one
datasource, then you should also make the effort to ensure that
interface-counter samples are also reported for the LAG as a whole.
That way you present a consistent model.
On the other hand, you may find that it's much easier
architecturally to only report separately for each component link.
This certainly has the advantage that it allows for analysis and
troubleshooting of how the load-balancing is working on the LAG (and
you can check that nothing unexpected is happening with broadcasts,
multicasts and unknown-unicasts). However not all sFlow collectors
will know to synthesize the LAG view from the components, so you
should take that into account. (Certainly if you take that approach
it would be helpful to implement SNMP MIBs like the ifStackTable and
LAG-MIB.)
regards,
Neil
On Oct 20, 2008, at 10:48 AM, Bill Fenner wrote:
I'm planning an sflow agent implementation, and ran across this
question: should a link aggregation interface be a data source? E.g.,
ifIndex 1 and ifIndex 2 are in a link aggregate, which has ifIndex 50.
Would people to expect to configure sflow on interface 1 and
interface 2 seperately, or is it normal to configure sflow on the
virtual aggregate interface?
Thanks,
Bill
