AAA Secondary ACS Entry

[s.kho]

Hi,

I have 802.1x and MAB configured. I added a second ACS server and added the definition on the switch.
My issue is that the ACS works fine when it is configured as the primary option in the switch. But when it is configured as the backup and I force a failure on the primary, it doesn't seem to try and use th backup ACS.

My configuration below, can someone please give me pointers?

Thanks

aaa group server radius rrrr
server-private 10.4.25.117 auth-port 1645 acct-port 1646 key 7 01100F175804575D72
server-private 10.4.25.114 auth-port 1645 acct-port 1646 key 7 01100F175804575D72
ip radius source-interface Vlan200
!
aaa new-model

aaa authentication dot1x default group rrrr
aaa authorization exec default local if-authenticated
aaa authorization network default group rrrr
aaa accounting dot1x default start-stop group rrrr

interface FastEthernet0/1
switchport access vlan 200
switchport mode access
switchport voice vlan 2
authentication control-direction in
authentication event fail action authorize vlan 100
authentication event server dead action authorize vlan 100
authentication event no-response action authorize vlan 100
authentication host-mode multi-domain
authentication order dot1x mab
authentication port-control auto
authentication violation protect
mab
dot1x pae authenticator
dot1x timeout quiet-period 3
dot1x timeout tx-period 4
spanning-tree portfast

[Tiago Antunes]

Hi,

How are you testing the failover?

What actions are you doing in order to simulate a failure of the primary?

Can you send the full show-run?

Can you please enable "debug radius" and reproduce that failure sharing the output with us?

HTH,

Tiago

--

If  this helps you and/or answers your question please mark the question as  "answered" and/or rate it, so other users can easily find it.

[s.kho]

Hi Tiago,

I was issuing application stop acs command and/or a reload on the server that I want to simulate a failure.

Attached is the configuration of the switch and the two radius debug logs. Both ACS only works fine when it is defined as the primary entry. The debug logs were captured with 10.4.25.117 defined as the primary entry with its services stopped.

Port int f0/1 is the port used to connect my dot1x workstation.

Thanks

[Richard Burts]

I have experienced problems similar to what you are describing. I had a primary server configured and a backup server. There was a situation where some services on the primary were stopped and this meant that it could not successfully authenticate. But ACS was still running. The server was still listening on the appropriate ports. It received the authentication request and instead of returning a response of ERROR it was returning a response of FAIL. This prevented my device from attempting the backup server.

If you want to check it out I would suggest that you try running debug radius authentication and see if you are receiving a response from the primary server and if so what is the response.

I would also suggest that you change your testing methodology. Produce a failure in the primary server by disconnecting its network connection or by configuring it with a different IP address. See what would happen with that type of failure.

HTH

Rick

[Tiago Antunes]

Hi,

It looks there is a misbehavior from the switch as when the ACS 10.4.25.114 is sending an access-chalenge with an ID for which the switch says it did not knows it:

2d16h: RADIUS: Fail-over to (10.4.25.114:1645,1646) for id 1645/61
2d16h: RADIUS: Received from id 1645/61 10.4.25.114:1645, Access-Challenge, len 84
2d16h: RADIUS:  authenticator C3 E4 6F BF 4F A6 43 B5 - FF 1C 19 85 70 95 D6 55
2d16h: RADIUS:  State               [24]  38
2d16h: RADIUS:   33 33 53 65 73 73 69 6F 6E 49 44 3D 42 51 4C 44  [33SessionID=BQLD]
2d16h: RADIUS:   45 56 41 43 53 30 31 2F 38 30 37 32 33 32 32 37  [EVACS01/80723227]
2d16h: RADIUS:   2F 31 30 3B              [ /10;]
2d16h: RADIUS:  EAP-Message         [79]  8
2d16h: RADIUS:   01 A8 00 06 19 21                 [ !]
2d16h: RADIUS:  Message-Authenticato[80]  18
2d16h: RADIUS:   77 40 BA 76 AF 14 67 BC 2C 6C AF E8 51 16 3D 8C          [ w@vg,lQ=]
2d16h: RADIUS(00000011): Received from id 1645/61
2d16h: RADIUS(00000011): Unique id not in use
2d16h: RADIUS/DECODE(00000011): There is no RADIUS DB Some Radius attributes may not be stored
2d16h: RADIUS/DECODE: EAP-Message fragments, 6, total 6 bytes
2d16h: RADIUS: Retransmit to (10.4.25.117:1645,1646) for id 1645/62
2d16h: RADIUS: Retransmit to (10.4.25.117:1645,1646) for id 1645/62
2d16h: RADIUS: Retransmit to (10.4.25.117:1645,1646) for id 1645/62
2d16h: RADIUS: Fail-over to (10.4.25.114:1645,1646) for id 1645/62
2d16h: RADIUS: Received from id 1645/62 10.4.25.114:1645, Access-Challenge, len 84

I would advise you to open a TAC Service Request to investigate deeper.

HTH,

Tiago

--

If  this helps you and/or answers your question please mark the question as  "answered" and/or rate it, so other users can easily find it.

[sandy.kho · Accepted solution]

Hi Tiago,

The fix was to configure the following:

radius-server restransmit 2

radius0server timeout 3

to allow for it to transistion to the secondary ACS server before commencing authnetication. It was trying to authenticate before it move to the second ACS.

Thanks for you help.