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 <[EMAIL PROTECTED]> > >> > > ===== 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 > >> > >[EMAIL PROTECTED] > >> > > > >> > > Opinions are mine and do not necessarily reflect > >> > > those of wyoming.com LLC > >> > > > >> > >=== > >> > >Archive at http://www.open.com.au/archives/radiator/ > >> > >Announcements on [EMAIL PROTECTED] > >> > >To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] > >> > To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] > >>To unsubscribe, email '[EMAIL PROTECTED]' with > >>'unsubscribe radiator' in the body of the message. > > > >Cortney Thompson > >[EMAIL PROTECTED] > > > > Opinions are mine and do not necessarily reflect > > those of wyoming.com LLC > > > >=== > >Archive at http://www.open.com.au/archives/radiator/ > >Announcements on [EMAIL PROTECTED] > >To unsubscribe, email '[EMAIL PROTECTED]' with > >'unsubscribe radiator' in the body of the message. > > Cortney Thompson > [EMAIL PROTECTED] > > 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
