Hi Pshem, Thank you very much for sharing the insight. I guess I’d have to struggle through it. But it seems this box can’t be used to terminate services/customers aggregated via attached L2 switch so only one customer/service per port. Regarding the QOS per EVC I remember ME3600 having similar problems when modifying service-policies already applied to EVC.
As far as the new chipset for ASR901 goes maybe Waris could share some insight on that. adam From: Pshem Kowalczyk [mailto:[email protected]] Sent: Sunday, June 22, 2014 11:18 AM To: Vitkovský Adam Cc: [email protected] Subject: Re: [c-nsp] QOS on asr901 Hi, ASR901 has a very odd qos implementation due to the fact it's based on a stock-standard Broadcom chip. From my experience - only basic stuff actually works (regardless of what docs say). On a single port you can effectively have only one egress policy (regardless of the number of the EVCs you have), ingress direction allows you one policy per EVC. The only classifier on egress is qos-group (that you have to set on ingress). From my experience - it can be made to work on the policing (ingress), shaping/scheduling (egress) front, but requires a lot of testing and experimentation. For example - I've noticed that If you try to modify some qos settings on a map already applied to an interface/evc - it gets detached quietly, but remains in the config as if it was ok. Also - the whole EVC has to be nuked if you want to modify a policy to make sure it actually gets applied correctly (it helps to modify the service instance id). If you think your core link might congest - pay close attention to the markings of control plane packets - we've seen links drop because BFD wasn't scheduled as priority. I was told that next revision will use a better chipset, but I don't know the timeframes. Have you considered an ME1200 (if you don't need the 10G)? http://www.cisco.com/c/en/us/products/switches/me-1200-series-carrier-ethernet-access-devices/index.html kind regards Pshem On 21 June 2014 02:15, Vitkovský Adam <[email protected]<mailto:[email protected]>> wrote: Hi folks, I'm just evaluating asr901 and came across some QOS issues. Anyone using egress QOS with priority and random-detect discard-class-based on ASR901 please? I'm getting so many errors and limitations. Had to strip the priority queue config to basically this: class core_realtime priority percent xx -as it seems you can't use police even though the queue is marked as priority -though the documentation says it's possible. And even than I got this errors Jun 20 21:21:46.562: Data Qualify failed(2):-7 Jun 20 21:21:46.562: Error in programming Exp:-7 I guess it's because of class class-default random-detect discard-class-based random-detect discard-class 0 20 30 10 Also are there any plans for supporting QOS under service instances please? Thank you adam _______________________________________________ cisco-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
