IPoE Session disconnect via COA asr 9k

[TuralLachinov]

Hi,

I want to disconnect IPoE session from Radius via COA, but still un successfull,

Is there anybody can help me ?

Config:

policy-map type control subscriber BNG-PM
 event session-start match-first
  class type control subscriber IPoE_CGN do-until-failure
   10 activate dynamic-template IPoE-TPL
   20 authorize aaa list default format USERNAME-FORMAT password cisco
   30 activate dynamic-template IP_QOS_TPL2
   40 activate dynamic-template POLICY-10
   50 activate dynamic-template POLICY-20
  !
 !
 event authorization-failure match-first
  class type control subscriber IPoE_CGN do-until-failure
   10 activate dynamic-template IPSUB_UNAUTH_TEMPLATE
   20 set-timer AUTH_TMR_CM 3
  !
 !
 event timer-expiry match-first
  class type control subscriber AUTH_TMR_CM do-until-failure
   10 disconnect

=========================================

interface Bundle-Ether1.515
 ipv4 point-to-point
 ipv4 unnumbered Loopback100
 arp learning disable
 service-policy type control subscriber BNG-PM
 ipsubscriber ipv4 l2-connected
  initiator dhcp
 !
 encapsulation ambiguous dot1q 515 second-dot1q 2000-2050

===================================================

Radius COA Command:

echo "cisco-avpair='subscriber:command=account-logoff',acct-session-id=${ID}"         | radclient -x ${NAS}:1700  coa        ${Secret}

====================================================

Debug on the ASR 9k says:

Unable to get attributes from COA context

Please help:

Regards

Tural

[xthuijs]

hi tural,

few things here, by default when a session for IPoE/dhcp trigger comes online it may be authorized (when the directive of aaa authorization... is used), but its state is unauthenticated.

In order to do an account logoff, you need it first to be logged-on. this is done via a COA request with an account-logon directive that provides a username/password to be authenticated against radius.

The next item is that you need to provide instructions in the account-logoff event to disconnect the session. Remember that here the subscriber context is gone, so the user will not be able to forward traffic against his subscriber interface and now will hit the access interface! This as the dhcp lease is not released in this scenario yet!

For ipsubs I tend to prefer to apply an HTTP redirect and or a restrictive acl but maintain the sub context otherwise it may be confusing to the user having an address not being able to forward any traffic.

Sample output to what I meant on the authorization/authenticated state:

Interface:                Bundle-Ether100.2.ip21
Circuit ID:               000400020064
Remote ID:                testme
Type:                     IP: DHCP-trigger
IPv4 State:               Up, Mon Jan 12 11:42:12 2015
IPv4 Address:             172.28.15.1, VRF: default
Mac Address:              0006.2aaa.2438
Account-Session Id:       00000178
Nas-Port:                 32
User name:                0006.2aaa.2438#000400020064#testme
Outer VLAN ID:            2
Subscriber Label:         0x00000077
Created:                  Mon Jan 12 11:42:11 2015
State:                    Activated
Authentication:           unauthenticated <<< user is not account logon!
Authorization:            authorized <<<<<radius author passed, but just based on mac/RID etc
Access-interface:         Bundle-Ether100.2
Policy Executed:
policy-map type control subscriber ipsub_fancy_auth
  event Session-Start match-first [at Mon Jan 12 11:42:11 2015]
    class type control subscriber DHCP do-until-failure [Succeeded]
      5 activate dynamic-template IPSUB [Succeeded]
      10 authorize aaa list default [Succeeded] <<<<<<<<< USER passed the radius request!
Session Accounting:        
  Acct-Session-Id:          00000178
  Method-list:              default
  Accounting started:       Mon Jan 12 11:42:12 2015
  Interim accounting:       Off
Last COA request received: unavailable

[xthuijs]

I forgot to mention that instead of doing the account logoff, you can also send a RADIUS POD request. COA is code 43, POD is code 40 as packet type in the radius header.

You can use the COA tool on the support forums (google asr9000 change of authorization) which is a COA tool that has the ability to send POD requests also.

xander

[TuralLachinov]

Hi Alexander,

You are always first to anwser and trying to help,thank you very much for this,really appriciate it.

As I mentioned I send POD request on the radius through COA with the help of the below command.

" echo "cisco-avpair='subscriber:command=account-logoff',acct-session-id=${ID}"         | radclient -x ${NAS}:1700  coa        ${Secret} "

And I see on the asr debug POD request is coming,asr receives the request,but cannot understand it.

In the debug Asr replies as " Unable to get attributes from COA contaxt " which i do not understand.

May be I have to add account-logon and account-logoff ?

But for redirect we do not use any authentication, just only redirect to one web site.

Regards

Tural

[xthuijs]

hey tural, thanks! :)

just to make sure, the request you send is a COA request for an account logoff, it is not a POD disconnect request. I felt it is important to make that distinction as both these actions are treated differently...

A COA request (type code 43) for an account logoff can only be done on logged on sessions, eg when the stated is authenticated

Also the account logoff needs to have a handler in the control policy that takes that event and attaches the action of "disconnect" to it:

event account-logoff

class type control subscriber <class>

10 disconnect

A Packet of disconnect, type code 40 needs a session key (eg the accounting session ID) only and will kill the subscriber and won't need an event handler in the control policy.

Based on the error message you describe I think that maybe the 2 attributes in your COA request are concatenated as opposed to sent as 2 individual attributes.

a debug radius detail will help with the decoded VSA's. Note that VSA decoding prior to 513 is not there, so you probably wnt to run 513 for this exercise.

Also for a COA/POD tool check this one:

https://supportforums.cisco.com/document/64681/using-coa-change-authorization-access-and-bng-platforms

also finally make sure that the session ID is properly inserted in the request with the leading zero's. attr44 wants to see (in most releases of XR) the full 8 chars that composes the acct-session-id.

cheers

xander

[TuralLachinov]

Great Explanation Alex,

Now it is clear to me the difference between COA request and POD disconnect.

For POD request I will not need an event handler in the comtrol-policy,this is what I needed.Because I just need to be able to disconnect sessions for administrative purposes.

Inorder to understand why ASR do not understand the attr. in the COA context I need to upgrade the Ios to 5.1.3 ?Cause I am running 5.1.2 now.

Regards

Tural

[xthuijs]

Awesome! glad I we sorted that :)

yeah 513 is an overall better release I would recommend, it is also an extended maintenance release with lots of smu support and large user base.

The radius debug for VSA is described with CSCuh48079  ASR9K BNG radius debug can not interpret cisco AVpair

and this fix is only in 513 onwards... it doesn't affect operations this one, it is merely the decoding of the vsa values in the debug to verify and see what the bNG receives.

cheers

xander

[TuralLachinov]

Yes,you are always helpfull,many thanks :)

Tomorrow I will upgrade it to 513 and come back with what I have received in the debug.

Thanks again.

Regards

Tural

[TuralLachinov]

Hi Alex,

Today I tried to send POD from Radius and it worked nicely without even upgrading. 

POD Request:

./coa_lin  -n 10.0.0.17 -p 3799  -k test -d  -1 44,"acct-session-id=000014f6"

ASR Debug:

RP/0/RSP0/CPU0:FTTXBNG#RP/0/RSP0/CPU0:Jan 14 04:32:55.493 : radiusd[1114]: Received COA/POD request from 10.0.0.18 and port 35825
RP/0/RSP0/CPU0:Jan 14 04:32:55.493 : radiusd[1114]: Dynamic Authorization Clientconfiguration not found. Using globally configured secret.
RP/0/RSP0/CPU0:Jan 14 04:32:55.493 : radiusd[1114]: DA Server : Listening on Port <3799>
RP/0/RSP0/CPU0:Jan 14 04:32:55.493 : radiusd[1114]: DA Server : Global key <test>
RP/0/RSP0/CPU0:Jan 14 04:32:55.493 : radiusd[1114]: DA Clients : VRF's = 1 : Client IP's = 1
RP/0/RSP0/CPU0:Jan 14 04:32:55.493 : radiusd[1114]: DA Clients : 
RP/0/RSP0/CPU0:Jan 14 04:32:55.493 : radiusd[1114]: [0] VRF Number : <0x60000000>
RP/0/RSP0/CPU0:Jan 14 04:32:55.493 : radiusd[1114]:    0) IP : <10.0.0.18> <A000012> : <>
RP/0/RSP0/CPU0:Jan 14 04:32:55.493 : radiusd[1114]: Total len = 46, Radius len = 46
RP/0/RSP0/CPU0:Jan 14 04:32:55.493 : radiusd[1114]: Message authenticator validation: PASS
RP/0/RSP0/CPU0:Jan 14 04:32:55.920 : radiusd[1114]: vrfidtonamelookup for vrf 1610612736(60000000)- No error
RP/0/RSP0/CPU0:Jan 14 04:32:55.921 : radiusd[1114]: Server 10.0.0.18/1812/1813 is UP  & Quarantined: NO
RP/0/RSP0/CPU0:Jan 14 04:32:55.921 : radiusd[1114]: Calling best local address using daemon address=10.0.0.18
RP/0/RSP0/CPU0:Jan 14 04:32:55.921 : radiusd[1114]: NAS best local address = 10.0.0.17
RP/0/RSP0/CPU0:Jan 14 04:32:55.926 : radiusd[1114]: Total len = 20, Radius len = 20
RP/0/RSP0/CPU0:Jan 14 04:32:55.926 : radiusd[1114]:   COA: Received Command Handler response from AAA Base.
RP/0/RSP0/CPU0:Jan 14 04:32:55.926 : radiusd[1114]: Response code is RAD_PK_DISCONNECT_REQUEST_ACK

Thank you very much for help

Regards

Tural

[xthuijs]

Awesome!! thanks for letting me know Tural.

I noticed that the COA doc has all the old(er) versions of the tool there also, some artifact when the forums migrated frome jive to drupal last year I guess. Wanted to make sure you have the v3.0 which is my latest version of that tool.

cheers!

xander

[TuralLachinov]

yes Alex,

We used the latest version. 

One more point - It also worked with the below COA request command even without and event in the control policy :

echo "cisco-avpair='subscriber:command=account-logoff',acct-session-id=${ID}" | radclient -x ${NAS}:3799 coa        ${Secret_fttx}

I am happy with this, thank you very much:

======================================================

There is another thing that I would like to know your advice:

I am using http redirect for just notification purposes to IPOE Clients when they are out of balance. We do not use any authentication.

When their balance is over we just redirect all the requests to one Web site,

But it seems not working correctly. I redirect http requests, but not https requests.

What would you recommend ?

ipv4 access-list 120
 30 permit tcp any any eq www
 40 permit tcp any any eq 443

type service IPSUB_UNAUTH_TEMPLATE
  service-policy type pbr L4-REDIRECT

 event authorization-failure match-first
  class type control subscriber IPoE_CGN do-until-failure
   10 activate dynamic-template IPSUB_UNAUTH_TEMPLATE

Regards

Tural

[xthuijs]

aha I see Tural. yeah for the logoff, in the release you have currently the event logoff has a default action "disconnect" hence it need not to be done specifically. I recall that this changed however at some point. a debug subscriber manager policy <cr> and class-eval will show you the policy evaluation and execution of the actions, nice for tracing.

As for the redirect, as I dont have the full config for the http-r section here, common problems with that are:

- the redirect class includes the server we are redirecting to, this results in that a redirect to the portal will result in a redirect to the portal :) So you need to exclude from the redirect traffic the server address of the portal.

- https can't be intercepted easily as it will create "policy" violations on the browser. we're looking at solutions for this, but this is not straight forward. intercepting https today can't be done easily.

regards

xander

[TuralLachinov]

Hi Alex, 

How are you ? I think something is wrong here, I would like to know your recommends for the configuration.

Just for information we do not use web authentication, it is just redirection.

Config:

class-map type traffic match-any IPSUB_PERMIT_CLASS
 match access-group ipv4 110 
 end-class-map
!
class-map type traffic match-all HTTP_TRAF_REDIRECT_CLASS
 match access-group ipv4 120 
 end-class-map
===================================================================

policy-map type pbr L4-REDIRECT
 class type traffic IPSUB_PERMIT_CLASS 
  transmit
 !
 class type traffic HTTP_TRAF_REDIRECT_CLASS 
  http-redirect http://x.x.x.x
 !
 class type traffic class-default 
 !
 end-policy-map
!
policy-map type pbr NO-L4-REDIRECT
 class type traffic NO-L4-REDIRECT 
  transmit
 !
 class type traffic class-default 
 !
 end-policy-map

======================================================================

type service NO-L4-REDIRECT
  service-policy type pbr NO-L4-REDIRECT
  accounting aaa list ACCT-LIST type session periodic-interval 60
 !
 type service IPSUB_UNAUTH_TEMPLATE
  service-policy type pbr L4-REDIRECT
  accounting aaa list ACCT-LIST type session periodic-interval 60

==================================================================

policy-map type control subscriber BNG-PM
 event session-start match-first
  class type control subscriber IPoE_CGN do-until-failure
   10 activate dynamic-template IPoE-TPL
   20 authorize aaa list default format USERNAME-FORMAT password cisco
   30 activate dynamic-template IP_QOS_TPL2
   40 activate dynamic-template POLICY-10
   50 activate dynamic-template POLICY-20
  !
 !
 event authorization-failure match-first
  class type control subscriber IPoE_CGN do-until-failure
   10 activate dynamic-template IPSUB_UNAUTH_TEMPLATE
  !
 !
 end-policy-map
!
end

=========================================================================

ipv4 access-list 110
 10 permit icmp any any
 20 permit udp any any
 30 permit tcp any host x.x.x.x eq www
!
ipv4 access-list 120
 30 permit tcp any any eq www
 40 permit tcp any any eq 443
!

Regards

Tural

[xthuijs]

The anatomy of your config looks fine there, although you don't need this:

type service NO-L4-REDIRECT
  service-policy type pbr NO-L4-REDIRECT <<<

it wastes pps cycles evaluating PBR, while we always transmit it, so we can improve our pps omitting that.

I have 2 screenshots attached to this message with more detail.

If it is not working, we need to evaluate the PBR application to the session, traffic capturing and redirection etc, a debug subscriber manager policy class-eval will be the first thing to check.

regards

xander

ps. I edited your original message to remove the address from the redirect to x.x.x.x

[TuralLachinov]

Hi Alex,

How are you?

Is https redirect possible or it is not supporting on asr9k ?

So my http redirect is working, but I see https request is not beeing redicted.Is it asr9k problem ?

Config:

class-map type traffic match-any IPSUB_PERMIT_CLASS
 match access-group ipv4 110 
 end-class-map
!
class-map type traffic match-all HTTP_TRAF_REDIRECT_CLASS
 match access-group ipv4 120 
 end-class-map
===================================================================

policy-map type pbr L4-REDIRECT
 class type traffic IPSUB_PERMIT_CLASS 
  transmit
 !
 class type traffic HTTP_TRAF_REDIRECT_CLASS 
  http-redirect http://x.x.x.x
 !
 class type traffic class-default 
 !
 end-policy-map
!

======================================================================
 !

dynamic-template 

!
 type service IPSUB_UNAUTH_TEMPLATE
  service-policy type pbr L4-REDIRECT
  accounting aaa list ACCT-LIST type session periodic-interval 60

==================================================================

policy-map type control subscriber BNG-PM
 event session-start match-first
  class type control subscriber IPoE_CGN do-until-failure
   10 activate dynamic-template IPoE-TPL
   20 authorize aaa list default format USERNAME-FORMAT password cisco
  !
 !
 event authorization-failure match-first
  class type control subscriber IPoE_CGN do-until-failure
   10 activate dynamic-template IPSUB_UNAUTH_TEMPLATE
  !
 !
 end-policy-map
!
end

=========================================================================

ipv4 access-list 110
 10 permit icmp any any
 20 permit udp any any
 30 permit tcp any host x.x.x.x
 40 permit tcp host x.x.x.x any
!
ipv4 access-list 120
 10 permit tcp any eq www any
 20 permit tcp any eq 443 any
 30 permit tcp any any eq www
 40 permit tcp any any eq 443
!

Kindly

Tural