cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3312
Views
0
Helpful
20
Replies

ASR 9001 BNG IPoE problems

Goergi Genov
Level 1
Level 1

Hi,

I have read and try these guides

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

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

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

But have some problems , here is my config ( almost same like the guides )

radius-server host xxx.xxx.xxx.46 auth-port 1812 acct-port 1813

!

aaa server radius dynamic-author

port 3799

client yyy.yyy.yyy.102 vrf default

!

client xxx.xxx.xxx.46 vrf default

!

aaa attribute format MY_AUTH

mac-address

!

aaa attribute format NAS_PORT_FORMAT

circuit-id plus remote-id separator .

!

!

aaa radius attribute nas-port format e SSAAPPPPQQQQQQQQQQVVVVVVVVVVUUUU type 32

aaa radius attribute nas-port format e SSAAPPPPQQQQQQQQQQVVVVVVVVVVUUUU

aaa radius attribute nas-port-id format NAS_PORT_FORMAT

aaa group server radius RADIUS_GR

server xxx.xxx.xxx.46 auth-port 1812 acct-port 1813

source-interface Loopback0

!

aaa authorization network default group RADIUS_GR

aaa accounting subscriber default group RADIUS_GR

aaa authorization subscriber AUTH_GR group RADIUS_GR

aaa authorization subscriber default group RADIUS_GR

aaa authorization subscriber RADIUS_GR group RADIUS_GR

aaa authentication subscriber default group RADIUS_GR

aaa accounting update periodic 10

dhcp ipv4

profile IP_DEFAULT proxy

  class IP_DEFAULT

   helper-address vrf default yyy.yyy.yyy.102 giaddr zzz.zzz.zzz.1

  !

  helper-address vrf default yyy.yyy.yyy.102 giaddr zzz.zzz.zzz.1

  relay information option

  relay information policy keep

  relay information option allow-untrusted

!

   interface Bundle-Ether100.361 proxy profile IP_DEFAULT

!

ipv4 access-list PERM_ALL

10 permit ipv4 any any

20 permit icmp any any

30 permit ipv4 any any

!

interface Bundle-Ether100

bundle load-balancing hash dst-ip

!

!

interface Bundle-Ether100.361

ipv4 point-to-point

ipv4 unnumbered Loopback100

service-policy type control subscriber IP_PM

encapsulation dot1q 361

ipsubscriber ipv4 l2-connected

  initiator dhcp

!

!

interface Loopback0

ipv4 address ccc.ccc.ccc.174 255.255.255.255

!

interface Loopback100

description 4dhcp

ipv4 address zzz.zzz.zzz.1 255.255.255.0

!

interface TenGigE0/0/2/0

bundle id 100 mode on

!

interface TenGigE0/0/2/1

!

dynamic-template

type ipsubscriber IPSUB_TPL

  ipv4 unnumbered Loopback100

  ipv4 access-group PERM_ALL ingress

  ipv4 access-group PERM_ALL egress

!

class-map type control subscriber match-any DHCP

match protocol dhcpv4

end-class-map

!

policy-map type control subscriber IP_PM

event session-start match-first

  class type control subscriber DHCP do-until-failure

   5 activate dynamic-template IPSUB_TPL

   10 authorize aaa list AUTH_GR format MY_AUTH password cisco

  !

!

end-policy-map

!


Without  service-policy type control subscriber IP_PM on the interface , CPE gets ip address and all works.

The radius server is configured always to autothenticate with access-accept but there are errors


  Total Deadtime: 0s Last Deadtime: 0s

  Timeout: 5 sec, Retransmit limit: 3

  Quarantined: No

  Authentication:

    468 requests, 1 pending, 154 retransmits

    0 accepts, 0 rejects, 0 challenges

    204 timeouts, 417 bad responses, 417 bad authenticators

    0 unknown types, 417 dropped, 0 ms latest rtt

    Throttled: 0 transactions, 0 timeout, 0 failures

    Estimated Throttled Access Transactions: 0

    Maximum Throttled Access Transactions: 0


  The most strange issue is this

000c.42a8.71e2  0.0.0.0         INIT       57         BE100.361            default    0x0      

and

RP/0/RSP0/CPU0:Sep 23 17:08:03.507 : dhcpd[1077]: DHCPD ERROR: TP2468: rib route delete failed, null ifhandle or IPv4 address

Here is the subscriber session info

RP/0/RSP0/CPU0:ASR9001#show subscriber session all

Mon Sep 23 17:08:46.995 EET

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      No                       CN        -                                   

RP/0/RSP0/CPU0:ASR9001#show subscriber session all detail

Mon Sep 23 17:08:48.394 EET

Interface:                None

Circuit ID:               000401690107

Remote ID:                0006001ebd7b2f00

Type:                     IP: DHCP-trigger

IPv4 State:               Up Pending, Mon Sep 23 17:08:32 2013

Mac Address:              000c.42a8.71e2

Account-Session Id:       000001e0

Nas-Port:                 67114640

User name:                unknown

Outer VLAN ID:            361

Subscriber Label:         0x0000005f

Created:                  Mon Sep 23 17:08:32 2013

State:                    Connecting

Authentication:           unauthenticated

Access-interface:         Bundle-Ether100.361

Policy Executed:

policy-map type control subscriber IP_PM

  event Session-Start match-first [at Mon Sep 23 17:08:32 2013]

    class type control subscriber DHCP do-until-failure [Succeeded]

      5 activate dynamic-template IPSUB_TPL [Succeeded]

Session Accounting: disabled

Last COA request received: unavailable

Pending Callbacks:

  Waiting for Authorization to complete

  Waiting for Authentication response from AAA

20 Replies 20

xthuijs
Cisco Employee
Cisco Employee

Hi Goergi,

radius is not giving us access-accepts back, instead the client on the 9k side complains about invalid authenticators, this usually is caused by incorrect keys between the client and server.

although the radius-server may respond with an access accept always, it should fill the authenticator field and when we parse the response, we dont have a good match on it and therefore fail the request.

the dhcp discover is held until the access accept is properly processed.

make sure the profile does not include a service-type outbound in there!!

cheers!

xander

Hi Alex,

I have a problem for establishing IPoE Subscriber.

my router has send Access-Request to Radius  :

LC/0/0/CPU0:Jan  6 17:04:52.711 : radiusd[320]:  RADIUS: Send Access-Request to 202.158.x8.6x:1645 id 58, len 275

LC/0/0/CPU0:Jan  6 17:04:52.711 : radiusd[320]:  RADIUS:  authenticator 92 EA 87 99 8D CF D0 0E - 1F 8F 00 B3 58 71 AF 57

C/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:  Vendor,Cisco        [26]    41     

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:   Cisco AVpair        [1]    35      client-mac-address=000f.b0d1.a219

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:  Vendor,Cisco        [26]    34     

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:   Cisco AVpair        [1]    28      dhcp-vendor-class=MSFT 5.0

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:  Acct-Session-Id     [44]    10      04000933

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:  NAS-Port            [5]     6       2147498128

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:  NAS-Port-Id         [87]    3       .      

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:   cisco-nas-port      [2]    3       .      

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:  User-Name           [1]     16      000f.b0d1.a219

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:  Service-Type        [6]     6       Outbound[0]

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:  Vendor,Cisco        [26]    9      

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:  Vendor,Cisco        [26]    33     

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:   Cisco AVpair        [1]    27      parent-if-handle=67111360

LC/0/0/CPU0:Jan  6 16:58:26.943 : radiusd[320]:  RADIUS:  NAS-Port-Type       [61]    6       IPOEOVLAN[0]

LC/0/0/CPU0:Jan  6 16:58:26.943 : radiusd[320]:  RADIUS:  Event-Timestamp     [55]    6       1389002276

LC/0/0/CPU0:Jan  6 16:58:26.943 : radiusd[320]:  RADIUS:  Vendor,Cisco        [26]    35     

LC/0/0/CPU0:Jan  6 16:58:26.943 : radiusd[320]:  RADIUS:   Cisco AVpair        [1]    29      dhcp-client-id=000fb0d1a219

LC/0/0/CPU0:Jan  6 16:58:26.943 : radiusd[320]:  RADIUS:  Nas-Identifier      [32]    26      HOSTNAME-BNG

LC/0/0/CPU0:Jan  6 16:58:26.943 : radiusd[320]:  RADIUS:  NAS-IP-Address      [4]     6       210.x.x.x

LC/0/0/CPU0:Jan  6 16:58:26.942 : radiusd[320]:  RADIUS:  User-Password       [2]     18      *      

And My Radius has Accept-Access:

*** Sending to 210.x.x.x port 39694 ....

Code:       Access-Accept

Identifier: 44

Authentic:  E{q<200><171><0><14><22><231><192><7><188><210>/<233>?

Attributes:

cisco-avpair = "subscriber:sa=IPSUB_TPL"

--

but the router never accept-access packet from the Radius ?

--

the weird thing is my router has state radius source interface is loopback0, but it still send NAS-IP-Address from interface physical. 210.x.x.x instead my loopback 202.158.x.233

interface Loopback0

ipv4 address 202.158.x.233 255.255.255.255

radius source-interface Loopback0 vrf default

--

class-map type control subscriber match-any IP_SUB

match protocol dhcpv4 dhcpv6

end-class-map

policy-map type control subscriber IP_PM

event session-start match-first

  class type control subscriber IP_SUB do-all

   10 activate dynamic-template IPSUB_TPL

   20 authorize aaa list author_grp format USERNAME_FORMAT password iosxr

  !

!

event account-logon match-first

  class type control subscriber IP_SUB do-all

   10 authenticate aaa list default

  !

!

end-policy-map

---

please help for clue.

thank you.

hi rommy,

it could be your radius server is replying back to the nas-ip-address and therefore we never see the response, this is incorrect from both the radius (as it should use the socket info) as well as the bng, which should have set the nas-ip-addr to the loopback source as per configuration.

for that latter clause, I am thinking that this is a bug from older releases, I recently verified this in xr43(2) and it was working solid there, which version are you using there?

regards

xander

rommy:

try adding this to your configuration:

aaa group server radius

server auth-port xxxx acct-port yyyy

source-interface Loopback0

i've seen this before, albeit, with 4.2, but try it and see what happens.

for some reason, this was not enough in my case:

radius source-interface Loopback0 vrf default

regards,

c.

rommykuntoro
Level 1
Level 1

Hi Carlos & Alex

im using version 5.1.0

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

    Built on Sat Sep  7 05:01:13 GMT 2013

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

below my configuration, did i miss something ?

thank you for the helps.

radius source-interface Loopback0 vrf default

radius-server host 202.aa.bb.cc auth-port 1645 acct-port 1646

key 7

radius-server timeout 10

pool vrf default ipv4 test

address-range 101.aaa.abc.2 101.aaa.abc.254

dhcp ipv4

profile DHCP server

  pool test

  dns-server 8.8.8.8

  subnet-mask 255.255.255.0

  default-router 101.aaa.abc.1

!

interface GigabitEthernet0/0/0/0.905 server profile DHCP

aaa attribute format NAS_PORT_FORMAT

circuit-id plus remote-id separator .

!        

aaa attribute format USERNAME_FORMAT

mac-address

!

aaa radius attribute nas-port format e SSAAPPPPQQQQQQQQQQVVVVVVVVVVUUUU type 32

aaa radius attribute nas-port format e SSAAPPPPQQQQQQQQQQVVVVVVVVVVUUUU

aaa radius attribute nas-port-id format NAS_PORT_FORMAT

aaa group server radius radiator

server 202.aa.bb.cc auth-port 1645 acct-port 1646

source-interface Loopback0

aaa accounting subscriber default group radiator

aaa authorization subscriber default group radiator

aaa authorization subscriber author_grp group radiator

aaa authentication subscriber default group radiator

dynamic-template

type ipsubscriber IPSUB_TPL

  ipv4 unnumbered Loopback2000

class-map type control subscriber match-any IP_SUB

match protocol dhcpv4 dhcpv6

end-class-map

!

policy-map type control subscriber IP_PM

event session-start match-first

  class type control subscriber IP_SUB do-all

   10 activate dynamic-template IPSUB_TPL

   20 authorize aaa list author_grp format USERNAME_FORMAT password iosxr

  !

event account-logon match-first

  class type control subscriber IP_SUB do-all

   10 authenticate aaa list default

end-policy-map

interface Loopback2000

ipv4 address 101.aa.bb.1 255.255.255.0

interface GigabitEthernet0/0/0/0.905

ipv4 point-to-point

ipv4 unnumbered Loopback2000

service-policy type control subscriber IP_PM

encapsulation dot1q 905

ipsubscriber ipv4 l2-connected

  initiator dhcp

  initiator unclassified-source

ok looks like you may are running into a new bug in xr51.

do you need func from xr51, otherwise I would recommend sticking with 434 for bng deployments.

ps great suggestion btw Carlos!

thanks

xander

Alex, thank you for you clarification. i will try to downgrade my ASR9001 to 4.3.4.

i will let you know the updates.

Hi Alex, i have downgrade my router to 4.3.4, in this version there are no DHCPv4 Server option. how do i get the dhcp server in my router ?

I have try to connect my demo client, the result is my router doesn't recieved Accept-Access from my Radius and also the routing system still send radius packet from interface physical instead loopback0.

Access-Request from Router to Radius #

  7 09:45:02.753 : radiusd[315]:  RADIUS: Send Access-Request to 202.xxx.xxx.60:1645 id 24, len 254

  7 09:45:02.754 : radiusd[315]:  RADIUS:  authenticator FC 30 00 B2 EB 76 ED 27 - 82 51 DF 8C F2 45 AA 6F

  7 09:45:02.754 : radiusd[315]:  RADIUS:  Vendor,Cisco        [26]    41     

  7 09:45:02.754 : radiusd[315]:  RADIUS:   Cisco AVpair        [1]    35      client-mac-address=000f.b0d1.a219

  7 09:45:02.754 : radiusd[315]:  RADIUS:  Vendor,Cisco        [26]    34     

  7 09:45:02.754 : radiusd[315]:  RADIUS:   Cisco AVpair        [1]    28      dhcp-vendor-class=MSFT 5.0

  7 09:45:02.754 : radiusd[315]:  RADIUS:  Acct-Session-Id     [44]    10      0400000a

  7 09:45:02.754 : radiusd[315]:  RADIUS:  NAS-Port-Id         [87]    13      130/8/0/905

  7 09:45:02.754 : radiusd[315]:  RADIUS:  Vendor,Cisco        [26]    19     

  7 09:45:02.754 : radiusd[315]:  RADIUS:   cisco-nas-port      [2]    13      130/8/0/905

  7 09:45:02.754 : radiusd[315]:  RADIUS:  User-Name           [1]     16      000f.b0d1.a219

  7 09:45:02.754 : radiusd[315]:  RADIUS:  Service-Type        [6]     6       Outbound[5]

  7 09:45:02.754 : radiusd[315]:  RADIUS:  User-Password       [2]     18      *      

  7 09:45:02.754 : radiusd[315]:  RADIUS:  Vendor,Cisco        [26]    33     

  7 09:45:02.754 : radiusd[315]:  RADIUS:   Cisco AVpair        [1]    27      parent-if-handle=67111360

  7 09:45:02.754 : radiusd[315]:  RADIUS:  NAS-Port-Type       [61]    6       IPOEOVLAN[40]

  7 09:45:02.754 : radiusd[315]:  RADIUS:  Event-Timestamp     [55]    6       1389062702

  7 09:45:02.754 : radiusd[315]:  RADIUS:  Nas-Identifier      [32]    26      HOSTNAME-BNG

  7 09:45:02.754 : radiusd[315]:  RADIUS:  NAS-IP-Address      [4]     6      210.xxx.yyy.2

Access-Request from Radius which got from Router #

*** Received from 210.xxx.yyy.2 port 51185 ....

Code:       Access-Request

Identifier: 31

Authentic:  *<134><174><25><251>a<140><17><170><255>S<191><205>;T<153>

Attributes:

cisco-avpair = "client-mac-address=000f.b0d1.a219"

cisco-avpair = "dhcp-vendor-class=MSFT 5.0"

Acct-Session-Id = "0400000b"

NAS-Port-Id = "130/8/0/905"

Cisco-NAS-Port = "130/8/0/905"

User-Name = "000f.b0d1.a219"

Service-Type = 5

User-Password = <251><10>h<203><11><203><151><132>i<29><222>@<251>t7<166>

cisco-avpair = "parent-if-handle=67111360"

NAS-Port-Type = 40

Event-Timestamp = 1389062760

NAS-Identifier = "HOSTNAME-BNG"

NAS-IP-Address = 210.xxx.yyy.2

##Accept-Access from Radius to Router ##

Tue Jan  7 09:42:53 2014: DEBUG: Handling with Radius::AuthFILE:

Tue Jan  7 09:42:53 2014: DEBUG: Radius::AuthFILE looks for match with 000f.b0d1.a219 [000f.b0d1.a219]

Tue Jan  7 09:42:53 2014: DEBUG: Radius::AuthFILE ACCEPT: : 000f.b0d1.a219 [000f.b0d1.a219]

Tue Jan  7 09:42:53 2014: DEBUG: AuthBy FILE result: ACCEPT,

Tue Jan  7 09:42:53 2014: DEBUG: Access accepted for 000f.b0d1.a219

Tue Jan  7 09:42:53 2014: DEBUG: Packet dump:

*** Sending to 210.xxx.yyy.2 port 51185 ....

Code:       Access-Accept

Identifier: 31

Authentic:  $U<226><252>4<219><171><228><226>q^<28><135>?<143><175>

Attributes:

## BUT The Router never recieved Access-Accept Packet from the Radius ##

== Current Configuration After Downgrade to 4.3.4 ==

radius source-interface Loopback0 vrf default

radius-server host 202.158.58.60 auth-port 1645 acct-port 1646

key 7

radius-server timeout 10

aaa attribute format NAS_PORT_FORMAT

circuit-id plus remote-id separator #

!

aaa attribute format USERNAME_FORMAT

mac-address

aaa group server radius radiator

server 202.xx.xx.60 auth-port 1645 acct-port 1646

source-interface Loopback0

!

aaa accounting subscriber default group radiator

aaa authorization subscriber default group radiator

aaa authorization subscriber author_grp group radiator

aaa authentication subscriber default group radiator

aaa accounting update periodic 5

dhcp ipv4

profile DHCPv4 proxy

  helper-address vrf default 202.xxx.1.34 giaddr 101.aaa.bbb.1

  relay information option

  relay information policy keep

  relay information option allow-untrusted

interface GigabitEthernet0/0/0/0.905 proxy profile DHCPv4

interface Loopback0

ipv4 address 202.ccc.ddd.233 255.255.255.255

interface Loopback2000

ipv4 address 101.aaa.bbb.1 255.255.255.0

interface GigabitEthernet0/0/0/0.905

ipv4 point-to-point

ipv4 unnumbered Loopback2000

service-policy type control subscriber IP_PM

encapsulation dot1q 905

ipsubscriber ipv4 l2-connected

  initiator dhcp

  initiator unclassified-source

  dynamic-template

type ipsubscriber IPSUB_TPL

  ipv4 unnumbered Loopback2000

!

!

class-map type control subscriber match-any IP_SUB

match protocol dhcpv4 dhcpv6

end-class-map

!

policy-map type control subscriber IP_PM

event session-start match-first

  class type control subscriber IP_SUB do-all

   10 activate dynamic-template IPSUB_TPL

   20 authorize aaa list author_grp format USERNAME_FORMAT password iosxr

  !

!

event account-logon match-first

  class type control subscriber IP_SUB do-all

   10 authenticate aaa list default

  !

!

end-policy-map

#Radius Status#

show radius

Tue Jan  7 09:56:52.137 GMT

Global dead time: 0 minute(s)

Number of Servers:1

Server: 202.xx.xx.60/1645/1646  is UP

  Total Deadtime: 0s Last Deadtime: 0s

  Timeout: 10 sec, Retransmit limit: 3

  Quarantined: No

  Authentication:

    11 requests, 1 pending, 31 retransmits

    0 accepts, 0 rejects, 0 challenges

    41 timeouts, 0 bad responses, 0 bad authenticators

    0 unknown types, 0 dropped, 0 ms latest rtt

    Throttled: 0 transactions, 0 timeout, 0 failures

    Estimated Throttled Access Transactions: 0

    Maximum Throttled Access Transactions: 0

    Automated TEST Stats:

        0 requests, 0 timeouts, 0 response, 0 pending

  Accounting:

    0 requests, 0 pending, 0 retransmits

    0 responses, 0 timeouts, 0 bad responses

    0 bad authenticators, 0 unknown types, 0 dropped

    0 ms latest rtt

    Throttled: 0 transactions, 0 timeout, 0 failures

    Estimated Throttled Accounting Transactions: 0

    Maximum Throttled Accounting Transactions: 0

    Automated TEST Stats:

        0 requests, 0 timeouts, 0 response, 0 pending

from this logging it looks like the radius-server replies back to the nas-ip-address.

depending on what the socket value was from where the request originated (can you see that in your radius-server

log too where the request came from on the socket?)

if you have defined a radius-server group, make sure that the source address is configured under the group properly also.

make sure that the address of the source interface is the right address also.

if this all confirmed, then try a proc restart on radiusd for me, on the rsp.

another thing to try is to use the aaa authentication subscriber default group radius (to leverage the global group of radius servers as opposed to the group defined one)

Also a sniffer trace capturing the radius traffic between bng and radius may help here as I can't see from this logging what the source address was used on the socket of the bng.

xr43 doesnt have a local dhcp server, so you may need to use an external one, eg a simple ios device can do that for you, but that is not necessary to verify/demonstrate this particular issue.

regards

xander

Thank you xander,

i'm sured that my radius-server source interface is already state to my loopback address, and my loopback address also right. but the weird one is  why my router send nas-ip-address as my physcial interface ip instead my loopback ip which i have stated from my global radius or group radius source interface using loopback0.

im afraid that when the return packet accept-access from radius, the router expect from my router loopback0, but when he send the access-request to the radius, my router send it from the physical address.

i will try to sniff my bng and radiator to see what happens there.

Hi Xander,

i have sniff between Radiator and BNG:

1. from the interface radius, radiator has recieved Access-Request from router, and transmit Access-Accept to router

2. from the interface bng, bng send Access-Request to radius and the radius accepted it. and then Access-Accept was sent from radius to bng, but from the inside the bng, the access-accept packet never recevied.

do you have any clue on that, xander ? btw the radius server is also used for BNG(PPPoE) router ASR1K  and they are perfectly running well.

thanks for the helps

Carlos A. Silva
Level 3
Level 3

A couple of questions rommy:

In your sniffer: are all you expected ip addresses correct? both dst-ip and src-ip in both the access request and access accept packets?

Are the BNG and radius server connected back to back? I ask because you say you have a sniffer between them.

If not, is there a cloud of routers in between them? Radius communications are straight forward, as long as dst-ip and src-ip are ok, the only thing that could be wrong is the radius key and (if back 2 back) just maybe the MAC address on the packets.

Hi Carlos,

Yes, all the addresses are correct. both dst-ip and src-ip, also the identifier of the radius packet.

the BNG and Radius are not back to back, they are talk each other via routing.  yes,  i sniffed both of them. from the radius interface side and and from the interface router side.

just like you said carlos, they talked straight forward. even if i stated my radius source-interface to physical interface, it is the same thing, my router never got the accept-access.  and i really confuse, when i state radius source-interface to loopback0, the router send NAS-IP-Address still physical interface addresses. is it kind a bug ? of miss configuration ?

all my config was posted above. did i something wrong?, and never been experience like this until now when using ASR1K platform.

so, let me backtrack a little, you never got the BNG to change the source-ip for the radius packets to the loopback address? wow! i missed that part.

best guess it is a bug. kinda hard to guess without actually looking.

i'll share a config from a live/working box with 4.3.2:

radius source-interface Loopback0 vrf default

radius-server host x.x.x.x auth-port 1812 acct-port 1813

key 7 XXXXXXXX

radius-server host y.y.y.y auth-port 1812 acct-port 1813

key 7 YYYYYYYY

aaa group server radius ZZZZZ

server x.x.x.x auth-port 1812 acct-port 1813

server y.y.y.y auth-port 1812 acct-port 1813

source-interface Loopback0

aaa accounting subscriber default group ZZZZZ

aaa authorization subscriber default group ZZZZZ

aaa authentication subscriber default group ZZZZZ

i also looked for public bugs and nothing.

Getting Started

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: