OK ... from what I understand of the RADIUS Vendor-specific attribute, it
needs to include a vendor-ID in the packet going from the server (RadiusNT)
to the client (a Cisco 2511). Enabling Debugging on the cisco, I find that
it's rejecting the Vendor-Specific packet sent from the RadiusNT server.
Here's an extract from the debug output:
Radius: Initial Transmit id 219 [Radius Server]:1645, Access-Request, len 77
Attribute 4 6 CB13D61B
Attribute 5 6 00000013
Attribute 61 6 00000000
Attribute 1 6 74657374
Attribute 31 15 3230332E
Attribute 2 18 2510FB99
Radius: Received from id 219 [Radius Server]:1645, Access-Accept, len 66
Attribute 6 6 00000006
Attribute 26 40 636973636F2D6176
RADIUS: saved authorization data for user 181FCC at 17FBEC
AAA/AUTHEN (118427841): status = PASS
Radius: unrecognized Vendor code 1667855203
The last line is my worry. I feel that the 2511 is rejecting the
Vendor-Specific attribute sent from the Radius server because the Vendor
Code should be set to the Cisco code. Am I wrong??
>> Can someone please reply to this one. It is rather important!! I've been
>> trying for over a month to get cisco a/v pairs working with radiusNT to no
>> success.
>
>Are these VS pairs, or standard RADIUS A/V pairs? Which ones?
Actually, they're tacacs+ A/V pairs. Cisco have implemented radius such
that it will accept tacacs+ A/V pairs submitted via the vendor-specific
Radius attribute.
>> Also, an answer on what EXACTLY call consolidation does would be
>> appreciated as well. Yes, I know it just summarises the calls for a month.
>> But is it a month based from the 1st of every month or based on the expire
>> date?? Or is it based on something else?? Somebody must know this. Surely
>> we haven't all been using this software package like a blind man uses a book.
>
>The Calls Consoliation is based upon the user's expire date.
OK. That's what I thought. But I have evidence that it's not
consolidating properly. I'm going to try and write something here on my
side that does consolidation. AFAIK, the only two tables affected during
the process are the CallHistory and Calls table.
Any code that you want to submit, Dale, would be extremely helpful.
BTW, the problem is that I'm finding a discrepancy between the times
listed in the call history and the times checked manually via the "Time On".
I'm doing the consolidation on a test SQL server and the "Time On" check on
our real server.
--------------------------------------#------------------------------------
David Khoury | "Where's the KABOOM ??
Technical Manager & Comms Engineer | There was supposed to be an
dave@flex.com.au | earth shattering KABOOM!!"
http://www.flex.com.au/~dave | Marvin the Martian
--------------------------------------#------------------------------------