ASR 1002 ISG ip session

Answered Question
Jul 25th, 2013
User Badges:

Hi,


I am tring configure ip session on ASR 1002 RP1 (with IOS XE asr1000rp1-adventerprisek9.03.09.01.S.153-2.S1.bin).

I want to authorize the session with ip address configured on the interface, but policy section returning error (can not use the source-ip-address as sesison identifier). The only identifer worked is the nas-port.I can not find more information about the identifers that can be used with authorization of different session types. Is this the normal behaviour?



Also I tried to use ip routed session, and this time ip sessoin is not triggering the control policy. Although its look like very simple configuration, I can not fiugre out why its not working.


1 - ip interface session with source-ip-address


policy-map type control TAL_IP_POLICY_RULE

class type control IP_UNAUTH_COND event timed-policy-expiry

  10 service disconnect

!

class type control always event session-start

  1 authorize aaa list pppoe password cisco identifier source-ip-address

  2 set-timer IP_UNAUTH_TIMER 5

!

interface GigabitEthernet0/0/1

ip vrf forwarding INTERNET

ip address 30.30.30.1 255.255.255.0

negotiation auto

service-policy type control TAL_IP_POLICY_RULE

ip subscriber interface

end

!

*Jul 25 00:34:54.183: SSS MGR [uid:255]: Event client-service-request, state changed from wait-for-req to authorizing

*Jul 25 00:34:54.183: SSS PM [42F218DC]: Create context 42F218DC

*Jul 25 00:34:54.183: SSS PM [uid:255][42F218DC]: Authen status update; is now "unauthen"

*Jul 25 00:34:54.183: SSS PM [uid:255][42F218DC]: IDMGR: assert authen status "unauthen"

*Jul 25 00:34:54.183: SSS PM [uid:255][42F218DC]: IDMGR:  send event Session Update

*Jul 25 00:34:54.183: SSS PM [uid:255][42F218DC]: Username key not found in set domain key API

*Jul 25 00:34:54.183: SSS PM [uid:255][42F218DC]: Username key not found in set domain key API

*Jul 25 00:34:54.183: SSS PM [uid:255][42F218DC]: Updated NAS port for AAA ID 276

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]: IDMGR:  send event Session Update

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]: Client block is NULL in get client block with handle 960000FF

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]: Client block is NULL in get client block with handle 960000FF

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]: Updated key list:

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]:   IP-Session-Handle = 3573547261 (D50000FD)

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]:   SHDB-Handle = 1845494015 (6E0000FF)

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]:   IP-Address = 30.30.30.1 (1E1E1E01)

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]:   IP-Address-VRF = IP 30.30.30.1:2

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]:   Final = 1 (YES)

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]:   Access-Type = 14 (IP-Interface)

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]:   Protocol-Type = 4 (IP Access Protocol)

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]:   Media-Type = 2 (IP)

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]:   Authen-Status = 1 (Unauthenticated)

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]:   Nasport = PPPoEoVLAN: slot 0 adapter 0 port 1 IP 192.168.126.230 VPI 0 VCI 0 VLAN 1

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]: Username key not found in set domain key API

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]: Username key not found in set domain key API

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]: Client block is NULL in get client block with handle 960000FF

*Jul 25 00:34:54.184: SSS PM [uid:255][42F218DC]: Client block is NULL in get client block with handle 960000FF

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]: Updated key list:

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   IP-Session-Handle = 3573547261 (D50000FD)

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   SHDB-Handle = 1845494015 (6E0000FF)

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   IP-Address = 30.30.30.1 (1E1E1E01)

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   IP-Address-VRF = IP 30.30.30.1:2

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   Final = 1 (YES)

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   Access-Type = 14 (IP-Interface)

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   Protocol-Type = 4 (IP Access Protocol)

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   Media-Type = 2 (IP)

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   Authen-Status = 1 (Unauthenticated)

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   Nasport = PPPoEoVLAN: slot 0 adapter 0 port 1 IP 192.168.126.230 VPI 0 VCI 0 VLAN 1

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]:   Session-Handle = 1006633215 (3C0000FF)

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]: SM Policy invoke - Service Selection Request

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]: Access type IP-Interface: final key

*Jul 25 00:34:54.185: SSS PM: Successfully added key SUBTYPE_CONVERTED as FALSE

*Jul 25 00:34:54.185: SSS PM [uid:255][42F218DC]: RULE: Looking for a rule for event session-start

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE:  Intf CloneSrc Gi0/0/1: service-rule any: TAL_IP_POLICY_RULE

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE:   Evaluate "TAL_IP_POLICY_RULE" for session-start

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE:    Wrong type "TAL_IP_POLICY_RULE/IP_UNAUTH_COND event timed-policy-expiry"

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE:    Matched "TAL_IP_POLICY_RULE/always event session-start"

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE:    Matched "TAL_IP_POLICY_RULE/always event session-start/1 authorize aaa list pppoe identifier source-ip-address"

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE[0]: Start

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE[0]: TAL_IP_POLICY_RULE/always event session-start/1 authorize aaa list pppoe identifier source-ip-address

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE[0]: Using author method AAA service

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: SIP [IP-Interface] can NOT provide more keys

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE[0]: No more keys

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE[0]: No more keys. Giving LTERM

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE[0]: rule processing error occurred

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: Event <session disconnect>, State: initial-req to end


2 - ip interface session with nas-port

policy-map type control TAL_IP_POLICY_RULE

class type control IP_UNAUTH_COND event timed-policy-expiry

  10 service disconnect

!

class type control always event session-start

  1 authorize aaa list pppoe password cisco identifier nas-port

  2 set-timer IP_UNAUTH_TIMER 5

!


*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: RULE[0]: TAL_IP_POLICY_RULE/always event session-start/1 authorize aaa list pppoe identifier nas-port

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: RULE[0]: Using author method AAA service

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: RULE[0]: Have key combo_keys

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: State: initial-req to check-auth-needed

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: RULE[0]: Using key combo_keys

*Jul 25 00:39:15.912: SSS PM CCM:  Found SHDB handle 0x5F000106 for policy context 0x42F218DC

*Jul 25 00:39:15.912: SSS PM CCM:  [SESSION PM EVENT] Event = NEW-REQUEST (ctx: 0x42F218DC, action: AUTHORIZE)

*Jul 25 00:39:15.912: SSS PM HA:  Dynsess not required shdb = 0x5F000106 spol_ctx = 0x42F218DC

*Jul 25 00:39:15.912: SSS PM CCM:  Set PM HA as not ready (session 0x5F000106) successfully

*Jul 25 00:39:15.912: SSS PM HA:  Adding an action (type AUTHORIZE) into the PM HA queue

*Jul 25 00:39:15.912: SSS PM HA:  Setting current elem, from 0x0 to 0x3D7DABD8

*Jul 25 00:39:15.912: SSS PM CCM:  New bulk session (shdb 0x5F000106), ctx 0x42F218DC, dsess_hdl 0x0, AUTHORIZE OK

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: RULE[1]: Start

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: RULE[1]: TAL_IP_POLICY_RULE/always event session-start/1 authorize aaa list pppoe identifier nas-port

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: Event <send auth>, State: check-auth-needed to authorizing

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: Handling AAA service Authorization

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: Sending AAA request for 'nas-port:192.168.126.230:0/0/1/1'

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: SSS PM: Allocating per-user profile info

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: SSS PM: Add per-user profile info to policy context

*Jul 25 00:39:15.912: SSS AAA AUTHOR [uid:262]: using named author method list "pppoe"

*Jul 25 00:39:15.912: SSS AAA AUTHOR [uid:262]: using set aaa password "cisco"

*Jul 25 00:39:15.912: SSS AAA AUTHOR [uid:262]: Root SIP IP-Interface

*Jul 25 00:39:15.912: SSS AAA AUTHOR [uid:262]:  Enable IP parsing

*Jul 25 00:39:15.912: SSS AAA AUTHOR [uid:262]:  Enable DHCP parsing

*Jul 25 00:39:15.912: SSS AAA AUTHOR [uid:262]:  Enable IP-Interface parsing

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: ACTIVE HANDLE[0]: Snapshot captured in Active context

*Jul 25 00:39:15.912: SSS PM [uid:262][42F218DC]: ACTIVE HANDLE[0]: Active context created

*Jul 25 00:39:15.913: SSS AAA AUTHOR [uid:262]: Event <make request>, state changed from idle to authorizing

*Jul 25 00:39:15.913: SSS AAA AUTHOR [uid:262]: Active key set to combo_keys

*Jul 25 00:39:15.913: SSS AAA AUTHOR [uid:262]: Authorizing key nas-port:192.168.126.230:0/0/1/1

*Jul 25 00:39:15.913: SSS AAA AUTHOR [uid:262]: Set authorization profile type default -  user

*Jul 25 00:39:15.913: SSS AAA AUTHOR [uid:262]: AAA request sent for key nas-port:192.168.126.230:0/0/1/1

*Jul 25 00:39:15.953: SSS AAA AUTHOR [uid:262]: TAL authorisation keys added

*Jul 25 00:39:15.953: SSS AAA AUTHOR [uid:262]: Received an AAA pass


3 - ip subnet session


interface GigabitEthernet0/0/1

ip vrf forwarding INTERNET

ip address 30.30.30.1 255.255.255.0

negotiation auto

service-policy type control TAL_IP_POLICY_RULE

ip subscriber routed

  initiator unclassified ip-address

end



PE-1#sh debu

PE-1#sh debugging

SSS:

  SSS Manager events debugging is on

  SSS packet detail debugging is on

  SSS Manager errors debugging is on

  SSS Manager fsm debugging is on

  SSS AAA authorization event debugging is on

  SSS AAA authorization FSM debugging is on

  all IC debugs debugging is on

  SSS policy all debugs debugging is on

IP Subscriber:

  all IP subscriber debugs debugging is on

PE-1(config)#interface GigabitEthernet0/0/1

PE-1(config-if)# ip subscriber routed

PE-1(config-subscriber)#

*Jul 25 01:06:31.193: IPSUB_DP: [uid:0] IP session message from control plane

*Jul 25 01:06:31.194: IPSUB_DP: [uid:0] Remove config event

*Jul 25 01:06:31.194: IPSUB_DP: [uid:0] FIBSB Required check for GigabitEthernet0/0/1, not required

*Jul 25 01:06:31.196: IPSUB: Config removed from Gi0/0/1: cleaning up its IP sessions.

*Jul 25 01:06:31.196: IPSUB: Skipping cleanup for Gi0/0/1: intf either down, a vtemp, or non-PPP.

PE-1(config-subscriber)#  initiator unclassified ip-address

PE-1(config-subscriber)#

*Jul 25 01:06:36.314: IPSUB: Initiator invoked

*Jul 25 01:06:36.315: IPSUB: Initiator invoked

*Jul 25 01:06:36.315: IPSUB: Initiator Unclassified

*Jul 25 01:06:36.315: IPSUB_DP: [uid:0] IP session message from control plane

*Jul 25 01:06:36.315: IPSUB_DP: [uid:0] Apply config event

*Jul 25 01:06:36.315: IPSUB_DP: [uid:0] FIBSB Required check for GigabitEthernet0/0/1, required

*Jul 25 01:06:36.315: IPSUB_DP: [uid:0] FIBSB Update for GigabitEthernet0/0/1

*Jul 25 01:06:36.315: IPSUB_DP: [uid:0] FIBSB Update, set identifier (1), initiators (2) and ipv6_prefix_len (128) for GigabitEthernet0/0/1

PE-1(config-subscriber)#

PE-1(config-subscriber)#end

PE-1#


Correct Answer by Manuel Rodriguez about 3 years 11 months ago

Hi Deniz,


I did the test in my lab and I can see the same behavior. To be honest, I cannot confirm whether using 'source-ip-address' as identifier for interface sessions is supported. 


When I see at the internal details of the session, I can see the IP address is there as a key:

  Current key list from client        :

    Identifier: IP-Address-VRF = IP 30.30.30.1:0

    Identifier: Converted-Session = 0 (NO)

    Identifier: Protocol-Type = 4 (IP Access Protocol)

    Identifier: Media-Type = 2 (IP)

    Identifier: Authen-Status = 0 (Authenticated)

    Identifier: Nasport = PPPoEoE: slot 0 adapter 1 port 4 IP 0.0.0.0 VPI 0 VCI 0 VLAN 0

    Identifier: Session-Handle = 553648900 (21000304)

    Identifier: AAA-Id = 178070 (0002B796)

    Identifier: Auth-User = "nas-port:0/1/4/0"

    Identifier: IP-Session-Handle = 3774873908 (E1000134)

    Identifier: SHDB-Handle = 503317363 (1E000373)

    Identifier: IP-Address = 30.30.30.1 (1E1E1E01)


However, it seems like during the session establishment, that key cannot be retrieved for some reason. Typically the 'source-ip-address' identifier refers to the source address in the packet for sessions using traffic as first sign of life. Given that, this may be not supported. However, I couldn't find any documentation stating this. For a formal confirmation, I would suggest to open a TAC case so we can involve the development team for a definite answer.


On the other hand, you mentioned that you want to have the nas-port and the IP address to identify the session right? What if you configure 'radius-server attribute 8 include-in-access-req' in the router. By doing this I'm able to have the nas-port as the username and the IP address in the Framed-IP-Address attribute:

28673815: Aug 30 11:16:34.486: RADIUS(0002B79A): Send Access-Request to 10.48.88.121:30645 id 21714/86,len 173

28673816: Aug 30 11:16:34.486: RADIUS:  authenticator 40 5B AE 12 9E 7D 63 B4 - 42 E9 10 E6 5F 4B 42 78

28673817: Aug 30 11:16:34.486: RADIUS:  User-Name           [1]   18  "nas-port:0/1/4/0"

28673818: Aug 30 11:16:34.486: RADIUS:  User-Password       [2]   18  *

28673819: Aug 30 11:16:34.486: RADIUS:  Framed-IP-Address   [8]   6   30.30.30.1


Maybe this can be an option for you?


Best regards.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Manuel Rodriguez Fri, 08/02/2013 - 07:34
User Badges:
  • Cisco Employee,

Hi,


I'm not sure which identifiers can be used for IP interface sessions. However, it's not clear what is the purpose of doing a TAL for an IP interface session since IP interface sessions are static sessions created when the configuration is entered.


Could you let me know what is the goal behind that?


Also, where do you see the error you mentioned ("can not use the source-ip-address as sesison identifier")?


Regards.

Deniz AYDIN Thu, 08/29/2013 - 04:08
User Badges:

Hi Manuel,

Sorry for late response, I was in holiday.


Actually, I am just tring to see usage of ISG IP session features. And I got idea to use these features for static ip interfaces, like our ethernet customers. The most important one is using the radius accounting for metro ethernet services. Normaly, these customers defined as separate L3 interfaces on router (subinterface etc, each one is using different vlan or different physical interface) and its very hard to give service like usage based services to these customer as the usage data cannot be collecedted easliy like radius accounting. My idea is to use ISG ip subs features.


For the authentication part, I dont want any service which is not defined in our customer database (misconfiguration, etc). I tried to auhenticate the source ip address or prefix aloung with nas-port. This can be done with some snmp or eem scripting (which will be based on pull method) but using the TAL for this kind of services will be much more easier if its possible.


I guess,


*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: SIP [IP-Interface] can NOT provide more keys

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE[0]: No more keys

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE[0]: No more keys. Giving LTERM

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: RULE[0]: rule processing error occurred

*Jul 25 00:34:54.186: SSS PM [uid:255][42F218DC]: Event , State: initial-req to end


part of the debug giving the error. Also with source-ip-address configured ISG is not triggering any radius auth req.

Correct Answer
Manuel Rodriguez Fri, 08/30/2013 - 04:18
User Badges:
  • Cisco Employee,

Hi Deniz,


I did the test in my lab and I can see the same behavior. To be honest, I cannot confirm whether using 'source-ip-address' as identifier for interface sessions is supported. 


When I see at the internal details of the session, I can see the IP address is there as a key:

  Current key list from client        :

    Identifier: IP-Address-VRF = IP 30.30.30.1:0

    Identifier: Converted-Session = 0 (NO)

    Identifier: Protocol-Type = 4 (IP Access Protocol)

    Identifier: Media-Type = 2 (IP)

    Identifier: Authen-Status = 0 (Authenticated)

    Identifier: Nasport = PPPoEoE: slot 0 adapter 1 port 4 IP 0.0.0.0 VPI 0 VCI 0 VLAN 0

    Identifier: Session-Handle = 553648900 (21000304)

    Identifier: AAA-Id = 178070 (0002B796)

    Identifier: Auth-User = "nas-port:0/1/4/0"

    Identifier: IP-Session-Handle = 3774873908 (E1000134)

    Identifier: SHDB-Handle = 503317363 (1E000373)

    Identifier: IP-Address = 30.30.30.1 (1E1E1E01)


However, it seems like during the session establishment, that key cannot be retrieved for some reason. Typically the 'source-ip-address' identifier refers to the source address in the packet for sessions using traffic as first sign of life. Given that, this may be not supported. However, I couldn't find any documentation stating this. For a formal confirmation, I would suggest to open a TAC case so we can involve the development team for a definite answer.


On the other hand, you mentioned that you want to have the nas-port and the IP address to identify the session right? What if you configure 'radius-server attribute 8 include-in-access-req' in the router. By doing this I'm able to have the nas-port as the username and the IP address in the Framed-IP-Address attribute:

28673815: Aug 30 11:16:34.486: RADIUS(0002B79A): Send Access-Request to 10.48.88.121:30645 id 21714/86,len 173

28673816: Aug 30 11:16:34.486: RADIUS:  authenticator 40 5B AE 12 9E 7D 63 B4 - 42 E9 10 E6 5F 4B 42 78

28673817: Aug 30 11:16:34.486: RADIUS:  User-Name           [1]   18  "nas-port:0/1/4/0"

28673818: Aug 30 11:16:34.486: RADIUS:  User-Password       [2]   18  *

28673819: Aug 30 11:16:34.486: RADIUS:  Framed-IP-Address   [8]   6   30.30.30.1


Maybe this can be an option for you?


Best regards.

Deniz AYDIN Tue, 09/03/2013 - 07:00
User Badges:

Hi Manuel,


As you said, documentation is not giving usefull information about the avaliable session keys for each feature. I can not open tac case, this is not a open project in my company.


For your suggestion about using the ip address included in access-req, it is not giving the netmask. So if the subnetting happens for different customer it is not possible to determine customer from access-req.


My idea is to configre ethernet based ip services like Dynamic Ethernet Service Activation (ı am not sure quato based features are avaliable also for DESA services, its not mentioned in the documentation), it seems it's not avaliable right now. It will be very nice to have these features, may be in the future.

Manuel Rodriguez Tue, 09/03/2013 - 07:41
User Badges:
  • Cisco Employee,

Hello Deniz,


For your suggestion about using the ip address included in access-req,  it is not giving the netmask. So if the subnetting happens for different  customer it is not possible to determine customer from access-req.

This is not clear to me. If you need the subnet mask to identify the subscriber, how source-ip-address as identifier would have been useful for you then? The value you could potentially have in source-ip-address identifier is exactly the same as the one in Framed-IP-Address attribute. Is simply the subscriber IP address. Perhaps this is something you noticed now and actually source-ip-address would have not been useful either?


Regarding DESA feature, as you said, I'm not sure if it can be used together with prepaid feature. In fact, I'm not even sure if it can actually be used in ASR1k at all since the documentation mentions as a prerequisite "Cisco 7600 routers with ES+ line cards.". This is not clear to me from the documentation either.


If you cannot open a TAC case then I would suggest to contact your Cisco System Engineer or local representative. Perhaps they will be able to clarify these concerns for you without having to open a TAC case.


Best regards.

Deniz AYDIN Tue, 09/03/2013 - 07:59
User Badges:

If I can go with the source-ip netmask will be my next concern:)


I even test DESA but I plan to use it with ASR 9K, IOS XR not with ASR1K.


Thanks for your suggestions.

Actions

This Discussion