(RADIATOR) "Ascend-Access-Event-Request".
Hugh Irvine
hugh at open.com.au
Tue Apr 16 17:27:01 CDT 2002
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.
===
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