QPPB on ASR9k BNG session

[metal_icer]

Hi all!

Does anybody have any information regarding such feature/implementation. Any info regarding this would be much appriciated.

Thanks,

Hristo

CCIE# 38272

[elnur.mammadov]

Hi Hristo

were you able to do it?

Regards

Elnur

[metal_icer]

Hi, Elnur!

I got confirmation from cisco that QPPB is not available nor currently planned to be implemented for BNG subscriber sessions.

Hristo

CCIE# 38272

[xthuijs]

That is unfortunately correct indeed. QPPB doesnt operate on the subscriber session.

Technically this would be useful if there are peerings on sub interfaces, but alternatively you could

apply it on a core interface and leverage the qos group setting on the prefix for the subscriber side to adjust its rates based on that group setting?

regards

xander

[elnur.mammadov]

Hi Xander,

can you please help me understand this better.

Say I've got a couple of BGP peering at our borders, QoS group 2 and 3, 2 has 10Gbps of bandwidth, 3 has 1Gbps of bandwidth, routes from both peering are iBGPed to a9k along with QPPB , and a9k sets QoS groups properly (pls see below 'show cef' output), this all seems all good to me so far.

Now I can police outgoing traffic from subscriber interface based on the QoS group it originated from no problem, what I struggle to understand is, how do police traffic going to QoS groups from subscriber interface, what is going to classify it? or is it already classified?

In other words for any given IP subscriber session I would to symmetrically limit bandwidth per QoS group, which have been set with QPPB.

Thank you

RP/0/RSP0/CPU0:ironman0#show cef 8.8.8.8
Tue Sep 16 16:51:23.354 Baku
8.8.8.0/24, version 96311, internal 0x14000001 0x0 (ptr 0x9f2578f8) [1], 0x0 (0x0), 0x0 (0x0)
 Updated Aug 16 01:37:10.862
 Prefix Len 24, traffic index 0, precedence n/a, priority 4
 QoS Group: 3
   via [snip], 3 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x9dd54c30 0x0]
    next hop [snip] via [snip]

RP/0/RSP0/CPU0:ironman0#show cef 217.14.96.36
Tue Sep 16 16:51:36.211 Baku
217.14.96.32/27, version 5076003, internal 0x14000001 0x0 (ptr 0xa2ea5b48) [1], 0x0 (0x0), 0x0 (0x0)
 Updated Aug 20 04:32:29.132
 Prefix Len 27, traffic index 0, precedence n/a, priority 4
 QoS Group: 2
   via [snip], 3 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x9dd54c30 0x0]
    next hop [snip] via [snip]

[xthuijs]

the qos-group is a "tag" on the packet that can be used as match clause in a policy-map.

this tag on the packet is available on the downstream to subscriber also if the tag is set on ingress packets received from the core.

so now you can police the qos-group on a per subscriber bases downstream.

you can also have the ingress core interface where the marker happened, police an aggregate of all qos-group 2.

class-map QG2

match qos-group X

policy-map BLA

class QG2

police rate xyz

xander

[elnur.mammadov]

e.g. following applied to a subscriber session will just work for both directions?

class-map match-any GENERIC-INTER-IX
 match qos-group 3
 end-class-map
!
class-map match-any GENERIC-LOCAL-IX
 match qos-group 2
 end-class-map
!
policy-map GENERIC-6MBPS
 class GENERIC-LOCAL-IX
  police rate 100 mbps
  !
 !
 class GENERIC-INTER-IX
  police rate 6 mbps
  !
 !
 class class-default
 !
 end-policy-map
!

[xthuijs]

if the packets are marked ingress on the core facing interface, then this pmap will only work in the downstream to the subscriber.

packets from the subscriber are not marked or tagged (yet).

xander

[elnur.mammadov]

alright, exactly, I have on the core facing interface: 

ipv4 bgp policy propagation input qos-group source

I understand this instructs the box - look at the packet _source_ and classify as per QPPB information you have.

Now there should be a counterpart applied to the session:

ipv4 bgp policy propagation input qos-group destination

Which would instruct the box - look at the packet _destination_ and classify as per QPPB information you have.

right? this way makes much more sense to me, again I might be missing something obvious 

of course we could do all sorts of things on the core facing interface, but it would not be the same...

regards

elnur

[xthuijs]

for the upstream from sub to core you need the qppb on the subscriber indeed, but that is not supported (nor planned).

so you probably want to look at a different classification method for the upstream there.

xander

[elnur.mammadov]

I guess this is due to a hardware (FPGA/ASIC) limitation somewhere, otherwise, honestly, does not make sense to me.

my concern is all our subscriber phy is 1Gbps

if not too much trouble for you, please advise a different method, how can I limit upstream bandwidth per subscriber (not service plan) individually on the upstream, is there an obvious way that i'm missing? 

The only way I can think of, is to mark everything on ingress from the sessions per service plan, and later aggregate limit bandwidth (as you already suggested above) on the egress from the core facing interface, yet not sure if both QPPB source/destination will work on the same interface and policies will have to be adjusted when subscribers are added/removed from service plans.

thank you!

elnur

[xthuijs]

it is not a hw limitation, it is just a lot of ucode that needs to be done to make this happen.the code paths for qppb and subscribers intersect at many levels, hence not easy to combine these 2 within ucode in an efficient way.

considering that it is such a lot of work and no true demand for it, it is not seriously on the roadmap today. that is the honest answer :)

you could define a few services and in these services define a policer inbound.

the classification of the policer is a acl match on prefixes of your liking.

then the user subscribes to these services to gain a controlled/policed access to those services.

cheers

xander

[elnur.mammadov]

thank you for your honest answer:) good man!

ACL with ~1k routes that needs to be maintained somehow (manual/script)

seriously count me in for this to be implemented, it makes life much more easier, adds flexibility, almost magical:) what is the purpose of QPPB otherwise, I mean this game is all about subscribers, the end users, and QPPB works only in one direction:)

Back in 2007, on C7200, it worked even for PPPoE sessions (i know they are not that hardware based).

Is this implemented on CRS or another XR based platform? 

cheers

elnur

[xthuijs]

I see your point, but the 7200 only supports limited number of subs, and its pps rate and bw are also not the same.

so at some point we have to resort to hardware forwarding and that has limitations and restrictions also.

the prob for qppb is that it intersects in various "TOPS" (task optimized processors) in teh bng code path. That means that the packet needs to be looped around for an additional processing. And that affects performance and then there is some code to handle what needs to be done on the packet on a pass. Technically all possible, sure thing! But this one is not something that I can turn around over night quickly.

I would want to recommend to connect with your account team to ahve a business case raised. So our marketing dept can aggregate the various cases together so it can become a compelling feature to develop.

cheers

xander

[metal_icer]

Hi, Elnur!

I want to add that our customer ended with this exact solution - ACL with ~2k prefixes managed manually or semi-manualy with some scripts etc. It is ugly solution but it works so far.

Cheers

Hristo