Re: [c-nsp] netflow restrictions on ASR920
Sartaj, Can you please help with the following question? Best Regards, [http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg] Waris Sagheer Technical Marketing Manager Service Provider Infrastructure wa...@cisco.com<mailto:wa...@cisco.com> https://cisco.jiveon.com/docs/DOC-966237 Phone: +1 408 853 6682 Mobile: +1 408 835 1389 CCIE - 19901 This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html From: "cisco-nsp-boun...@puck.nether.net" on behalf of Nick Cutting Date: Thursday, January 19, 2017 at 7:49 PM To: Nick Cutting , "cisco-nsp@puck.nether.net" Subject: Re: [c-nsp] netflow restrictions on ASR920 And here is one more, guess I won't be using it at all: This is mentioned under the MPLS config guide - it is not mentioned at all under the Netflow configuration guide. SDM templates are supported only by the Metro Aggregation Services license. Use the help option of the sdm prefer command to display the supported SDM templates. Nick -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Cutting Sent: Wednesday, January 11, 2017 10:14 PM To: cisco-nsp (cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net>) mailto:cisco-nsp@puck.nether.net>> Subject: [c-nsp] netflow restrictions on ASR920 oOk I am about to configure this on an ASR-920-4SZ-A I am seeing some alarming restrictions in the configuration guide: Restrictions for Netflow Monitoring for ASR 920 Series Routers * Netflow monitoring supports only the 7 keys-Source IP, Destination IP, Layer 3 protocol type, TOS, source port, destination port and input logical interface to identify or classify the flow for both IPv4 and IPv6 unicast traffic. All other keys are notsupported. * MPLS and BGP-based netflow is not supported. * Non-key fields supported are packets and bytes (collect counter packets and collect counter bytes) * Only routed ports (IP Ethernet, BDI) and EFP are supported. * EFP flow monitoring can be configured only after configuring bridge-domain on the EFP service instance. * Flow monitoring of multicast traffic is not supported. * Maximum of 16K flows can only be learnt due to FPGA limitations. Though, Netflow supports 16K entries, flows monitored are lower due to hash collisions. * FPGA monitor only 1Gbps traffic rate (with minimum frame size of 100 byte). The accounting is accurate only when the overall traffic monitored is within 1Gbps. * At interface level, MVPN/MLDP/SPAN/PBR feature cannot be enabled on the same interface with Netflow configuration. * Permanent and aggregate flow caches are not supported due to FPGA limitations. Configuration of caches entries number is not supported. * SADT/BFD feature cannot co-exist with Netflow configurations for the following routers: oASR-920-12CZ-A oASR-920-12CZ-D oASR-920-4SZ-A oASR-920-4SZ-D oASR-920-12SZ-IM oASR-920-16CZ-IM * So If I am reading this correctly - my 10gig link will not have correct information when the traffic goes over 1 gig in untilization? Is this due to the ASIC FPGA logic on this hardware? I cannot use PBR on this interface And I cannot enable BFD? Am I missing something or this is a bit of an afterthought for this router? Any help/experience greatly appreciated Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] netflow restrictions on ASR920
And here is one more, guess I won't be using it at all: This is mentioned under the MPLS config guide - it is not mentioned at all under the Netflow configuration guide. SDM templates are supported only by the Metro Aggregation Services license. Use the help option of the sdm prefer command to display the supported SDM templates. Nick -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Cutting Sent: Wednesday, January 11, 2017 10:14 PM To: cisco-nsp (cisco-nsp@puck.nether.net) Subject: [c-nsp] netflow restrictions on ASR920 oOk I am about to configure this on an ASR-920-4SZ-A I am seeing some alarming restrictions in the configuration guide: Restrictions for Netflow Monitoring for ASR 920 Series Routers * Netflow monitoring supports only the 7 keys-Source IP, Destination IP, Layer 3 protocol type, TOS, source port, destination port and input logical interface to identify or classify the flow for both IPv4 and IPv6 unicast traffic. All other keys are notsupported. * MPLS and BGP-based netflow is not supported. * Non-key fields supported are packets and bytes (collect counter packets and collect counter bytes) * Only routed ports (IP Ethernet, BDI) and EFP are supported. * EFP flow monitoring can be configured only after configuring bridge-domain on the EFP service instance. * Flow monitoring of multicast traffic is not supported. * Maximum of 16K flows can only be learnt due to FPGA limitations. Though, Netflow supports 16K entries, flows monitored are lower due to hash collisions. * FPGA monitor only 1Gbps traffic rate (with minimum frame size of 100 byte). The accounting is accurate only when the overall traffic monitored is within 1Gbps. * At interface level, MVPN/MLDP/SPAN/PBR feature cannot be enabled on the same interface with Netflow configuration. * Permanent and aggregate flow caches are not supported due to FPGA limitations. Configuration of caches entries number is not supported. * SADT/BFD feature cannot co-exist with Netflow configurations for the following routers: oASR-920-12CZ-A oASR-920-12CZ-D oASR-920-4SZ-A oASR-920-4SZ-D oASR-920-12SZ-IM oASR-920-16CZ-IM * So If I am reading this correctly - my 10gig link will not have correct information when the traffic goes over 1 gig in untilization? Is this due to the ASIC FPGA logic on this hardware? I cannot use PBR on this interface And I cannot enable BFD? Am I missing something or this is a bit of an afterthought for this router? Any help/experience greatly appreciated Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] netflow restrictions on ASR920
adamv0...@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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] netflow restrictions on ASR920
Hi, > James Bensley > Sent: Thursday, January 12, 2017 9:25 AM > > > If anyone can elaborate I’d like to know of if anyone from Cisco wants to > chime in please do. It’s very annoying they aren’t clearer about these things > as anything we want to do we have to lab test it and work it out for our self > (typical questions like “how many ‘features’ or which ‘features’ can I enable > and still get line rate or X Mbps/Gbps, because we aren’t told how the > features are working). > Yeah very annoying indeed, However it would be a very long list/test, cause if feature X' has X pps tax and feature Y' has Y pps tax, then enabling both features does not result in X+Y pps tax, but more like (X+Y)-Z, where Z depends on how effective they are with mem lookups. Oh and the pps tax for a feature is not constant either and might change with a new code release, cause the SW paths are being streamlined. What is striking though is that we could live without any kind of telemetry from forwarding ASICs/NPUs up until now. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] netflow restrictions on ASR920
On 12 January 2017 at 03:14, Nick Cutting wrote: > * FPGA monitor only 1Gbps traffic rate (with minimum frame size of > 100 byte). The accounting is accurate only when the overall traffic monitored > is within 1Gbps. ... > So If I am reading this correctly - my 10gig link will not have correct > information when the traffic goes over 1 gig in untilization? > Is this due to the ASIC FPGA logic on this hardware? > > I cannot use PBR on this interface > And I cannot enable BFD? I'm not entirely sure as I haven't tried NetFlow on the ASR920's (it looks like a disaster so we haven't placed them anywhere we would need NetFlow) but is that limit perhaps relating to CPU punted traffic only? My understanding is as follows: All PHY controllers connect to the Cylon ASIC so it should be a compact forwarding path, traffic comes in one port (be it 1G or 10G etc.), local forwarding logic and TCAM on-chip (Cylon) looks up correct egress port and re-write details, Cylon sends the traffic to the appropriate egress PHY. There is a PCIe link between the Cylon ASIC and CPU, and there is a PCIe link from the Cylon to the FPGA and then from the FPGA to the CPU. Given the direct link from Cylon to CPU I’m not sure why the FPGA would limit NetFlow for “normal” (non-punted) traffic, I would assume the CPU would handle this. I’m not fully aware of how the design/topology is working here. There is a cylon_mgr process which I presume runs on the CPU (it sites outside of IOSd). I’m not sure what functions the FPGA is handling that the Cylon can’t handle itself. There is 2GB DDR3 memory hanging off the FPGA and 2GB DDR3 memory handing off the CPU and I *think* the FPGA attached memory is running at a faster clock. There is 12MB of on-chip packet buffers on the Cylon, so why are there two lots of DDR3 memory? Again not sure what is being offloaded to the CPU and what is being off loaded to the FPGA. Maybe NetFlow is off loaded to the FPGA? If anyone can elaborate I’d like to know of if anyone from Cisco wants to chime in please do. It’s very annoying they aren’t clearer about these things as anything we want to do we have to lab test it and work it out for our self (typical questions like “how many ‘features’ or which ‘features’ can I enable and still get line rate or X Mbps/Gbps, because we aren’t told how the features are working). Cheers, James. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] netflow restrictions on ASR920
Hi, On Thu, Jan 12, 2017 at 03:14:24AM +, Nick Cutting wrote: > Am I missing something or this is a bit of an afterthought for this router? It's an amazing addition to a switch. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
