This document provides an overview of Vendor Specific attributes that can be used in the ASR9000 BNG solution. They can either be used as part of the Access Accept Radius message or COA requests to change the behavior of the session.
police-rpct(<conform-rate-in-pct>,<conform-burst-in-us>,<exceed-rate-in-pct>,<exceed-burst-in-us>, <conform-action>,<exceed-action>, <violate-action>)
police(<conform-rate-in-kbps>,<conform-burst-in-kBytes>,<exceed-rate-in-kbps>,<exceed-burst-in-kbytes>, <conform-action>,<exceed-action>, <violate-action>)
authentication cpe12 CoA cisco123
attribute 44 “<string>” <<< Accounting Session ID
vsa cisco generic 1 string "subscriber:command=account-logon"
vsa cisco generic 1 string "subscriber:command=account-logoff"
(used to change a profile)
vsa cisco generic 1 string "subscriber:command=account-update”
<radius attributes to set/update>
vsa cisco generic 1 string "subscriber:sa=<service-name>”
vsa cisco generic 1 string "subscriber:sd=<service-name>”
All these operations from the first column, report an event to the control policy.
account-logoff Account logoff event
account-logon Account logon event
authentication-failure Authentication failure event
authentication-no-response Authentication no response event
authorization-failure Authorization failure event
authorization-no-response Authorization no response event
exception Exception event
service-start Service start event
service-stop Service stop event
session-activate Session activate event
session-start Session start event
session-stop Session stop event
timer-expiry Timer expiry event
Accounting session ID is the preferred session identifier. You can also use the framed-ip-address to key on the subscriber and the vrf (if applicable)
Attribute 8: Framed-IP-Address
and starting 4.2.1:
Attribute 8: Framed-IP-Address + AVPair: ip:vrf-id=<vrf name>
Dynamic Template cmd
IP addess source intf
ipv4 unnumbered <interface>
PPP framed address
PPP Address Pool
ppp ipcp peer-address pool <addr pool >
ipv4:addr-pool=<addr pool name>
PPP framed pool
framed-pool=<addr pool name>
PPP framed route
vrf <vrf name>
ppp ipcp dns <pprimary dns ip> <secondary dns ip>
ip:primary-dns=<primary dns ip>
Ip:secondary-dns=<secondary dns ip>
accounting aaa list <method list> type session
accounting aaa list <method list> type session periodic-interval <minutes>
Dual Stack Accnt Start Delay
accounting aaa list <method list> type session dual-stack-delay <secs>
ppp timeout absolute <sec>
timeout idle <sec>
service-policy input <in_mqc_name> shared-policy-instance <spi-name>
service-policy output <out_mqc_name> shared-policy-instance <spi-name>
subscriber:sub-qos-policy-in=<in_mqc_name> [shared-policy-instance <spi-name> ]
subscriber:sub-qos-policy-out=<out_mqc_name> [shared-policy-instance <spi-name>]
subscriber:qos-policy-in=add-class(target policy (class-list) qos-actions-list)
subscriber:qos-policy-in=remove-class(target policy (class-list))
subscriber:qos-policy-out=add-class(target policy (class-list) qos-actions-list)
subscriber:qos-policy-out=remove-class(target policy (class-list))
ipv4 access-group <in_acl_name> in
Ipv4 access-group <out_acl_name> out
ipv6 access-group <in_v6acl_name> in
ipv6 access-group <out_v6acl_name> out
service-policy type pbr <HTTR policy name>
subscriber:sub-pbr-policy-in=<HTTR policy name>
Dynamic Template equivalent config
ppp ipv6cp peer-interface-id <64bit #>
ipv6 nd framed-prefix-pool <name>
DHCP6 (Local Server)
dhcpv6 address-pool <name>
dhcpv6 delegated-prefix-pool <name>
To be configured in DHCPv6 server profile
the following accounting attributes pertaining to packet accounting for the ASR9000 solution, also specific to IPv6
Session input total byte count
Session input total packet count
Session output total byte count
Session output total packet count
Cisco VSA (26,9,1): acct-input-octets-ipv4
Session input IPv4 byte count
Cisco VSA (26,9,1): acct-input-packets-ipv4
Session input IPv4 packet count
Cisco VSA (26,9,1): acct-output-octets-ipv4
Session output IPv4 byte count
Cisco VSA (26,9,1): acct-output-packets-ipv4
Session output IPv4 packet count
Cisco VSA (26,9,1): acct-input-octets-ipv6
Session input IPv6 byte count
Cisco VSA (26,9,1): acct-input-packets-ipv6
Session input IPv6 packet count
Cisco VSA (26,9,1): acct-output-octets-ipv6
Session output IPv6 byte count
Cisco VSA (26,9,1): acct-output-packets-ipv6
Session output IPv6 packet count
Cisco VSA (26,9,1): connect-progress
Indicates Session set up connection progress
RADIUS attribute example for different type of framed-route:
PPPoE V6 route
Framed-IPv6-Route = "45:1:1:1:2:3:4:5/128 :: 4 tag 5”
PPPoE v4 route
Framed-Route = "22.214.171.124 255.255.255.0 0.0.0.0 6 tag 7”
IPoE v4 route
Framed-Route = "vrf vpn1 126.96.36.199/24 vrf vpn1 0.0.0.0 4 tag 5”
router bgp 100
address-family ipv4 unicast
redistribute subscriber <route-policy>
Xander Thuijs CCIE#6775
Principal Engineer, ASR9000
Ah cool! yeah that make sense Artsiom!
nice investigation! :)
CPE —> BOOTREQUEST (REQUEST, ciaddr defined ) —> BNG
BNG —> AAA (request)
BNG <— AAA (Accepted, Service Activate)
CPE <— BOOTREPLY (NAK) <—BNG
CPE —> BOOTREQUEST (DISCOVER ciaddr 0.0.0.0) —> BNG
CPE <— BOOTREPLY (OFFER) <—BNG
AAA Requests are the same, how do you think if control policy can influence this?
Wow, great news. Thank you for this info Xander.
If this recycle time of 1 minute is in 5.1.1 than we can also upgrade to 5.1.2, which should has less bugs.
We are using a pool of /16 (RFC 1918) so this should be ok.
I have a couple of questions for you.
1. We are using a pool with /16. For now there are only 2000 dualstack subscribers (because of those issues). This would mean that you can add a waiting time on 4.3.4 for an ip address greater or equal of 1 minute, right?
2. Do you recommend to switch to 5.1.2? On Cisco download I do not see much SMU's, so it could mean that this release has less bugs than 4.3.4.
3. If we switch to 5.1.2 - do we have to change some pppoe config or is everything the same (I am right now checking the config guide)?
I am afraid of some possible issues which we can not solve in the maintance window, and this would mean that we have to go back to 4.3.4.
4. You probably remember CSCuo70731 - ASR9K/4.3.4:Acct start packet does not contain delegated IPv6 prefixes. If we upgrade to 5.1.2 than this would mean that we have lost this feature?
looks like we are limited a number of replies per discussion, and this may become hard(er) to read, if this continues, maybe we should move it to a new discussion forum topic or something...
1) the waiting time is system defined, today we have no configurable option for it. but with a large pool, you know that that one minute wait time can be managed, so we should be fine. (still believe that your netflow APP is taking the easy way out here...)
2) 512 is only out since end of April. So far it has been doing good. 513 is out end of August which is another EMR. (ext maint release). I would promote that over 512, but if you have to make an action today, 512 is a consideration.
3) I am not aware of any cli changes between 434 and 512 so it should be a straight forward move.
4) this one is targeted for inclusion in 513 also. so that might be the ultimate strategy I think.
Somehow these forum replies are limited to a number of itterations which makes it hard to respond to the actual issue, hopefilly this still comes out ok...
It looks like we are dealing with 2 separate AAA requests, and they are cause by a request and a discover.
This is of course not ideal, so I need to undertand better where these requests are originated from.
a debug subscriber policy manager event/class will help along with a debug radius detail. Together with a config of the subscriber policy and access interface (and version) used.
Probably a tac case is easier at this time to contineu the investigation...
Yeah, it's getting harder to reply. I think that we can finish this discussion after my last question.
I can open a new discussion if it's really necessary.
Guys from netflow app are not replying back, Cisco is more professional!!
Because we can not wait, we will upgrade to 5.1.2. Regarding Ipv6 delegated prefix, we will see what we can do. After this issue the missing IPv6 DP should be nothing. I really hope that customer will not make a hell to us because of this.
Many thanks for your help. This is the 100th time I think :)
Analog question about Service Deactivate.
Can you explain this attributes:
When this attributes are applicable ? (Access-Accept, CoA, another way)
What do this attribute subscriber:command=service-deactivate ?
when you have a dynamic template of the type service, that contains a (set of) feature(s) such as ACL or QOS etc, you can apply them to the user's session to allow them to have that qos profile or traffic permittance/denial defined by the ACL.
At some point, you may want to remove that service because of a usage quota exceed, a time duration expiration etc.
When you want to remove that service, you would use the service-deactivate command directives.
So you can use them in access-accept or coa.
user comes online, fails authentication because we don't recognize the mac addr or the user needs to pay their bill, we apply http redirect to hand him off to a portal to submit a payment.
After this we want to provide normal access so we can service deactivate the HTTP-R.
Or, user got a bonus for a high speed service for 3 hours to watch HD content. After 3 hours a COA request is sent to remove the service that provided this high bw shaper.
few months ago we have finished a PCRF project with scenarios like the example from Xander.
I can try to give you some more technical details about that. I have to contact some colleagues for that. Just ask.
Thanks for answer.
But you don't understand my question right ...
I understand what to do this attributes, but don't undberstand, when i can aplly them ?
Because different documentation contain different information.
What attributes I can use in Access-Accept ?
What attributes I can use in CoA ?
Attribute "subscriber:command=service-deactivate". This attribute triggers the action in policy-map named "event service-stop" ? Example: Radius sends attribute in CoA (or in Access-Accept ?), bng accepts it, then evaluates actions on subscriber session specified in "event service-stop" ? Analog question about attribute "subscriber:command=account-logon".
ah I see, let me see if I can produce a table like that for those atts, that may help indeed.
Service activation at access accept is a newer implementation (52/53 timeframe), so that is why you may have seen different documentation.
Service Activate/Deactivate can be used with COA and Accept
Logon is a COA directive (it doesn't make sense to run that at accept time).
When you act/deact a service it indeed enqueues another event that you can evaluate and trigger on.
I would like to ask you if DHCP Server RADIUS Proxy functionality is supported in IOS-XR/ASR9K BNG.
Yes, it is supported.
hi D! the ios XR dhcp server doesn't a radius proxy precisely like this requirement from the link you mention...
You can however use the radius directly before a dhcp proxy request is made. that is when the dhcp triggered subscriber comes in, IOS-XR can reach out to the radius server and get some attributes back for the session such as address, gateway, class.
while the bng then does a dhcp proxy request, it will merge the response from the dhcp server with the radius attributes for the client.
the vendor class download from radius is nice to be able to steer a pool pick request to the dhcp server.
Thank you both for the quick answers :)
Is there any document describing the functionality in more details or a config guide?
For example, how can I trigger an access request before the DHCP proxy request? In the subscriber control policy map?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: