[c-nsp] netflow restrictions on ASR920

[Nick Hilliard]

adamv0025 at netconsultings.com wrote:
> What is striking though is that we could live without any kind of
> telemetry from forwarding ASICs/NPUs up until now.

what is striking is that we accepted certain vendors' netflow-good,
sflow-bad mantra for so long without considering the consequences of
this, namely that because sflow doesn't require state management on
network device, it's neither particularly difficult nor expensive to
implement properly in hardware, unlike netflow.

It would be really nice if the telemetry religious affairs departments
in these vendors would stop being so silly about refusing point blank to
allow sflow implementations to appear on boxes which use chipsets which
already support it (e.g. all the merchant silicon boxes), or where it's
leaked out into production images, about refusing to fix the
implementation deficiencies which make it practically unusable from the
command line, e.g. ability to specify sflow direction on n3k platform
instead of mandating ingress + egress on all ports with no option to
change it.

For those interested in poking internals, it should be possible to do it
like this (totally untested and may cause your switch to crash, burn or
grow a nasty case of warts):

n3k# conf t
n3k(config)# feature sflow
n3k(config)# sflow data-source interface Ethernet1/1
n3k(config)# ^Z
n3k# test hardware internal bcm-usd bcm-diag-shell
Available Unit Numbers: 0
bcm-shell.0> PortSampRate xe0 4096 0
bcm-shell.0> PortSampRate xe0
 xe0:   ingress: 1 out of 4096 packets, egress: not sampling,
bcm-shell.0> quit
n3k#

This feature should be exposed from the normal CLI.  Poking around with
the BCM shell should not be necessary for core functionality like this.
 More to the point, there are plenty of switches from other vendors
where this works fine.

Nick