(RADIATOR) "Ascend-Access-Event-Request".
Cortney Thompson
Cortney at wyoming.com
Wed Apr 17 11:58:22 CDT 2002
Logs are gone, Trace 4 shows the handler picking these requests up now.
Thanks again guys.
At 06:05 PM 4/16/02 -0600, Cortney Thompson wrote:
>I guess I should have also. I will try that out.
>
>Thanks
>
>At 08:27 AM 4/17/02 +1000, Hugh Irvine wrote:
>
>>Hello Cortney -
>>
>>I should have seen this before - your Handler should look like this:
>>
>><Handler Request-Type=Ascend-Access-Event-Request>
>>
>>regards
>>
>>Hugh
>>
>>
>>On Wed, 17 Apr 2002 00:35, Cortney Thompson wrote:
>> > Well I thought that took care of it, but I checked log files today and
>> > those logs are back. I put the handler in both my AAA servers, and my PRXY
>> > servers. So at least one of them should be picking it up.
>> >
>> > Here is some sample debug. Off the problem. I have no clue why the
>> > handler you gave me is not picking these requests up.
>> >
>> > Tue Apr 16 07:50:24 2002: DEBUG: Packet dump:
>> > *** Received from XXX.XXX.XXX.XXX port 7017 ....
>> > Code: Ascend-Access-Event-Request
>> > Identifier: 123
>> > Authentic: %<136>t<171><188><2>aC<128><203><245>Z<243>W<230><28>
>> > Attributes:
>> > NAS-IP-Address = XXX.XXX.XXX.XXX
>> > Port_Entry = "<0><0><0><1>"
>> >
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler Realm=nms should be used
>> > to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Called-Station-Id=/XXX1000$/ should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Called-Station-Id=/XXX1111$/ should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Called-Station-Id=/XXX1111$/ should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Called-Station-Id=/XXX1111$/ should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Called-Station-Id=/XXX1111$/ should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Called-Station-Id=/XXX1111$/ should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Called-Station-Id=/XXX1111$/ should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Called-Station-Id=/XXX1111$/ should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Called-Station-Id=/XXX1111$/ should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Called-Station-Id=/XXX8378$/ should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler
>> > Code=Ascend-Access-Event-Request should be used to handle this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Check if Handler should be used to
>> handle
>> > this request
>> > Tue Apr 16 07:50:24 2002: DEBUG: Handling request with Handler ''
>> > Tue Apr 16 07:50:24 2002: DEBUG: Handling with Radius::AuthRADIUS
>> > Tue Apr 16 07:50:24 2002: DEBUG: Packet dump:
>> > *** Sending to AAA1 port 1812 ....
>> > Code: Ascend-Access-Event-Request
>> > Identifier: 1
>> > Authentic: %<136>t<171><188><2>aC<128><203><245>Z<243>W<230><28>
>> > Attributes:
>> > NAS-IP-Address = XXX.XXX.XXX.XXX
>> > Port_Entry = "<0><0><0><1>"
>> >
>> >
>> > Let me know if you need any thing else.
>> >
>> > Thanks,
>> > Cortney
>> >
>> > At 11:03 AM 4/15/02 -0600, Cortney Thompson wrote:
>> > >Frank, Hugh
>> > >
>> > >Thanks for the Handler. Works like a charm. Logs look much better now.
>> > >
>> > >Thanks again.
>> > >
>> > >Cortney
>> > >
>> > >At 11:50 AM 4/13/02 +1000, Hugh Irvine wrote:
>> > >>Hello Frank, Hello Cortney -
>> > >>
>> > >>You should probably use DefaultResult ACCEPT, otherwise the NAS will
>> > >> continue to send the requests over an over again.
>> > >>
>> > >>regards
>> > >>
>> > >>Hugh
>> > >>
>> > >>On Sat, 13 Apr 2002 07:13, Frank Danielson wrote:
>> > >> > It looks like the problem is that your servers AAA1 and AAA2 do not
>> > >> > know what to do with an Ascend-Access-Event-Request. I found this
>> > >>
>> > >> explanation of
>> > >>
>> > >> > the Ascend-Access-Event-Request on the web by doing a quick Google
>> > >> > search: ..................................
>> > >> > Ascend-Access-Event-Request (33)
>> > >> > The MAX TNT can report the number of sessions by class to the RADIUS
>> > >> > authentication server and to the RADIUS accounting server. The
>> MAX TNT
>> > >> > reports the number of sessions by sending an
>> > >> > Ascend-Access-Event-Request (33) packet type at a user-defined
>> > >> > interval specified by one of the following parameters:
>> > >> >
>> > >> > Auth-Sess-Interval in the Rad-Auth-Client subprofile of the
>> > >> > External-Auth profile
>> > >> >
>> > >> > Acct-Sess-Interval in the Rad-Acct-Client subprofile of the
>> > >> > External-Auth profile
>> > >> > ...................................
>> > >> >
>> > >> > Since this just looks like extra accounting data that you have
>> > >> > obviously been living without I would deal with it by using a handler
>> > >> > clause at
>> > >>
>> > >> Prxy1
>> > >>
>> > >> > and Prxy2 that looks something like this:
>> > >> >
>> > >> > <Handler Code=Ascend-Access-Event-Request>
>> > >> > <AuthBy INTERNAL>
>> > >> > DefaultResult ACCEPT
>> > >> > </AuthBy>
>> > >> > </Handler>
>> > >> >
>> > >> > <Handler>
>> > >> > <AuthBy RADIUS>
>> > >> > Secret somesecret
>> > >> > Host AAA1
>> > >> > Host AAA2
>> > >> > </AuthBy>
>> > >> > </Handler>
>> > >> >
>> > >> >
>> > >> > You could change the DefaultResult to IGNORE or REJECT at your
>> option.
>> > >> >
>> > >> > >===== Original Message From Cortney Thompson <Cortney at wyoming.com>
>> > >> > > ===== Lately I have been getting an increase in these logs.
>> > >> > >
>> > >> > >Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5
>> > >> > >retransmissions to AAA1 for (25)
>> > >> > >Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5
>> > >> > >retransmissions to AAA2 for (1)
>> > >> > >Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS could not find a working
>> > >> > > host to forward to. Ignoring
>> > >> > >
>> > >> > >I know what the problem is, however the answer to the problem is
>> > >> > > alluding me very well. These are not ACCT, or AUTH packets. If
>> > >> > > they were, they would have a UserID by them. These do no.
>> > >> > >
>> > >> > >Doing more investigation, I find that all requests that have this
>> > >> > > problem are Code: "Ascend-Access-Event-Request".
>> > >> > >I get these logs in my Radius Proxy servers (Prxy1, & Prxy2). The
>> > >> > > proxy servers talk with two other Radiator machines. (AAA1, and
>> > >> > > AAA2) For the actual Auth, and Acct.
>> > >> > >These logs are from my prxy1 machine. Prxy2 logs very similar.
>> > >> > >
>> > >> > >
>> > >> > >Fri Apr 12 11:33:51 2002: DEBUG: Packet dump:
>> > >> > >*** Received from XXX.XXX.XXX.XXX port 7023 ....
>> > >> > >Code: Ascend-Access-Event-Request
>> > >> > >Identifier: 25
>> > >> > >Authentic: <15>\<200><163>7<218>=<179>u~0<166><233>[<211><214>
>> > >> > >Attributes:
>> > >> > > NAS-IP-Address = XXX.XXX.XXX.XXX
>> > >> > > Port_Entry = "<0><0><0><1>"
>> > >> > >
>> > >> > >
>> > >> > >*** Sending to AAA1 port 1812 ....
>> > >> > >Code: Ascend-Access-Event-Request
>> > >> > >Identifier: 25
>> > >> > >Authentic: <15>\<200><163>7<218>=<179>u~0<166><233>[<211><214>
>> > >> > >Attributes:
>> > >> > > NAS-IP-Address = XXX.XXX.XXX.XXX
>> > >> > > Port_Entry = "<0><0><0><1>"
>> > >> > >
>> > >> > >Fri Apr 12 11:34:26 2002: DEBUG: Timed out, retransmitting
>> > >> > >Fri Apr 12 11:34:26 2002: DEBUG: Packet dump:
>> > >> > >*** Sending to AAA1 port 1812 ....
>> > >> > >Code: Ascend-Access-Event-Request
>> > >> > >Identifier: 25
>> > >> > >Authentic: <15>\<200><163>7<218>=<179>u~0<166><233>[<211><214>
>> > >> > >Attributes:
>> > >> > > NAS-IP-Address = XXX.XXX.XXX.XXX
>> > >> > > Port_Entry = "<0><0><0><1>"
>> > >> > >
>> > >> > >Fri Apr 12 11:34:21 2002: INFO: AuthRADIUS: No reply after 5
>> > >> > >retransmissions to AAA1 for (25)
>> > >> > >Fri Apr 12 11:34:21 2002: DEBUG: Packet dump:
>> > >> > >*** Sending to AAA2 port 1812 ....
>> > >> > >Code: Ascend-Access-Event-Request
>> > >> > >Identifier: 1
>> > >> > >Authentic: <15>\<200><163>7<218>=<179>u~0<166><233>[<211><214>
>> > >> > >Attributes:
>> > >> > > NAS-IP-Address = XXX.XXX.XXX.XXX
>> > >> > > Port_Entry = "<0><0><0><1>"
>> > >> > >
>> > >> > >Fri Apr 12 11:34:26 2002: DEBUG: Timed out, retransmitting
>> > >> > >Fri Apr 12 11:34:26 2002: DEBUG: Packet dump:
>> > >> > >*** Sending to AAA2 port 1812 ....
>> > >> > >Code: Ascend-Access-Event-Request
>> > >> > >Identifier: 1
>> > >> > >Authentic: <15>\<200><163>7<218>=<179>u~0<166><233>[<211><214>
>> > >> > >Attributes:
>> > >> > > NAS-IP-Address = XXX.XXX.XXX.XXX
>> > >> > > Port_Entry = "<0><0><0><1>"
>> > >> > >
>> > >> > >Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS: No reply after 5
>> > >> > >retransmissions to AAA2:1812 for (1)
>> > >> > >Fri Apr 12 11:34:51 2002: INFO: AuthRADIUS could not find a working
>> > >> > > host to forward to. Ignoring
>> > >> > >
>> > >> > >
>> > >> > >As we can see the Prxy's are working correctly. They did not
>> receive
>> > >> > > a reply, so they retransmitted 5 times. Just what I have
>> > >> > > configured. Then it drops the packet, with no working host found.
>> > >> > > My Question is this. How can I get my Radiator AAA1, and AAA2 to
>> > >> > > listen to these requests. Right now the Prxy1, and Prxy2
>> listen, but
>> > >> > > the AAA's will not pick these requests up. There are no logs in
>> > >> > > AAA1, or AAA2 of this request even getting to them.... All four
>> > >> > > servers are at 2.19. The only thing I can think of, is Dictionary.
>> > >> > > I use a pure Ascend2 dictionary on the Prxy's, and a combination of
>> > >> > > Default Dictionary,Ascend2, and Cisco. on the AAA machines.
>> > >> > >
>> > >> > >Could this be my problem? Do I need the entire Ascned2
>> dictionary on
>> > >> > > the AAA's?
>> > >> > >
>> > >> > >Am I missing something?
>> > >> > >
>> > >> > >Any help is appreciated.
>> > >> > >
>> > >> > >Thanks
>> > >> > >Cortney
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >Cortney Thompson
>> > >> > >Cortney at wyoming.com
>> > >> > >
>> > >> > > Opinions are mine and do not necessarily reflect
>> > >> > > those of wyoming.com LLC
>> > >> > >
>> > >> > >===
>> > >> > >Archive at http://www.open.com.au/archives/radiator/
>> > >> > >Announcements on radiator-announce at open.com.au
>> > >> > >To unsubscribe, email 'majordomo at open.com.au' with
>> > >> > >'unsubscribe radiator' in the body of the message.
>> > >> >
>> > >> > Frank Danielson
>> > >> > [Infrastructure Architect]
>> > >> >
>> > >> > wireless:407.467.7832
>> > >> > fax:407.515.9001
>> > >> >
>> > >> > Data On Air
>> > >> > 301 E. Pine St. Suite 450
>> > >> > Orlando, FL 32801
>> > >> > USA
>> > >> >
>> > >> > ===
>> > >> > Archive at http://www.open.com.au/archives/radiator/
>> > >> > Announcements on radiator-announce at open.com.au
>> > >> > To unsubscribe, email 'majordomo at open.com.au' with
>> > >> > 'unsubscribe radiator' in the body of the message.
>> > >>
>> > >>--
>> > >>Radiator: the most portable, flexible and configurable RADIUS server
>> > >>anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
>> > >>-
>> > >>Nets: internetwork inventory and management - graphical, extensible,
>> > >>flexible with hardware, software, platform and database independence.
>> > >>===
>> > >>Archive at http://www.open.com.au/archives/radiator/
>> > >>Announcements on radiator-announce at open.com.au
>> > >>To unsubscribe, email 'majordomo at open.com.au' with
>> > >>'unsubscribe radiator' in the body of the message.
>> > >
>> > >Cortney Thompson
>> > >Cortney at wyoming.com
>> > >
>> > > Opinions are mine and do not necessarily reflect
>> > > those of wyoming.com LLC
>> > >
>> > >===
>> > >Archive at http://www.open.com.au/archives/radiator/
>> > >Announcements on radiator-announce at open.com.au
>> > >To unsubscribe, email 'majordomo at open.com.au' with
>> > >'unsubscribe radiator' in the body of the message.
>> >
>> > Cortney Thompson
>> > Cortney at wyoming.com
>> >
>> > Opinions are mine and do not necessarily reflect
>> > those of wyoming.com LLC
>>
>>--
>>Radiator: the most portable, flexible and configurable RADIUS server
>>anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
>>-
>>Nets: internetwork inventory and management - graphical, extensible,
>>flexible with hardware, software, platform and database independence.
>
>
>Cortney Thompson
>Cortney at wyoming.com
>
> Opinions are mine and do not necessarily reflect
> those of wyoming.com LLC
>
>===
>Archive at http://www.open.com.au/archives/radiator/
>Announcements on radiator-announce at open.com.au
>To unsubscribe, email 'majordomo at open.com.au' with
>'unsubscribe radiator' in the body of the message.
Cortney Thompson
Cortney at wyoming.com
"Brilliance is often born in the crucible of desperation."
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list