[c-nsp] Question about returning multiple un-numbered interface attributes via radius

[Bryan Tabb]

Heya

Nah didn’t make it to NZNOG. 

We know the NAS ip the request is coming from and it'll be easy enough to maintain small table (e.g. ip = A then BNG = 1k etc)

I think I just need to get my head around how to add custom scripts \ lookups to FR

Will do some more digging and provide beer and pick your brains soon :-)

Cheers

Bryan

-----Original Message-----
From: Nathan Ward [mailto:lists+freeradius at daork.net] 
Sent: Wednesday, 24 January 2018 2:57 PM
To: Bryan Tabb <bryan.tabb at nztechnologygroup.com>
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Question about returning multiple un-numbered interface attributes via radius

Hey Bry,

> On 24/01/2018, at 9:23 AM, Bryan Tabb <bryan.tabb at nztechnologygroup.com> wrote:
> 
> Hi all
> 
> We have a mixture of BNGs,  ASR9k and ASR1k that use Freeradius for AAA.
> 
> One of the differences between the models is the format for the 
> unnumbered loopback attribute that comes from Freeradius
> 
> For the ASR9k format is "ip:ipv4-unnumbered=Loopback2000"
> For the ASR1k format is "ip:ip-unnumbered=Loopback2000"
> 
> Does anyone see a problem with sending both via AV pairs when user logs in ?
> 
> The taught process being the ASR9k will ignore the ip:ip-unnumbered 
> and process the ip:ipv4-unnumbered and with the ASR1k vise versa
> 
> E.g. from debug radius on asr1k
> Jan 24 09:10:30.784 NZDT: RADIUS:   Cisco AVpair       [1]   31  "ip:ip-unnumbered=Loopback2000"
> Jan 24 09:10:30.784 NZDT: RADIUS:  Vendor, Cisco       [26]  39
> Jan 24 09:10:30.784 NZDT: RADIUS:   Cisco AVpair       [1]   33  "ip:ipv4-unnumbered=Loopback2000"
> Jan 24 09:10:30.784 NZDT: RADIUS(00000077): Received from id 1645/3 
> Jan 24 09:10:30.784 NZDT: RADIUS/DECODE: parse unknown cisco vsa 
> "ipv4-unnumbered" - IGNORE
> 
> The attributes are part of radgroupreply.
> 
> Under normal operations users will be authenticating against their 
> local BNG but in a failure situation we would Psuedowire the customers 
> off to the next closest BNG which may be a different model.  If this 
> were to occur I'm trying to avoid having to update radius for those 
> users (so they get the correct attribute)
> 
> Or am I looking at this this wrong way and there is a much easier way ?

Yeah so in FR you can do a few things to identify at NAS to a model/class/whatever and respond with appropriate attributes.

One way is set to set some internal attributes in the client config per client, and then match on it later - or you can match on the NAS ID, just means changing a big if statement whenever your BNGs change.

Are you doing this for different DHCP pools or similar? I have a better way to handle that - if you’re in Queenstown this week come grab me.

--
Nathan Ward