[email protected] 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
