(RADIATOR) Cisco, non-unique NAS-Ports, clobbering Online DB

[Frank Danielson]

How about handling it with a preclient hook in the client clause to strip
the number you want out of the Cisco-NAS-Port attribute and stuff it into
the NAS-Port attribute.

-----Original Message-----
From: Dave Kitabjian [mailto:dave at netcarrier.com]
Sent: Wednesday, July 10, 2002 5:25 PM
To: radiator at open.com.au
Subject: (RADIATOR) Cisco, non-unique NAS-Ports, clobbering Online DB



I finally tracked down the reason why our Online DB has been reporting a
much lower count of onliners than are actually online.

Look at the attached sequence of two accounting records. tmeyers logs on to
NAS 216.118.66.25 and Port 105. Then, 3 minutes later, while he's still
online, cheezwhiz logs off of the same NAS and Port, clobbering tmeyers'
entry in the online DB. 

But how can two people have been on the same port at the same time, you ask?
The answer is that when Cisco is (again) lazy, it's easy to happen. If you
look at the Cisco-NAS-Port attribute, you'll see that they are really on two
distinct ports. Cisco is just taking a portion of the info and plopping it
in NAS-Port, even though that means that many people can be on the same
NAS-Port at once. Most manufacturers come up with a procedure for encoding
all that "Async4/105*Serial7/0:25:3" stuff into some unique, numeric port
number and then put that in NAS-Port. 

Now, if we were enforcing concurrency limits we'd be even more screwed. 

Has anyone else experienced this? How are you dealing with it? Does Radiator
have any solutions? I wonder if using the Acct-Session-Id for deletions
would be more reliable than matching NAS/Port combos. Comments welcome!

Dave 
_____________________________ 

Wed Jul 10 15:23:21 2002: DEBUG: Packet dump: 
*** Received from 216.118.66.25 port 1646 .... 
Code:       Accounting-Request 
Identifier: 188 
Authentic:  <218><232>t<199>j<163><234><138><27><251><221><133>HsX<142> 
Attributes: 
        Acct-Session-Id = "000087C2" 
        Framed-Protocol = PPP 
        Connect-Info = "46667/24000 V90/V42bis/LAPM" 
        cisco-avpair = "connect-progress=Call Up" 
        Acct-Authentic = RADIUS 
        Acct-Status-Type = Start 
        User-Name = "tmeyers" 
        Acct-Multi-Session-Id = "0000511D" 
        Acct-Link-Count = "<0><0><0><2>" 
        Framed-Address = 216.118.88.4 
        Cisco-NAS-Port = "Async4/105*Serial7/0:25:3" 
        NAS-Port = 105 
        NAS-Port-Type = Async 
        Class = "netcarrier.com" 
        Service-Type = Framed-User 
        NAS-IP-Address = 216.118.66.25 
        Event-Timestamp = 1026329001 
        Acct-Delay-Time = 0 


Wed Jul 10 15:26:16 2002: DEBUG: Packet dump: 
*** Received from 216.118.66.25 port 1646 .... 
Code:       Accounting-Request 
Identifier: 239 
Authentic:  <30>u<226><4><138><177><143><248><254>:<165>d<182><<200>? 
Attributes: 
        Acct-Session-Id = "000084AB" 
        Framed-Protocol = PPP 
        cisco-avpair = "connect-progress=Call Up" 
        Acct-Session-Time = 2897 
        Connect-Info = "49333/24000 V90/V42bis/LAPM" 
        Acct-Input-Octets = 349671 
        Acct-Output-Octets = 2362531 
        Acct-Input-Packets = 3246 
        Acct-Output-Packets = 2835 
        Acct-Terminate-Cause = User-Request 
        cisco-avpair = "disc-cause-ext=PPP Receive Term" 
        Acct-Authentic = RADIUS 
        Acct-Status-Type = Stop 
        User-Name = "cheezwhiz" 
        Acct-Multi-Session-Id = "00004F51" 
        Acct-Link-Count = "<0><0><0><1>" 
        Framed-Address = 216.118.90.220 
        Cisco-NAS-Port = "Async3/105*Serial7/0:18:21" 
        NAS-Port = 105 
        NAS-Port-Type = Async 
        Class = "netcarrier.com" 
        Service-Type = Framed-User 
        NAS-IP-Address = 216.118.66.25 
        Event-Timestamp = 1026329176 
        Acct-Delay-Time = 0 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20020710/50e9bb40/attachment.html>