cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
16008
Views
0
Helpful
10
Replies

IPoE BNG and DHCP on the ASR9K

mike-stevenson
Level 1
Level 1

Hi,

can some one tell me if this is possible.

I have a bundle Interface -using ambiguous VLANS:

interface Bundle-Ether100.1

vrf customers_1

ipv4 unnumbered lo2

ipv4 point-to-point

arp learning disable

service-policy type control subscriber UFB_DHCP

ipsubscriber ipv4 l2-connected

  initiator dhcp

!

encapsulation ambiguous dot1q any second-dot1q any

!

I have two loopback interfaces:

interface lo2

vrf customers_1

ipv4 address 100.64.0.1 255.255.128.0

interface lo3

vrf customers_1

ipv4 address 200.200.200.1 255.255.254.0

I am authenticating users using option82 remote-id, and DHCP for address allocation.  I want to use RADIUS to send back attributes, to set the users template, and, somehow set the dhcp giaddr so that the user gets an address from the correct pool.

ie. put the user into this template:

dynamic-template

type ipsubscriber CUSTOMER

  vrf customers_1

  ipv4 unnumbered Loopback3

and have them then given an address in the lo3 (200.200.200.0) range.  No matter what i do the dhcp giadd remains the address of the Bundle Interface.

I have tried all sorts of radius attributes:

Cisco-AVPair = 'subscriber:service-name=CUSTOMER'

Cisco-AVPair = 'subscriber:command=activate-service'

I have tried:

Cisco-AVPair= 'ipv4:ip-unnumbers=Loopback3'

Cisco-AVPair= 'subscriber:classname=lo192'  - and creating a dhcp class to set giaddr

I get a "aaa_type invalid attribute, flags 0x21"

I am at a bit of loss, and am not sure if what I am wanting to do is even possible.

though if set the template statically via an onboard policy things seem to work, and my user gets an address from the correct loopback.

any help would be appreciated.

ta.

1 Accepted Solution

Accepted Solutions

Hi Mike,

cool glad to hear that it is working!

the subscriber:dhcp-class is the radius directive to assign the class from the proxy config in case you want to simplify the local config, that is a good trick also.

Say is your SE Grant-M by any chance? (he was asking about this exact attribute also in a similar setup/design)

the attribute is fairly new let me check the doc status of that and add it to the avp page I had set up here also:

https://supportforums.cisco.com/docs/DOC-35624

regards

xander

View solution in original post

10 Replies 10

narvenka
Cisco Employee
Cisco Employee

Which image are you using ?

Cisco IOS XR Software, Version 5.1.0[Default]

asr9k-bng-px, V 5.1.0[Default], Cisco Systems, at disk0:asr9k-bng-px-5.1.0

    Built on Fri Sep  6 22:02:30 UTC 2013

    By iox-bld5 in /auto/srcarchive8/production/5.1.0/all/workspace for pie

This is the RADIUS reply message:

RP/0/RSP0/CPU0:Nov 21 19:51:01.048 : radiusd[1120]: rctx found is 0x50154e4c

RP/0/RSP0/CPU0:Nov 21 19:51:01.048 : radiusd[1120]: Radius packet decryption complete with rc = 0

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]:  RADIUS: Received from id 20 202.74.33.109:1812, Access-Accept, len 162

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]:  RADIUS:  authenticator 04 0B 2E 67 47 61 71 51 - F9 6C 89 31 1E 9D 52 08

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]:  RADIUS:   Vendor-Specific    [26]    43             

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]:  RADIUS:   Vendor-Specific    [26]    44             

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]:  RADIUS:   Vendor-Specific    [26]    29             

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]:  RADIUS:  Reply-Message       [18]    26      User authenticated - UBA

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]: Freeing server group transaction_id (F1000034)

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]: pack_length = 162 radius_len = 162

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]: rad_nas_reply_to_client: Received response from id : 20,packet type 2

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]: vrfnametoidlookup for vrf customers_1 - No error

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]: RADIUS: parsing sevice 'CUSTOMER' (len 8)

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]: (rad_nas_reply_to_client) Successfully decoded the response No error: PASS

RP/0/RSP0/CPU0:Nov 21 19:51:01.049 : radiusd[1120]: (rad_nas_reply_to_client) Successfully stored the preferred server info

I have the following set in radius:

cisco-avpair = 'subscriber:command=activate-service'

cisco-avpair += 'subscriber:service-name=CUSTOMER'

cisco-avpair += 'ip:vrf-id=customers_1'

Thought I woud add the VRF in-case this was causing problems..

ta

hi mike,

I see a few things:

Cisco-AVPair= 'ipv4:ip-unnumbers=Loopback3'

needs to be ipv4:ipv4-unnumbered

since you are activating the template as a service, I think it needs to be of the type service instead of ipsubscriber:

dynamic-template

type ipsubscriber CUSTOMER

assuming that the classname is defined in dhcp config that should go fine.

the debug dhcp ipv4, debug dhcp ipv4 proxy pack etc will help identifying the dhcp transactions too.

regards

xander

Alexander,

thanks for your reply,

If I use

Cisco-AVPair = 'subscriber:sa=UFB_CUSTOMER'  -> sets dynamic template

Cisco-AVPair += 'ipv4:ipv4-unnumbered=Loopback3' -> sets ipv4 loopback

I get the following form the RADIUS debug (showing template, and loopback understood by RADIUS)

RP/0/RSP0/CPU0:Nov 28 13:33:11.478 : radiusd[1120]: Radius packet decryption complete with rc = 0

RP/0/RSP0/CPU0:Nov 28 13:33:11.478 : radiusd[1120]:  RADIUS: Received from id 195 202.74.33.109:1812, Access-Accept, len 121

RP/0/RSP0/CPU0:Nov 28 13:33:11.478 : radiusd[1120]:  RADIUS:   Vendor-Specific    [26]    34             

RP/0/RSP0/CPU0:Nov 28 13:33:11.478 : radiusd[1120]:  RADIUS:  authenticator F2 4D D3 E7 B1 E8 90 D3 - F8 77 F1 1C 28 36 E9 6C

RP/0/RSP0/CPU0:Nov 28 13:33:11.478 : radiusd[1120]:  RADIUS:   Vendor-Specific    [26]    41             

RP/0/RSP0/CPU0:Nov 28 13:33:11.478 : radiusd[1120]:  RADIUS:  Reply-Message       [18]    26      User authenticated - UBA

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: pack_length = 121 radius_len = 121

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: rad_nas_reply_to_client: Received response from id : 195,packet type 2

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: Total len = 121, Radius len = 121

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: filter not found

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: Decoding the attribute: Vendor-Specific, aaa_type invalid attribute, flags 0x21

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: Decoding the attribute: Vendor-Specific, aaa_type invalid attribute, flags 0x21

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: This is sub-string of the Loopback interface name

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: Loopback attribute value: Loopback3

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: Decoding the attribute: Reply-Message, aaa_type reply-message, flags 0x100

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: Reply-Message fragments, 24

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: , total 24 bytes

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: RADIUS: parsing sevice 'UFB_CUSTOMER' (len 12)

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: (rad_nas_reply_to_client) Successfully decoded the response No error: PASS

RP/0/RSP0/CPU0:Nov 28 13:33:11.479 : radiusd[1120]: (rad_nas_reply_to_client) Successfully stored the preferred server info

RP/0/RSP0/CPU0:Nov 28 13:33:11.478 : radiusd[1120]: Freeing server group transaction_id (B1000047)

output from show subscriber running:

Subscriber Label: 0xff

% No such configuration item(s)

dynamic-template

type ipsubscriber UFB_CUSTOMER

  vrf customers_1

!

The subscriber shows up as a session:

RP/0/RSP0/CPU0:tpisp-cr02-h#show subscriber session all

Thu Nov 28 13:38:05.389 UTC

Codes: IN - Initialize, CN - Connecting, CD - Connected, AC - Activated,

       ID - Idle, DN - Disconnecting, ED - End

Type         Interface                State     Subscriber IP Addr / Prefix                             

                                                LNS Address (Vrf)                             

--------------------------------------------------------------------------------        

IP:DHCP      BE100.1.ip71             AC        100.64.0.98 (customers_1) 

However..

the ip address range is from the loopback 2 address, (this is the loopback bound to the unbundled BNG interface)

My understanding is that the giaddr address should have been changed to the ip address of lo3, which is the loopback specified in the RADIUS attribute.

dhcp debug: (this is the dhcp debug that follows directly after the RADIUS debug)

RP/0/RSP0/CPU0:Nov 28 13:33:11.484 : dhcpd[1080]: DHCPD PACKET: TP1225: Process packet event, client mode: PROXY

RP/0/RSP0/CPU0:Nov 28 13:33:11.484 : dhcpd[1080]: DHCPD PROXY: TP1955: FSM called for chaddr 000c.4270.6e7c with event DPM_SUCCESS state INIT_DPM_WAIT

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD PROXY: TP1917: Process client request called for chaddr 000c.4270.6e7c

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD PACKET: TP1883: Giaddr not present, Set giaddr 100.64.0.1, chaddr 000c.4270.6e7c

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD PACKET: TP571: L3 packet TX unicast to dest 202.74.33.108, port 67, source 100.64.0.1, vrf 0x60000003 (1610612739), tbl 0xe0000012 (3758096402)

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: ---------- IPv4 DHCPD --- dhcpd_iox_l3_unicast_packet -------

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: VRF name (id): customers_1 (0x60000003)

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: L3 src: 100.64.0.1

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: L3 dst: 202.74.33.108

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: L3 dst port: 67

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: L3 input Intf: Bundle-Ether100.1

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: Output Intf: Null

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: FROM: L3

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: NETWORK_ORDER

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: Vlan Info

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: Vlan EtherType 1: 0x8100

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: Vlan Priority 1: 0 (0x0)

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: Vlan Format 1: 0 (0x0)

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: Vlan ID 1: 101 (0x65)

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: Vlan EtherType 2: 0x8100

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: Vlan Priority 2: 0 (0x0)

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: Vlan Format 2: 0 (0x0)

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: metadata: Vlan ID 2: 23 (0x17)

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666:

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: op:     BOOTREQUEST

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: chaddr: 000c.4270.6e7c

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: xid:    0x303751ed

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: flags:  0x8000 (broadcast)

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: ciaddr: 0.0.0.0

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: yiaddr: 0.0.0.0

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: siaddr: 0.0.0.0

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: giaddr: 100.64.0.1

RP/0/RSP0/CPU0:Nov 28 13:33:11.485 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: cookie: 0x63825363

RP/0/RSP0/CPU0:Nov 28 13:33:11.486 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: option: MESSAGE_TYPE: DISCOVER

RP/0/RSP0/CPU0:Nov 28 13:33:11.486 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: option: PARAMETER_REQUEST data: "0x01-79-03-21-06-2a"

RP/0/RSP0/CPU0:Nov 28 13:33:11.486 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: option: CLIENT_IDENTIFIER data: "0x01-00-0c-42-70-6e-7c"

RP/0/RSP0/CPU0:Nov 28 13:33:11.486 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: option: HOST_NAME data: "MikroTik"

RP/0/RSP0/CPU0:Nov 28 13:33:11.486 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: option: RELAY_INFORMATION

RP/0/RSP0/CPU0:Nov 28 13:33:11.486 : dhcpd[1080]: DHCPD_PACKET: pktTx id 666: option: RELAY_INFORMATION: CIRCUIT_ID: 0x01-0f-43-48-4f-52-55-53-31-30-30-30-30-30-34-35-33

I tried changing the dynamic template to service rather than ipsubscriber, this did not make a difference.  You make a reference to DHCP classname.  I have defined a DHCP class, however do not know how to match or force the use of a particular class by using a RADIUS attribute.

Thanks,

Mike

Hi Mike,

yes the GI addr set in the dhcp ipv4 config needs to be pointing to the same interface/subnet so the dhcp server provides an address out of that pool you're unnumbered to after all the config gets applied.

the giaddr effectively is a pointer to the dhcp server as to from which pool to pick.

the ipv4 unnumbered attribute or template config is effectively the default gateway for the sesions

so your dhcp porfile needs to point to thed efault gateway option being the loopback addr you're unnumbered to.

regards

xander

Xander Thuijs CCIE #6775
Principal Engineer 
ASR9000, CRS, NCS6000 & IOS-XR

Xander,

yes I think this is the heart of my problem.  With the help of a local SE, we have solved it.

My current DHCP config:

dhcp ipv4

profile UFB_CGN proxy

  class IPoE_PUBLIC

   helper-address vrf customers_1 202.74.33.108 giaddr 200.200.200.1

  !

  class IPoE_CGN

   helper-address vrf customers_1 202.74.33.108 giaddr 100.64.0.1

!

  lease proxy client-lease-time 300

  helper-address vrf customers_1 202.74.33.108 giaddr 0.0.0.0

  relay information option

  relay information policy keep

  relay information option allow-untrusted

!

interface Bundle-Ether100.1 proxy profile UFB_CGN

I was missing a RADIUS AV, dhcp-class -this AV does not appear in the config guide..

so to get my subscribers dynamically allocated to service/ip i have used the following:

CGN Ip RANGE - subscribers with addresses that will be nat'd have the following AV's applied

Cisco-AVPair='subscriber:sa=UFB_CUSTOMER_CGN'

Cisco-AVPair+='subscriber:dhcp-class=IPoE_CGN'

Cisco-AVPair+='ipv4:ipv4-unnumbered=loopback2'

PUBLIC ip RANGE - subscribers i want to have public addresses are assigned the following

Cisco-AVPair='subscriber:sa=UFB_CUSTOMER'

Cisco-AVPair+='subscriber:dhcp-class=IPoE_PUBLIC'

Cisco-AVPair+='ipv4:ipv4-unnumbered=loopback3'

Xander, thanks for your help

Hi Mike,

cool glad to hear that it is working!

the subscriber:dhcp-class is the radius directive to assign the class from the proxy config in case you want to simplify the local config, that is a good trick also.

Say is your SE Grant-M by any chance? (he was asking about this exact attribute also in a similar setup/design)

the attribute is fairly new let me check the doc status of that and add it to the avp page I had set up here also:

https://supportforums.cisco.com/docs/DOC-35624

regards

xander

xander,

yes I have been dealing with Grant, it appears all roads lead back to you :-)

I would very much like to thank you for your help, it is very very much appreciated.  You are a good man!

cheers,

mike

hi mike, ah funny full circle and small world!

coolhave fun with it and if you run into something new dump your post and we'll get it sorted!

cheers

xander

Hi Xander

 

This post is a little bit old, but much interesting as I have the same case to setup on my network these days.

But I have a problem regarding configuration on this post:

* different vrf (1, 2, 3),

* different loopback address (for different vrf), 

* same dynamic-template (type ipsub, with loopback1)

* same pmap/cmap,

* same dhcp config with different class (for classname),

* same bundle interface for customer input trafic

* dhcp server is configured to provide different subnet for different classname, depending on giaddr

 

So here is my problem. 

case 1)

* How can i provide different unnumbered loopback interface for same bundle interface ?

* also not possible affect same bundle interface in different vrf

 

case 2) 

instead of differt in vrf, I just try to do all in same vrf (default), so:

* different loopback addresses : lo1, lo2 and lo3(in order to select giaddr, because not same service, and not same pool in external dhcp server)

* same dynamic-template (type ipsub, loopback1)

* same pmap/cmap,

* same dhcp config with different class ( for classname and then giaddr <loopback> so CLASS_A with lo1, CLASS_B with lo2, and CLASS_C  with lo3),

* same bundle interface for customer input trafic: this bundle use for example <ipv4 unnumbered lo1>

* dhcp server is configured to provide different subnet depend on different classname, on giaddr configured on ASR dhcp config as following :

 

!
dhcp ipv4
  profile IPOE_PROXY proxy
    !
    class CLASS_A
      helper-address vrf default 172.20.1.50 giaddr <lo1>
    !
    class CLASS_B
      helper-address vrf default 172.20.1.50 giaddr <lo2>
    !
    class CLASS_C
      helper-address vrf default 172.20.1.50 giaddr <lo3>
    !
    relay information option
    relay information policy keep
    relay information option allow-untrusted
   !
   interface Bundle-ether10.3600 proxy profile IPOE_PROXY

 

 I can assign ONLY one loopback on same bundle interface.

 

So if Radius send back for example:

Cisco-AVPair='ipv4:ipv4-unnumbered=loopback2',

Cisco-AVPair+='subscriber:dhcp-class=CLASS_B'

DHCP server provide for CLASS_B, subnet within lo2 (ie. lo2=10.2.10.254, and subnet=10.2.10.0/24)

 

The result I expect for this customer is that: ip address should be within 10.2.10.0/24 with gw 10.2.10.254.

 

how can ASR9K reconfigure bundle interface as it is already configured CLI with <unnumbered lo1> ?

 

in others words:

 how can i provide different subnet (through giaddr), for different customers, on same bundle interface ?

 

What should be best practice?

 

Thanks for answers which can clarify it.

 

Jacques