fine tuning the logging to cisco device

Answered Question
Jul 10th, 2008

Dear Netpro Community,

I am trying to fine tune the AAA portion on the cisco device

Here is my current configuration:

aaa new-model

aaa authentication login default group radius local

aaa authentication enable default group radius enable

If the radius server is offline, the first level is not a problem. However, the issue occurs if I want to go to enable mode. It will not use the enable password defined locally, but instead it will go to and search for radius server for authentication.

Debug:

test_switch>en

Password:

01:05:15: RADIUS: Authenticating using $enab15$

01:05:15: RADIUS: ustruct sharecount=1

01:05:15: RADIUS: Initial Transmit tty0 id 44 x.x.x.x:1812, Access-Request,

len 72

01:05:15: Attribute 4 6 AC10E10F

01:05:15: Attribute 5 6 00000000

01:05:15: Attribute 61 6 00000000

01:05:15: Attribute 1 10 24656E61

01:05:15: Attribute 2 18 69ABFDF8

01:05:15: Attribute 6 6 00000006

01:05:20: RADIUS: Retransmit id 44

01:05:25: RADIUS: Retransmit id 44

01:05:30: RADIUS: Retransmit id 44

Password:

01:05:35: RADIUS: Marking server x.x.x.x:1812,1813 dead

01:05:35: RADIUS: Tried all servers.

01:05:35: RADIUS: No valid server found. Trying any viable server

01:05:35: RADIUS: Tried all servers.

01:05:35: RADIUS: No response for id 44

01:05:35: RADIUS: No response from server

% Password: timeout expired!

% Error in authentication.

How do I ensure that i can access the switch in privilege mode if there is no path to the radius server?

I have this problem too.
0 votes
Correct Answer by michael.leblanc about 8 years 4 months ago

It took 20 sec. from initial transmit:

01:05:15: RADIUS: Initial Transmit tty0 id 44 x.x.x.x:1812, Access-Request,

len 72

... with three retransmits, until the server was marked dead:

01:05:35: RADIUS: Marking server x.x.x.x:1812,1813 dead

Perhaps you should mark an MIA RADIUS Server as dead more rapidly, by defining a RADIUS Server timeout (e.g.: 1 sec.).

e.g.:

radius-server host aaa.bbb.ccc.ddd auth-port 1812 acct-port 1813 timeout 1 key xxxxxxxxxx

If the server is recognized as dead earlier (4 sec., incl. 3 retransmits) perhaps there is an opportunity to utilize the locally configured enable password before the "password timeout occurs".

I'm not saying for sure that this will resolve your issue, but I know I'd try it to find out.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
Jagdeep Gambhir Thu, 07/10/2008 - 04:18

Benson,

Enable authentication was meant to function with TACACS, and when used with RADIUS it does

not perform the same.

As a result, the only way for you to get enable authentication to work with RADIUS would be to input the username $enab15$ into your RADIUS server and every user would need to use that username.

Regards,

~JG

Do rate helpful posts

Correct Answer
michael.leblanc Thu, 07/10/2008 - 07:08

It took 20 sec. from initial transmit:

01:05:15: RADIUS: Initial Transmit tty0 id 44 x.x.x.x:1812, Access-Request,

len 72

... with three retransmits, until the server was marked dead:

01:05:35: RADIUS: Marking server x.x.x.x:1812,1813 dead

Perhaps you should mark an MIA RADIUS Server as dead more rapidly, by defining a RADIUS Server timeout (e.g.: 1 sec.).

e.g.:

radius-server host aaa.bbb.ccc.ddd auth-port 1812 acct-port 1813 timeout 1 key xxxxxxxxxx

If the server is recognized as dead earlier (4 sec., incl. 3 retransmits) perhaps there is an opportunity to utilize the locally configured enable password before the "password timeout occurs".

I'm not saying for sure that this will resolve your issue, but I know I'd try it to find out.

Jagdeep Gambhir Fri, 07/11/2008 - 06:22

Well one sec is quite low and can cause issue when reaching radius server. Default / recommended timeout value is 5 secs.

The issue here is that enable authentication is not working when radius server is down. This has nothing to do with radius timeout value.

Infact you need to increase the "login response timeout" using this command in vty, so that it wont expire by the time it falls back to enable method.

Router(config-line)#timeout login response ?

<1-300> Timeout in seconds

So keep radius timeout 5 and timeout login response 30 secs.

Regards,

~JG

michael.leblanc Fri, 07/11/2008 - 07:40

Jagdeep:

With the default "radius-server retransmit" value, there are (potentially) three retransmissions that may occur if the RADIUS server doesn't respond to the first request. With a 1 sec. "radius-server timeout", this provides a four second window of opportunity for a successful response.

If he doesn't want to use a "radius-server timeout" as low as 1 sec. (per your concern), he can use the "radius-server retransmit" command to constrain (to a reasonable period) the time required to mark an MIA RADIUS Server as dead.

e.g.:

radius-server host aaa.bbb.ccc.ddd auth-port 1812 acct-port 1813 timeout 2 retransmit 1 key xxxxxxxxxx

Contrary to your statement, your approach and mine are trying to facilitate the same thing, i.e.: accommodating fall back to the enable method prior to login timeout.

However, your recommendation only results in a successful login after 20+ sec., due to postponement of fall back, resulting from the 20 sec. spent determining that the MIA RADIUS Server is dead.

I don't ever want to wait 20+ sec. for a login, and don't find it necessary to wait that long to conclude that an AAA server is MIA.

Jagdeep Gambhir Fri, 07/11/2008 - 08:00

Michael,

What you are saying is correct. My point was to increase the timeout to atleast 5 sec as one sec can lead to radius request timing out quite often (when radius is up)

So best tweak would be to lower the

Router(config)#radius-server retransmit 2 or 1

Router(config)#radius-server timeout 5

Router(config-line)#timeout login response 25

Thank You !

Regards,

~JG

Actions

This Discussion