(RADIATOR) "Ascend-Access-Event-Request".

Cortney Thompson Cortney at wyoming.com
Mon Apr 15 12:03:25 CDT 2002


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.


More information about the radiator mailing list