Per user ACL with RADIUS on ASR9K

[Jordi Smits]

Hello all,

I'm facing some difficulties with RADIUS and the ASR9K platform. We are deploying a couple of 9K's in our network for BNG usage. We are using freeradius as RADIUS servers and the problem I am facing is related to per-user ACL. Most of the VSA's we've tried, function as expected. However, if I try to make this work, then things break.

cisco-avpair += "ip:inacl#1=permit tcp any any"

cisco-avpair += "ip:inacl#2=permit udp any any"

cisco-avpair += "ip:inacl#3=deny icmp any any"

This is just an ACL for testing purposes of course.

The 9K logs (among a lot of normal other things):

RP/0/RSP0/CPU0:Mar 20 16:06:23.585 : radiusd[1107]: Decoding the attribute: Vendor-Specific, aaa_type invalid attribute, flags 0x21

And the session stops after:

RP/0/RSP0/CPU0:Mar 20 16:06:23.588 : PPP-MA[365]: %L2-PPP_MA-4-ERR_AAA_SESSION_IF : Unknown Interface ID 00008820: Unexpected error encountered whilst receiving an activate response: Invalid argument

The 9K is running 4.3.0 with the A9K-9001-AIP-LIC and A9K-BNG-LIC-8K licenses. I find the documentation to be quite unclear on the VSA's. In the article from Xander about 'ASR9000 BNG Training guide setting up PPPoE and IPoE sessions', there is an example with RADIUS using inacl and outacl. In the ASR 9000 BNG configuration guide, release 4.3.x, there is no reference to outacl being a VSA.

RADIUS is working properly. We are using PPPoE and without the per user ACL configuration everything works as expected. Is it possible to use per user ACL on the 9K platform? Could anybody please point me in the right direction?

Thanks,

Jordi Smits

[Andre Gustavo Albuquerque]

Have you tried the sequence below?

cisco-avpair += "ip:inacl=permit tcp any any"

cisco-avpair += "ip:inacl=permit udp any any"

cisco-avpair += "ip:inacl=deny icmp any any"

The last statement seems useless given the implicity deny any any...

Regards

[xthuijs · Accepted solution]

Currently in teh shipping releases we dont have support for per user ACL. That is that the individual ACE's are downloaded from AV pairs.

We can define an ACL on the system and reference that either with Filter-ID (attr11) or the avpairs for inacl/outacl.

And point taken on the VSA support and definition, the official documentation is being updated, may take a bit.

regards

xander

[Jordi Smits]

Thanks for the information.  Defining an ACL on the system and referencing that via RADIUS attributes  works just fine. We have deployed it that way at the moment. Thanks to  your BNG training guide btw.

Do you have any pre-release or unofficial documentation on VSA support?

Thanks,

Jordi

[xthuijs]

Hi Jordi,

glad to hear the guide worked out

I dont have a pre-release for the per user ACL yet.

That will likely come in XR4.3.2 which is still under development.

regards!

xander

[xthuijs]

I just got word that this may not make it in XR4.3.2 due to the low demand of this feature requirement...

Just an FYI.

xander

[olegch]

Hello All,

"Per user ACL" is very valuable feature for SP.  We have plenty of services that are controlled by ACLs and it would be great to have this feature. Are there any plans to implement it ?

[xthuijs]

Hi Olegch,

I totally recongize that. but the thing is with this feature it is a huge burden on hardware that does ACL matching.

Generally, ACL's have a very similar pattern for a user set and if we dont implement this smartly, you could end up with nearly the same ACL numerous time in the TCAM for each subscriber.

So we have to look at some compression algo's and smart ways to do this to make sure the (expensive) resources are used to the optimum.

It is not forgotten, but not a 1-2-3. I am checking with our marketing folks if this is planned for and when it is to be seen.

regards

xander

[Umpri]

Hi colleagues,.. we are facing something similar.

Our operation center have made some statistics in connection with daily customer complains and came to the conclusion that four pppoe session are closed by lost of carrier by day affecting every user.

The following are the BNGASR9K logs that appeared:

RP/0/RSP0/CPU0:Jun 5 12:45:52.010 : PPP-MA[374]: %L2-PPP_MA-4-ERR_AAA_ATTR_IF : Bundle-Ether1.1309308401.pppoe28833: Unexpected error encountered whilst adding AAA attribute type 136 to list: 'AAA ATTR' detected the 'fatal' condition 'Invalid or NULL Parameter in API'

Do you have any suggestion to solve our problem?

Best regards

Javier

[xthuijs]

hey javier,

at this point I have no solution for you other then to remove the ip:inacl#=.... radius vsa.

I am tracking this via : CSCup20620 to be fixed in 513 that will skip the processing of this attribute when present to continue the session without disconnecting.

regards

xander

[Umpri]

Hey Xander!!! .. nice to know about you again.. I really appreciate your later response

You see I have showed our log is... RP/0/RSP0/CPU0:Jun 5 12:45:52.010 : PPP-MA[374]: %L2-PPP_MA-4-ERR_AAA_ATTR_IF : Bundle-Ether1.1309308401.pppoe28833: Unexpected error encountered whilst adding AAA attribute type 136 to list: 'AAA ATTR' detected the 'fatal' condition 'Invalid or NULL Parameter in API'

So you suggest to remove ip:inacl#=... radius vsa...

 Our question here is.. What is the relation of AAA atribute type 136 associated to ip:inacl#=...

I would like to be sure you have understood our problem  ;-)

Regards,

Javier

[xthuijs]

yeah been some time :) Say, The error message is just a side effect of the session getting destroyed and it wants to update some info on an interface no longer there. This is moved to an ltrace as it is informational only in XR511.

There is a different reason for the disconnect. I maybe preemptively assumed that you were focussing on the pu-acl considering this discussion/thread, but if you dont have that vSA, there may be another one that causes it.

Also check in ther adius accounting what the disconnect reason was to get a hint there also. If you can show your radius profile maybe we can say easily which one causes it.

regards

xander