Mailing List Archive

Hi James,

> On 7 Sep 2021, at 14:10, james list <jameslist72@gmail.com> wrote:
>
> Dear experts,
> I'd like to rate limit some ingress traffic coming from untrusted source to
> 10Mbs.
>
> I've an ASR1001X (16.3.7) and this is the config I'd place:
>
> *********************
> ip access-list extended ACL_10_203_231_129
> permit ip any host 10.203.231.129
>
> class-map match-all CM_LIMIT_INGRESS
> match access-group name ACL_10_203_231_129
>
> policy-map PM_LIMIT_INGRESS
> class CM_LIMIT_INGRESS
> police 10000000 5000000 5000000 conform-action transmit exceed-action
> drop violate-action drop
> class class-default
>
> The PM is attached to tunnel interface:
>
> TUNNEL0
> service-policy input PM_LIMIT_INGRESS
>
> *********************
>
> Can you please confirm:
>
> 1) I'll not drop/limit other traffic

It won’t. It will apply the policy only to matching traffic (ACL ACL_10_203_231_129).

> 2) ASR1001X applies rate limit in hardware and not in software (in order to
> avoid CPU overload)

Hardware.

> 3) is there any mode to limit pps and not only bandwidth

I no longer remember this from top of my mind, but there’s bunch of good QoS/HQoS presentations about ASR 1000 in particular on ciscolive.com that you can use as reference.

--
./
_______________________________________________
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/

On Wed, 8 Sept 2021 at 16:30, Lukasz Bromirski <lukasz@bromirski.net> wrote:

> > 3) is there any mode to limit pps and not only bandwidth
>
> I no longer remember this from top of my mind, but there’s bunch of good QoS/HQoS presentations about ASR 1000 in particular on ciscolive.com that you can use as reference.

police rate x pps

--
++ytti
_______________________________________________
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/

Saku is always on point ;)

> On 8 Sep 2021, at 15:31, Saku Ytti <saku@ytti.fi> wrote:
>
> On Wed, 8 Sept 2021 at 16:30, Lukasz Bromirski <lukasz@bromirski.net> wrote:
>
>>> 3) is there any mode to limit pps and not only bandwidth
>>
>> I no longer remember this from top of my mind, but there’s bunch of good QoS/HQoS presentations about ASR 1000 in particular on ciscolive.com that you can use as reference.
>
> police rate x pps

Just checked this on 17.x based release (3k = 3000 for this example):

rtr-edge(config-pmap-c)#police rate 3k ?
account Overhead Accounting
bps Treat 'rate' value in bits-per-second
burst Specify 'burst' parameter
conform-action action when rate is less than conform burst
cps Treat 'rate' value in cells-per-second
peak-rate Specify peak rate or PCR for single-level ATM 4.0 policer policies
pps Treat 'rate' value in packets-per-second
<cr> <cr>

--
./
_______________________________________________
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/

Thanks
I would try to apply both Bps OR pps if possible

Cheers

Il Mer 8 Set 2021, 15:51 Lukasz Bromirski <lukasz@bromirski.net> ha scritto:

> Saku is always on point ;)
>
> > On 8 Sep 2021, at 15:31, Saku Ytti <saku@ytti.fi> wrote:
> >
> > On Wed, 8 Sept 2021 at 16:30, Lukasz Bromirski <lukasz@bromirski.net>
> wrote:
> >
> >>> 3) is there any mode to limit pps and not only bandwidth
> >>
> >> I no longer remember this from top of my mind, but there’s bunch of
> good QoS/HQoS presentations about ASR 1000 in particular on ciscolive.com
> that you can use as reference.
> >
> > police rate x pps
>
> Just checked this on 17.x based release (3k = 3000 for this example):
>
> rtr-edge(config-pmap-c)#police rate 3k ?
> account Overhead Accounting
> bps Treat 'rate' value in bits-per-second
> burst Specify 'burst' parameter
> conform-action action when rate is less than conform burst
> cps Treat 'rate' value in cells-per-second
> peak-rate Specify peak rate or PCR for single-level ATM 4.0
> policer policies
> pps Treat 'rate' value in packets-per-second
> <cr> <cr>
>
> --
> ./
_______________________________________________
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/

Hi
just tested and police rate x pps is only applicable to control plane

Cheers

Il giorno mer 8 set 2021 alle ore 15:51 Lukasz Bromirski <
lukasz@bromirski.net> ha scritto:

> Saku is always on point ;)
>
> > On 8 Sep 2021, at 15:31, Saku Ytti <saku@ytti.fi> wrote:
> >
> > On Wed, 8 Sept 2021 at 16:30, Lukasz Bromirski <lukasz@bromirski.net>
> wrote:
> >
> >>> 3) is there any mode to limit pps and not only bandwidth
> >>
> >> I no longer remember this from top of my mind, but there’s bunch of
> good QoS/HQoS presentations about ASR 1000 in particular on ciscolive.com
> that you can use as reference.
> >
> > police rate x pps
>
> Just checked this on 17.x based release (3k = 3000 for this example):
>
> rtr-edge(config-pmap-c)#police rate 3k ?
> account Overhead Accounting
> bps Treat 'rate' value in bits-per-second
> burst Specify 'burst' parameter
> conform-action action when rate is less than conform burst
> cps Treat 'rate' value in cells-per-second
> peak-rate Specify peak rate or PCR for single-level ATM 4.0
> policer policies
> pps Treat 'rate' value in packets-per-second
> <cr> <cr>
>
> --
> ./
_______________________________________________
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/

Aww. For competitive analysis this is supported in MX Trio (actually
my RLI) and PTX Triton (but not Paradise, hw limit, unsure if SW for
Triton exists yet, haven't tested.).

Definitely no reason why ASR1k could not support it if you have
leverage towards vendor.




On Thu, 9 Sept 2021 at 20:02, james list <jameslist72@gmail.com> wrote:
>
> Hi
> just tested and police rate x pps is only applicable to control plane
>
> Cheers
>
> Il giorno mer 8 set 2021 alle ore 15:51 Lukasz Bromirski <lukasz@bromirski.net> ha scritto:
>>
>> Saku is always on point ;)
>>
>> > On 8 Sep 2021, at 15:31, Saku Ytti <saku@ytti.fi> wrote:
>> >
>> > On Wed, 8 Sept 2021 at 16:30, Lukasz Bromirski <lukasz@bromirski.net> wrote:
>> >
>> >>> 3) is there any mode to limit pps and not only bandwidth
>> >>
>> >> I no longer remember this from top of my mind, but there’s bunch of good QoS/HQoS presentations about ASR 1000 in particular on ciscolive.com that you can use as reference.
>> >
>> > police rate x pps
>>
>> Just checked this on 17.x based release (3k = 3000 for this example):
>>
>> rtr-edge(config-pmap-c)#police rate 3k ?
>> account Overhead Accounting
>> bps Treat 'rate' value in bits-per-second
>> burst Specify 'burst' parameter
>> conform-action action when rate is less than conform burst
>> cps Treat 'rate' value in cells-per-second
>> peak-rate Specify peak rate or PCR for single-level ATM 4.0 policer policies
>> pps Treat 'rate' value in packets-per-second
>> <cr> <cr>
>>
>> --
>> ./



--
++ytti
_______________________________________________
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/

On 9/9/21 20:04, Saku Ytti wrote:

> Definitely no reason why ASR1k could not support it if you have
> leverage towards vendor.

With Cisco putting a lot more effort into IOS XR, I really wonder if the
ASR1000 and other platforms based on IOS XE will be around in the
medium-to-long term.

Mark.
_______________________________________________
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/

On Fri, 10 Sept 2021 at 14:53, Mark Tinka <mark@tinka.africa> wrote:

> With Cisco putting a lot more effort into IOS XR, I really wonder if the
> ASR1000 and other platforms based on IOS XE will be around in the
> medium-to-long term.

Didn't they just release next-gen catalyst switches and isr cpes
(rebranded as catalyst?) with IOS-XE?

--
++ytti
_______________________________________________
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/

Saku, Mark,

> On 10 Sep 2021, at 14:38, Saku Ytti <saku@ytti.fi> wrote:
>
> On Fri, 10 Sept 2021 at 14:53, Mark Tinka <mark@tinka.africa> wrote:
>
>> With Cisco putting a lot more effort into IOS XR, I really wonder if the
>> ASR1000 and other platforms based on IOS XE will be around in the
>> medium-to-long term.
>
> Didn't they just release next-gen catalyst switches and isr cpes
> (rebranded as catalyst?) with IOS-XE?

IOS-XE is here to stay :) Indeed, there’s “dumbed down” version of it for SD-WAN, and they’re being slowly unified with normal IOS-XE being adopted to work in “centralized” (vs “autonomous”) mode. That’s not “autonomous” like with the Autonomic Networking feature from some years back, it’s “normal” IOS-XE.

From hardware perspective, yes, UADP (Catalyst/switches) and QFP (Catalyst/ASR/routers) can handle a lot of fancy QoS duties, and doing pps/bps at the same time would be just enhancement. PPS limit for normal traffic seems to be less popular as Customers usually care more about bandwidth/throughput than PPS, while PPS is *very* important and more applicable for Control-Plane protection duties, as all processing is PPS-bound obviously.

@James - please reach out to your account team to request such feature.

--
?ukasz Bromirski
CCIE R&S/SP #15929, CCDE #2012::17
_______________________________________________
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/

On 9/10/21 14:38, Saku Ytti wrote:

> Didn't they just release next-gen catalyst switches and isr cpes
> (rebranded as catalyst?) with IOS-XE?

It wouldn't be the first time Cisco had different camps competing for
direction, internally.

Some of the features I have asked for on IOS XE in the past have been
declined on the basis that many IOS XE-based platforms will be moving to
IOS XR.

Maybe this only affects routers, and not switches. Not sure how the NX
OS team feel about IOS XE switches :-).

Mark.
_______________________________________________
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/

On 9/10/21 17:50, Lukasz Bromirski wrote:

> IOS-XE is here to stay :) Indeed, there’s “dumbed down” version of it for SD-WAN, and they’re being slowly unified with normal IOS-XE being adopted to work in “centralized” (vs “autonomous”) mode. That’s not “autonomous” like with the Autonomic Networking feature from some years back, it’s “normal” IOS-XE.
>
> From hardware perspective, yes, UADP (Catalyst/switches) and QFP (Catalyst/ASR/routers) can handle a lot of fancy QoS duties, and doing pps/bps at the same time would be just enhancement. PPS limit for normal traffic seems to be less popular as Customers usually care more about bandwidth/throughput than PPS, while PPS is *very* important and more applicable for Control-Plane protection duties, as all processing is PPS-bound obviously.
>
> @James - please reach out to your account team to request such feature.

Thanks, Lukasz.

But with respect, this is one of the reasons I am changing all our gear
over to Juniper. The messaging from Cisco depends on who you speak to,
and when. Last year with our AM team was horrible, trying to get
features into the ASR920, and being told that the NCS540 is where all
focus is going; so, sorry!

This may or may not have been true last year. This may or may not be
true this year. But I can't build a business on this uncertainty.

I'm not moaning at you, just to be clear :-).

Mark.
_______________________________________________
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/

Mark,

> On 10 Sep 2021, at 17:57, Mark Tinka <mark@tinka.africa> wrote:
>
> On 9/10/21 14:38, Saku Ytti wrote:
>
>> Didn't they just release next-gen catalyst switches and isr cpes
>> (rebranded as catalyst?) with IOS-XE?
>
> It wouldn't be the first time Cisco had different camps competing for direction, internally.
>
> Some of the features I have asked for on IOS XE in the past have been declined on the basis that many IOS XE-based platforms will be moving to IOS XR.

You may be talking about ASR 903/907, which indeed changed into NCS 540 (XR based) and NCS 560 (also XR based). NCS 520 is IOS-XE based though given the positioning of the platform (access).

> Maybe this only affects routers, and not switches. Not sure how the NX OS team feel about IOS XE switches :-).

NX OS teams is virtualizing everything right now.

There are no plans to introduce IOS-XE to NX-OS switches that I am aware of.

--
?ukasz Bromirski
CCIE R&S/SP #15929, CCDE #2012::17
_______________________________________________
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/

On 9/10/21 18:04, Lukasz Bromirski wrote:

> You may be talking about ASR 903/907, which indeed changed into NCS 540 (XR based) and NCS 560 (also XR based).

No, I was asking for the ASR920.


> NCS 520 is IOS-XE based though given the positioning of the platform (access).

Feature-wise, sounds like the ASR920 would still be miles ahead, non?



> NX OS teams is virtualizing everything right now.
>
> There are no plans to introduce IOS-XE to NX-OS switches that I am aware of.

I mean the other way around...

Mark.
_______________________________________________
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/

Mark,

I’m from a different BU, but overall - yes, I remember some of the discussions we’ve had in the past. I’m very sorry it turned out this way.

Unfortunately, some of the decisions are not made on single-platform level, and I do get you’re frustrated because either there’s no one to talk to, answers are not satisfactory or there’s simply black hole - no answers.

Just for everyone to know - SP team changed the way they process feature requests from Customers and Account Teams. Tools by themselves won’t solve any problem, but right now it should be much easier to track all of the requests received across the board. If you, like Mike, are frustrated with the suggestions or requests falling to „deaf ears”, please try once again.

And hey - solid competition is what can move us all forward :)

--
./

> On 10 Sep 2021, at 18:16, Mark Tinka <mark@tinka.africa> wrote:
>
> ?
>
>> On 9/10/21 17:50, Lukasz Bromirski wrote:
>>
>> IOS-XE is here to stay :) Indeed, there’s “dumbed down” version of it for SD-WAN, and they’re being slowly unified with normal IOS-XE being adopted to work in “centralized” (vs “autonomous”) mode. That’s not “autonomous” like with the Autonomic Networking feature from some years back, it’s “normal” IOS-XE.
>>
>> From hardware perspective, yes, UADP (Catalyst/switches) and QFP (Catalyst/ASR/routers) can handle a lot of fancy QoS duties, and doing pps/bps at the same time would be just enhancement. PPS limit for normal traffic seems to be less popular as Customers usually care more about bandwidth/throughput than PPS, while PPS is *very* important and more applicable for Control-Plane protection duties, as all processing is PPS-bound obviously.
>>
>> @James - please reach out to your account team to request such feature.
>
> Thanks, Lukasz.
>
> But with respect, this is one of the reasons I am changing all our gear over to Juniper. The messaging from Cisco depends on who you speak to, and when. Last year with our AM team was horrible, trying to get features into the ASR920, and being told that the NCS540 is where all focus is going; so, sorry!
>
> This may or may not have been true last year. This may or may not be true this year. But I can't build a business on this uncertainty.
>
> I'm not moaning at you, just to be clear :-).
>
> Mark.
_______________________________________________
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/

Thanks, Lukasz.

For clarity, my requests didn't fall on deaf ears. The local AM team
escalated all the way to the TME's and BU heads in San Jose, and they
gave the answer to move to the NCS540 because the ASR920 is on its way out.

Very possible that things changed since then, which would be great for
customers. Glad to hear that you, indeed. But we are way down our path
to migrate away now.

That said, we still do like the CSR1000v very much as our out-of-path
RR. Considering the current code is full of great features, many of
which we use and many that we don't, we'd be keeping that anyway even if
IOS XE were to ever disappear :-).

Trying to run Junos or IOS XR as an RR just hurts my eyes. So I'll give
IOS XE that :-).

Mark.

On 9/10/21 18:25, ?ukasz Bromirski wrote:
> Mark,
>
> I’m from a different BU, but overall - yes, I remember some of the discussions we’ve had in the past. I’m very sorry it turned out this way.
>
> Unfortunately, some of the decisions are not made on single-platform level, and I do get you’re frustrated because either there’s no one to talk to, answers are not satisfactory or there’s simply black hole - no answers.
>
> Just for everyone to know - SP team changed the way they process feature requests from Customers and Account Teams. Tools by themselves won’t solve any problem, but right now it should be much easier to track all of the requests received across the board. If you, like Mike, are frustrated with the suggestions or requests falling to „deaf ears”, please try once again.
>
> And hey - solid competition is what can move us all forward :)
>

_______________________________________________
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/