Discussion:
SNMP and Command Line joint configuration
andy kitchingman
2009-11-24 02:56:59 UTC
Permalink
Hi

Just out of interest, what is the reasoning behind not having SNMP being
able to modify a command line configured sFlow change as per Section 6.1
in the sFlow version 5 specification?
An example or use case would help clarify this.

Thanks in advance.

Andy Kitchingman

NOTICE: This message contains privileged and confidential
information intended only for the use of the addressee
named above. If you are not the intended recipient of
this message you are hereby notified that you must not
disseminate, copy or take any action in reliance on it.
If you have received this message in error please
notify Allied Telesis Labs Ltd immediately.
Any views expressed in this message are those of the
individual sender, except where the sender has the
authority to issue and specifically states them to
be the views of Allied Telesis Labs.
Neil McKee
2009-11-30 19:22:10 UTC
Permalink
Andy,

The assumption here is that you wouldn't want to set something up in the CLI config, and then have it change under your feet.

You asked for an example: the mechanism you can use to enforce this separation is to define multiple sampler and poller instances for each interface, and allow a corresponding number of receivers to be defined. Then you can expose some via the SNMP MIB and dedicate the rest to the CLI. If you allow for 6 receivers, then you could hard-wire the first three to be for SNMP configuration only, and the last 3 to be for CLI configuration only (and invisible to the SNMP MIB, so that a GET-NEXT will just skip over them and a GET or SET to them will fail). Similarly, each interface might be represented by 6 sampler instances, and 6 poller instances. Only the first 3 would be accessible via SNMP.

So a remote collector that configures sFlow through the MIB will find and acquire a free receiver slot (e.g. slot 2) and write in his IP address. Then he will find and acquire free sampler and poller instances for each interface that he wants to monitor and connect them to receiver slot = 2, requesting the desired sampling-rate and polling interval. At the same time a CLI command might be using receiver 4 to send sFlow to a different collector with a different sampling rate and polling interval, but this would not be visible through the MIB.

Clean separation. No surprises.

Does that help?

Regards,
Neil


P.S. There is a separate question here about how to set things up so that multiple sampler instances can represent the same interface and yet still be configured to sample at different rates. One collector might ask for 1-in-500 and another might ask for 1-in-200. You are likely to only have one hardware sampling rate for that interface. One solution is to set the hardware to sample at the highest-common-factor, and then assign a "sub-sampling" rate to each sampler instance. To make this cleaner you might decide to always round the requested sampling-rate to the nearest power of 2. So in this example you might set the hardware to sample at 1-in-256. Then one sampler would have a sub-sampling rate of 1 and the other would have a sub-sampling rate of 2, to get to 1-in-512. Maybe
this is all quite obvious, but perhaps it helps to clarify what is meant by sampler "instances".
Post by andy kitchingman
Hi
Just out of interest, what is the reasoning behind not having SNMP being
able to modify a command line configured sFlow change as per Section 6.1
in the sFlow version 5 specification?
An example or use case would help clarify this.
Thanks in advance.
Andy Kitchingman
NOTICE: This message contains privileged and confidential
information intended only for the use of the addressee
named above. If you are not the intended recipient of
this message you are hereby notified that you must not
disseminate, copy or take any action in reliance on it.
If you have received this message in error please
notify Allied Telesis Labs Ltd immediately.
Any views expressed in this message are those of the
individual sender, except where the sender has the
authority to issue and specifically states them to
be the views of Allied Telesis Labs.
Continue reading on narkive:
Loading...