ASR 512K License

[foad jalali]

thank you for all your help and Support

about 9000 family routers i have a big question that I can't find any answer

I have  a ASR 9006 routerr  that i want to  terminate 512K subscriber on it  but unfortunately  I can't find any license about  512K subscriber

The only license that cisco offer is A9K-BNG-LIC-8K for every Slot or line card

If i have 2 line card that are A9K-MOD80-SE should  i  pre order  only 2 license  ? or more ?

And i want To know what is difference between asr9k-bng-px.pie-5.1.1  and  A9K-BNG-LIC-8K

And If i don’t want to get  license , does my router work as a BNG and how many subscriber does it supports without any license ?

Thank you again

[smailmilak]

Thanks Xander!

I am preparing a presentation for our customer and I have to know the limits of the platform (DS, bundle, Geo-R). Without you and Aleksander Vidakovic I wouldn't have an idea.

We plan to propose Geo-Redundancy and we will get rid of bundle-ethernet because it's more scalable with LC based subscribers.

p.s. ASR 9001-S where one NPU is disabled - are all four integrated 10G ports enabled or only two?

[xthuijs]

you're very welcome Smail! :) yah good call on the geored, solid solution!

oh as for the 9001-S, you have 1 NPU active only, that means only one bay and 2 onboard 10G's.

cheers!

xander

[chatasos]

Xander, can i use 1 x A9K-MOD160-SE in order to reach 4x32k sessions on a single slot?

If yes, what about 4 x A9K-MOD160-SE in an ASR9006 in order to reach (theoretically) 512k sessions?

--

Tassos

[xthuijs]

Hey Tassos, correct with the mod160 you can do that.

Because you have 4 NPU's on that linecard (2 per bay). The interfaces of the MPA (port adapter) are equally shared over the 2 available NPU's.

And indeed there too, if you have 4 MOD160's then you can get to 512k! But that number is in the works for testing etc. The HW will support it.

regards

xander

[Dimitris Kotsilis]

Hi Xander,

According to info received by our local account's system engineer, the max sessions supported in a chassis that were targeted for 2015 have been shifted one year later (2016) still not committed.

So, for now, we can't reach 512K sessions even if we have 4 x MOD160. And by saying "sessions" we mean single stack, since when talking about dual stack the chassis limitation is lower and it's not going to be 512K in the future either.

Concluding

• Best case scenario for Dual Stack sessions: 384K per chassis (target:2106/not committed)
• Current Dual Stack session capacity (committed): 128K per chassis.

Correct?

Regards,

Dimitris

[xthuijs]

Hi Dimitris,

we have successfully done the 256k and even 512k already as a proof of concept, in order to solidify that effort and ensuring that this works in a variety of cases we need more testing obviously and increase capabilities of some processes, as a lab environment is not the same as a real network obviously. Since we believed that hardening the existing implementation at a very robust scale and providing for a few more features had more priority the decision was made to shift the official support for that increased scale out.

So today you have:

256k ipv4, 128k ipv6, 128k dual stack. Sessions per LC will remain at 64k for Typhoon based models. 32k per NPU is a hard limit of the NPU specific TOP (task optimized processor).

The future plan is indeed 512k ipv4, 512k ipv6 and 384k dual stack. (dual stack takes a LOT of resources on the cpu).

regards

xander

[Dimitris Kotsilis]

Thanks for the clarifications Xander :)

Two quick questions:

1. Which version is needed for reaching 256K IPv6 sessions? Is this version considered as stable/recommended for BNG or not yet?
2. Given that our BNG setup is for Dual-Stack but not all sessions are really Dual-Stack (the customer's configuration decides the session type), 128K is the max we can reach? For example lets say that 50% of the sessions terminated in the BNG is IPv4, 45% Dual-Stack and 5% IPv6. Can I reach over 128K in that box?

Cheers

Dimitris

[Dimitris Kotsilis]

Hi Xander.

I need your help once again, since we need to plan our next steps regarding BNG.

I saw the info regarding the BNG scaling of ASR9K in https://supportforums.cisco.com/document/12529621/bng-deployment-scale-guidelines-asr9000-xr-release-524 and it is the same you gave us 6 months ago:

"So today you have:

256k ipv4, 128k ipv6, 128k dual stack. Sessions per LC will remain at 64k for Typhoon based models. 32k per NPU is a hard limit of the NPU specific TOP (task optimized processor)."

Please keep in mind that all the following questions are about Dual-Stack sessions

1. Is there a way I can go over 128K PPP in a single chassis today? If not, when it is expected/committed?

2. Is this 64K per linecard limitation still applicable in Typhoon models? If yes, is there any reason for us to buy MOD160 instead of MOD80? Are there any time plans (committed or expected) for achieving 128K Dual Stack in a single MOD160?

3. You said the following about Dual Stack: "dual stack takes a LOT of resources on the cpu". I guess you mean the LC CPU, right? Will RSP440  be enough for 128K DS per slot and 256K (or 512K) DS per chassis or we will have to change RSPs?

4. Given that our BNG setup is for Dual-Stack but not all sessions are really Dual-Stack (the customer's configuration decides the session type), 128K is the max we can reach per chassis today? For example lets say that 50% of the sessions terminated in the BNG are IPv4, 45% Dual-Stack and 5% IPv6. Can we reach over 128K in that box or since our setup is for DS, 128K is the limit?

Thank you in advance,

Dimitris

[xthuijs]

hey dimitris,

some answers:

1) with the existing code versions up to 53x it is still 128k dual stack (256k v4 only). numbers beyond that we are testing with anticipation of 512k/chassis and 384k dual stack. This may require more memory and might very likely leverage the RSP880 (together with typhoon LC's and LC based subscribers). Timeframe 2016.

2) 64k per LC is a test limit, need at minimum 2 NPU's for that (2x32k) NPU 32k limit is hard. A mod160 might be an option for:

    a) having need for more pps performance

    b) if we can qualify in our testing more sessions per LC, that is dependent on:

        x) LC memory (some 16G versions do exist now!)

        y) feature matrix support, which is testing effort.

x is taken care of. y is an unknown at this moment whether this can work at complex feature intersections (eg services, (p)QOS etc).

3) the CPU in question here is determined whether the session's access interface is LC based (phy subinterface) or RP based (when used as bundle, or PWHE access). Any number beyond 128k DS will likely require an RSP880 (because it has more memory) or the need for LC based subs.

4) yes you could, how far it would go, that is probably a test exercise. Main "concern" or part of consideration for these limits is (shared) memory.

Note also that we are now developing BNG on Tomahawk also, allowing for higher scale and more power and 100G access (or 10x10 breakout). Also ISSU is part of the planning. But I am not sure on the need of ISSU conidering we have GEO REDUDANCY.

cheers

xander

[Dimitris Kotsilis]

Thanks for the quick response Xander.

Just a few clarifications regarding your last reply:

1) RSP880 is not an option in the cisco commerce configurator for ASR-9006-AC-V2, although it should be supported based on the datasheet. On the other hand, it is available in the ASR-9904. Do I miss something? Based on https://supportforums.cisco.com/discussion/12377846/rsp-880 I should be able to replace my RSP-440SE with RSP-880SE in my ASR-9006-AC-V2 if needed, right?

2) b) x) Are we talking about MOD or MPA LCs with 16G memory? Is this info (memory in LC) available publicly, in order to make a configuration using the proper LCs?

3) So for LC based sessions, RSP880 is not mandatory? By using LCs with increased memory could we go over 128K in a single chassis with RSP440?

Tomahawk for BNG is overkill, since the less dense is 24 x 10GE, unless the "pay as you grow" model is available ;)

Regards,

Dimitris

[xthuijs]

hey D: The RSP880 can work in the V2 chassis. The TH linecards (may) require extra power for redundancy. Some more detail on the power stuff can be found in the cisco live id 2904 from 2015 san diego.

The 8x100 LC requires the 99xx chassis (for extra fabric links), but the 4x100 can work in the 90xx chassis (possibly requiring extra power).

The LC cpu memory to be 16G, the MPA itself has no memory that needs to be updated, it is really the LC CPU memory that is a factor here (which is 8G by default and is ECO'd to 16G). show mem sum loc will provide the current LC mem configuration.

As for "3" there may be a possibility that that can work, but that would be a testing exercise also. At this moment the plan for increased scale is to leverage the RSP880, regardless of LC or RP based sessions. I will look into that if the increased scale can also be achieved when we do LC based subs, but with the RSP440.

The TH has a native pay as you grow model (with what we call "slices") you can even power down slices you don't need to save on power also.

ps you rated the previous answer as "4", I don't mind, but did we miss anything to your expectation? If so, would like to know so we can improve you see.

cheers

xander

[Dimitris Kotsilis]

So it's weird the configurator doesn't give me the option to add RSP880 in a 90xx chassis. I will check it with our local account team.
Regarding the LC memory, the question is how can we know the amount of memory in a LC before ordering it. Our current MOD80 have 8GB and I cannot find any partNo for upgrading them.

As for the rate, we consider 4/5 as a very good grade. To be honest, in our internal PDR system, "3" is the expected, "4" is more than expected and "5" is exceptional :)

I believe that in Cisco the perspective is different and "5" is the expected and everything below "5" is less than expected. If yes, I will try to use your perspective when rating an answer ;)

[xthuijs]

ah that is interesting, I'll check too with the marketing folks here to see what they planned for, it may be that testing consideration, but I do know that TH can be done in 90xx, I'll get back to you on that too.

haha, yeah that rating system, that is why I don't like that 5 point scale myself. Me being european by origin too, 5 = 10 and nothing is perfect. But yeah in cisco rating 5 is "met expectations" and anything below that is "oh I didn't completely do the trick for ya" :)

Not a prob of course, I strive for perfection and you deserve it, hence the ask :)

cheers!

xander

[Sebastiaan1978]

Hi Xander,

I have a question about an ASR 9904 with 2x RSP880 with and 2x an 8x100GE LC. What is the max number of subscriber sessions (IPoE) for this setup and how do I get to that number? You mentioned a hard 32k limit per NPU (is that limit still valid?) but I can't find how many NPU's there are on the 8x100GE LC, I also don't know if I at least have to use 1, 2, 4 or 8 interfaces per LC to get to the max number of subscriber sessions?

According to the roadmap I saw the max number of subscriber sessions was increasing from 128k to 512k (all LC based), do you have updated information about the max number of sessions for the releases currently available and the releases in the near future (coming year)?

Thank you in advance,

Sebastiaan

[xthuijs]

hi sebastiaan,

the 8x100 or 4x100 have 4 npu's on the LC.

<=XR62 you have 32k sessions per npu, >=XR63 it is 64k/npu in eXR.

there is no limit per-se as to sessions per physical interface. so all sessions can be on the same phy int. however due to the qos chunking we can only have 8k sessions per subinterface. so you'd need 4 ubinterfaces on that phy int to get to 32k subs. those subifs can be a unique/explicit vlan or a range/ambigious.

xander